RFC 9998

Report from the IAB/W3C Workshop on Age-Based Restrictions on Content Access

📅 published June 2026, from ietf

RFC 9998: Report from the IAB/W3C Workshop on Age-Based Restrictions on Content Access 💖

okay bestie, this one is an Informational report 🎀 from the Internet Architecture Board (IAB), and it was written by M. Nottingham and M. Thomson. It's dated June 2026, and the ISSN is 2070-1721 ✨. The title block doesn't list anything it obsoletes or updates, so there's no older RFC being replaced here 🌸

It's a summary of what people said at the workshop, not a set of rules anyone has to follow 💅

Abstract ✨

The Workshop on Age-Based Restrictions on Content Access was held by the Internet Architecture Board (IAB) and the World Wide Web Consortium (W3C) in October 2025 🦋 This report recaps the big talking points and flags topics that might be worth more thought and work later 🧚

heads up though: this is a report on what happened at the workshop. The views and positions in it belong to the people who took part, and they don't necessarily match the views of the IAB or W3C 🙈

Status of This Memo 🌈

This document is not an Internet Standards Track spec. It's published for information only 💜

It's a product of the Internet Architecture Board (IAB), and the IAB decided it was valuable enough to keep on the permanent record ✨ It reflects the consensus of the IAB. Documents the IAB approves for publication aren't candidates for any level of Internet Standard, which you can read about in Section 2 of RFC 7841 💅

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9998 🔥

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved 🌸

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date it was published 📜 Read those carefully, because they spell out your rights and restrictions for this document 👑

Table of Contents 🍓

1.  Introduction
  1.1.  Views Expressed in This Report
  1.2.  Chatham House Rule
2.  Overview of the Workshop
3.  Key Takeaways
  3.1.  There Is a Need for Cross-Cutting Collaboration
  3.2.  Identifying the Roles Involved Is Important
  3.3.  A Common Vocabulary Is Necessary
  3.4.  Privacy and Trust Expectations Need Further Discussion
  3.5.  More Than One Approach Will Be Required
  3.6.  Mapping the Risks for Architectures Is a Useful Next Step
  3.7.  Safety Requires More Than a Technical Solution
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
Appendix A.  Workshop Agenda
  A.1.  Topic: Introduction
  A.2.  Topic: Setting the Scene
  A.3.  Topic: Guiding Principles
  A.4.  Topic: Potential Impacts
  A.5.  Topic: Where Enforcement Happens
  A.6.  Topic: Available Techniques
  A.7.  Discussion
  A.8.  Summary and Reflection
  A.9.  Outcomes
Appendix B.  Workshop Participants
Appendix C.  Potential Impacts
  C.1.  Impact on Children
  C.2.  Ecosystem Impact
  C.3.  Implementation and Deployment Difficulties
  C.4.  Security and Privacy
  C.5.  Equity
  C.6.  Societal Impacts
Appendix D.  Desirable and Essential Properties of a Solution
  D.1.  Functional
  D.2.  Accountability and Transparency
  D.3.  Privacy and Security
  D.4.  Equity
  D.5.  Jurisdiction and Geopolitical
  D.6.  Usability
  D.7.  Implementation and Deployment
  D.8.  General/Other
IAB Members at the Time of Approval
Authors' Addresses

1. Introduction ✨

Governments and lawmakers all over the world are getting more and more into restricting what young people can see online, all in the name of cutting down on potential harm 👀

In October 2025, the Internet Architecture Board (IAB) and the World Wide Web Consortium (W3C) got together for the Workshop on Age-Based Restrictions on Content Access 🎀 It brought together technologists, civil-society advocates, business folks, and government stakeholders to dig into the nuances of bringing these measures in 💖

The main goal was "to perform a thorough examination of the technical and architectural choices that are involved in solutions for age-based restrictions on access to content" with the aim of "build[ing] a shared understanding of the properties of various proposed approaches" 🧚

If you want the details, see the workshop announcement [ANNOUNCE] 📣 The papers and presentation materials are linked from there. This report is the recap of what the workshop covered 🦋

1.1. Views Expressed in This Report 🫶

This is a report on what happened at the workshop 🌸 The views and positions in it were shared by participants during the event, and they don't necessarily reflect the views or positions of the IAB or W3C, or of every participant either 🙈

Also, the report's content comes from presentations by participants and from notes taken during the discussions, with no interpretation or checking 🔍 So it follows the flow and back-and-forth of the workshop, but it doesn't try to capture a consensus ✨

1.2. Chatham House Rule 🤫

The participants agreed to run the workshop under the Chatham House Rule [CHATHAM-HOUSE] 💅 That means this report doesn't attribute statements to individuals or organizations without their express permission. Most submissions to the workshop were public, so they can be attributed, and they're used here for substance and context 💜

Appendix B lists the workshop participants, unless they asked for that info to be kept private 🌈

Part 1 of 5 is done! 🎀 More parts are coming, so stay tuned, bestie 💖

2. Overview of the Workshop 🌸

okay so the IAB/W3C Workshop on Age-Based Restrictions on Content Access 💅 pulled together a super mixed crowd from technical, policy, regulatory, and research communities to figure out how the Internet could handle age-based access controls. For three days, the talks went everywhere: technology, governance, human rights, social expectations. The recurring themes were privacy, accountability, and keeping the open architecture of the Internet intact 🦋

The workshop kicked off with a framing session about the Internet's original design as a universal, non-segmented space ✨ People pointed out that the Web doesn't naturally tell adult and child users apart, and that governments are building regulatory environments that move responsibility from parents and individuals onto service providers. The scope was tightly defined, bestie. It wasn't about whether age restrictions are moral or good policy. It was about the technical, architectural, and human-rights implications of enforcing them. The challenge, as many people agreed, is building mechanisms that are accurate, respect privacy, keep global interoperability, and avoid creating infrastructure that could get repurposed for censorship or surveillance 😭

Early on, the conversation got stuck on terminology and scope. Should "age verification" mean narrowly checking identity, or more broadly "age assurance"? 🤔 People also talked about how different cultures think about parental authority, and how legal frameworks are popping up all over different jurisdictions. Some folks warned about "slippery slope" effects, where mechanisms built for age checks could slowly turn into tools for broader identity enforcement 💀 Several people noted that while liability drives a lot of policy decisions, technical design should aim to minimize harm and avoid over-centralization. And the question of who is responsible for child safety (platforms, regulators, or device manufacturers?) kept coming back again and again 🙈

Human-rights principles were the main lens for evaluating everything 🌈 Privacy was discussed not just as data protection law (including techniques like minimization) but also as protection from unwanted exposure or interaction. Freedom of expression and opinion came up too, especially the fact that both adults and children have rights to communicate, access information, and associate without the chilling effects of surveillance or discrimination. The group also revisited old-school Internet design tenets like decentralization and the end-to-end principle, asking how those should shape modern architectures that could easily drift toward central control 👑 Some argued that successful systems have to stay open, interoperable, and reversible. Others warned that any solution, even a well-intentioned one, would inevitably reshape the Internet's social and economic balance ⭐

On the technical side, sessions explored a spectrum of enforcement models: service-based, network-based, and device-based 🧚 Service-based enforcement puts the compliance burden on websites, which risks fragmentation and user fatigue from repeated verification flows. Network-based filtering (already common in some jurisdictions) offers broad coverage but limited accuracy and big privacy trade-offs. Device-based enforcement, where operating systems mediate access based on a one-time verification, got praise for potential usability and consistency, but also criticism for possibly concentrating power among major vendors 👀 Lots of participants noted that a pluralistic approach is more likely to succeed, since no single architecture can meet all requirements equally across jurisdictions 💜

Privacy-enhancing technologies (PETs) like anonymous credentials and zero-knowledge proofs (ZKPs) were discussed as promising tools, though not necessarily sufficient 🎀 PETs don't address all privacy concerns, and they also don't address the wider issues around access to underlying sources of truth. Some participants cautioned that PETs cannot prevent circumvention or censorship, and that they're relatively untested. They also said that open-sourcing code does not automatically make a system trustworthy 🫶 A recurring worry was that credential-based verification might work great in countries with unified ID systems, but it risks excluding people who don't have access to such credentials and entrenching inequalities 😤

Discussions about parental controls and network operator roles showed the practical tensions between effectiveness, usability, and user rights 🍓 Some people saw value in layered approaches that combine device, service, and network measures. Others pointed out how complex parental-control tools are, and how rarely people adopt them even when they're available. The workshop also looked at the ethical side: could building better tools accidentally legitimize overbroad or intrusive regulation? That's a big question, not gonna lie 🥺

By the third day, everyone was reflecting on the need for collaboration across disciplines and institutions 🤝 Many people admitted that complete solutions are unlikely in the short term, but that agreeing on shared vocabulary, architectural roles, and evaluation properties is an essential foundation. There was broad agreement that future work should map risks against possible architectures, document trade-offs in neutral terms, and communicate clearly with policymakers so that outcomes don't undermine Internet openness 🌟

The meeting closed with reflections on what process could take proposed solutions through a standards process 📚 Both IETF and W3C representatives explained how exploratory work might proceed within their frameworks, and stressed that standardization would take consensus, open participation, and time ⏳

Now, a workshop can't produce specific standards proposals or take positions on whether regulatory proposals are advisable 🙅‍♀️ Still, it was suggested that leadership bodies, including the IAB and the Technical Architecture Group (TAG), could make statements to that effect 📣

Here's the vibe check: most participants found the current status quo unsatisfying, where age restrictions are piecemeal, opaque, and often privacy-eroding 😩 But many cautioned that hasty solutions could entrench even worse problems. That led to a growing recognition that protecting children online must not come at the expense of the Internet's foundational freedoms, and that sustained, multi-stakeholder collaboration is the only viable path forward 💖

3. Key Takeaways 🔑

This section highlights the parts of the workshop discussion that seemed most impactful ✨

3.1. There Is a Need for Cross-Cutting Collaboration 🫂

Lots of participants said the workshop helped them appreciate perspectives they hadn't fully considered before 🧠 Although several substantial efforts have included industry, civil society, government, and technologists, collaboration across all stakeholders seems to be rare, which is kind of wild 😭

This was especially obvious when it came to the technical community. There have been a bunch of consultations by governments and other bodies, but the technical community's involvement is often limited to policy representatives from technology companies. That can lead to an underappreciation of the architectural impact and related harm of design decisions 🙈

Architectures that work well for the goals and are less likely to have profound harmful consequences may need multiple actors fulfilling different roles (see Section 3.2) 🧩 So standardization may be especially important for interoperable, collaborative development of architectures involving both servers and clients 🌈

Some participants also noted that approaches where liability sits with only one party (for example, a content or platform provider) are unlikely to get the desired results. Why? Because it creates disincentives for the cooperation that's necessary for meaningfully reducing harm 💅 An approach that considers the roles of young people, their parents, device manufacturers, operating system vendors, content providers, and society overall was believed to be more likely to succeed 👑

3.2. Identifying the Roles Involved Is Important 🎭

One of the more substantive discussions on architecture involved presentations on the functional roles involved in any system [HANSON] 📊 Four key roles were identified, and honestly, this part is so helpful 🦋

Verifier: The verifier role determines whether a person falls into a target age range 🪪

Enforcer: The enforcer is responsible for ensuring that a person who does not satisfy the verifier is unable to access age-restricted content or services 🚧

Policy selector: The policy selector is responsible for determining which policies should apply to the user, based on their jurisdiction, status, or preferences 🗺️

Rater: The rater is responsible for determining whether content or services require age restrictions and the age ranges that apply 🏷️

Also, it was noted that ratings and laws are often limited by geography or jurisdiction, so services often need to figure out the applicable jurisdiction first 📍 It was generally accepted that this function often uses IP geolocation mappings, even though they have acknowledged limitations around accuracy and are susceptible to getting around things with VPNs 🙃

3.3. A Common Vocabulary Is Necessary

Early on, everyone kept talking past each other because they didn't all use the same words for the same activities or functions 🙃 People agreed that shared language matters, and some pointed to [ISO-IEC-27566-1]. Here are the key terms as participants discussed them, bestie 🎀

  • Age assurance: This is an umbrella term 🌸 for technology that gives some entity information about a person's age. It covers several classes of specific methods, including age verification, age estimation, and age inference. Age assurance doesn't have to produce one specific age. Age ranges are often preferred because they can have better privacy properties 🔐
  • Age verification: This means gaining high assurance that a person is within a given age range. Strong assurances are often tied to official or governmental documentation, so age verification can involve government-issued digital credentials 🪪
  • Age estimation: This uses statistical processes that look at a person's physical or behavioral characteristics to produce a probabilistic value for how old someone is, or whether their age falls in a target range. Lots of techniques are used, but the most common is facial age estimation, which uses machine learning models to estimate how old a person is from still or moving images of their face 📸
  • Age inference: This draws on data sources to work out whether a person fits a given age range. It can require identification information, such as an email address or phone number, to find relevant records. For example, evidence of online activity before a certain date in the past might support the view that a person is older than a target threshold 🕰️
  • Age gating: This is the process of restricting access to something based on the age of the person requesting access 🚪

Relating these functions to the roles described in Section 3.2, all age assurance types fit the "verifier" role, whereas age gating applies to the "enforcer" role 🧚

3.4. Privacy and Trust Expectations Need Further Discussion

Privacy came up again and again at the workshop, but it got very clear that there are multiple things to consider 🔍 Privacy often got tangled up with trust, and each approach depends on different kinds of trust between the different actors 🫶

Participants identified privacy as important to maintaining trust in any system that involves age assurance or age gating 💜

Where private information is used by the actors in a proposed architecture, those actors might need to be trusted to handle that information responsibly. In that approach, safeguards on personal information become a core part of what might let people trust the system. Prompt disposal of personal information is one example, and it's a practice that many age verification providers promise 🗑️✨

Several people observed that the kind of trust being asked of people might not match the role certain entities play in people's lives. It depends on context: "adult" content providers generally serve anonymous users, whereas social media often already holds a lot of personal information about its users 👀

In either case, users might have no prior knowledge of providers contracted to provide age assurance functions, or no trust in them. It was observed that one likely consequence of some arrangements is training people to become more trusting of strange sites that ask for personal information 😬

Alternatively, trust might not be placed in actors at all, but in the system as a whole. This is possible if no information is made available to different actors, which removes the need to trust how they handle private information 🤯 To make that achievable, the use of ZKPs or similar cryptographic techniques was seen as a way to limit what each entity learns. However, some participants noted that these techniques do not address circumvention or censorship risks. They also still introduce new information into the ecosystem and may concentrate trust in particular software implementations 🚩

Other aspects of trust were considered equally important from different perspectives. Services that rely on an independent age assurance provider need to trust that the provider makes an accurate determination of age, at least to the extent that they might be held liable in law. They also need to trust that the service respects privacy, because using a low-quality provider could create other forms of liability or drive away potential customers 💅

3.5. More Than One Approach Will Be Required

A recurring theme in the discussion was that no single age assurance technique is enough to make sure people aren't unjustifiably excluded 😭 Every age assurance method discussed fails to correctly classify some subset of people:

  • Age verification that depends on government-issued credentials will fail when people don't hold accepted credentials. This includes people who don't hold credentials at all, and people whose credentials aren't recognized 🙅‍♀️
  • Age estimation produces probabilistic information about age that can be wrong by some number of years, which can exclude people near threshold ages 🎂 This shows up as both false acceptance (people who are outside the target age range being accepted) and false rejection (people who are in the target age range being rejected). If the goal is to minimize the false acceptance rate, that increases the number of false rejections 📉
  • Age inference techniques can fail due to lack of information 🫥

Discussion often came back to an approach that is increasingly recommended for use in age verification, where multiple methods are applied in series. Checks with lower friction (meaning they require less active participation from people) or checks that are less invasive of privacy are attempted first. Successive checks are only used when a definitive result can't be achieved 🪜

Some participants noted that inconsistent friction and invasiveness create a different kind of discrimination, one that can make existing adverse discrimination worse 💔 For example, the accuracy of age estimation for people with African ancestry is often significantly lower than for people with European ancestry [FATE]. This is attributed to the models being trained and validated on datasets with less coverage of some groups. People affected by this bias are more likely to need to engage with more invasive methods 😤

One consequence of having multiple imperfect techniques is the need to recognize that any system will be imperfect. That creates several tensions 🌪️

  • Some people will never be able to satisfy age assurance checks, and so they'll be excluded by strict assurance mandates. Here, discussions acknowledged that purely technical systems are likely inadequate 🛑
  • Some people who should be blocked from accessing content or services will find ways to get around restrictions. In this context, the term "advanced persistent teenager" was recognized as describing the nature of the "adversary": individuals who are considered too young to access content, but who are highly motivated, technically sophisticated, and have time to spare 🕵️‍♀️💀
  • Offering people more choices can improve privacy, because they get to pick the method that suits them. However, when a chosen method fails, having to engage with additional methods has a higher privacy cost 🎭

Some participants argued that accepting these risks is necessary in order to gain any of the benefits that age-based restrictions might confer 🤷‍♀️ Other participants were unwilling to accept potential impositions on individual rights, given how insufficient restrictions are at providing meaningful protection. See Section 3.7 for more on that 🌈

3.6. Mapping the Risks for Architectures Is a Useful Next Step ✨

Okay bestie, the way the group talked about how the roles from Section 3.2 get arranged into actual architectures was lowkey the most substantive chat of the whole workshop 🧠💖. [JACKSON] walks through some of the alternatives and what each arrangement brings with it, so go read that too 🦋.

Here's the vibe: active deployments almost always land on the same pattern. Content providers have to age-gate access, and then they contract a third party to run that service for them 💅. Several people pointed out that this is kind of a natural result of the constraints actors are stuck with 🫶. Figure 1 shows the typical deployment model for age-gated content and services, with the roles from Section 3.2 labelled.

   o
---+---  +------------+                      +-----------+
   |     |            |       Visits         |           |  Rater +
   +     |  Browser   |--------------------->|  Website  |  Policy
  / \    |            |                  .---|           |  Selector
 /   \   +------------+                 |    +-----------+
               |   |      Redirected To |
               |   |                    |    +-----------+
               |   |                     '-->|           |
               |   |     Evidence of Age     |    Age    |
               |    '----------------------->| Assurance |  Verifier
               |                             |  Service  |
               |                         .---|           |
               |                        |    +-----------+
               |          Redirected To |
               |                        |    +-----------+
               |                         '-->|    Age-   |
               |           Admitted          |   Gated   |  Enforcer
                '--------------------------->|  Content  |
                         or Blocked          +-----------+

Figure 1: Typical Deployment Model

Some participants also flagged that certain approaches can carry higher path-dependence risk once they're widely deployed 😬, even if they're still theoretically possible to withdraw or replace. This can come from accumulated architectural dependencies, from operational integration with third-party services, and from changing expectations among users and service providers 🌸. So architectures that tightly couple functionality with external verification services, or that bake in assumptions about routine age signaling, may make transition more expensive 💸 if better alternatives show up later that handle privacy, equity, or effectiveness concerns more effectively ✨.

Figure 2 shows a deployment model for parental-control software and how the roles from Section 3.2 might apply to it 🧚. Here, the parental controls do any age verification that's needed and select policies 💜. Content ratings might be done by websites, by the parental-control software on the device, or by both (marked with a "*" in the figure) 🎀. Enforcement happens on-device 📱.

   o
---+---  +------------+       Visits         +-----------+
   |     |            |--------------------->|           |
   +     |  Browser   |    (Rated) Content   |  Website  |  Rater*
  / \    |            |<---------------------|           |
 /   \   +------------+                      +-----------+
               ^     ^
               |      \
               |       \__ Rater* +
               |           Enforcer
               |
         +------------+
         |  Parental  |  Verifier +
         |  Controls  |  Policy Selector
         +------------+

Figure 2: Parental-Control Deployment Model

An observation was made that lawmakers often want to name a single entity as responsible for making sure age restrictions actually work 🙈. That need to designate a responsible entity comes from how laws function, but it also creates its own constraints 🌀.

Another constraint was the need for specialist expertise to run all the different age assurance techniques, see Section 3.5 🔍. This means services naturally tend to contract with specialist age assurance services 🤝.

Some of the proposed architectures were better able to work under these constraints 👑. Others needed more coordination, which just highlights how important the collaboration from Section 3.1 is 🫶.

When people talked about the constraints on different architectures, they often pointed to one particular aspect of an approach and said "that's risky" 😅. In fact, the final reckoning of risks came out as a long list of potential issues that might need mitigation (see Appendix C) 📋.

Architectures aren't equally vulnerable to every risk, so we need a more thorough analysis to figure out how each risk applies to each approach 🔬. An analysis that looks at the constraints and assumptions needed to successfully deploy different architectures would be a contribution participants would likely welcome 💖.

3.7. Safety Requires More Than a Technical Solution ✨

Experts in child safety kept saying that restricting access to selected content can't be assumed to be enough 🛡️. Keeping children appropriately safe while preparing them for the challenges they'll face over their lifetimes is a massively complex task 🌈.

A recurring theme was the old maxim, "it takes a village to raise a child" 🏡. This idea crosses cultural boundaries, and people recognized it 🫶. The roles that parents, guardians, educators, governments, and online services play in creating an environment where children can thrive and grow were discussed too 🌸.

Content and service restrictions are likely only a small part of a bigger set of actions that work together to give children protection, but also support and encouragement 🧚. This theme came up several times, even though the goal of the discussion was to explore technical and architectural questions 🤓.

Restrictions are necessarily binary and lack nuance 🙃. Questions of what to restrict were out of scope for the workshop, but the discussions often surfaced subject matter that showed how hard it is to make simplistic classifications 🧩. People acknowledged how important the adults who support children on their life journey are 💜. For example, eating disorders can be really hard to classify, and participants stressed that being able to recognize trends and inform and engage responsible adults matters a lot 🍓. Ultimately, every child has their own challenges, and the people around them are in the best position to give the support that suits that child best 💖.

The concept of age-appropriate design came up on several occasions 🎨. It presents significant privacy challenges, because it means giving services more information about age 😬. Still, people recognized that services have legal and moral obligations to cater to the needs of children in different age groups 🌟. That's a much more complex problem space than binary age restrictions, since it requires recognizing how children's needs change as they get older 🌱.

4. Security Considerations ✨

Age verification has a significant potential security impact upon the Internet; see Section 3.4. 💀🔥

5. IANA Considerations ✨

This document has no IANA actions. 🫶

6. Informative References ✨

Appendix A. Workshop Agenda 🎀

This section contains a copy of the workshop agenda. 📋

A.1. Topic: Introduction 👋

We'll kick off the workshop with a greeting, a round of introductions, and an explanation of the terms of engagement, background, goals, and non-goals of the workshop 🌸.

A.2. Topic: Setting the Scene 🎬

Successfully deploying age restrictions at Internet scale comes with lots of considerations and constraints 🌍. We'll explore them at a high level, one at a time 🧭. The goal is for the group to talk through the scope of topics the workshop will try to address 💬.

A.3. Topic: Guiding Principles 🧭

Architectural principles give us a framework for evaluating additions and changes to the Internet ✨. Technical principles are subject to a bunch of other considerations, especially human-rights principles 🕊️. We'll review the principles that might apply to age-based restrictions, explain what they do, what impact they have, and how they're applied 📚. This includes human-rights impacts, such as:

  • Privacy and Security
  • Safety and Efficacy
  • Censorship and Access
  • Access to the Internet
  • Freedom of Expression

It also covers effects on the Internet and Web architecture, such as:

  • Deployment, Extensibility, and Evolution
  • Avoid Centralization
  • End-to-End
  • One Global Internet/Web
  • Layering and Modularity

A.4. Topic: Potential Impacts 💫

We want to look at some of the higher-level considerations that apply no matter what approach you pick 🔭. We'll check out some different perspectives on how to think about the overall problem 👀. The discussion will try to figure out how those perspectives can be shaped to guide choices 🧩.

A.5. Topic: Where Enforcement Happens 🚪

The Internet standards community is in a unique position to make controlled changes to the architecture of the Internet, so there are multiple ways and places to deploy age restrictions 🌐. We'll examine the options, looking at the deployment properties of each location and configuration and how they relate to the architectural principles 🔎. In particular, we'll consider the establishment of new roles as well as the use of existing ones 🦋.

Appendix A. Workshop Agenda ✨

A.6. Topic: Available Techniques 🔍

okay so there are a bunch of age restriction systems out there, both live and still cooking 🍳. we're gonna look at each one through three lenses: how it vibes with the architectural principles, what impacts it could have, and what enforcement options come with it. the lineup is:

  • Age verification: including server-side solutions using government identity systems and ZKPs
  • Age estimation: including biometrics and data analysis
  • Age "inference" approaches
  • In-network solutions
  • Classification and on-device/parental-control designs

A.7. Discussion 💬

we're gonna circle back to the convos we didn't finish and revisit what we've learned about architecture 🧠✨

A.8. Summary and Reflection 🪞

we'll recap what we talked about and what we figured out so far 💖

A.9. Outcomes 🎯

we'll map out the potential outcomes, what happens next, and the next steps 🦋

Appendix B. Workshop Participants 🎀

okay, the attendees, listed with their main affiliation 💅 the program committee (PC), the Internet Architecture Board (IAB), and the W3C Technical Architecture Group (TAG) are also marked, so you know who's who 👑

  • Steve Bellovin
  • Hadley Beeman, TAG (PC)
  • Matthew Bocci, IAB (Observer)
  • Christian Bormann, SPRIND
  • Marcos Cáceres, TAG (Observer)
  • Andrew Campling, 419 Consulting
  • Sofía Celi, Brave
  • David Cooke, Aylo
  • Iain Corby, Age Verification Providers Association
  • Dhruv Dhody, IAB (Observer)
  • Nick Doty, Center for Democracy and Technology (PC)
  • Sarah Forland, New America Open Technology Institute
  • Jérôme Gorin, École Polytechnique
  • Alexis Hancock, Electronic Frontier Foundation
  • Julia Hanson, Apple
  • Wes Hardaker, University of Southern California Information Sciences Institute
  • Kyle den Hartog, Brave
  • Dennis Jackson, Mozilla
  • Leif Johansson, SIROS Foundation
  • Mallory Knodel, Article 19
  • Mirja Kühlewind, IAB (Observer)
  • Jonathan Langley, Ofcom UK
  • Veronica Lin, Carnegie Mellon University
  • Thibault Meunier, Cloudflare
  • Tom Newton, Qoria
  • Mark Nottingham, IAB (PC Co-Chair)
  • Georgia Osborn, Ofcom UK
  • Tommy Pauly, IAB (PC)
  • John Perrino, Internet Society
  • Eric Rescorla, Knight-Georgetown Institute
  • Beatriz Rocha, Ceweb.br
  • Omari Rodney, Yoti
  • Gianpaolo Scalone, Vodafone
  • Sarah Scheffler, Carnegie Mellon University
  • Andrew Shaw, UK National Cyber Security Centre
  • Aline Sylla, German Federal Commissioner for Data Protection and Freedom of Information
  • Martin Thomson, TAG (PC Co-Chair)
  • Carmela Troncoso, EPFL, the Swiss Federal Institute of Technology in Lausanne
  • Benjamin VanderSloot, Mozilla
  • Tara Whalen, World Wide Web Consortium (PC)

Appendix C. Potential Impacts 🌈

during the workshop, people were asked to name potential impacts, good or bad, that could come along with age-based restrictions 🙈 this list isn't exhaustive, it mostly focuses on the challenges around introducing these mechanisms, and it does NOT mean everyone agreed with every point 💜

C.1. Impact on Children 🧸

  1. Children encounter online harm
  2. Pushing kids to less safe resources
  3. Kids lose the ability to explore on their own
  4. Diminishing children's rights

C.2. Ecosystem Impact 🌐

  1. Centralization
  2. Fragmentation of the Internet
  3. Increased costs for running a website
  4. Chilling effects on use of the Internet
  5. VPNs proliferate
  6. Chilling effects on the publication of borderline content
  7. Less content being available online
  8. Restricting people to a few platforms/services
  9. More use/utility of the Internet due to a perception of safety
  10. More (or all) online services require a verified login

C.3. Implementation and Deployment Difficulties 🛠️

  1. Device compatibility
  2. "Advanced Persistent Teenagers"
  3. Difficulties regarding jurisdiction checking
  4. Spillover to other software (e.g., VPNs)
  5. Displacing users from compliant to non-compliant sites
  6. False sense of addressing the problem
  7. Dealing with conflict of laws
  8. Operators pulling out of territories
  9. Increasing the footprint of the deep web
  10. Imposition of cultural norms on other jurisdictions
  11. Technical solutions are reused for other purposes (scope creep)
  12. Dealing with obsolete and non-compliant systems

C.4. Security and Privacy 🔐

  1. Increased cybersecurity risks
  2. Fingerprinting risk
  3. Ad targeting could get creepier
  4. Needing to trust someone on their word without evidence
  5. Normalizing online identity requests -- increase to phishing risk
  6. Data breaches

C.5. Equity ⚖️

  1. Lack of access (e.g., due to lack of device support)
  2. Refugees, stateless people, people without identity
  3. Harm to vulnerable people
  4. Not addressing other vulnerable groups (i.e., not age-based)
  5. Lack of availability of redress mechanisms
  6. Users' rights to restitution
  7. Loss of control over and access to data
  8. Risk to anonymity
  9. Loss of ability to run software of your choice

C.6. Societal Impacts 🏛️

  1. Air cover for blocking the Internet
  2. User control of the content they see online
  3. Costs to society (e.g., regulatory overhead)
  4. Increased online tracking and state surveillance
  5. Use as a censorship mechanism
  6. Advancing foreign policy goals with censorship
  7. Abuse of guardians who don't cut off their wards

Appendix D. Desirable and Essential Properties of a Solution 👑

during the workshop, people were asked to nominate the properties they thought would be helpful, or even essential, for a solution in this space 🫶 the group agreed that not all of these can be achieved at once, since some goals pull against each other 😭

D.1. Functional ⚙️

  1. Underage don't access content that's inappropriate
  2. Not trivially by-passable
  3. Flexible enough to be provided through different means
  4. Bound to the user
  5. Reliable
  6. Handles user-generated content
  7. Enables differential experiences or age-appropriate design (not just blocking)
  8. Agile by design -- assume adversarial engagement
  9. Difficult to bypass
  10. Accurate

D.2. Accountability and Transparency 📋

  1. Transparency and accountability regarding what is blocked
  2. Minimizes the need for trust decisions
  3. Can be independently/publicly verifiable and tested
  4. Auditability
  5. Appeal mechanism for incorrect labeling of content

D.3. Privacy and Security 🔒

  1. Issuer-Verifier and Verifier-Verifier unlinkability
  2. Unlinkability across components
  3. Purpose limitation of the data processed
  4. Security of data processed
  5. Phishing-resistant
  6. Doesn't process or transfer any more data than is necessary
  7. Avoids becoming a tracking vector

D.4. Equity 🌸

  1. Inclusive
  2. Fair -- avoids or minimizes bias
  3. Does not create inequalities (e.g., across education, other properties)
  4. Discriminates solely upon age, not other properties
  5. Works on open devices
  6. Device independence
  7. Usable by people of all ages to increase their safety online
  8. User choice in who verifies their age, and how
  9. No clear losers
  10. Accessible to people with disabilities
  11. Includes appeal mechanisms for incorrect age determinations

D.5. Jurisdiction and Geopolitical 🗺️

  1. Able to handle arbitrary composition of different jurisdictional requirements (possibly down to school level)
  2. Applicable globally
  3. Applies the rule of law in the jurisdiction where it applies universally
  4. No concentration of power in any one entity (or small group of them)
  5. No concentration of power in any country
  6. Aligned to legal duties
  7. Based upon a valid legal basis

D.6. Usability 🧁

  1. Economically sustainable
  2. Low friction for adults
  3. Fast
  4. Comprehensible by users

D.7. Implementation and Deployment 🚀

  1. Low dependency on a single root of trust
  2. Enforceable by a good mix of technology and law
  3. Broad deployability -- not expensive or complex
  4. Decentralized
  5. Future-proof
  6. Ability to report/learn when there are issues in the system/telemetry

D.8. General/Other 🦋

  1. Not perfect
  2. Technically robust
  3. Not a single, sole solution
  4. Stable -- resilient
  5. Alignment of incentives among participants
  6. Simple to implement
  7. Resistance to repurposing for censorship
  8. Unable to be used for surveillance
  9. Addresses risk of verification becoming over-prevalent
  10. Accountable governance
  11. Open Standards-based

IAB Members at the Time of Approval 🌟

these are the Internet Architecture Board members at the time this document was approved for publication 💖

  • Ali C. Begen
  • Matthew Bocci
  • Roman Danyliw
  • Dhruv Dhody
  • Jana Iyengar
  • Suresh Krishnan
  • Warren Kumari
  • Jason Livingood
  • Mark Nottingham
  • Yingzhen Qu
  • Alvaro Retana
  • Yaroslav Rosomakho
  • Nick Sullivan

Authors' Addresses ✨

Mark Nottingham Email: mnot@mnot.net

Martin Thomson Email: mt@lowentropy.net

📦 where this page comes from