Choosing a credential format: W3C Verifiable Credentials, SD-JWT VC or ISO mdoc

A verifiable credential is a signed set of claims about a subject that a holder keeps and presents. The format fixes the encoding, the signature scheme, how individual claims can be disclosed and which protocols carry it. A verifier that cannot parse a format cannot accept the credential, however trustworthy the issuer, so the choice decides which wallets and verifiers can take part in an ecosystem.

Format debates often turn into arguments about taste, JSON-LD against plain JSON or CBOR against text. The better questions are practical. Who must verify the claim, and on what devices? Is it presented online, at a counter or offline? Must two verifiers be unable to tell they saw the same holder? Does a regulation or scheme name a format?

The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on 15 May 2025¹. It defines a JSON-LD data model, so claims can reference shared vocabularies, and two families of securing mechanisms: embedded proofs based on Verifiable Credential Data Integrity, and enveloping proofs based on the companion JOSE and COSE specification¹.

Data Integrity cryptosuites differ in what they allow. EdDSA and ECDSA suites sign the whole credential; selective-disclosure suites let a holder derive a proof over chosen claims. The BBS cryptosuite goes further, offering selective disclosure and unlinkable derived proofs, so each presentation looks different to verifiers². It is still a Candidate Recommendation Draft², and BBS relies on pairing-friendly curves that common phone secure hardware does not currently support, which complicates device-bound keys.

The model suits ecosystems that value shared semantics across many credential types, such as supply-chain certificates, education records and organisational credentials, and can absorb the extra work of JSON-LD processing.

Selective Disclosure for JWTs was published as RFC 9901 in November 2025³. The issuer replaces each disclosable claim with a salted hash, signs the resulting JWT and gives the holder the matching disclosures. To present, the holder sends the JWT, only the disclosures it chooses to reveal and, usually, a key-binding JWT that proves possession of the holder key. SD-JWT VC, the profile that adds credential typing and verification rules, was still an Internet-Draft submitted to the IESG when this page was reviewed⁴.

Its strengths are simplicity and reach: plain JSON, standard JOSE libraries and an OAuth-style issuance protocol. Its weakness is linkability. The issuer signature and digests are identical in every presentation, so colluding verifiers can recognise the same credential. The usual mitigation is batch issuance of single-use copies, each with fresh salts and keys.

The mdoc format comes from ISO/IEC 18013-5, the mobile driving licence standard, and is generalised in ISO/IEC 23220-2⁵. Data elements are encoded in CBOR; the issuer signs a mobile security object containing salted digests of each element, and the device authenticates each presentation with a key held in the phone. That makes mdoc the only one of the three designed for proximity presentation, where ISO/IEC 18013-5 is used, while remote presentations can run over OpenID4VP or ISO/IEC 18013-7⁵.

Like SD-JWT VC, mdoc hides undisclosed elements but reuses one issuer signature across presentations, so batches of short-lived credentials address linkability. Its data model is defined per document type, which helps identity documents interoperate and fits open-ended business credentials less naturally.

Verifiers also need to know which key belongs to the issuer. W3C Decentralized Identifiers, a W3C Recommendation since July 2022, resolve an identifier to a document listing keys and services⁶. did:web publishes that document on the issuer's domain, so trust follows DNS and web hosting. did:key encodes the key in the identifier itself, which suits short-lived or device keys but cannot rotate. Ledger-based methods such as did:hedera record DID document changes on a public network⁷, giving every party the same key history without depending on one organisation's web server. The EU wallet framework, by contrast, relies on certificate authorities and trusted lists.

A ledger-based DID earns its place when issuers span many organisations with no shared certificate authority, when key history must be auditable years later, or when devices and AI agents need identifiers nobody can quietly reassign. It adds nothing where one authority already runs a trusted list, and personal data never belongs on the ledger.

Signatures do not survive translation: an SD-JWT VC cannot be converted into an mdoc by the holder, because the issuer's signature covers one encoding only. A multi-format strategy therefore keeps one canonical claim model in the issuer's systems and issues each format separately, usually as different credential configurations of the same OpenID4VCI issuer⁹. Keep revocation in step across formats, and test with the verifiers that will actually read each one.