# Mobile Driving Licence

> Source: https://docs.barcoder.ai/docs/standards/mobile-driving-licence
> research date 2026-06-03 · extracted at 2026-10-06
> Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards

Specifications:
- [ISO/IEC 18013-5:2021 — Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application](https://www.iso.org/standard/69084.html)
- [AAMVA Mobile DL Implementation Guidelines v1.3](https://www.aamva.org/getmedia/261ed16b-3f5c-4678-a2db-cc3016934234/MobileDLImplementationGuidelines-Version1-3.pdf)
- [Participating States and Eligible Digital IDs — TSA](https://www.tsa.gov/digital-id/participating-states)

## Overview

The **Mobile Driving Licence (mDL)** is the digital, phone-resident form of a driver license, defined by **ISO/IEC 18013-5:2021** <sup>[1][1]</sup>. 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 <sup>[1][1]</sup>. Unlike the physical card's [PDF417](https://docs.barcoder.ai/docs/standards/pdf417) barcode (see [AAMVA DL/ID](https://docs.barcoder.ai/docs/standards/aamva-dl)), the mDL carries cryptographically signed attributes that the holder can **selectively disclose**, and it is engaged through a **[QR Code](https://docs.barcoder.ai/docs/standards/qr-code)** (or NFC tap) rather than carried *in* a barcode <sup>[6][6]</sup>.

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](https://docs.barcoder.ai/docs/standards/eudi-wallet) <sup>[6][6]</sup>. The [QR Code](https://docs.barcoder.ai/docs/standards/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 <sup>[6][6]</sup>.

## 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 <sup>[1][1]</sup>. 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 <sup>[6][6]</sup>. ISO/IEC 18013-5 thus covers proximity presentation while ISO/IEC TS 18013-7 covers online presentation <sup>[6][6]</sup>.

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](https://docs.barcoder.ai/docs/standards/aamva-dl) standard <sup>[2][2]</sup>.

## 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`) <sup>[6][6]</sup>. CBOR's compact binary encoding keeps the payload small enough to move over short-range links <sup>[6][6]</sup>.

**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 <sup>[6][6]</sup>. 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 <sup>[6][6]</sup>. This is the mechanism for **selective disclosure** and data minimization <sup>[6][6]</sup>.

**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](https://docs.barcoder.ai/docs/standards/qr-code)** the reader scans, or over an NFC tap <sup>[6][6]</sup>. The reader and device then perform an **ECDH** key agreement using ephemeral keys to establish an encrypted session <sup>[6][6]</sup>.

**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** <sup>[6][6]</sup>.

**Three mandatory security mechanisms for device retrieval** <sup>[6][6]</sup>:
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 <sup>[7][7]</sup>.

## Use cases

- **Roadside / traffic stops** — proximity presentation to law enforcement, the original driving-licence use case <sup>[1][1]</sup>.
- **Airport security** — TSA accepts ISO/IEC 18013-5 mDLs at checkpoints using CAT-2 credential-authentication readers <sup>[3][3]</sup>.
- **Age and identity verification** — selective disclosure lets a holder prove "over 21" without revealing the full record <sup>[6][6]</sup>.
- **Account opening / remote KYC** — online presentation via ISO/IEC TS 18013-7 and OpenID4VP <sup>[6][6]</sup>.

## 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 <sup>[4][4]</sup>.
- **`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 <sup>[6][6]</sup>.
- **AWS reference architecture** — AWS documents building an ISO/IEC 18013-5 mDL solution using AWS Private CA and AWS KMS for the issuer PKI <sup>[6][6]</sup>.
- Multiple state issuers and the **Apple Wallet** / **Google Wallet** platforms support adding ISO/IEC 18013-5 mDLs in participating U.S. states <sup>[3][3]</sup>.

## Comparison

Versus the physical-card **[AAMVA DL/ID](https://docs.barcoder.ai/docs/standards/aamva-dl) [PDF417](https://docs.barcoder.ai/docs/standards/pdf417)**: the [PDF417](https://docs.barcoder.ai/docs/standards/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](https://docs.barcoder.ai/docs/standards/qr-code)/NFC rather than carried in the barcode <sup>[1][1], [6][6]</sup>. The two coexist — AAMVA maintains both the card-design standard and the mDL guidelines <sup>[2][2]</sup>.

Versus the **[EUDI Wallet](https://docs.barcoder.ai/docs/standards/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 <sup>[6][6]</sup>. ISO/IEC TS 18013-7 bridges the gap by defining online mdoc presentation over OpenID4VP <sup>[6][6]</sup>.

## 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 <sup>[6][6]</sup>.

## 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 <sup>[3][3]</sup>. (Some states, e.g. Delaware's separate app and Mississippi, run non-ISO mobile-ID programs that TSA does not accept <sup>[3][3]</sup>.) 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 <sup>[3][3]</sup>.

## Sources

[1]: https://www.iso.org/standard/69084.html
[2]: https://www.aamva.org/getmedia/261ed16b-3f5c-4678-a2db-cc3016934234/MobileDLImplementationGuidelines-Version1-3.pdf
[3]: https://www.tsa.gov/digital-id/participating-states
[4]: https://github.com/eu-digital-identity-wallet/eudi-lib-android-verifier-core
[6]: https://www.dock.io/post/iso-18013-5
[7]: https://pomcor.com/2023/10/27/overview-of-iso-iec-18013-5-innovations-and-vulnerabilities-in-the-mdl-standard/

1. [ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application](https://www.iso.org/standard/69084.html) — ISO, 2021
2. [AAMVA Mobile DL Implementation Guidelines v1.3](https://www.aamva.org/getmedia/261ed16b-3f5c-4678-a2db-cc3016934234/MobileDLImplementationGuidelines-Version1-3.pdf) — AAMVA
3. [Participating States and Eligible Digital IDs](https://www.tsa.gov/digital-id/participating-states) — TSA, 2026
4. [eudi-lib-android-verifier-core — Android SDK for verifying EUDI identity documents, ISO 18013-5](https://github.com/eu-digital-identity-wallet/eudi-lib-android-verifier-core) — EU Digital Identity Wallet (GitHub), 2025
6. [ISO 18013-5 Standard: What It Is And How It Works](https://www.dock.io/post/iso-18013-5) — Dock Labs
7. [Overview of ISO/IEC 18013-5: Innovations and Vulnerabilities in the mDL Standard](https://pomcor.com/2023/10/27/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