IAB Age Rules Should Not Freeze a Device Gatekeeper

Summary

On 24 August 2026, the IAB warned that age checks imposed on services, third-party assurance systems or networks can concentrate sensitive data, reduce privacy, pressure encryption, encourage risky circumvention and fragment the Internet.
It identified a narrower target: a minimal purpose-specific age signal that is not linkable across sites, does not report activity, keeps visited sites hidden from the age issuer, avoids a centralized sensitive-data store and travels through open interoperable interfaces.
The IAB currently regards device-based mechanisms as the most promising, but expressly says they give device and operating-system vendors considerable leverage and require robust support for shared devices.
The statement is architectural advice, not a law, certification, IETF standard or deployment command. RFC 9998 is a separate workshop report whose participant views are not automatically IAB or W3C positions.
A workable implementation needs a substitution receipt: child-safety outcomes and minimal-signal semantics must remain intact when the device, operating system, browser, assurance method or supplier changes.

The check changes hands

Most age-assurance arguments begin with accuracy: can a system correctly distinguish a person above a threshold from one below it? That is necessary, but it begins too late. Before a verifier returns an answer, an architecture has already decided who may ask, what evidence may be demanded, where the result is stored, which activity becomes visible and who can refuse access when the machinery fails.

Put the check at each website and the site becomes a collector, directly or through a contractor. Put it in network infrastructure and the access provider needs a way to identify services and enforce a block, creating pressure for traffic visibility. Put it on a device and identity need not travel to every destination, but the device or operating-system layer gains the ability to mediate a consequential signal.

These are not three implementations of the same neutral switch. They assign control, liability, breach exposure and bargaining power to different actors. A privacy improvement at one boundary can create dependence at another. A regulator can reduce repeated identity disclosure while unintentionally making one platform's interface the price of lawful access.

That is the importance of the IAB's current statement. It does not present a finished protocol. It changes the commissioning question. Instead of asking which vendor can satisfy an urgent rule today, it asks which system properties must remain true regardless of the technology used.

Why the service and network routes worry the IAB

The announcement-list copy records the statement in full and dates it to 24 August. The IAB begins by sharing the aim of protecting children online. Its objection is not to that objective but to architectures that can fail while leaving everyone with a more fragile Internet.

A third-party age-assurance service can become a high-value store of identity and eligibility data. Requiring every site to establish age can multiply collection points, expand exposure to identity theft and teach users that identity challenges are normal wherever they browse. Even if a site receives a categorical result rather than a birth date, the wider system still needs controls over correlation, logs, issuer knowledge and reuse.

Network blocking shifts the problem again. To block services that do not perform an approved check, an access provider must identify the target and make enforcement decisions in the path. The IAB points to RFC 7754, whose technical analysis treats blocking location, granularity, encryption, collateral damage, transparency and redress as architectural questions rather than invisible compliance details.

Circumvention is not a side note. A young user who moves to an unknown free VPN, a fraudulent credential or a grey-market application may escape one gate by accepting a more dangerous intermediary. A mechanism can therefore score well on formal coverage while worsening the risk encountered by the people it is meant to protect. Counting challenges or blocked requests is not the same as measuring safety.

Jurisdiction compounds the problem. If each country requires a different disclosure, certified supplier or enforcement location, services can withdraw rather than build every variation. A nominally local rule then changes the global shape of access. Fragmentation is not merely a policy disagreement displayed on a map; it becomes missing services, incompatible clients and unequal routes through the same Internet.

Seven properties narrow the signal

The statement sets out seven properties that should survive whatever technology is chosen. The mechanism should disclose no more than a purpose-specific age signal. It should not report the user's activity. Signals should not be linkable across sites. The party that established age should not learn which sites the person visits. The design should not create a centralized store of sensitive data, impose other significant harms or burdens on users of any age, or depend on a closed interface.

Taken together, these properties describe separation, not a new identity super-service. The issuer knows enough to establish an attribute but should not acquire a browsing diary. A service knows enough to apply one age rule but should not automatically receive a civil identity. Two services should not be able to join their signals into a durable cross-site handle. An implementation may carry a result, but it should not quietly combine issuer, observer, policy selector and universal gatekeeper in one ledger.

The word “minimal” also needs a schema. A binary threshold for one restricted function is not permission to expose a birth date, exact age, identity-document type, household relation or prior verification history. Purpose limitation must be testable at the field and protocol level. Otherwise minimization remains a promise written above a payload that reveals more.

Open interfaces are equally specific. Publishing source code for one client is not the same as an interoperable contract. A usable standard needs common semantics for a request and response, version negotiation, error behavior, privacy properties, conformance tests and a path for independent implementations. It must state what a service is allowed to infer and what an issuer, device or intermediary must not learn.

None of these properties proves that the policy itself is wise or that a mechanism protects children effectively. They establish architectural constraints for jurisdictions that choose an age-based rule. That boundary matters: engineering advice can show how a mandate creates risk without claiming authority to decide what a legislature should restrict.

The device route is promising because it can keep identity local

The IAB assesses device-based mechanisms as the most promising given current technological maturity. The qualification matters. “Most promising” is neither “selected” nor “proven”. No protocol, operating system, browser, credential issuer or supplier is approved by the statement.

The attraction is clear. A user might establish an age property once in a device-held context and later give a service only the narrow signal it needs. The service would not receive full identity, the issuer would not learn each destination, and repeated checks would not create the same centralized trail. The hardware in the user's possession can mediate the exchange rather than an intermediary's server observing every transaction.

This is a different control geometry, not control-free architecture. A device platform can decide which assurance methods qualify, how household roles are represented, whether an alternative browser receives equal access, how errors are appealed and which jurisdictions are supported. It can update the interface or retire a version. A service can decide how much weight to place on the result. An issuer can still exclude users who lack acceptable evidence.

Shared devices expose the gap quickly. A tablet used by several family members cannot safely equate the device with one person's age. A household may include adults, teenagers and children with different legal rules and safety needs. If switching profiles is confusing, unavailable or easy to bypass, the elegant privacy model can fail in ordinary use. The statement therefore calls out robust multi-user support rather than treating it as product polish.

The open-interface condition is what keeps device mediation from becoming device sovereignty. Any conforming device, operating system or browser must be able to implement the exchange. Websites should request a defined signal, not require one platform's account, wallet or proprietary verification ritual. The distinction is small in an API diagram and constitutional in a market: one lets implementations compete; the other turns compliance into a distribution advantage.

A workshop report and an IAB statement are different records

The IAB and W3C convened their workshop in October 2025. Its official group page says the purpose was to examine technical and architectural choices, build a shared understanding and not necessarily identify a single candidate solution. Factors included privacy, equity, centralization, circumvention, cost, accuracy, jurisdiction and censorship.

The call for papers also marked a scope boundary. Regulatory choices about which content should be restricted were out of scope; the workshop focused on how restrictions interact with Internet and Web architecture. Participation was by invitation, under a modified Chatham House rule, and the promised output was a report.

That report became RFC 9998 in June 2026. It is an Informational document on the IAB stream, not an Internet Standards Track specification. More importantly, it says the views described are those of participants, do not necessarily reflect IAB or W3C positions and were not assembled as a claim of workshop consensus.

The distinction prevents borrowed authority. A workshop can surface a useful concern without making it an institutional conclusion. The IAB may later adopt some analysis in a formal statement, reject another part or frame the issue differently. The 24 August text is news because it is the IAB's own current position; RFC 9998 supplies context and evidence, not a shortcut that turns every workshop contribution into that position.

RFC 7841 explains why stream and category labels matter. Not every RFC is standards-related, and non-IETF-stream documents do not pass through IETF-wide Last Call and IESG approval. A durable public record must preserve workshop observation, IAB statement, candidate specification, approved standard, certified implementation, legal mandate and deployment as separate states.

The IAB can advise architecture without legislating access

RFC 2850 charters the IAB as a committee of the IETF and an advisory body of the Internet Society. It gives the Board long-range architectural oversight, standards-process oversight and appeal, liaison and advice functions. It also contemplates workshops whose reports can advise the IETF community and IESG.

RFC 9281 preserves the same distribution of roles in a newer map of the standards process. The IAB reviews architecture and process and generally supplies technical, architectural, procedural and policy advice. It is neither a national legislature nor the regulator responsible for a service's legal duty.

That limit does not make the statement weak. Advice is valuable when it is timely enough to change a decision before dependence hardens. The IAB can show that a technology-specific mandate will pressure encryption or centralize identity without claiming the power to enact or annul the mandate. A regulator can specify the public outcome and remain responsible for legality, scope, remedy and effectiveness. A standards body can define an interoperable interface. Vendors can implement it. Services can apply the lawful rule. Users can contest errors.

The roles need separate receipts because each actor can prove only its own act. An IAB statement proves an architectural position. A standards document proves a specification reached a named status. A certification proves an implementation passed stated tests. A law proves a legislature enacted text for a jurisdiction. Production evidence proves a mechanism operated under measured conditions. No badge can substitute for the others.

RFC 3935 adds the final restraint: an IETF standard describes how to do something when claiming conformance; it does not mandate or police use. Even a future age-signal standard would not by itself establish legal authority, policy wisdom or successful deployment.

The open interface needs a substitution receipt

The IAB warns that hastily deployed systems become difficult to dislodge after economic incentives and widespread dependencies form. In Internet architecture, it calls that ossification. Outcome-based mandates and interoperable interfaces are intended to leave space for better mechanisms as they mature.

That principle becomes operational only when replacement can be demonstrated. Daniel Kade's proposed receipt has five linked parts.

First, define the outcome independently of the supplier: which user, service and jurisdiction are in scope; what access result is required; what safety benefit is expected; and which error and appeal obligations apply. “Use vendor X” is not an outcome.

Second, fingerprint the signal contract: the minimum fields, threshold semantics, binding context, lifetime, replay protection, unlinkability properties, version and failure states. A successor must be able to implement the same public contract without copying a private identity store.

Third, test implementation diversity. At least two independently controlled devices, operating systems or browsers should be able to produce or carry conforming signals. A service must not need a separate proprietary integration for each one, and an alternative implementation must not lose legal recognition merely because it lacks the incumbent's account system.

Fourth, test migration. Change the assurance provider, device and browser separately. Observe whether identity disclosure expands, household state survives safely, services continue to interpret the signal, users retain an appeal route and old correlation handles become useless. A standard that works only before the first supplier change has documented syntax, not interoperability.

Fifth, attach a review trigger. Evidence of high false rejection, breach concentration, discriminatory exclusion, ineffective safety, encryption pressure, service withdrawal or excessive supplier concentration should reopen the implementation choice. The trigger is not a promise to abandon child safety. It protects the ability to reach the same objective with a less harmful mechanism.

The receipt also limits what can be claimed. Passing it would not prove that every user is safe, that every jurisdiction agrees or that circumvention has ended. It would show something narrower and essential: the public outcome is not hostage to one technical controller.

The IAB Wants Age Rules to Name Outcomes, Not Freeze a Gatekeeper

Summary

The check changes hands

Why the service and network routes worry the IAB

Seven properties narrow the signal

The device route is promising because it can keep identity local

A workshop report and an IAB statement are different records

The IAB can advise architecture without legislating access

The open interface needs a substitution receipt

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing