Summary

  • The issuer replaces selectively disclosable cleartext with digests in the signed payload and gives the holder separate Disclosures. The holder chooses which valid Disclosures to present; the verifier recomputes their digests and reconstructs the processed payload.
  • Object-property Disclosures contain a salt, claim name and claim value. Array-element Disclosures contain a salt and value. Salts must be cryptographically random, independent and unique per claim, hidden until disclosure; RFC 9901 recommends at least 128 random bits.
  • The top-level _sd_alg selects the disclosure hash. Nested use is forbidden, absence defaults to sha-256, and implementations must support sha-256. The issuer-signed JWT must be signed, never use none, and be checked before every presented Disclosure.

RFC 9901 is a Standards Track format, not an encryption scheme. It does not recover undisclosed claims from a token, replace confidential transport, or turn a presentation into a zero-knowledge proof or an anonymous credential. Its control surface is a chain: issuer disclosure design, holder choice, verifier policy and, where required, proof that the presenter controls a key.

The structure can be recursive. A hidden child may depend on disclosure of its parent, so a presentation missing a dependency is invalid even when an individual child Disclosure is well formed. Decoy digests can obscure the original number or existence of hidden claims, at the cost of larger tokens. They mitigate a side channel; they do not prevent correlation and do not guarantee unlinkability.

Key Binding is optional unless an application or verifier profile requires it. When used, the SD-JWT carries a holder public key or reference, and the holder signs a KB-JWT with typ kb+jwt, iat, aud, nonce and sd_hash. The sd_hash binds the exact issuer-signed JWT and selected Disclosures. A requiring verifier validates the holder key, signature, algorithm, type, time window, audience, nonce and digest binding.

Verification should reject an invalid issuer signature, none, an unsupported or wrongly placed hash declaration, a failed Disclosure digest, malformed reconstruction, a missing recursive dependency, or a required validity-controlling claim. Profiles must decide which claims are required: selectively hiding exp, for example, can deprive a verifier of data needed to reject a presentation. Confidential transport remains necessary where privacy or passive-correlation risks matter; RFC 9901 specifies no encryption mechanism and relies on the transport protocol. Storage should be restrained rather than treated as harmless because salts, Disclosures and stable credential material can add correlation data.

Theo March analysis — not an RFC mandate. Issuers should publish a minimum-disclosure schema; verifiers should request only policy-required evidence; consent interfaces should make each Disclosure legible; logs should avoid retaining unnecessary cleartext; revocation callbacks should be defined by the application; holder keys need rotation, loss and recovery procedures; and batch issuance with fresh salts and holder keys may improve verifier-to-verifier and presentation unlinkability. None of these operational choices is an automatic property of the format, and their adoption, performance, legal status and wallet presentation are unknown here.

The limit is explicit: a stable issuer-signed credential can let colluding issuers and verifiers recognize the same credential. Batch issuance can improve some verifier-to-verifier unlinkability, but cannot deliver issuer/verifier unlinkability against collusion. Selective disclosure redistributes trust; it does not eliminate it.

Conformance checks

  1. Confirm RFC 9901 is the governing specification and RFC 7515/7519 are used only for the JWS/JWT baseline.
  2. For every object property and array element, verify an independent unique salt, cryptographic randomness and at least 128 random bits.
  3. Confirm top-level _sd_alg, default sha-256 behavior, supported hash processing and no nested _sd_alg.
  4. Verify the issuer signature, reject none, recompute every presented digest and enforce recursive dependency closure.
  5. If Key Binding is required, validate kb+jwt, iat, aud, nonce, sd_hash, holder-key proof, algorithm and time window.
  6. Test missing required claims, malformed payloads, replay conditions, confidential transport and restrained retention.

Operator decision path

Start with the verifier’s minimum evidence. If a claim need not be seen, make it selectively disclosable and issue its Disclosure separately. If an array element is sensitive, construct its salt-and-value Disclosure independently; for an object property, construct salt, name and value. Add decoys only where their side-channel benefit justifies size. Require Key Binding only when the profile needs presenter possession, then enforce the complete KB-JWT checklist.

Otherwise validate the issuer signature and Disclosure chain, reject missing policy claims, use confidential transport, minimize storage, and document that correlation resistance is limited.

Sources