The Government CIO’s Guide to Verifiable Credentials: W3C VC, SD-JWT, mDoc — What Matters
Three credential formats are competing for adoption in government digital identity programs. Each has vocal proponents, active standards bodies, and production deployments. A government CIO evaluating digital identity platforms needs to understand what each format does, where it’s strong, and where it falls short — without getting lost in the cryptographic weeds.
This guide is for the CIO who needs to make an informed decision, not the cryptographer who will implement it.
The three formats
W3C Verifiable Credentials (VCs) are the broadest credential format. Specified by the World Wide Web Consortium (W3C) under the Verifiable Credentials Data Model 2.0, W3C VCs can represent any type of credential — identity documents, educational certificates, professional licenses, health records, permits, and anything else an issuer wants to attest about a subject. The format is JSON-based, extensible, and supports multiple signature algorithms. It’s designed for the general case: any credential, any issuer, any verifier.
SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential) is an IETF-specified format that combines the JWT token structure (familiar to web developers) with selective disclosure — the ability for the holder to reveal only specific attributes without exposing the entire credential. SD-JWT VC is newer than W3C VCs and was designed to address a specific gap: efficient selective disclosure in a compact, web-friendly token format. It’s gaining traction in the European EUDI ecosystem.
mDoc (ISO 18013-5) is the format used for mobile driver’s licenses. Specified by ISO/IEC 18013-5:2021, mDoc is optimized for government-issued identity credentials presented in person — at airports, police stops, age verification, and hotel check-in. It uses CBOR encoding (compact binary), supports NFC and QR presentation, and includes built-in selective disclosure. It’s the most mature format for the specific use case of government-issued identity.
What each format does well
W3C VCs: flexibility. Any credential type. Any data model. Any signature algorithm (Ed25519, ECDSA, BBS+ for zero-knowledge proofs). The breadth is the strength — if you’re building an ecosystem with diverse credential types (health, education, identity, professional), W3C VCs are the most versatile container. The tradeoff: flexibility means more implementation choices, which means more potential for interoperability issues between implementations.
SD-JWT VC: selective disclosure efficiency. SD-JWT was purpose-built for selective disclosure in web environments. The holder can create a presentation that reveals only the requested attributes, without exposing the full credential content. The format is compact, web-native (JWT is ubiquitous in web development), and efficient for online verification. The tradeoff: newer standard, smaller implementation ecosystem, and less mature tooling compared to W3C VCs.
mDoc: in-person identity verification. mDoc is optimized for the scenario where a person presents a government ID to a verifier in person — via NFC tap or QR scan. It’s compact (CBOR is smaller than JSON), designed for offline verification, and has the most mature NFC presentation protocol. Every US state mDL and every EUDI-compliant identity credential uses (or will use) mDoc for in-person presentation. The tradeoff: mDoc is optimized for government identity, not for arbitrary credential types. Using mDoc for a professional license or an educational certificate is possible but awkward.
The convergence
The good news for government CIOs: you probably don’t need to choose one format exclusively. The three formats are converging toward interoperability, and the most sophisticated platforms support all three.
The emerging pattern in the EUDI ecosystem (which is the largest government digital identity program in the world, covering 450 million EU citizens):
- mDoc for government-issued identity credentials (driver’s licenses, national IDs) — especially for in-person NFC presentation.
- SD-JWT VC for online credential presentation — especially where selective disclosure is critical and the interaction happens over the web.
- W3C VCs for the long tail of credential types — educational certificates, professional licenses, health credentials — where the flexibility of the W3C data model is needed.
A well-architected platform should support all three formats and let the credential type determine the format — not force all credentials into a single format.
What to ask your platform vendor
Five questions that separate vendors who understand the credential format landscape from those who picked one format and built everything around it:
1. Which credential formats does the platform support? The ideal answer: “W3C VCs, ISO 18013-5 (mDoc), and SD-JWT VC.” If the answer is only one of these, ask why — and whether adding another format requires a platform upgrade or is architecturally impossible.
2. Can the citizen’s wallet hold credentials in different formats simultaneously? The citizen should be able to carry an mDL (mDoc) and a professional license (W3C VC) in the same wallet. If the wallet only supports one format, it will limit the credential ecosystem.
3. How does selective disclosure work for each format? Each format implements selective disclosure differently. mDoc has built-in selective disclosure at the attribute level. W3C VCs support selective disclosure through signature algorithms (BBS+) or through the SD-JWT mechanism. Ask for a demonstration, not a slide deck.
4. Can credentials be verified offline? This is format-dependent. mDoc was designed for offline NFC verification. W3C VCs can be verified offline if the verifier has the issuer’s public key cached. SD-JWT VC online verification is more common, but offline is architecturally possible. Ask how the platform handles offline verification for each supported format.
5. What happens when a standard updates? Standards evolve. W3C VC Data Model 2.0 is current; 3.0 will come. ISO 18013-5 has a revision in progress (ISO 18013-7 for online presentation). Ask how the platform handles standard version transitions — can it support multiple versions simultaneously during migration?
The KeyShare approach
The KeyShare Digital ID Platform supports all three credential formats: W3C Verifiable Credentials (Data Model 2.0), ISO 18013-5 (mDoc), and SD-JWT VC. The format is matched to the credential type and presentation context — not mandated by the platform.
The Puck and Reader Library handle ISO 18013-5 NFC presentation for in-person verification. The platform APIs handle SD-JWT VC and W3C VC for online and cross-organizational credential exchange. The citizen’s wallet holds credentials in whichever format the issuing authority chose — the wallet is format-agnostic.
