Selective Disclosure for JWT Access Tokens Without Changing the Token

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

Section 2.2.2 of [RFC9068] notes that authorization servers commonly put resource owner attributes in JWT access tokens. A token that carries such attributes by value exposes them wherever the token goes: in token stores and logs, in every resource server it names, and in any place it is forwarded. Encrypting the token [RFC7516] hides the values but also stops any party without the key from validating it.¶

Issuing a separate minimal token per resource server [RFC8707], or an opaque token that a gateway exchanges for an internal JWT, both answer this by multiplying tokens or by adding an exchange. Selective disclosure [RFC9901] instead separates the two inside one token: the token carries only digests, and the holder presents the values it chooses, per request and per resource server, as an agent calling several resource servers on a user's behalf does. The holder, here the client, does receive every value; where the client itself must not see them, encryption remains the only answer. This document applies it to the [RFC9068] token with the token in the Authorization header unchanged, so that existing infrastructure processes it as before. The Disclosures and the Key Binding JWT travel in separate HTTP fields, as the DPoP proof does in [RFC9449]; those fields are visible to intermediaries, and what the profile protects is the token, not the request (Section 6).¶

This profile covers access tokens presented to a resource server over HTTP. It defines no credential format; [I-D.ietf-oauth-sd-jwt-vc] covers that case.¶

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

"Issuer-signed JWT", "Disclosure", "Key Binding JWT" (KB-JWT), "SD-JWT" and "SD-JWT+KB" are as defined in [RFC9901]. "Token" means an Issuer-signed JWT that satisfies Section 3.¶

3. Token Format

A Token is a JWT access token [RFC9068] whose payload MAY contain, at the top level only, the _sd and _sd_alg claims of Section 4 of [RFC9901]; the ... array elements, nested _sd claims and the recursive Disclosures of Section 4.2.6 of [RFC9901] MUST NOT be used. Every Disclosure then names a top-level claim and stands on its own. The header is that of Section 2.1 of [RFC9068], including typ at+jwt. Section 9.11 of [RFC9901] recommends a distinct typ for SD-JWT profiles; this profile keeps the [RFC9068] value because Section 4 of [RFC9068] requires resource servers to reject any other, and because keeping it is what leaves existing infrastructure unchanged. What Section 9.11 of [RFC9901] guards against is a JWT being taken for another kind; a recipient unaware of this profile taking a Token for an access token is the intended behavior. A recipient recognizes a selectively disclosable Token by the presence of _sd in its payload, which it sees once it has validated the Token as any JWT access token.¶

The following claims, with their contents, MUST be in the clear and MUST NOT be selectively disclosable: iss, exp, aud, sub, client_id, iat, jti, cnf, and scope and nbf when present. These are the claims that the processing defined by [RFC9068], [RFC9449] and this profile depends on, and the set satisfies Section 9.7 of [RFC9901]. The same applies to any claim whose absence would widen what the Token permits, such as act [RFC8693] with everything nested in it; a resource server MUST NOT read an undisclosed claim as permission. Any other top-level claim MAY be selectively disclosable. A Token with no selectively disclosable claim is an ordinary [RFC9068] token.¶

4. Token Response

Whenever a token response [RFC6749] delivers a Token that has selectively disclosable claims, the authorization server MUST include a disclosures parameter whose value is a JSON array of the Disclosure strings issued with, and committed to by digest in, that Token. This holds for a refresh as for the initial issuance, and Disclosures are used only with the Token they were returned with. They are returned apart from access_token so that its value stays a JWT that recipients unaware of this profile can parse.¶

A client that does not implement this profile ignores the parameter, as Section 5.1 of [RFC6749] provides for parameters it does not understand, and presents the Token alone; the resource server then sees only the cleartext claims. An authorization server therefore issues a selectively disclosable Token only to a client it knows to implement this profile; how it knows is outside this document.¶

This associates the Disclosures with the Token on the client side; the cryptographic binding remains the digests in the Token. The client MUST NOT inspect the Token (Section 6 of [RFC9068]) and need not: each Disclosure carries its claim name and value (Section 4.2 of [RFC9901]), so the client selects by claim name among those it received with the Token. It does not perform the Holder processing of Section 7.2 of [RFC9901]; the Token is its own authorization server's, presented opaquely as any access token is.¶

5. Presentation

6. Security Considerations

This profile invites Tokens to be stored and logged as less sensitive than before. A bearer Token would turn every such place into a credential leak, which is why Tokens under this profile MUST be DPoP-bound [RFC9449]: only the holder of the key can use one. The KB-JWT does not replace DPoP here, because intermediaries do not verify it. [RFC8725] applies to the Token, the KB-JWT and the DPoP proof.¶

This profile protects the Token, not the request. An intermediary that can read the request can read SD-JWT-Disclosures; confidentiality from such a party is provided by the transport, as Section 10.3 of [RFC9901] notes, and not by this profile. A deployment that needs it beyond the transport could carry each Disclosure as a JWE [RFC7516] for the resource server, which decrypts it before reassembly; this is left to future work. What the profile ensures is that the Token itself, when stored, logged, introspected or forwarded, does not contain the selectively disclosable values; those travel only in the Disclosures.¶

An intermediary can also remove SD-JWT-Disclosures or members of it. Only a KB-JWT protects the set of Disclosures (Section 9.10 of [RFC9901]); without one, the resource server cannot distinguish a client that disclosed nothing from a field that was removed, so a resource server behind intermediaries SHOULD require a KB-JWT. Disclosures cannot be forged or substituted, since each is committed to by a digest in the Token and Section 7.1 of [RFC9901] rejects any that is not.¶

The two fields carry the values this profile keeps out of the Token. They MUST be handled like the Authorization field: excluded from access logs, traces, request dumps, monitoring and CDN logs, and from any shared cache (Section 10.2 of [RFC9901]). Infrastructure unaware of this profile will not do so, since logging configurations typically redact fields by name; this is the reason for the rule in Section 5.2 that Disclosures go only to resource servers known to implement the profile.¶

7. Privacy Considerations

This profile hides values from the Token, not from the client, which receives every Disclosure and SHOULD store them no longer than the Token (Section 10.2 of [RFC9901]). It offers none of the unlinkability discussed in Section 10.1 of [RFC9901]: the Token's jti, sub and digests are the same in every request. Where a pairwise sub is used (Section 6 of [RFC9068]), it and decoy digests (Section 4.2.5 of [RFC9901]) limit what a resource server learns beyond what is disclosed to it.¶

8. IANA Considerations

This document requests registration of SD-JWT-Disclosures and SD-JWT-Key-Binding as permanent entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" [RFC9110], with Section 5.1 of this document as the reference, and of disclosures in the "OAuth Parameters" registry [RFC6749] for use in token responses, described as "JSON array of the SD-JWT Disclosures issued with the access token in the same response", with Section 4 as the reference. No JWT claims or header parameters are registered.¶

Appendix A. Example

Token payload with email and name selectively disclosable (digests and Disclosures below are placeholders):¶

{
  "iss": "https://as.example.com",
  "sub": "https://as.example.com/users/9f1c2d",
  "aud": "https://api.example.com",
  "client_id": "agent-7f3a",
  "scope": "files:read",
  "iat": 1790640000,
  "exp": 1790643600,
  "jti": "urn:uuid:3b1c9f2e-7a41-4d0e-9c55-1f0a2b6d8e71",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "_sd": [
    "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
    "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE"
  ],
  "_sd_alg": "sha-256"
}

Token response delivering it:¶

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZ...",
  "token_type": "DPoP",
  "expires_in": 3600,
  "disclosures": [
    "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWls...",
    "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm5hbWUi..."
  ]
}

Request disclosing email and withholding name:¶

GET /files HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZ...
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0...
SD-JWT-Disclosures: "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWls..."
SD-JWT-Key-Binding: "eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.eyJu..."

A gateway in front of api.example.com validates the first two headers as for any DPoP-bound access token. The Token it validates, stores or logs as a token carries the digest of the email address, not the address; the address is in the SD-JWT-Disclosures field, which the gateway forwards without processing.¶

Appendix B. Open Issues

This section is to be removed before publishing as an RFC.¶

• Whether the KB-JWT is redundant beside DPoP. An alternative is a claim in the DPoP proof carrying the hash of the reassembled SD-JWT, which binds the disclosed set to the request with one signature and no nonce. Whether Section 4.2 of [RFC9449] permits additional claims has to be settled first.¶
• Whether keeping typ at+jwt is acceptable against Section 9.11 of [RFC9901].¶
• How a resource server states that it implements this profile and which Disclosures it needs (its metadata, or a WWW-Authenticate challenge; no existing error code fits "valid Token, required claim not disclosed"), and how a client states to the authorization server that it implements it (see Section 5.2).¶

Author's Address