Privacy-Preserving Age Verification, Explained

Every vendor in this market now calls itself privacy-preserving. The phrase has been used to describe products that read an entire identity record and products that read one boolean, which means it has stopped carrying information on its own.

Here are five questions that do carry information. They are ordered so that a weak answer to an early one makes the later ones less relevant.

1. What exactly does the reader request?

Not “we only use the age,” and not a paragraph about respecting privacy. The document type, the namespace, the element list, and the retention flag.

There is a fundamental difference between a product that requests one signed age attestation and a product that requests a standard element set and then filters. The second has already collected the data. Everything after that is a policy about data it holds.

If a vendor cannot produce their request in a single short block, that is the answer to the question.

2. Is the retention declaration honest?

ISO/IEC 18013-5 requests carry a per-element intentToRetain flag — the verifier’s declaration to the wallet about whether it will store the value. A wallet can surface that to the holder.

Two failure modes to look for. A verifier that never sets it thoughtfully has not engaged with the question. A verifier that declares no retention and then writes values to a database is misrepresenting itself to the holder at the protocol level, which is considerably worse than collecting openly.

3. Is any stable per-person value derived?

This is the question that most often finds a problem, because it is the one vendors rarely volunteer.

Hashing a document number produces a stable per-person key. So does fingerprinting a device, or deriving a “repeat visitor” token, or storing a truncated hash “just for deduplication.” Each of these turns an anonymous check into an identity system while allowing the vendor to say no personal data is stored — which is technically true and substantively false.

Ask directly: is there any value, anywhere in the system, that is the same for the same person across two visits? The only good answer is no.

4. How granular is the reporting?

Suppose a report shows one fail at one location on one afternoon. No name is attached. But anyone who was present knows exactly who that was.

A count small enough is an individual record. Products that claim aggregate-only reporting but render every row regardless of size have not addressed this. The mitigation is a minimum group size — a k-anonymity threshold — below which rows are withheld.

Two follow-ups worth asking: is the threshold applied in the query or only in the interface, and does any role bypass it? A threshold enforced only at render time will be bypassed by the first export feature someone builds.

5. Could the system hold identity data if someone wanted it to?

The deepest version of the question. If a product’s privacy properties come from configuration, then a settings change, an enterprise tier, a support escalation, or a future acquisition can remove them.

If they come from the schema — no column for a name, no table representing an individual, no contract field that would accept one — then removing them requires rebuilding the system, which is a change nobody makes quietly.

Ask whether the outcome storage is a row per check or a counter. A row per check can always become an identity record by adding a column. A counter cannot.

A scoring shortcut

Ask questions 1 and 3. A product that requests one element and derives no stable per-person value is almost certainly serious about this. A product that hesitates on either is answering a different question than the one you asked.

What “privacy-preserving” should mean

That the business gets its answer, and no party — including the vendor — ends up holding data about the person who provided it. Not that the data is encrypted, not that it is deleted on a schedule, and not that the vendor promises not to look.

Encryption and retention limits are good practices for data you have. The point of this technology is that you can decline to have it.

LaurelID’s answers to all five

Laurel’s own product, for comparison rather than as a claim about the field.

1. The request: org.iso.18013.5.1.mDL / org.iso.18013.5.1 / age_over_21, and nothing else.
2. Retention: intentToRetain is false, and honestly so — there is no column for the value.
3. Stable identifiers: none. No hashed document number, no repeat-visitor token, no device-to-person mapping anywhere.
4. Reporting: aggregate counters per location, outcome, and day, with rows below k = 3 suppressed in the database query and re-checked in responses, exports, and contracts, for every role including the highest.
5. Schema: there is no primary key anywhere representing an individual, and the outcome tables are counters rather than rows-per-check. The device-to-platform contract is an allowlist that rejects unrecognised fields rather than stripping them.

The full version, including the mechanisms that enforce each point, is on the privacy architecture page. We would rather be evaluated on that than on this article.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. Digital Identities — Mobile Driver's License (mDL) project — NIST National Cybersecurity Center of Excellence
3. Supported attributes for credentials in Google Wallet — Google