If you have only ever seen someone hold up a phone at a checkout, a mobile driver’s licence looks like a picture of a licence. It is not. The picture on the screen is the least important part of it, and treating it as the credential is the single most common mistake businesses make when they first encounter one.
The short version
A mobile driver’s licence — an mDL — is a set of data fields about a person, signed by the authority that issued them, stored on that person’s phone. When a business checks it, the phone releases some of those fields to the business’s reader along with the issuer’s cryptographic signature. The reader checks the signature against the issuing authority’s published keys and knows the data has not been altered.
The international standard that defines all of this is ISO/IEC 18013-5, published in 2021. It specifies the data structures, the cryptography, and the ways a phone can hand data to a reader in person.
What actually gets exchanged
The credential is structured, not pictorial. Data lives in named elements inside a namespace — family_name, birth_date, portrait, document_number, and so on — inside a document type identified as org.iso.18013.5.1.mDL.
Crucially, the standard also defines pre-computed age attestations: age_over_18, age_over_21, and similar. These are boolean values the issuing authority signs at issuance. A business that only needs to know whether someone is old enough can request one of those instead of a birth date. It is a genuinely different question, not a polite version of the same one.
When a presentation happens, the phone releases only the elements the reader asked for, each accompanied by enough cryptographic material for the reader to verify it against the issuer’s signature. The reader learns nothing about the elements it did not request.
Why the on-screen image is not the credential
Most wallet apps will render something that looks like a licence, mainly so a human can recognise what they are holding. That rendering is not signed, is not verifiable, and can be produced by any screenshot tool. A business that accepts a visual as proof has gained nothing over a physical card and has arguably lost something, since a convincing fake image is far easier to produce than a convincing fake card.
The verifiable path requires a reader: a device that requests specific elements and validates the response cryptographically. There is no way to get the security property by looking.
Who issues them, and who decides they are real
mDLs are issued by state motor vehicle authorities, the same bodies that issue physical licences. Each issuing authority operates a certificate authority — an IACA — whose keys ultimately sign the credentials it issues.
A reader therefore needs a trustworthy list of legitimate issuing-authority keys. In the United States, AAMVA operates a Digital Trust Service that publishes exactly that: a signed list, called a VICAL, that a relying party downloads and loads into its reader before it starts accepting credentials. Without that list, a reader can check that a credential is internally consistent but cannot know whether the entity that signed it is a real motor vehicle authority.
Where you will encounter them
Two wallet ecosystems dominate today. Apple Wallet carries state-issued licences and IDs in a set of participating US jurisdictions, and Google Wallet does the same for its own published list of issuing authorities. Some states also distribute a mobile ID through their own app rather than through either wallet.
All of these are worth treating as separate facts. A state issuing a mobile ID is one thing; a particular wallet carrying it is another; and a particular verification product being able to accept it is a third. Vendors routinely blur those three together, and the blur is almost always in the vendor’s favour.
What this changes for a business
Three things, in order of how much they matter.
You can ask a narrower question. With a physical card, establishing that someone is over 21 means reading a card that also carries their name, address, and document number. With an mDL, the age attestation is a separate signed element you can request on its own.
The answer is cryptographic rather than interpretive. Door staff currently assess holograms, fonts, and card stock — a skill that degrades in bad light and under time pressure, and that does not transfer across fifty state formats. Signature validation does not have those failure modes.
Not everyone has one. Adoption is real and growing but partial, and it will remain partial for years. Any plan that assumes an all-mobile door is wrong. Mobile ID is an additional path alongside your existing manual procedure, not a replacement for it.
Where LaurelID fits
This section is Laurel’s own position rather than a description of the standard.
LaurelID is a verifier for exactly one question. It requests the age_over_21 element from an mDL, with the retention flag set to false, and returns one of three outcomes to staff. It never requests a name, a birth date, a portrait, or a document number, so those never enter the system at any point.
Checked-in owner-attested evidence records Apple Wallet and Google Wallet physical interoperability on Elo M51. Current physical-evidence, trust-binding, promotion, and production status are derived from the reviewed registry on the compatibility page.
Sources
- ISO/IEC 18013-5:2021 — Personal identification, ISO-compliant driving licence, Part 5: Mobile driving licence (mDL) application — ISO
- Mobile Driver License Digital Trust Service — AAMVA
- Add your driver's license or state ID to Apple Wallet — Apple
- Add your US Driver's License or State ID to Google Wallet — Google
How to read this article
Statements about standards, wallets, and issuing authorities are drawn from the primary sources listed above. Statements about what LaurelID does are ours, and are marked as such in the text. Nothing here is legal advice, and wallet or jurisdiction availability changes — check the source before relying on a detail.