Google Wallet Mobile IDs: What Businesses Need to Know

Google Wallet carries state-issued driver’s licences and IDs in the United States, built on the same ISO/IEC 18013-5 foundation as other mobile ID implementations. For a business, the practical questions are the same as with any wallet: which jurisdictions, how does presentation work, and what does any of it mean for the verifier you are considering buying.

Where the authoritative lists are

Two Google-published pages are worth bookmarking:

• Supported issuers and their IACA certificates — the issuing authorities Google supports, with links to the certificate material behind them.
• Add your US Driver’s License or State ID — the consumer-facing view of the same question.

As with Apple, we do not restate the jurisdiction list on this page. It changes, and a stale copy on a vendor site is worse than no copy.

One useful detail from Google’s issuer page: most listed issuing authorities are reachable through AAMVA’s trust service, while a few maintain their own certificate distribution. That is a real operational difference for anyone building or configuring a reader, and it is a reasonable thing to ask a vendor how they handle.

In-person presentation

Google documents in-person acceptance separately from online acceptance, which is the right split — they are different problems.

For in-person checks, the flow is the ISO/IEC 18013-5 one: engagement (over NFC tap or QR), then a data-retrieval session over a local transport such as BLE, then a request naming specific elements, then a signed response the reader validates. Google provides open-source implementations of the BLE data-retrieval methods these interactions rely on.

Google also frames interoperability as an explicit goal: a business accepting IDs this way is accepting a standards-conforming credential, not a Google-specific object. That framing is worth taking seriously in both directions — it means a conforming reader is not locked to one wallet, and it means “we support Google Wallet” is a weaker statement than it sounds.

Wallet availability is not verifier support

This deserves stating bluntly, because the market blurs it constantly.

Google listing an issuing authority means Google’s wallet will carry that authority’s credential. It says nothing about:

• whether a given verification product trusts that authority’s material;
• whether that product has been tested against a real credential from that authority;
• whether it has been tested on the hardware you would actually deploy;
• or when any of that testing last happened.

Those four are the vendor’s responsibility. A compatibility page that lists wallet jurisdictions without separating them from validated configurations is describing someone else’s work as its own.

What to expect operationally

Two wallets, one reader. A conforming reader should be able to accept a conforming credential from either wallet. In practice, transport behaviour differs enough across phone models, OS versions, and reader chipsets that “should” and “does” are separated by physical testing.

Adoption is partial, again. Same as with Apple Wallet: plan for a mixed door.

Device-side experience differs. Wallet UI, authentication prompts, and how a holder initiates a presentation vary between platforms. Staff training should be about the outcome on your verifier, not about what the customer’s phone looks like — that is the only part that is consistent.

Questions worth asking a vendor

• Have you physically validated a Google Wallet presentation? On which jurisdiction, which hardware, and when?
• If not, how is Google Wallet described in your published compatibility material?
• How does your reader source trust material for issuers who distribute their own certificates rather than through AAMVA?

A vendor whose answer to the first question is “no” and whose marketing says “supports Google Wallet” has answered a more important question than the one you asked.

LaurelID’s current position

Laurel’s own status, stated plainly.

LaurelID has not physically validated a Google Wallet presentation on any hardware. No validation date exists in our evidence record, so we list Google Wallet as planned as a LaurelID capability, and describe the ecosystem-level fact separately as wallet available.

We will describe it as supported when — and only when — a validation date, a jurisdiction, and a device can be printed in the row on our compatibility matrix. Until then, saying anything stronger would be exactly the practice this article is warning about.

Sources

1. Verify with Google Wallet — overview — Google
2. In-person acceptance of digital credentials — Google
3. Supported issuers and their IACA certificates — Google
4. Add your US Driver's License or State ID — Google