]>

nine01223@naver.com

Security Web Authorization Protocol DPoP credential proof of possession resource server AI agents 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. Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at .

Introduction 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 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 . 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 defines an MCP server as an OAuth 2.1 resource server, and the Agent2Agent protocol 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. 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 (). 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.

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. 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. 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. 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. A credential conforming to can be used under this document when presented without disclosures ().

Applicability Presentation protocols such as 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. 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 , and vice versa. Profiles that require audience-restricted tokens, such as , can use this document with credentials that carry an aud claim ().

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 (). 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 .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. 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 or identity provider Issuer Holder Client Holder (Wallet) Verifier Resource Server Verifier Issuer, Holder and Verifier are as defined in . In this document the Verifier is always a Resource Server as defined in , and the Holder is always a Client as defined in . DPoP Proof is as defined in . An OpenID Connect Relying Party corresponds to the Client in this table, not to the Verifier.

Credential:

An issuer-signed JWT that satisfies .

Overview

| Holder | +--------+ | (Client) | | +----------+ | 4. issuer keys, status list | v | 2. sign +------------+ | proof | Verifier | 3. Authorization: DPoP | | (Resource | <------------------------------------------+ | Server) | DPoP: +------------+ ]]>

The Issuer issues a Credential whose cnf claim confirms the Holder's key. For each request, the Holder signs a DPoP proof over the request and the hash of the Credential. The Holder sends the Credential in the Authorization header with the DPoP scheme and the proof in the DPoP header. 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.

Credential Requirements A Credential is a JWT signed with an asymmetric algorithm. The following requirements apply to its payload. Claim Requirement Description iss REQUIRED Identifies the Issuer. sub REQUIRED Identifies the principal the claims are about. exp REQUIRED   cnf REQUIRED Confirmation claim per . The jwk member is RECOMMENDED; the jkt member of MAY be used. See . status RECOMMENDED Status information per . aud OPTIONAL If present, restricts the set of Resource Servers that may accept the Credential (). It does not identify the target of an individual request. iat, nbf, jti OPTIONAL As in . 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 can be used as a Credential only when its issuer-signed JWT, carrying cnf, is sent without disclosures.

Presentation To present a Credential, the Holder creates a DPoP proof JWT as defined in , 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 . nonce: REQUIRED if the Resource Server has provided a DPoP-Nonce (). ath: REQUIRED, computed as defined in . This document profiles the DPoP authorization scheme of as follows: the Credential takes the place that the access token occupies in . Consequently ath is the hash of the Credential value, and the way it is computed does not change. The Holder sends:

DPoP: ]]>

Since makes ath REQUIRED for resource requests, this section is the client behavior of with the Credential in place of the access token.

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 and , with the Credential as the token value in the ath calculation as specified in . Steps 5 through 7 are specific to this document. Check that a DPoP header is present and contains exactly one well-formed JWT. Verify the DPoP proof's signature, typ, htm, htu, iat freshness, jti uniqueness and, if required, nonce, as in . Compute the SHA-256 hash of the US-ASCII bytes of the Credential as received and check that it equals the proof's ath. Check that the DPoP proof's public key matches the key confirmed in the Credential's cnf (). Verify the Credential's signature with a key of its iss, applying the algorithm restrictions of . The Verifier MUST reject a Credential whose iss it does not trust (). Check exp, nbf and, if present, aud (). If the Credential carries a status claim, obtain and check the status as defined in . The Verifier MUST reject a Credential whose status is invalid. If any step fails, the Resource Server responds as in with WWW-Authenticate: DPoP and an appropriate error code. Resource Servers SHOULD provide DPoP-Nonce values as described in to bound the replay window of proofs. What this document adds to resource server validation under is steps 5 through 7, in particular the acceptance of Credentials without aud and the status check.

Matching the Confirmation Key confirms the key with a JWK thumbprint in cnf.jkt, while and use cnf.jwk. To interoperate with both, the Verifier proceeds as follows: If cnf contains jkt, compare it with the JWK SHA-256 thumbprint 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.

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

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. 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. 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 (). 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.

Security Considerations

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 , by htu, htm, jti uniqueness and a server-provided nonce. Verifiers MUST enforce jti uniqueness at least for the accepted iat window.

Absence of an Issuer Audience Specifications such as 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.

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.

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 (). The Credential travels in an HTTP header and can appear in server access logs and in proxies that log headers. Deployments MUST use TLS and SHOULD configure intermediaries not to log the Authorization header.

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 , and MUST reject a Credential whose iss is not trusted even if its signature is valid.

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.

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 . An issuer-signed JWT is correlatable across Verifiers by its signature value. Deployments that need unlinkability should issue batches of single-use Credentials.

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 .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. MATTR Bundesdruckerei SPRIND This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. Defakto Security Zscaler This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture and associated protocols. OpenID Foundation OpenID Foundation Model Context Protocol A2A Project

Comparison with OpenID for Verifiable Presentations and this document address different situations and do not compete.   OpenID4VP This document Initiator Verifier sends an authorization request Holder sends an HTTP request Holder Wallet, usually with a person present Any software holding the key Transport Redirects, response_uri, DC API Two HTTP header fields Presentation query DCQL None; the whole Credential is sent Selective disclosure Supported Out of scope Key binding Key Binding JWT DPoP proof Verifier implementation OpenID4VP verifier DPoP-capable resource server

Issuing Credentials from an OpenID Provider An OpenID Provider 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. Such a token is not an ID Token and MUST NOT be labeled or accepted as one. Its typ follows .

Future Work: Selective Disclosure This document intentionally covers only the submission of a whole Credential. When the Credential is an SD-JWT 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 and the sd_hash of 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 , or is signaled per request through a WWW-Authenticate challenge () is a separate design problem, as is the relationship with the key binding requirements of . This document leaves that problem open for a separate document.

Acknowledgments The structure of this mechanism follows the pattern established by and the WIMSE workload token specifications.