]> 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 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 in order 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 on the principal (in the Agent Platform Identity (apd) claim and/or in the Agent Identity (aid) claim). The token exchange is performed using the grant type urn:ietf:params:oauth:grant-type:jwt-bearer at the authorization server's token endpoint. The KYAPay token is supplied as the assertion value. The protected resource that access is being requested for is supplied as the resource value . Note that OAuth Token Exchange , which has a separate subject_token and actor_token values, is not used, since the KYAPay token has all the information needed to describe both parties for delegated authorization.

KYAPay Token Exchange Example The following is a non-normative example of a POST request to perform a KYAPay token exchange for an access token: An example decoded set of JWT Header Parameters for the KYAPay token is: An example decoded JWT Claims Set for the KYAPay token is: An example decoded set of JWT Header Parameters for the resulting access token is: An example decoded JWT Claims Set for the resulting access token is:

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

Privacy Considerations The privacy considerations defined in and apply to this specification.

IANA Considerations This specification requires no actions by IANA.

References Normative References 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 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. 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 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. 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.

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

• Initial draft.

Contributors Skyfire Systems Inc.