]> Skyfire Systems Inc.

ankit_agarwal@yahoo.com https://skyfire.xyz

Self-Issued Consulting

michael_b_jones@hotmail.com https://self-issued.info/

Akamai

sthumma@akamai.com

Security Web Authorization Protocol agent agentic commerce agentic commerce identity JWT bot management fraud account takeover payment The KYAPay Token is a JSON Web Token (JWT) that carries verified identity ("Know Your Agent", KYA) and payment (PAY) information for requests made by software agents on behalf of human principals. This document describes how security intermediaries -- bot managers, fraud managers, account-takeover (ATO) protection systems, and customer identity and access management (CIAM) systems -- consume KYAPay tokens to answer a question that traditional bot detection cannot: "did a verified human authorize this agent?", rather than "is this a human?". It specifies how KYAPay tokens are carried in HTTP requests, how they are validated (including in combination with request-signing layers such as HTTP Message Signatures), and how the verified, layered identity in a token is used to make access, routing, fraud detection, account-lifecycle, and step-up decisions. It defines the token-consuming "recipient" role that the KYAPay Token leaves unspecified. It is intentionally non-prescriptive about how tokens are created, because agent architectures, agent-identity technologies, and agent-communication protocols are diverse and still emerging; the token itself is the interoperability contract. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Legitimate automated traffic acting on behalf of users is a long-standing feature of the web. Financial aggregation tools, automated booking agents, and data synchronizers routinely interact with web services at the direction of their subscribers. To prevent legitimate automation from being blocked by defenses designed to detect malicious bots, security intermediaries have traditionally relied on static network metadata -- including published IP ranges, Autonomous System Numbers (ASNs), and User-Agent strings -- to identify bots and apply configured policies. This network-level model identifies bots primarily by associating their traffic with a known operator or network. However, its verification mechanisms are brittle: User-Agent headers are easily forged, IP ranges change across cloud providers and shared egress infrastructure, and network metadata cannot establish which individual subscriber authorized a particular request. The result is that network-level bot identification can establish where automated traffic comes from, but not which principal it is acting for. The rise of capable AI agents makes this limitation more significant. An account aggregation service reimplemented as an LLM-orchestrated agent may perform the same task for the same subscriber, but through dynamic execution flows. The relevant distinction is therefore not simply between human and automated traffic, but between:

• direct human interaction,
• a human or organization acting through an authorized agent, and
• unattended automation without verifiable authorization from an identified principal.

Rather than relying on fragile network indicators to establish legitimacy, an agent presenting a KYAPay token can provide cryptographically verifiable assertions about the agent and the principal it is authorized to represent. KYAPay tokens provide issuer-signed assertions that can be verified against trusted public keys. A KYAPay token is a signed JSON Web Token (JWT) that can carry the agent instance (aid), the execution platform (apd), and the identified principal the issuer asserts the agent acts for (hid) -- the KYA ("Know Your Agent") information -- and optionally payment credentials (the PAY information). A validated KYA token asserts that a trusted issuer has verified, to an established level of assurance, that the identified principal authorized the identified agent, running on the identified platform, to act on their behalf. A validated PAY token further asserts that a trusted issuer has authorized the agent to execute a payment within specified parameters. Crucially, identification is distinct from admission. Recipients consume KYAPay tokens as authenticated context for site-configured policy engines, not as an automatic grant of access. A design goal of this specification is that recipients can reliably distinguish attributable, human-authorized agentic traffic from unattributed automation, so that site operators can apply appropriate policy -- admit, rate-limit, require step-up, or deny -- based on verified identity rather than default blocking.

Scope This document describes how consumers of KYAPay tokens -- in particular the security intermediaries that guard websites, APIs, and accounts -- convey, validate, and act on KYAPay tokens. It does not redefine the token; the claims, their meanings, and the base validation rules are specified in the KYAPay Token and are referenced normatively here. This document is deliberately normative about consumption and non-prescriptive about creation. places requirements on how intermediaries validate and use tokens. discusses token creation as a software-architecture problem and intentionally does not mandate a mechanism; the rationale is given in .

Relationship to Other Documents This document builds directly on the KYAPay Token , which defines the KYA, PAY, and KYA-PAY token types, the claim schema (including the layered identity claims hid, apd, and aid), and the core token validation procedure. The specification defines the token and the roles of issuer, initiator, and target, but it does not define the role of the party that receives and validates a token in order to make a security decision. This document defines that role -- the recipient (or relying party) -- and specifies its behavior. Three related specifications define JWT claims and values that a recipient can use to reason about how a principal was authenticated and verified, and that MAY appear in KYAPay tokens: the Additional Authentication Method Reference Values specification , which defines additional amr claim values, the Identity Verification Methods Values specification , which defines the ivm claim and values, and the Anti-Money Laundering Methods Values specification , which defines the aml claim and values.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This specification uses the Initiator/Target and agent identity terms Initiator Agent, Initiator Principal, Agent Platform, and the identity grouping claims hid, apd, and aid defined by . This document defines the following terms:

Human-via-agent request:

An HTTP request or protocol message issued by an agent that carries a valid KYAPay token attesting that the agent is acting on behalf of an identified, authorizing human principal (an individual or an organization).

Bot:

Unattended automation that is not acting on behalf of, or with the authorization of, an identified human principal, and that does not present a valid KYAPay token. This document does not attempt to further classify bots; existing "good bot" / "bad bot" mechanisms are orthogonal and continue to apply.

Recipient (Relying Party):

The entity that receives a KYAPay token, validates it, and acts on the result. A recipient may be a security intermediary (below), a Target's own resource server, or an edge/CDN provider acting on a Target's behalf.

Security intermediary:

A recipient, typically operated by a security vendor or by the Target, that inspects requests and makes an admission, routing, scoring, or lifecycle decision before or as the request reaches the Target's application. This document addresses four common (and often overlapping) kinds of security intermediary:

Bot manager:

An inline application-layer system that detects automated traffic -- using behavioral telemetry, fingerprinting, and network-derived signals -- to decide whether to admit, challenge, throttle, or block a request.

Fraud manager:

An application-layer system that scores the risk of a transaction or action, typically using identity, reputation, behavioral, and device signals.

Account-takeover (ATO) protector:

A system that detects and prevents unauthorized access to existing accounts, for example by distinguishing legitimate sessions from hijacked or automated ones.

CIAM (customer identity and access management) system:

A system that manages account creation, authentication, and login for a Target's customers.

Human presence signal:

The aggregate assurance, derived from a validated KYAPay token, that a request is authorized by an identified human principal. See .

Assurance level:

A per-entity indication of how strongly an identity in the token was verified (for example, the identity-proofing level of the human principal). See .

Design Principles This section is informative. It records the assumptions that motivate the normative requirements in later sections.

Human Identity is Paramount An underlying hypothesis of KYAPay is that commerce -- with or without payment -- is conducted between humans and human organizations, not between machines. An agent is a tool through which a human or organization acts. Consequently, the identity that matters most is the human identity behind the request, and liability for a request must ultimately be assignable to a human party: the principal, the developer of the agent, the operator of the agent platform, or some other identified party. KYAPay tokens are structured to convey these identities so that this auditable, cryptographically verifiable chain of responsibility -- from agent action back to an accountable human -- can be established.

Ubiquity of Access on the Existing Web Agents are useful in proportion to the breadth of the web they can act across. If a human must pre-configure access for an agent at each site before the agent can act, the result is indistinguishable from the workflow automation that already exists, and the principal loses the probabilistic discovery -- of new merchants, products, services, and alternatives -- that is one of the main reasons to use an agent at all. The goal is therefore agentic access to the existing web, not a parallel, agent-only surface that must be set up in advance. This goal can only be met if security intermediaries admit legitimate human-via-agent requests by default when a valid token is present.

Works with Today's Web at Zero Merchant Tech Lift Websites exist today, in the millions, and merchants and services already know how to sell through them, manage fraud, make offers, build brand loyalty, and test changes. A key property of a website (and, similarly, of a merchant-controlled MCP server) is that the merchant controls its own interface and is not locked into an API schema that must be carefully versioned; agents driven by large language models (LLMs) can frequently learn to use these interfaces automatically. A protocol for delivering agent identity and payment credentials should therefore work with today's web without requiring merchants to build new APIs. KYAPay meets this by conveying credentials in the HTTP request itself (), which requires no change to how a merchant's site is built.

One Source of Truth Across All Layers of Defense Bot managers, fraud managers, ATO protectors, and CIAM systems all operate at the application layer. Today, each makes its decision in isolation, and their verdicts on the same request can contradict one another. A single validated KYAPay token gives every layer the same verified identity and, where present, payment context, so that their decisions are more likely to be consistent than conflicting.

Runtime Business Decisions A further goal is to give the Target the information it needs to make a business decision at request time: do I want to do business with this human, arriving via this agent, on this platform, for this action? Because the token carries verified, layered identity and (optionally) payment context, the Target and its intermediaries can decide at runtime whether to admit, price, personalize, step up, or decline. As one illustration, a merchant that recognizes a KYAPay-bearing request MAY adapt its existing pages for agent consumption using the same techniques it already uses to restyle pages, retaining ownership of its interface and its existing fraud and good/bad-actor signals rather than exposing a separate API surface.

The Trust Stack: Bearer Tokens Today, Proof of Possession Ahead This section is informative. It situates KYAPay tokens among the other mechanisms a recipient encounters and, importantly, distinguishes what is deployed today from the planned evolution, so that the consumption requirements in are read against the correct baseline.

KYA is an Issuer-Signed Bearer Token Today As currently deployed, a KYA (or KYA-PAY) token is an issuer-signed, short-lived bearer token. Its single most valuable operational property is that a Target has to do almost nothing to consume it: verify a JWT against the issuer's public key via JWKS, exactly as it would verify any OpenID Connect or OAuth token. Any Target with a standard JWT library can participate, including those behind CDNs, API gateways, and serverless platforms. Preserving that low bar is a primary design goal (); mechanisms that would raise it are weighed against the adoption they would cost. A bearer token establishes identity but not proof of possession: possession of the token is all that is needed to present it, so a token captured within its validity window can be replayed. Today this residual, in-window risk is bounded rather than eliminated, by means that do not raise the consumption bar:

• short token lifetimes (exp), so a captured token expires quickly;
• audience binding (aud, and where used tdm/tsi), so a token minted for one Target cannot be presented to another;
• TLS on every hop, which mitigates on-the-wire capture and man-in-the-middle; and
• issuer-gated onboarding (KYC/KYB), which mitigates malicious agents and Targets being admitted to the network in the first place.

The accepted residual threats, and the irreducible ones, are stated in .

Identity and Proof of Possession are Different Layers It is useful to separate two questions a recipient may want answered:

• Who is behind this request? This is answered by the KYA token: a trusted, neutral issuer that performs KYC/KYB attests to the identity of the human principal (hid), agent platform (apd), and agent (aid), acting as a client-side trust anchor analogous to a Certificate Authority. KYA is a set of verifiable nouns -- identity, verification status, authorization, payment -- and, being a JWT, it is transport-agnostic: the same token rides HTTP, WebSockets, gRPC metadata, a message queue, or a stdio MCP channel, and can be logged and independently re-verified at rest.
• Did the sender actually hold the credential's key? This is proof of possession, which a bearer token does not provide. Establishing it requires the agent to sign the request itself; over HTTP, HTTP Message Signatures are a mechanism for this. A signature proves control of a key but says nothing about whose key it is -- it is a verb, not an identity format.

Because these are different layers, HTTP Message Signatures and similar request-signing mechanisms are complementary to KYA, not alternatives to it; request signing supplies authenticity and possession, while KYA supplies identity, authorization, and payment. A complete proof-of-possession design uses both, bound together, as described next.

The Proof-of-Possession Path (Planned Evolution) When per-request signing becomes practical at scale, the planned evolution of KYA is a Certificate-Authority-like model that adds proof of possession without changing the trust anchor:

1. the issuer onboards the agent as a CA would;
2. the agent generates a key pair and provides its public key to the issuer;
3. the issuer binds that public key into the KYA token using the JWT confirmation claim cnf . The token MUST carry cnf.jwk -- the key itself. A key identifier would satisfy only on its own terms, which hold "provided the recipient is able to obtain the identified key": a recipient meeting the agent for the first time holds no such key, and a thumbprint is a one-way hash from which none can be recovered. The issuer cannot determine when that proviso is met -- it knows neither which recipients a token will reach, nor the initiator's intent, nor the state of any interaction between initiator and target. Nor can it rely on continuity between tokens: where a target de-duplicates on jti to prevent replay, each token is fresh and must stand on its own. Carrying the key is therefore the only form that works in the general case. Other confirmation members MAY additionally be present; a recipient MUST NOT be required to obtain the key by any means other than reading cnf.jwk; and
4. the agent signs each request in place -- a signature over the request (method, path, body digest, timestamp/nonce) using -- verified against the key in cnf, with no separate proof-of-possession token.

This yields an unbroken chain from request to key to identity: the request is signed by a key, and that key is vouched for as the initiator's by the issuer. Preferring a request signed against the cnf key over a detached, DPoP-style proof keeps a single token -- the recipient validates the KYA token once (per session), caches the cnf key, then performs only a fast per-request signature check, instead of validating two artifacts and confirming they are bound to each other. When present, this binding is consumed as specified in and closes the in-window replay and malicious-Target-reuse risks of the bearer model (). Adoption remains the constraint on when this becomes mandatory. Per-request signing is costly: hardware-protected keys are secure but slow, software keys are fast but exfiltratable, and post-quantum algorithms do not make signing faster. Defeating replay of the proof itself further requires either per-Target nonce caches or binding the signature to the request content, and other request-bound designs considered (mutual TLS , TLS channel binding, session-based schemes) each raise the participation bar or add Target-side state. Until fast, secure signing and a workable anti-replay approach exist that keep the Target's job about as simple as verifying a JWT, KYA remains a bearer token by default and proof of possession is an optional, forward-compatible upgrade rather than a precondition for participation.

Conveying KYAPay Tokens in Requests

The KYAPay-Token HTTP Header Field When KYAPay tokens are used with websites and HTTP APIs, a human-via-agent request carries its token(s) in an HTTP header field, in the same spirit that a human's browser conveys identity and payment details in the request itself. For a directly interacting human, such details are typically carried in the request body (for example, form fields at checkout); for a human-via-agent request, they are carried in the KYAPay-Token header field defined here. The KYAPay-Token header field is an HTTP request header field whose value is a KYA, PAY, or KYA-PAY token, as defined in . HTTP field names are case-insensitive . A request MAY convey more than one token (for example, separate KYA and PAY tokens) either as a comma-separated list in a single KYAPay-Token header field or as multiple KYAPay-Token header fields; per , multiple field lines with the same name are equivalent to a single comma-separated field line. Because a JWT uses only the base64url alphabet plus the period (".") separator, it never contains a comma, so list parsing is unambiguous. A sender:

• MUST place exactly one JWT in each list member;
• SHOULD NOT send more than one token of the same typ () in a single request; and
• MUST NOT rely on the ordering of tokens within the field to convey meaning.

A recipient:

• MUST determine the type of each token from its typ header parameter (), not from its position; and
• MUST ignore a KYAPay-Token member it cannot parse as a JWT, while continuing to process the remaining members, unless local policy requires rejecting the whole request.

Intermediaries and caches MUST treat KYAPay-Token as containing sensitive, request-specific credentials; it MUST NOT be cached in a way that would allow it to be replayed on a different request, and it MUST NOT be logged or forwarded to parties other than legitimate participants (see ). The KYAPay-Token header field is intended for use over TLS. A token MUST NOT be sent over a non-TLS-protected connection. When the token carries a proof-of-possession key (), it SHOULD be accompanied by a request Message Signature over that key; otherwise it is a bearer token, subject to the controls and accepted risks in .

Conveying Tokens over Other Interfaces Beyond HTTP requests to websites and APIs, agents interact through a growing set of interfaces and protocols, including agent-to-tool interactions such as MCP , agent-to-agent interactions such as A2A , agent-to-API interactions (for example, OpenAPI descriptions converted into locally callable tools), and emerging protocols such as Universal Commerce Protocol and Verifiable Intent . KYAPay is designed so that the same self-contained token can be conveyed across any of these interfaces -- as an HTTP header field, a message field, or a tool argument -- to deliver verified identity and payment credentials to the receiving service, API, or agent. Because a KYA token is a self-contained JWT, it is transport-agnostic in a way that a request-signing mechanism is not: HTTP Message Signatures are meaningful only for HTTP exchanges, whereas the same token can ride HTTP, WebSockets, gRPC metadata, message queues, or a stdio MCP channel, and can also sit at rest in a store or audit log for later verification. This document specifies only the HTTP header binding in ; bindings for other protocols are expected to be defined by those protocols or by companion specifications. In all cases, the validation and usage rules of apply to the token, once received.

Authenticating the Counterparty Conveying a token securely also requires that the sending agent deliver it to the intended recipient and that the recipient be able to bind the token to itself. The aud claim, together with the optional tdm (target domain) and tsi (target service identifier) claims defined in , allows a recipient to confirm that a token was minted for it and to mitigate replay to a different party (). At the transport and discovery layers, mechanisms such as DNS domain names (with TLS server authentication), A2A agent cards , and MCP server identification help an agent confirm that it is communicating with the correct counterparty before presenting a token.

Using KYAPay Tokens at Security Intermediaries This section is normative. It defines a common processing model and then describes how each kind of security intermediary uses the validated token. Throughout, "validate the token" means to perform the validation procedure defined in , Section 4 (JWT header validation, signature and issuer validation, and validation of exp, iat, jti, aud, and env), plus the PAY-specific validation for pay+jwt and kya-pay+jwt tokens.

Common Processing Model On receiving a request that carries one or more KYAPay tokens, a security intermediary:

1. MUST extract each token as described in .
2. MUST confirm that the token's issuer is one the recipient trusts for the claims being relied upon (see ). This check MUST precede any processing that resolves a value taken from the token, and in particular any network retrieval driven by the iss claim. Until the token has been verified, iss is supplied by the sender: resolving it before the issuer is known to be trusted would allow an unauthenticated request to cause an outbound fetch to an arbitrary URL of the sender's choosing. The trusted-issuer set is configured out of band and is not derived from the token.
3. MUST validate each token as specified in , Section 4. A token that fails validation MUST NOT be treated as conveying a human presence signal, and the intermediary MUST fall back to its default (token-absent) policy for that request.
4. MUST verify the token signature against a key obtained from the issuer's JWK Set, discovered via the iss claim using the /.well-known/jwks.json mechanism (). Because KYAPay tokens are self-contained, this verification SHOULD be performed locally, without a synchronous callout to the issuer per request; issuer keys SHOULD be cached and refreshed according to standard JWK Set practice.
5. MUST confirm that the token is intended for this recipient by checking the aud claim (and, if used, the tdm and tsi claims) as described in .
6. MUST confirm that the env claim (for example, production) matches the environment the intermediary is operating in. When the token carries a proof-of-possession key (the cnf claim , Section 4), MUST verify that the request is signed by that key -- over HTTP, using HTTP Message Signatures -- and reject the request if the signature is absent or invalid.
7. When the token carries no such key, it is a bearer token: the intermediary MUST rely on the controls in (short lifetime, audience binding, TLS, issuer-gated onboarding) and MUST NOT assume that mere presentation of the token proves the sender holds a key bound to it.
8. SHOULD use the token's claims to inform its decision, as described in the following subsections, only after successful validation.

A security intermediary MUST NOT treat the mere presence of a KYAPay-Token header field as a human presence signal; only a successfully validated token from a trusted issuer conveys that signal.

Determining Human Presence and Assurance The core purpose of consuming a KYAPay token is to distinguish a human-via-agent request from a bot, and to gauge how strongly to trust it. After validation, a recipient SHOULD derive the human presence signal from the layered identity in the token, treating each layer as a distinct entity verified by distinct means:

• the human principal (hid): the presence and content of the human identity claim, and how strongly it was verified -- for example a verified status and verifier (), and, where a deployment conveys it, an identity-proofing assurance level (such as an Identity Assurance Level per ) and the amr , ivm , and aml claims describing how the principal was authenticated and verified;
• the agent platform (apd): the identity of the operator that built and runs the agent, and whether it was verified (for example, a business/Know-Your-Business attestation), which supports reputation-based logic about the platform; and
• the agent instance (aid): the specific agent, including a meaningful name and, where present, references to its OAuth identity () and a proof-of-possession key bound to the token via cnf (or a request-signing key published in an A2A Agent Card ).

Because these are different entities verified to different degrees, a recipient SHOULD NOT collapse them into a single yes/no signal. Instead, it SHOULD apply per-entity, per-action policy. For example, a recipient might require a higher human-principal assurance level and a "registered" agent for a payment than for browsing: = document+biometric require apd verified as a business require aid bound to a verified domain /payment: require hid assurance >= document+biometric require hid authenticated with a hardware key require aid registered by its platform ]]> The strength of the human presence signal is a function of which identities are present, how strongly each was verified, and how much the recipient trusts the attesting issuer and verifier. A recipient MAY combine the token signal with its existing signals rather than replacing them, and MAY accept a lower assurance for low-risk actions while requiring step-up () for higher-risk ones.

Bot Managers A bot manager sits inline in the request path to make per-request admission decisions with minimal added latency. Traditionally, it relies on a detection pipeline -- client-side behavioral telemetry, browser fingerprinting, request timing, and network-signal analysis -- to infer whether a request is automated and who operates it. KYAPay tokens transform this detection model into a self-identification model. By presenting a valid KYA token, an agent explicitly identifies itself as automated up front. The bot manager verifies the token -- checking the cryptographic signature against the issuer's published keys, issuer trust, validity window, and audience -- and classifies the request as a verified agent. For token-bearing traffic, the identification question is settled: the bot manager does not need to execute its behavioral or fingerprinting detection heuristics to prove the request is automated. Untokened or unverifiable requests fall back to the standard detection pipeline. Settling identification, however, does not grant automatic access. Identification is distinct from admission: classifying a request as a verified agent simply provides authenticated context. The bot manager uses the token's verified identity layer -- the human principal (hid), the agent platform (apd), and the agent instance (aid) -- to select and evaluate the site's configured access policy to determine the final disposition (admit, rate-limit, require step-up, or deny) rather than applying bot-blocking challenges designed for unattended, unattributed automation. KYAPay tokens are well-suited to inline bot management for several reasons:

• Low Latency. Because the token is a self-contained, signed JWT, the bot manager performs standard JWT verification locally and needs no per-request callout to a third party. Issuer keys SHOULD be cached.
• Policy Selection via Identity Context. A validated token provides verified initiator identity (and, when targeting an agent, target identity), which the bot manager uses to select and evaluate the appropriate site policy rather than treating the traffic as suspected automation. By contrast, network-origin claims (such as declared source IP ranges) are unreliable as proof of origin -- addresses change and can be masked by VPNs, CGNAT, or shared pools -- so a recipient MAY use them as a weak corroborating signal only, but MUST NOT treat an IP match alone as sufficient to bypass controls nor an IP mismatch as conclusive. Short lifetimes, audience binding, and proof-of-possession (), not IP correlation, are the recommended controls against token misuse.
• Replay Resistance. A bearer token captured within its validity window can be replayed; a bot manager bounds this with short lifetimes, audience binding, and TLS (). Where a token carries a proof-of-possession key (), the bot manager (or the edge/CDN provider acting for the Target) SHOULD additionally verify the per-request signature against that key, which removes in-window replay exposure.

Fraud Managers A fraud manager operates at the application layer and scores the risk of an action or transaction. It benefits from the token's layered identity and verification metadata:

• It SHOULD incorporate the per-entity verified identity (hid, apd, aid) and assurance levels into its risk model, distinguishing a request backed by a strongly verified human principal on a reputable platform from a weakly verified or anonymous one.
• It SHOULD use the verifier/verified/verification_id sub-claims, and the amr ivm , and aml claims where present, to weight how the principal was authenticated and verified.
• For pay+jwt and kya-pay+jwt tokens, it SHOULD use the payment context (amt, cur, stp, sti, and the pricing claims tpr and tps) as additional transaction risk signals, after performing the PAY-token validation of , Section 4. Because the PAY token pins amount, currency, and target, the fraud manager MAY rely on those as hard limits enforced by the token rather than re-deriving them.

A fraud manager need not sit inline in the request path. In practice the token is made available to it either inline (the Target forwards the received token to its fraud manager) or out of band (for example, script running on the Target's page captures the KYAPay-Token value and sends it to the fraud manager before the request reaches the Target's application). The same token MAY be inspected before the action, after it, or both. In all of these arrangements, the token issuer is not in the transaction path; the fraud manager verifies the self-contained token locally by JWKS, as described in . The fraud manager MAY continue to apply its existing behavioral and device models; the token supplements, and does not replace, those signals.

Step-Up Authentication Not all actions carry the same risk; viewing a loyalty balance is far less sensitive than making a large payment. A KYAPay token attests the assurance established at the time of issuance, which may be insufficient for a high-value action. A recipient SHOULD be able to require a higher assurance level for sensitive actions and to signal that requirement so that a fresh token can be obtained after additional verification of the human principal (for example, a step-up authentication such as a push-notification approval, a one-time code, or a re-run of identity verification). This document does not define a wire mechanism for a Target to request step-up out of band from an issuer; that is an open item (see ). Until such a mechanism is standardized, recipients SHOULD express assurance requirements as local policy over the assurance signals in and decline actions whose required assurance is not met.

Account-Takeover Protectors An ATO protector distinguishes legitimate account sessions from hijacked or unauthorized ones. KYAPay tokens let it separate three cases that previously looked alike: a direct human-present session, a human-initiated agentic session, and an unauthorized automated session.

• It SHOULD treat a validated KYAPay token, bound to its request per , as evidence that a session is a human-initiated agentic session rather than an unattended attack, and SHOULD record that distinction for auditing.
• When the agent needs to act within an existing account, the token MAY be exchanged for an OAuth access token using KYAPay Token Exchange or OAuth 2.0 Token Exchange . A Security Token Service, Identity Provider, or OAuth 2.0 Authorization Server validates the KYA token, extracts principal claims such as the email address from hid, and issues an access token that the agent uses against the Target.
• The access token resulting from such an exchange SHOULD be sender-constrained (for example, via DPoP or mutual TLS ) rather than issued as a freely transferable bearer token, so that exchanging the KYA token does not simply reintroduce a replayable credential.
• Cross-domain trust must be established: the Target's authorization server can fetch the issuer's keys via the iss JWKS endpoint, but it must also decide whether to trust that issuer and how to interpret its claims (see ).
• A valid token attests authorization at the moment of issuance, not continuous human control. An ATO protector SHOULD NOT assume that the human remains in control for the token's whole lifetime, SHOULD prefer short token lifetimes, and SHOULD apply step-up () for sensitive actions.

CIAM Systems A CIAM system manages account creation and login for a Target's customers. With KYAPay tokens it can manage agents consistently with humans:

• It MAY create an account for an agent (or for the human principal behind an agent) directly from a validated KYA or KYA-PAY token, drawing account attributes such as the email address from the hid claim.
• It SHOULD use KYAPay Token Exchange or OAuth 2.0 Token Exchange to exchange a KYA token for an access token, enabling logged-in experiences (loyalty, saved preferences, offers) for human-via-agent sessions, applying the sender-constraining and cross-domain-trust considerations of .
• It SHOULD maintain the linkage between a human principal and the agents authorized to act for them, so that a principal can be given visibility into, and control over, agent activity and vice versa.

Consistency Across Layers Because all of the intermediaries above validate the same token and draw on the same verified claims, an operator SHOULD configure them to reach consistent verdicts on a given request: a request admitted as a verified human-via-agent request by the bot manager should not be scored as an anonymous bot by the fraud manager.

Granular Bad-Actor Mitigation and Triage The layered identity in a KYA token (hid for the principal, apd for the platform, aid for the agent instance) lets intermediaries choose the scope of a mitigation deliberately, rather than being forced into a single broad, "nuclear" block. Because every request carries all three identities, a recipient can select the narrowest scope that is effective and escalate only as warranted:

• the individual human principal (hid) -- e.g., block or throttle one abusive user while all other users of the same agent continue to be served;
• the specific agent instance (aid) -- e.g., isolate one compromised or malfunctioning agent without affecting the principal's other agents or the rest of the platform; or
• the entire agent platform (apd) -- e.g., when an operator is systematically abusive, unresponsive, or untrusted, block or de-rate all traffic from that platform.

The same granularity supports responses short of blocking the requests, such as throttling, requiring step-up (), or lowering an assurance score, applied at whichever tier is appropriate. Choosing the tightest effective scope isolates threats while protecting the reputation of well-behaved platforms and avoiding collateral damage to legitimate human-via-agent requests; reserving platform-wide action for cases that genuinely warrant it keeps that option available without making it the default.

Feedback to the Token Issuer The mitigation described above is local: a recipient acts on its own traffic. Because the token issuer is the party that vouches for the initiator and can decline to vouch again, there is value in a feedback loop that lets a security intermediary report observed bad behavior back to the issuer, so that action can be taken at the source rather than only at each recipient independently. When a security intermediary observes abusive or anomalous behavior that it can attribute, using the layered identity in the token, to a particular entity, it MAY report that observation to the token's issuer (identified by iss). The attribution follows the same tiers as :

• the individual human principal (hid);
• the specific agent instance (aid); or
• the agent platform as a whole (apd).

On receiving such feedback, and subject to its own verification and anti-abuse safeguards, the issuer MAY take appropriate action, up to and including ceasing to issue tokens to the implicated initiator, agent, or platform -- the issuance-side counterpart to a recipient's refusal to accept a token, and complementary to the token-lifetime and revocation considerations of . This mirrors the Certificate-Authority analogy of : just as a CA can stop issuing (and can revoke) certificates for a misbehaving subscriber, a KYAPay issuer can stop vouching for a misbehaving initiator. This document does not define the mechanism, format, or trust model for this feedback channel; how a recipient authenticates to an issuer, how reports are structured, how issuers guard against false or malicious reports, and what evidence is required are all open items. Feedback SHOULD be treated as sensitive: reports identify principals, agents, or platforms and MUST be shared only with the relevant issuer and handled per . An issuer SHOULD corroborate feedback (for example, requiring reputation, multiple independent reports, or evidence) before taking action that would affect a principal, so that the channel cannot itself be used to deny service to legitimate initiators.

Non-Payment and Handoff Flows Not every human-via-agent flow includes a payment made by the agent. In a common pattern, the agent performs discovery and assembles a cart but does not pay; it then hands off to the human, who completes checkout in a browser, in a later session, or even in a physical store. In such flows, the KYA token (carried without a PAY token) still provides the human presence signal that lets a security intermediary admit the agent's discovery and cart-building activity. Intermediaries SHOULD accept KYA-only requests (those conveying a KYA token but no PAY token) for actions that do not themselves settle a payment, and MUST NOT treat the absence of a PAY token as a reason to classify an otherwise valid human-via-agent request as a bot. Because the human identity claim hid (for example, an email address) is stable across these touchpoints, a Target or fraud manager MAY link the agent's earlier work to the human's eventual purchase -- for attribution, personalization, and fraud analysis -- even when the purchase completes outside the agent session or on a different channel.

Token Creation Considerations This section is non-normative with respect to how tokens are created. It records considerations that KYAPay Token Issuers and agent developers should weigh, but it deliberately does not mandate a mechanism. The normative interoperability contract is the token defined by and consumed as specified in ; how a given agent obtains a valid token is an implementation and architecture choice.

Why this Document is Not Prescriptive about Creation Readers accustomed to fixed API contracts may expect a specification to prescribe exactly how a credential is minted. For agents, such prescription is neither possible nor desirable at this time, for several reasons:

• Agent architectures are diverse. Agents are built in fundamentally different ways -- computer-use agents that drive a desktop, browser-use agents that drive a browser, and programmatic agents that call APIs or tools -- and there is no single formula for building one. An agent may be an individual's personal, ad hoc creation, or a highly governed and deterministic enterprise agent for a regulated workflow, or anything in between.
• Credentials may need to be shielded from the LLM. In many designs, it is desirable that the LLM driving an agent never sees raw credentials. Token creation may therefore be placed inside deterministic tools that the LLM can invoke but whose outputs (the tokens, or the secrets used to mint them) it cannot read. Whether this matters depends on the deployment; a specification that mandated a single creation flow could not accommodate both shielded and unshielded designs.
• Agent-identity and communication protocols are still emerging. Multiple protocols for agent identity and for agent communication -- agent-to-tool (MCP ), agent-to-agent (A2A ), request signing (), OAuth client identity (), agent-to-API, Verifiable Intent , UCP , and others -- are under active development and require significant investment to reach production. Standardizing a single creation mechanism now would bind KYAPay to choices that are not yet settled.
• The web already exists. In contrast to those emerging interfaces, websites and merchant-controlled endpoints exist today at scale and require no new integration effort from merchants (). A usable protocol must therefore work now, over the existing web, which argues for standardizing the delivered token rather than the creation path.

KYAPay's position is that the token is the fixed point, and creation is allowed to vary. This is what lets a single token type serve individual and enterprise agents, shielded and unshielded designs, and today's web alongside tomorrow's agent protocols.

Guidance for KYAPay Token Issuers Given the above, KYAPay Token Issuers are encouraged to make token creation possible and easy regardless of the technology an agent uses:

• Match the issuing interface to the agent. A programmatic agent using a deterministic tool may be well served by a single REST endpoint with optional arguments -- one call that can mint a KYA, PAY, or KYA-PAY token with any supported settlement type (payment cards, stablecoins, and so on). An agent driven through MCP may instead be better served by several narrow, specific tools (one per token type and per settlement type), so as to reduce the decision burden placed on the LLM.
• Support multiple identity technologies. Because there is no single agent-identity standard today, issuers should be prepared to accept and bind a variety of identity inputs when minting tokens, including (for example) CIMD , WIMSE / SPIFFE , Agent Name Service (ANS), request-signing keys published in A2A Agent Cards , and public/private key pairs.
• Be available across agent technologies and protocols. Issuers should be reachable by agents irrespective of the agent's runtime technology, the identity protocol it uses, and the communication protocol it speaks.

Origination and issuance need not be performed by the same party. The iss claim identifies the party that signs (issues) the token, while the optional ori claim () identifies the party that originated -- that is, assembled and requested -- it; these can be the same entity or different entities. Likewise, the verified identity information carried in hid and apd may be supplied by the agent platform or a third-party verifier and merely attested by the issuer. Verification itself need not be completed up front: it can be progressive, beginning with a lightweight check (such as email verification) and stepping up as a Target's requirements demand. Consumers observe the result of these choices through the verifier/verified sub-claims and, where used, the ivm , amr , and aml claims, rather than through any mandated creation flow. The objective of all of the above is a single outcome: a valid KYAPay JWT that is consumable by every transacting party -- the Initiator, the Target, and the bot managers, fraud managers, ATO protectors, and CIAM systems in between.

Security Considerations When validating the JWTs described here and in , implementers MUST follow the JSON Web Token Best Current Practices , in addition to the validation steps of , Section 4.

Transport Confidentiality KYAPay tokens convey identity and, for PAY tokens, payment credentials. They MUST be transmitted over TLS and MUST NOT be sent in the clear.

Token Freshness and Lifetime A long-lived token is a credential that can be captured, farmed, and resold for reuse against the same Target. The exp claim MUST be present; recipients SHOULD require short lifetimes (for high-assurance actions, on the order of a few minutes) and MUST reject tokens whose lifetime exceeds their local policy maximum. Recipients SHOULD reject tokens whose iat is outside an acceptable window.

Replay and Proof of Possession A bare bearer token can be replayed by anyone who captures it within its validity window. As deployed today (), KYAPay accepts this bounded in-window risk and mitigates rather than eliminates it: recipients MUST validate the aud claim (and tdm/tsi where used) so that a token minted for one Target cannot be presented to another, MUST keep accepted lifetimes short, and SHOULD use the jti claim to detect replay to the same recipient. Where a token carries a proof-of-possession key (cnf ), recipients MUST additionally verify a per-request signature over that key (), which removes the in-window replay exposure. Access tokens produced by token exchange () SHOULD be sender-constrained (, ).

Malicious or Compromised Target Reuse A Target that legitimately receives a bearer token can, within the token's window, reuse it to act elsewhere on the agent's behalf. Audience binding limits this to the intended Target; the proof-of-possession model (), which binds each use to a fresh request signature, closes it. Recipients and Targets MUST NOT forward received tokens to other parties (see ).

Compromised Agent Host (Irreducible) Malware resident on the agent's host can drive the agent's legitimate key as a signing oracle for as long as it is present. Proof of possession does not prevent this: the malware's requests convey valid bindings and are indistinguishable from the real agent's. This risk is bounded not by the token bindings but by short token lifetimes -- so anything signed during a compromise expires quickly once the malware is evicted -- together with host-level controls such as attestation, anomaly detection, and hygiene.

Issuer Trust A token is only as trustworthy as its issuer and the verifiers it cites. The system is federated: many issuers are possible, and a recipient MUST maintain an explicit set of trusted issuers and the claims and assurance levels it will accept from each. Establishing this trust at scale is an open problem analogous to the Certificate Authority model (audits, a maintained issuer list, a removal mechanism, and possibly transparency logs); this document does not define such a framework, and deployments should not assume one exists. Until it does, trust is established out of band (for example, configured relationships with well-known issuers).

Revocation An agent whose platform is deregistered, or a human whose identity verification is revoked, may still hold unexpired tokens. This specification does not define a revocation mechanism. Recipients SHOULD keep accepted lifetimes short to bound exposure, and SHOULD consult an issuer's live-status or revocation endpoint, where one is offered, for high-assurance or high-value actions.

Continuity of Human Control A valid token attests that the human principal authorized the agent at the time of issuance. It does not prove the human remains in control -- for example, if the agent is later prompt-injected, or if credentials are exfiltrated from the agent or its host. Recipients SHOULD treat high-value actions as warranting step-up () rather than relying solely on a previously issued token.

Key Management If an issuer or platform rotates a signing key, tokens signed with the old key may fail validation prematurely. Issuers SHOULD retain superseded verification keys in their JWK Set for at least the maximum token lifetime after rotation.

Privacy Considerations The privacy considerations of apply. In particular:

Minimal Disclosure Only the information needed to facilitate the intended interaction should be placed in a token and conveyed to intermediaries and Targets. Issuers and senders SHOULD prefer the least revealing set of claims sufficient for the decision at hand -- for example, an assurance level or a boolean verified status rather than underlying identity documents or personally identifying verification data. Because KYA tokens are JWTs, selective disclosure (for example, SD-JWT ) is a forward-compatible path to revealing only the claims a given Target needs.

Consent Tokens assert that an agent acts on behalf of a principal. That assertion is only legitimate when the principal has authorized the interaction. Systems SHOULD be designed so that tokens are minted only with the principal's authorization.

Handling by Intermediaries Security intermediaries receive verified personal data in the course of making decisions. They MUST treat KYAPay-Token values and their decoded contents as sensitive personal data: not caching them for replay, not logging them in the clear, and not sharing them with parties other than legitimate participants in the interaction.

IANA Considerations

HTTP Field Name Registration IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry established by :

• Field Name: KYAPay-Token
• Status: permanent
• Structured Type: List
• Reference: of this document
• Comments: Carries one or more KYAPay tokens in an HTTP request

JWT and Media Type Registrations This document defines no new JWT claims, JWT confirmation methods, or media types. The claims and media types used by KYAPay tokens are registered by . The amr extensions and the ivm and aml claims and values are registered by , , and , respectively.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. Skyfire Systems Inc. Self-Issued Consulting This document defines a token format for agent identity and payment tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this token format to consume identity and payment tokens in an interoperable manner. Skyfire Systems Inc. Self-Issued Consulting Okta Ory This specification describes how KYAPay tokens can be exchanged for OAuth access tokens to dynamically grant agents access to resources they need to accomplish their mission. Informative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Skyfire Systems Inc. Self-Issued Consulting Experian Akamai The JWT "amr" (Authentication Methods References) claim contains values conveying authentication methods used in the authentication. This specification defines additional Authentication Method Reference values beyond those already registered to represent additional authentication methods in use today. Skyfire Systems Inc. Self-Issued Consulting Experian Akamai Knowing how a person's identity was verified can be important when making trust decisions. This specification defines a claim and values for declaring how the person's identity was verified. Skyfire Systems Inc. Self-Issued Consulting Experian Financial regulations require application of Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) methods in many jurisdictions worldwide. This specification defines a claim and values for declaring what AML/CFT methods were employed. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. National Institute of Standards and Technology Anthropic and the Model Context Protocol Contributors A2A Project UCP Contributors Verifiable Intent Contributors SPIFFE Project / Cloud Native Computing Foundation Skyfire Systems Inc.

Acknowledgments The authors thank the contributors to the KYAPay Token specification and the partners in the KYAPay consortium (see ) -- including bot-management, fraud, CIAM, and ATO vendors and merchants -- whose deployment and review experience informed the usage patterns and open issues described here. We would like to thank Jean Diaconu for his contributions to the specification.

Document History [[ to be removed by the RFC Editor before publication as an RFC ]] -01

• Rewrote the Introduction to frame agents as an evolution of verified bot traffic.
• Clarified the meaning of Verifier and differentiated from Recipient.
• Added {:vspace} syntax to definition list entries.

-00

• Initial draft.