A system that checks age by collecting identity documents has answered a yes-or-no question by building a register. The gap between what is being asked and what is being collected, why implementations default to the wider one, and what a narrow answer would look like.
Two different questions
Is this person over eighteen and who is this person are different questions. Only the first was asked.
This piece is about the mechanism rather than the merits: whether age restrictions are a good idea is a separate argument, and nothing here depends on how it comes out.
What gets collected instead
A document photograph, which carries a full name, a date of birth, an address and a document number. Usually a face, to bind the document to whoever is holding it.
And one more item, created by the check and not existing before it: a record that this named person reached this category of service at this time. The verification did not merely fail to protect that fact. It manufactured it.
Why implementations default to the wider answer
Not malice. Four ordinary pressures, pointing the same way.
Identity documents are the primitive that already exists, in everyone's pocket, already trusted for other purposes. Verification vendors sell identity, because identity is a bigger product than a single attribute. Liability pushes towards keeping evidence, since an organisation that has to demonstrate it checked would rather hold a record than a promise. And an audit trail is easier to show a regulator than an absence is.
Every one of those favours retention. Nothing in the arrangement pays anybody to collect less.
The category error at the centre
The question is one bit. The answer produced is a durable link between a real identity and a sensitive interest.
That link is frequently more dangerous than the material it was built to gate. A breach of a content service exposes accounts. A breach of the verification layer exposes a list of named people and what category of thing they were reaching for — which is exactly the list nobody would have consented to appear on, assembled as a side effect of a protective measure.
The protection created a target that did not previously exist.
What a narrow answer would look like
In principle, and without naming any scheme: somebody who already knows you — an issuer you have an existing relationship with — attests to one attribute. Over eighteen. Nothing else.
You present that attestation to the service. The service learns the attribute and not your name. The issuer does not learn which service you presented it to. No durable link is created between the two sides.
This is well understood and not speculative. It is also not what most deployments do, because a single attribute is harder to sell than an identity product, and because an absence of records is harder to show as compliance than a pile of them.
What follows for a user
Small and honest.
Prefer checks performed at your device or by an issuer over checks performed at the site, where the difference is visible.
Notice the distinction between shown and retained. They look identical in the moment and differ entirely afterwards.
And read "we delete it after verification" as what it is: a policy statement about a copy you cannot inspect, made by a party with an incentive to retain evidence that the check occurred.
Close
When a system asks for more than the question requires, the excess is not an accident of implementation. It is the part somebody wanted.