Standards/mobile-driving-licence
Mobile Driving Licence
Overview
The Mobile Driving Licence (mDL) is the digital, phone-resident form of a driver license, defined by ISO/IEC 18013-5:2021 1. The standard establishes the interface between the mDL on a holder's mobile device and an mDL reader, and between the reader and the issuing authority's infrastructure 1. Unlike the physical card's PDF417 barcode (see AAMVA DL/ID), the mDL carries cryptographically signed attributes that the holder can selectively disclose, and it is engaged through a QR Code (or NFC tap) rather than carried in a barcode 6.
The data format is the mdoc — an "ISO mobile document" structure encoded in CBOR (RFC 8949), with issuer signatures expressed in COSE. The mDL is the canonical mdoc; the same machinery underpins other mobile documents and is reused by the EU's EUDI Wallet 6. The QR Code in an mDL transaction does not contain identity data — it carries the device engagement parameters (the device's ephemeral public key and the transfer methods on offer) that bootstrap a secure session over which the data then flow 6.
History
ISO/IEC 18013-5:2021 — "Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application" — was published in 2021 as the first edition, covering proximity (in-person) presentation 1. It builds on the broader ISO/IEC 18013 family for the physical ISO driving licence.
Online / unattended presentation is addressed by a companion specification, ISO/IEC TS 18013-7 (technical specification, published 2025), which profiles how an mdoc/mDL is presented remotely over the web — including via OpenID4VP — rather than in person 6. ISO/IEC 18013-5 thus covers proximity presentation while ISO/IEC TS 18013-7 covers online presentation 6.
In North America, AAMVA publishes companion Mobile DL Implementation Guidelines (e.g. version 1.3) that profile ISO/IEC 18013-5 for U.S. and Canadian issuers, sitting alongside the physical-card AAMVA DL/ID standard 2.
Technical specification
Data model — mdoc / CBOR. An mdoc is a CBOR data structure defined in ISO/IEC 18013-5. Data elements are grouped under a namespace; for the driving licence the namespace is org.iso.18013.5.1 (with mDL-specific data under org.iso.18013.5.1.mDL) 6. CBOR's compact binary encoding keeps the payload small enough to move over short-range links 6.
Issuer data authentication — the Mobile Security Object (MSO). The issuing authority provisions the mDL to the device together with a MobileSecurityObject, a CBOR object signed by the issuer as a COSE_Sign1 structure. The MSO contains a digest algorithm, a per-element digest of each data element, and a validity period 6. Each data element is committed with a random salt, so that during presentation the wallet can reveal a chosen element's value plus its salt and the verifier recomputes the hash and compares it to the MSO digest — proving the value is genuine without the issuer having to sign each subset 6. This is the mechanism for selective disclosure and data minimization 6.
Device engagement via QR / NFC. A transaction begins with device engagement: the mDL device communicates a DeviceEngagement CBOR structure — its ephemeral public key and the available transfer methods — to the reader, typically by displaying a QR Code the reader scans, or over an NFC tap 6. The reader and device then perform an ECDH key agreement using ephemeral keys to establish an encrypted session 6.
Device retrieval transfer methods. After engagement, the mdoc request and mdoc response messages (CBOR) move over one of three proximity channels: Bluetooth Low Energy (BLE), NFC, or Wi-Fi Aware 6.
Three mandatory security mechanisms for device retrieval 6:
- Session encryption — the ECDH-derived session protects data in transit.
- Issuer data authentication — verifying the issuer-signed MSO and per-element digests.
- mdoc authentication — the device proves possession of the key bound to the credential, via a device signature or MAC, defending against cloning.
Known design trade-offs. Independent analysis notes that ISO/IEC 18013-5 deliberately shares the device's public key only through short-range engagement and that reader authentication is not required at engagement, so the initial session is unauthenticated — a deliberate privacy/usability choice that also carries man-in-the-middle and relying-party-tracking considerations 7.
Use cases
- Roadside / traffic stops — proximity presentation to law enforcement, the original driving-licence use case 1.
- Airport security — TSA accepts ISO/IEC 18013-5 mDLs at checkpoints using CAT-2 credential-authentication readers 3.
- Age and identity verification — selective disclosure lets a holder prove "over 21" without revealing the full record 6.
- Account opening / remote KYC — online presentation via ISO/IEC TS 18013-7 and OpenID4VP 6.
Implementations
eu-digital-identity-wallet/eudi-lib-android-verifier-core— Kotlin, Apache-2.0. Android SDK for verifying EUDI identity documents, explicitly compliant with ISO 18013-5. ~2 stars; last pushed 2025 4.eu-digital-identity-wallet/eudi-lib-ios-iso18013-security— Swift. Implements the mdoc security mechanisms (session encryption, MSO verification, mdoc authentication) of ISO/IEC 18013-5 6.- AWS reference architecture — AWS documents building an ISO/IEC 18013-5 mDL solution using AWS Private CA and AWS KMS for the issuer PKI 6.
- Multiple state issuers and the Apple Wallet / Google Wallet platforms support adding ISO/IEC 18013-5 mDLs in participating U.S. states 3.
Comparison
Versus the physical-card AAMVA DL/ID PDF417: the PDF417 is a static, cleartext barcode that reveals everything on every scan and cannot be revoked or selectively shared; the mDL is a signed mdoc supporting selective disclosure, revocation via validity periods, and cryptographic anti-cloning, engaged through a QR Code/NFC rather than carried in the barcode 1, 6. The two coexist — AAMVA maintains both the card-design standard and the mDL guidelines 2.
Versus the EUDI Wallet: the EU wallet mandates the ISO/IEC 18013-5 mdoc format as one of its two required credential formats (alongside SD-JWT VC), so mDL is a building block of EUDI rather than a competitor; where the two differ is that EUDI also embraces the W3C-VC / OpenID web-credential approach, whereas plain mDL is rooted in the ISO mdoc/CBOR proximity model 6. ISO/IEC TS 18013-7 bridges the gap by defining online mdoc presentation over OpenID4VP 6.
Fun facts
- The QR code shown by an mDL holder contains no personal data — only the device's ephemeral public key and a menu of transfer methods; the actual licence data never travel through the barcode, only over the encrypted BLE/NFC/Wi-Fi-Aware session that the QR bootstraps 6.
Status
Actively rolling out. As of mid-January 2026, 21 U.S. states plus Puerto Rico had ISO/IEC 18013-5-based mDL programs that the TSA accepts at checkpoints — Alaska, Arizona, Arkansas, California, Colorado, Delaware, Georgia, Hawaii, Illinois, Iowa, Kentucky, Louisiana, Maryland, Montana, New Mexico, New York, North Dakota, Ohio, Utah, Virginia and West Virginia 3. (Some states, e.g. Delaware's separate app and Mississippi, run non-ISO mobile-ID programs that TSA does not accept 3.) Roughly 41% of Americans live in states with a live mDL program and ~76% in states with one active or in development; TSA accepts mDLs at 250+ checkpoints via CAT-2 readers 3.
Sources
- ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO, 2021
- AAMVA Mobile DL Implementation Guidelines v1.3 — AAMVA
- Participating States and Eligible Digital IDs — TSA, 2026
- eudi-lib-android-verifier-core — Android SDK for verifying EUDI identity documents, ISO 18013-5 — EU Digital Identity Wallet (GitHub), 2025
- ISO 18013-5 Standard: What It Is And How It Works — Dock Labs
- Overview of ISO/IEC 18013-5: Innovations and Vulnerabilities in the mDL Standard — Pomcor, 2023
Deployments
No country reports mention this standard by name.
Regions / aggregations not mapped to a single country
- Universal