Age Assurance Architecture

1.1. Related Work

Several documents address the same problem. [RFC9998] records the IAB/W3C workshop discussion, [IAB-Statement-2026] sets out the IAB's position, and [I-D.knodel-age-arch] analyses age gating methods along two dimensions, efficacy and privacy cost, organised by trust anchor. This document is offered as an alternative architecture to the last. It differs mainly in using terminology consistent with ISO/IEC 27566-1 throughout, in treating assurance as a measurable and multidimensional property of implemented systems, in distinguishing privacy properties enforced by design from those that rely on policy, and in focusing on how age assertions are communicated and trusted between independently governed systems. Appendix A compares the two documents on specific points.¶

1.2. Terminology

Terms follow ISO/IEC 27566-1 and IEEE 2089.1 where those documents define them. The definitions below are paraphrased for an Internet audience; the referenced standards are authoritative. Some terms, including the forms of binding and triple-blind, are introduced by this document and are not defined in either standard.¶

Age assurance:

The umbrella term for processes that establish, with a stated level of confidence, that a person is of a certain age, over or under an age threshold, or within an age range. It includes age verification, age estimation and age inference.¶

Age verification:

Age assurance that relies on authoritative evidence of date of birth, such as a government-issued document, a digital credential or a trusted record, checked for authenticity and bound to the person presenting it.¶

Age estimation:

Age assurance that derives an estimate of age from physical or behavioural characteristics of the person, such as facial or voice features, typically using machine learning models.¶

Age inference:

Age assurance that draws a conclusion about age from other verified facts about the person, such as holding a payment card, a mortgage or a long-standing account, or from a combination of signals.¶

Self-declaration:

A user's unverified statement of age. It provides no independent evidence and is not age assurance in the sense used here, though it may be a useful first step in a waterfall of methods.¶

Age threshold:

The age that a relying party needs to know a user is above or below, for example 13, 16 or 18.¶

Over NN:

At least NN years of age (for example, a person who has reached their 18th birthday is "over 18"). In protocols it should be expressed as the inclusive test age >= NN, with the semantics defined explicitly.¶

Relying party:

The service that uses the result of age assurance to decide what access or experience to provide. It is the "enforcer" in the roles of [RFC9998].¶

Age assurance provider:

The party that performs age assurance and asserts the result. It may be an independent provider, the relying party itself, a credential issuer, a wallet, an operating system, app store or another intermediary. It is the "verifier" in [RFC9998].¶

Age assertion:

The result of age assurance as conveyed to a relying party, for example "over 18", together with information about its level of assurance, provenance and validity.¶

Level of assurance:

A standardised measure of the confidence that can be placed in an age assertion, reflecting accuracy, binding, resistance to attack and other factors. IEEE 2089.1 defines levels from Asserted through Basic, Standard and Enhanced to Strict. A level summarises confidence in the result; it does not describe every characteristic relevant to a particular relying party (Section 3.2).¶

Binding:

Measures that link an age result to a person. This document treats three related but different problems separately: initial binding (at the original check, the evidence or characteristics assessed belong to the person being checked), holder binding (the assertion or credential is tied to its legitimate holder, typically through a key whose control the presenter can prove) and contemporaneous person binding (the person presenting at the point of reliance is that legitimate holder). Device possession and successful local authentication establish holder binding, not contemporaneous person binding. Only contemporaneous person binding directly addresses sharing and collusion.¶

False acceptance / false rejection:

Accepting a person who is in fact below the threshold, or rejecting a person who is in fact above it.¶

Buffer (or challenge age):

A margin above the legal threshold that an age estimate must exceed, set from measured performance so that the false acceptance rate meets the requirement.¶

Reusable age assurance:

An age assertion established once and presented again to the same or another relying party, without repeating the original check.¶

Interoperability network:

An arrangement under which relying parties accept age assertions from providers they do not contract with directly, under common rules on assurance and liability.¶

Upstream age signal:

An age assertion or age range supplied by an operating system, app store, browser, network or device setting, rather than by the relying party's own check.¶

Triple-blind:

A property of an age assurance flow in which the relying party receives no identifying information beyond the minimum age-related assertion necessary for its purpose, the provider or issuer cannot learn which relying parties the user visits, and any operating system or other platform technically involved cannot learn which relying parties the user visits either. Relying parties should also be unable to link presentations by the same user. Section 4.7 distinguishes where each property is cryptographically enforced and where it rests on operational or legal controls.¶

Age gating:

Restricting access to content, features or goods on the basis of an age assertion.¶

2.1. Age Verification

Age verification checks authoritative evidence of date of birth. Sources include passports, identity cards and driving licences, whether physical or digital; government and other authoritative databases; and verifiable digital credentials such as ISO/IEC 18013-5 mobile driving licences [ISO-18013-5], SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] or W3C Verifiable Credentials issued by a state or other trusted issuer.¶

To reach a high level of assurance, verification needs two things. First, the authenticity of the evidence must be established, for example by validating the issuer's signature on a credential or the security features of a document. Second, the evidence must be bound to the person presenting it, for example by a liveness-checked comparison with the document photo. Where a credential is held on a device, device-bound keys and local authentication show that the presenter controls the device, but not necessarily that they are the person originally verified: a parent could hand over an unlocked device or authorise a presentation on a child's behalf. Where sharing is a significant risk, higher levels of assurance may call for contemporaneous person binding, such as a fresh face match against the credential's portrait, or for other controls in proportion to the risk.¶

Verification can also be performed entirely on the user's device. For example, an app can read the chip in an electronic passport or identity card over NFC, validate the issuing state's signature and compare the chip photo with a live selfie, so that personal data never leaves the user's hand and only the age result is shared.¶

A common assumption is that age verification requires the relying party to receive a copy of an identity document. It does not. In well-designed systems the provider inspects the evidence and returns only the age assertion, and selective disclosure credentials can prove "over 18" without revealing a date of birth to the relying party. Systems that copy documents to relying parties reflect poor practice, not a property of the method.¶

Verification is necessary where a specific date of birth must be established. It excludes people who lack accepted documents, so it should normally be offered alongside other methods rather than as the only route.¶

2.2. Age Estimation

Age estimation infers age from characteristics of the person, most commonly a facial image or short video, and sometimes voice or hand movement. It does not establish identity, and a well-designed implementation retains no image once the estimate is made.¶

Estimation can likewise run entirely on the user's device, so the image is never transmitted and only the estimated age or threshold result is passed on. Discord, for example, offers facial age estimation processed entirely on the user's device and deleted immediately afterwards, while its document checks are sent to a provider [Discord-AA]. On-device processing removes the risk of a central breach of images, but the result must still be protected against tampering on the device, for example by attesting the integrity of the software that produced it. The example illustrates data minimisation only; it does not by itself demonstrate resistance to presentation, injection or other attacks.¶

Older evaluations of facial age estimation, such as NIST IR 7995 from 2014, do not represent current technology. NIST IR 8525 [NIST-IR-8525] and the ongoing NIST age estimation evaluation [NIST-FATE-AEV] provide more recent measurements of algorithm performance, while the Australian Age Assurance Technology Trial [AU-AATT] provides additional evidence from independent evaluation. Performance varies between algorithms, age thresholds, demographic groups and capture environments, and laboratory results neither transfer automatically to a given capture setting nor establish resistance to attack. The appropriate architectural response is therefore to set measurable performance requirements, including false acceptance rates, and to require testing under conditions relevant to the intended deployment.¶

The relevant question is not whether an estimate can be wrong. It is whether the error at the relevant threshold is measured and managed. Estimation achieves a required false acceptance rate by applying a buffer: a user may need to be estimated at 21 or 25 to pass an 18 check. Users near the threshold who are rejected can be offered another method. This is the "waterfall" approach described in Section 3.5 of [RFC9998], in which lower-friction methods are tried first.¶

Differential performance across demographic groups is real and must be measured, reported and minimised. It is a reason for independent testing and certification (Section 3), not a reason to exclude the method. It is also a reason to ensure alternative methods are always available so users are not wrongly excluded.¶

2.3. Age Inference

Age inference draws a conclusion about age from other facts that are themselves verified. Examples include a credit card check with the issuing bank, the existence of a mortgage or other adult financial product, mobile network operator records showing an account without adult content restrictions, the age of an email address and its history of use, or a professional licence with a minimum age, such as a commercial airline pilot's licence. Such facts are evidence of age only to the extent that eligibility rules guarantee it, the fact is authentic and the person presenting it is the person to whom it relates. Holding a credit card shows that an account exists, not that the person at the keyboard is its holder. Some forms therefore need more data points, or added binding, than others to reach a given level of assurance.¶

Inference can be low-friction and privacy-protective when the facts are checked by the party that already holds them and only the result is returned. It can also be intrusive if it relies on profiling users without their knowledge. This document addresses inference performed as a deliberate, transparent age check, not behavioural profiling for other purposes.¶

Social media platforms have deployed a form of age inference, sometimes called "heuristics", to detect underage users who already hold accounts. Three months after Australia's minimum age law took effect, the share of 10 to 15 year olds holding an account on an age-restricted platform had fallen only from around 52% to 42%, and the eSafety Commissioner concluded that platform implementation remained ineffective [eSafety-SMMA-3M]. These findings indicate that the age assurance measures deployed by platforms during the initial implementation period did not reliably prevent under-16s from retaining or creating accounts. They do not, by themselves, establish the accuracy of any particular inference algorithm.¶

2.4. Parental and Guardian Involvement

Some legal requirements concern parental consent or parental controls rather than age restriction alone. These involve establishing that an adult is a parent or guardian of the child, and that the adult has consented or set a control. IEEE P2089.3 [IEEE-P2089.3] is developing a standard for online parental consent. Operating system and app store settings chosen by parents can be an effective way to implement such requirements, provided they meet the conditions in Section 5.¶

2.5. Reusable Age Assurance

Once established, an age assertion can be held by the user (for example in a wallet or as a device-bound token) or by a provider, and presented again later. Reuse reduces friction and the number of times personal data, if required at all, is processed. It also introduces new requirements: the assertion must remain bound to the right person, carry its level of assurance and validity and avoid acting as a persistent identifier across relying parties. Section 4 describes architectures that meet these requirements.¶

3.1. Components of Assurance

Drawing on ISO/IEC 27566-1 and IEEE 2089.1, this document groups the factors that determine confidence in an age assertion as follows. The grouping is this document's own; the normative requirements of each standard are set out in its published text.¶

• Accuracy. For verification, the rate at which forged, altered or invalid evidence is accepted. For estimation, the error in the estimate and its distribution, and in particular the false acceptance and false rejection rates around the relevant threshold. For inference, the strength of the link between the facts checked and age.¶

• Binding. How strongly the result is tied to a person, which involves three distinct questions (Section 1.2): whether the evidence assessed at the initial check belonged to the person checked; whether a reused assertion or credential is tied to its legitimate holder; and whether that holder is the person actually presenting it at the point of reliance. Live estimation addresses the first and third together, because it assesses the person in front of the camera at that moment. For reused results and evidence from another source, device possession and local authentication establish control of a credential, not that the original subject is the present user: a younger sibling who knows the PIN, or is handed an unlocked device, will pass them. Where sharing and collusion are significant risks, contemporaneous person binding, such as a fresh liveness-checked face match, is one control. Others include short validity periods, limits on reuse and risk signals, and the appropriate combination depends on the use case.¶

• Resistance to attack. Detection of presentation attacks (masks, photos or replayed video shown to the camera), evaluated for example to ISO/IEC 30107-3 [ISO-30107-3]. Separately, detection of injection attacks (synthetic or manipulated media inserted into the capture pipeline, bypassing the camera) and assurance of capture integrity, for which CEN/TS 18099 [CEN-TS-18099] provides an evaluation method. And controls against collusion and credential sharing.¶

• Bias. Measured differences in performance across groups defined by age, sex, skin tone or other protected characteristics, and steps to minimise them.¶

• Privacy and security. Data minimisation, retention, purpose limitation and the security of any personal data processed.¶

3.2. Levels of Assurance

Standard levels of assurance let a regulator or relying party specify the confidence it needs in an age result without prescribing technology. IEEE 2089.1 defines five levels: Asserted, Basic, Standard, Enhanced and Strict, with requirements set out in that standard. A level of assurance describes confidence that the age result is correct and belongs to the person presenting it. It does not capture everything a relying party or user may care about. Privacy properties and inclusion are separate dimensions, and should be expressed and assessed separately rather than folded into a single level. Assurance is therefore multidimensional, and a nominal level of assurance cannot substitute for understanding the characteristics relevant to a particular relying-party context: two results at the same level may differ, for example, in how they are bound to the person presenting them or in what they reveal. Certification status is not one of these dimensions; it is evidence about whether claimed characteristics have been established (Section 3.3).¶

This outcome-based approach is converging internationally. Ofcom's "highly effective age assurance" criteria in the UK (technically accurate, robust, reliable and fair) [Ofcom-HEAA] and the European Commission's guidelines under Article 28 of the Digital Services Act [EC-Art28] both set outcomes rather than mandate methods (although the Article 28 guidelines prefer verification where access is restricted to adults by law).¶

3.3. Independent Testing and Certification

Claims about accuracy, privacy and effectiveness should rest on independently verifiable evidence and comparable testing. Conformity assessment, including certification, is a mechanism for establishing confidence in claims about a system's characteristics; it is not itself one of those characteristics. Certification provides independently established objective evidence that specified requirements have been fulfilled, but it does not make an implementation effective, and its value depends on what those requirements cover. Three forms of evidence are available:¶

1. Laboratory evaluation of algorithms against common datasets, such as the NIST age estimation evaluation [NIST-FATE-AEV]. This measures algorithm performance, not a deployed service.¶

2. Conformity assessment and certification of a whole service against the requirements of a certification scheme, such as one based on IEEE 2089.1 or ISO/IEC 27566-1, by a certification body that is itself accredited by a national accreditation body to operate that scheme. A framework standard does not on its own define everything a scheme must test.¶

3. Test purchasing, online and face to face, which shows whether technology and processes work together in real deployments, including against attempts at circumvention.¶

The Australian Government's Age Assurance Technology Trial [AU-AATT], conducted independently by the Age Check Certification Scheme, combined laboratory evaluation and test purchasing with a review of each provider's practice statement, in the same way that conformity assessment bodies assess solutions.¶

Where a relying party performs age assurance in-house or relies on an upstream signal, the same kinds of evidence are needed to establish confidence in its claimed level of assurance and other characteristics. Assessment should also cover system-level properties such as privacy, unlinkability and resilience, a gap identified in [IAB-Statement-2026]. How regulators might recognise certification is a policy question, discussed in Appendix B.¶

3.4. Inclusion

Because every method fails for some people, inclusion is achieved by offering alternatives at the required level of assurance, not by lowering the level. A person without a passport, credit history, smartphone or suitable biometric characteristics should be able to use another method. Professional vouching, in which a trusted professional attests to the age of someone without documentary evidence, is one possible route, subject to independently established requirements for its reliability and binding. No single method should therefore be the sole route to compliance.¶

4.1. Roles

This document uses the roles from Section 3.2 of [RFC9998] and describes them in terms consistent with ISO/IEC 27566-1:¶

• User: the person whose age is assured.¶

• Age assurance provider: performs the check and issues the assertion.¶

• Credential issuer: a party, which may be a state, that issues evidence of age used by a provider or held by the user.¶

• Holder agent: software that holds a reusable assertion for the user, such as a wallet, browser or operating system component.¶

• Relying party: uses the assertion to decide access, and remains responsible for compliance.¶

• Policy selector and rater: decide which threshold applies to which content in which jurisdiction. These are usually the relying party, guided by law.¶

Source of assertion         Relying party      Privacy safeguard

+--------------------+    +---------------+
| A: direct check    |--->|               |  Provider sees service;
| provider, redirect |    | receives only:|  deletes data after check
+--------------------+    |               |
+--------------------+    | - age         |
| B: user-held       |--->|   threshold   |  Issuer not involved;
| wallet or device-  |    |   result      |  single-use or ZKP proofs
| bound credential   |    | - level of    |
+--------------------+    |   assurance   |
+--------------------+    | - accountable |
| C: interoperable   |--->|   provider    |  Pairwise or blinded
| prior check by     |    | - validity and|  tokens; no network-wide
| another provider   |    |   binding     |  identifier
+--------------------+    |               |
+--------------------+    |               |
| D: upstream signal |--->|               |  Platform ideally cannot
| OS, app store,     |    |               |  see service, else must
| browser, network   |    |               |  not log
+--------------------+    +---------------+

Whichever route an assertion takes, the relying party should receive the same minimised set of information, and each route has its own safeguard against tracking.¶

4.2. Age Assertion Information Model

A binary result is not enough for a relying party that remains responsible for the outcome. This section proposes a conceptual information model for an age assertion. The model describes what must be established, not what must be transmitted: some elements travel in each presentation, while others are established once through a trust framework or independently verifiable scheme rules.¶

Not everything needed for accountability must go to every relying party. Three sets of information should be distinguished: what the relying party needs to evaluate the assurance; what an auditor or scheme operator needs to establish accountability after the event; and what must be transmitted in every presentation. A rare issuer, a precise timestamp or other uncommon metadata can shrink the anonymity set and allow correlation even without a user identifier. Presentations should therefore carry coarse values where the relying party does not need more, for example a scheme or trust-list identifier rather than an individual provider, and a validity window rather than the time of the check.¶

An assertion should not carry the user's identity, date of birth, the evidence examined or any identifier that is stable across relying parties. Proposed work on ISO/IEC 27566-4 [ISO-27566-4] on interoperability and semantics for age assurance, not yet a published standard, would address how independently governed ecosystems can express and understand these characteristics.¶

4.3. Flow A: Direct Check

The relying party sends the user to a provider, by redirect or embedded component. The provider performs a check and returns a signed assertion to the relying party. This is the deployment model shown in Figure 1 of [RFC9998] and is widely deployed today. It can be made privacy-preserving if the provider deletes personal data once the check is complete and returns only the assertion. Its weakness is that the provider learns which relying party the user is visiting, and the user may need to repeat the check at each service.¶

4.4. Flow B: User-Held Reusable Assertion

A provider or issuer issues an assertion to a holder agent controlled by the user, bound to a key on the user's device. When a relying party requests proof of age, the holder agent presents the assertion, disclosing only the threshold result. Presentation can use OpenID for Verifiable Presentations [OpenID4VP], mediated in the browser by the W3C Digital Credentials API [W3C-DC-API], with credentials in ISO mdoc [ISO-18013-5] or SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] format. These formats and protocols are building blocks. Selective disclosure and unlinkability are different properties: a credential that reveals only "over 18" can still carry an issuer signature, credential identifier, holder key or other metadata that lets relying parties correlate presentations. Binding to a device key establishes holder binding; it does not establish who is using the device at the point of presentation (Section 1.2).¶

Because the issuer is not involved at presentation, it does not learn which relying parties the user visits, provided it does not also operate the wallet or receive status or revocation checks that reveal them. To prevent relying parties from correlating presentations, issuers can issue batches of single-use credentials (as in the EU age verification app blueprint [EU-AV-Blueprint]) or use zero-knowledge proofs, so that no signature, key or identifier repeats across presentations. The resulting privacy depends on how issuance, metadata and verifier behaviour are constrained, not on the credential format alone.¶

4.5. Flow C: Interoperability Network

A relying party asks its own contracted provider for an assertion. If the user has already been checked by another provider in the same network, the relying party's provider obtains a fresh assertion based on that earlier check rather than checking the user again. Networks need rules on equivalent standards, liability and the communication of levels of assurance, and must avoid a persistent network-wide identifier.¶

One design that meets this aim routes reuse through the user's browser or holder agent rather than between providers' servers. The relying party's provider asks the user agent for a reusable token. The user agent obtains from the originating provider a fresh, blindly signed, single-use token stating the age result and level of assurance, so the originating provider does not learn which relying party or which provider asked for it. The relying party's provider verifies the token against the originating provider's published key, obtained from the scheme's trust list. Because each token is used once, neither provider can link presentations. Variants in which providers exchange assertions directly between servers are simpler to deploy, but expose the requesting party to the originating provider and depend more on scheme rules.¶

The euCONSENT project [euCONSENT] piloted interoperable age assurance and parental consent between multiple providers across EU member states. It demonstrated that providers can accept each other's checks; it did not by itself demonstrate every privacy property described here.¶

4.6. Flow D: Upstream Age Signal

An operating system, app store, browser or network supplies an age range, usually established at account creation or set by a parent or guardian. The relying party queries it through a platform interface. This can be low friction and useful for parental controls. Where a relying party relies on such a signal to meet a legal requirement, the signal must meet the same conditions as any other assertion: a stated level of assurance, independent assessment and a clearly accountable party (Section 5).¶

A platform usually establishes the age of the account holder, not of the person using the device at a given moment. Shared devices and family accounts make that distinction material. A relying party should treat such a signal accordingly unless the platform binds it to the current user, for example through robust multi-user support.¶

4.7. Triple-Blind Operation

A triple-blind flow aims at three properties: the relying party receives no identifying information beyond the minimum age-related assertion necessary for its purpose; the provider or issuer cannot learn which relying parties the user visits; and the operating system, browser, app store or wallet provider cannot learn this either. Relying parties should also be unable to link presentations by the same user. Each property can be achieved in two quite different ways: by cryptographic or architectural design, so that a party is technically unable to learn the information, or by operational and legal controls, so that a party that can observe it commits not to retain or use it. The second is weaker and should be described as such.¶

The last row matters. Where presentation is mediated by the browser or operating system, for example through the W3C Digital Credentials API, the user agent can inspect the request and the requesting origin by design. A platform's commitment not to retain that information is not equivalent to being unable to observe it.¶

Browsers and operating systems necessarily process the addresses of sites that users visit, so it is not realistic to require that they never know the destination. The triple-blind requirement concerns something narrower: that the platform cannot observe, or does not record, that an age assurance transaction took place with a given relying party, or its result. A platform that knows a user visited a site, but not that the site asked for proof of age or what was proved, meets the requirement. An age assertion may itself be personal data under data protection law, particularly when combined with other information the relying party holds, which is why the requirement is framed as minimisation rather than as the absence of personal data.¶

Blind-signature token schemes such as Privacy Pass [RFC9576] [RFC9578] can be one component of an unlinkable presentation layer, by separating the party that attests age from the party that redeems tokens. They do not themselves establish age, a level of assurance or binding to the person, and the Privacy Pass architecture describes information that can leak depending on the deployment model. They need a separate age attestation mechanism and protection against token transfer. At least one option that is triple-blind by design, not only by policy, should be available in any ecosystem.¶

4.8. Mapping to Existing Specifications and Work in Progress

Each entry is a building block. None of them alone delivers the properties described in Section 4.2 and Section 4.7; those depend on how the components are combined, configured and assessed.¶

4.9. Trust Model

Signature verification is necessary but not sufficient. Before acting on an assertion, a relying party needs to establish that:¶

1. the assertion is authentic: its signature verifies against a key of the stated issuer or provider;¶

2. the issuer or provider is trusted for this claim, which the relying party learns from a trust framework, scheme operator or trust list rather than from the assertion itself;¶

3. the level of assurance, and any other assurance characteristics relevant to the use case such as binding or privacy properties, meet the relying party's requirements;¶

4. the assertion is valid: unexpired, not revoked and intended for this relying party; and¶

5. the presentation is bound to the person presenting it to the degree the use case requires, recognising that proof of control of a credential (holder binding) does not establish that its legitimate holder is the person present (contemporaneous person binding).¶

The trust framework supplies verification keys, trust lists and assurance policies to relying parties in advance. It need not be involved in individual transactions, which keeps it from becoming a point of observation. Proposed ISO/IEC 27566-4 work on interoperability is intended to let relying parties make these judgements across independently governed ecosystems.¶

5.1. Service Layer

The relying party is where the decision to grant or restrict access is made, and where legal responsibility usually sits. It determines the assurance characteristics appropriate to its risk, including but not limited to a level of assurance, chooses one or more providers and applies the result. This document treats the service layer as the primary point of decision, informed by assertions that may originate at any layer.¶

5.2. Operating System and App Store Layer

Operating system and app store signals can make age assurance easier, particularly where parents have set an age range for a child's device. They are well suited to laws that require parental consent or controls. Three conditions apply where they are used to meet legal obligations:¶

1. Equivalent assurance. The signal carries a stated level of assurance, is independently assessed and has an accountable party, as for any other source of age assertions.¶

2. Architectural openness. The interface between platform and service is an open standard. Relying parties can accept assertions from independent providers through the same interface (provider independence). Assertions are portable between trust frameworks, and no central intermediary is mandatory, so there is no single point of failure.¶

3. No tracking. Where the architecture allows, the platform should be technically unable to learn which relying parties request the signal. Where it can observe requests, it must not retain or use them, and that weaker, policy-based protection should be disclosed (Section 4.7).¶

[IAB-Statement-2026] considers device-based mechanisms the most promising current approach, provided the interface between device and service is an open standard and shared devices have robust multi-user support. This document agrees that on-device processing offers strong privacy. It notes that on-device processing is not limited to operating system vendors: independent providers can run verification and estimation on the user's device (Section 2), delivering the privacy benefit without concentrating control in a few platforms.¶

5.3. Network Layer

"Network" is often listed among the layers at which age assurance can operate, but there are few examples of it in practice. Operators already apply category-based filtering for subscribers who choose it, and in some jurisdictions by default on mobile connections. Such filtering avoids new personal data collection. The network layer may also have a more constructive role than blocking alone.¶

A mobile network operator often holds verified information about its account holder, including their age, and knows whether the account holder or a parent or guardian has set controls on a line. In principle, it could express this as a privacy-preserving age-range signal (for example under 13, 13 to 17 or 18+) rather than an enforcement decision. For example, it could indicate to a relying party, at the user's request, that a connection is subject to under-18 controls, without revealing the subscriber's identity. Such a signal could trigger safer defaults on a service, or a stronger check, without the network inspecting content. Because the person using a line may not be the account holder, such a signal describes the controls on the line rather than the age of its user.¶

Network signals face the same conditions as other upstream signals. They must be user-initiated or user-visible, must not create a persistent identifier observable by services, and must not be a vector for network-level censorship. They complement, rather than replace, checks at the service layer.¶

5.4. Geolocation

Age requirements vary by jurisdiction, so relying parties need some assurance of where a user is. Location assurance should be proportionate and privacy-preserving, for example by using coarse location rather than continuous tracking. VPN circumvention is a risk to be addressed in proportion to harm. Any approach to VPNs should respect their legitimate privacy and security benefits for users of all ages. Device-based location checks can return binary responses that confirm only whether a user is within a regulated jurisdiction, not their current location. Privacy-preserving location assurance could also use cryptographic proofs of jurisdictional eligibility, provided the underlying location evidence is trustworthy. Such approaches require an explicit trust model and measures against location spoofing. They should avoid unnecessary disclosure of precise location or persistent identifiers.¶

8.1. Failure Handling

Every method fails for some people, and every service is sometimes unavailable. Architectures should define:¶

• what happens when a method cannot reach a result, normally by offering another method at the same level rather than a lower one;¶

• how a person can challenge and correct a wrong determination, including one made by estimation or inference, without disclosing more data than the original check required;¶

• what a relying party does when a provider, issuer or status service is unavailable, and whether it fails open or closed given the risk; and¶

• how revocation of a compromised issuer, key or credential reaches relying parties.¶