]> Skyfire Systems Inc.

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

Self-Issued Consulting

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

WorkOS

abhishek@hingnikar.com

Ory

jhickman.it@gmail.com

Security Web Authorization Protocol agent identity agentic payment commerce 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. 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 KYAPay tokens are used by agents to identify themselves, the principal they are acting on behalf of, their payment capabilities, their authorized scope of action or mission, and their intended audience. Agents may need access to resources to accomplish their mission. This specification describes how an agent can present a KYAPay token to obtain an OAuth access token granting access to a resource that it needs to accomplish its mission.

Use Cases for KYAPay Token Exchange Enabling agents to create accounts and/or log in to accounts on behalf of their human principals is a 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 email addresses. 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. One example use case is to exchange a KYAPay token for an OAuth access token for a Model Context Protocol service when the agent needs to use the MCP service to accomplish its goals. 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.

Roles The roles defined in are incorporated into this specification.

KYAPay Token Exchange The KYAPay token contains identifying information for both the principal on whose behalf the request is being made (in the Human Identity (hid) claim) and the agent that is authorized to act on behalf of the principal (in the Agent Platform Identity (apd) claim and the Agent Identity (aid) claim). This specification defines two methods of exchanging KYAPay tokens for access tokens: a direct method and a method using a Client ID Metadata Document (CIMD) . It also defines an authorization grant profile identifier, which authorization servers and clients use to declare that they support KYAPay Token Exchange, and an optional authorization server metadata parameter listing supported KYAPay token issuers. The steps when successfully exchanging a KYAPay token for an access token and using it with the protected resource are:

1. The client retrieves the OAuth protected resource metadata document .
2. The client determines from the resource metadata what authorization server(s) can be used for the token exchange.
3. The client chooses an authorization server and retrieves its metadata .
4. The client determines from the authorization server metadata whether the authorization server supports KYAPay Token Exchange, per . It also may be able to determine if the authorization server accepts tokens from specific KYAPay token issuers.
5. The client makes a token exchange request to the authorization server, passing the KYAPay token as the subject_token value, the subject_token_type value of urn:ietf:params:oauth:token-type:kyapay, and passing the resource identifier as the "resource" value.
6. The authorization server returns an access token for the resource to the client using information from the KYAPay token to create the access token. Note that this may be a bearer access token or a DPoP-bound access token . The access token will contain or reference sufficient information for the protected resource to be able to provision access for the client, which may include dynamic account creation.
7. The client uses the access token to make an HTTP resource request to the resource.
8. The resource responds to the resource request providing the requested information.

Note that the ability to use information in the KYAPay token to dynamically provision access to the resource by the agent is critical to enable seamless agentic access to resources for the user. This obviates the need to pre-provision an account for the user at every resource that their agent might access -- a process that would not scale.

Direct KYAPay Token Exchange Method The direct KYAPay Token Exchange method uses a Client Identifier that is constructed directly from information in the KYA Token. Its value contains the token issuer, the token originator, the agent platform identifier, and the agent identity identifier. Specifically, it is the string concatenation of - the string literal "kyapay:", - the iss claim value, - the string literal "|", - the ori claim value, - the string literal "|", - the apd claim's id value, - the string literal "|", and - the aid claim's id value. If the KYAPay token has no ori claim, or no apd claim, the corresponding part is the empty string, so the Client ID always has four parts separated by "|". An example such Client ID value is: This requires the authorization server to recognize and accept these Client IDs without client pre-registration (as described in ) or dynamic client registration . There is precedent for authorization servers using non-pre-registered clients based on the syntax of their Client Identifiers; the Client ID Metadata Document (CIMD) specification uses unregistered Client IDs, the OpenID Federation specification uses unregistered Client IDs, and the OpenID for Verifiable Presentations specification uses unregistered Client IDs. The OpenID4VP specification also uses Client ID prefixes, as this specification does. The token exchange uses and is performed as follows:

• The "none" client authentication method is used.
• An HTTP POST is made to the authorization server's token endpoint.
• The grant_type value is urn:ietf:params:oauth:grant-type:token-exchange.
• The client_id value is the Client ID constructed as described above.
• The subject_token value is the KYAPay token being exchanged.
• The subject_token_type value is urn:ietf:params:oauth:token-type:kyapay.
• The resource value is the URL of the protected resource that the resulting token is intended for.
• The requested_token_type parameter MAY be included; if included, its value is urn:ietf:params:oauth:token-type:access_token.
• No actor_token or actor_token_type parameters are included.

The following is a non-normative example of a POST request to perform a direct KYAPay token exchange for an access token:

KYAPay Token Exchange Method using Client ID Metadata Document (CIMD) This section describes a KYAPay token exchange method using a Client ID Metadata Document (CIMD) . This method uses the CIMD URL as the Client ID. As described in (Client Authentication), clients that are capable of maintaining private key material and performing client authentication SHOULD do so with an acceptable method, such as the private_key_jwt client authentication method. Otherwise, the "none" client authentication method is used, and the client_id parameter is the CIMD URL. The token exchange uses and is performed as follows:

• An HTTP POST is made to the authorization server's token endpoint.
• The grant_type value is urn:ietf:params:oauth:grant-type:token-exchange.
• The subject_token value is the KYAPay token being exchanged.
• The subject_token_type value is urn:ietf:params:oauth:token-type:kyapay.
• The resource value is the URL of the protected resource that the resulting token is intended for.
• The requested_token_type parameter MAY be included; if included, its value is urn:ietf:params:oauth:token-type:access_token.
• No actor_token or actor_token_type parameters are included.

The following is a non-normative example of a POST request by a CIMD client using the private_key_jwt client authentication method to perform a KYAPay token exchange for an access token:

Authorization Server Metadata An authorization server declares support for KYAPay token exchange by including the value urn:ietf:params:oauth:grant-profile:kyapay in its authorization_grant_profiles_supported metadata parameter . An authorization server that includes this value MUST also include urn:ietf:params:oauth:grant-type:token-exchange in grant_types_supported. Including this value indicates only that the authorization server implements the processing rules of this specification. It does not indicate that a token from any particular KYAPay token issuer will be accepted. An authorization server MAY also include the kyapay_issuers_supported metadata parameter . The definition of this parameter is:

kyapay_issuers_supported:

OPTIONAL. JSON array containing a list of issuer identifiers of KYAPay token issuers, as specified in , that can be used with this authorization server. Authorization servers MAY choose not to advertise some supported token issuers, even when this parameter is used. In some use cases, the set of token issuers will not be enumerable. The array MAY be empty.

An authorization server that includes kyapay_issuers_supported MUST also include urn:ietf:params:oauth:grant-profile:kyapay in authorization_grant_profiles_supported.

Client Metadata A client can declare support for KYAPay token exchange by including the value urn:ietf:params:oauth:grant-profile:kyapay in its authorization_grant_profiles_supported client metadata parameter , for example, in its Client ID Metadata Document. A client that includes this value MUST also include urn:ietf:params:oauth:grant-type:token-exchange in its grant_types. Clients using the direct method have no client metadata, so this applies only to clients that publish or register metadata.

KYAPay Token Example An example decoded set of JWT Header Parameters for a KYAPay token is: An example decoded JWT Claims Set for a KYAPay token is: The KYAPay token is used as the subject_token value for the token exchange.

Security Considerations The security considerations defined in and apply to this specification.

Privacy Considerations The privacy considerations defined in and apply to this specification. The kyapay_issuers_supported value may disclose a set of KYAPay token issuers that the authorization server trusts. Clients may need to know, before making a request, whether a KYAPay token they hold or can obtain will be accepted. Deployments that consider their issuer relationships sensitive should take this into account before publishing the list. As in , issuer lists are not conveyed in authorization_grant_profiles_supported.

IANA Considerations

OAuth URI Registration This specification registers the following values in the IANA "OAuth URI" registry established by .

urn:ietf:params:oauth:token-type:kyapay

• URN: urn:ietf:params:oauth:token-type:kyapay
• Common Name: KYAPay Token Type
• Change controller: IETF
• Specification Document: of this specification

urn:ietf:params:oauth:grant-profile:kyapay

• URN: urn:ietf:params:oauth:grant-profile:kyapay
• Common Name: Authorization grant profile identifier for KYAPay Token Exchange
• Change controller: IETF
• Specification Document: of this specification

OAuth Authorization Server Metadata Registration This specification registers the following parameter in the IANA "OAuth Authorization Server Metadata" registry established by .

kyapay_issuers_supported

• Metadata Name: kyapay_issuers_supported
• Metadata Description: JSON array containing a list of issuer identifiers of KYAPay token issuers that can be used with this authorization server
• Change Controller: IETF
• Specification Document(s): of this specification

References Normative References This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. 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. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. 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. 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. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). This pattern is informally referred to as Cross-App Access (XAA). 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 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 use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. 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. Anthropic and the Model Context Protocol Contributors IANA

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

• Reworked to use OAuth 2.0 Token Exchange . Both direct exchange of a KYAPay token for an access token and token exchange for a client using CIMD are defined.
• Defined the urn:ietf:params:oauth:grant-profile:kyapay authorization grant profile for authorization server and client metadata, and the optional kyapay_issuers_supported authorization server metadata parameter.
• Registered the urn:ietf:params:oauth:token-type:kyapay token type, the urn:ietf:params:oauth:grant-profile:kyapay grant profile, and the kyapay_issuers_supported metadata parameter.

-01

• Added Abhishek Hingnikar and Jeffrey Hickman as authors.

-00

• Initial draft.

Contributors Skyfire Systems Inc.