SD-JWT explained: selective disclosure tokens (RFC 9901)

SD-JWT is a signed data format that lets the person holding a credential reveal only some of its contents. A university could issue you a token with your name, birth date, address and student status. When a library asks only whether you are a student, you present the token with just that one claim opened, and the library can still verify that the university signed it. The core specification is RFC 9901, published by the IETF in November 2025.

What problem does SD-JWT solve?

An ordinary signed token, such as a JSON Web Token (JWT), is all or nothing. If you want to prove one fact, you hand over every claim inside it, because changing the content would break the signature. For identity documents this is a poor fit: a shop that needs to know you are over 18 does not need your address.

SD-JWT keeps the signature but makes individual claims optional to reveal. This is the technical basis for data minimisation, a principle of the EU’s data protection rules, and a building block for the EUDI Wallet.

How does it work?

The idea is called salted hashes. Three roles take part: the issuer creates and signs the credential, the holder (your wallet) stores it, and the verifier (the service asking for data) checks it.

1. Issuance. For each claim that may be hidden, the issuer creates a small record, a disclosure, containing a random salt, the claim name and the value. The issuer puts only the hash of each disclosure into the signed token, not the claim itself.
2. Storage. The holder receives the signed token plus all disclosures.
3. Presentation. The holder sends the signed token plus only the disclosures it chooses to reveal. Disclosures are appended to the token and separated by a tilde character (~).
4. Verification. The verifier checks the issuer’s signature, hashes each received disclosure and confirms the hash appears in the signed token. Hidden claims stay hidden because the salt makes their hashes impossible to guess.

A simplified presentation looks like this:

<issuer-signed-JWT>~<disclosure: age_over_18 = true>~<key-binding-JWT>

The final part, the key-binding JWT, is optional but important for identity use. The holder signs a short message with a key tied to the credential, including a nonce from the verifier and the verifier’s identifier. This proves that the person presenting the token is the one it was issued to, and stops a stolen copy from being replayed.

SD-JWT, SD-JWT VC and other terms

• SD-JWT (RFC 9901) is the generic mechanism. See the IETF datatracker entry.
• SD-JWT VC is a profile for verifiable digital credentials built on SD-JWT. It defines credential types and how verifiers find issuer keys. It is still an Internet-Draft of the IETF OAuth working group; as of October 2026 it had passed working group review and was in the IESG publication process.
• Verifiable credentials is the wider concept; our page on verifiable credentials explains how the different formats relate.

Where does the EUDI Wallet use SD-JWT?

The EU’s wallet architecture, the Architecture and Reference Framework, names two credential formats that wallets and issuers must support: ISO mdoc and SD-JWT VC. Person identification data, the digital version of your national identity, is meant to be issued in both formats. Which one a given service accepts depends on the use case and on the channel: mdoc comes from the proximity world of the mobile driving licence (see mdoc and ISO 18013-5), while SD-JWT VC comes from the web and OAuth world.

Credentials get into the wallet through OpenID for Verifiable Credential Issuance, and are presented to services through OpenID for Verifiable Presentations. SD-JWT is the payload inside those protocols, not a protocol itself.

Examples

• Age check. A wallet shows only an age_over_18 claim; no name, no birth date.
• Address for a delivery. The holder reveals the postal address but not the date of birth.
• Employee badge. An employer’s credential reveals only the company name and role to a partner portal.

Security and privacy: what to know

• Selective disclosure is not unlinkability. The issuer’s signature and the hashes are the same every time the credential is presented. Two verifiers that compare notes can recognise the same credential. Wallets and issuers can mitigate this by issuing many single-use copies, and RFC 9901 discusses unlinkability explicitly. Our article on EUDI Wallet privacy goes deeper.
• Issuers see nothing at presentation time. Unlike in classic single sign-on, the issuer is not contacted when you present a credential, which is good for privacy.
• Key binding matters. Without it, anyone who copies a token and its disclosures could present them. Verifiers should require key binding for identity credentials.
• Salts must be random. Predictable salts would let a verifier guess hidden values. This is the issuer’s responsibility.
• Revocation needs a separate mechanism. SD-JWT does not say how to withdraw a credential; status lists are used for that and are specified elsewhere.

How does it compare with other standards?

Format	Encoding	Selective disclosure	Typical use
SD-JWT VC	JSON, JWS	Salted hashes	Online and web flows, OAuth-based wallets
ISO mdoc	CBOR, COSE	Salted hashes of data elements	Proximity (NFC, QR, Bluetooth) and online
W3C VC with JSON-LD proofs	JSON-LD	Depends on the proof suite	Research, some pilots

SD-JWT and mdoc work on the same principle, hiding claims behind salted digests, but differ in encoding and ecosystem. For the full picture of how a wallet works, start with the EUDI Wallet overview.

Status in October 2026

RFC 9901 is final and stable. SD-JWT VC is close to publication but not yet an RFC, so details may still change and implementers should follow the latest draft. The EU’s own technical specifications for wallets reference these documents and are updated regularly; always check the current version of the architecture framework before building.