mdoc explained: the ISO mobile document format
An mdoc is an official document that lives on a phone and can be checked on the spot, by a police officer at the roadside, a doorman at a venue or a website asking for proof of age. It is one of the two credential formats the European digital identity wallet is built on, and it is the one designed for the moment when neither side has a network connection. This page explains what an mdoc is, what is inside it, and what carrying one changes for the organisations that issue and accept it.
What an mdoc is
The name is short for mobile document, and the format is written down in an international standard, ISO/IEC 18013-5. It started life as the mobile driving licence: the question the standard set out to answer was how a police officer with a reader can trust a licence shown on a screen as much as one printed on plastic. The answer had to work in a car park at night with no signal, which is why the format looks the way it does.
Once that was solved, the same container was generalised. An mdoc can now carry any set of attributes, not only licence data, and every mdoc says which type of document it is so a reader knows which attributes to expect. A driving licence, an identity document, a diploma and a company registration can all be mdocs.
Two things follow from its origin and are worth holding on to. An mdoc is compact, because it had to fit through a short-range radio link rather than a broadband connection. And it is self-contained, because there was never going to be a server to call.
What is inside one
An mdoc holds its content as separate data elements rather than as one document: date of birth is one element, portrait is another, licence categories a third. That separation is the whole point. It is what lets a bar be told that someone is over eighteen without being told their birthday, their address or their licence number.
Next to the elements sits the piece that makes them trustworthy: a small signed object from the issuer. It does not sign the values directly. It signs a fingerprint of each element, computed with a random ingredient so two people with the same date of birth do not produce the same fingerprint. The holder can then hand over three elements out of twenty and the signature over the rest still checks out, without the verifier learning anything about the seventeen that stayed behind.
The third piece is a key that never leaves the phone. The credential is tied to it, so during a check the reader can see that this device is the one the mdoc was issued to. A screenshot of a licence, or a copy lifted off someone else, has no way to answer that challenge. The issuer signature proves the data is genuine, and the device key proves the person holding it is the one it was given to.
How an mdoc is presented
In person, the two devices talk to each other and to nobody else. The holder shows a QR code or taps the reader, which is only there to get the two introduced, and the attributes then move directly over Bluetooth Low Energy. No server sees the exchange, which means no record of it exists anywhere for the issuer to keep.
Online, a later part of the same standard family lets a website ask for the same credential and get back the same signed data, either through the browser on the phone itself or through a code shown on a larger screen. The route changes, the credential does not, and the verifier checks it exactly as a handheld reader would.
In person
ISO/IEC 18013-5. Two devices held next to each other, no network needed.
- The reader asks for a document and names the attributes it wants to see.
- The holder shows a QR code or taps the reader, which starts the session between the two devices.
- The wallet shows the request, the holder approves, and only the chosen attributes are released.
- The attributes travel straight to the reader over Bluetooth Low Energy, and the reader checks the issuer signature itself.
Online
ISO/IEC 18013-7. A website asks, the phone answers, the same signed data.
- A website asks for the same attributes, in a request the wallet can read.
- The request reaches the wallet through the browser on the same phone, or through a code shown on a larger screen.
- The wallet shows who is asking and what for, and the holder approves.
- The signed response goes back to the website, which verifies it against the issuer the same way a reader would.
mdoc next to SD-JWT VC
European digital identity does not pick a winner. The architecture the EU wrote for the wallet names two credential formats, mdoc and SD-JWT VC, and expects wallets, issuers and verifiers to be able to handle both. This surprises people who assume one must be the modern replacement for the other. Neither is.
The practical consequence is that a wallet often holds the same attestation twice, once in each format, and hands over whichever the other side asks for. A supermarket self-checkout with an ISO reader built into the till gets the mdoc. A web shop that added an age check to its existing login gets the other one. To the person holding the phone these are the same credential.
For your organisation the question is not which format to back. It is whether whatever you buy or build can speak both, because the side you do not support is the side that will turn up.
Where you will meet one
Driving licences are the obvious case and the furthest along: several countries and a long list of US states already issue one, and readers exist in the field. Identity attestations are next, because the personal identification data every European wallet has to carry is specified in the mdoc format as well as the other one.
After that it opens out. Age checks at a till or a door, a membership or season ticket at a turnstile, a professional qualification shown to a client on site, a company registration handed to a counterparty. The pattern is the same everywhere: a check that happens in front of you, quickly, where reaching for a network is either slow or not an option.
What this means for you
Issuer
Decide early which attributes are separate elements, because that decision fixes what a holder can share on its own later. Plan for issuing the same attestation in both formats, and decide how long a copy stays valid before it has to be refreshed.
Relying party
Ask for the fewest elements that answer your question, not for the whole document, and be ready to accept both formats. If your check happens at a counter or a gate, an mdoc reader is the piece of the ecosystem that has to work without a network.
Wallet holder
Read what the wallet shows before you approve: it names who is asking and lists exactly which elements they want. Handing over an mdoc is not handing over your phone, and it is not showing the whole document either.
Related terms
Frequently asked questions
Is an mdoc the same thing as an mDL?
No, an mDL is one kind of mdoc. The mobile driving licence is what the format was built for, and it is still the best known example, but the same container was then opened up to carry any set of attributes. A company registration, a professional qualification and a proof of age can all be mdocs, and each one says which type of document it is so a reader knows what it is looking at.
Does a verifier have to contact the issuer to check an mdoc?
No. Everything needed to check the attributes travels with the credential: the values, the issuer signature over them, and the proof that the phone presenting them is the one the credential was issued to. The verifier needs the issuer public key, which it already holds from a trusted list, not a live call. That is what makes a roadside check or a ticket gate work with no signal on either side.
If the EUDI Wallet also uses SD-JWT VC, why keep mdoc?
Because they were built for different rooms. mdoc came out of in-person identity checks and is compact enough to move over Bluetooth between two devices with no network. SD-JWT VC came out of the web and slots into the tooling that already runs there. The European rules ask wallets, issuers and verifiers to handle both, so a wallet typically holds the same attestation twice, once in each format, and hands over whichever the other side speaks.
What happens when an mdoc has to be withdrawn?
The signed part of an mdoc carries its own validity window, so a copy that is no longer current stops being accepted on its own once that window closes. Where a withdrawal has to bite sooner than that, the European rulebooks add a status mechanism the verifier can consult, and many issuers simply keep the validity window short and refresh the credential often. Which of the two you need is a policy decision, not a property of the format.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the ISO standards and the EU Architecture and Reference Framework directly.