Verifiable Credentials & SD-JWT

What it is

A Verifiable Credential (VC) is a cryptographically signed, tamper-evident digital credential a holder keeps in a wallet and presents without the verifier calling the issuer. It is the data layer of decentralized identity: a machine-verifiable version of a diploma, a driver's license or proof of employment.

The term covers two standards families that share one model, the issuer, holder, verifier triangle:

• W3C Verifiable Credentials Data Model 2.0, a JSON-LD data model secured with embedded Data Integrity proofs or enveloping JOSE and COSE signatures.
• IETF SD-JWT and SD-JWT VC, a JWT-based format built for selective disclosure, favored by the EU wallet.

A third family, ISO mdoc, covers mobile driver's licenses. AnonCreds persists in Hyperledger Indy based networks.

Status (November 2026)

Dates are from the W3C TR index and the IETF datatracker, checked 5 November 2026. SD-JWT VC was on the IESG telechat agenda for 5 November 2026; the DISCUSS must clear before it becomes an RFC. Note that HAIP deliberately pins SD-JWT VC draft-13 and Token Status List draft-14, so production EU wallets lag the latest drafts.

How it works

1. Issuance. An issuer signs claims about a subject and delivers the credential to the holder's wallet, typically over OpenID4VCI. The credential is bound to a key the wallet holds. The issuer's key is found through a DID, an X.509 chain, or (for SD-JWT VC) issuer metadata.
2. Presentation. A verifier requests specific claims over OpenID4VP. The wallet builds a verifiable presentation with only those claims, signed with the holder key over the verifier's nonce.
3. Verification. The verifier checks the issuer signature, the holder binding, validity dates and status, then decides whether it trusts the issuer, typically via a trust registry or trusted list.

How SD-JWT selective disclosure works (RFC 9901). For each disclosable claim the issuer builds a disclosure, a base64url JSON array of salt, claim name and value, and puts its SHA-256 digest in an _sd array inside the JWT it signs. It may add decoy digests to hide how many claims exist. The holder sends the issuer-signed JWT followed by the disclosures it chooses, each terminated by ~, and for holder-bound credentials a key binding JWT (typ: kb+jwt) carrying iat, aud, nonce and sd_hash over the presented SD-JWT. The verifier hashes each disclosure and matches it to a signed digest. If the issuer included a boolean age claim, a request for proof of age reveals that one claim and nothing else.

What SD-JWT VC adds (draft-24). The application/dc+sd-jwt media type and typ, a required vct claim naming the credential type, type metadata retrievable from the vct URL, issuer key discovery through /.well-known/jwt-vc-issuer metadata or an inline x5c chain, and an optional status claim pointing at the IETF status list.

Revocation. The credential carries a status entry pointing to an index in a list the issuer publishes (revocation registry). Bitstring Status List serves W3C credentials and Token Status List serves SD-JWT VC; HAIP requires the latter with a unique, unpredictable index per credential.

Choosing a format

Who implements it

• walt.id: feature list covers dc+sd-jwt, jwt_vc_json, mso_mdoc and ISO/IEC 23220, plus Token Status List, Bitstring Status List v1.0 and older status lists. Its current stacks reject JSON-LD ldp_vc.
• Procivis: standards page lists SD-JWT VC (citing draft-05), mdoc, and W3C VCs with Data Integrity or JOSE and COSE, with Bitstring Status List and Token Status List revocation.
• Talao: supports SD-JWT VC, mdoc and W3C VCs.
• Microsoft Entra Verified ID: its standards page lists VC Data Model v1.1 in JWT-VC form and a 2023 status list draft, so it predates both VC 2.0 and SD-JWT VC.
• MATTR and Hyperledger Indy, Aries and AnonCreds cover the mdoc and AnonCreds ends of the market.

Rankings: best verifiable credential platforms, best decentralized identity for KYC.

Security and privacy pitfalls

• Signature-only verification. A valid issuer signature without a holder binding check accepts a stolen or copied credential. Always verify the key binding JWT or Data Integrity presentation proof against your nonce.
• Correlation by signature. Showing the same SD-JWT VC twice reveals the same issuer signature and digests, so colluding verifiers can link the user. Use batch issuance and one presentation per copy, or an unlinkable scheme.
• Weak salts. RFC 9901 relies on salts to stop verifiers guessing undisclosed values from their digests and recommends at least 128 bits of randomness. Use a vetted library, not a hand-rolled one.
• Status list privacy and freshness. Cache status lists sensibly; fetching per credential leaks timing, and stale lists accept revoked credentials.
• Trusting the issuer field. Anyone can mint a DID and sign a credential. Trust comes from your issuer allowlist or trust registry.
• Version mismatch. SD-JWT VC draft numbers, VC 1.1 versus 2.0, and status list versions all break interop silently. Pin versions per verifier.

Related

Guides: what is decentralized identity, verifiable credentials implementation guide, reusable identity and KYC with verifiable credentials. Articles: verifiable credentials use cases. Standards: DID, OpenID4VC, mDL, eIDAS 2 / EUDI Wallet. Glossary: verifiable credential, SD-JWT, verifiable presentation, JWT, zero-knowledge proof. Vendors: decentralized identity. Directory: digital IDs by country.

Who wrote it

Manu Sporny kickstarted the W3C work behind verifiable credentials and co-created JSON-LD underneath it. Selective disclosure rests on Daniel Fett's SD-JWT and on BBS signatures, co-edited by Tobias Looker and built on the BLS scheme co-authored by Dan Boneh. More in the experts directory.