Age Checks as Identity Infrastructure

The age verification debate should not be treated as a narrow content moderation argument. Age verification is identity infrastructure. Once a site must know whether a visitor crosses an age threshold, designers have to decide who verifies the claim, what data gets shared, how often the proof can be reused, and whether the proof can be linked across sites.

Those decisions shape the web beyond the first policy goal.

Age Is Hard to Prove Without Proving More

A website wants a yes/no answer: is this user above a threshold? Most verification methods reveal much more.

Method	Data Exposed	Main Risk
Government ID upload	Name, birthdate, document number, image	Sensitive document retention and breach risk
Credit card check	Payment relationship, billing region	Excludes users and leaks financial linkage
Telecom check	Phone identity, carrier, region	Ties browsing to persistent phone identifiers
Biometric estimate	Face or voice data	Sensitive biometric processing and error rates
Third-party identity provider	Cross-site verification events	Centralized tracking and vendor dependence
Account reputation	Platform history and device data	Opaque scoring and false positives

A privacy-preserving design should reveal only the predicate: over 18, under 13, allowed for this service class. Most deployed systems will face pressure to reveal more because richer identity data reduces compliance uncertainty, helps enforcement, and creates business value.

The Core Technical Properties

A serious age verification architecture should be judged on technical privacy properties, not slogans.

Data minimization. The relying site should receive the smallest possible claim. "Over threshold" should be enough for most cases.

Unlinkability. A verifier should not learn every site the user visits. Sites should not collude through stable verification tokens.

Selective disclosure. The user should be able to prove an attribute without disclosing full identity.

Revocation without tracking. The system needs a way to revoke fraudulent credentials without turning every check into a tracking event.

Local or blinded verification. The verifier should avoid seeing both the user's identity and the destination service when possible.

Auditability. Regulators and civil society should be able to inspect whether providers retain data, sell signals, or support secondary use.

These properties are difficult to combine. That difficulty should make policymakers more cautious, not less.

Token Design Matters

Many proposals eventually become token systems. A user proves age to a verifier, then presents a token to sites. The details decide whether the system becomes surveillance infrastructure.

A safer token should:

• Be scoped to a broad service category, not a specific site identity.
• Avoid stable cross-site identifiers.
• Expire quickly enough to reduce replay risk.
• Support blinded issuance where practical.
• Reveal only the age predicate.
• Avoid embedding device, region, or account metadata.
• Give users a way to delete local credentials.

A dangerous token does the opposite. It stays stable across sites, includes issuer metadata, refreshes through a central server, and lets verifiers observe browsing behavior. That design can create a shadow login layer for the web.

Secondary Use Is the Main Threat

Identity systems rarely stay within their first use case. A mechanism built for adult content can migrate to social media, app stores, AI tools, gaming, political content, financial education, forums, whistleblowing platforms, and search.

Each expansion has an argument. Each argument adds another place where anonymous browsing becomes suspicious or unavailable.

The secondary-use risk should be part of the technical spec:

• Can a site request a stronger identity claim than the law requires?
• Can the verifier sell or share verification events?
• Can law enforcement request logs of sites visited?
• Can platforms combine age tokens with advertising IDs?
• Can employers, schools, or parents demand proof histories?
• Can a future law reuse the same system for speech attribution?

If the architecture makes those expansions easy, the initial use case does not limit the harm.

Safety Without Identity Dragnet

Child safety is a legitimate goal. The design space should not collapse into universal identity checks.

Alternatives and complements include:

• Device-level parental controls that do not report browsing to sites.
• App-store-level family settings with local enforcement.
• Content labeling standards that clients can interpret.
• Stronger default privacy protections for minors.
• Limits on behavioral advertising to children.
• Reporting and moderation improvements for abusive content.
• Education and guardian tools that do not require ID upload.

These approaches have tradeoffs. They also avoid turning every adult into a verified web subject.

Evaluation Checklist

I would evaluate any age verification proposal with this checklist:

1. Does the relying site learn real identity or only an age predicate?
2. Can the verifier see which sites the user visits?
3. Can two sites link the same user's verification events?
4. What data does the verifier retain, and for how long?
5. Can users delete verification artifacts?
6. Does the system work for people without government ID or credit cards?
7. How does the system handle false negatives for adults?
8. How does it handle false positives for minors?
9. Can the architecture support later speech attribution?
10. Who audits the provider and publishes abuse findings?

The last two questions often reveal the real trajectory. A system that can identify everyone for age can identify everyone for other reasons.

The Engineering Burden

Developers asked to implement age verification should not treat it as a simple SDK integration. They are adding an identity dependency to the product. That dependency affects logs, analytics, incident response, consent flows, regional behavior, and threat models.

At minimum, teams should document:

• Data received from the verifier.
• Data sent to the verifier.
• Token lifetime.
• Storage location.
• Error handling for failed verification.
• Appeal paths.
• Deletion process.
• Access controls for verification logs.

Age verification systems should be designed as if they will be breached, subpoenaed, expanded, and repurposed. Many identity systems eventually face all four.

Threat Model the Verifier

Most public arguments focus on the website asking for age proof. The verifier deserves equal scrutiny. A verifier can become a database of sensitive behavior even if each relying site receives only a yes/no answer.

Ask what the verifier can observe:

• The user's real identity.
• The user's device or IP address.
• The time of verification.
• The relying site or service category.
• The success or failure result.
• The token refresh pattern.
• The appeals history.

If the verifier sees identity and destination, it can build a browsing-adjacent history. If it sees identity and broad category, it still learns sensitive patterns. If it sees only blinded token issuance, the privacy story improves.

The verifier also becomes a target. Attackers may want document images, age status, browsing-adjacent logs, or account linkage. A breach of an age verifier could expose people who visited sensitive services even if the services themselves kept no identity logs.

Failure and Appeal Paths

Age verification systems need appeal design. False negatives will block adults. False positives will let minors through. Biometric estimation may fail across age, lighting, disability, device quality, and demographic groups. ID-based systems will exclude people without current documents.

An appeal path can increase privacy risk if it asks users to upload more documents, contact support, or create persistent accounts. The system should define:

• What data an appeal collects.
• Who reviews it.
• How long it stays stored.
• Whether the relying site learns about the appeal.
• Whether repeated failures create a risk score.
• How users delete appeal artifacts.

Policy discussions often skip this operational layer. Users experience the system through failures, not through white papers about cryptographic ideals.

A Minimal Architecture Sketch

A privacy-preserving version would look closer to this:

1. User proves age to a verifier through a high-friction path.
2. Verifier issues blinded, short-lived age tokens.
3. User stores tokens locally.
4. Site requests a predicate token, such as over_18.
5. User presents a token without a stable cross-site identifier.
6. Site verifies issuer signature without learning real identity.
7. Verifier does not learn which site consumed the token.

This architecture still has problems: device compromise, coercion, token resale, issuer trust, exclusion, and legal demands. It at least minimizes the obvious surveillance path. Systems that skip these protections should be described as identity checks, not privacy-preserving age gates.

Sources

• Pluralistic: Age verification as mass surveillance