How Mobile ID Verification Works, Step by Step

An in-person mobile ID check takes a couple of seconds and involves five distinct steps. Understanding them is what lets you tell a real verification product from something that shows a picture on a screen.

1. Engagement

The phone and the reader have to find each other and agree on how to talk. In ISO/IEC 18013-5 this is called device engagement, and it carries the parameters needed to set up a secure session — including a public key from the phone.

Engagement can happen through a QR code the reader scans, or through an NFC tap. The tap is meaningfully better in a service setting: it is a deliberate physical act by the holder, it removes the ambiguity of which phone in a queue you are talking to, and it does not require anyone to aim a camera in bad light.

Whichever route is used, engagement does not carry the credential. It carries the setup for the conversation that follows.

2. The session

Once engagement completes, the actual data exchange runs over a separate transport. Bluetooth Low Energy is the common one for in-person checks: it has the range and throughput to carry a credential response, where NFC alone is constrained.

The session is encrypted, and its keys derive from the material exchanged during engagement. That binding matters: the response the phone produces is cryptographically tied to this session, which is what stops a captured response being replayed into a different exchange later.

3. The request

The reader now sends a request naming exactly what it wants: a document type, a namespace, and a list of data elements. For an mDL that is org.iso.18013.5.1.mDL and the org.iso.18013.5.1 namespace, and then whichever elements the business actually needs.

Each requested element carries an intentToRetain flag. This is the reader declaring whether it intends to store the value it is about to receive. It is part of the request the wallet can surface to the holder, which makes it a meaningful signal rather than an internal note.

This step is where privacy is won or lost. A reader that asks for the whole namespace has already collected everything, no matter what its retention policy says afterwards. A reader that asks for one age attestation has structurally limited what it can ever hold.

4. The response

The phone returns the requested elements, together with the issuer-signed structure that commits to their digests — the mobile security object. The response is also signed using a key bound to the device, which is what ties the credential to this phone rather than a copy of one.

Nothing about the elements the reader did not request is included.

5. Validation

Only now does the reader look at any values. A correct implementation checks, in order:

• that the issuer’s certificate chains to a trusted issuing-authority root;
• that the mobile security object’s signature is valid;
• that the digest of each received element matches the digest the security object committed to;
• that the device signature is valid and binds the response to this device;
• that the response belongs to the session that requested it, and is within validity windows.

If any of those fail, there is no answer to read. A well-built verifier treats that as an explicit cannot verify state rather than an approximation of a result.

Where the trust list comes from

A signature is only meaningful if you know whose it is. Readers therefore load legitimate issuing-authority keys ahead of time. Laurel’s reviewed US trust inputs are either the signed VICAL published by AAMVA’s Digital Trust Service or exact certificate bytes independently obtained from an issuing authority’s official endpoint. Trust never comes from the credential being presented.

The size and provenance of a reader’s trust set is one of the more revealing things to ask a vendor about. A reader that accepts device-supplied roots, imported roots, or test certificate authorities can be made to say “valid” about a credential nobody issued.

What this means when you are evaluating a product

Ask four questions:

1. What exactly does the reader request? Get the document type, namespace, and element list, not a summary.
2. What is intentToRetain set to? If the answer is “we don’t set it,” the product has not thought about this.
3. Where does the trust list come from, and what else is accepted? The second half of that question is the interesting one.
4. When is the claim read? Reading a value before validation completes is a real implementation mistake, and a vendor who can answer this precisely has probably not made it.

How LaurelID answers those four

This section describes Laurel’s own product.

LaurelID engages over NFC and completes over BLE. Its entire request is org.iso.18013.5.1.mDL / org.iso.18013.5.1 / age_over_21 with intentToRetain set to false. Production trust uses only reviewed AAMVA VICAL authorities or exact issuing-authority certificate bytes from official endpoints; it does not accept Android system or user certificate authorities, credential-supplied roots, imported roots, or test IACAs. The age claim is read only from the verified document model, after every check above has passed.

The result is one of three outcomes shown to staff — and one aggregate counter increment on the platform. Details are on the verifier product page.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. In-person acceptance of digital credentials — Google
3. Present your driver's license or state ID from Apple Wallet — Apple
4. For relying parties — mDL Digital Trust Service — AAMVA