Web Authorization Protocol S. F. Lee Internet-Draft 1 October 2026 Intended status: Informational Expires: 4 April 2027 JWT Access Tokens as W3C Verifiable Credentials draft-lee-oauth-dpop-credential-presentation-03 Abstract 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. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lee-oauth-dpop-credential- presentation/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Lee Expires 4 April 2027 [Page 1] Internet-Draft Access Tokens as VCs October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. The Holder and Its Key . . . . . . . . . . . . . . . 9 3.2.2. Identifiers . . . . . . . . . . . . . . . . . . . . . 9 3.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 11 4. Presentation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. To a Resource Server . . . . . . . . . . . . . . . . . . 12 4.2. To a Verifier . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Obtaining a Token for a Verifier . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. A Live Access Token Is Shown to a Verifier . . . . . . . 14 5.2. Sender-Constraining . . . . . . . . . . . . . . . . . . . 14 5.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Token Confusion . . . . . . . . . . . . . . . . . . . . . 15 5.5. Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Retrieval of External Resources . . . . . . . . . . . . . 15 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 Lee Expires 4 April 2027 [Page 2] Internet-Draft Access Tokens as VCs October 2026 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Document History . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. 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 [RFC9068] already carries nearly everything a Verifiable Credential [VC-DATA-MODEL-2.0] 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 [RFC9449], the resource server validates it as [RFC9068] and [RFC9449] 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 (Section 4.2). 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 [MCP.Authorization] 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. 1.1. Applicability This profile applies only when all of the following hold. Lee Expires 4 April 2027 [Page 3] Internet-Draft Access Tokens as VCs October 2026 1. 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 (Section 3.2.1). This profile is not a way to issue credentials to end-user wallets. 2. 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. 3. 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 (Section 5). 4. The token is presented whole. It is a JWS in compact serialization [RFC7515] signed with an asymmetric algorithm. Selective disclosure is out of scope, and every claim is visible to the recipient. 5. The token has a single audience (Section 3.3), and the resource server it names validates JWT access tokens as [RFC9068] specifies and enforces DPoP (Section 5). 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. 1.2. Related Work [I-D.ambekar-oauth-epop] 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. Lee Expires 4 April 2027 [Page 4] Internet-Draft Access Tokens as VCs October 2026 2. 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 [RFC2119] [RFC8174] 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 | +----------------------+------------------------+-----------------+ Table 1: Role correspondence "Token" in this document means a JWT that satisfies Section 3. "Verifier" means a party that processes the Token as a Verifiable Credential; it may or may not also be the resource server. 3. Token Format A Token is a JWT [RFC7519] that is an access token as defined in [RFC9068] and whose payload is also a verifiable credential as defined in [VC-DATA-MODEL-2.0], secured as described in [VC-JOSE-COSE]. The claims required by [RFC9068] and the properties required by [VC-DATA-MODEL-2.0] are members of the same top-level JSON object. 3.1. Header +===========+==================+========================+ | Parameter | Value | Basis | +===========+==================+========================+ | typ | at+jwt | REQUIRED by this | | | | profile. See below. | +-----------+------------------+------------------------+ | cty | vc | REQUIRED by this | | | | profile. | Lee Expires 4 April 2027 [Page 5] Internet-Draft Access Tokens as VCs October 2026 +-----------+------------------+------------------------+ | alg | An asymmetric | [RFC9068], [RFC8725]. | | | algorithm | none MUST NOT be used. | +-----------+------------------+------------------------+ | kid | Identifier of | OPTIONAL, except as | | | the Issuer's key | stated in Section 3.5. | +-----------+------------------+------------------------+ Table 2: Header parameters The two specifications treat typ differently. Section 2.1 of [RFC9068] requires the access token media type in typ and recommends writing it without the application/ prefix, as at+jwt; Section 4 of [RFC9068] requires a resource server to reject a token whose typ is neither at+jwt nor application/at+jwt. [VC-JOSE-COSE] recommends vc+jwt without requiring it. This profile therefore requires at+jwt, and identifies the content as a verifiable credential with cty, the parameter [VC-JOSE-COSE] provides for distinguishing secured content. Section 5.2 of [RFC7519] 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 (Section 4.2). 3.2. Claims All claims that [RFC9068] requires are present, and cnf is added. The following table lists them together with the [VC-DATA-MODEL-2.0] property each corresponds to, if any. Lee Expires 4 April 2027 [Page 6] Internet-Draft Access Tokens as VCs October 2026 +===========+======================+================================+ | JWT claim | VC property | Rule | +===========+======================+================================+ | iss | issuer | REQUIRED. The same value. | | | | This profile requires it | | | | to be a URI | | | | (Section 3.2.2). | +-----------+----------------------+--------------------------------+ | sub | credentialSubject.id | REQUIRED. The same value. | | | | This profile requires it | | | | to be a URI | | | | (Section 3.2.2) and makes | | | | credentialSubject.id | | | | REQUIRED. | +-----------+----------------------+--------------------------------+ | aud | none | REQUIRED. A single value, | | | | set by the Issuer | | | | (Section 3.3). | +-----------+----------------------+--------------------------------+ | 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 (Section 3.2.1). | +-----------+----------------------+--------------------------------+ | scope | none | OPTIONAL. As in | | | | [RFC9068]. | +-----------+----------------------+--------------------------------+ | cnf | none | REQUIRED by this profile, | | | | for DPoP binding. jkt | | | | (Section 6.1 of [RFC9449]) | | | | is REQUIRED. jwk [RFC7800] | | | | MAY be added; if both are | | | | present they MUST identify | | | | the same key. | +-----------+----------------------+--------------------------------+ Table 3: JWT access token claims Lee Expires 4 April 2027 [Page 7] Internet-Draft Access Tokens as VCs October 2026 The payload also carries the properties that [VC-DATA-MODEL-2.0] 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 | | | Section 3.4. | +-------------------+-----------------------------------------------+ Table 4: Verifiable Credential properties 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 [VC-DATA-MODEL-2.0] 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 [VC-JOSE-COSE] requires. The nbf claim SHOULD NOT be used, as [VC-JOSE-COSE] 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. Lee Expires 4 April 2027 [Page 8] Internet-Draft Access Tokens as VCs October 2026 3.2.1. 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 (Section 5 of [RFC9449]). This is the binding that Section 4.1.3 of [VC-JOSE-COSE] 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 Section 5 of [RFC9449] 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 (Section 1.1). As Section 11.11 of [RFC9449] 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. 3.2.2. Identifiers [RFC9068] does not require iss or sub to be a URI. This profile does, because [VC-DATA-MODEL-2.0] 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. Lee Expires 4 April 2027 [Page 9] Internet-Draft Access Tokens as VCs October 2026 For iss one constraint follows from OAuth rather than from this profile. Section 4 of [RFC9068] requires iss to exactly match the authorization server's issuer identifier, and a resource server that obtains keys through authorization server metadata [RFC8414] 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 (Section 3.3), 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. 3.3. 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 Section 3 of [RFC9068] and [RFC8707] 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 Section 2.2 of [RFC8707] 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 [RFC8693] serves the same purpose. The restriction has three effects: * The scope of a Token refers to one resource. The ambiguity that Section 5 of [RFC9068] 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. Lee Expires 4 April 2027 [Page 10] Internet-Draft Access Tokens as VCs October 2026 * No recipient learns which other resources the Holder may access, or sees claims intended for them. 3.4. 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 [VC-BITSTRING-STATUS-LIST] or a status claim as defined in [I-D.ietf-oauth-status-list]. 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; [RFC9068] does not, and a resource server that validates Tokens as [RFC9068] specifies remains conformant. Status information indicates revocation only. It never extends the period set by exp and validUntil. 3.5. Key Discovery A resource server obtains the Issuer's keys as it does for any JWT access token, from the authorization server metadata [RFC8414]. A Verifier uses the key discovery of [VC-JOSE-COSE], 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 (Section 3.2.2). kid is not required by [RFC9068]. It MUST be present where the key discovery rules of [VC-JOSE-COSE] 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. 4. Presentation Lee Expires 4 April 2027 [Page 11] Internet-Draft Access Tokens as VCs October 2026 4.1. To a Resource Server The Holder presents the Token as a DPoP-bound access token, exactly as Section 7.1 of [RFC9449] specifies. The resource server validates it as Section 4 of [RFC9068] and Section 7.1 of [RFC9449] 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 (Section 3.2.1): 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. 4.2. To a Verifier A Holder MAY present the same Token to a Verifier through a credential presentation protocol such as [OpenID4VP]. How the Token is carried is determined by that protocol; one way is to enclose it in a verifiable presentation as an EnvelopedVerifiableCredential [VC-DATA-MODEL-2.0]. 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 [OpenID4VP] is outside the scope of this document. A Verifier processes the Token as it processes any verifiable credential secured with JOSE [VC-JOSE-COSE], 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 (Section 3.5). * Validity. validUntil is always present and never later than exp (Section 3.2), so checking validUntil, exp, or both gives the same result. Lee Expires 4 April 2027 [Page 12] Internet-Draft Access Tokens as VCs October 2026 * 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 (Section 4.1.3 of [RFC7519]). * Holder binding. The presentation is signed by the Holder's key. The Verifier identifies that key from cnf, as [VC-JOSE-COSE] allows, or from credentialSubject.id where that identifier yields the key (Section 3.2). Where cnf contains only jkt, the comparison is by JWK SHA-256 Thumbprint [RFC7638]. * Status. Checked if the deployment requires Verifiers to do so (Section 3.4). The point at which a Verifier may need to do something it does not do for other credentials is typ. [VC-JOSE-COSE] 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 Table 4. 4.2.1. 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 (Section 3.3), by requesting one with the Verifier's identifier as the resource value [RFC8707]. 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 [OpenID4VP] 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 (Appendix B). Lee Expires 4 April 2027 [Page 13] Internet-Draft Access Tokens as VCs October 2026 5. Security Considerations The security considerations of [RFC9068] and [RFC9449] apply. In particular, DPoP protects a Token that has leaked; it does not protect one whose Holder is compromised. As Section 11.4 of [RFC9449] describes, an attacker able to run code in the client can use the Holder's key, whether or not the key can be exported. 5.1. 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 (Section 3.3). A Token names one protected resource, and a Verifier accepts only a Token that names the Verifier (Section 4.2). 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 (Section 5.2) adds to this: even at the resource it names, the Token cannot be used without the Holder's key. 5.2. 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. Section 7.2 of [RFC9449] 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 Section 7.2 of [RFC9449] observes, a resource server that is unaware of DPoP would most likely accept a DPoP-bound token as a bearer token. Lee Expires 4 April 2027 [Page 14] Internet-Draft Access Tokens as VCs October 2026 5.3. Replay Replay of a DPoP proof is limited as in [RFC9449]. Resource servers SHOULD supply a nonce as described in Section 9 of [RFC9449]. 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. 5.4. 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 Section 4.2 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 [RFC9068] access token, and is issued only by an authorization server the resource server already trusts. 5.5. Lifetime The credential's validity never exceeds the access token's. validUntil cannot be later than exp (Section 3.2), and status information cannot extend either (Section 3.4). 5.6. 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 (Section 3.2). 6. 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. Section 6 of [RFC9068] 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 Lee Expires 4 April 2027 [Page 15] Internet-Draft Access Tokens as VCs October 2026 from deployment configuration, not from parsing them. As [RFC9068] 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. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . Lee Expires 4 April 2027 [Page 16] Internet-Draft Access Tokens as VCs October 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [VC-DATA-MODEL-2.0] W3C, "Verifiable Credentials Data Model v2.0", 15 May 2025, . [VC-JOSE-COSE] W3C, "Securing Verifiable Credentials using JOSE and COSE", 15 May 2025, . 8.2. Informative References [I-D.ambekar-oauth-epop] Ambekar, A., "JSON Web Token (JWT) Profile for OAuth 2.0 Enveloped Proof of Possession (EPOP)", Work in Progress, Internet-Draft, draft-ambekar-oauth-epop-03, 23 July 2026, . [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf- oauth-status-list-21, 21 June 2026, . [MCP.Authorization] Model Context Protocol, "Model Context Protocol Specification: Authorization", 25 November 2025, . [OpenID4VP] OpenID Foundation, "OpenID for Verifiable Presentations 1.0", n.d., . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . Lee Expires 4 April 2027 [Page 17] Internet-Draft Access Tokens as VCs October 2026 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [VC-BITSTRING-STATUS-LIST] W3C, "Bitstring Status List v1.0", 15 May 2025, . Appendix A. Example Header: { "alg": "ES256", "typ": "at+jwt", "cty": "vc", "kid": "as-key-1" } Payload: Lee Expires 4 April 2027 [Page 18] Internet-Draft Access Tokens as VCs October 2026 { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://www.w3.org/ns/credentials/undefined-terms/v2" ], "type": ["VerifiableCredential"], "issuer": "https://as.example.com", "validUntil": "2026-09-29T01:00:00Z", "credentialSubject": { "id": "https://as.example.com/users/alice" }, "iss": "https://as.example.com", "sub": "https://as.example.com/users/alice", "aud": "https://tools.example.com", "client_id": "agent-7f3a", "scope": "files:read", "iat": 1790640000, "exp": 1790643600, "jti": "urn:uuid:3b1c9f2e-7a41-4d0e-9c55-1f0a2b6d8e71", "id": "urn:uuid:3b1c9f2e-7a41-4d0e-9c55-1f0a2b6d8e71", "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" } } Presentation to the resource server: POST /mcp HTTP/1.1 Host: tools.example.com Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImN0... DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0... Appendix B. 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 [OpenID4VP], to be defined elsewhere. * Presentation to a Verifier that the authorization server cannot name as an audience, such as an [OpenID4VP] verifier known only by a client identifier (Section 4.2.1). Lee Expires 4 April 2027 [Page 19] Internet-Draft Access Tokens as VCs October 2026 Appendix C. Document History -03 * @context: a Token carries claims that the Verifiable Credentials context does not define, and now has to declare that as [VC-DATA-MODEL-2.0] 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 (Section 3.2.1). * 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 [RFC9068] 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. Lee Expires 4 April 2027 [Page 20] Internet-Draft Access Tokens as VCs October 2026 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 Section 3.3. Ashwin Ambekar pointed the author to EPOP. Errors and remaining disagreements are the author's own. Author's Address Su-hyeon Forten Lee Email: nine01223@naver.com Lee Expires 4 April 2027 [Page 21]