What ISO/IEC 18013-5 Means for Businesses

Standards documents are written for implementers, and ISO/IEC 18013-5 is no exception. If you are a business deciding whether mobile ID is worth adopting, you do not need to read it. You need to know what it guarantees you, and what it does not.

What the standard is

ISO/IEC 18013-5:2021 is Part 5 of the ISO/IEC 18013 series, which covers ISO-compliant driving licences. Part 5 specifically defines the mobile driving licence application: how an mDL is structured, how it is secured, and how it is presented to a verifier in person.

Two companion documents are worth knowing exist. ISO/IEC TS 18013-6 defines test methods, which is what makes conformance claims checkable rather than asserted. ISO/IEC TS 18013-7 covers add-on functions, including presentation over the internet rather than in person — a different problem with a different threat model.

Part 5 is the one that matters for a door or a counter.

The four things it gives a business

1. Interoperability

The standard defines a common document type (org.iso.18013.5.1.mDL), a common namespace, and common element names. A conforming reader can, in principle, accept a conforming credential from any issuing authority — the reader does not need bespoke code per state the way barcode parsing has historically needed bespoke handling per format.

The caveat is real: interoperability in principle is not interoperability in practice. Transport behaviour varies between phone models and reader chipsets, and issuing authorities make different choices within the standard’s latitude. This is precisely why test methods exist as a separate part of the series, and why any vendor telling you their reader works with “all mDLs” is describing an aspiration.

2. Cryptographic verification

The issuing authority signs a structure committing to the digest of every data element. The reader validates that signature, then checks that each element it received matches its committed digest. A response is additionally signed with a key bound to the presenting device.

The practical consequence: an mDL check does not depend on anyone’s judgement about a hologram. It either validates or it does not, and it produces the same answer at 2pm and at 2am.

3. Selective disclosure

The credential is a set of independently verifiable elements rather than one blob. A reader can request a subset, and the holder’s wallet releases only that subset.

The standard also defines pre-computed age attestations — age_over_18, age_over_21, and so on — signed at issuance. This is what makes it possible to prove an age threshold without disclosing a birth date, which is a genuinely new capability rather than a policy improvement.

4. A defined trust model

The standard describes how a list of legitimate issuing-authority public keys can be shared with relying parties, through a verified issuer certificate authority list — a VICAL. That is the mechanism AAMVA’s Digital Trust Service implements for the United States.

Having a defined trust distribution mechanism is what separates this from a scheme where every relying party assembles its own list of who to believe.

What the standard does not give you

It does not tell you the phone belongs to the person holding it. The credential binds to a device and to an issuer. Whether the human in front of you is the human the credential describes is still a judgement, exactly as it is with a physical card. Some presentations release a portrait to support that judgement — but a business that requests one has made a very different privacy decision than one that requests only an age attestation.

It does not make a bad implementation good. A reader that accepts any certificate authority, or that reads claims before validation completes, is not made safe by the standard it nominally follows. Conformance is testable, which is a strong reason to ask a vendor what has actually been tested and on what hardware.

It does not guarantee availability. The standard says nothing about which jurisdictions issue mDLs, which wallets carry them, or how many of your customers have one. Those are separate facts that change independently, and none of them follow from the others.

What to ask a vendor about standards conformance

• Which document type, namespace, and elements does your reader request?
• Which transports do you implement, and which have you tested on the hardware I would deploy?
• Where does your trust list come from, and what else does the reader accept?
• Which jurisdictions have you physically validated, on which devices, and when?

The last question is the one that separates a specification claim from a deployment claim. A reader that conforms to the standard has demonstrated something about its code. A reader that has verified a real credential from a named jurisdiction on named hardware has demonstrated something about your rollout.

How LaurelID relates to the standard

This section is Laurel’s own position.

LaurelID is an ISO/IEC 18013-5 reader that implements a deliberately narrow slice of what the standard permits: NFC engagement, BLE device retrieval, and a single-element request for age_over_21 with intentToRetain false. It does not implement online presentation, does not request other elements, and does not support other age thresholds.

Narrowness is the point. Most of the standard’s surface area is capability we have chosen not to have, which is why our compatibility matrix can be short and specific rather than a list of everything the specification allows.

Sources

1. ISO/IEC 18013-5:2021 — Personal identification, ISO-compliant driving licence, Part 5 — ISO
2. ISO/IEC TS 18013-7:2025 — mDL add-on functions — ISO
3. ISO/IEC TS 18013-6:2024 — mDL test methods — ISO
4. Digital Identities — Mobile Driver's License (mDL) project — NIST National Cybersecurity Center of Excellence