SD-JWT

SD-JWT (Selective Disclosure for JWTs) is the IETF specification that retrofits privacy onto the ubiquitous JSON Web Token. A standard JWT is all-or-nothing: present the token and every claim inside it — name, birthdate, address, entitlements — is visible to the verifier, whether the interaction needs it or not. SD-JWT changes that contract. The issuer marks individual claims as selectively disclosable, and the holder later chooses, presentation by presentation, exactly which ones to reveal to each verifier — all without breaking the issuer's signature over the credential.

The salted-hash mechanism

The construction is refreshingly plain. For each disclosable claim, the issuer does not embed the cleartext value in the signed payload. Instead it creates a Disclosure — a base64url-encoded JSON array containing a random salt, the claim name, and the claim value — and places only a digest of that Disclosure into the signed token. The holder receives the JWT plus the full set of Disclosures alongside it. At presentation time, the holder forwards the token together with only the Disclosures they wish to reveal; the verifier hashes each one and matches it against the digests inside the signed payload. Anything not disclosed remains an opaque digest — provably committed to by the issuer, but unreadable. The per-claim random salt is what prevents guessing: without it, a verifier could hash likely values ("is the birthdate 1990-01-01?") and test them against the digests. Implementations must support SHA-256 as the digest function, and holder-binding extensions let the presentation prove possession of a holder key so a stolen credential cannot simply be replayed.

Why it won adoption

SD-JWT's virtue is that it demands almost nothing new. It reuses the existing JOSE/JWT tooling that every web stack already ships — ordinary signatures, ordinary hashing, ordinary base64url — rather than exotic pairing-based cryptography. That pragmatism is why the EU's eIDAS 2 regulation and the EUDI Wallet architecture adopted SD-JWT-based verifiable credentials alongside the ISO mdoc format, and why it has become the default answer when an existing JWT-shaped system needs privacy without a cryptographic research project. For a developer, upgrading from "send the whole token" to "send the token plus chosen disclosures" is an afternoon, not a migration.

The honest limitation: linkability

The trade-off versus zero-knowledge approaches is correlation. The salted hashes and the issuer's signature value are identical every time the same credential is shown, so two verifiers — or one verifier across visits — can match presentations and build a profile even when the disclosed claims differ. Batch issuance of many single-use credential copies blunts this but multiplies issuer interaction. Schemes built on BBS+ signatures avoid the problem cryptographically, letting the holder re-randomize each presentation so no two showings are linkable, and AnonCreds goes further still with predicate proofs. SD-JWT chooses deployability over unlinkability, and it is important to know which property your use case actually needs. The mitigation hierarchy is worth remembering: disclose less, rotate credentials often, and reserve the unlinkable schemes for contexts where correlation is the actual threat model rather than a theoretical one.

The sovereign read

SD-JWT is a genuine improvement over the status quo — data minimization by default, holder consent per presentation, and it composes cleanly into a verifiable presentation. The sovereign caution is simply to remember whose privacy model it implements: it hides claims from verifiers, not the fact of credential use from a determined correlator, and the issuer still learns whatever it learned at issuance. As one concrete implementation of selective disclosure, it is the pragmatic floor — and knowing where the floor is helps you decide when you need the stronger, heavier ceiling.