mdoc or SD-JWT VC? Two Credential Formats, Two Different Worlds
We issue one of them. The other is roadmap and not built.
If your requirement is a mobile driving licence, stop here: we are not a candidate, and no amount of the rest of this page changes that.
They come from different worlds, and that explains almost everything
mdoc descends from the physical document. Its lineage is the driving licence: an ISO working group, a card in a wallet, a police officer at a roadside with no signal. It was designed for offline, in-person presentation first, with online presentment added later.
SD-JWT VC descends from the web. Its lineage is OAuth and JSON Web Tokens: an IETF draft, an HTTP request, a browser. It was designed for online first.
Neither is a better engineer's version of the other. They solved different problems, decades apart, for different institutions, and the European framework accepts both, which is why anyone has to choose.
The concrete differences
| mdoc | SD-JWT VC | |
|---|---|---|
| Encoding | CBOR, binary, compact | JSON, text, inspectable |
| Signing envelope | COSE | JOSE / JWS |
| Home | ISO/IEC, standards are paywalled | IETF, drafts are free to read |
| Designed for | offline, in person | online |
| Tooling | specialist | every language has a JWT library |
| Status | published international standard | a draft, not a published RFC |
Two of those rows matter more than the rest.
Paywalling. You can read the SD-JWT VC draft right now, for nothing. Reading the mdoc standard costs money, which shapes who implements it, how many independent implementations exist, and how much of the ecosystem is hobbyists versus institutions. That is not a technical property, and it has more effect on adoption than any technical property on this page.
Maturity, in the other direction. mdoc is a published international standard; SD-JWT VC is a draft that can still change. On stability the older format wins, and we say so on our own format page.
Where each one actually wins
Choose mdoc if: the credential is a government identity document · it must work offline · you need the driving-licence ecosystem, phone wallets and reader hardware · your counterparties are institutions that already speak ISO.
Choose SD-JWT VC if: the credential moves over the web · your developers should be able to read it without specialist tooling · you want implementations in every language for free · the issuers are not governments.
A serious wallet in Europe will need both. That is the honest shape of the requirement, and it is why "we support the standards" from any vendor deserves the follow-up: which of the two, and is the second one shipping or planned?
Our answer to that question
SD-JWT VC: yes, and it works. Verified this session from a clean directory against the published
package: a valid credential verifies, a wrong issuer key returns "Verify Error: Invalid JWT Signature", and an expired one returns "Verify Error: JWT is expired". The controls are what make
the passing case mean anything.
mdoc: roadmap, not built. Measured rather than asserted: the published packages contain zero
files referencing CBOR, zero referencing COSE, and zero referencing the mdoc media type, with
sdjwt matching 30 files as the control. Across the whole monorepo, the ISO standard number and the
media type match nothing, against 32 files for SD-JWT.
It is a documented roadmap item and it is not partially done. There is no half-implementation to find.
And the one trace of mdoc in what we ship is wrong
The only mention of mdoc in our published packages is a doc comment, and it says SD-JWT VC is "one of two W3C VC formats accepted by the EUDI Wallet ARF."
SD-JWT VC is an IETF draft. It is not a W3C format. The two bodies own different layers, the map is here, and getting that wrong in a comment shipped to every developer who installs our SDK is our error, not a subtlety.
We filed it against the package and we are naming it here too, because this page is exactly where a reader would otherwise absorb it as fact.
What choosing one format does not settle
Neither format makes a credential trustworthy. Both carry an issuer's signature, and whether that issuer should be believed is a question no encoding answers, which is the whole of the problem.
And neither is unlinkable on its own. Two presentations of the same credential are correlatable in both, absent a separate mechanism. Ours is a different, unaudited path, and what the digest still reveals applies whichever format you pick.