How Age Can Be Verified Without Sharing a Date of Birth

For as long as ID checks have existed, proving you are old enough has meant showing when you were born. That was not a design decision; it was a consequence of the medium. A card cannot answer a question — it can only display facts, and the person reading it does the arithmetic.

Mobile IDs change the medium, and with it the question.

The mechanism

An mDL is a set of individually verifiable data elements. Alongside birth_date, an issuing authority signs a family of boolean attestations at issuance: age_over_18, age_over_21, and other thresholds a jurisdiction chooses to support.

Each of those is a genuine, independently signed fact. age_over_21 = true is not derived by the phone at presentation time, and it is not something the wallet computes and asserts on the holder’s behalf. It is the issuing authority’s signed statement, made when the credential was issued.

That is what makes it usable. A verifier can request age_over_21 and nothing else, validate the issuer’s signature over it, and act on the result — without the birth date ever being released.

Why this is different from “we don’t store the birth date”

Almost every ID-scanning product will tell you it does not retain a date of birth. That claim is about what happens after the data arrives. It requires you to trust a retention policy, a configuration, a deployment, a backup regime, and every future version of the software.

Requesting only the age attestation is a claim about what arrives at all. There is no birth date to retain, no window during which it existed in memory alongside a bug, and no future product decision that could quietly start keeping it.

The distinction is the difference between a promise and a property. Security reviewers care about it a great deal, and rightly.

The retention flag

ISO/IEC 18013-5 requests carry a per-element intentToRetain flag: the verifier’s declaration of whether it intends to store what it receives. Because the flag travels inside the request, a wallet can surface it to the holder.

A verifier that requests one age attestation with intentToRetain set to false is making a narrow and checkable statement: I am asking one question, and I am telling you I will not keep the answer.

A verifier that requests a wide element set with retention declared has at least been honest. A verifier that requests a wide element set and declares no retention while writing everything to a database is doing something considerably worse than collecting data — it is misrepresenting itself to the holder at the protocol level.

Where the limits are

A single threshold answers a single question. age_over_21 cannot answer whether someone is over 18. A business that gates products at multiple ages needs multiple attestations, and a verifier built for one is not silently capable of the others.

Not every jurisdiction supports every threshold. Which attestations are present in a credential is an issuing-authority decision. Wallet operators publish which attributes are available for the credentials they carry, and it is worth checking rather than assuming.

Identity binding is still human. The credential proves that the holder of this device has an attestation from an issuer. Whether the person in front of you is that holder remains a judgement — the same judgement staff make with a physical card today.

It does not remove the need for a fallback. Mobile ID adoption is partial. Your manual procedure continues to cover everyone who does not present one, which is still most people in most places.

What good looks like in practice

If you are evaluating an age-verification product built on mobile ID, the test is simple: ask for the exact request the reader sends. Not a description of it. The document type, the namespace, the element list, and the retention flag.

If a vendor cannot produce that in one line, they are either not sending a narrow request or have not thought about why it matters. Both are useful things to learn early.

LaurelID’s request

This is Laurel’s own product, stated for comparison.

document type:  org.iso.18013.5.1.mDL
namespace:      org.iso.18013.5.1
element:        age_over_21
intentToRetain: false

That is the complete request, unchanged in every release. There is no configuration screen that widens it, no enterprise tier that adds fields, and no diagnostic mode that captures more. The consequence is described in full on the privacy architecture page: the platform has no column for a name, a birth date, a portrait, or a document number, because none of them are ever requested.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. Supported attributes for credentials in Google Wallet — Google
3. IDs in Apple Wallet — Apple Platform Security — Apple