]>

nine01223@naver.com

Security Web Authorization Protocol access token selective disclosure SD-JWT DPoP This document adds selective disclosure to JWT access tokens without changing the form of the Authorization header or how the token is validated. The RFC 9068 token is sent as today, with some of its claims selectively disclosable as defined by SD-JWT (RFC 9901); the Disclosures and the optional Key Binding JWT travel in two new HTTP fields. A recipient that does not implement this profile ignores the fields and processes the token as an ordinary JWT access token. The token itself then carries no selectively disclosable value, and the holder chooses per request which values to reveal. About This Document Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at .

Introduction 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 hides the values but also stops any party without the key from validating it. Issuing a separate minimal token per resource server , 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 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 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 ; those fields are visible to intermediaries, and what the profile protects is the token, not the request (). This profile covers access tokens presented to a resource server over HTTP. It defines no credential format; covers that case.

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. "Issuer-signed JWT", "Disclosure", "Key Binding JWT" (KB-JWT), "SD-JWT" and "SD-JWT+KB" are as defined in . "Token" means an Issuer-signed JWT that satisfies .

Token Format A Token is a JWT access token whose payload MAY contain, at the top level only, the _sd and _sd_alg claims of ; the ... array elements, nested _sd claims and the recursive Disclosures of MUST NOT be used. Every Disclosure then names a top-level claim and stands on its own. The header is that of , including typ at+jwt. recommends a distinct typ for SD-JWT profiles; this profile keeps the value because requires resource servers to reject any other, and because keeping it is what leaves existing infrastructure unchanged. What 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 , and this profile depends on, and the set satisfies . The same applies to any claim whose absence would widen what the Token permits, such as act 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 token.

Token Response Whenever a token response 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 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 () and need not: each Disclosure carries its claim name and value (), so the client selects by claim name among those it received with the Token. It does not perform the Holder processing of ; the Token is its own authorization server's, presented opaquely as any access token is.

Presentation

HTTP Fields Two Structured Fields are defined.

SD-JWT-Disclosures

A List of Strings, each one Disclosure in its base64url form. Order is significant. The field MAY be split across several field lines, which recipients combine in order as specifies; a field with no members is omitted rather than sent empty.

SD-JWT-Key-Binding

An Item that is a String, one KB-JWT in compact serialization.

The reassembled SD-JWT of a request is the Token, a tilde, and each member of SD-JWT-Disclosures in order, each followed by a tilde: the serialization of and the input to sd_hash (). An absent SD-JWT-Disclosures field means zero Disclosures, and the reassembled SD-JWT is then the Token followed by a tilde. Appending the KB-JWT gives the SD-JWT+KB.

Sending The client sends the Token in the Authorization header with the DPoP scheme and a DPoP proof, as specifies, with nothing attached. In SD-JWT-Disclosures it sends any subset of the Disclosures received with that Token (), each at most once. Which Disclosures a resource server needs, and whether it implements this profile at all, is something the client knows about that resource server, as it knows which scope to request; this profile defines no way to ask, and a client SHOULD NOT send Disclosures to a resource server it does not know to implement it. How it knows is outside this document; the resource server's metadata or the client's registration with the authorization server are natural places. A KB-JWT, if sent, satisfies : sd_hash is computed over the reassembled SD-JWT, aud identifies the resource server by the identifier it expects in the Token's aud, and nonce is the DPoP nonce the resource server provided (). A resource server that requires a KB-JWT therefore provides DPoP nonces.

Receiving A resource server that implements this profile:

1. Validates the Token and the DPoP proof as and specify. This step is unchanged from any DPoP-bound JWT access token and MUST succeed first. The DPoP ath covers the Token alone (), not the Disclosures.
2. Verifies the reassembled SD-JWT, with the KB-JWT appended if present, as specifies, and uses the Processed SD-JWT Payload. This holds with zero Disclosures too, where a KB-JWT alone forms the SD-JWT+KB of , though it then adds nothing beyond the DPoP proof. A failure yields invalid_token ().

Whether a KB-JWT is required is resource server policy and, as requires, MUST NOT depend on whether one was received; a resource server that requires one rejects a request without it. The key that verifies the KB-JWT is the jwk in the header of the DPoP proof, whose thumbprint MUST equal the Token's cnf.jkt (). A resource server that does not implement this profile ignores both fields, as permits, and sees only the cleartext claims. So does one that relies on token introspection instead of validating the Token itself, since the introspection response carries no Disclosure and an authorization server MUST NOT put selectively disclosable values in one, so such a resource server gains nothing from this profile.

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 : only the holder of the key can use one. The KB-JWT does not replace DPoP here, because intermediaries do not verify it. 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 notes, and not by this profile. A deployment that needs it beyond the transport could carry each Disclosure as a JWE 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 (); 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 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 (). 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 that Disclosures go only to resource servers known to implement the profile.

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 (). It offers none of the unlinkability discussed in : the Token's jti, sub and digests are the same in every request. Where a pairwise sub is used (), it and decoy digests () limit what a resource server learns beyond what is disclosed to it.

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" , with of this document as the reference, and of disclosures in the "OAuth Parameters" registry for use in token responses, described as "JSON array of the SD-JWT Disclosures issued with the access token in the same response", with as the reference. No JWT claims or header parameters are registered.

References Normative References Informative References

Example Token payload with email and name selectively disclosable (digests and Disclosures below are placeholders): Token response delivering it: Request disclosing email and withholding name: 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.

Open Issues

• 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 permits additional claims has to be settled first.
• Whether keeping typ at+jwt is acceptable against .
• 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 ).