mdoc is the CBOR-based credential format from ISO/IEC 18013-5, identified as mso_mdoc. It uses a Mobile Security Object holding digests of each data element, which is what lets elements be disclosed selectively.
Technical standardReviewed 7 October 2026
Inside the wallet, which belongs to the user and is under their control.
Issuer
Signs credentials: a member state, university, bank or employer
Issuance
EUDI Wallet
Belongs to the user, who decides what to share
Presentation
Relying party
The service that requests and checks the data
Trust layer: who is allowed to sign, and is it still valid?
Rules: the law and technical framework behind it all
mdoc was designed for the mobile driving licence and carries that world’s assumptions: compact CBOR encoding, and a namespace structure grouping data elements by issuing domain. ISO/IEC 23220-2 generalises the same format for attestation types that are not driving licences. It is not proximity-only either: it travels over NFC or Bluetooth in person, and remotely over ISO/IEC 18013-7 or OpenID4VP.
The Mobile Security Object is the issuer-signed part. It holds digests of each element rather than the values, so a holder can release a subset and the verifier can still check each released element against the signature.
The ARF recognises three formats, but two of them carry the traffic today. Every PID is issued as mdoc and as SD-JWT VC, so a verifier reading only one can still fail on a credential it nominally supports. W3C VCDM v2.0 is listed as a third option and the ARF does not currently require a transport for it.
Defined in
ISO/IEC 18013-5 and ISO/IEC 23220-2; ARF v3.0.0 sections 5.4.1 and 5.4.2
A verifier that only does SD-JWT VC fails on driving licences. One that only does mdoc fails on most attestations. Format coverage is an interoperability requirement, not an optimisation.
Where you meet it
