ISO/IEC 18013-5 Mobile Driver's License (mDL)

What it is

ISO/IEC 18013-5 defines the mobile driver's license (mDL): a driver's license or state ID issued to a phone wallet in a standardized, cryptographically verifiable format. A verifier can check it offline against the issuing authority's public key and receive only the fields it asked for. It is one of the most widely deployed verifiable credential formats because governments are shipping it into consumer wallets. The companion technical specification ISO/IEC TS 18013-7 extends presentation to websites and apps.

The data structure is called an mdoc, and it is not limited to licenses. The same format carries the EU's PID in the EUDI Wallet, and OpenID4VC uses the identifier mso_mdoc for it.

Status (November 2026)

Sources: the ISO catalogue pages for 18013-5 and TS 18013-7. Note that 18013-7 is a Technical Specification, not a full International Standard, which is why it can be revised quickly.

In the United States, AAMVA published version 1.6 of its mDL Implementation Guidelines on 30 June 2026, revising its over-the-internet appendix and its revocation guidance. AAMVA's Digital Trust Service (DTS) went live on 15 April 2024 with Utah and Maryland. It publishes a Verified Issuer Certificate Authority List (VICAL) that relying parties download before they read an mDL; the version at vical.dts.aamva.org was dated 5 November 2026 when we checked. AAMVA's public pages do not list participating jurisdictions, and we could not fetch TSA's checkpoint list directly, so see the United States digital ID page for the current state-by-state picture.

How it works

An in-person mDL transaction at a pharmacy counter:

1. Device engagement. The holder taps the phone (NFC) or shows a QR code. AAMVA notes these mechanisms were chosen because they only work at close range.
2. Session setup. Reader and phone derive an ephemeral session key, and data moves over a short-range transport such as BLE.
3. Request. The reader sends a DeviceRequest naming specific data elements, for example portrait and age_over_21. It can sign the request with a reader certificate (mdoc reader authentication) so the wallet knows who is asking. AAMVA forbids wallets from demanding reader authentication before releasing the mandatory elements.
4. Consent and response. The holder approves. The phone returns a DeviceResponse with the elements plus the mobile security object (MSO): a structure signed with the issuer's document signer certificate that holds a digest of every element and a validity period.
5. Verification. The reader chains the document signer to the issuer's IACA root certificate (from the VICAL in the US), recomputes the digests, and checks that the response was produced by the device the credential is bound to. AAMVA explains that 18013-5 requires each mDL to be cryptographically bound to the device it was provisioned on, and the reading protocol terminates if it is not, which stops copied mDLs.

Selective disclosure is built in because each element is hashed separately. AAMVA's guidelines require issuers to include an age_over_NN statement for every age question common in their jurisdiction, so a 20-year-old's mDL carries age_over_18=True and age_over_21=False and a bar learns nothing else. See selective disclosure and age verification.

Device retrieval versus server retrieval. 18013-5 requires device retrieval (data on the phone, works offline) and allows server retrieval (the reader fetches data live from the issuer). AAMVA's guidelines prohibit server retrieval in support of their no-tracking rule.

Online presentation (ISO/IEC TS 18013-7)

According to AAMVA's v1.6 Appendix C, the second edition of 18013-7 contains three protocols:

AAMVA also records work on an Annex D based on OpenID4VP 1.0 plus HAIP, and joint ISO and OpenID work toward a common internet protocol, with no timeline. The W3C Digital Credentials draft (Working Draft, 5 November 2026) registers both org-iso-mdoc (18013-7 Annex C) and the OpenID4VP 1.0 protocol identifiers, so a browser can broker either.

Who implements it

• Google Wallet: Google's developer documentation says it "supports ISO mdoc based Digital IDs over OpenID4VP (Version 1.0)" through the Digital Credentials API in Chrome.
• MATTR: its remote web verifier quickstart follows "OID4VP and ISO/IEC 18013-7:2025".
• Procivis: its standards page lists ISO/IEC 18013-5 proximity (NFC or QR engagement, BLE retrieval) and 18013-7 Annex B.
• walt.id: its feature list covers mso_mdoc and 18013-7 remote flows.
• SpruceID: its open-source SpruceKit Mobile libraries target mDL and verifiable credentials in mobile apps.

For verifier-side checks bundled into KYC, see identity verification vendors and the customer identity verification guide.

Security and privacy pitfalls

• Skipping the device binding check. Checking only the issuer signature accepts a replayed copy of the data. Verify that the response is bound to the device key and the current session every time.
• Relayed online requests. For app-to-app and online sharing, AAMVA requires protection against an attacker forwarding engagement or request data to a victim's wallet, by binding the presentment to the originating request channel (18013-7 clause 6.5). Prefer a protocol designed for it, such as 18013-7 Annex C over the Digital Credentials API, which the EU ARF credits with clear origin verification, over a custom deep link.
• Stale trust lists. Refresh the VICAL on a schedule; an unknown IACA should fail closed.
• Ignoring validUntil. AAMVA notes the MSO validity is what authenticates the mDL, separate from the license's printed expiry. Revocation handling changed in v1.6, so read that chapter.
• Linkability. AAMVA warns that long-lived metadata (hardware addresses, long-term public keys, session tokens) lets verifiers link transactions. The portrait is always shared in matched transactions, so anonymity there is limited.
• Over-asking. Requesting the full element set when age_over_21 would do defeats the design and raises your retention risk.
• Protocol drift online. 18013-7 Annex B is pinned to an old OpenID4VP draft. Test with the wallets you expect, and keep a fallback to document scan verification.

How it fits with the other standards

mDL and SD-JWT VC are the two credential formats the EU ARF names for the EUDI Wallet. OpenID4VCI can issue an mdoc and OpenID4VP can present one, and HAIP profiles both. mdoc does not use DIDs: trust comes from X.509 certificate chains (PKI) anchored in issuer lists like the VICAL or EU trusted lists.

Related

Guides: reusable identity and KYC with verifiable credentials, verifiable credentials implementation guide. Directories: digital IDs by country, United States, European Union, identity verification vendors. Standards: Verifiable Credentials, OpenID4VC, eIDAS 2 / EUDI Wallet, DIDs. Glossary: mobile driver's license, digital identity wallet, x.509, KYC. Ranking: best identity verification for enterprises.

Who wrote it

Browser-side presentation of mobile driving licences runs through the W3C Digital Credentials API, edited by Tim Cappalli. Wayne Chang worked on the California DMV programme that deployed one. More in the experts directory.