How Offline Mobile ID Verification Works

“Works offline” is a claim worth interrogating, because it can mean four different things and only one of them is interesting.

Why the check itself needs no network

In the ISO/IEC 18013-5 device retrieval model, the phone hands data directly to the reader over a local transport — NFC for engagement, then typically BLE for the data exchange. There is no server in the path. Google’s own documentation splits in-person acceptance from online acceptance for exactly this reason: they are different flows with different requirements.

Everything the reader needs to reach a verdict is either in the response or already on the reader:

• the issuer-signed structure committing to element digests — in the response;
• the released elements — in the response;
• the device signature binding the response to the phone — in the response;
• the list of legitimate issuing authorities — already loaded on the reader.

That last item is the one that makes offline possible. AAMVA’s guidance to relying parties is explicit that the trust list is downloaded and loaded into reader technology before engaging with a credential. Trust is provisioned in advance, not fetched per check.

What connectivity actually affects

Three things, none of them the verdict:

Trust freshness. The list of legitimate issuers changes as authorities are added, rotated, or withdrawn. A reader that has been offline for a long time is working from an increasingly stale picture of who is legitimate.

Delivery of operational records. If your verifier reports anything to a platform — counts, health, diagnostics — that delivery obviously needs a network. What matters is whether it queues or drops.

Management actions. Provisioning a new device, changing configuration, suspending or revoking a device, and rotating credentials all require the device to be reachable.

The stale-trust question

This is where implementations differ, and where a good one is distinguishable from a convenient one.

If trust material can be used indefinitely offline, then withdrawal and rotation stop meaning anything. A device that has been off the network for a year would still honour a certificate authority that was removed eleven months ago.

If trust material has a bounded offline life, the reader eventually stops producing decisions and says so. That is inconvenient and correct: an age control that reports “I cannot verify right now” is doing its job, while one that silently answers from stale authority is not.

Ask any vendor two questions: how long can your reader operate on cached trust material, and what does it do when that window expires? “Indefinitely” and “it keeps working” are the wrong pair of answers.

The reporting question

If a check happens offline and its record is never delivered, your reporting is silently wrong. If it is delivered twice — which is what happens when a device retries after an ambiguous failure — your reporting is silently inflated.

A well-built system handles this with three properties working together:

1. A durable local queue with explicit bounds, so a long outage does not lose accepted records and does not grow without limit.
2. A stable identity per record, assigned when it is queued and preserved across retry, restart, and reboot.
3. Idempotent processing on the server, so receiving the same identity twice has the same effect as receiving it once.

Together, those give correct aggregate numbers over an unreliable network. Note that this is not the same as “exactly-once delivery,” which is not achievable over an unreliable network — a vendor claiming it is describing something they have not thought carefully about. The achievable and useful property is exactly-once effects.

Also worth asking: what happens when the queue fills? Silently discarding the oldest records is the easy implementation and the wrong one, because it converts an operational problem into an invisible data problem.

What to ask about offline behaviour

• Does a check require a network round trip? (If yes, it is not device retrieval.)
• How long can the reader work on cached trust material, and what happens at expiry?
• Are outcomes queued locally? With what bounds?
• What happens to counts when a device retries after an ambiguous failure?
• What happens when the queue is full?

How LaurelID answers

Laurel’s own implementation.

Verification is entirely local, so an outage does not stop checks — it delays reporting. Completed outcomes enter a bounded transactional on-device outbox (5,000 rows, 8 MiB, 28 days). Once an event reports queued, its stable random identity survives retry, process death, force-stop, reboot, response loss, and partial synchronisation.

Delivery is at-least-once; the platform claims each identity atomically before updating a counter, so an exact retry is idempotent and a changed-payload replay fails closed. We describe the result as effective exactly-once aggregate effects rather than exactly-once delivery, because the second would not be true.

Queue pressure or expiry is visible and quarantined rather than silently evicting an accepted row. The device stops starting new sessions when either its policy lease or admitted signed trust publication is no longer valid; a grace period cannot revive expired or invalid trust.

One limitation we state rather than hide: a process kill in the narrow interval after a result is rendered but before the outbox commit can lose that single aggregate event. Verification is unaffected. Full detail on offline reliability.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. In-person acceptance of digital credentials — Google
3. mDL Digital Trust Service — For Relying Parties — AAMVA