Age Verification in the Web -- Holy Grail to Control Access to Restricted Content

Source: arXiv:2605.05513 · Published 2026-05-06 · By Wojciech Wodo, Maksymilian Gorski, Lucjan Hanzlik

TL;DR

This paper addresses the practical and policy gap in online age verification — specifically, how to reliably prevent minors from accessing harmful content (pornography, gambling, violence, alcohol) without creating a centralized surveillance infrastructure. The authors survey three active legislative attempts: the UK's Online Safety Act 2023 (enforcement from July 25, 2025), Australia's Social Media Minimum Age Act 2024 (enforcement from December 10, 2025), and the EU's emerging Age Verification blueprint (two versions released July and October 2025). Their critique is that each of these frameworks either permits too wide a range of verification methods — including low-assurance ones that are trivially bypassed — or routes sensitive biometric and identity data through single governmental authorities whose data-handling track record is demonstrably poor (citing CJEU rulings on GDPR violations under EU Regulation 2019/1157, where biometric data collected for ID cards was retained and shared beyond its stated purpose).

The proposed alternative is a privacy-preserving anonymous token scheme built on two existing open standards: the IETF Privacy Pass architecture (RFC 9576) and Apple's Private Access Tokens (PATs). The core substitution is conceptually simple: instead of solving a CAPTCHA to earn a batch of unlinkable cryptographic tokens, the user completes a KYC age-verification procedure with a qualified Trust Service Provider (as defined under eIDAS 2.0). The resulting tokens are then spent anonymously at age-restricted websites, carrying no linkable identity information. Token batches are finite, requiring periodic re-attestation, and the scheme is designed to work without requiring dedicated software installation beyond what is already present in modern browsers or mobile secure enclaves.

The paper is primarily a position and design paper rather than an empirical evaluation. It does not report experimental benchmarks, implement a prototype, or conduct a formal security proof. Its contribution is architectural and regulatory: it maps known weaknesses of deployed systems (bypass via VPNs, deepfake avatars, proxy scans, makeup-based circumvention of facial estimation), articulates desired properties for any acceptable solution (unlinkability, no single point of trust, no specialized software, reusable across multiple sites within a token batch), and sketches how Privacy Pass + KYC attesters satisfies those properties better than current governmental proposals.

Key findings

• 87.71% of under-18 desktop traffic to pornographic sites is directed to the top 200 UK-ranked adult sites (August 2020 traffic data), indicating minors concentrate on mainstream adult platforms rather than obscure ones.
• Up to 90% of teens have reportedly viewed pornography online, with ~10% admitting daily use, based on cited survey data — underlining the scale of failure of existing soft controls.
• About 9% of young people have encountered harmful age-restricted content online, and ~11% encounter it weekly / 7% daily, per VerifyMy.io cited statistics.
• The UK Online Safety Act's early enforcement revealed that hackers exploited unpatched APIs and low challenge-age thresholds (set at 20-25), with fewer than 1% of 13-17 year-olds slipping through via manipulated documents — but VPN-based bypass was demonstrated within seconds of enforcement going live on July 25, 2025.
• Facial age estimation systems in both UK and Australia deployments were bypassed using 3D Gaussian Splatting and Gaussian Avatars for liveness spoofing, and by minors using makeup, filters, or proxy scans (older siblings/parents performing the facial scan on behalf of the minor).
• Australia's Social Media Minimum Age Bill (2024) mandates platform fines up to AU$50 million for systemic non-compliance, yet lacks precise numerical age-accuracy thresholds, relying instead on eSafety Commissioner discretion — a regulatory gap the authors flag explicitly.
• The EU's mDL credential standard (ISO/IEC 18013-5), which underpins EUDI wallet plans, has been publicly criticized by cryptographers for lacking unlinkability, a property required by eIDAS 2.0; the authors cite 'Cryptographers' Feedback on EU Digital Identity's ARF' [1] as the formal objection.
• The proposed Privacy Pass + KYC token scheme requires no dedicated software installation, supports multiple competing attesters (reducing single-authority risk), and inherits the cryptographic unlinkability guarantees of RFC 9576 Privacy Pass — but no latency, throughput, or token-batch-size numbers are reported in the paper.

Threat model

The paper implicitly defines two adversary classes but never formalizes them. The first adversary is a minor (or an adult assisting a minor) attempting to bypass age gates: they are assumed to have access to consumer VPNs, prepaid/gift credit cards, makeup and filters, older proxies willing to perform facial scans, and consumer-grade deepfake tools including 3D Gaussian Splatting-based avatar generation capable of passing liveness detection. The second adversary is a data-aggregating or surveillance entity — specifically a government authority or platform operator who may improperly retain or share biometric/identity data collected during verification, as evidenced by the CJEU ruling on EU Regulation 2019/1157. The scheme's design is oriented toward neutralizing the second adversary (via unlinkable tokens and one-time KYC) while relying on KYC provider certification (ETSI 119 461) to address the first. The paper does not model a cryptographic adversary against the Privacy Pass protocol itself, nor does it consider a compromised attester, a malicious issuer, or a colluding attester-origin pair.

Methodology — deep read

This is a design and policy analysis paper, not an empirical ML or systems evaluation. There is no dataset, training loop, or controlled experiment. The methodology consists of four identifiable activities: regulatory comparative analysis, threat/weakness enumeration, architectural proposal, and property argumentation.

1. Threat model and adversary assumptions: The paper implicitly defines two adversary classes. The first is a minor attempting to self-circumvent age gates — assumed to have access to VPNs, prepaid cards, older-sibling proxies, makeup, and consumer-grade deepfake tools (Gaussian Splatting, Gaussian Avatars, Death Stranding avatar case cited). The second is a data-harvesting or surveillance adversary — specifically a government or platform operator who may retain biometric data beyond its stated purpose, as documented in the CJEU ruling on EU Regulation 2019/1157. The paper does not formally define adversary capabilities in cryptographic terms (no security game or reduction is given), which is a notable gap for a paper invoking Privacy Pass.

2. Regulatory survey: The authors analyze three live or near-live legislative frameworks. For each, they examine: what verification methods are mandated or permitted, what bypass techniques have already been observed in the wild (citing news and regulator sources rather than controlled red-team studies), what data-minimization requirements exist, and what enforcement mechanisms and penalties apply. The UK and Australia analyses draw heavily on Ofcom guidance documents, eSafety Commissioner materials, and journalistic reports of first-day bypasses. The EU analysis uses the European Commission's July and October 2025 blueprint publications and references the open-source ageverification.dev repository.

3. Weakness enumeration: The authors systematically identify that both the UK and Australian frameworks suffer from the 'weakest-link' problem — allowing a broad menu of verification methods (facial estimation, credit card, MNO data, email-based estimation, photo ID) without requiring minimum assurance floors. They argue an attacker always reduces the system's security to that of the least secure permitted method. They also flag that the EU's mDL/ISO 18013-5 approach, while standardized, lacks the unlinkability property required by eIDAS 2.0, citing external cryptographic analysis.

4. Architectural proposal: The proposed system maps directly onto RFC 9576 Privacy Pass, which defines two protocols (token issuance and token redemption) and four roles: Client (user's device), Attester (KYC provider), Issuer (token-signing authority), and Origin (age-restricted website). The substitution the authors make is replacing the CAPTCHA challenge in the standard Privacy Pass flow with a KYC procedure performed by a qualified Trust Service Provider under eIDAS 2.0. Upon successful KYC, the user receives a finite batch of cryptographically blind-signed tokens. These tokens are spent one-per-session (or per-access) at origin websites, which verify token validity without learning anything about the user's identity or which attester was used. Apple's Private Access Tokens variant extends this by binding attestation to the device's secure enclave, preventing token theft and replay across devices. The paper sketches an issuance flow diagram (Fig. 4) but does not specify token batch sizes, re-attestation intervals, or the exact blind signature scheme used (Privacy Pass supports both public-metadata and private-metadata variants; the paper does not specify).

5. Property argumentation: Rather than formal proofs or benchmarks, the authors argue that their scheme satisfies four desired properties: trustworthiness (KYC providers are obligated under ETSI 119 461 to demonstrate anti-spoofing countermeasures), user-friendliness (no new software required; browser-native via existing PAT support), privacy preservation (tokens are unlinkable by the unlinkability guarantees of Privacy Pass; KYC is performed once per batch), and assurance-level flexibility (different attester classes can be whitelisted for different assurance tiers). No formal security reduction, simulation, or benchmark is provided to substantiate these claims.

6. Reproducibility: The paper references the ageverification.dev open-source repository for the EU blueprint but does not release code, a prototype, or a reference implementation of the proposed scheme. The Privacy Pass RFC (RFC 9576) and Apple PAT documentation are publicly available, so the building blocks exist, but the integration layer is not implemented or evaluated.

Technical innovations

• Substituting the CAPTCHA challenge in the standard Privacy Pass (RFC 9576) issuance protocol with a KYC age-verification procedure, thereby repurposing an existing anonymous-credential infrastructure for age gating without protocol modification.
• Proposing a multi-attester ecosystem anchored in eIDAS 2.0 qualified Trust Service Providers (with mandatory ETSI 119 461 anti-spoofing certification) as the attester layer, in contrast to prior proposals that rely on a single governmental EUDI wallet issuer.
• Identifying and articulating the 'weakest-link assurance' structural flaw in the UK and Australian regulatory frameworks — that permitting a broad menu of verification methods without minimum assurance floors reduces effective security to the easiest-bypassed method.
• Extending the Privacy Pass + PAT model to leverage Apple's Secure Enclave device-binding property, so that tokens are tied to a physical device rather than being freely transferable, adding a hardware attestation layer absent from the basic Privacy Pass scheme.
• Critiquing the EU mDL/ISO 18013-5 standard's lack of cryptographic unlinkability (as documented in 'Cryptographers' Feedback on EU Digital Identity's ARF') and positioning Privacy Pass's blind-signature unlinkability as a drop-in remedy compatible with near-term deployable hardware.

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2605.05513.

Fig 1: UE Age Verification App - Journey of a Proof of Age Attestation User [8]

Fig 2: Privacy Pass Development Timeline by Cloudflare [19]

Fig 3: Privacy Pass Token Lifecycle by Cloudflare [19]

Fig 4: Proposed Anonymous Age Verification Token Issuance Flow Diagram

Limitations

• No prototype implementation: the proposed scheme is a design sketch only; no code, no latency measurements, no token-throughput numbers, no red-team evaluation are provided, making it impossible to assess real-world feasibility.
• No formal security proof: the paper asserts unlinkability and privacy properties by inheritance from Privacy Pass, but does not provide a reduction, simulation argument, or even a threat model written in standard cryptographic terms (e.g., no definition of what adversary breaks unlinkability).
• KYC provider trust assumption is underexamined: the scheme shifts trust from governments to eIDAS 2.0-qualified private KYC providers, but does not analyze what happens if a KYC provider is compromised, coerced, or behaves maliciously — a significant residual risk given the sensitivity of age+identity data.
• Token batch size and re-attestation policy are unspecified: the paper says users receive 'a portion of cryptographic tokens' that can be spent until exhausted, then must re-attest, but gives no guidance on batch sizes, expiry windows, or how to prevent a user from sharing a token batch with a minor after attestation.
• Circumvention of the KYC step itself is not addressed: the paper criticizes facial estimation and photo ID methods for being bypassable, but its own KYC step relies on the same class of ID-proofing technology (the paper acknowledges ETSI 119 461 requirements but does not analyze whether those countermeasures are sufficient against Gaussian Splatting or proxy attacks).
• Regulatory and legal analysis relies heavily on URLs to news articles, regulator pages, and blog posts rather than primary legal texts or peer-reviewed sources, which weakens the scholarly rigor of the comparative analysis.
• Apple PAT dependency: the device-binding enhancement relies on Apple's Secure Enclave and PAT infrastructure, making that component Apple-platform-specific; a cross-platform solution for Android or desktop-only users is not discussed.

Open questions / follow-ons

• What token batch size and re-attestation frequency strike the right balance between usability (fewer KYC interruptions) and security (limiting the window in which a shared or stolen token batch can be misused by a minor)?
• Can the KYC attestation step itself be made resistant to the same Gaussian Splatting / liveness-spoofing attacks that defeat current facial estimation systems, and what does ETSI 119 461 compliance actually require in practice against such attacks?
• How should the trusted-attester whitelist be governed — who decides which KYC providers are admitted, removed, or audited — without recreating a single governmental authority and its associated privacy risks?
• Is there a viable cross-platform path for the device-binding property that does not depend on Apple's Secure Enclave PAT infrastructure, particularly for Android devices and desktop browsers where equivalent hardware attestation is less standardized?

Why it matters for bot defense

For bot-defense practitioners, this paper is directly relevant because it proposes repurposing the Privacy Pass / Private Access Token stack — the same cryptographic infrastructure already used to reduce CAPTCHA friction for legitimate users — as an age-verification gate. The key insight is that Privacy Pass tokens are already a CAPTCHA replacement in Cloudflare's and Apple's deployments; the authors' proposal is to swap the issuance challenge from 'prove you are human' to 'prove you are over 18 via KYC.' A bot-defense team maintaining a CAPTCHA or trust-signal pipeline should note that this creates a new class of token-based access that must be validated server-side, and that the unlinkability property means the origin site cannot distinguish two requests from the same user across sessions — which is both a privacy win and a detection constraint. Any anomaly-detection or velocity-limiting logic that relies on cross-session user fingerprinting would be blind to re-use patterns within a token batch.

Practically, the paper highlights a concrete attack surface that bot-defense engineers already contend with: the liveness-detection layer of KYC providers is vulnerable to the same adversarial media techniques (Gaussian Splatting avatars, deepfake proxies) that are used to bypass visual CAPTCHAs and anti-bot challenges. If age-verification tokens become a trusted signal for access, a bot operator who can defeat the KYC liveness check once gains a batch of unlinkable tokens usable across many sites — a high-value target. The paper does not address this threat from the bot-operator perspective at all, which is a meaningful blind spot that CAPTCHA and bot-defense practitioners would immediately identify. The relevance to building or evaluating such a system is high; the paper's value is in framing the design space and regulatory constraints, not in providing an implementation-ready specification.

Cite

@article{arxiv2605_05513,
  title={ Age Verification in the Web -- Holy Grail to Control Access to Restricted Content },
  author={ Wojciech Wodo and Maksymilian Gorski and Lucjan Hanzlik },
  journal={arXiv preprint arXiv:2605.05513},
  year={ 2026 },
  url={https://arxiv.org/abs/2605.05513}
}

Read the full paper

• arXiv:2605.05513 (abstract)
• arXiv:2605.05513 (PDF)