SD-JWT Explained: Selective Disclosure Without Sending the Whole Credential

A digital credential often contains more information than a service needs. A venue may need proof that someone meets an age threshold; a service may need a verified address. Sending a complete identity record is an unnecessarily broad exchange.

Selective Disclosure JWT (SD-JWT) lets an issuer sign a set of claims while allowing the holder to choose which of those claims to reveal to a verifier.

The issuer signs commitments to claims; the holder presents only the openings needed for the current request.

A signed credential with optional openings

A conventional signed JWT puts claims directly in its payload. SD-JWT instead creates a disclosure for each selectively disclosable claim and commits to it with a digest. The issuer places those digests in the signed JWT; the holder keeps the disclosures and supplies only selected ones at presentation time.

A verifier hashes a received disclosure and checks that its digest appears in the issuer-signed JWT. It can validate a revealed value without receiving every other value to which the issuer committed.

Issuance is not presentation

The holder may receive all disclosures it is entitled to use, but does not have to forward them unchanged. A presentation can contain the signed SD-JWT, only the disclosures relevant to the verifier’s request, and—where required—a Key Binding JWT. The issuer signature remains the same; the selected disclosures change.

Selective disclosure is not encryption

Undisclosed claim values are unavailable to a verifier because the holder does not send the corresponding disclosures. SD-JWT enables data minimization, but does not make it automatic. Product teams must still decide which claims are necessary, how requests explain their purpose, whether values are retained, and whether repeated requests create unnecessary disclosure pressure.

A valid issuer signature is not enough

A valid SD-JWT and correct disclosures establish that an issuer committed to values. They do not necessarily establish that the response is live, intended for this verifier, or presented by the credential’s legitimate holder.

Holder binding addresses that gap. An SD-JWT can include a cnf confirmation claim for a holder key. The holder creates a Key Binding JWT with the corresponding private key. A verifier checks a fresh nonce and its own client_id, binding the presentation to this session and recipient.

Where SD-JWT fits in an OpenID credential flow

SD-JWT is a credential representation, not a complete transport protocol. OID4VCI can deliver a credential to a wallet. OID4VP gives a verifier a structured way to request credential evidence and receive a response. In OID4VP 1.0, the SD-JWT VC format identifier is dc+sd-jwt and a verifier can use DCQL to describe the format and claims it needs.

What builders should take away

A production verifier must validate issuer trust, each received disclosure, credential validity and applicable status information, and holder binding when required. It must also keep self-attested data distinct from issuer-verified credential claims. Done well, SD-JWT lets services obtain strong evidence without defaulting to full-credential disclosure.