Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP
draft-lee-oauth-dpop-credential-presentation-00
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Su-hyeon Forten Lee | ||
| Last updated | 2026-09-28 | ||
| RFC stream | (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-00
Web Authorization Protocol S. F. Lee
Internet-Draft 28 September 2026
Intended status: Standards Track
Expires: 1 April 2027
Presenting Issuer-Signed JWT Credentials to Resource Servers with DPoP
draft-lee-oauth-dpop-credential-presentation-00
Abstract
This document defines how a Holder presents an issuer-signed JWT
credential directly to an HTTP resource server using OAuth 2.0
Demonstrating Proof of Possession (DPoP). The credential is carried
in the Authorization header with the DPoP scheme, and possession of
the key confirmed in the credential's cnf claim is demonstrated with
a DPoP proof.
The wire format is the same as that of a DPoP-bound access token.
What this document adds is a model rather than a mechanism: the
credential is issued by an authorization server or identity provider
that the resource server already trusts, the credential may carry no
issuer-defined audience, and the resource server checks the
credential's status. Neither an authorization server nor a
presentation protocol such as OpenID for Verifiable Presentations is
involved between issuance and use.
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.
Lee Expires 1 April 2027 [Page 1]
Internet-Draft DPoP Credential Presentation September 2026
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/.
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 1 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. Relationship to Existing Work . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Credential Requirements . . . . . . . . . . . . . . . . . . . 7
5. Presentation . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Matching the Confirmation Key . . . . . . . . . . . . . . 10
6.2. Audience and Request Binding . . . . . . . . . . . . . . 10
6.3. Issuer Trust Model . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Token Theft and Replay . . . . . . . . . . . . . . . . . 12
7.2. Absence of an Issuer Audience . . . . . . . . . . . . . . 12
7.3. Long-Lived Credentials . . . . . . . . . . . . . . . . . 12
7.4. Exposure of the Whole Credential . . . . . . . . . . . . 12
7.5. Issuer Trust . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Confusion with Access Tokens . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
Lee Expires 1 April 2027 [Page 2]
Internet-Draft DPoP Credential Presentation September 2026
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Comparison with OpenID for Verifiable
Presentations . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Issuing Credentials from an OpenID Provider . . . . 16
Appendix C. Future Work: Selective Disclosure . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
An issuer-signed JWT credential is issued once and presented many
times to verifiers that were not known at issuance time. Credential
formats are mature, but the way a Holder hands a credential to a
verifier is specified only for interactive, browser- or wallet-
mediated flows, namely OpenID for Verifiable Presentations
[OpenID4VP]. OpenID4VP requires the verifier to operate an
authorization request, a presentation query language and a response
endpoint. That is proportionate when a person opens a wallet, but
excessive when software calls an HTTP API.
OAuth 2.0 resource servers already have a complete mechanism for
accepting a key-bound token in an HTTP request: DPoP [RFC9449]. A
DPoP proof is a statement, signed by the holder of the key confirmed
in the token, that "this token is being presented for this request".
That is the same structure that credential specifications call a
presentation. The resource server verifies the token with the
issuer's key, verifies that the DPoP proof is signed by the key
confirmed in the token's cnf claim, and verifies that the proof is
bound to the request. An OAuth resource server is, in effect,
already a presentation verifier.
The gap is most visible for AI agents. Agents are software that call
the HTTP APIs of tools and of other agents on behalf of people, and
their ecosystem builds authorization on OAuth. The Model Context
Protocol authorization specification [MCP.Authorization] defines an
MCP server as an OAuth 2.1 resource server, and the Agent2Agent
protocol [A2A] lets an Agent Card declare OAuth 2.0 and OpenID
Connect security schemes. When these agents need to prove, with a
credential, on whose behalf and in what capacity they are calling,
there is no standardized presentation method that reuses the OAuth
resource request processing model. This document defines one. An
agent can present a credential with the OAuth client stack it already
uses, and a tool server can verify it with the OAuth resource server
stack it already has.
Lee Expires 1 April 2027 [Page 3]
Internet-Draft DPoP Credential Presentation September 2026
This document defines the presentation of an issuer-signed JWT
credential with two HTTP header fields, Authorization: DPoP and DPoP,
and adds three rules to the verification that a DPoP-capable resource
server already performs:
* The verifier trusts the credential's Issuer. In this document the
Issuer is an authorization server or identity provider that the
verifier already trusts, so the trust configuration is the same as
in current DPoP deployments (Section 6.3).
* The credential may carry no issuer-defined audience. In that case
it can be submitted to any verifier that trusts its Issuer, and
the DPoP proof binds proof of possession to the request in which
it is submitted.
* A credential may live longer than an access token, so the verifier
checks the status information the credential refers to.
A credential presented under this document is the same on the wire as
a DPoP-bound access token. An implementation can support this
document by treating the presented credential as the DPoP-bound token
and applying the additional validation rules defined here.
1.1. Relationship to Existing Work
Two IETF working group documents already use the same structural
pattern of a key-confirmed JWT plus a per-request proof, and this
document is deliberately aligned with them.
* [I-D.ietf-oauth-attestation-based-client-auth] presents a key-
confirmed JWT together with a DPoP proof. Its purpose is client
authentication: "what is this OAuth client?". The purpose of this
document is credential presentation: "what credential does this
Holder possess?". The structure is the same; the question
answered is different.
* [I-D.ietf-wimse-wpt] separates a reusable workload identity token
from a proof bound to the request. This document follows the same
separation, but reuses DPoP instead of defining new header fields.
The boundaries with two other documents are as follows.
* [RFC9068] requires aud in JWT access tokens, so a credential under
this document is not an access token under that profile. The two
documents use the same wire format with different issuance models.
Lee Expires 1 April 2027 [Page 4]
Internet-Draft DPoP Credential Presentation September 2026
* A credential conforming to [I-D.ietf-oauth-sd-jwt-vc] can be used
under this document when presented without disclosures
(Section 4).
1.2. Applicability
Presentation protocols such as [OpenID4VP] exist to solve a
negotiation problem. The Verifier does not know in advance which
credentials the Holder has, the Holder does not know which claims the
Verifier needs, and a person may have to be asked for consent in
between. An authorization request, a query language such as DCQL and
a response endpoint are the cost of that negotiation.
Many deployments have no such problem: AI agents calling tool
servers, agents calling other agents, and services calling partner
APIs. The Holder is an OAuth client that already knows the Resource
Server it calls and already holds a credential that the Resource
Server accepts. It can submit the credential, whole and
unilaterally, with the request, as it would submit an access token.
Just as an OAuth client decides which scope to request by reading the
resource server's documentation rather than negotiating at runtime,
the choice of credential is made at development time. In this
situation a runtime negotiation protocol adds round trips,
implementation surface and failure modes without adding information.
This document is RECOMMENDED when both of the following hold:
* The Holder is software acting as an OAuth client and submits the
credential without a Verifier-initiated request or user
interaction at presentation time.
* The Resource Server is, or can become, a DPoP-capable OAuth
resource server.
[OpenID4VP] or another Verifier-initiated presentation protocol
SHOULD be used instead when the Verifier must discover which
credentials the Holder has, when the required claims vary per request
and only a subset is to be disclosed, or when a natural person must
consent at presentation time. The two mechanisms address different
situations and a deployment MAY support both. A Resource Server that
implements this document is not thereby required to implement
[OpenID4VP], and vice versa.
Profiles that require audience-restricted tokens, such as
[MCP.Authorization], can use this document with credentials that
carry an aud claim (Section 6.2).
Lee Expires 1 April 2027 [Page 5]
Internet-Draft DPoP Credential Presentation September 2026
1.3. Scope
This document specifies only the presentation of a single credential,
whole, to an HTTP resource server and its verification. The Issuer
is limited to an authorization server or identity provider that the
verifier already trusts (Section 6.3). Accepting credentials from
external issuers with which the verifier has no prior trust
relationship, selective disclosure, issuance, publication of
credential status, and delegation between holders are out of scope.
For selective disclosure see Appendix C.
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.
This document sits where credential specifications and OAuth
specifications name the same roles differently. The roles correspond
as follows, and this document uses the terms in the first column.
+===============+======================+======================+
| This document | OAuth 2.0 (, ) | OpenID4VP, SD-JWT () |
+===============+======================+======================+
| Issuer | Authorization Server | Issuer |
| | or identity provider | |
+---------------+----------------------+----------------------+
| Holder | Client | Holder (Wallet) |
+---------------+----------------------+----------------------+
| Verifier | Resource Server | Verifier |
+---------------+----------------------+----------------------+
Table 1: Role correspondence
Issuer, Holder and Verifier are as defined in [RFC9901]. In this
document the Verifier is always a Resource Server as defined in
[RFC6749], and the Holder is always a Client as defined in [RFC6749].
DPoP Proof is as defined in [RFC9449]. An OpenID Connect Relying
Party corresponds to the Client in this table, not to the Verifier.
Credential: An issuer-signed JWT that satisfies Section 4.
3. Overview
Lee Expires 1 April 2027 [Page 6]
Internet-Draft DPoP Credential Presentation September 2026
+--------+ 1. issue credential (cnf = Holder key) +----------+
| Issuer | ----------------------------------------> | Holder |
+--------+ | (Client) |
| +----------+
| 4. issuer keys, status list |
v | 2. sign
+------------+ | proof
| Verifier | 3. Authorization: DPoP <credential> |
| (Resource | <------------------------------------------+
| Server) | DPoP: <proof: htu, htm, ath, nonce>
+------------+
Figure 1: Presentation flow
1. The Issuer issues a Credential whose cnf claim confirms the
Holder's key.
2. For each request, the Holder signs a DPoP proof over the request
and the hash of the Credential.
3. The Holder sends the Credential in the Authorization header with
the DPoP scheme and the proof in the DPoP header.
4. The Resource Server verifies the Issuer's signature, the DPoP
proof, the key binding between them, and the Credential's status.
There is no round trip to the Issuer or to an authorization
server on the request path.
4. Credential Requirements
A Credential is a JWT [RFC7519] signed with an asymmetric algorithm.
The following requirements apply to its payload.
Lee Expires 1 April 2027 [Page 7]
Internet-Draft DPoP Credential Presentation September 2026
+========+=============+===========================================+
| Claim | Requirement | Description |
+========+=============+===========================================+
| iss | REQUIRED | Identifies the Issuer. |
+--------+-------------+-------------------------------------------+
| sub | REQUIRED | Identifies the principal the claims are |
| | | about. |
+--------+-------------+-------------------------------------------+
| exp | REQUIRED | |
+--------+-------------+-------------------------------------------+
| cnf | REQUIRED | Confirmation claim per [RFC7800]. The |
| | | jwk member is RECOMMENDED; the jkt member |
| | | of Section 6.1 of [RFC9449] MAY be used. |
| | | See Section 6.1. |
+--------+-------------+-------------------------------------------+
| status | RECOMMENDED | Status information per |
| | | [I-D.ietf-oauth-status-list]. |
+--------+-------------+-------------------------------------------+
| aud | OPTIONAL | If present, restricts the set of Resource |
| | | Servers that may accept the Credential |
| | | (Section 6.2). It does not identify the |
| | | target of an individual request. |
+--------+-------------+-------------------------------------------+
| iat, | OPTIONAL | As in [RFC7519]. |
| nbf, | | |
| jti | | |
+--------+-------------+-------------------------------------------+
Table 2: Credential claims
status is not REQUIRED because some Credentials are intentionally
non-revocable, or short-lived enough that revocation is not needed.
Other claims MAY be present. The Verifier receives the whole
Credential, so there is no step in which the Holder selects claims to
disclose. Issuers SHOULD include only claims that may be seen by
every Verifier to which the Credential may be presented.
The typ header parameter MUST be present and MUST NOT be at+jwt or a
value used for ID Tokens. Deployments MUST define the acceptable typ
value or values for each trusted Issuer.
This document does not define the SD-JWT presentation syntax. An SD-
JWT VC [I-D.ietf-oauth-sd-jwt-vc] can be used as a Credential only
when its issuer-signed JWT, carrying cnf, is sent without
disclosures.
Lee Expires 1 April 2027 [Page 8]
Internet-Draft DPoP Credential Presentation September 2026
5. Presentation
To present a Credential, the Holder creates a DPoP proof JWT as
defined in Section 4.2 of [RFC9449], signed with the private key
corresponding to the Credential's cnf, with the following claims:
* htm and htu: the HTTP method and target URI of the request.
* iat and jti: as in [RFC9449].
* nonce: REQUIRED if the Resource Server has provided a DPoP-Nonce
(Section 9 of [RFC9449]).
* ath: REQUIRED, computed as defined in Section 4.2 of [RFC9449].
This document profiles the DPoP authorization scheme of [RFC9449] as
follows: the Credential takes the place that the access token
occupies in [RFC9449]. Consequently ath is the hash of the
Credential value, and the way it is computed does not change.
The Holder sends:
Authorization: DPoP <Credential>
DPoP: <DPoP proof JWT>
Since [RFC9449] makes ath REQUIRED for resource requests, this
section is the client behavior of Section 7.1 of [RFC9449] with the
Credential in place of the access token.
6. Verification
A Resource Server that receives a request with the DPoP authorization
scheme performs the following steps. Steps 1 through 4 apply the
corresponding requirements of Section 7.1 of [RFC9449] and
Section 4.3 of [RFC9449], with the Credential as the token value in
the ath calculation as specified in Section 5. Steps 5 through 7 are
specific to this document.
1. Check that a DPoP header is present and contains exactly one
well-formed JWT.
2. Verify the DPoP proof's signature, typ, htm, htu, iat freshness,
jti uniqueness and, if required, nonce, as in Section 4.3 of
[RFC9449].
3. Compute the SHA-256 hash of the US-ASCII bytes of the Credential
as received and check that it equals the proof's ath.
Lee Expires 1 April 2027 [Page 9]
Internet-Draft DPoP Credential Presentation September 2026
4. Check that the DPoP proof's public key matches the key confirmed
in the Credential's cnf (Section 6.1).
5. Verify the Credential's signature with a key of its iss, applying
the algorithm restrictions of [RFC8725]. The Verifier MUST
reject a Credential whose iss it does not trust (Section 6.3).
6. Check exp, nbf and, if present, aud (Section 6.2).
7. If the Credential carries a status claim, obtain and check the
status as defined in [I-D.ietf-oauth-status-list]. The Verifier
MUST reject a Credential whose status is invalid.
If any step fails, the Resource Server responds as in Section 7.1 of
[RFC9449] with WWW-Authenticate: DPoP and an appropriate error code.
Resource Servers SHOULD provide DPoP-Nonce values as described in
Section 9 of [RFC9449] to bound the replay window of proofs.
What this document adds to resource server validation under [RFC9449]
is steps 5 through 7, in particular the acceptance of Credentials
without aud and the status check.
6.1. Matching the Confirmation Key
[RFC9449] confirms the key with a JWK thumbprint in cnf.jkt, while
[RFC9901] and [I-D.ietf-oauth-sd-jwt-vc] use cnf.jwk. To
interoperate with both, the Verifier proceeds as follows:
* If cnf contains jkt, compare it with the JWK SHA-256 thumbprint
[RFC7638] of the jwk header of the DPoP proof.
* If cnf contains jwk, compute the JWK SHA-256 thumbprint of that
key and compare it with the thumbprint of the jwk header of the
DPoP proof.
The keys match if and only if the thumbprints are equal. Issuers MAY
include both members; if both are present they MUST identify the same
key.
6.2. Audience and Request Binding
The only audience is the Credential's aud, and it is set by the
Issuer. The Holder does not set an audience; it only chooses the
Resource Server to which it sends the Credential. The two MUST NOT
be confused.
Lee Expires 1 April 2027 [Page 10]
Internet-Draft DPoP Credential Presentation September 2026
* The DPoP proof's htu and htm identify the request for which the
Credential is presented. The Verifier accepts the proof only if
htu matches the request it received. This is request-level proof-
of-possession binding and does not replace audience validation.
* The Credential's aud, if present, is set by the Issuer at issuance
and restricts where the Credential may be used at all. The
Verifier MUST reject a Credential whose aud does not contain the
Verifier's configured identifier. Which identifier a Verifier
uses is a matter of deployment configuration. Issuers SHOULD omit
aud unless such a restriction is intended, because its presence
turns a reusable credential into a token for a fixed set of
recipients.
6.3. Issuer Trust Model
In this document the Issuer is a party that the Verifier already
trusts. It takes one of two forms, and in neither does the Verifier
acquire a new trust relationship.
1. The Issuer is the Verifier's authorization server. The
organization's authorization server issues Credentials under this
document alongside, or instead of, access tokens. The Verifier's
trust configuration is the same as in current DPoP deployments;
what changes is the lifetime of the issued token and the handling
of aud and status.
2. The Issuer is an identity provider that the Verifier already
trusts. If the organization's OpenID Provider already publishes
keys for single sign-on and the Verifier already accepts them,
the same identity provider becomes the Issuer of the Credential
(Appendix B). Its issuance logic gains one additional token
type.
In both cases the verification procedure is the same; only the
trusted iss in step 5 differs. Because the Issuer and the Verifier
trust each other already, the claim vocabulary of the Credential and
the provision of status are agreed between them.
Accepting Credentials from an external party with which the Verifier
has no prior trust relationship is out of scope for this document.
That case requires establishing trust through an allow-list or a
trust framework and agreeing how the Verifier interprets each
Issuer's claim vocabulary, which is a separate problem. The
verification procedure of this document would still apply, but this
document makes no provision for establishing that trust.
Lee Expires 1 April 2027 [Page 11]
Internet-Draft DPoP Credential Presentation September 2026
7. Security Considerations
7.1. Token Theft and Replay
A Credential without a DPoP proof is useless to an attacker who does
not hold the confirmed private key. Replay within a proof's validity
window is limited exactly as in [RFC9449], by htu, htm, jti
uniqueness and a server-provided nonce. Verifiers MUST enforce jti
uniqueness at least for the accepted iat window.
7.2. Absence of an Issuer Audience
Specifications such as [I-D.ietf-wimse-workload-identity-practices]
require aud on JWT credentials, with the aim of preventing reuse
across trust boundaries. A Credential without aud can be presented
to every Resource Server that trusts its Issuer. This document does
not define trust boundaries between Resource Servers. If use must be
restricted to a particular set of Resource Servers, the Issuer MUST
use aud. Protection is layered:
* The Credential is a reusable identity, restricted by aud when
present.
* The DPoP proof is proof of possession for this request.
* The Verifier's authorization policy decides whether access is
allowed. The Verifier MUST NOT infer authorization from the mere
validity of a Credential.
7.3. Long-Lived Credentials
Credentials under this document may live much longer than access
tokens. The role that short access token lifetimes play is taken
here by status. Verifiers MUST check status when present, and MAY
treat the absence of status on a long-lived Credential as grounds for
rejection. Issuers SHOULD provide status information for Credentials
whose lifetime is longer than they are willing to leave unrevocable.
Verifiers MAY cache status lists; the cache lifetime becomes the
delay before a revocation takes effect.
7.4. Exposure of the Whole Credential
The Holder submits the Credential whole, so every claim is visible to
every Verifier. Issuers need to design claims with this in mind, and
use cases in which different Verifiers must see different subsets
need a selective disclosure presentation protocol rather than this
document (Appendix C). The Credential travels in an HTTP header and
can appear in server access logs and in proxies that log headers.
Lee Expires 1 April 2027 [Page 12]
Internet-Draft DPoP Credential Presentation September 2026
Deployments MUST use TLS and SHOULD configure intermediaries not to
log the Authorization header.
7.5. Issuer Trust
A Verifier that accepts any iss whose keys it can fetch is vulnerable
to an attacker who hosts keys and issues a Credential to themselves.
Verifiers MUST accept as Issuers only authorization servers and
identity providers that they already trust, as described in
Section 6.3, and MUST reject a Credential whose iss is not trusted
even if its signature is valid.
7.6. Confusion with Access Tokens
A Credential is the same on the wire as a DPoP-bound access token. A
Resource Server that accepts both MUST distinguish them by iss and
typ. Interpreting an access token issued by an authorization server
as a Credential, or the reverse, would misapply the trust model and
the status check.
8. Privacy Considerations
The Issuer is not contacted at presentation time and does not learn
where or how often a Credential is used, except through status list
retrieval. Verifiers SHOULD cache status lists and MAY fetch them
through the privacy-preserving means discussed in
[I-D.ietf-oauth-status-list]. An issuer-signed JWT is correlatable
across Verifiers by its signature value. Deployments that need
unlinkability should issue batches of single-use Credentials.
9. IANA Considerations
This document has no IANA actions. It defines no new header fields,
claims, media types or error codes, and profiles the use of those
registered by [RFC9449].
10. References
10.1. Normative References
[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>.
Lee Expires 1 April 2027 [Page 13]
Internet-Draft DPoP Credential Presentation September 2026
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[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>.
[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>.
[RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JSON Web Tokens", RFC 9901,
DOI 10.17487/RFC9901, November 2025,
<https://www.rfc-editor.org/rfc/rfc9901>.
10.2. Informative References
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification",
n.d., <https://a2a-protocol.org/latest/specification/>.
Lee Expires 1 April 2027 [Page 14]
Internet-Draft DPoP Credential Presentation September 2026
[I-D.ietf-oauth-attestation-based-client-auth]
Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0
Attestation-Based Client Authentication", Work in
Progress, Internet-Draft, draft-ietf-oauth-attestation-
based-client-auth-11, 3 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
attestation-based-client-auth-11>.
[I-D.ietf-oauth-sd-jwt-vc]
Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
Verifiable Digital Credentials (SD-JWT VC)", Work in
Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-19,
31 August 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-oauth-sd-jwt-vc-19>.
[I-D.ietf-wimse-workload-identity-practices]
Schwenkschuster, A. and Y. Rosomakho, "Workload Identity
Practices", Work in Progress, Internet-Draft, draft-ietf-
wimse-workload-identity-practices-07, 22 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-identity-practices-07>.
[I-D.ietf-wimse-wpt]
Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof
Token", Work in Progress, Internet-Draft, draft-ietf-
wimse-wpt-02, 27 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-02>.
[MCP.Authorization]
Model Context Protocol, "Model Context Protocol
Specification: Authorization", 18 June 2025,
<https://modelcontextprotocol.io/specification/2025-06-
18/basic/authorization>.
[OIDC.Core]
OpenID Foundation, "OpenID Connect Core 1.0", n.d.,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID4VP]
OpenID Foundation, "OpenID for Verifiable Presentations
1.0", n.d., <https://openid.net/specs/openid-4-verifiable-
presentations-1_0.html>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/rfc/rfc6750>.
Lee Expires 1 April 2027 [Page 15]
Internet-Draft DPoP Credential Presentation September 2026
[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>.
[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", RFC 9728,
DOI 10.17487/RFC9728, April 2025,
<https://www.rfc-editor.org/rfc/rfc9728>.
Appendix A. Comparison with OpenID for Verifiable Presentations
[OpenID4VP] and this document address different situations and do not
compete.
+================+=======================+====================+
| | OpenID4VP | This document |
+================+=======================+====================+
| Initiator | Verifier sends an | Holder sends an |
| | authorization request | HTTP request |
+----------------+-----------------------+--------------------+
| Holder | Wallet, usually with | Any software |
| | a person present | holding the key |
+----------------+-----------------------+--------------------+
| Transport | Redirects, | Two HTTP header |
| | response_uri, DC API | fields |
+----------------+-----------------------+--------------------+
| Presentation | DCQL | None; the whole |
| query | | Credential is sent |
+----------------+-----------------------+--------------------+
| Selective | Supported | Out of scope |
| disclosure | | |
+----------------+-----------------------+--------------------+
| Key binding | Key Binding JWT | DPoP proof |
+----------------+-----------------------+--------------------+
| Verifier | OpenID4VP verifier | DPoP-capable |
| implementation | | resource server |
+----------------+-----------------------+--------------------+
Table 3: Positioning
Appendix B. Issuing Credentials from an OpenID Provider
An OpenID Provider [OIDC.Core] already signs JWTs about authenticated
users and publishes its keys. It can act as an Issuer under this
document by issuing a token that differs from an ID Token in three
ways: it carries a cnf claim for a key whose possession the Holder
demonstrated during authentication, it omits the aud that an ID Token
fixes to the requesting client, and it SHOULD carry a status claim.
Lee Expires 1 April 2027 [Page 16]
Internet-Draft DPoP Credential Presentation September 2026
Such a token is not an ID Token and MUST NOT be labeled or accepted
as one. Its typ follows Section 4.
Appendix C. Future Work: Selective Disclosure
This document intentionally covers only the submission of a whole
Credential. When the Credential is an SD-JWT [RFC9901] and the
Holder wants to disclose only some of its disclosures, presenting it
with the same two header fields is technically possible. The ath of
[RFC9449] and the sd_hash of [RFC9901] are both defined as a hash of
the US-ASCII bytes of the presented string, so computing ath over the
presentation string including disclosures would let the DPoP proof
play the role of the Key Binding JWT.
Selective disclosure, however, presupposes that the Holder knows
which claims to disclose, that is, a negotiation with the Verifier.
Whether that negotiation lives in documentation at development time,
is declared in OAuth 2.0 Protected Resource Metadata [RFC9728], or is
signaled per request through a WWW-Authenticate challenge (Section 3
of [RFC6750]) is a separate design problem, as is the relationship
with the key binding requirements of [I-D.ietf-oauth-sd-jwt-vc].
This document leaves that problem open for a separate document.
Acknowledgments
The structure of this mechanism follows the pattern established by
[I-D.ietf-oauth-attestation-based-client-auth] and the WIMSE workload
token specifications.
Author's Address
Su-hyeon Forten Lee
Email: nine01223@naver.com
Lee Expires 1 April 2027 [Page 17]