Selective Disclosure for JWTs, or SD-JWT, is a credential format that lets a holder reveal only chosen claims from a signed token. The undisclosed claims remain hidden but remain cryptographically verifiable through hash commitments, which supports privacy-preserving identity verification and reduces unnecessary data sharing.
How SD-JWT Works
SD-JWT is built around a signed token that can carry multiple claims while allowing the holder to reveal only the claims needed for a specific interaction. The hidden claims are not discarded, they are committed cryptographically, so a verifier can still check integrity without seeing the full payload.
This design matters because it changes the shape of disclosure. Instead of sending a complete credential every time, the holder can present a narrower proof that supports the same trust decision while reducing exposure of personal or sensitive attributes.
Why Selective Disclosure Matters
The main value of SD-JWT is data minimisation. When a verifier only needs one attribute, such as age band, membership, or a single eligibility fact, selective disclosure avoids over-sharing and lowers the chance that unrelated claims are copied, stored, or repurposed.
That makes SD-JWT useful in privacy-sensitive identity workflows, especially where the same token may be reused across parties with different trust needs. It also supports a better separation between proof of validity and visibility of content, which is a common requirement in modern digital credential systems.
SD-JWT is especially relevant when the credential itself is part of a broader trust flow, not just a static data container. It fits naturally alongside privacy-preserving verification patterns such as holder-controlled disclosure and proof verification based on commitments rather than full token exposure.
Security Properties and Limitations
The security model depends on the integrity of the signing process, the binding between the disclosed claims and the committed claims, and the verifier’s ability to check that binding correctly. If any of those steps are weak, the privacy benefit can collapse into either over-disclosure or unverifiable partial disclosure.
Selective disclosure also does not make the credential itself safe by default. A badly designed claim set can still leak unnecessary context, and a token that is broadly reusable can still become a tracking or correlation vector even when only some claims are shown.
Operationally, SD-JWT should be treated as a privacy control inside an identity proofing or credential-verification flow, not as a substitute for authorization design. It reduces what is revealed, but it does not by itself decide whether the relying party should be trusted.
Common Implementation Contexts
SD-JWT is most often discussed in digital identity, verifiable credential, and API-facing trust workflows where different relying parties need different slices of the same asserted identity. It is also relevant wherever a system wants to prove something about a subject without transferring the full underlying record.
In practice, that often means packaging a credential so the holder can present only the claims needed for a transaction while the verifier can still validate that the hidden data exists and has not been altered. The result is less unnecessary disclosure and a smaller blast radius if the presentation is intercepted or stored.
The term is sometimes used alongside newer privacy-preserving credential patterns, but the key idea remains simple, claims can be revealed selectively without breaking cryptographic verifiability. For a broader workload-identity comparison point, the Guide to SPIFFE and SPIRE is useful because it shows how identity proofing, attestation, and token-style trust objects fit into machine identity systems.
Risk and Threat Considerations
Selective disclosure reduces exposure, but it also creates failure modes if implementers misunderstand what is actually hidden, what remains linkable, and what the verifier can still infer from presentation patterns. The biggest practical risk is assuming privacy has been solved when the credential can still leak context through reuse, correlation, or poor claim design.
Failure mechanism: If binding between disclosed claims and the committed token is implemented incorrectly, or if holders reuse presentations in ways that enable correlation, an attacker or careless verifier can undermine the privacy model without breaking the signature.
Impact: The result can be unnecessary disclosure, tracking across relying parties, or a false sense of confidentiality that leads organisations to expose more sensitive attributes than intended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication, and Access Control | SD-JWT shapes what identity claims are disclosed to verifiers. |
| PR.DS-1 — Data-at-Rest Data Protection | Selective disclosure reduces unnecessary exposure of sensitive claim data. | |
| Recommendation — Limit presented claims to the minimum needed for the access decision. Protect credential payloads so only intended claims are revealed. | ||
| CIS Controls v8 | 6.3 — Require MFA Where Appropriate | Selective disclosure often sits inside identity proofing and credential presentation flows. |
| Recommendation — Apply strong authentication before issuing or accepting credential presentations. | ||
Practitioner Guidance
What to watch for: Treat SD-JWT as a disclosure-control mechanism that still needs careful governance around claim selection, verifier expectations, and presentation lifecycle. The common mistake is to assume that “selective” automatically means “safe enough” for every trust relationship.
Practitioner takeaway: Design the token around the minimum claims needed for the transaction, then validate that the verifier can prove integrity without learning or retaining more than the use case requires.
Related resources from NHI Mgmt Group
- What do security and fraud teams get wrong about selective disclosure?
- What goes wrong when selective disclosure is implemented without strong verifier policy?
- How should organisations govern selective disclosure in digital identity systems?
- Why does selective disclosure matter in identity architecture?
