What Is ISO/IEC 18013-5, and How Does the mDL Standard Actually Work?

A physical driver’s license works in another state for a mundane reason: everyone roughly agrees what one looks like, what data it carries, and how to check it. Verifiable digital credentials need the same agreement, written down precisely enough that software can act on it. Without a shared standard, fifty state programs become fifty islands, and a bar in Denver has no reliable way to read a license issued in Sacramento. ISO/IEC 18013-5 is that written agreement for the mobile driver’s license.

This post is a survey for people evaluating or planning digital DMV credentials. It walks through the four pieces that matter (the data model, device engagement, the issuer signature, and offline verification) and explains why standardization, not any single feature, is the point.

What ISO/IEC 18013-5 actually defines

ISO/IEC 18013-5:2021 defines two interfaces: one between the mDL on a person’s device and the reader that verifies it, and one between that reader and the issuing authority’s infrastructure. In plain terms, it specifies how the credential is packaged and how the in-person handshake works, so that a reader and a phone built by different vendors can still understand each other.

At its core is a standardized data model. mDL data lives in a defined namespace, org.iso.18013.5.1, with a fixed set of elements. Mandatory fields include name, portrait, date of birth, issue and expiry dates, and driving privileges; optional fields include sex, height, and age attestations. Because the field names and formats are specified rather than left to each vendor, a reader can identify what “date of birth” means and where to find it, without a per-state mapping or custom integration for each issuer.

How a phone engages a reader

Device engagement is the opening handshake: the phone and the reader establish a connection and a shared encryption key before any data moves. ISO/IEC 18013-5 supports two ways to start it. The reader can scan a QR code shown on the holder’s screen, or the two devices can tap over NFC (Near Field Communication). Either path carries the information needed to set up a secure channel, typically Bluetooth Low Energy or Wi-Fi Aware, over which the actual data transfer happens.

The sequence matters for privacy. Engagement establishes an encrypted session first, then the reader requests specific fields, and only the requested fields are returned. That design supports selective disclosure: a verifier checking age can receive a yes/no answer to “is this person over 21” without seeing the date of birth or address. The mechanics of that handshake are worth their own treatment; here, it is enough to know that engagement is standardized, encrypted, and designed to minimize what crosses the wire.

How the issuer’s signature makes the data verifiable

The reason a reader can trust mDL data is cryptography, not the phone. When an issuing authority provisions an mDL, it signs the data with its private key and packages it in an issuer-signed structure, the Mobile Security Object, that includes a digital signature over the credential’s contents. That signature serves two purposes: it indicates that the data came from the issuing authority and that it has not been altered since issuance.

At verification time, the reader checks that signature against the issuing authority’s public key. If a single field had been tampered with, the signature would fail. This is the same public-key infrastructure that secures much of modern digital government, applied to a driver’s license. The credential on the phone is a signed, verifiable object, and its trustworthiness comes from the issuer’s key, not from possession of the device. For why the format that carries that signed data is itself a consequential decision, see what a credential format is and why it matters which one you choose.

How verification works offline

One of the standard’s most useful properties is that verification does not require a live connection to the DMV. The reader does not need to ask “is this license real?” over a network. Instead, it needs one thing in advance: a list of the trusted public keys belonging to issuing authorities. With those keys pre-loaded, the reader can validate the issuer’s signature entirely on its own device.

That means a roadside check, a TSA lane with weak connectivity, or a venue with no network can still verify an mDL. It also means the issuer does not learn where or when a person presents their credential, because the transaction does not need to touch the issuer’s servers. Offline verification is a first-class design goal of ISO/IEC 18013-5, not a fallback bolted on afterward, and it is what makes in-person use practical at scale. The trust model is straightforward: a verifier trusts the issuing authority’s keys, not the holder’s phone.

Why one standard turns fifty programs into one ecosystem

Here is the payoff for digital ID interoperability. When every state builds its mDL to the same standard, a conformant reader can verify a credential from any of them without a prior relationship; it only needs that issuer’s public key on its trusted list. Cross-jurisdictional digital identity is moving from a series of one-off integrations to a single, shared model.

That shift is underway. As of mid-2026, roughly 20 U.S. states plus Puerto Rico issue mobile IDs that the TSA accepts at participating airport checkpoints, a number that continues to grow as more states launch programs. SpruceID helped build the State of California’s open-source mobile wallet, hosted a fully-remote interoperability test event for mDL implementations, and worked with the NIST National Cybersecurity Center of Excellence (NCCoE) on mDL verification in financial services. The common thread across all of it is conformance to shared standards. Standards are what make credentials recognizable across state lines, a point we develop in how cross-state credential recognition works.

What the standard does not solve

ISO/IEC 18013-5 governs in-person, proximity presentation. It does not, on its own, cover presenting an mDL over the internet; that is the job of the companion standard ISO/IEC 18013-7. It also does not decide policy questions: which fields a verifier is allowed to request, how trusted-issuer key lists are governed, or how a program handles a lost device. Those are governance and implementation choices layered on top of the standard. What 18013-5 provides is the technical foundation that supports the rest. For the broader case on why this matters to government service delivery, see what interoperability in government digital services is and why it’s not optional.

Working with SpruceID

SpruceID built the California DMV’s open-source mobile driver’s license wallet, hosted a fully-remote ISO/IEC 18013-5 interoperability test event, and partnered with the NIST NCCoE on mDL verification pilots. For agencies evaluating how to build a standards-conformant mDL program that verifiers in other states and industries can trust on day one, get in touch with our team.

About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.