Mobile Driving Licence (mDL) Guide: ISO 18013-5 and -7

A mobile driving licence only adds security over a plastic card if the relying party verifies it cryptographically; a verifier that looks at a phone screen has accepted a picture that anyone can fake. Mobile driving licences (mDLs) built on ISO/IEC 18013-5 carry issuer-signed data, a key bound to the holder's device and encrypted transfer, which together give stronger evidence than a physical card and let holders share only what a transaction needs. This guide explains the mdoc data model, proximity and online presentation, the trust chain from issuing authority to reader, US deployment and TSA acceptance, wallet support, privacy design, and how a relying party integrates and measures an mDL programme. It is written for identity, fraud and product teams at banks, retailers, venues, government services and anyone building a verifier.

Key takeaways

Verify, do not view. Security comes from checking the issuer signature, the device signature and the session; a visual check of the screen gives none of it, and AAMVA warns that screen-only "flash pass" methods carry significant fraud risk.
Trust is a key list, not a database lookup. Readers validate data against issuing authority root certificates (IACAs), which in the US are published in the AAMVA Digital Trust Service VICAL; the issuer is not contacted at presentation time.
Selective disclosure is built in. Each data element is separately hashed and signed, so a reader can ask for age_over_21 alone, and the holder consents on the device before anything is released.
Two presentation modes, one data model. ISO/IEC 18013-5 covers in-person (proximity) presentation and ISO/IEC TS 18013-7 covers presentation over the internet, which wallets now deliver through OpenID4VP and the browser Digital Credentials API.
An mDL is a credential, not identity proofing. It proves what the issuer verified at enrolment and that the presenting device holds the bound key; relying parties still decide how to bind the person in front of them, and what assurance their use case needs.

Standards and building blocks

ISO/IEC 18013-5:2021, published in September 2021, "specifies the interface between the mDL and mDL reader and the interface between the mDL reader and the issuing authority infrastructure". It defines a general structure called an mdoc; the mDL is one document type of it. ISO lists the 2021 edition as due to be replaced by a revised edition now at Draft International Standard stage, so check which edition your readers and issuers implement.

Specification	What it covers	Who relies on it
ISO/IEC 18013-5:2021	mDL data model, device engagement, proximity transfer (BLE, NFC, Wi-Fi Aware), session encryption, issuer and device authentication, optional reader authentication, IACA certificate profiles	Issuers, wallet makers, reader vendors
ISO/IEC TS 18013-7:2025	Add-on functions; its abstract names "presentation of a mobile driving licence to a reader over the internet"	Online relying parties, wallets
ISO/IEC 23220 series	Generic mdoc building blocks for other identity documents; Apple's verifier reads "ISO 18013-5 or ISO 23220-1 compliant mobile IDs"	Issuers of photo ID and national ID in mdoc form
AAMVA mDL Implementation Guidelines	US profile: AAMVA namespace, data elements such as `DHS_compliance`, certificate and security expectations	US and Canadian jurisdictions, relying parties
AAMVA Digital Trust Service (DTS)	Publishes the VICAL, the list of verified issuing authority public keys	Every US relying party
OpenID4VP 1.0 and W3C Digital Credentials API	Request and response protocol for online presentation through the browser or operating system	Web and app relying parties

How a proximity presentation works

The in-person flow is designed so that the verifier never needs to touch the holder's phone and neither side needs an internet connection. AAMVA's law enforcement FAQ states that "At transaction time, both the mDL and mDL reader can operate offline."

Device engagement: the holder opens the wallet and presents a QR code or taps the phone on the reader over NFC. The engagement structure carries the wallet's ephemeral public key and the transport options; AAMVA notes the QR code "only contains enough information to establish a secure connection", not licence data.
Session establishment: the reader generates its own ephemeral key, and both sides derive session keys by elliptic curve Diffie-Hellman. All further messages are encrypted (AES-256-GCM in 18013-5), over BLE, NFC or Wi-Fi Aware.
Request: the reader asks for specific data elements and, for each, whether it intends to retain the value. If reader authentication is used, the request is signed with a reader certificate so the wallet can show who is asking.
Consent: the wallet shows the holder what is requested (and by whom, when authenticated) and requires user authentication, such as a passcode or biometric, before release.
Response: the wallet returns the approved elements, the issuer-signed mobile security object (MSO) and a device signature or MAC over the session transcript.
Verification: the reader validates the document signer certificate to a trusted IACA, checks the MSO signature and validity dates, recomputes each element's digest, and checks the device authentication against the device key in the MSO.

18013-5 also defines server retrieval, where the reader fetches data from the issuer. AAMVA's FAQ says online retrieval is possible but discouraged, and offline device retrieval is the privacy-preserving default because the issuer never learns where the licence was used.

Security mechanisms and what they stop

Mechanism	How it works	Attack it addresses
Issuer data authentication	The MSO holds salted digests of every data element, the device public key and validity dates, signed by a document signer certificate chained to the issuing authority's IACA root	Forged or edited data, fake licences built in an app
mdoc (device) authentication	The wallet proves possession of the private key named in the MSO by signing or MACing the session transcript	Copying the signed data to another phone (cloning), replay of a captured response
Session encryption	Ephemeral ECDH keys per transaction, encrypted messages over the chosen transport	Eavesdropping on BLE or NFC, tampering in transit
Reader authentication (optional)	Reader signs its request with a certificate the wallet can check against a trust list	Rogue readers harvesting data, over-asking by unknown verifiers
Holder authentication on the device	Wallet requires passcode or biometric before release; AAMVA expects at minimum a code	Use of a lost or stolen phone
Portrait in the response	Signed portrait image returned for comparison with the person present	A different person presenting a legitimate device

Device authentication proves the phone holds the key; only the portrait comparison (by a person or a face match) links the credential to the human in front of you. Decide that binding step deliberately. See the Biometrics Guide.

The mdoc data model and selective disclosure

The mDL document type is org.iso.18013.5.1.mDL, and its core namespace is org.iso.18013.5.1. Data is CBOR-encoded, and each element is a separate signed item, which is what makes element-level disclosure possible.

Element (namespace org.iso.18013.5.1)	Typical use	Disclosure advice
`age_over_NN` (for example `age_over_18`, `age_over_21`)	Age-restricted sales, venue entry	Request this instead of `birth_date`; issuers choose which NN values to include
`portrait`	Binding the holder to the credential	Request for in-person checks; do not retain unless legally required
`family_name`, `given_name`, `birth_date`	Customer identification, account opening	Request only where regulation requires identity, not just age
`document_number`, `issue_date`, `expiry_date`, `issuing_authority`, `issuing_country`	Audit trail, KYC records	Retain only what record-keeping rules demand
`resident_address`	Address verification	High sensitivity; request rarely
`driving_privileges`	Car rental, employer driver checks	Only where driving entitlement is the purpose
`DHS_compliance` (AAMVA namespace)	REAL ID status; federal acceptance requires value "F"	Needed by federal agencies, rarely by others

Intent to retain: every requested element carries a flag saying whether the verifier will store it. Google's verifier documentation tells developers to set it to true only "if you are saving the value of the field". Treat the flag as a declaration that must match your privacy notice and records of processing.
Zero-knowledge proofs: Google's online verifier supports a ZKP format (mso_mdoc_zk) for "verifying a user is over 18 without seeing their exact birthdate". It is an emerging option; check wallet and issuer support before relying on it.
Linkability: the MSO signature and device key are the same in every presentation of a given MSO, so colluding verifiers could correlate a holder. Issuers that provision several short-lived MSOs and rotate them reduce this; ask your issuers what they do.

For age-gated services, see the Age Assurance Guide, which compares mDL-based checks with estimation and other methods.

Trust: IACAs, the VICAL and the AAMVA Digital Trust Service

Every issuing authority runs an Issuing Authority Certificate Authority (IACA) whose root signs its document signer certificates. A reader must hold the IACA roots it trusts before the transaction. In the US, AAMVA's DTS collects public keys from issuing authorities and publishes them in the VICAL (Verified Issuer Certificate Authority List). AAMVA states that "All relying parties can download the VICAL and load it in their mDL reader technologies", that access is free, that the list is continuously updated, and that "The download must take place prior to engaging with an mDL". Downloading means accepting the DTS terms, and AAMVA states the DTS does not receive or store holders' personal data.

Validate the VICAL itself: check its signature before importing keys, and automate refresh so new jurisdictions and rotated keys arrive without manual work.
Pin by use case: a bar may accept any VICAL issuer; a federal agency must also check that the state holds a TSA waiver (6 CFR 37.8(a)).
Handle validity, not just signatures: the 2021 edition relies on MSO validity periods (validFrom, validUntil) rather than an online status check, so reject expired MSOs and ask issuers how quickly a suspended licence stops presenting.

Outside the US, the same pattern applies with other trust lists, and the EU wallet framework uses EU trusted lists. See the Machine Identity, PKI and Certificate Lifecycle Guide for certificate handling practice.

Online presentation: 18013-7, OpenID4VP and the Digital Credentials API

ISO/IEC TS 18013-7:2025 (second edition, May 2025) extends the mDL to presentation over the internet. In practice, the large wallets expose it through the operating system and browser:

Google Wallet: Google's verifier documentation uses OpenID4VP 1.0 over the Digital Credentials API, with a DCQL query naming the doctype, namespace and elements. Responses are encrypted to the relying party's key (ECDH-ES on P-256, returned as a JWE). Signed requests (ES256 with an x5c chain) are "required to enable Cross Device flows". Production use requires registering the relying party with Google and accepting its relying party terms.
Verification steps online: Google lists building the SessionTranscript from the handover data, validating issuerSigned data "against the official IACA certificates", checking the MSO signature and value digests (18013-5 clause 9.1.2) and the device signature (clause 9.1.3). Skipping IACA validation leaves the integration open to spoofed credentials.
Apple Wallet: Apple offers ID Verifier for in-person checks on iPhone "without the need for external hardware", and a separate Verify with Wallet API that Apple asks businesses to consider before requesting ID Verifier data transfer. ID Verifier has a Display Only mode, where "Apps don't read or store the ID information", and a Data Transfer entitlement granted per app to businesses with a legal age or identity verification requirement.
Cross-device flows: when a user on a laptop presents from a phone, the request travels by QR code and a Bluetooth proximity check run by the platform. The signed request and session transcript bind the response to that relying party and that session, which limits relay to a phishing site.

Deployment status: US states, TSA, wallets, EU and UK

Area	Status confirmed from primary sources
TSA acceptance	TSA's digital ID page (checked 17 October 2026) accepts digital IDs "through platforms such as Apple Wallet, Google Wallet, and Samsung Wallet or a state-issued app", read by tapping the device or scanning a QR code at Credential Authentication Technology (CAT-2) units, and states "all passengers must still carry a physical ID for verification". The participating-state list is published as a graphic on that page. On 7 January 2025 TSA named 14 jurisdictions, including Puerto Rico.
REAL ID waiver rule	Effective 25 November 2024. States may apply for a temporary waiver; a certificate is "valid for a period of three years from the date of issuance" (37.9(e)(1)). It incorporates 19 standards, including ISO/IEC 18013-5:2021, FIPS 140-3 and NIST SP 800-63B. Federal agencies must "use an mDL reader to retrieve mDL data" and validate it per 18013-5; acceptance is voluntary.
Apple ID Verifier	Reads 18013-5 and 23220-1 mobile IDs; device region United States, Puerto Rico or Japan; device and iOS minimums vary by issuer.
NIST NCCoE	Digital Identities: mDL project with 32 participants, including AAMVA and the OpenID Foundation, covering KYC/CIP account opening and government services; NIST SP 1800-42A was released as an initial public draft.
European Union	Under Regulation (EU) 2024/1183, member states must offer a European Digital Identity Wallet by 24 December 2026; the wallet architecture supports ISO mdoc alongside SD-JWT VC. See the Digital Identity Wallets Guide.
United Kingdom	The government announced on 21 January 2025 that a digital driving licence would be "piloted later in 2025" in the GOV.UK Wallet, optional and underpinned by GOV.UK One Login. We could not confirm the current rollout status or the standard used from a primary source; check before planning acceptance.

Where identity fits: assurance and relying party decisions

An mDL tells you that a government issuer proofed this person at enrolment, that the data is unaltered, and that it came from the device the issuer provisioned. It does not, on its own, prove the presenter is the subject; the holder's device unlock and your portrait check do that. Treat an mDL as strong evidence inside an identity proofing process, not as the whole process. See the Identity Proofing and KYC Guide.

Use case	Choose	Why
Age check at a till or door	Proximity mDL, `age_over_NN` plus portrait, nothing retained	Strongest evidence for least data; no internet needed
Online age gate	Online mDL with `age_over_NN` only, ZKP where offered	Avoids collecting birth dates and document images
Bank account opening (CIP/KYC)	Online mDL for core attributes, plus liveness or face match to the signed portrait, and document scan fallback	Signed attributes beat OCR of a photographed card; fallback covers holders without an mDL
Account recovery	mDL presentation matched to attributes already on file	Resists help desk social engineering better than knowledge questions
Federal official purpose	Proximity reader, waiver state check, `DHS_compliance` = "F"	Required by 6 CFR 37.8

Small versus large organisations: a small retailer can use a certified handheld reader or Apple's ID Verifier Display Only mode and never touch the data. A bank or platform will integrate OpenID4VP directly, manage its own relying party certificates and VICAL refresh, and feed results into its fraud and onboarding systems. See the Customer IAM (CIAM) Guide and the Account Recovery and Help Desk Security Guide.

Implementation steps

Define the minimum data per journey, its retention rule and lawful basis.
Choose channels: proximity readers, online via wallets, or both; confirm which wallets and issuers your customers hold.
Build trust management: automate signed VICAL import, add any non-US trust lists, and alert on refresh failure.
Integrate in sandbox: Google provides pre-trusted test keys; test valid, expired, wrongly signed, tampered-digest and replayed responses, and confirm each is rejected.
Pilot with a fallback: run alongside your existing document check for one journey, compare outcomes, and keep the old route as the rollback path.
Register for production with wallet providers, publish privacy notices that match your intent-to-retain flags, and train staff that a screen alone is not acceptance.

Detection and measurement

Log every verification outcome: issuer, document signer certificate, MSO validity, digest check, device authentication result, elements requested and retained, and channel, without logging the attribute values themselves.
Alert on: signature failures from one source, repeated presentations of the same document number across many accounts, responses from issuers not in the current VICAL, and readers or apps using stale trust lists.

Metric	What it shows
Cryptographic verification rate (verified presentations / all mDL acceptances)	Target 100%; anything lower means visual acceptance is happening
Verification failure rate by reason	Expired MSOs, unknown issuers and tampering attempts need different responses
VICAL age at time of verification	Trust list freshness across readers and services
Elements requested per journey versus the approved minimum	Data minimisation drift
Fallback rate to document scan	Wallet coverage among your customers
Fraud rate per verification method	Whether mDL journeys outperform document capture

Common failure patterns

Accepting the screen: staff look at a wallet card, a screenshot or a state app animation. AAMVA says these methods "carry significant risk and vulnerabilities for fraud and counterfeiting". Accept only reader-verified presentations.
Checking the signature but not the chain: verifying the MSO with the certificate it carries, without chaining to a trusted IACA, accepts any self-signed fake. Google's documentation calls this out directly.
Skipping device authentication: without it, a copied MSO and data set replay perfectly from a cloned app.
Over-asking: requesting full name, address and birth date for an age check, then retaining them, turns a privacy-preserving credential into a data liability.
No portrait binding: trusting device authentication alone lets someone present a relative's unlocked phone.
Stale trust lists: readers loaded once at deployment reject new states and keep trusting rotated or withdrawn keys.

Framework mapping

Control area	NIST CSF 2.0 / SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	Other
Identity proofing using mDL evidence	PR.AA-02 / IA-12	A.5.16 Identity management	NCCoE SP 1800-42 (draft)
Cryptographic verification and trust lists	PR.DS / SC-12, SC-13, SC-17	A.8.24 Use of cryptography	ISO/IEC 18013-5 clause 9
Transmission protection	PR.DS-02 / SC-8	A.8.24	18013-5 session encryption
Data minimisation and retention	No CSF privacy function / PT-2, PT-3, SI-12	A.5.34 Privacy and protection of PII	GDPR Art. 5(1)(c)
Verification logging	DE.CM / AU-2, AU-12	A.8.15 Logging	6 CFR 37.8(d) threat reporting for agencies

Practitioner checklist

Accept mDLs only through a reader or API that verifies issuer signature, IACA chain, MSO validity, digests and device authentication.
Automate signed VICAL import and alert when any reader's trust list is older than your threshold.
Request the minimum elements per journey, prefer age_over_NN, and set intent-to-retain flags that match your privacy notice.
Bind the holder with the signed portrait, by trained staff or a face match with liveness.
Use reader authentication certificates where wallets support it, and protect their private keys like any signing key.
Keep a fallback route and measure fallback rate, failure reasons and fraud by method.
Register with each wallet provider for production and track their terms and certificate renewals.
For federal acceptance, check TSA's waiver list and DHS_compliance before relying on an mDL.

Mobile Driving Licence (mDL) Guide