]>

nine01223@naver.com

Security Web Authorization Protocol access token verifiable credential DPoP resource server AI agents This document profiles the JWT access token of RFC 9068 so that the same JWT is also a W3C Verifiable Credential secured with JOSE. The authorization server is the credential's issuer, and the token is bound to the client's key with DPoP (RFC 9449). A resource server receives it as an ordinary DPoP-bound access token and needs no change. A verifier that the authorization server can name as the token's audience can process the same object as a Verifiable Credential. The profile defines no new header parameters, claims or registrations. It states which existing header parameters and claims the token carries, how the claims of the two data models correspond, and the conditions under which one object can safely serve both purposes. Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at .

Introduction OAuth access tokens and Verifiable Credentials are both issuer-signed statements about a subject that a holder of a key presents to a relying party. They have grown up in separate ecosystems, with separate issuance and presentation protocols. A deployment that wants both today issues two objects and runs two stacks. For one class of deployment this is avoidable. Where the party that issues the credential is the authorization server the resource server already trusts, and the party that holds the credential is the OAuth client, a JWT access token already carries nearly everything a Verifiable Credential needs: an issuer, a subject, a validity period and a signature. This document specifies the remainder, so that one JWT satisfies the requirements of both data models under this profile. The primary way the token is presented is the one OAuth already defines. The token is a DPoP-bound access token , the resource server validates it as and require, and the DPoP proof is what binds the presentation to the holder's key. Nothing about the resource server changes. As a secondary path, a holder can present the same object as a Verifiable Credential through a credential presentation protocol, to a verifier that is named as the token's audience (). AI agents are the motivating case. An agent is an OAuth client that calls the HTTP APIs of tools on behalf of a person, and defines an MCP server as an OAuth resource server that accepts only tokens issued for it by its authorization server. A token under this profile satisfies that rule unchanged, and is at the same time a credential stating on whose behalf the agent is calling.

Applicability This profile applies only when all of the following hold. The Holder is the OAuth client, identified in the token by client_id. The client holds the key the token is bound to, as an AI agent or other software client does (). This profile is not a way to issue credentials to end-user wallets. The Issuer is an authorization server that the resource server already trusts. Issuers with which the resource server has no prior relationship are out of scope. The token is sender-constrained with DPoP. The DPoP proof is what binds the token to its holder, so use as a bearer token is prohibited (). The token is presented whole. It is a JWS in compact serialization signed with an asymmetric algorithm. Selective disclosure is out of scope, and every claim is visible to the recipient. The token has a single audience (), and the resource server it names validates JWT access tokens as specifies and enforces DPoP (). How the authorization server authenticates the user or the client before issuing the token is out of scope, as it is in OAuth generally. That includes the case in which the authorization server itself acts as a verifier of credentials the client holds. This profile concerns only the token the authorization server issues afterwards. The profile fits deployments that want a token that is used essentially as an access token, carries no more personal data than an access token would, and is also consumable by Verifiable Credential tooling.

Related Work carries an access token inside an envelope signed by the client. A token under this profile is an access token and can be carried that way as well. The two documents are independent: that one defines how a token is bound and transported, this one what the token is.

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 roles of the two ecosystems correspond as follows. OAuth 2.0 Verifiable Credentials In this profile Authorization server Issuer The same party Client Holder The same party Resource server Verifier May be the same party Access token Verifiable Credential The same object "Token" in this document means a JWT that satisfies . "Verifier" means a party that processes the Token as a Verifiable Credential; it may or may not also be the resource server.

Token Format A Token is a JWT that is an access token as defined in and whose payload is also a verifiable credential as defined in , secured as described in . The claims required by and the properties required by are members of the same top-level JSON object.

Header Parameter Value Basis typ at+jwt REQUIRED by this profile. See below. cty vc REQUIRED by this profile. alg An asymmetric algorithm , . none MUST NOT be used. kid Identifier of the Issuer's key OPTIONAL, except as stated in . The two specifications treat typ differently. requires the access token media type in typ and recommends writing it without the application/ prefix, as at+jwt; requires a resource server to reject a token whose typ is neither at+jwt nor application/at+jwt. recommends vc+jwt without requiring it. This profile therefore requires at+jwt, and identifies the content as a verifiable credential with cty, the parameter provides for distinguishing secured content. does not recommend cty in a JWT that is not nested. This profile uses it nonetheless, because typ is taken by the access token media type and cty is the only other place in the header where the content can be identified. A recipient that does not understand the value ignores it; only the value JWT has a defined effect on JWT processing. Because vc+jwt is a recommendation, a Verifier that does not enforce it needs no change on account of typ. A Verifier that strictly requires vc+jwt needs an exception for at+jwt with cty vc ().

Claims All claims that requires are present, and cnf is added. The following table lists them together with the property each corresponds to, if any. JWT claim VC property Rule iss issuer REQUIRED. The same value. This profile requires it to be a URI (). sub credentialSubject.id REQUIRED. The same value. This profile requires it to be a URI () and makes credentialSubject.id REQUIRED. aud none REQUIRED. A single value, set by the Issuer (). exp validUntil REQUIRED. validUntil MUST NOT be later than exp and SHOULD express the same instant. iat none REQUIRED. Independent of validFrom. jti id REQUIRED. If id is present it MUST equal jti. client_id none REQUIRED. The OAuth client, which is the Holder (). scope none OPTIONAL. As in . cnf none REQUIRED by this profile, for DPoP binding. jkt () is REQUIRED. jwk MAY be added; if both are present they MUST identify the same key. The payload also carries the properties that requires. VC property Requirement @context REQUIRED. See below. type REQUIRED. MUST include VerifiableCredential. issuer REQUIRED. The same value as iss. credentialSubject REQUIRED. Claims about the subject. validUntil REQUIRED by this profile. Not later than exp. id OPTIONAL. The same value as jti. credentialStatus OPTIONAL. See . The first value of @context MUST be https://www.w3.org/ns/credentials/v2. That context defines iss, sub, aud, exp, iat and cnf, but not client_id, jti, scope, or the jkt member of cnf. Section 5.2 of requires a document that uses terms its contexts do not define to say so. A Token therefore MUST either include a context that defines those terms, or include https://www.w3.org/ns/credentials/undefined-terms/v2 as the last value of @context. The vc and vp claims MUST NOT be present, as requires. The nbf claim SHOULD NOT be used, as recommends. validUntil is REQUIRED so that a Verifier that determines validity from the credential's own properties, as a Verifiable Credential verifier does, reaches the same result as a resource server that checks exp.

The Holder and Its Key sub identifies the subject of the claims, for example the user. client_id identifies the Holder, for example the agent. The two differ whenever a client acts on behalf of a user, and a recipient MUST NOT assume that the party identified by sub is the Holder. cnf confirms the Holder's key. It is the key the client demonstrated with a DPoP proof in the token request (). This is the binding that Section 4.1.3 of recommends, in which the credential is bound to a proof-of-possession key that the Holder provided to the Issuer. The key need not be published or long-lived. It has to remain available to the Holder only for the lifetime of the Token. A client can use a new key for each Token, unless it obtains Tokens with a refresh token that is itself bound to a DPoP key, as requires for public clients; such a client uses that key for as long as it uses the refresh token. The authorization server associates that key with client_id through the client authentication performed in the same token request. How it authenticates the client is out of scope (). As notes, that association is not a cryptographic one. A deployment that needs one can have the client's authentication credential confirm the DPoP key, for example with a client assertion that carries the key's thumbprint. Where the subject is itself the Holder, the Issuer MAY use as sub and credentialSubject.id an identifier from which the Holder's key can be obtained, such as a DID. That key MUST then be the key cnf confirms, and a Verifier can identify the Holder's key from credentialSubject.id as it does for other Verifiable Credentials. This option implies that the key is a long-term one and that the Holder uses it for DPoP.

Identifiers does not require iss or sub to be a URI. This profile does, because requires issuer and credentialSubject.id to be URLs and each pair carries a single value. A Decentralized Identifier (DID) is a URI and MAY be used for either. For iss one constraint follows from OAuth rather than from this profile. requires iss to exactly match the authorization server's issuer identifier, and a resource server that obtains keys through authorization server metadata knows that identifier as an https URL. In such a deployment iss is that https URL. An iss that is not an https URL can be used only where the resource server is configured with the issuer identifier and its keys by other means. aud and client_id are not affected. aud carries the identifier the resource server expects for itself (), and client_id is the OAuth client identifier. The payload is processed as JSON. A recipient is not required to perform JSON-LD processing, and MUST NOT retrieve documents referenced by @context values in order to validate the Token.

Audience The audience is set by the Issuer when the Token is issued. The Holder does not set it. aud MUST contain exactly one value, and that value MUST identify a single protected resource. This is the audience that and produce for a request naming one resource. An identifier that several distinct protected resources have agreed to accept MUST NOT be used, since it has the properties of a multi-valued audience under another form. A Holder that calls several resource servers obtains a Token for each. This does not require asking the user again. As describes, a client that has been granted access to several resources names one of them in the resource parameter of each token request, including a refresh request, and receives a token for that resource. Token exchange serves the same purpose. The restriction has three effects: The scope of a Token refers to one resource. The ambiguity that warns of, in which a scope value cannot be correlated with one of several audiences, does not arise. A Token carries authority over one resource, and that is the extent of the damage if the Holder's key is compromised. A DPoP proof binds a presentation to a request; it does not reduce the authority the Token conveys, and a Holder has no means of presenting less than the whole Token. The Token itself therefore has to be narrow. No recipient learns which other resources the Holder may access, or sees claims intended for them.

Status Status information is OPTIONAL. A Token is short-lived, as access tokens are, and many deployments will need no revocation mechanism. A deployment that requires status checking MUST specify which mechanism it uses and which recipients check it. The mechanism is either a credentialStatus property referring to a Bitstring Status List or a status claim as defined in . A recipient is not required to support a mechanism the deployment has not chosen, and ignores status information it does not support. If a Token carries both, they MUST express the same status. This profile does not itself require a resource server to check status; does not, and a resource server that validates Tokens as specifies remains conformant. Status information indicates revocation only. It never extends the period set by exp and validUntil.

Key Discovery A resource server obtains the Issuer's keys as it does for any JWT access token, from the authorization server metadata . A Verifier uses the key discovery of , which can start from iss, from kid, or from both. The Issuer MUST make the signing key discoverable by both, each through its own mechanism, and uses a single identifier as both iss and issuer (). kid is not required by . It MUST be present where the key discovery rules of require it, which is the case when the Issuer's key is expressed as a DID URL. If kid is present, it MUST identify the same key in both contexts.

Presentation

To a Resource Server The Holder presents the Token as a DPoP-bound access token, exactly as specifies. The resource server validates it as and specify. This document adds nothing to either. In particular, ath in the DPoP proof is the hash of the Token, and the proof's key is checked against cnf.jkt. Seen from the credential side, the DPoP proof is the holder binding of the presentation (): a statement signed with the key the Issuer confirmed, bound to this request by htm and htu, to this Token by ath, and to the resource server's challenge by nonce when the resource server supplies one. No separate presentation object is created. A resource server that supports DPoP requires no change to accept a Token. It need not understand the Verifiable Credential properties in the payload and ignores those it does not use.

To a Verifier A Holder MAY present the same Token to a Verifier through a credential presentation protocol such as . How the Token is carried is determined by that protocol; one way is to enclose it in a verifiable presentation as an EnvelopedVerifiableCredential . Holder binding is provided by that protocol, with a presentation signed by the Holder's key. The definition of a credential format identifier for use with is outside the scope of this document. A Verifier processes the Token as it processes any verifiable credential secured with JOSE , and the Token is formed so that this needs as little special handling as possible: Signature. The Verifier verifies it with a key of an Issuer it trusts (). Validity. validUntil is always present and never later than exp (), so checking validUntil, exp, or both gives the same result. Audience. Two audiences are involved. The audience and nonce of the presentation are set in the exchange between the Holder and the Verifier, and are checked as the presentation protocol specifies. The aud of the Token is set by the Issuer and cannot be changed by the Holder or by that exchange. The Verifier checks it as any recipient of a JWT does, and rejects the Token if aud is not an identifier the Verifier expects for itself (). Holder binding. The presentation is signed by the Holder's key. The Verifier identifies that key from cnf, as allows, or from credentialSubject.id where that identifier yields the key (). Where cnf contains only jkt, the comparison is by JWK SHA-256 Thumbprint . Status. Checked if the deployment requires Verifiers to do so (). The point at which a Verifier may need to do something it does not do for other credentials is typ. recommends vc+jwt and does not require it, so a Verifier that does not enforce the recommendation needs no change. A Verifier that does enforce it needs an exception that accepts at+jwt when cty is vc. Whatever its handling of typ, a Verifier MUST NOT treat as a Verifiable Credential a JWT access token that lacks cty vc or does not satisfy .

Obtaining a Token for a Verifier Because of the audience check, a Token is presented only to the Verifier named in its aud. If the Verifier is the resource server the Token was issued for, the same Token is presented. For another Verifier, the Holder obtains a Token whose aud is that Verifier (), by requesting one with the Verifier's identifier as the resource value . This requires that the authorization server know the Verifier as a protected resource it can name as an audience. A Verifier in a credential presentation protocol is not necessarily such a party; in it is an OAuth client, identified by a client identifier. Presentation to a Verifier that the authorization server cannot name as an audience is outside the scope of this document ().

Security Considerations The security considerations of and apply. In particular, DPoP protects a Token that has leaked; it does not protect one whose Holder is compromised. As describes, an attacker able to run code in the client can use the Holder's key, whether or not the key can be exported.

A Live Access Token Is Shown to a Verifier Presenting the Token to a Verifier discloses a valid access token to that Verifier. Encrypting the Token does not change this, since the Verifier has to read the Token in order to verify it. The single audience addresses it (). A Token names one protected resource, and a Verifier accepts only a Token that names the Verifier (). What a Verifier is shown is therefore a token that is valid only at itself, which is what any resource server is shown, and it is of no use anywhere else. Sender-constraining () adds to this: even at the resource it names, the Token cannot be used without the Holder's key.

Sender-Constraining The Token is a credential bound to its holder only because of cnf and a proof of possession. Without them, anyone who obtained the Token could present it. Sender-constraining is therefore a condition of this profile, not an option: An authorization server MUST NOT issue a Token that is not DPoP-bound. A resource server that accepts Tokens MUST NOT accept one presented with the Bearer scheme. already requires this of a resource server that supports both schemes. An authorization server MUST NOT issue a Token for a resource server that does not enforce DPoP. As observes, a resource server that is unaware of DPoP would most likely accept a DPoP-bound token as a bearer token.

Replay Replay of a DPoP proof is limited as in . Resource servers SHOULD supply a nonce as described in . Without one, replay is limited only by the period for which a resource server accepts a proof's iat, and by jti where the resource server tracks it.

Token Confusion The same object is an access token to a resource server and a credential to a Verifier. The cty and payload check in keeps an ordinary access token from being taken for a credential. In the other direction, a resource server is unaffected: a Token is a valid access token, and is issued only by an authorization server the resource server already trusts.

Lifetime The credential's validity never exceeds the access token's. validUntil cannot be later than exp (), and status information cannot extend either ().

Retrieval of External Resources A status list URL taken from a Token and dereferenced as is gives an attacker a way to make the recipient issue requests. A recipient SHOULD retrieve status lists only from locations that a trusted Issuer has made known through configuration. Documents referenced by @context are not retrieved ().

Privacy Considerations A Token is presented whole, so every claim is visible to its recipient. An Issuer SHOULD include only claims that the recipient may see, and no more personal data than it would put in an access token. Credentials that describe a natural person in detail, and that need selective disclosure or the person's consent at presentation time, belong in a wallet and in a presentation protocol designed for them, not in this profile. states that a client MUST NOT inspect the content of an access token, because the authorization server and the resource server may change the token format at any time. This profile does not require a client to do so. On both presentation paths the client handles the Token as an opaque string: it computes a hash of it for the DPoP proof, or encloses it in a presentation. A client learns that the tokens it receives conform to this profile from deployment configuration, not from parsing them. As also notes, the content of an unencrypted token is visible to the client, and an authorization server takes that into account when it chooses what to include.

IANA Considerations This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. 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. 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. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. 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. W3C W3C 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. MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. eBay This specification defines a profile for OAuth 2.0 sender-constrained credentials in which access tokens and refresh tokens are cryptographically bound to the client's private key as a single inseparable envelope. Authorization code flows are also covered: the client declares its public key binding via cnf.jkt in the EPOP token presented at the token endpoint, ensuring the authorization code can only be exchanged by the key-holding client; the code itself travels as the standard code form parameter. Unlike existing mechanisms, EPOP provides proof-of-possession uniformly across both JWT and opaque access tokens, and across HTTP and non-HTTP transports. The profile extends sender-constraining beyond HTTP to non-HTTP transports including MQTT, Kafka, the Model Context Protocol (MCP), gRPC, and SASL-based protocols such as those defined in [RFC7628]. It introduces atomic proof-of-possession key rotation, enabling clients to rotate key pairs without disrupting active sessions, and an offline-derived client nonce (cnonce) that eliminates the server- issued nonce round-trip required by existing mechanisms — enabling stateless proof validation critical for non-HTTP and high-throughput deployments. Authorization servers, resource servers, and clients from different vendors can implement this profile interoperably. W3C OpenID Foundation Model Context Protocol

Example Header:

Payload:

Presentation to the resource server:

Open Issues Whether Verifiable Credential verifiers will accept typ at+jwt with cty vc. Input from the W3C community is needed. The Verifiable Credentials context defines jwk and kid as members of cnf, but not jkt. Whether a Token should also carry cnf.jwk for the benefit of Verifiers. A credential format identifier for , to be defined elsewhere. Presentation to a Verifier that the authorization server cannot name as an audience, such as an verifier known only by a client identifier ().

Document History -03 @context: a Token carries claims that the Verifiable Credentials context does not define, and now has to declare that as requires. The example in -02 did not. The Holder is the client identified by client_id. A statement in -02 that a recipient must not assume this was wrong and is removed; the caution applies to sub only. Added what the Holder's key is, how long it has to live, and how it is associated with the client (). The abstract no longer says that any verifier can process a Token; the Verifier has to be named as its audience. Stated that the security considerations of RFC 9068 and RFC 9449 apply. Acknowledged that RFC 7519 does not recommend cty outside nested JWTs. -02 Changed the approach. The object presented to a resource server is now an access token issued by the authorization server, with a single aud value set by the Issuer. Presentation of credentials that are not access tokens was removed. The Token is at the same time a W3C Verifiable Credential secured with JOSE. SD-JWT and selective disclosure are no longer discussed. Title changed to match. Intended status changed to Informational. -01 Editorial corrections only. -00 Initial version.

Acknowledgments This version owes its direction to the discussion of -00 and -01 on the OAuth working group mailing list. The author is especially indebted to Warren Parad, who engaged with the earlier versions over many exchanges with patience and care. His questions led the author to reconsider what this document should define, and it would not have taken its present form without them. Yaron Zehavi's review of the credential presentation model informed that reconsideration, and his advice on audience handling informed . Ashwin Ambekar pointed the author to EPOP. Errors and remaining disagreements are the author's own.