Home » Security Bloggers Network » Your JWTs Are Now Outdated — Meet Selective Disclosure (RFC 9901)

Your JWTs Are Now Outdated — Meet Selective Disclosure (RFC 9901)

by MojoAuth - Advanced Authentication & Identity Solutions on November 20, 2025

#Your JWTs Are Now Outdated — Meet Selective Disclosure (RFC 9901)

If you think you’re done with tokens because you issue a signed JSON Web Token (JWT) every time a user logs in or a service authenticates — think again. There’s a new kid on the block: Selective Disclosure JWT (SD-JWT), set to land soon as RFC 9901. And if you keep handing out full-blown JWTs with every claim under the sun, you’re already behind.

The Problem with Traditional JWTs

JWTs have been the backbone of modern auth: compact, stateless, verifiable, “just include it in the Authorization header” simple. But they come with a blind spot:

Imagine: you issue a token for your SSO platform with 15 claims — user_id, email, name, roles, department, company, country, address, phone_number, etc. Then you hand that token to multiple microservices. One service only needed email_verified and roles. Why is it seeing address and phone_number too?

Even worse: your token gets intercepted or mis-used. Suddenly, all those extra claims are exposed — leaks happen, data minimization goes out the window, compliance may suffer.

If you’re still rolling full-claim JWTs with every service, your tokens are chatty. And chatty means eventually insecure.

What’s the Change? Enter RFC 9901 / SD-JWT

The new spec, SD-JWT, gives you — the issuer, the holder (user or client), and the verifier — a more refined control model. In plain language:

The issuer creates a JWT but does not expose certain claims in plaintext. Instead, those claims get converted into digests and are hidden in the payload.
Alongside the token, the issuer sends a set of “disclosures” (think of them as encrypted envelopes) to the holder.
The holder decides: “Okay, when I present this to Verifier A, I will reveal disclosures 1 and 2. To Verifier B I’ll only reveal disclosure 3.”
The verifier gets the signed JWT + the selected disclosures. It can check: “Yes, digest X in the token matches the disclosure you sent, so the claim existed in the original.” But it never learns the claims you didn’t disclose.

Bonus feature: SD-JWT+KB (Key-Binding) — you can optionally bind the token to a cryptographic key under control of the holder so the verifier can confirm the holder is indeed the one presenting it.

In short: you issue once, reveal selectively, and avoid oversharing.

How It Works Under The Hood

Let’s walk through a simplified flow:

Old way (regular JWT):

Issuer: Build token with full claims: { "user_id": "u123", "email": "[email protected]", "roles": ["admin","editor"], "address": "123 Main St", … }
Token signed, sent to client.
Client uses token with various verifiers; each sees all claims.
Risk: every service sees everything—even if it doesn’t need to.

New SD-JWT way:

Issuer: Decide which claims might be disclosed later. For each candidate claim you: compute a salt + hash the claim value + include that digest in payload under a special _sd array and set _sd_alg (say "sha-256"). The plaintext value of that claim is not in the token.
Issuer also provides the holder with the corresponding disclosure items (each is base64url-encoded JSON array containing salt, claim name, value) but these remain under holder control. ([Curity][3])
Holder wants to talk to Verifier A (who only needs email_verified). Holder sends: the signed token + disclosure for email_verified. Verifier: verifies signature, computes hash over disclosure, sees it matches digest in _sd and accepts claim value. Any other claims remain hidden.
Optional: If Key-Binding is required, holder also sends proof (KB-JWT) linking their key with the SD-JWT.

The result: The verifier sees only what you want it to see. Token stays compact, secure, and privacy-aware.

What This Means For SSO / Authentication

If you’re building or using authentication/SSO infrastructure (hello MojoAuth readers), this update matters a lot.

Better privacy, fewer leaks. A token isn’t a full profile dump anymore — it’s minimal by design.
Service-specific claim sharing. One user login → one token → multiple verifiers → each gets only what they need.
Compliance aligned. GDPR/CCPA prefer minimal data exposure. SD-JWT helps you architect for “data you don’t share you don’t risk”.
Future-proofing. As identity moves into verifiable credentials, wallets, cross-service flows, having selective disclosure built-in becomes a competitive advantage.
Brand credibility. Roughly: “Our product issues privacy-smart tokens that adapt to what each service needs.” That’s a message enterprise buyers care about.

Implementation Considerations & Pitfalls

Before you jump head-first, keep a few things on your radar:

Hash algorithm & salt. The _sd_alg claim dictates what hash to use, and you need good salt entropy so hidden values cannot be guessed. ([Curity][3])
Library support. SD-JWT is new. Make sure your token issuance library, verifier stack, and SDKs support it (or are upgradeable).
Backward compatibility. You may have services expecting regular JWTs. Decide whether you issue hybrid tokens, version your tokens, or upgrade all clients.
Complexity overhead. You’re adding more steps: issuers must manage disclosures; holders must manage which disclosures to reveal; verifiers must verify hash matching. Design with this complexity in mind.
Security hygiene. Hidden claims aren’t visible to a verifier—but the digests still exist. Poorly structured claims or weak salts may allow guessing attacks. And if you skip key-binding, a token might get replayed.
Governance & user expectations. If a service expects more data than you reveal, you’ll need coordination on what claims are required, optional, hidden.

How to Get Started (Your Roadmap for 2026-Ready Identity Stack)

Here’s a step-by-step action plan for your team:

Audit your current JWT usage.
- List all claims you issue.
- Tag each: “Always required”, “Sometimes required”, “Rarely required”.
- Find candidates for selective disclosure (claims that are rarely used or vary by verifier).
Decide your policy.
- Which claims you will treat as “disclosable”.
- Define rules: Verifier A requires X & Y; Verifier B requires Z; others may need only subset.
Update token issuance flow.
- In the issuer, generate the signed JWT with digests in _sd for selected claims.
- Issue disclosures separately to holder.
Update holder workflow.
- Manage token + disclosures.
- When presenting token, select only relevant disclosures for the target verifier.
Update verifier logic.
- Accept SD-JWT format.
- Verify signer, parse disclosures, hash them, compare with _sd digests.
- Only trust claims legally allowed.
Roll-out & feature flag.
- Initially issue regular JWTs + offer SD-JWT as opt-in.
- Monitor issuer/holder libraries, client integrations.
- Gradually move verifiers over to expect SD-JWT.
Educate your ecosystem.
- Internal dev teams, external clients, service integrators.
- “Here’s what changed, here’s what you need to code”.

Wrap-Up: Why You Shouldn’t Wait

If your token strategy is still “issue one JWT with everything and hope the verifier behaves”, you’re behind. The world is shifting. The new standard is selective, smart, and privacy-first. With SD-JWT (RFC 9901) you get tokens that disclose only what needs to be disclosed — and hide the rest.

Don’t let your JWTs be the data-dump of tomorrow. Start planning now, get ahead of the curve, and keep your stack modern, secure, and developer-savvy.