]> Skyfire Systems Inc.

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

Self-Issued Consulting

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

Security Web Authorization Protocol agent identity agentic payment commerce 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction As software agents evolve from pre-orchestrated workflow automations to truly autonomous or semi-autonomous assistants, they require the ability to identify themselves -- and more importantly, identify their human principals -- to external systems. Agents acting on behalf of users to discover services, create accounts, or execute actions currently face significant operational barriers. The KYAPay token addresses these challenges by providing a standard envelope to carry verified identity and payment information. By utilizing "kya" (Agent Identity) and "pay" (Payment) tokens, agents can identify their human principals to services, sites, bot managers, customer identity and access management (CIAM) systems, and fraud detectors. This enables agents to bypass common blocking mechanisms and access services that were previously restricted to manual human interaction. KYAPay does not aim to define agentic identity in its entirety. Rather, it specifies a standard and extensible JSON Web Token (JWT) that can be used to securely share human principal and agent identity information with websites and APIs. KYAPay tokens provide a strong signal of human presence behind agentic requests that are otherwise indistinguishable from programmatic and potentially malicious bot requests. Note that, in the future, the payment token functionality could be split into a separate specification, if desired by a working group adopting the specification. It is retained here at present for ease of reviewing.

Use Cases for the KYAPay Token Enabling agents to access websites and APIs on behalf of the human principals they represent is a design goal of KYAPay tokens. Today’s internet is designed primarily for humans, meaning that automated systems are often classified as malicious and blocked by web security infrastructure. However, the rise of AI agents has introduced a new paradigm where programmatic clients legitimately access websites and APIs on behalf of human principals. Because these agents can be hard to distinguish from traditional bots, they are often inadvertently blocked, creating a need for the web security ecosystem to distinguish between legitimate agentic traffic and potentially malicious activity. KYAPay tokens are designed to address this challenge by enabling agents to convey verified identity and payment credentials. These tokens can provide web security systems and merchants with a strong signal that the requests are authorized by a human, allowing them to safely permit legitimate programmatic transactions while aggressively blocking undesired traffic. Enabling agents to create accounts and/or log in to accounts on behalf of their human principals is a related design goal. To achieve this, systems can utilize a token exchange workflow . In this process, a Security Token Service (STS), Identity Provider (IdP), or OAuth Authorization Server verifies incoming KYA tokens and extracts claims associated with the human principal, such as hid.id, or an email address where it requested one. The authorization server then performs a token exchange, swapping the KYA token for a standard OAuth Access Token, which the agent subsequently uses to interact with the target service. Crucially, this architecture allows the service to know that the agent is acting on behalf of the user, making it possible to differentiate between direct, human-present sessions and human-initiated, agentic sessions for authorization, auditing, and security purposes. Enabling agents to have ubiquity of access across the Internet just like their human principals is a related design goal. Automation typically scales as it achieves higher reliability and lower cost-to-entry. Unlike the structured logic required by cron jobs or low-code / no-code platforms, agentic automation leverages LLMs to execute tasks via natural language, effectively removing the software-skill barrier. As model reasoning improves and infrastructure scales, these agents become increasingly dependable and affordable for the human principal. To maximize utility, agents require ubiquitous Internet access, a feat made possible by KYAPay Token Issuers. By providing a client-side verification framework analogous to the server-side role of Certificate Authorities (CAs), KYAPay builds a standardized network of acceptance across the web security ecosystem. This allows for the seamless attestation of both the agent’s and the human principal’s identity, ensuring secure, cross-domain task execution without the friction of fragmented authentication silos. Enabling the ecosystem of web security vendors to engage in finer-grained and deliberate bad-actor mitigation is a related design goal. KYA tokens provide a layered, verified, and extensible identity stack specifically engineered for autonomous agents. This framework allows the web security ecosystem to distinguish among individual agent instances, the platforms they run on, and the human principals behind them. By establishing this level of granular visibility, security systems can transition from broad defensive measures to specific mitigation; rather than being forced to block an entire platform, administrators can now isolate and neutralize a single malicious human user or a malfunctioning software instance without disrupting legitimate traffic. Note that the protocols using these tokens to achieve these goals are not defined by this specification. The interoperable use of them for these purposes will require further specification. Early production deployments of KYAPay tokens are described at https://kyapay.org.

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. The claims iss, iat, exp, aud, and jti are defined by . The header parameters alg, kid, and typ are defined by . The alg value ES256 is a digital signature algorithm defined in .

Roles

Agent:

An application, service, or specific software process, executing on behalf of a Principal.

Agent Identity:

A unique identifier and a set of claims describing an agent. Grouped into the aid claim for convenience. Because an agent can be public or confidential (as described in ), the level of assurance for these claims varies dramatically. Agents also vary in terms of longevity -- they can have stable long-running identities (such as those of a server-side confidential client), or they can be transient and ephemeral, and correspond to individual API calls or compute workloads.

Agent Platform:

The service provider and runtime environment hosting the Agent, such as a cloud compute provider or AI operator service. Assertions about the agent platform are grouped into the apd claim, and are primarily used to identify the Principal entity operating the platform, allowing consumers of the token to apply reputation-based logic or offer platform-specific services.

Principal:

A legal entity (human or organization) on whose behalf / in whose authority an agent or service is operating.

Initiator Roles

Initiator Agent:

An Agent performing tasks on behalf of an Initiator Principal, that has its own Agent Identity, grouped into the aid claim.

Initiator Agent Platform:

The Agent Platform hosting the Initiator Agent. Some use cases require the Platform to have its own verified identity assertions, grouped into the apd claim.

Initiator Principal:

A legal entity (human or organization) behind the purchase / consumption of a product or service. In buyer/seller transactions, the Initiator is the buyer. The Principal typically interacts with the target via an Initiator Agent. Many targets are required to be able to determine the Initiator Identity in order to comply with KYC/AML regulations, accounting standards, and to maintain a direct customer relationships. The initiator principal's identity is grouped into the hid claim.

Initiator Identity:

The aggregate verified identity assertions of the initiator entities, typically encompassing the Initiator Principal, the Initiator Agent Platform, and the Initiator Agent itself. This composite identity is conveyed via the KYA token, allowing the target to verify the entire chain of responsibility behind a request. The initiator identity utilizes the hid, apd, and aid claims.

Target Roles

Target Agent:

An Agent performing tasks on behalf of a Target Principal, directly interacting with Initiator Agents to facilitate discovery and purchase. Typically runs on Internet-connected infrastructure, and discoverable via service directories. Target agent identity claims are also grouped into the aid claim if KYA tokens are generated for the targets.

Target Agent Platform:

The Agent Platform that hosts Target Agents. Some use cases require the Platform to have its own verified identity assertions, grouped into the apd claim.

Target Principal:

A human principal (individual or organization) that owns the product, service, API, website, or content being consumed or sold, and serves as the ultimate beneficiary of a transaction. In buyer/seller transactions, the Target is the seller. The target principal's identity is grouped into the hid claim.

Target Identity:

The aggregate verified identity assertions of the target entities, typically encompassing the Target Principal, the Target Agent Platform, as well as the Target Agent Identity. These various aspects of Target Identity allow Initiators and Initiator Agents to perform reputation-based logic, to verify that they are interacting with the authorized (and expected) counter-party, and to fulfill KYC/AML regulation requirements. The target identity utilizes the hid, apd, and aid claims.

Ecosystem Infrastructure Roles

KYA Token Issuer:

A trusted neutral entity that conducts Know Your Customer (KYC) and Know Your Business (KYB) (for organizations) verifications. It is responsible for issuing cryptographically signed Know Your Agent (KYA) tokens that attest to the identity of the Principal, Agent, and Agent Platform, for both Initiators and Targets.

Payment Token Issuer:

A trusted entity responsible for facilitating the exchange of payments and credentials between the Initiator and Target. It issues signed pay tokens that enable settlement via various schemes (Cards, Banks, Cryptocurrency), without exposing raw credentials or secrets. Like a KYA Token Issuer, it conducts Know Your Customer (KYC) and Know Your Business (KYB) verifications of the Initiator. KYAPay does not provide for anonymous payment, so a Payment Token Issuer does not issue a pay token for an Initiator it has not verified.

Verifier:

The party used by the KYA Token Issuer to verify the identity of the human, organization, or agent or the party used by the Payment Token Issuer to verify the payment method.

KYAPay Token Schemas

Common Token Claims The following are claims in common, used within the KYA (Know Your Agent), PAY (Payment), and KYA-PAY (combined Know Your Agent and Payment) Tokens.

iss:

REQUIRED - URL of the token's issuer. The value MUST be an origin as defined in : a scheme, a host, and an optional port, with no path, query or fragment component. Used for locating the JWK Set for token signature verification, as described in .

sub:

REQUIRED - Subject Identifier. MUST be pairwise unique within a given issuer: unique, and different at each Target service (tsi). As for hid.id, the value MUST NOT be, or reveal, a directly identifying attribute, and values at different Target services MUST NOT be linkable to one another without the issuer's cooperation. The subject identifies the combination of identities the issuer has verified for the initiator: the human principal, the agent platform and the agent. An issuer MUST use the same sub value at a given Target service while that combination remains unchanged, MUST use a different value at each other Target service, MUST NOT use that value for a different combination, and MUST assign a new sub when any of those identities changes. KYA and KYA-PAY tokens carry the human principal and the agent as the hid and aid claims, and carry the agent platform as the apd claim where it is identified. PAY tokens carry none of them. The subject identifies the same combination in either case, since an issuer does not issue a token without having verified the initiator. Tokens of different types issued by the same issuer for the same initiator at the same Target service therefore carry the same sub. A recipient MAY associate a PAY token with a KYA token on that basis, but MUST treat them as referring to the same initiator only when both the iss and the sub values are equal.

aud:

REQUIRED - Audience (used for audience binding and replay attack mitigation). The audience identifies the combination of identities the issuer holds for the Target: the human principal, the agent platform and the agent, where "agent" is understood broadly (). A single string value.

iat:

REQUIRED - as defined in . Identifies the time at which the JWT was issued. This claim must have a value in the past and can be used to determine the age of the JWT.

jti:

REQUIRED - Unique ID of this JWT as defined in . This claim identifies the token, not the request. A token may be presented on more than one request within its lifetime, so a repeated jti is not by itself evidence of replay.

exp:

REQUIRED - as defined in . Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

tdm:

REQUIRED where the Target is identified by a domain name; OPTIONAL otherwise. A host name, optionally followed by a path, identifying the Target the token is intended for. See .

ori:

OPTIONAL - URL of the token's originator.

env:

OPTIONAL - Issuer environment (such as "production" or "sandbox"). Additional values may be defined and used.

tsi:

REQUIRED - Target Service ID, assigned by the Token Issuer, identifying the service offered under the Target agent named by aud. See .

itg:

OPTIONAL - Initiator tag - an opaque reference ID internal to the initiator.

cnf:

OPTIONAL - Confirmation claim, as defined in , binding the token to a key held by the agent identified in the aid claim. When present, it MUST contain the jwk member: the agent's public key represented as a JWK . The JWK MUST contain only public key material; a cnf containing private key material MUST be rejected. Other confirmation members MAY additionally be present, but a recipient MUST NOT be required to obtain the key by any means other than reading cnf.jwk. A token carrying cnf is sender-constrained rather than bearer: the presenter is required to demonstrate possession of the confirmation key. Recipient processing is specified in .

Additional claims MAY be defined and used in these tokens. The recipient MUST ignore any unrecognized claims.

Identifying the Target Three claims identify the party a token was minted for, and they answer different questions. The aud claim is the counterpart, on the Target side, of sub on the initiating side, and it names the same three things. Where sub identifies the combination of identities the issuer has verified for the initiator (the human principal, the agent platform and the agent), aud identifies that combination for the Target: the Target's agent, the platform it runs on, and the human principal behind it. "Agent" is used broadly on the Target side. On the initiating side it is a program acting for a person. On the Target side it is whatever the initiator is dealing with, which may be a website, an API, an MCP server, or another agent. The tsi claim identifies the particular service offered under that Target agent. The Token Issuer assigns both, and both are present in every token it creates, so that it can account for the tokens it has issued. Their values are meaningful to the issuer and to a Target that has onboarded to it; onboarding is what allows a Target to interpret them, not what causes them to be set. The two sides differ in what stands behind them. The identities named in sub are verified by the issuer. Those named in aud and tsi are verified where the Target has onboarded to the issuer; where the issuer has no means of confirming the Target, they are its record of the Target that the initiator asserted it was minting for, and tdm carries the domain the initiator supplied. A recipient reads these claims accordingly. They bind a token to one Target and so limit where it can be presented, which holds in either case because the binding narrows the token rather than granting anything. A recipient MUST NOT read tdm alone as the issuer confirming the Target's identity. The tdm claim identifies a Target reached over a URL-based interface, such as a website or an HTTP API: at least its domain, and optionally its host and a path. Unlike aud and tsi it is not issuer-specific, so any recipient can interpret it without a relationship with the issuer. It is present in addition to aud and tsi where such a Target is identified by a domain name. The value of tdm is a host name in lower case, optionally followed by a path, with no scheme, port, query or fragment; for example example.com, shop.example.com or shop.example.com/store. The Target's domain is the registrable domain of that host, determined using the Public Suffix List , including its private section. A host on a shared hosting platform that the list names is therefore a domain of its own, and a token minted for one such host does not name the platform's other hosts. tdm and tsi are alternates rather than duplicates: they name the same Target by different means, one publicly interpretable and one not. A recipient validates whichever it is in a position to interpret. A Target that has onboarded to the issuer checks aud and tsi. A recipient that has not, including a security intermediary acting for many Targets, checks at least that tdm names the domain it is protecting for that request. The Authenticating the Counterparty section of describes that choice. A recipient that checks more than the domain checks that tdm names the Target it is protecting for the request: the host in tdm is that Target's host, and where that Target is identified by a path, the path in tdm is that path or one below it. Paths are matched as cookie paths are (), after both are normalized as described in . Ports are not compared. For example, for a Target at shop.example.com/store, a tdm of shop.example.com/store or shop.example.com/store/cart passes, but shop.example.com, shop.example.com/storefront and example.com/store do not. A recipient that checks only the domain does not enforce the host or the path. A Target whose host serves several tenants, or that protects only some of its paths, therefore checks the host and path itself, or aud and tsi where it has onboarded to the issuer.

Issuer Key Discovery The JWK Set used to verify a token signature is located at the well-known URI formed from the iss claim with the URI suffix jwks.json. Because iss is an origin, this is the well-known URI construction described in applied to that origin. For example, an iss value of https://issuer.example.com yields https://issuer.example.com/.well-known/jwks.json. The jwks.json URI suffix is registered in . JWK Sets SHOULD be cached and refreshed according to standard JWK Set practice. Retrieval per request is neither required nor expected; because KYAPay tokens are self-contained, signature verification is intended to be performed locally. A recipient retrieves this JWK Set only for an issuer it trusts (). A future revision of this specification may additionally define an issuer metadata document, giving an issuer somewhere to advertise capabilities beyond the location of its keys, such as the identity verification methods it supports. Such a document would supplement the mechanism described here rather than replace it.

Token Size This specification sets no maximum token size; the Token Size section of sets the minimum a recipient must accept. An issuer SHOULD NOT emit a token whose claims total more than 4096 octets of JSON, counting all claims together, whichever specification defines them, and measuring before encoding. Base64url encoding adds about a third, so 4096 octets of claims, with a typical JOSE header and an ES256 signature, serializes to about 5670 octets, within that minimum. An issuer using a larger header or signature SHOULD check the complete serialized token against that minimum. Where a request would carry both a KYA token and a PAY token, an issuer SHOULD issue one KYA-PAY token instead, because two tokens at this limit exceed a single header field at a typical origin.

KYA Token The following identity related claims are used within KYA and KYA-PAY tokens:

hid:

REQUIRED - A map of human identity claims (individual or organization).

apd:

OPTIONAL - Agent Platform identity claims.

aid:

REQUIRED - Agent identity claims.

scope

OPTIONAL - String with space-separated scope values, per

The following informative example displays a decoded KYA type token.

A KYA type token

hid - Human Identity Sub-Claims The Human Identity (hid) claim contains sub-claims identifying the human principal (individual or organization) as follows.

id:

REQUIRED - Human principal identifier. An opaque, pseudonymous identifier for the human principal, assigned by the issuer. It MUST NOT be, or reveal, an email address, telephone number or other directly identifying attribute. An issuer MUST use the same value for the same principal acting through the same agent platform at the same Target service (tsi), whatever the agent, and MUST use a different value for each agent platform and for each Target service. Values for different agent platforms or Target services MUST NOT be linkable to one another without the issuer's cooperation; an issuer can, for example, assign each value at random or derive it using a key known only to itself. The value is unique within a given issuer, so a recipient that compares hid.id values from two tokens MUST first check that both carry the same iss.

email:

OPTIONAL - Email address associated with the human individual or organization.

given_name:

OPTIONAL - Given name(s) or first name(s) of the human principal if they are an individual.

middle_name:

OPTIONAL - Middle name(s) of the human principal if they are an individual.

family_name:

OPTIONAL - Surname(s) or last name(s) of the human principal if they are an individual.

phone_number:

OPTIONAL - Phone number associated with the human individual or organization.

organization_name:

OPTIONAL - Name of the organization.

verifier:

OPTIONAL - URL of the party that performed the identity verification

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token carrying unverified identity claims, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified identity on the strength of the claim's presence.

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the identity verification performed. This could be used during auditing and dispute resolution.

ivm:

OPTIONAL - Identity Verification Methods . A JSON array of the methods by which the human principal's identity was verified. An issuer SHOULD include this sub-claim when it knows the methods used.

amr:

OPTIONAL - Authentication Methods References, as defined in Section 2 of , with values from and . A JSON array of the methods by which the human principal authenticated. An issuer SHOULD include this sub-claim when it knows the methods used.

aml:

OPTIONAL - Anti-Money Laundering Methods . A JSON array of the anti-money laundering and counter-terrorist financing methods applied to the human principal. An issuer SHOULD include this sub-claim when it knows the methods used.

The ivm, amr, and aml sub-claims use the syntax and values of the claims of the same names defined in the cited specifications. The absence of any of them does not indicate that a method was not used. The sub-claims email, given_name, middle_name, family_name, phone_number and organization_name directly identify the human principal, and verification_id is the same at every Target. An issuer MUST NOT include any of them unless a Target requires it for the action at hand and the principal has authorized its disclosure to that Target, whether to the issuer or to the agent platform (). Additional sub-claims MAY be defined and used, including further identifiers for the human principal where a Target requires them to recognize an account. An issuer MUST NOT assert an identifier of the human principal unless it has verified that the principal controls it. This document does not prescribe how control is verified. The recipient MUST ignore any unrecognized sub-claims.

Agent Platform Identity apd Sub-Claims The apd claim is REQUIRED in KYA and KYAPay tokens. It contains the following sub-claims.

id:

REQUIRED - Agent Platform identifier.

name:

REQUIRED - Agent Platform name.

email:

OPTIONAL - Email associated with agent platform.

phone_number:

OPTIONAL - Phone number associated with agent platform.

organization_name:

OPTIONAL - Legal name associated with agent platform.

verifier:

OPTIONAL - URL of the party that verified the agent identity (KYA)

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token carrying unverified Know Your Agent claims, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified identity on the strength of the claim's presence.

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the KYA verification performed. This could be used during auditing and dispute resolution.

ivm:

OPTIONAL - Identity Verification Methods . A JSON array of the methods by which the agent platform's identity was verified. An issuer SHOULD include this sub-claim when it knows the methods used.

aml:

OPTIONAL - Anti-Money Laundering Methods . A JSON array of the anti-money laundering and counter-terrorist financing methods applied to the agent platform. An issuer SHOULD include this sub-claim when it knows the methods used.

The ivm and aml sub-claims use the syntax and values of the claims of the same names defined in the cited specifications. The absence of either does not indicate that a method was not used. In a KYAPay token, the ivm, amr, and aml claims appear only as sub-claims of hid and apd, so that each describes the party whose claim contains it: in hid, how the human principal was vetted; in apd, how the agent platform was vetted. amr does not apply to the agent platform and is not used in apd. Issuers MUST NOT include ivm, amr, or aml as top-level claims in a KYAPay token, and recipients MUST ignore them if they appear there. Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.

Agent Identity aid Sub-Claims The aid claim is REQUIRED. It contains the following sub-claims.

id:

REQUIRED - Agent identifier. An issuer MUST use the same value for the same agent at the same Target service (tsi), and a different value at each Target service. The value MUST NOT be, or reveal, a directly identifying attribute, and values at different Target services MUST NOT be linkable to one another without the issuer's cooperation.

name:

REQUIRED - Agent name. The name should reflect the business purpose of the agent. The name MUST be unique among the agents of a given agent platform at a given issuer, so that the issuer, the agent platform and the agent name together identify the agent unambiguously.

creation_ip:

OPTIONAL - The public IP address of the system / agent that requested the token. Its value is a string containing the public IPv4 or IPv6 address from where the token request originated. When present, it MUST be captured directly from the token request. It is a diagnostic aid, for example when investigating an incident, and is not an access-control signal: a recipient MAY use it as a weak corroborating signal only and MUST NOT treat it as sufficient on its own (). It is personal data, subject to the privacy considerations in .

source_ips:

OPTIONAL - Valid public IP address, or range of public IP addresses, from where the system / agent's requests to merchants / services will originate. A JSON array of IPv4 addresses or ranges, IPv6 addresses or ranges, or domain names resolvable to an IP address via DNS. IPv4 and IPv6 addresses can be a single IPv4 or IPv6 address or a range of IPv4 or IPv6 addresses in CIDR notation or start-and-end IP pairs.

Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.

PAY Token The following payment related claims are used within PAY and KYA-PAY type tokens:

tpr:

OPTIONAL - JSON string representing target service price in currency units.

tps:

OPTIONAL - Target pricing scheme, which represents a way for the target list how it charges for its service or content. One of pay_per_use, subscription, pay_per_mb, or custom. Additional values may be defined and used.

amt:

REQUIRED - JSON string representing token amount in currency units.

cur:

REQUIRED - Currency unit, represented as an ISO 4217 three letter code, such as "EUR".

val:

REQUIRED - JSON string representing token amount in settlement network's units.

mnr:

OPTIONAL - JSON number representing maximum number of requests when tps is pay_per_use.

stp:

REQUIRED - Settlement type (one of coin or card). Additional values may be defined and used.

sti:

REQUIRED - Meta information for payment settlement, depending on the stp value.

Settlement Information sti Sub-Claims The sti claim is REQUIRED in Pay Tokens. It contains the following sub-claims, with the requirement levels marked below. The sti claim carries the settlement instrument, and its contents depend on the value of stp. When the stp value is card, the settlement instrument is an agentic payment credential issued by a payment network under an agentic-commerce programme -- for example Visa Intelligent Commerce (visa_vic) or Mastercard Agent Pay, using Secure Card on File (mastercard_scof). Such a credential is a payment token issued by the payment network (). It is used with a single-use token cryptogram (token_security_code), and the network restricts its use to one initiator, one target, and one amount. It is not a Primary Account Number (PAN), and the underlying PAN cannot feasibly be recovered from it.

type:

REQUIRED - "type" is dependent on the "stp" value; for "coin" - "usdc"; for "card" - "visa_vic" or "mastercard_scof". Additional values may be defined and used.

payment_token:

REQUIRED when the stp value is card; otherwise OPTIONAL - String containing the network-issued agentic payment credential, formatted per ISO/IEC 7812, 12-19 characters. This value MUST be a payment-network-issued agentic or tokenized credential. It MUST NOT be a Primary Account Number (PAN).

token_expiration_month:

REQUIRED when payment_token is present - String containing two-digit Expiration Month Number.

token_expiration_year:

REQUIRED when payment_token is present - String containing four-digit Expiration Year.

token_security_code:

REQUIRED when payment_token is present - String containing the single-use token cryptogram accompanying the credential in payment_token -- a Dynamic Token Verification Value (DTVV) or Token Authentication Verification Value (TAVV), depending on the network. 3 or 4 digits. This value is generated per transaction and is short-lived; its validity period is determined and enforced by the payment network. It MUST NOT be a static Card Verification Value (CVV, CVC2 or CVV2).

verifier:

OPTIONAL - URL of the party that performed the payment method verification

verified:

OPTIONAL - Boolean verification status. When present, the value MUST be true. An issuer does not issue a token against an unverified payment method, so a token never asserts false. The claim gives a recipient an explicit affirmative signal rather than requiring it to infer verification from other claims. A recipient that receives false MUST treat the claim as not asserting verification, and MUST NOT treat the token as carrying a verified payment method on the strength of the claim's presence.

verification_id:

OPTIONAL - Verification identifier. This is the verifier's identifier for the payment method verification performed. This could be used during auditing and dispute resolution.

Additional sub-claims MAY be defined and used. The recipient MUST ignore any unrecognized sub-claims.

Scope of Card Settlement This specification supports card settlement only through payment-network agentic-commerce programmes whose credentials are Payment Tokens as defined by the EMV Payment Tokenisation Specification , used with a single-use token cryptogram and restricted by the payment network to the transaction bound in the token. A token defined in this specification, of any type, MUST NOT contain a Primary Account Number, full magnetic-stripe or chip track data, a static card verification value (CVV, CVC2 or CVV2), or a PIN or PIN block. Settlement instruments that fall within PCI DSS scope require mechanisms this specification does not define -- including confidentiality protection of the token contents and a defined cardholder-data-environment boundary. Support for such instruments is left to future work, and implementers requiring it should not attempt to carry them in the claims defined here.

PAY Token Example The following informative example displays a decoded PAY type token.

A PAY type token

KYA-PAY Token Example The following informative example displays a decoded KYA-PAY type token.

A KYA-PAY type token

Token Validation

Validating KYA and PAY Tokens A recipient MUST confirm that the iss claim names an issuer it trusts before it performs any step below that retrieves key material or otherwise depends on the issuer. A recipient MUST NOT retrieve key material for an issuer that is not in its configured set of trusted issuers. The set of trusted issuers is configured out of band and is not derived from the token.

JWT Header Validation

1. alg - The alg header parameter MUST be present. Recipients MUST support ES256 , and MUST accept it from any issuer they trust whose JWK Set publishes an ES256 key. Issuers MUST use ES256, or an algorithm that they know every recipient of the token accepts. A recipient MUST determine the set of algorithms it will accept for a given issuer, limited to those for which the issuer's JWK Set publishes a suitable key. The set MUST NOT be derived from the token. A token whose alg value is absent from, or outside, that set MUST be rejected, including the value none and any symmetric (MAC) algorithm, since an issuer's JWK Set publishes only public keys. Verification is then performed using the algorithm named in the token and the key obtained from the issuer's JWK Set, or the token is rejected. Together, these guarantee that any conforming recipient can verify a token whose recipients the issuer does not know in advance, without constraining which algorithm a deployment uses. Implementations remain free to support and use others, including post-quantum algorithms as they are standardized; this requirement is a floor for interoperability, not a ceiling on agility. Where the key retrieved from the issuer's JWK Set carries an alg or use parameter, the recipient MUST confirm it is consistent with the parameters of the issued token, and reject the token otherwise.
2. kid - The kid claim MUST be present, and set to a valid Key ID present in the issuer's JWK Set, located as described in .
3. typ - The typ header parameter MUST be present, and its value MUST be one of: kya+jwt, pay+jwt, or kya-pay+jwt. As specified in , values are compared case-insensitively, and a value with the application/ prefix, such as application/kya+jwt, is the same type. A token whose typ is absent or has any other value fails validation. A recipient MUST determine which of these types it accepts for a given request before validating a token. A token of one of these types that the recipient does not accept for that request is set aside: the recipient does not use it for that request, and does not treat it as having failed validation.

JWT Payload Validation

1. Validate iss Claim - Ensure that the token's issuer is one the recipient trusts ().
2. Verify JWT Signature - Valid JWTs MUST be signed with a valid key belonging to the token's issuer (iss claim).
3. Validate the exp Claim - The recipient MUST validate that the token has not expired, within the clock skew tolerance described in .
4. Validate the iat Claim - The recipient MUST validate that the token was issued in the past, within the clock skew tolerance described in .
5. Validate the jti Claim - Ensure that the jti claim is present, and is a UUID.
6. Validate the Audience - A recipient that has onboarded to the issuer ensures that aud and tsi identify it as the intended audience. A recipient that has not ensures at least that tdm names the domain it is protecting for the request ().
7. Validate the env Claim - Ensure that the Environment claim is set to an expected and use case appropriate value (such as production or sandbox)

Clock Skew The iat and exp claims are set from the issuer's clock and evaluated against the recipient's. These are never precisely synchronized, so a recipient applies a tolerance when evaluating them. A recipient MUST accept a token whose iat is up to the tolerance in the future, and MUST accept a token up to the tolerance beyond its exp. A recipient MUST support a tolerance of at least 5 seconds. A recipient SHOULD NOT apply a tolerance greater than 60 seconds; 30 seconds is RECOMMENDED. A tolerance approaching the token's own lifetime defeats the purpose of exp: the effective window in which a captured token is accepted is its lifetime plus twice the tolerance. Where a party generating these timestamps can observe the Date header field () of a response from the intended recipient, it SHOULD use that value to correct subsequent timestamps rather than relying on the recipient's tolerance. Correcting at the sender resolves skew at the only party positioned to detect it.

Validating PAY Tokens For tokens of type pay+jwt or kya-pay+jwt, perform the steps described in the Validating KYA and PAY Tokens section. In addition, perform the following steps.

1. The val claim is greater than 0.
2. The amt claim is greater than 0.
3. The cur claim is set to a currency the target supports (such as USD)
4. The tps claim, if present, matches the pricing scheme that you configured in the target's service
5. The tpr claim, if present, matches the price that you configured in the target's service

Security Considerations

General JWT Practices When validating the JWTs described in this specification, implementers MUST follow the JSON Web Token Best Current Practices, BCP 225 .

Confidentiality of Token Contents The tokens defined in this specification are signed using JWS Compact Serialization. Signing provides integrity protection, not confidentiality. The claims in a token are encoded, not encrypted, and are readable by any party that obtains the token. Tokens defined in this specification carry identity claims about a human principal and, in the case of PAY and KYA-PAY tokens, payment settlement information. Accordingly:

• Tokens MUST be transmitted over a channel providing confidentiality, integrity and server authentication, such as TLS .
• Tokens MUST NOT be written to logs, traces, analytics pipelines, or other persistent stores that are not required to process the transaction. An agent that obtains a token through a tool whose result is returned to a language model may be unable to keep the token out of that model's context or out of a transcript retained from it; the Token Exposure in the Agent Runtime section of describes how such a deployment treats the token.
• Tokens MUST NOT be forwarded to parties other than those necessary to complete the interaction for which they were issued.
• Issuers SHOULD include only those claims necessary for the interaction for which the token is issued. Confidentiality risk is reduced most reliably by not carrying a claim at all.

This specification does not define encryption of the token itself. Tokens are intended to be read by multiple independent parties along a single request path -- bot management and fraud systems at the edge, identity providers, and the target service -- none of which is known to the issuer at the time the token is minted, and between which no key-distribution relationship is assumed. Encrypting the token to a single recipient would both require pre-established key exchange with that recipient and withhold the token's contents from the intermediaries that are its intended consumers. Confidentiality is therefore provided at the transport layer and by minimising token contents, not at the token layer. The settlement information carried in a PAY or KYA-PAY token is additionally protected by its own construction rather than by encryption: the network restricts the credential to the transaction bound in the token, and its accompanying cryptogram is single-use, so a captured token yields no reusable payment instrument.

Settlement Credential Handling The sti claim of a PAY or KYA-PAY token carries a settlement instrument. When stp is card, that instrument is a payment token issued by a payment network and accompanied by a single-use token cryptogram (). For entities other than Token Service Providers, a Payment Token that is defined and used in accordance with the EMV Payment Tokenisation Specification and that exists outside the Token Service Provider's token data environment is not Account Data and is not in scope for PCI DSS . Receiving, inspecting, or forwarding a token defined in this specification therefore does not of itself bring a recipient within that scope. That determination concerns the payment token, not the recipient's wider environment: a system that also stores, processes, or transmits Account Data, or is connected to one that does, remains in scope. prohibits Account Data in any token. A token that carried it would bring every system that processes it within PCI DSS scope, for which this specification provides no confidentiality mechanism.

Token Lifetime The exp claim of a token carrying a settlement instrument SHOULD NOT extend beyond the validity period of that instrument. The token cryptograms that accompany agentic payment credentials are single-use and short-lived; their validity period is determined and enforced by the payment network. Issuing a long-lived token around a short-lived credential provides no benefit and widens the window in which a captured token can be replayed. More generally, issuers SHOULD set exp to the shortest value compatible with the intended interaction.

Bearer Semantics and Proof of Possession Tokens defined in this specification are bearer tokens unless they carry a confirmation method: any party in possession of such a token can present it. For bearer tokens, the protections above -- transport confidentiality, restricted forwarding, short lifetimes, and audience restriction via the aud claim -- are the primary defences against capture and replay. A token MAY carry a cnf claim binding it to a public key held by the agent. A token carrying cnf is sender-constrained rather than bearer: possession of the token alone is insufficient, and a recipient requires the presenter to demonstrate possession of the confirmation key on each request. Recipient behaviour for tokens carrying cnf -- including the requirement to verify an HTTP Message Signature over the confirmation key, and to reject requests where that signature is absent or invalid -- is specified in . Issuers SHOULD include cnf where the agent holds a suitable key and the target is expected to enforce it. Issuers MUST NOT rely on cnf as a substitute for the bearer-token protections above, since a token carrying cnf may still be presented to a recipient that does not enforce it.

Identity Binding The subject binds the human principal, the agent platform and the agent together, and the issuer's signature covers all of them. A recipient can therefore verify that the issuer associated the parties named by the token (see ). Modifying any of those claims within a token invalidates its signature. Combining claims taken from two separately signed tokens does not invalidate either signature, so a recipient that correlates tokens MUST check that both carry the same iss and sub values before treating them as referring to the same initiator. Because the subject is stable at a Target service while the bound identities are unchanged, a recipient at that service MAY use sub as a stable key for that combination, for example to rate-limit or isolate a particular agent without affecting other agents acting for the same principal.

Privacy Considerations By default, a KYA token identifies the human principal only by hid.id. Directly identifying sub-claims such as email, phone_number or names are disclosed only when a Target requires them for the action at hand, as stated in its decline response or discovery document, and the principal has authorized the disclosure. The issuer MAY collect the principal's authorization itself or delegate its collection to the agent platform. Whichever of them collected it MUST be able to demonstrate that it was given. What counts as sufficient evidence may depend on applicable law and regulation. Targets SHOULD NOT require directly identifying sub-claims for actions that do not need them, such as browsing a catalog. A token carrying only hid.id is pseudonymous, not anonymous. hid.id, sub and aid.id are each specific to one Target service and different at every other Target service. At a given service, hid.id is stable for a principal returning through a given agent platform, whatever the agent, while sub and aid.id are stable for one agent of that principal and change with the agent. Two Targets, or a party that sees the traffic of both, cannot link the principal from these values. apd identifies the agent platform and is the same at every Target. aid.name is also the same at every Target, so where an agent acts for a single principal, its name can link that principal's activity across Targets. Directly identifying sub-claims link wherever they are disclosed. KYAPay tokens are designed to convey the information that an agent is acting on behalf of a principal - a person or organization. To do this, they will necessarily contain information about that principal that can be verified and utilized by participants in the system. Participants should therefore only share these tokens with other legitimate participants and not make their contents public or disclose them to unknown or untrustworthy parties. Consent of the principal represented to participate in the interactions is vital. If I authorize an agent to shop for a widget at given price, it's legitimate for the agent to carry enough information about me to the merchant to be able to do this for me. Whereas, if an agent claims to be shopping for me but does not have my authorization to do so, my privacy and possibly also my financial integrity are being violated. The principle of minimal disclosure should be employed. Only the information needed to facilitate the intended interactions should be placed in the tokens and conveyed to participants.

IANA Considerations

JSON Web Token Claims Registration This specification registers the following Claims in the IANA "JSON Web Token Claims" registry established by .

"tdm" Claim

• Claim Name: tdm
• Claim Description: Target domain the token is intended for
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"tsi" Claim

• Claim Name: tsi
• Claim Description: Target Service ID that this token was created for
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"ori" Claim

• Claim Name: ori
• Claim Description: URL of the token's originator
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"env" Claim

• Claim Name: env
• Claim Description: Issuer environment (such as "production" or "sandbox")
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"itg" Claim

• Claim Name: itg
• Claim Description: Initiator tag, an opaque reference ID internal to the initiator
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"hid" Claim

• Claim Name: hid
• Claim Description: JSON structure containing human identity claims
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"apd" Claim

• Claim Name: apd
• Claim Description: JSON structure containing agent platform identity claims
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"aid" Claim

• Claim Name: aid
• Claim Description: JSON structure containing agent identity claims
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"tpr" Claim

• Claim Name: tpr
• Claim Description: JSON string representing target service price in currency units
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"tps" Claim

• Claim Name: tps
• Claim Description: Target pricing scheme, which represents a way for the target list how it charges for its service or content
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"amt" Claim

• Claim Name: amt
• Claim Description: JSON string representing token amount in currency units
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"cur" Claim

• Claim Name: cur
• Claim Description: Currency unit, represented as an ISO 4217 three letter code, such as "EUR"
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"val" Claim

• Claim Name: val
• Claim Description: JSON string representing token amount in settlement network's units
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"mnr" Claim

• Claim Name: mnr
• Claim Description: JSON number representing maximum number of requests
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"stp" Claim

• Claim Name: stp
• Claim Description: Settlement type
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

"sti" Claim

• Claim Name: sti
• Claim Description: Meta information for payment settlement, depending on settlement
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Reference: of this specification

Media Types Registration This section registers the following media types in the IANA "Media Types" registry in the manner described in .

application/kya+jwt

• Type name: application
• Subtype name: kya+jwt
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: Uses JWS Compact Serialization as defined in
• Security considerations: See Security Considerations in
• Interoperability considerations: n/a
• Published specification: of this specification
• Applications that use this media type: Applications using Know Your Agent tokens
• Additional information:
  • Magic number(s): n/a
  • File extension(s): n/a
  • Macintosh file type code(s): n/a
• Person & email address to contact for further information: TBD
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael B. Jones - michael_b_jones@hotmail.com
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com

application/pay+jwt

• Type name: application
• Subtype name: pay+jwt
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: Uses JWS Compact Serialization as defined in
• Security considerations: See Security Considerations in
• Interoperability considerations: n/a
• Published specification: of this specification
• Applications that use this media type: Applications using Pay tokens
• Additional information:
  • Magic number(s): n/a
  • File extension(s): n/a
  • Macintosh file type code(s): n/a
• Person & email address to contact for further information: TBD
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael B. Jones - michael_b_jones@hotmail.com
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com

application/kya-pay+jwt

• Type name: application
• Subtype name: kya-pay+jwt
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: Uses JWS Compact Serialization as defined in
• Security considerations: See Security Considerations in
• Interoperability considerations: n/a
• Published specification: of this specification
• Applications that use this media type: Applications using KYA-Pay tokens
• Additional information:
  • Magic number(s): n/a
  • File extension(s): n/a
  • Macintosh file type code(s): n/a
• Person & email address to contact for further information: TBD
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael B. Jones - michael_b_jones@hotmail.com
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com

Well-Known URI Registration This specification registers the following URI suffix in the IANA "Well-Known URIs" registry established by .

• URI Suffix: jwks.json
• Change Controller: Michael B. Jones - michael_b_jones@hotmail.com
• Specification Document: of this specification
• Status: permanent
• Related Information: The resource is a JWK Set containing the keys with which the origin signs KYAPay tokens.

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] 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. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 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. 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] 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. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. 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. 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. 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. 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. Informative References This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 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. Mozilla Foundation IANA IANA IANA Skyfire Systems Inc. Self-Issued Consulting Akamai 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. Skyfire Systems Inc. Self-Issued Consulting WorkOS 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. EMVCo PCI Security Standards Council

Related Specifications The following specifications are related to and designed to be used with this specification:

• 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?".
• describes how KYAPay tokens can be exchanged for OAuth access tokens to dynamically grant agents access to resources they need to accomplish their mission.
• defines additional "amr" (Authentication Method Reference) values to represent additional authentication methods in use today.
• defines the "ivm" (Identity Verification Methods) claim and values for declaring how the person's identity was verified.
• defines the "aml" (Anti-Money Laundering Methods) claim and values for declaring what AML/CFT methods were employed.

Acknowledgments We would like to thank Bhasker Allam, Jean Diaconu and Carlos Martínez for their contributions to the specification.

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

• Added the optional ivm, amr, and aml sub-claims to the hid claim, and the optional ivm and aml sub-claims to the apd claim.
• Stated that the subject identifies the combination of identities the issuer has verified for the initiator, that it is stable while those identities are unchanged, and that a change to any of them gives a new subject. The identities are carried as claims in KYA and KYA-PAY tokens and not in PAY tokens, but the subject identifies the same combination in all three.
• Stated in the Privacy Considerations that hid.id, sub and aid.id are specific to one Target service, and that directly identifying sub-claims are disclosed only when a Target requires them and the principal has authorized it.
• Removed the qualifier on hid, which read as though the claim were required only for some use cases.
• Stated that a Payment Token Issuer verifies the Initiator, which the role definition had left to the KYA Token Issuer alone.
• Stated that a verified claim is only ever true, and corrected a KYA-PAY example that asserted false. This is a compatibility change: the previous definition admitted false, so a token carrying that value conformed to -02 and does not conform here. Recipient behaviour on receiving false is specified alongside each claim.
• Required a recipient correlating a PAY token with a KYA token to check that both carry the same iss and sub.
• Made sub pairwise: a different value at each Target service, stable at that service.
• Stated that an agent name is unique within an agent platform at a given issuer.
• Added Identity Binding to the Security Considerations.
• Corrected the example comments on sub, which described the subject as an agent account identifier.
• Added "id" as a required sub-claim within "aid".
• Made the "apd" claim REQUIRED in KYA and KYAPay tokens.
• Added a Token Size section: no maximum token size, aggregate size guidance for issuers that fits the minimum recipients are required to accept, and a preference for one KYA-PAY token over separate KYA and PAY tokens.
• Stated that jti identifies the token, not the request, so a repeated jti is not by itself evidence of replay.
• Made creation_ip OPTIONAL and described its use.
• Replaced the example IP addresses with documentation addresses.
• Required a recipient to confirm that it trusts the issuer before retrieving key material, and moved the issuer check ahead of signature verification.
• Added traces to the logging prohibition, and pointed to the Using document for tokens that reach a language model's context.
• Allowed further identifiers for the human principal in hid, only where the issuer has verified that the principal controls them.
• Prohibited Account Data in tokens of every type, described card credentials as EMV Payment Tokens, and cited PCI SSC FAQ 1326 for their PCI DSS scope.
• Replaced the example payment credential values with values that cannot be mistaken for real ones.
• Added an Identifying the Target section relating aud, tsi and tdm, made tsi REQUIRED and tdm REQUIRED where the Target is identified by a domain name, defined the form of tdm, and let a recipient that has not onboarded to the issuer validate the audience using tdm.
• Added hid.id, a pseudonymous identifier for the human principal, specific to one agent platform and one Target service, and made aid.id specific to one Target service.
• Made email OPTIONAL, and included email, phone_number, organization_name, verification_id and the name sub-claims only when a Target requires them for the action at hand and the principal has authorized their disclosure.
• Required recipients to support ES256 and to accept it from trusted issuers that publish an ES256 key, and issuers to use it or an algorithm every recipient of the token accepts; limited the accepted algorithms to those the recipient's configuration allows and the issuer's JWK Set has keys for; and rejected none and symmetric algorithms.
• Required a recipient to determine the typ values it accepts before validating a token, set aside a token of a defined type it does not accept, and reject a token whose typ is missing or not a defined type.
• Changed "SHOULD follow" BCP 225 to "MUST follow".

-02

• Corrected the sti sub-claim names in the PAY and KYA-PAY examples to match the normative names in the Settlement Information section (payment_token, token_expiration_month, token_expiration_year, token_security_code). The examples had retained the pre-rename camelCase forms.
• Clarified that the card settlement instrument is a network-issued agentic payment credential and that token_security_code carries a single-use token cryptogram, not a static CVV.
• Made the aid and sti claims REQUIRED, and marked the sti sub-claim requirement levels individually.
• Added the cnf (confirmation) claim, binding a token to a key held by the agent, and described the resulting sender-constrained semantics.
• Added a Scope of Card Settlement section prohibiting Primary Account Numbers and static card verification values.
• Expanded Security Considerations to cover confidentiality of token contents, settlement credential handling, token lifetime, and bearer versus sender-constrained semantics.
• Tightened JWT header validation: an alg value of none and algorithm substitution are rejected.
• Corrected a missing comma in the KYA token example, and shortened the example token lifetimes, which had exceeded a year.
• Added {:vspace} syntax to definition list entries.
• Required the iss claim to be an origin, with no path, query or fragment component, and corrected the example iss values accordingly; one had lacked a scheme.
• Added an Issuer Key Discovery section specifying that the issuer's JWK Set is located at the jwks.json well-known URI formed from iss, and registered that URI suffix with IANA.
• Added a Clock Skew section bounding the tolerance applied to the "iat" and "exp" claims, and requiring senders to correct skew they can observe.
• Addressed review comments by Jean Diaconu.
• Clarified the meaning of Verifier and differentiated from Recipient.

-01

• Added appendix referencing related specifications.

-00

• Renamed draft-skyfire-kyapayprofile to draft-skyfire-oauth-kyapay-token.

draft-skyfire-kyapayprofile-02

• Changed terms buyer and seller to initiator and target to generalize applicability. These claim names were changed: "sdm" to "tdm", "ssi" to "tsi", "btg" to "itg", "spr" to "tpr", and "sps" to "tps".
• Updated Settlement Information sti Sub-Claims.
• Changed specification type from Informative to Proposed Standard.

draft-skyfire-kyapayprofile-01

• Removed "srl" (Seller Resource Locator) claim.

draft-skyfire-kyapayprofile-00

• Initial Internet Draft.

Contributors