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), 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 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]:

1. Session encryption — the ECDH-derived session protects data in transit.
2. Issuer data authentication — verifying the issuer-signed MSO and per-element digests.
3. 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 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

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO, 2021
2. AAMVA Mobile DL Implementation Guidelines v1.3 — AAMVA
3. Participating States and Eligible Digital IDs — TSA, 2026
4. eudi-lib-android-verifier-core — Android SDK for verifying EUDI identity documents, ISO 18013-5 — EU Digital Identity Wallet (GitHub), 2025
5. ISO 18013-5 Standard: What It Is And How It Works — Dock Labs
6. 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