Mobile driver's licenses, usually shortened to mDLs, are digital credentials issued by a state DMV or national authority and stored on a phone, built to the ISO/IEC 18013-5 standard. Several US states, the UK, the EU (through eIDAS 2.0's digital identity wallet framework), and a growing list of other jurisdictions have deployed or are actively piloting them. The standard's headline feature is selective disclosure: an mDL doesn't have to reveal every field it contains just because it's revealing one.
What selective disclosure actually means at the protocol level
An mDL's data is organized into individually signed elements rather than one signed blob. The issuing authority (the DMV) signs each data element (date of birth, address, license class, photo) separately, all under one document-level certificate chain. When a verifier requests information, the holder's device can present just the requested elements along with a cryptographic proof that they came from the same signed document, without transmitting the elements that weren't asked for.
This is the same underlying idea as SD-JWT selective disclosure, applied to a physical-ID use case instead of a general-purpose token: prove a subset of claims came from a trusted issuer without revealing the rest of the claim set, and without the verifier needing to contact the issuer to check.
A properly implemented mDL age verification transmits a single boolean: over-21, yes or no, cryptographically signed by the state. Not the date of birth. Not the address. Not the license number. The verifier's device never even receives the underlying data it would need to compute the answer itself.
The part the cryptography can't enforce
The standard defines how to make a request narrow. It does not, and cannot, force a verifier to actually request the narrow thing. An age-gated retail kiosk asking for "over 21: yes/no" is using the standard as designed. An age-gated retail kiosk that requests full name, date of birth, address, and photo, and gets it because the presentation flow allows the verifier to ask for whatever fields it wants, is technically also using the standard as designed, just for a much broader request than the use case requires.
This mirrors a pattern we've written about before with app permission requests: the platform gives an app the ability to ask for a narrow scope, and whether it does depends on the app's own incentives, not on anything the platform enforces. mDL adds a genuine improvement over a physical ID in that the holder's app can show, before any data leaves the device, exactly which fields a given verifier is requesting, and the holder can decline. A bouncer glancing at a paper license has no equivalent moment of informed consent, because the whole card is already in their hand.
Where the design gets more contested
| Concern | Standard's answer |
|---|---|
| Can the issuer see every time I show my ID? | By default, no. The standard's in-person presentation flow (device-to-device over Bluetooth or NFC) doesn't phone home to the DMV per transaction. Some deployments' online/remote presentation flows are a separate, more contested case. |
| Can verifiers correlate my visits across locations? | Depends on implementation. If a verifier reuses the same session or requests a static identifier field unnecessarily, correlation is possible even without help from the issuer. The standard supports rotating session-specific presentations, but doesn't require every verifier deployment to use them well. |
| What if I lose my phone? | Revocation exists at the issuer level, similar to a lost physical license. Unlike a physical license, most deployments still require a fallback physical credential, since not every verifier accepts mDL yet. |
| Is the underlying data model still centralized? | Yes. The DMV remains the sole issuer and signer of the underlying claims. mDL changes what's disclosed per transaction, not who controls the source record. It's a narrower disclosure model, not a decentralized identity model like DIDs. |
The online presentation case is the sharper edge
The in-person, device-to-device flow gets most of the attention because it's the one people picture: tap phones at a bar or a TSA checkpoint. ISO 18013-5 and its companion standard for remote use also define an online presentation flow, for verifying age or identity on a website without any physical proximity at all. This is where the privacy properties get noticeably weaker in practice. A remote flow typically routes through the issuer or a relying-party intermediary to complete the cryptographic handshake, which means the DMV, or whatever intermediary service the state contracts for this, is structurally positioned to see which website just verified someone's age, even if it never sees the specific content of what that website is.
Some proposed implementations address this with blinded or anonymized token schemes, similar in spirit to Privacy Pass, where the issuer can confirm a credential is valid without learning which specific relying party redeemed it. Whether a given state's rollout actually implements that stronger version, or falls back to a simpler flow that does let the issuer see the destination, varies by deployment and isn't something the ISO standard itself mandates. Anyone using an mDL for an online age check is trusting a more complex, less battle-tested part of the stack than the in-person tap, and it's the part regulators pushing mandatory online age verification (a wave of state laws now requiring it for adult content and some social media access) are leaning on hardest.
Why the honest framing is "convenience and surveillance risk, together"
Civil liberties groups pushing back on rapid mDL adoption aren't objecting to the cryptography, which is a real improvement over a wallet full of scannable barcodes. The objection is to what mDL makes newly convenient: a retailer, bar, or venue that previously had no reasonable way to log every ID check now has a frictionless digital handshake it can log by default, unless something in the deployment specifically stops it. Selective disclosure limits what's transmitted per transaction. It doesn't limit how many transactions happen, or what a verifier does with the yes/no answer it received, once received.
That distinction, between what a protocol makes possible and what a specific deployment chooses to do, comes up constantly in privacy engineering, and mDL is a clean current example of it. The standard is a genuine step forward from handing a stranger your entire wallet card. Whether any specific rollout delivers on that promise is a question about the app and the verifier's incentives, not about ISO 18013-5 itself.