Confirmation Response Parameter for OAuth 2.0 Token Exchange

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

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 20 January 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

OAuth 2.0 Token Exchange [RFC8693] defines a protocol for exchanging one security token for another. The Token Exchange request can convey inputs that trigger the authorization server to issue a sender-constrained token: a DPoP proof [RFC9449] in the request header, a mutual-TLS client certificate [RFC8705], or a future sender-constraint method.¶

When the authorization server applies sender-constraining to the issued token, the primary signal to the client is the cnf claim ([RFC7800]) inside the issued token. For JWT-formatted tokens the client can read, this works. The signal fails in three deployment shapes:¶

1. Opaque tokens. The issued token is an unstructured string and the client cannot read any claim from it.¶

2. Encrypted tokens. The issued token is a JWE encrypted to a downstream consumer (such as a Resource Authorization Server [I-D.ietf-oauth-identity-assertion-authz-grant]), and the client does not hold the decryption key.¶

3. token_type is "N_A". Section 2.2.1 of [RFC8693] requires the token_type response parameter to be N_A when the issued token is not used directly as an access token. Existing sender-constraint methods, such as DPoP [RFC9449], rely on token_type carrying the binding method (token_type: "DPoP"), and that signal is unavailable here.¶

Without a protocol-level signal in the Token Exchange response, an authorization server that silently fails to apply sender-constraining (by error or by misbehavior) can downgrade the issued token without the client noticing.¶

This document closes the gap by adding an optional cnf parameter to the Token Exchange response. The parameter carries the same confirmation structure that [RFC7800] defines for the cnf claim. The client verifies the response cnf against the key or certificate it provided in the request, the same way it would verify the in-token cnf claim, and treats absence (when sender-constraining was expected) as a downgrade.¶

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 [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms "access token," "authorization server," "client," "resource server," and "token endpoint" defined by OAuth 2.0 [RFC6749]. The "issued token" is the token returned in the access_token member of a Token Exchange response (Section 2.2.1 of [RFC8693]).¶

A "confirmation method" is a sender-constraint binding mechanism registered in the "JWT Confirmation Methods" registry established by [RFC7800], such as the JWK SHA-256 Thumbprint (jkt) defined in [RFC9449] and the X.509 Certificate SHA-256 Thumbprint (x5t#S256) defined in [RFC8705].¶

3. Confirmation Response Parameter

This specification adds the following optional parameter to the Token Exchange response defined in Section 2.2 of [RFC8693]:¶

cnf:

OPTIONAL. A JSON object containing one or more confirmation members as defined in Section 3 of [RFC7800]. The value identifies the confirmation method that the authorization server applied to the issued token, allowing the client to verify the sender-constraint binding without inspecting the issued token.¶

The parameter's structure and member names are those of the cnf JWT claim [RFC7800]; this document defines no new confirmation methods. Conveying a token's confirmation outside the token follows the precedent of token introspection (Section 3.2 of [RFC8705]; Section 6.2 of [RFC9449]).¶

The parameter describes only the issued token, not any refresh_token returned in the same response. It is defined only for Token Exchange responses; its use with other grant types is out of scope. Clients that do not support this specification ignore unrecognized response members (Section 5.1 of [RFC6749]).¶

4. Authorization Server Behavior

When the authorization server applies sender-constraining to the token it issues in response to a Token Exchange request:¶

• It MUST include the cnf parameter in the Token Exchange response.¶

• The confirmation member name and value MUST identify the confirmation method actually applied to the issued token.¶

• The cnf parameter SHOULD contain exactly one confirmation member and MUST NOT contain a member identifying a binding that was not applied.¶

When the authorization server does not apply sender-constraining to the issued token, it MUST NOT include the cnf parameter in the response.¶

When the authorization server receives sender-constraint input (for example a DPoP proof header or a mutual-TLS client certificate) but does not apply the binding, it SHOULD reject the request with an error response (Section 2.2.2 of [RFC8693]) rather than issue an unbound token. If it issues the token anyway, omitting cnf signals the downgrade to the client.¶

5. Client Behavior

A client that provides sender-constraint input in a Token Exchange request (for example a DPoP proof or a mutual-TLS client certificate) MUST validate the Token Exchange response as follows:¶

1. The client MUST treat a cnf value that is not a JSON object, or is an empty JSON object, as if cnf were absent.¶

2. If the response does not contain a cnf parameter (or contains one treated as absent per the previous rule), the client MUST treat the issued token as not sender-constrained. A client that requires sender-constraining MUST reject the response and not use the issued token.¶

3. Otherwise, the client MUST verify that cnf contains the confirmation member corresponding to its sender-constraint input and that the member's value matches that input:¶

   • For a DPoP proof: a jkt member whose value equals the JWK SHA-256 Thumbprint ([RFC7638]) of the public key in the DPoP proof JWT.¶

   • For a mutual-TLS client certificate: an x5t#S256 member whose value equals the base64url-encoded SHA-256 hash of the certificate's DER encoding ([RFC8705]).¶

   If the corresponding member is absent or its value does not match, the client MUST reject the response and not use the issued token. The client MUST ignore any other confirmation members.¶

Absence of cnf indicates either a downgrade (intentional or otherwise) or an authorization server that does not implement this specification; the rules above treat both the same.¶

A client that did not provide sender-constraint input but receives a response containing cnf holds a token bound to the identified key or certificate. If the client holds that key or certificate (for example, the certificate it used for mutual-TLS client authentication), it MAY use the issued token and SHOULD satisfy the confirmation method when presenting it. Otherwise the issued token is unusable, and the client SHOULD treat the response as an error.¶

6. Examples

The examples in this section illustrate the cnf response parameter for different confirmation methods. Extra line breaks in request bodies and header fields are for display purposes only.¶

POST /oauth2/token HTTP/1.1
Host: as.example
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&requested_token_type=
 urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid-jag
&audience=https%3A%2F%2Fras.example%2F
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=
 urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJ0eXAiOi...",
  "token_type": "N_A",
  "expires_in": 300,
  "cnf": {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "issued_token_type":
    "urn:ietf:params:oauth:token-type:access_token",
  "access_token": "mF_9.B5f-4.1JqM",
  "token_type": "Bearer",
  "expires_in": 3600,
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJ0eXAiOi...",
  "token_type": "N_A",
  "expires_in": 300
}

7. Security Considerations

8. IANA Considerations

IANA is requested to register the following parameter in the "OAuth Parameters" registry [IANA.oauth-parameters] established by [RFC6749]:¶

• Parameter Name: cnf¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

• Specification Document(s): Section 3 of this document¶

9. References

Acknowledgments

The gap addressed by this specification was identified during work on "OAuth Identity Assertion Authorization Grant" [I-D.ietf-oauth-identity-assertion-authz-grant], where the combination of token_type: "N_A" (mandated by [RFC8693]) and optional ID-JAG encryption removed the existing client-side path for detecting sender-constraint downgrade.¶

Document History

-00¶

• Initial draft.¶

Author's Address