mDoc

Origin: composes. ISO/IEC introduced this format inside ISO 18013-5; the EUDI ARF later reused it for EU credentials generally. Solidus has not implemented it.

mDoc ("mobile document") is the generic, reusable data-container format that ISO/IEC 18013-5 introduced to hold a mobile driving licence, and that the EUDI ARF later adopted as one of the two mandatory formats for any EU digital-identity credential, not just driving licences. Where ISO 18013-5 mDL (the sibling Lexicon entry) is about the specific application, a driving licence, mDoc is the underlying container shape that application uses, and that the ARF now reuses for the PID itself.

What's actually inside one, in plain terms

An mdoc is encoded in CBOR, a compact binary format, not JSON; think "JSON's smaller, faster cousin, designed for constrained devices and offline transfer", and structured around a few core pieces:

• Namespaces and data elements, the credential's actual claims (name, date of birth, license category, whatever the specific document type carries), grouped by namespace so different document types can share a common structure without colliding.
• The Mobile Security Object (MSO): a signed digest of every data element, so a verifier can check that any given field is genuinely what the issuer signed, without needing every field present to verify the signature. This is what makes selective disclosure possible: reveal only the fields you want, and the verifier can still cryptographically confirm those fields are untampered and really came from the stated issuer.
• IssuerAuth / DeviceAuth, separate signatures from the issuer (proving the document is genuine) and from the holder's device (proving this presentation came from the device the credential was actually issued to, not a copy).

CBOR's compactness and deterministic encoding matter specifically because mDL/mdoc presentation is designed to work over Bluetooth Low Energy and NFC at close range, sometimes with no internet connection at all: a JSON-based format would simply be heavier than the use case tolerates.

Why the EUDI ARF requires this alongside SD-JWT VC, not instead of it

mdoc and SD-JWT VC solve overlapping problems for different situations: mdoc for proximity, offline-friendly presentation (a physical gate, a border checkpoint); SD-JWT VC for the web-native, always-online case (logging into a website, an OAuth-style flow). The ARF's decision to mandate both, for the same PID, is a deliberate hedge against betting the entire rollout on one wire format.

Solidus's actual relationship to it

Solidus has built none of this. Every credential format Solidus ships today, SD-JWT VC and BBS+ JSON-LD credentials, is JSON/JWT-family, not CBOR/COSE-family, and the two are not interchangeable: there is no simple conversion path from one to the other, because they encode trust and selective disclosure differently at the byte level. Solidus's BBS+ selective disclosure, unaudited today, full stop, is a genuinely strong property in its own right (see the BBS+ Signature entry), but it is not a substitute for mdoc support anywhere a relying party specifically requires the mdoc wire format, that requirement simply isn't met today.

Check it yourself

Real mdoc test vectors and worked examples are public in the EUDI Wallet's own reference implementation at github.com/eu-digital-identity-wallet. Pull one apart with any CBOR/COSE decoding library and see the actual structure: there is no equivalent artifact from Solidus to hold up next to it.