Threat modeling age-based content restrictions: what we learned at EIC 2026

At the European Identity and Cloud Conference (EIC 2026) in Berlin, we ran a hands-on threat modeling workshop using LEGO® SERIOUS PLAY® as a facilitation method. The session built on the approach described in our earlier W3C post on threat modeling with LEGO® SERIOUS PLAY®, but used a more specific case: age-based content restrictions.

The choice was deliberate. EIC is one of the places where the digital identity market is visible while it is still taking shape. At EIC 2025, much of the conversation was about personal wallets: how to build them, distribute them, and get them adopted by relying parties, governments, and users. At EIC 2026, the discussion had shifted. AI was everywhere, and in identity that meant agent identity, non-human identities, workload identity, delegation, and intent verification in agentic scenarios.

The age-based content restriction use case

That does not mean human identity has disappeared from the agenda. It means the harder questions are now tied to concrete uses. Age-based content restrictions are one of those cases.

They are difficult because regulators are asking for operational solutions now, while the technical architecture is still unsettled. A design that affects access, privacy, anonymity, and interoperability can also create exclusion, surveillance, censorship, or reuse of the same infrastructure for other purposes.

This was also reflected in October 2025, when W3C and IAB organized a joint workshop on age-based restrictions for access to online content. That workshop focused on technical and architectural choices without assuming that there is a single correct solution.

This is the situation we wanted to model. Regulatory pressure often pushes people to look for "the solution". On the web, though, a mechanism that changes who can access content, how people prove attributes, and whether they can remain anonymous is not just an implementation detail. It changes the conditions under which people use the web.

So we started with a narrower question: what trade-offs are we actually accepting? From there, we worked backwards from harms to threats, and from threats to the properties the system should protect.

Starting from harms

In the EIC workshop, we asked participants not to start with "who attacks what?" but with the possible damage to people, society, and the actors in the ecosystem.

That changes the exercise. The first question is not whether a signature verifies or whether a credential can be presented. The first question is who might be excluded, profiled, forced to reveal more information than needed, denied access to a service, or exposed to censorship or surveillance.

We focused on age verification as one technical component within the broader set of architectural choices for age-based content restrictions. Looking at it from this direction is useful. If a person is excluded when they should not be, the cause may be a poorly written requirement, lack of access to a required credential provider, an incorrect classification, or a fallback that is documented but does not work in practice.

Surveillance is another example. The threat may come from how the age attribute is requested, who mediates the request, who issues the attribute, whether two relying parties can link the same user, or whether the same relying party can link different interactions from that user.

The workshop helped make those questions concrete. A harm became useful for threat modeling only when we could tie it to a flow, an actor, an assumption, or a responsibility boundary.

Translating harms into technical language

One of the most useful parts of the retrospective was seeing that people with similar backgrounds still built different models of the same problem.

That was not a failure of the exercise. It was the exercise.

In digital identity discussions, we often assume that we share the same mental model: user, wallet, browser, issuer, verifier. When people build the model by hand, differences become visible. Some participants placed the trust point in the wallet. Others focused on the relying party, the browser, the issuer, the regulator, or the fallback path.

Participants also noted that building in three dimensions helped explain concepts with fewer words. It made it easier to discuss where trust, enforcement, and responsibility sit in the architecture.

This matters because age verification architectures are not equivalent. They differ in where they place trust, where they enforce policy, what they reveal, and which party is left carrying the remaining threat.

Identifying threats is only the first step

The workshop was not intended to produce a complete threat model in 90 minutes. That would not have been credible. The goal was to show a practical way to start: make assumptions explicit, identify harms and derived socio-technical threats, discuss trade-offs, and feed that work back into the Threat Model for Decentralized Credentials.

After that first pass, the next question is the one that matters in threat modeling: what are we going to do about it?

For age verification, the answer cannot be a single check at the end of a flow. Some responses belong in the technical architecture: the role of the user agent, attribute minimization, origin binding, anti-correlation protections, integrity requirements, and where verification happens. Other responses sit outside the protocol: user comprehension, viable fallbacks, audits, dispute resolution, transparency, and regulatory incentives that do not reward the most invasive deployment.

The useful outcome of the workshop was not a list of generic concerns, but practical results we added in our threat model. In particular, the connection between harms and the points in the flow where threats arise, expressed as stories. If a threat comes from the interaction of architecture, economic incentives, user interface, and regulatory pressure, one technical mitigation will rarely be enough.

At the same time, technical analysis still matters. Without it, regulation can easily lock in fragile architectures and make them hard to change later.

That is why supporting W3C work on this topic matters. The theory of change is simple: W3C does not decide age policy, but it can make the technical choices visible before policy and market pressure turn them into infrastructure.

Age-based content restrictions will remain controversial because every architecture carries a model of the web. The EIC workshop confirmed one practical lesson: starting from harms helps people discuss architecture while keeping in view those who will bear the consequences.