JWT Access Tokens as W3C Verifiable Credentials
draft-lee-oauth-dpop-credential-presentation-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Su-hyeon Forten Lee | ||
| Last updated | 2026-10-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-oauth-dpop-credential-presentation-03
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[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,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/rfc/rfc8725>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/rfc/rfc9068>.
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, <https://www.rfc-editor.org/rfc/rfc9449>.
[VC-DATA-MODEL-2.0]
W3C, "Verifiable Credentials Data Model v2.0", 15 May
2025, <https://www.w3.org/TR/vc-data-model-2.0/>.
[VC-JOSE-COSE]
W3C, "Securing Verifiable Credentials using JOSE and
COSE", 15 May 2025, <https://www.w3.org/TR/vc-jose-cose/>.
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,
<https://datatracker.ietf.org/doc/html/draft-ambekar-
oauth-epop-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
status-list-21>.
[MCP.Authorization]
Model Context Protocol, "Model Context Protocol
Specification: Authorization", 25 November 2025,
<https://modelcontextprotocol.io/specification/2025-11-
25/basic/authorization>.
[OpenID4VP]
OpenID Foundation, "OpenID for Verifiable Presentations
1.0", n.d., <https://openid.net/specs/openid-4-verifiable-
presentations-1_0.html>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/rfc/rfc8414>.
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,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.
[VC-BITSTRING-STATUS-LIST]
W3C, "Bitstring Status List v1.0", 15 May 2025,
<https://www.w3.org/TR/vc-bitstring-status-list/>.
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]