SD-JWT VC

SD-JWT VC takes an ordinary, everyday JWT, the kind of signed token used to log into much of the internet, and turns it into a credential where the holder can reveal some fields and withhold others, while the verifier can still cryptographically confirm the revealed fields are genuine and untampered.

A normal JWT signs one JSON object as a whole. Change one character and the signature breaks; reveal the token and you reveal everything in it. SD-JWT changes the construction: instead of putting each claim's plaintext value directly in the signed payload, the issuer replaces sensitive claims with a salted hash ("digest") of the value, and separately hands the holder the plaintext value plus its salt as a detached "disclosure." The issuer signs the JWT containing the digests. To present the credential, the holder sends the signed JWT plus only the disclosures for the fields they choose to reveal. The verifier recomputes each disclosed field's hash and checks it matches the digest inside the signed JWT, confirming the field is genuine, without the issuer ever having to sign a separate credential per possible disclosure combination.

SD-JWT VC layers a credential profile on top of that mechanism, issuer/subject metadata, credential typing, status/revocation references, so the result behaves like a W3C-style verifiable credential while staying inside plain-JWT tooling most backend engineers already have (JWT libraries, JWKS endpoints, standard JOSE headers).

Where it comes from

The core SD-JWT mechanism is an IETF OAuth working group specification, edited by Daniel Fett, Kristina Yasuda, and Brian Campbell. The credential profile, SD-JWT-based Verifiable Credentials, extends it for identity use cases and has been adopted directly into the EU's eIDAS 2.0 / EUDI Wallet technical specifications (see ARF), which is why it matters beyond being one more JWT variant. Solidus designed none of this; it implements the IETF draft as published.

Solidus status

Shipped: @solidus-network/sdk exposes issueSdJwtVc, verifySdJwtVc, presentSdJwtVc, and createStatusListJwt (for revocation), plus holder-key binding via KB-JWT so a presented credential is bound to the holder's key, not just copyable.

Worth being precise here, because it's a different guarantee than BBS+'s: SD-JWT VC gives you selective disclosure, not unlinkability. The digests for undisclosed fields still travel inside every presentation of the same credential; if a credential is reused (not single-use) and two verifiers compare notes, the shared digests are, in principle, a correlation handle. Solidus's holder-key binding narrows who can present the credential: it does not remove this property. If unlinkable presentation is the requirement, that's what BBS+ is for.

This runs on Solidus's public testnet, not a production deployment with a paying relying party, and the SDK exists only in TypeScript today: Python, Go, Rust, and Java bindings are roadmap items, not shipped code.

Proof you can run yourself: npm i @solidus-network/sdk, issue a credential, and inspect the disclosures, each one is a plaintext triple you can hash yourself and compare against the digest embedded in the signed JWT. Nothing about the disclosure mechanism requires trusting Solidus's account of it.