Credentials
mdoc and mDL (ISO/IEC 18013-5)
An mdoc is a mobile document in the ISO/IEC 18013-5 format, a CBOR-based credential best known as the mDL, the mobile driving licence. It is one of the two formats the EU Digital Identity Wallet uses, and the EU age verification attestation is an mdoc.
Also called: mdoc, mDL, mobile driving licence, ISO 18013-5, mso_mdoc
At a glance
- Spec
- ISO/IEC 18013-5
- Encoding
- CBOR, with COSE signatures
- Signed structure
- Mobile Security Object (MSO), holding digests by namespace
- Issuer signature
- issuerAuth, a COSE_Sign1 over the MSO
- Holder signature
- deviceAuth, over a session transcript
- Trust anchor
- IACA root; chain anchoring only, the issuer string is not consulted
The Mobile Security Object is the load-bearing part
An mdoc separates the values from what the issuer signed. Each disclosed data element travels as an issuer signed item with a random salt and a digest ID. The Mobile Security Object, the MSO, is the structure the issuer actually signs, and it contains the digests of all those items grouped by namespace, plus the document type and a validity window.
So verifying an mdoc means hashing each element you received and finding that digest in the MSO under the right namespace and digest ID. It is the same idea as SD-JWT disclosure, expressed in CBOR. Skip that step and you have checked a signature over a structure while never confirming it covers the values in front of you.
Two signatures that prove different things
Issuer data authentication is the MSO signature, made by a Document Signer whose certificate chains to an issuing authority root. It proves an authority vouched for these values.
Device authentication is a separate signature or MAC made by the device, over a session transcript that binds the response to this particular request. It proves the holder is presenting it now, and that nobody is replaying a copy. An inspection tool that takes a pasted document cannot check the second one, because there is no session to bind to, and it should say so, because a green tick implies otherwise.
The trust chain, and its soft spot
Trust is pure chain anchoring: the Document Signer certificate must chain to an IACA root the verifier already trusts. Unlike an issuer-string allowlist, the identifier in the document is not consulted, so an attacker choosing a label cannot move the answer.
The soft spot is the certificate profile. ISO 18013-5 Annex B constrains what a Document Signer certificate may look like, including its extended key usage and lifetime. A verifier that only checks the chain will accept a certificate that anchors correctly but is not a valid Document Signer, and profile enforcement is commonly missing.
Check one yourself
Reading about it only gets you so far. These are free validators in Tessio Labs, no signup, and nothing you paste is stored.
Why it matters
If you're verifying mdocs, the digest match against the MSO is the check that makes the signature mean anything about the values. Confirm your library does it rather than assuming.
If you're choosing a library, ask what it does about the Annex B Document Signer profile and about device authentication. Both are commonly skipped, and skipping either is defensible only if the tool says so.
Frequently asked
Is an mDL the same as an mdoc?
An mDL is one kind of mdoc: the mobile driving licence, with its own document type and namespace. The mdoc format carries other documents too, including the EU age verification attestation.
Why CBOR rather than JSON?
mdoc comes from the ISO identity-document world, where the format also has to work over NFC and Bluetooth in a proximity check, and compactness matters. SD-JWT VC comes from the web world and is JSON.
Does verifying an mdoc prove the person in front of me holds it?
Only if device authentication is checked, and that needs a real session to bind against. A tool validating a pasted document is checking the issuer signed side, which is a different and weaker claim.
Primary sources
This is a plain language explanation, not legal advice. Specifications and dates in this area move, so check anything you are going to rely on against the primary sources.
Keep reading
Age verification API
Or skip the theory and build against it
Tessio proves someone is over 18 from their EU Digital Identity Wallet and stores no personal data. Access is invite only while we onboard design partners. Tell us what you're building.