Summary

  • Revision 01 of Using KYAPay Tokens, posted on 2 October 2026, changes the consumer role from “verifier” to “recipient” and says explicitly that identification is distinct from admission. A valid token supplies authenticated context; the recipient still chooses whether to admit, challenge, rate-limit or deny.
  • The same validation cannot prove every later proposition. A bearer token does not prove possession of a private key, an issuance-time authorization does not prove continuous human control, and a payment credential does not prove merchant acceptance or settlement.

The sharpest change in draft-skyfire-oauth-using-kyapay-tokens-01 is a noun. The system that consumes a KYAPay token is no longer called the verifier. It is the recipient.

That change matters because verification describes a test, while receipt describes a position of authority. Revision 01 says the party at that position may be a target resource server, an edge provider, a bot manager, a fraud manager, an account-takeover protector or a customer-identity system. Each can validate the same signed assertion and still make a different local decision.

The new introduction makes the separation explicit. A KYA token can carry an issuer-signed account of the human principal, the agent platform and the agent instance. A PAY token can add payment context. If the cryptography and registered claims validate, the recipient has a stronger answer to “who does the issuer say is behind this request?” It has not received a command to open the gate.

Revision 01 calls identification distinct from admission. The token is input to a site-configured policy engine. The recipient can admit the request, limit it, demand stronger authentication or reject it. A low-risk browsing action may need less assurance than an account change or a large payment. One green “verified agent” badge would erase exactly the distinctions the draft asks the recipient to retain.

The document and its companion format are still individual Internet-Drafts. Their frozen Datatracker records show no stream, intended standards level or standards level. The OAuth mailing list is the discussion venue, not evidence of Working Group adoption. Requested HTTP-field or JWT-claim registrations are proposals until the registries show otherwise.

The common processing path is useful because it exposes several independent checks. The recipient first decides whether the issuer is trusted. It validates the JWT signature and header, then the expiry, issuance time, token identifier, audience and environment. It determines the token type and the assurance attached to the human, platform and agent claims. Mere presence of a KYAPay-Token field is not a human-presence signal.

Even a successful sequence leaves another boundary: presentation. By default, the specification describes bearer tokens. Anyone who captures one may present it during its validity window. Short lifetime, TLS, audience binding and replay storage reduce the exposure. They do not prove that the sender holds an agent-controlled private key.

The companion token revision allows a cnf claim. That identifies confirmation-key material and can make the token sender-constrained—but only when the surrounding protocol requires a proof and the recipient actually verifies it. A key reference inside a signed object is not the proof itself. Revision 01 therefore treats identity and proof of possession as separate layers and calls the stronger path planned evolution.

Time adds another limit. The draft says a valid token attests that the principal authorized the agent at issuance. It does not show that the person remains in control for the whole lifetime. An agent host can be compromised after issuance, a platform can be deregistered, or authority can be withdrawn. Revision 01 defines no revocation mechanism. The shorter the action's tolerance for stale authority, the more the recipient needs a fresh challenge or another control.

Issuer trust is also local. A correct signature proves that a key corresponding to the selected issuer signed the token. It does not prove that the issuer's identity proofing, agent registration, platform controls or verifier evidence meet the recipient's risk threshold. The draft calls scalable issuer trust an open problem and says trust currently depends on out-of-band arrangements. That makes the trust-list version part of the decision receipt.

Payment context must not swallow the same caveat. The companion format can bind a target, amount and currency and carry a transaction-scoped credential with a single-use cryptogram. Those properties make a captured credential less reusable and let a fraud system compare the intended transaction with the request. They do not prove that the merchant accepted it, that a network authorized or cleared it, that settlement became final, that a refund is impossible, or that goods arrived.

A defensible receipt consequently needs several coordinates. Record the exact KYAPay draft and token profile; issuer and key-set version; identity-verifier evidence and assurance; immutable token hash; signature and registered-claim results; audience and environment; replay-store decision; bearer or proof-of-possession result; recipient policy and step-up outcome; and final application action. For a payment, append the separate authorization, clearing, settlement and reversal records that actually exist.

This is not an argument against interoperable assertions. It is the condition for using them without transferring invisible power. Common syntax can let multiple intermediaries see the same human, agent and platform coordinates. Consistency improves when they stop guessing from IP ranges and User-Agent strings. But shared evidence need not mean one centrally imposed action.

Heng Lu’s Minimum Initial Specification supports that architecture: define the smallest shared claims and validation invariants, then leave consequence-sensitive policy local and inspectable. Running-Code Primacy adds the operational test. A signed token does not execute the application, and a future registry entry would not prove the request succeeded. Reality Layers prevents an issuer assertion, a signature result, a key proof, a policy decision and a human-visible outcome from collapsing into “authorized”.

Revision 01’s recipient is therefore more than a terminology repair. It names where the next decision lives. The issuer can attest. The token can transport. The validator can check. The recipient still governs its interface, and the application must record what it actually did.

Sources