What AAMVA's VICAL and Digital Trust Service Do

Every explanation of mobile ID eventually says the reader “validates the issuer’s signature.” That sentence hides the hardest part of the problem: how does the reader know which signatures belong to real motor vehicle authorities?

The problem

An mDL is signed by a certificate that chains to an issuing authority’s root — its IACA, or issuing authority certificate authority. A reader can check that chain internally. But an attacker can also generate a certificate authority, sign a credential with it, and present a document that is perfectly internally consistent.

The reader needs an external, trustworthy answer to the question is this a legitimate issuing authority? Getting that answer for every jurisdiction, independently, would be an enormous and error-prone burden on every relying party.

The mechanism the standard defines

ISO/IEC 18013-5 anticipates this and defines a verified issuer certificate authority list — a VICAL — as the mechanism by which a list of legitimate issuing-authority public keys is shared with relying parties. It is a signed list, so a reader can verify that the list itself has not been tampered with.

That turns the problem from “know every issuer” into “trust one list publisher,” which is a tractable trust decision.

What AAMVA operates

AAMVA runs an mDL Digital Trust Service for its member jurisdictions. Issuing authorities’ public keys are published to the DTS VICAL, and AAMVA describes the service as the single best source for relying parties to confirm the veracity of an mDL.

For a business, the operationally relevant parts of AAMVA’s guidance are:

• Relying parties download the VICAL and load it into their reader technology.
• The download happens before engaging with a credential, not during the presentation.

That second point matters more than it looks. A reader that fetched trust material mid-presentation would be unable to work offline, and would make every check depend on a network round trip. Loading trust ahead of time is what makes local, offline-capable verification possible at all.

AAMVA also describes what admission to the DTS is meant to signify — that participating programs adhere to ISO/IEC 18013-5 and AAMVA’s mDL implementation guidelines, and follow key-management practices.

What this means for evaluating a verifier

The trust configuration is one of the most revealing questions you can ask a vendor, and one of the least commonly asked.

Where does the trust list come from? A named, signed source with verifiable provenance is the answer you want.

How is an update validated before it is used? A candidate trust package should have its signature and provider chain verified against a pinned root before it replaces anything, and an invalid update should leave the previous known-good copy in place.

Is there rollback protection? Without it, an attacker who can influence updates could replay an older list — potentially one containing material that has since been withdrawn.

How long can trust material be used offline? Indefinitely is the wrong answer. A bounded offline life is what makes withdrawal and rotation mean anything. The correct behaviour when it expires is to stop producing decisions, not to keep going on stale authority.

What else is accepted? This is the question that finds problems. A reader that also accepts operating-system certificate authorities, roots supplied by the presented credential, imported roots, or test IACAs has a trust set far wider than its documentation implies.

Some issuing authorities distribute their own certificate material rather than exclusively through AAMVA. A reader that supports multiple jurisdictions will need a story for both routes, and it is fair to ask what it is.

The failure mode to imagine

Picture a reader with a permissive trust configuration. Someone generates their own certificate authority, issues themselves a credential asserting age_over_21 = true, and presents it. The reader validates the chain against a root it should never have accepted, and shows a green screen.

Nothing in the standard was violated. The cryptography worked exactly as designed. The reader simply trusted the wrong list, and every check it performs is now worth nothing.

That is why the trust question is not a technical footnote. It is most of the security of the entire system.

How LaurelID handles trust

Laurel’s own implementation, described for comparison.

LaurelID admits exact issuing-authority certificate bytes through two explicit production source types: the signed AAMVA Digital Trust Service VICAL and a reviewed certificate obtained from an issuing authority’s official endpoint. Builds ship with reviewed public trust files rather than fetching implicitly. VICAL updates are verified for signature, provider chain, validity interval, and rollback against a pinned official root before atomic activation. Direct-source certificates are parsed, validity-checked, jurisdiction-bound, and pinned byte-for-byte. A failed refresh never silently changes an existing pin or replaces the last-known-good copy.

Offline use is bounded by the admitted signed publication and the authenticated device-policy lease. Laurel refreshes before expiry, retains a still-valid current bundle after a failed refresh, and never lets a grace period revive expired or invalid trust. The canonical behavior is maintained on the security architecture page.

Not accepted as trust anchors, in any configuration: Android system or user certificate authorities, roots supplied by the presented credential, imported roots, test IACAs, and indefinitely stale packages. More detail is on the security architecture page.

Sources

1. Mobile Driver License Digital Trust Service — AAMVA
2. mDL Digital Trust Service — For Relying Parties — AAMVA
3. Verified Issuer Certificate Authority List (VICAL) — AAMVA
4. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO