Summary

  • The IAB’s 24 August statement identifies device-mediated, minimal and unlinkable age signals as the most promising direction at today’s level of maturity. It does not call the design deployable overnight, a legal-compliance certificate or proof of the person presently using a device.
  • Shared devices create an independent binding problem. Age establishment, local profile selection, browser session state and the site’s request can each be correct in isolation while the resulting threshold answer refers to the wrong household member.

The cleanest disclosure can still answer the wrong question

The opening is a hypothetical failure, not a reported incident. It matters because it separates two properties that policy debates often compress into one. A system can minimize disclosure—returning only “over 18,” for example—without proving that the current holder is the person or profile to which that conclusion belongs.

That distinction does not weaken the privacy case. Exact birth dates, identity documents and browsing histories should not be disclosed merely because a service has an age rule. A threshold answer can be materially safer than a reusable identity record. But data minimization narrows what is revealed; it does not magically establish the binding between a credential, a local account, a browser session and the human making the request.

On a personal phone, designers may treat the device, account and user as a practical bundle. A family tablet, school computer, borrowed handset or living-room console breaks that assumption. The adult may have completed age establishment correctly. The operating system may have stored the result correctly. The browser may ask through the specified interface. The service may receive an authentic response. If the child is using the adult context, every component can produce the expected record while the policy outcome fails.

The useful question is therefore not simply, “Was the age signal valid?” It is, “What subject and moment did the signal validly describe?”

The IAB offered a direction, not a finished product

The Internet Architecture Board published its Statement on Age-Based Restrictions and Online Safety on 24 August 2026. It begins from a shared objective—protecting children online—then inventories architectural risks in several common approaches.

Third-party assurance services can become high-value stores of sensitive information. Requiring each site to collect identity information increases privacy and identity-theft exposure. Network blocking can create pressure to weaken encryption or reveal traffic. Circumvention can send users toward untrusted VPNs, shared or fraudulent credentials and grey-market applications. A small set of platform vendors can gain leverage over reliability, competition and digital sovereignty. Divergent national mechanisms can fragment a network that depends on interoperability.

Against those risks, the IAB describes desirable properties: disclose only a purpose-specific age result; avoid activity reporting and cross-site linkability; keep the party establishing age from learning which sites a person visits; avoid a central activity store; limit burdens and exclusion; and use open interfaces developed through multistakeholder processes.

At current maturity, the statement calls device-based verification the most promising direction “in principle.” That phrase carries weight. The statement says such a design does not remove the need to establish age in the first place. It warns that operating-system and device vendors would acquire considerable leverage. It conditions the approach on an open interface that any device, operating system or browser can implement. It also explicitly says robust multi-user support on shared devices is needed.

Those qualifications are the architecture. Removing them turns a constrained proposal into an endorsement the document did not make.

RFC 9998 maps the roles that must not be collapsed

RFC 9998, published in June 2026 on the IAB stream, reports the 2025 workshop on age assurance and the Internet. It is Informational. The report cautions that workshop contributions do not necessarily represent the IAB or W3C and that inclusion is not validation or consensus.

Its role vocabulary is useful precisely because it reveals the chain. A verifier evaluates age-related evidence. An enforcer applies a rule. A policy selector determines which policy governs. A rater may classify content or services. Age assurance itself is an umbrella covering verification, estimation and inference, each with different evidence, error and exclusion properties.

Credentials can be absent, unavailable in a jurisdiction or unrecognized. Estimation can produce false acceptance and false rejection. Inference can fail because the relevant data do not exist or because behavioral proxies are misleading. A range is generally less revealing than an exact age, but the range still needs a defined subject and valid context.

Zero-knowledge proofs and selective disclosure can reduce the data revealed to a service. They do not prevent credential sharing, evasion or censorship, and their software dependencies can concentrate trust. A mathematically valid proof answers the proposition encoded in it. It cannot repair an operational decision that selected the wrong local profile before the proof began.

A threshold token crosses at least six authority boundaries

Consider the lifecycle of one “adult” answer.

First, an age-establishment authority connects evidence or an estimate to a person, account or device context. Second, an account or profile system decides where that result is stored. Third, the device decides which local context is active. Fourth, the browser or application decides which context to consult and how to preserve it across sessions. Fifth, the service asks for a threshold under a particular policy. Sixth, a legal or institutional authority decides whether that threshold, method and remedy satisfy the applicable rule.

No actor automatically controls the whole chain. A document issuer does not know who later holds the tablet. A device vendor does not choose the site’s jurisdiction. A browser should not invent a legal threshold. A site cannot inspect a private local profile without defeating the minimization goal. An enforcement body can require an outcome without possessing the technical evidence that a particular request was correctly bound.

This is why “device-based” is too broad to be an operating claim. A credible design must specify the assertion subject, profile-selection event, session boundary, freshness window, requesting origin, threshold semantics and recovery path. It must say what happens after sleep, app switching, handoff, account switching, guest use and parental override. It must distinguish a device that contains an adult credential from a session currently authorized to use it.

Open interfaces redistribute power; they do not abolish it

An open, interoperable request interface can prevent one platform from dictating a private protocol to every site. It can let browsers, operating systems and independent implementations compete. It can keep the service’s request narrow and make the returned assertion auditable without exposing identity.

Yet the device or operating system still controls local profile state, secure storage, user-presence signals, update policy and interface availability. That is substantial authority. The IAB acknowledges the leverage rather than pretending the interface makes it disappear.

Procurement and regulation should therefore test both portability and refusal. Can an independent browser obtain the same class of signal? Can a device implement the interface without joining one vendor’s identity service? Can a user contest a false under-age result without revealing a full identity to every site? Can a service explain a denial without creating a cross-site identifier? Can a jurisdiction demand a different threshold without forcing the global interface to encode national law?

These questions decide whether “open” describes an implementable boundary or only a public doorway into a private dependency.

Outcome rules should preserve room to repair the binding

The IAB argues for outcome-based mandates rather than technology-specific prescriptions. That is not an argument for weak accountability. It is a way to avoid freezing a young method before shared-device behavior, exclusion rates, circumvention and concentration effects are understood.

A regulator can require measurable child-safety outcomes, privacy limits, independent assessment, accessible appeal and incident reporting without naming one credential format or device provider. A service can stage adoption by risk and context rather than treating every forum, shop, game and health resource as identical. Implementers can improve profile switching and user-presence checks without asking lawmakers to amend a protocol reference.

The alternative—mandating one early mechanism—creates path dependence. Compliance spending, vendor contracts and installed software can make a flawed binding expensive to change. The economic incentive then shifts from discovering whether the right person was checked to proving that the required box was checked.

Sources