Opening an app should not require knowing who I am. Age assurance is becoming less like a gate and more like infrastructure. Prompted by Jerry Fishenden’s latest thinking on citizen-held credentials, this article asks what comes after age verification: how identity, authentication, authorisation and attributes should relate, why civil identity is so often introduced unnecessarily, and whether the internet can establish what it needs to know without needing to know who we are.

Executive Summary

The age-gated internet is no longer principally about age gates. Over the past six months, age assurance has begun to move from a visible interaction between a user and an individual service into the surrounding technical environment. Platforms, operating systems, applications and policy engines increasingly have mechanisms through which age-related information can be established, transmitted and acted upon. The important architectural change is not simply that more services can ask how old somebody is. It is that verified attributes can become routine inputs into software behaviour, allowing different users to be placed into different permitted environments without encountering a conventional gate at all.

At the same time, the political and institutional landscape has changed. The British government cancelled its proposed national Digital ID programme, departments and responsibilities were reorganised, and the apparent trajectory towards a single government identity programme became considerably less straightforward. Yet many of the underlying requirements survived. Government services still require authentication, employers still need to establish entitlement to work, age-dependent regulation still requires reliable age assurance, and the infrastructure for digital verification continues to develop. A programme can disappear without removing the problems it was intended to solve.

Jerry Fishenden’s recent argument about government data and citizen-held verifiable credentials provides the immediate prompt for revisiting these questions. His model offers an attractive alternative to repeated data collection and interdepartmental data sharing: institutions issue trustworthy credentials and citizens present the necessary claims themselves. That can materially reduce unnecessary movement and disclosure of personal information. It does not, however, settle the prior question of whether a transaction needs identity at all.

That question is sharpened by Simon Freeman’s distinction between identification, authentication, authorisation and attribute verification. A service may need to know that somebody controls an authorised account without knowing their civil identity. It may need to establish that somebody is over eighteen without knowing their name or date of birth. It may need evidence of entitlement, jurisdiction, uniqueness or continuity without acquiring the underlying biographical information from which those propositions were established.

From that distinction this article develops the Principle of Minimum Identity: a digital transaction should establish no more about the human participant than is necessary to authorise that transaction. If identity is not required, do not identify. If age is required, prove age. If entitlement is required, prove entitlement. If continuity is required, authenticate the principal. Civil identity should enter the transaction only where civil identity itself is material to the decision being made.

Privacy-preserving verification does not resolve the architectural problem by itself. Selective disclosure and verifiable credentials can reduce the information revealed by each verification while simultaneously making verification cheaper, easier and more acceptable to deploy. This creates a paradox: less disclosure can enable more verification. A system can become substantially better at protecting information during each transaction while also making verified attributes a more pervasive condition of digital participation.

The article therefore introduces the Horkan model as a descriptive model of architectural selection rather than a preferred design. Organisations faced with a policy or business requirement tend towards mechanisms that are already available, trustworthy, auditable, deployable and defensible. That selection pressure can favour citizen-held credentials, minimum-identity architectures or identity-bound systems depending upon the surrounding infrastructure. The model does not predict which architecture must prevail; it asks which satisfactory mechanism institutions will find easiest to build, operate and defend.

The resulting question is no longer simply whether the internet will require identity. It is where identity belongs in the trust chain, which propositions services should legitimately establish, and which decisions can be made without identifying the person at all. Age assurance has exposed that boundary because age is one of the first attributes being operationalised at scale. What comes after the age gate depends upon whether verified civil identity becomes the default substrate for digital permission, or whether systems are deliberately engineered to establish only what each transaction actually needs to know.

Key Findings

• Cancelling the Digital ID programme did not cancel the requirement. Authentication, Right to Work, age assurance and entitlement checks remained. A programme and a trusted fact are different things.
• The gate has started to become configuration. Under-16 rules concern whether a specified service is offered. The 16–17 proposals concern how an admitted service behaves: hours, notifications, autoplay, recommendation. One controls entry. The other shapes the environment.
• The durable pattern is not the age check. It is a reusable decision: a principal, a trusted attribute, a policy, a permitted environment. Age is the first attribute being operationalised at scale. It need not be the last.
• An attribute is not an identity. AGE >= 18 = TRUE can be established without a name, a date of birth, or a civil-identity binding. Identity-mediated and attribute-mediated systems can present the same result and still be different trust models.
• Citizen-held credentials improve how a claim travels. They do not decide whether the claim should have been required, who writes the rule, or what happens if the holder refuses. Holding the credential is not defining the system.
• Identification, authentication, authorisation and attribute verification are different questions. Civil identity can answer several of them indirectly. That does not make it necessary to each of them.
• The Principle of Minimum Identity: establish no more about the human participant than the transaction requires. If continuity is required, authenticate the principal. If age is required, prove age. Introduce civil identity only where the person is material to the decision.
• Privacy-preserving verification creates a paradox. Less disclosure can make verification cheaper, easier and more acceptable, and therefore more common. A system can reveal less in each transaction while making verified attributes a more ordinary condition of participation.
• Institutions select the satisfactory mechanism that is easiest to deploy, operate, audit and defend. A minimum-identity architecture can be the right one and still lose. It wins only if it becomes the path of least resistance.
• The resulting design problem is not identity or no identity. It is where identity belongs, and whether the narrower answer has been made practical enough to build.

Contents

1. Introduction

This article was prompted, in part, by Jerry Fishenden’s recent piece, What went wrong with data in government — and how do we fix it?. Jerry looks back across several decades of attempts to make government data more coherent and interoperable, and at the remarkable capacity of government to rediscover problems it has already attempted to solve. His proposed direction is towards citizen-held digital credentials: rather than repeatedly moving information between institutional databases, trusted organisations issue credentials and the citizen presents the necessary proof.

That caught my attention partly because Jerry and I have been discussing variations of these problems for more than twenty years, but also because the landscape surrounding the argument has changed rather dramatically since I began writing this series in March.

The most conspicuous change is political. The national Digital ID programme proposed under the previous premiership has been cancelled. The new government has explicitly confirmed that the programme, including the proposed mandatory use of that Digital ID for Right to Work checks, will not proceed. Yet it has equally explicitly said that this does not end its broader work on digital identity. GOV.UK One Login and GOV.UK Wallet continue, the Office for Digital Identities and Attributes continues to support the market for digital verification services, and the statutory framework for those services remains in place.

That is a useful complication for the argument I have been making throughout The Age-Gated Internet. If the thesis were simply that the British government was constructing a national identity system and that everything else followed from it, the cancellation of the programme ought to have substantially broken the model.

It has not.

The direction of travel remains roughly similar, but for a more interesting reason. The underlying requirements have not disappeared with the programme intended to address some of them. Services still need authentication. Governments and employers still need trustworthy evidence of particular statuses and entitlements. Platforms operating under age-dependent rules still need mechanisms for distinguishing children from adults. Operating systems and application platforms are increasingly capable of carrying age-related signals. Regulation is reaching beyond simple access decisions towards determining which features, defaults and capabilities should be available to different categories of user.

This is not the continuation of a single government programme by other means. There does not need to be one. Different institutions, responding to different requirements, can continue to create demand for the same underlying capability: a trustworthy answer to a question about the person, principal or device on the other side of a transaction.

Jerry’s article therefore arrived at an opportune moment because it approaches the same territory from another direction. His concern is not primarily age assurance. It is the repeated failure of government to use information coherently and his belief that citizen-held verifiable credentials offer a better architecture than repeatedly copying and reconciling personal data between institutional systems. That is an attractive proposition, particularly when compared with architectures built around ever larger accumulations of centrally accessible personal information.

But it also exposes a question that has become increasingly difficult for me to ignore.

Before asking how we should prove things about ourselves, we should ask what the transaction actually needs to know.

That distinction takes us beyond the original age gate. It separates identity from attributes, identification from authentication, authentication from authorisation, and possession of a trustworthy credential from the question of whether that credential should have been required at all. It also brings together two rather different lines of thought from two people I have known since our Government Gateway days: Jerry Fishenden’s attempt to put trustworthy claims under greater citizen control, and Simon Freeman’s more fundamental challenge to the routine use of identity as the foundation of digital trust.

The first three articles in this series asked whether child-safety regulation, platform governance and identity infrastructure were beginning to produce an identity-mediated internet. Six months later, I think the question needs refining. The emerging architecture may be less straightforwardly identity-mediated than attribute-mediated: systems increasingly able to obtain trustworthy propositions about us and alter what we may see, do or access accordingly.

That could produce substantially better privacy than conventional identity systems. It could also make verification far more pervasive.

So the question for this fourth article is no longer simply: is the internet becoming age-gated?

It is: after the age gate, what exactly should the internet be entitled to know about us?

2. Catching Up: Six Months Is a Long Time on the Internet

Six months is not a long time in government. It is a surprisingly long time on the internet.

When I first wrote The Age-Gated Internet: Child Safety, Identity Infrastructure, and the Not So Quiet Re-Architecting of the Web in March 2026, much of what interested me was prospective. Age-assurance legislation was proliferating, identity services were appearing at different layers of the technology stack, operating-system vendors were developing mechanisms for carrying age-related signals, and governments were increasingly asking platforms to determine something about their users before allowing particular forms of interaction.

The argument was not that somebody had designed a new internet and was quietly implementing it. It was almost the opposite. Separate interventions, created for different reasons by different institutions, appeared capable of producing a common architectural consequence. Once services are required to know something reliable about a user before deciding what that user may do, some mechanism has to exist to establish that fact and communicate it to the systems making the decision.

The subsequent articles, The Age-Gated Internet Revisited: Identity, Trust and the Architecture of Control and The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex, pushed that argument further, particularly around attribution, liability, anonymity and institutional convergence. They also placed limits around it. If age assurance remained narrowly confined to age-restricted services, if anonymous participation remained the ordinary condition of the web, if privacy-preserving proofs displaced persistent identity, or if governments and platforms moved away from identity-mediated enforcement, then the model would need to change.

So rather than repeat the argument, it is worth asking a simpler question.

What actually happened?

2.1 The Institutions Moved

The British political landscape changed substantially during the summer. Andy Burnham became Prime Minister on 20 July 2026. Within days, the machinery of government responsible for technology policy was reorganised.

The Department for Science, Innovation and Technology (DSIT), itself only created in 2023, ceased to exist as a standalone department. Its responsibilities were redistributed across government. AI strategy, the AI Security Institute, public-sector AI adoption and the new Prime Minister’s AI Taskforce moved towards the Cabinet Office and the centre of government. Digital identity policy, Government Digital Service, online safety and other digital responsibilities moved into an enlarged Department for Digital, Culture, Media and Sport (DDCMS). Science and innovation functions moved into the Department for Business, Innovation, Science and Trade (DBIST).

This is useful evidence, although perhaps not for the reason one might initially think. A recurring temptation in debates about digital identity and online regulation is to imagine government as a single persistent actor: “the government” decides something, builds something and deploys something. Real government rarely behaves like that. Departments are created and abolished, ministers change, responsibilities migrate, and programmes are renamed, merged, cancelled or inherited by organisations that did not exist when the original policy was conceived.

The British digital identity programme provides an unusually immediate example. One of Burnham’s first announcements as Prime Minister was the cancellation of the previous government’s Digital ID programme, with the government explicitly saying that money allocated to it would instead contribute towards reducing household electricity costs. Taken literally, that sounds like a fairly decisive counterexample to the trajectory I have been describing: the government proposed a national digital identity programme, a new Prime Minister arrived, and the programme was cancelled.

Except that the wider problem does not disappear with the programme. Government services still need authentication. Employers still need mechanisms for establishing Right to Work. Regulated services still need age assurance. Platforms still need to distinguish children from adults if they are to comply with age-dependent rules. Government still has One Login, digital services, identity standards and existing verification mechanisms. Private-sector identity providers do not disappear because a Whitehall programme has been cancelled.

The distinction between a digital identity programme and the requirement to establish trusted facts about people digitally therefore becomes rather important. One can disappear while the other continues. That is less tidy than a story about inexorable government identity policy, but considerably more interesting.

2.2 Age Assurance Became Operational

The strongest evidence of continuity comes from age assurance itself. Ofcom’s Use of Age Assurance Report 2026, published in July, examined evidence from the first six months of the Online Safety Act’s child-protection duties. It found age checks being deployed across pornography, social media and online dating at what the regulator described as unprecedented scale.

Ofcom was appropriately cautious about what could be concluded from the early data. Its report was not a declaration that age assurance had solved online child safety, and it identified weaknesses in implementation and effectiveness. Some services still lacked effective measures; some methods did not meet the required standard; providers remained responsible for ensuring that systems described as age assurance were actually effective.

That distinction matters. Deployment is not effectiveness, effectiveness is not proportionality, and none of those things establishes what the long-term architecture will look like. But the status of the technology has nevertheless changed.

The question in March was partly whether age assurance would move beyond specialist implementations and become a routine compliance mechanism. By July, Ofcom was reporting on its operation across several categories of mainstream online service.

The experiment had moved into production.

2.3 The Gate Expanded Into The Environment

The more revealing development came from the scope of the rules being proposed. In June, the government announced that social-media companies would no longer be permitted to offer specified services to children under 16, with regulations intended to come into force in spring 2027. The July government response to its Growing Up in the Online World consultation then described a different set of controls for 16- and 17-year-olds.

Those users would still be permitted to use social media, but the environment presented to them would be altered. The proposals included default overnight restrictions between midnight and 6am, muted push notifications overnight, autoplay disabled by default and personalised recommender feeds switched off by default.

That is a more interesting development than another website acquiring an age-verification screen. A conventional age gate answers a binary question:

May this user enter?

These proposals require a system to answer another:

How should this service behave for this user?

The distinction is easy to overlook because both begin with age, but architecturally they do different things. One controls entry; the other uses an established characteristic of the user as an input into the configuration of the service. The person does not merely pass or fail a test. The environment changes around them.

2.4 Then It Reached The Device

In September, the boundary moved again. The government announced that it was preparing legislation intended to require technology companies to prevent under-18s from taking, viewing or sending nude images, including through device cameras and third-party applications. The proposal envisages protections operating on devices and platforms, with adults able to establish that the restrictions should not apply to them through age assurance.

The proposal is not the same thing as deployed technology. How it would operate in practice, what technical mechanisms would satisfy the requirement, how reliably they would distinguish relevant material, how exceptions would work and what privacy consequences would follow are all questions that remain open. But the location of the proposed control is notable.

The regulatory discussion has travelled from content, to the service, to the user environment, and now potentially to device capability.

The gate is moving away from the gate.

A child-safety rule that begins with access to particular online content can eventually become a requirement affecting what a camera, operating system or application is permitted to do, depending upon an established characteristic of the person using it. This is precisely where simple descriptions such as “website age verification” become inadequate.

2.5 What Changed, And What Did Not

There is no clean line through the events of the last six months, and that is probably the point. A national Digital ID programme was cancelled, the department responsible for much of digital policy was dismantled, AI policy was pulled towards the centre of government, and digital and online-safety responsibilities were redistributed. At the same time, age assurance continued to be deployed, the proposed under-16 social-media regime increased the number of circumstances in which reliable age determination would be required, proposals for 16- and 17-year-olds shifted the problem from access towards configuration, and government proposals reached further down the technical stack towards devices themselves.

This is not evidence of a single programme unfolding according to plan. It is almost evidence of the opposite. Policies can change while technical requirements survive them, departments can disappear while functions migrate elsewhere, and one identity programme can be cancelled while entirely separate regulatory decisions increase the number of situations in which somebody’s age, status or entitlement must be established reliably.

That makes the situation considerably harder to describe using the normal language of programmes and policies. The common factor is increasingly the decision being made before interaction occurs: can this person enter, which functions should be available, which defaults should apply, and can this device perform this operation?

The more questions of that kind a digital system is required to answer, the more useful a reliable signal about the person becomes. And that takes us beyond the age gate itself.

3. After The Age Gate

The obvious image of an age-gated internet is a gate. You arrive at a website, something interrupts you, you prove your age, and the site lets you through. It is familiar because it reproduces a physical-world interaction: somebody checks that a condition has been satisfied before allowing access.

But that may be a transitional experience rather than the eventual one. If an operating system, wallet, application store, identity provider or some other trusted component can already provide an acceptable assertion about age, there is little technical reason for every service to repeat the ceremony. The user may never encounter a gate, but the decision still happens. That difference matters.

3.1 From Verification To Configuration

Consider the proposed protections for 16- and 17-year-olds. A service first needs sufficient confidence that a user falls into that category. Having established it, the service can apply several policies: at midnight, access changes; notifications stop; autoplay behaves differently; personalised recommendation changes. There need not be a separate verification event for each decision. The same underlying attribute can inform all of them.

In abstract terms, the interaction starts to look something like:

principal + attribute + policy → permitted environment

The principal need not necessarily be a civil identity. It might be an account, device, credential holder or some other entity that the system can recognise with sufficient continuity. The attribute might be equally narrow:

age >= 18

or:

age = 16–17

The policy engine does not inherently need to know a name. It needs enough confidence in the proposition to make the required decision. That is a considerably more interesting architecture than repeatedly uploading a passport to websites, and it is also where terminology starts to matter.

3.2 Identity Is Not The Same Thing As An Attribute

The earlier articles used the term identity-mediated internet because identity systems appeared to be emerging as the means through which reliable information about users could be established and transmitted. The Age-Gated Internet: Child Safety, Identity Infrastructure, and the Not So Quiet Re-Architecting of the Web specifically identified age as a potential first widely deployed verified attribute rather than assuming that every interaction would require disclosure of a person’s full identity.

That distinction now deserves to be made sharper. An identity can contain attributes, but an attribute does not necessarily reveal an identity. A service wanting to determine whether I am over 18 does not inherently need to know my date of birth, and it certainly does not inherently need to know my name. It needs an answer to a proposition:

AGE >= 18 = TRUE

Similarly, a service restricted by jurisdiction may need UK RESIDENT = TRUE; an employer might need RIGHT TO WORK = TRUE; and a professional service might need REGISTERED PROFESSIONAL = TRUE. None of those propositions necessarily answers:

Who is this person?

That opens two very different architectural possibilities. In one, the system establishes my identity and derives the required attribute from it. In the other, it establishes the required attribute without disclosing my identity. The result presented to the relying service may look identical. The underlying trust model is not.

3.3 The Attribute-Mediated Web

This suggests that attribute-mediated may ultimately be a more useful description of the emerging system than identity-mediated. Not because identity has ceased to matter; quite the opposite. Somebody or something has to establish why a claim should be trusted. Credentials need issuers, issuers need evidence, devices need keys, and services need mechanisms for determining which assertions they will accept.

But the transaction visible to the service can potentially be reduced to the minimum fact required for the decision. That possibility matters because otherwise two substantially different futures get bundled together under the label “digital identity”.

One future looks like this:

identity → disclose information → establish attribute → authorise

Another could look like:

trusted proof of attribute → authorise

The second may still depend upon identity somewhere upstream. It may also be possible, in some circumstances, to avoid civil identity altogether. Those distinctions will matter later. For the moment, the simpler observation is that age assurance introduces a general computational pattern: establish something about the participant, then make access or behaviour conditional upon it. Once that pattern exists, age is only one possible input.

3.4 From Personalisation To Permission

Platforms have been classifying people for years. They infer interests, purchasing intent, location, likely age, relationships, political interests, viewing habits and countless other characteristics from behaviour. That classification has primarily been used for personalisation, advertising, recommendation and risk management.

Verified attributes introduce a different category of input. An inferred age might be useful for deciding which advert somebody is likely to click; it is a different matter to use that inference as the basis for denying access to a regulated service. The more consequential the decision, the greater the pressure for the underlying assertion to be dependable.

This creates an interesting shift from personalisation towards permission. The platform web asks, What is this person likely to want? An attribute-mediated system can additionally ask, What is this principal permitted to do? Those questions can coexist, and indeed they almost certainly will.

A service might personalise content behaviourally while simultaneously using verified age to determine which recommendation mechanisms are legally available. Jurisdiction might determine one set of rules, age another, subscription status another and parental consent another. The resulting environment is assembled from several inputs rather than opened by a single gate. Conceptually:

principal + verified attributes + jurisdiction + regulation + platform policy = available environment

The internet already contains countless examples of conditional access, so none of this should be mistaken for a claim that permission is new. What changes is the availability of portable, trusted assertions about the participant as routine inputs into those decisions.

3.5 The Less Visible It Becomes, The More Ordinary It Becomes

There is an odd usability consequence. The clumsiest version of the age-gated internet may also be the most obvious: photograph your driving licence, upload a passport, take a selfie, enter a date of birth, or wait while a third party performs an age estimate. People understandably experience those processes as identity checks because the act of verification interrupts whatever they were trying to do.

Integration can remove much of that friction. Imagine instead that an application requests proof that its user is over 18 and a trusted component on the device can satisfy the request. The application receives the result it needs, while the user presses a button, uses a biometric locally to unlock a credential, or perhaps does nothing at all because an appropriate permission has previously been granted.

From the user’s perspective, the age gate has disappeared. From the system’s perspective, verification has become more deeply embedded. That produces a counter-intuitive possibility:

the more pervasive verification becomes, the less often people may experience themselves as being verified.

This matters because public debate tends to concentrate on visible friction. People object to uploading passports, selfies and intrusive forms. A well-designed verification system could remove most of those annoyances while leaving the underlying decision structure intact, and potentially improve privacy at the same time. If a service currently receives my date of birth but a future system receives only OVER_18 = TRUE, it has learned less about me. That is plainly better from a data-minimisation perspective.

But another question remains: how many services should be asking the question? Reducing the information disclosed in each transaction does not tell us how many transactions should require verified attributes in the first place. Those are separate design problems.

3.6 A Reusable Decision Mechanism

This is where the architectural consequences begin to extend beyond age. Once software has a standard mechanism for requesting a trusted assertion and receiving a machine-readable answer, adding another policy decision may no longer require constructing another complete verification system. The pattern is reusable: a service asks a question, an accepted authority, credential or cryptographic mechanism supplies an answer, and the service applies a rule.

That rule might concern age, jurisdiction, entitlement or professional status. Eventually, in an internet increasingly populated by synthetic actors, it might concern whether the participant is a human being at all.

Technical capability does not imply inevitable adoption. The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex was explicit about this. If privacy-preserving attribute verification becomes dominant, or if identity remains narrowly constrained rather than becoming a general trust layer, the consequences are materially different from those of a system built around persistent identification and correlation.

But reusable capabilities change what is economically and operationally possible. A requirement that once appeared prohibitively expensive can become an API call. That is why the post-age-gated internet may not actually contain very many visible age gates. The gate is the crude implementation; the durable component is the decision:

What must be true about this participant before this system allows this action?

Once we formulate the problem that way, an awkward question begins to emerge: what exactly does the system need to know about us to answer it?

4. From Age Verification To Attribute Verification

By the end of the previous chapter, the age gate had almost disappeared. That is not just a change in presentation. It changes the economics of what comes next.

If every regulated service has to establish age independently, verification remains an awkward, relatively expensive intervention attached to particular transactions. Once a service can obtain a trustworthy assertion from infrastructure that already exists, the calculation changes. The difficult part is no longer necessarily establishing the fact. It is deciding whether the service is entitled, or required, to ask for it.

We have already seen the underlying pattern: establish something about the participant, apply a policy, configure the resulting environment. The next question is what happens when the mechanism used to establish that first fact is reusable.

4.1 The First Question Is The Expensive One

There is nothing technically magical about age. It has become prominent because governments have created strong reasons for online services to establish it. Child-safety regulation supplies the immediate requirement, platforms need a means of satisfying that requirement, and technology companies have incentives to make the resulting process less intrusive and less repetitive.

But once a system can convey a trustworthy claim about one characteristic of a user, the underlying machinery is no longer intrinsically concerned with birthdays. It is concerned with claims. That distinction matters because building the machinery is expensive. Issuers have to be trusted, credentials or assertions have to be represented somehow, software needs to know how to request them, and relying services need to know which sources they will accept. Fraud, revocation, expiry, recovery and compromise have to be handled. Different jurisdictions impose different requirements. Users need some means of understanding what is being requested and, where they have a choice, whether they want to provide it.

Age creates a reason to solve those problems. Once solved, at least some of the solution can be reused. This does not mean that an age-assurance provider automatically becomes a universal identity provider, or that a credential proving adulthood can somehow be repurposed to prove professional status. The evidence, issuer and level of assurance appropriate to one claim may be wholly inappropriate to another.

The reusable component is the pattern: a service requests a claim, something trusted establishes it, and the service receives enough information to make a decision. That is a much more general capability than an age gate.

4.2 Reuse Changes The Threshold

This is where the economics become more interesting than the technology. Suppose establishing a particular characteristic of a user requires every service to invent its own process, contract with specialist providers, design a user journey, manage sensitive evidence and maintain the whole arrangement indefinitely. There needs to be a fairly compelling reason to do it.

Now suppose the same service can request an assertion through infrastructure already present on the device or available through a standard protocol. The policy question may be unchanged, but the implementation cost is not.

That lower threshold matters because many forms of technological expansion happen this way. A capability originally justified by one use becomes available to other uses because the expensive part has already been built. We do not normally describe that as mission creep when discussing databases, payment systems, cloud platforms or communications protocols. We call it reuse. Identity and attribute systems deserve the same analytical treatment.

If a government, regulator or business can obtain a trustworthy answer to an additional question without constructing another verification system from scratch, proposals that previously looked impractical become easier to contemplate. Some will be sensible. Some may be disproportionate. Some will fail. Others will never progress beyond consultation documents or product roadmaps. The architecture does not determine which policies will be adopted; it changes the cost of adopting them.

That is a subtler mechanism than the familiar slippery-slope argument. No regulator needs to sit down in 2026 and decide that an age-assurance system will eventually be used to establish residency, professional status or anything else. Those later requirements can emerge independently. When they do, the existence of reusable verification machinery becomes part of the environment in which the new decision is made.

The capability precedes the justification for its next use.

4.3 From One Attribute To Many

We should be careful here, because it is easy to turn a discussion of capability into a prediction of inevitability. There is no evidence that every conceivable human characteristic is about to become a machine-readable credential, and no technical reason why it should.

But there are already plenty of circumstances in which digital systems need to establish facts rather than complete identities. Age is one. Residency can be another. Entitlement to work is another. Professional accreditation, student status, possession of a licence, organisational membership and eligibility for a particular service can all matter in particular contexts.

The post-LLM internet adds another class of problem. As the previous article explored, synthetic participation makes questions of provenance, reputation and proof-of-personhood more valuable without making civil identity desirable in every interaction. The fact that somebody is a unique human participant may eventually matter in places where their name does not. That possibility remains technically and institutionally unresolved, but it illustrates the distinction rather well.

These are not equivalent attributes. They need not share issuers or have the same assurance requirements, and they certainly do not need to be collected into a universal dossier. What they can share is an architecture in which a service asks for a trustworthy assertion and receives a result it can use.

That is the step from age verification to attribute verification. Age supplies the initial question; the machinery makes other questions cheaper to ask.

4.4 The Constraint Matters As Much As The Capability

There is another side to this. Reusable systems do not only make expansion easier; they can also make restraint technically enforceable.

A poorly designed identity system might disclose a name, date of birth and persistent identifier merely to establish that somebody is an adult. A better system can return a bounded age range or a threshold result. A still more privacy-preserving system might be designed so that presentations made in different contexts cannot easily be correlated. Those distinctions were already present in the earlier articles, and they remain central. The future described here is not one inevitable architecture.

What changes at this stage of the argument is the location of the constraint. If attribute verification becomes ordinary, then data minimisation cannot depend solely upon the goodwill of each website requesting information. It has to be reflected in the machinery that mediates the request.

What may the service ask? What does it receive? Can separate requests be correlated? Does the service receive a persistent identifier alongside the attribute? Who decides which issuers are trustworthy? Can the same credential be used across unrelated contexts? Can a user refuse, and what happens when refusal means the service cannot legally admit them?

Those questions cannot be answered by saying that the system uses “digital identity”, nor can they be answered merely by saying that it uses privacy-preserving credentials. They are properties of the architecture and its governance.

There is therefore a possible future in which the internet verifies considerably more facts about its users while individual services receive considerably less personal information about them. That sounds contradictory only if verification and identification are treated as the same thing. They are not. It is also possible for such a system to become more restrictive while becoming more private: a service might learn almost nothing about me while still requiring me to establish a particular attribute before it will deal with me.

That tension will matter later. For now, the point is narrower. Once the machinery for trustworthy attributes becomes reusable, the relevant boundary is no longer simply between identified and anonymous users. It is between interactions that require a verified claim and interactions that do not. The practical importance of that distinction increases dramatically when the mechanism for supplying the claim moves away from individual websites and into the platforms beneath them.

5. From Websites To Operating Systems

The most visible form of online age verification is probably also the least likely to scale gracefully. A website interrupts the user, a verification process begins, some evidence is supplied or an estimation is performed, the result is returned, and the user continues. Repeat that across thousands of services and the weaknesses become obvious.

The problem is not merely inconvenience. Repetition creates additional handling of sensitive information, inconsistent user experiences, duplicated integration work and a larger collection of organisations involved in verification. Every service has to decide what it trusts, every provider has to persuade relying services that its result is sufficient, and every user has to work out whether the request in front of them is legitimate.

The web can operate like that. The more interesting question is whether it will need to.

5.1 The Operating System Already Sits In The Middle

Apple’s current age-assurance architecture provides a useful example because it does not require an application to determine the user’s exact age itself. Its Declared Age Range API allows an application to request an age range using thresholds such as 13, 16 or 18. The operating system can return the range into which the user falls rather than an exact date of birth. Apple also provides information about how the age declaration was established, including, in supported circumstances, whether it was self-declared, guardian-declared or checked using another method such as a payment method or government identification. In regulated regions, the ranges returned can reflect the applicable legal requirements rather than merely the thresholds selected by the developer.

The details matter less here than the placement: the application asks the operating system. That is a different topology from every application independently establishing age.

Apple still places responsibility on developers for complying with the laws applicable to their applications, and the API does not magically determine whether a particular service is lawful. Nor does an age range necessarily represent verified civil identity. Apple explicitly distinguishes different declaration methods and levels of assurance. But the application no longer has to begin with the question, “How do I discover this person’s age?” It can begin with, “What age-related information can the platform provide?”

Google is developing a comparable pattern through the Play Age Signals API. The current Android documentation describes an application requesting access to age signals from Google Play. Depending upon the user, jurisdiction and sharing status, the application may receive signals, receive nothing, or be told that verification is required. In jurisdictions where applicable law requires age sharing, Google Play can make verified or supervised status available through that mechanism.

Apple and Google have made different implementation choices, and both systems continue to evolve. What they demonstrate together is more interesting than the product details: age assurance is becoming something an application can ask the platform about.

5.2 That Changes Who Does What

Moving a function down the stack does not eliminate it; it redistributes responsibility. The website or application can remain responsible for deciding what age restrictions apply, while the operating system, app marketplace, wallet or another trusted component can provide information relevant to that decision. An external verifier may still sit behind the process. A parent or guardian may be involved for a child. Government-issued evidence may be used in some circumstances and not others.

The system becomes a chain of assertions and decisions rather than a single verification event. One component establishes an attribute, another decides whether it trusts the source, another applies a regulatory rule, another configures the user experience, and another may provide the evidence from which the original assertion was derived. The person using the service sees the result of those relationships, but not necessarily the relationships themselves.

This is already visible in Apple’s model. The application can request age gates; the operating system mediates the request; the returned information can include an age range and information about its declaration; regional regulation can affect what must be shared; and the developer remains responsible for applying the result appropriately. That is a long way from uploading a passport to a website, and it is also a more plausible basis for scale.

5.3 Regulation Can Travel Down The Stack

There is a second consequence. Once the platform knows something about the regulatory environment, it can mediate not only an attribute but aspects of the obligation surrounding it.

Apple’s documentation now allows applications to determine whether age-related regulatory features apply to the current user and region. Its Declared Age Range regulatory framework can indicate circumstances in which an age range must be shared, while Apple’s broader Age Assurance framework covers additional requirements including acknowledgement and parental consent. Google’s documentation similarly distinguishes between regions where age-signal sharing is based upon user or parental choice and jurisdictions where age verification and sharing are mandatory.

The operating system or application marketplace is therefore no longer merely transporting a piece of information. It has some awareness of the regulatory context in which that information is being requested. That deserves careful wording: it does not mean that Apple or Google has become the regulator, that applications can hand their legal obligations to the operating system, or that every country will adopt the same rules. Quite the opposite. The mechanisms exist partly because rules differ.

What it does mean is that jurisdiction can increasingly affect the behaviour of the technical interface through which age information is supplied. The legal rule starts to acquire an executable edge. A developer does not merely read legislation and redesign an application; software can discover that particular age-related requirements apply in a particular context and respond accordingly. This is where the movement down the stack becomes more consequential than convenience.

5.4 Fragmented Rules, Common Machinery

At first sight, national and regional age-assurance laws appear to fragment the internet. A user in one jurisdiction may face requirements that do not apply in another. Age thresholds differ, definitions of a child differ, requirements for parental consent differ, and the legal responsibilities imposed upon application stores, developers and service providers differ.

The obvious technical response to that fragmentation is not necessarily to build an entirely different operating system for every jurisdiction. It is to build common machinery capable of expressing the differences. Apple’s API provides a concrete example: an application can specify age thresholds, but the system may return ranges determined by local regulatory requirements instead. Google similarly conditions aspects of its age-signals flow on whether mandatory age sharing applies in the user’s jurisdiction.

So regulation can fragment geographically while implementation converges technically. At the policy level there may be many regimes; at the platform level there may be a much smaller number of mechanisms capable of representing them. The result is not one global age policy. It is a common technical layer capable of enforcing or supporting multiple policies.

This is how heterogeneous regulation can still produce architectural concentration.

5.5 The Device Becomes A Policy Boundary

The September proposals discussed in Chapter 1 make the direction of travel more visible. If regulation concerns what a camera may capture, what an application may transmit, what a child may view, or which features should be enabled for a particular age group, then the website is no longer always the most useful place to make the decision. Some decisions can be made more consistently closer to the device.

That does not mean they should be. Moving control down the stack can improve privacy by reducing repeated disclosure, improve consistency, make circumvention harder and simplify compliance for developers. It can also concentrate consequential decisions in a very small number of operating systems, app marketplaces and credential infrastructures. Both things can be true at once.

This is one reason the usual argument between “privacy” and “safety” is too crude for what is emerging. An operating-system age signal might disclose substantially less information than uploading identification to dozens of websites while simultaneously making age-conditioned access far easier to implement across thousands of applications. The privacy of the individual verification can improve at exactly the same time as the reach of verification expands.

That is not a contradiction. It is an architectural trade-off.

5.6 Verification Without Ceremony

There is a final consequence of moving the function down the stack: it becomes less visible. The previous chapter described the possibility that the more deeply verification is integrated, the less frequently users will experience themselves as being verified. Operating-system integration is how that possibility starts to become practical.

The interaction no longer needs to resemble an identity check. An application requests an age range, the platform supplies one, the application configures itself, and the user encounters the resulting environment. There may still be moments when evidence has to be supplied, consent granted or a credential unlocked, but those events can happen somewhere else and at another time. The service consuming the assertion need not reproduce the original verification process.

This changes the feel of the system. The old age gate announces itself; the new one may simply be a branch in the software.

Once age-conditioned behaviour can be expressed as an ordinary platform capability, the next architectural question is no longer whether every website will acquire an identity check. It is what happens when applications, operating systems and services increasingly assume that trusted attributes are simply there to be asked for.

6. From One Internet To Multiple Environments

For most of its history, geographical fragmentation of the internet has been relatively easy to see. A government blocks a service, a platform withdraws from a country, copyright law makes a video unavailable in one territory, a streaming catalogue changes when somebody crosses a border, or a website displays a cookie banner to European visitors that somebody elsewhere never sees. The underlying service may be global, but access to it is not.

What the architecture described so far makes possible is a more granular form of fragmentation. The boundary need not sit around a country, a website or even an application; it can run through the service itself. Two people can open the same application, in the same city, at the same time, and legitimately receive different capabilities because the system has established different things about them.

We have already seen the beginnings of that with age. The proposed protections for 16- and 17-year-olds discussed earlier are not simply restrictions on whether a service can be entered. They alter how the service behaves once the user is inside it. Once that model is combined with the platform-level mechanisms examined in the previous chapter, the internet begins to acquire another dimension: it becomes conditional.

6.1 The Service Is No Longer A Single Thing

We tend to talk about an online service as though it were a reasonably stable object. There is Instagram, YouTube, TikTok, a search engine, a game, a messaging application or an online marketplace. Of course, that has never been completely true. Platforms already vary enormously between users. Recommendation systems produce different feeds, advertising systems choose different adverts, experiments place users into different interface variants, subscription tiers expose different functionality, geographic licensing affects available content, and parental controls alter behaviour.

The difference is what determines the variation. Most existing personalisation is commercial or behavioural. The service changes because the platform predicts what will hold somebody’s attention, because the user has paid for something, because a feature is being tested, or because content rights differ by territory.

Attribute-mediated regulation introduces another source of variation: the system changes because the user falls into a category to which a rule applies. That category might initially be age. The previous chapter showed how operating systems and application platforms can mediate age-related information while taking account of jurisdiction-specific requirements.

Combine those inputs and there is no longer necessarily one regulatory version of a service. There are environments assembled at runtime. The same application can expose one set of functions to an adult in Britain, another to a 17-year-old in Britain, another to a child using a supervised account, and potentially another to somebody subject to a different regulatory regime elsewhere. That does not require four separate applications; it requires a sufficiently expressive policy layer.

6.2 Geography Is Only One Input

This produces an apparently contradictory development. The internet can become more geographically fragmented at the same time as its underlying technical machinery becomes more standardised. Chapter 4 showed how Apple and Google can provide common mechanisms while accommodating different regulatory requirements. The policy varies by jurisdiction; the interface through which applications discover and respond to that policy can converge.

That pattern can extend beyond age. The service may know, or be able to establish, the jurisdiction in which a transaction occurs. It may receive an age range, know whether an account is supervised, have its own rules about what particular classes of user may do, while the regulator may impose another set of constraints. None of those inputs alone defines the experience. Their combination does.

The conceptual model introduced earlier therefore becomes more useful when treated not as a description of identity but as a description of environment selection:

principal + verified attributes + jurisdiction + policy → permitted environment

The interesting word is environment. A permission system does not have to respond with ALLOW or DENY; it can respond by changing what exists. A feature might disappear, a recommender operate differently, direct messaging become unavailable, search results be filtered differently, purchasing be disabled, a camera function behave differently, or notifications stop during particular hours.

The precise examples will depend upon the service and the law. The architectural point does not. Permission can be expressed through the shape of the environment rather than through a locked door.

6.3 The Boundary Moves Inside The Application

This changes the meaning of internet censorship in ways that deserve some care. The conventional model is comparatively legible. A state blocks a website, orders material removed, or requires a platform to make particular content unavailable. The restriction concerns an identifiable resource.

A dynamically configured environment can be much less binary. The service remains available, the user remains logged in, and most functionality may remain unchanged. Only particular capabilities, interactions or categories of content differ.

That can be entirely legitimate. We already accept that a child account should not necessarily have the same capabilities as an adult account, and few people would argue that every function offered by every digital service should be available to everybody regardless of circumstance. But the architectural form is worth noticing because it changes where the boundary sits.

The boundary is no longer necessarily between the user and the service; it can sit between the user and individual capabilities within the service. That makes regulation more granular while also making the resulting restrictions less visible as a coherent system. A person may simply encounter the environment that has been assembled for them without necessarily seeing the alternative environment that somebody else received.

6.4 One Application, Many Internets

There is a temptation to describe this as the “splinternet”, but that term usually refers to something larger and more geopolitical: national filtering regimes, incompatible regulatory blocs, sovereign infrastructure and the retreat from the idea of a single globally accessible network.

Something subtler is happening here. The network can remain interoperable, the application can remain global, the protocols can remain common, and the software binary can even be identical. What differs is the policy evaluation performed for the person using it.

This produces something closer to multiple overlapping internets implemented through the same infrastructure: not separate networks, but separate permitted environments. That distinction matters because technical convergence can conceal experiential divergence. Two users may appear to be using the same service because the icon, domain name and application are identical, yet the set of actions available to each can differ according to age, jurisdiction, account status and whatever other attributes the service is permitted or required to consider.

The web does not have to split physically in order to stop being experienced as a common space.

6.5 The Question Becomes Who Defines The Environment

Once a service is dynamically assembled in this way, governance becomes distributed across several layers. Legislation may establish the requirement, a regulator may interpret it, an operating system or app marketplace may expose the relevant signals, a credential provider may establish an attribute, the platform may translate the requirement into product rules, and the application finally enforces them.

That chain matters because “the platform decided” or “the government required” may both be incomplete descriptions of what happened. A government might require protection for a class of users without specifying the exact implementation. A platform may then choose a conservative implementation because regulatory penalties are asymmetric. An operating-system vendor may expose an API designed to satisfy several jurisdictions. Developers may adopt the API because doing so is easier than maintaining their own verification systems.

The resulting environment emerges from the interaction between law, platform architecture, risk management and implementation. That does not make responsibility unknowable; it makes attribution more demanding. It also means that changes can propagate in unexpected directions. A technical mechanism introduced to satisfy one jurisdiction can become available globally, a platform feature created for compliance can become the easiest way to implement an unrelated product rule, and a regulatory category can become a software category.

None of those outcomes is automatic. But once policy becomes something software can evaluate against trustworthy attributes, regulation stops being only a set of instructions addressed to institutions. Some of it becomes behaviour encoded into systems, and those systems can produce different internets for different people without ever creating different networks.

7. The Synthetic Internet Changes The Economics

There is another reason verified attributes may become more attractive, and it has relatively little to do with child safety: the internet is filling with machines that can behave increasingly like people.

That statement needs qualification. Bots are hardly new. Automated accounts, spam, fake reviews, click farms, scripted interactions and synthetic personas existed long before large language models. The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex examined the longer history of information operations and the institutional responses built around them. Generative AI changes the scale and quality of the problem.

Producing plausible language, images, voices and increasingly video has become cheap. Maintaining multiple synthetic personas has become easier. Generating responses that are contextually appropriate no longer requires a human operator to write each one. Software can participate in spaces designed around the assumption that coherent language is evidence of a person being present. For much of the history of the internet, that assumption was good enough. It no longer is.

7.1 Intelligence Has Become Cheap

The early web contained an accidental authentication mechanism: conversation was expensive. Writing a plausible response required somebody to read what had been said, understand enough of it to formulate an answer, and type that answer back. It was never proof of humanity, but the cost of sustained participation placed a practical limit on automation.

Large language models weaken that limit. A machine can now produce competent prose, respond to context, adopt a style, summarise an argument, maintain a conversational thread and generate variations at negligible marginal cost compared with human labour. That does not make machine-generated content indistinguishable from human content in every circumstance. Detection remains possible in some cases, models make characteristic errors, and provenance mechanisms can sometimes establish where material came from.

But the economic direction is clear enough. As I explored in Signal Under Conditions of Flow: The Architecture of Public Cognition After the Open Web, Synthetic cognition is becoming abundant. The scarcity moves elsewhere.

If generating apparently intelligent participation is cheap, then the valuable question increasingly becomes not Can this entity produce a plausible contribution? but What reason do I have to trust the entity producing it?

That is a different problem.

7.2 Authenticity Becomes Scarce

“Trust” is an overloaded word here. It can mean that a statement is true, that an account belongs to the person it claims to represent, that an image came from a particular camera, that a participant is human, that somebody has behaved consistently under the same pseudonym for ten years, or that a professional qualification has been verified. Those are different propositions and they require different mechanisms.

The mistake would be to collapse all of them into identity. A named human can lie, an anonymous human can tell the truth, a pseudonymous account can develop an excellent reputation, a machine can publish accurate information, and a photograph can be authentic while the interpretation attached to it is false. Identity does not solve epistemology.

But synthetic media and synthetic participation do increase the value of provenance, continuity and reputation. In some contexts they also increase the value of being able to establish that a participant is a human being, or that one human being is not masquerading as ten thousand.

The third article explored this as one of the forces likely to increase demand for identity and provenance infrastructure. What becomes clearer when placed alongside age assurance is that the two pressures can converge on some of the same technical machinery even though they originate from very different problems. Child safety asks whether a participant belongs to a protected age category; the synthetic internet asks whether a participant, account or artefact is what it purports to be. Neither question inherently requires a passport. Both create demand for trustworthy assertions.

7.3 Proof Of Personhood Is Not Proof Of Identity

This distinction becomes especially important around “proof of personhood”. Suppose a discussion forum is overwhelmed by automated accounts. Its problem may not be that it does not know everybody’s legal name; its problem may be that creating another apparent participant costs almost nothing. Requiring civil identity would be one way to raise that cost, but it is not the only way.

The service might instead want to establish that each account corresponds to a distinct human participant without learning who that human is. That is a considerably harder technical problem than it sounds. Any system making such a claim has to decide what counts as one person, how duplicate enrolment is prevented, what happens when credentials are lost, how coercion or credential markets are handled, and whether the mechanism itself creates a persistent means of tracking people. Those problems are not resolved simply by attaching the word “privacy” to the design.

But the desired property remains distinct from identity:

UNIQUE HUMAN = TRUE

is not the same claim as:

THIS IS WAYNE HORKAN

That distinction is going to become increasingly useful. The economic pressure created by synthetic participation is towards some mechanism that makes trustworthy human participation scarce again. The architectural danger is assuming that the only available scarcity mechanism is civil identity.

7.4 Reputation Changes Too

There is a related effect on reputation. Online reputation has traditionally been attached to accounts, handles, domains, communities and platforms. Its strength comes partly from continuity. An account that has existed for years and accumulated a history of interactions is harder to reproduce than one created five minutes ago.

Generative AI complicates that model because producing the activity itself becomes cheaper. As I explored in All Noise and No Signal: The Future of Online Spaces, a synthetic account can post frequently, maintain stylistic consistency, interact with other synthetic accounts and produce the superficial signals of participation at machine speed. That does not make reputation systems useless; it changes what gives them weight.

History matters. Provenance matters. The cost of establishing the principal may matter. External attestations may matter. Relationships between credentials may matter. The internet therefore acquires another incentive to distinguish between content and provenance of content, and between behaviour and the entity responsible for that behaviour.

Again, identity is one possible answer. It is not synonymous with the problem.

7.5 The Collision Of Two Pressures

This is where the age-gating argument and the synthetic-internet argument begin to intersect. They start in different places: one begins with child protection, regulated access and age-dependent environments; the other with cheap synthetic participation, uncertain provenance and the declining evidential value of apparently human behaviour.

One asks, Is this participant old enough? The other may ask, Is this participant human, unique, continuous or reputable? Both benefit from infrastructure capable of carrying trustworthy assertions.

That creates a reinforcing economic effect. Age regulation can justify building mechanisms for verified attributes, while synthetic participation can create commercial demand for mechanisms establishing provenance, uniqueness and reputation. Government does not have to compel every use, platforms do not have to adopt every government identity system, and the technical systems need not even share a single provider. The pressures can still push in the same architectural direction: away from trusting what an entity says about itself, and towards assertions supplied or supported by something else.

This is where the question of who provides those assertions becomes unavoidable, because there is a very attractive answer. Rather than every government department, platform and service repeatedly collecting and reconciling information about people, issue trustworthy credentials once and allow people to present the necessary proof themselves.

That is the architecture Jerry Fishenden has been arguing for in What went wrong with data in government and how do we fix it?, and it deserves to be considered on its own terms.

8. Jerry Fishenden: The Optimistic Case

There is some personal history behind the next part of the argument. I have known Jerry Fishenden and Simon Freeman for more than twenty years. We worked together around the Government Gateway programme in the Cabinet Office, where Jerry and Simon carried considerably more responsibility for the programme than I did. My own work included security policy and aspects of the implementation, alongside my friend and colleague Dave Walker of Sun Microsystems.

That matters here because these are not positions I have encountered recently and recruited to opposite sides of an argument. They come from people whose thinking about identity, authentication and government systems I have known for a long time, and from a set of problems we were already wrestling with when large-scale digital identity infrastructure was considerably less mature than it is today.

Some of that intellectual history also runs through Kim Cameron, whose work on user-centric identity had a considerable influence on the identity community of the period and, in particular, on Jerry’s thinking. I have written about Cameron’s insistence upon user control, contextual identity and minimum disclosure in Remembering Kim Cameron: The Man Who Changed Identity. The lineage matters because Jerry’s current argument for citizen-held credentials is not simply a fashionable response to digital wallets. It belongs to a much longer attempt to put the individual back into the identity transaction rather than treating them as a record passed between institutional systems.

Jerry Fishenden starts from a problem that is both more mundane and more deeply embedded than the age-gating questions considered so far. Government is extraordinarily good at asking for the same information repeatedly. A department needs to establish something about a citizen; another department already knows it, perhaps several departments know it, yet the citizen is asked to enter the information again, upload another document, complete another form or consent to another exchange between systems.

Behind that apparently simple inconvenience sits decades of accumulated architecture. Jerry has documented much of that history. British governments have repeatedly attempted to make public-sector information systems work together more effectively: common standards, interoperability programmes, shared services, identity schemes, data-sharing initiatives, portals, federated identity and successive attempts at “digital transformation”. The names and technologies change, but the underlying problem has proved remarkably persistent.

His diagnosis is not that government lacks data; it has rather a lot of it. The problem is what government does with it.

8.1 The Citizen As The Integration Point

The conventional approach to joining up public services tends to begin with organisations. Department A needs to establish whether I satisfy some condition. Department B holds one piece of relevant information, Department C holds another, and Department D perhaps maintains the authoritative record. The engineering problem then becomes: how does A obtain what it needs from B, C and D?

That question produces an entire class of government technology. Data-sharing agreements have to be negotiated, interfaces built, matching rules developed to reconcile records, and legal bases for processing established. Data moves between organisations, copies proliferate, systems become dependent upon one another, and somebody has to maintain the whole arrangement as departments, legislation and technology change.

Jerry’s alternative changes the topology. Instead of making government organisations responsible for assembling a picture of the citizen from one another, the relevant organisations issue trustworthy credentials representing facts they are authoritative for. The citizen holds those credentials and, when another service needs to establish a fact, presents the necessary proof.

The model becomes something like:

issuer → credential → citizen → verifier

rather than:

department A → department B → department C → department D

That sounds like a modest rearrangement. It is not. The citizen has become the integration point.

Jerry describes this as an inversion of the existing model: government becomes an issuer of facts rather than a central checker; citizens can prove eligibility directly; organisations verify proofs rather than repeatedly acquiring and processing the underlying personal data. There is an obvious connection to the architecture developed in the previous chapters. A service does not necessarily need the underlying record. It needs a trustworthy answer.

8.2 From Moving Data To Proving Facts

Consider a deliberately simple example. Suppose a public service is available only to people who satisfy some residency condition. The conventional digital-government response may be to ask the applicant for an address and then attempt to establish whether it is valid. Perhaps the service asks for documentary evidence, queries another government system, or obtains data from several sources and reconciles the result.

In a credential model, an authoritative body could instead issue something capable of proving the relevant residency condition. The service does not need to acquire all the information from which that conclusion was derived; it needs the conclusion. The same pattern could apply to entitlement, qualification, licensing, employment status or other facts for which some recognised organisation is capable of making an authoritative assertion.

This is the same separation encountered earlier with age. The evidence used to establish a fact does not necessarily have to travel with the fact. A passport might help an issuer establish something about me, but that does not mean every subsequent service needs a copy of the passport. A government database might contain information used to determine my entitlement, but that does not mean every organisation checking that entitlement needs access to the database.

The distinction is between establishing a claim and presenting a claim. Verifiable credentials make that separation technically useful because the recipient can verify that the credential came from an accepted issuer and has not been altered. Depending upon the credential system and cryptographic mechanisms used, it may also be possible to disclose only the information required for the transaction rather than the complete contents of the credential.

This is why the model deserves more serious consideration than the phrase “digital identity” sometimes receives. It can reduce data movement rather than increase it.

8.3 Less Data Sharing Can Mean More Trust

For years, “joined-up government” has often implied joined-up data. That seems intuitive: if government departments are to provide coherent services, surely their systems need to exchange information about the people using them.

Jerry’s model challenges the assumption. Perhaps the systems do not need to know more about one another; perhaps they need better ways of trusting claims. That is a substantially different engineering problem.

If Department B can issue a cryptographically verifiable assertion that I satisfy condition X, Department A does not necessarily need direct access to B’s database, nor does it necessarily need to know the evidence B used to reach that conclusion. A dependency remains, but it has changed form: A trusts B to issue a particular class of credential correctly; it does not need B to expose its underlying records.

There are obvious attractions to that arrangement. Less information needs to move between organisations, fewer copies of sensitive data need to be created, citizens can avoid repeatedly supplying the same evidence, eligibility checking can become simpler, and services can potentially operate without constructing another central database containing information already held elsewhere.

Jerry has described this as moving away from systems that repeatedly “acquire, copy, store, and process” the same data and towards systems in which trusted facts can be presented by the citizen and verified where they are needed. That is not simply a usability improvement. It is an architectural argument about data minimisation.

8.4 The Wallet Changes The Relationship

A citizen-held wallet makes the model more tangible. The wallet need not be understood as a digital folder containing photographs of documents. The useful abstraction is closer to a mechanism for holding and presenting cryptographically protected credentials.

An issuer places a trustworthy claim into that environment; later, another service requests proof, the citizen presents it, and the verifier checks it. There are numerous implementation details hidden inside that sequence: credential formats, key management, issuer trust, revocation, recovery, device migration, selective disclosure, offline operation and the consequences of losing access to the wallet. Different systems will answer those questions differently.

The conceptual shift remains. The citizen participates directly in the flow of information rather than merely being the subject around whom institutional databases communicate. That is what gives Jerry’s use of citizen-centric some substance. It is not simply that a government application has a pleasant interface; the architecture attempts to move part of the information exchange towards the citizen.

Government says, in effect, Here is a trustworthy fact about you. The citizen can then say, I want to use that fact here.

That is a better starting point than constructing another centralised system in which every relying organisation acquires another copy of the person’s information. It may also be considerably better than forcing every website or application to perform its own identity verification.

8.5 The Strongest Version Of The Argument

It is worth stating Jerry’s case in its strongest form because otherwise the discussion becomes another sterile argument between “digital ID” and “privacy”. His proposal can potentially give us more verification with less disclosure. That sounds paradoxical only because identification and verification are so often treated as synonyms. They are not.

If I need to establish an entitlement, the service does not necessarily need the data from which that entitlement was calculated. If I need to prove a qualification, the service does not necessarily need access to the university’s student database. If I need to establish that I am an adult, the service does not necessarily need my date of birth.

A credential architecture can therefore support precisely the kind of attribute-mediated environment discussed earlier while avoiding some of the worst characteristics of centralised identity infrastructure. That possibility should not be dismissed simply because the credentials ultimately derive their authority from institutions. Trust has to originate somewhere: a university is authoritative about degrees it awards, a professional body may be authoritative about registration, and a government agency may be authoritative about a statutory entitlement.

The useful architectural question is how much of the information behind those assertions needs to travel when the assertion is used. Jerry’s answer is often: considerably less than we currently move around. That is persuasive.

It also creates a problem, because once the architecture becomes sufficiently convenient, private and reliable, the cost of asking people to prove things about themselves falls dramatically. That takes us back to the question raised in Chapter 3: the machinery makes questions cheaper to ask.

I should probably declare a bias here: I like Jerry, both personally and intellectually. He understands the machinery of government unusually well, including the reasons apparently sensible reforms repeatedly disappear into departmental boundaries, procurement structures, institutional incentives and administrative history. His instinct is generally constructive. Faced with a dysfunctional architecture, he tends to ask how it could be made to work better.

That optimism is one of the strengths of his argument, but it is also where I begin to part company with it. Credential-mediated architectures can move control towards the citizen and substantially reduce unnecessary disclosure, but they can also create an increasingly elaborate economy of issuers, holders, verifiers, wallets, trust frameworks, revocation mechanisms and credential exchanges. The machinery required to avoid moving the underlying data does not disappear; some of it is displaced into the machinery required to establish, carry and validate trustworthy claims.

Jerry sees considerable promise in that machinery. I see the promise too, but I am less confident that making credential exchange elegant necessarily makes the surrounding identity ecosystem simple, or that making verification privacy-preserving answers the prior question of how much verification we should be doing.

9. Citizen-Centric According To Whom?

There is a point at which I part company with Jerry’s terminology. Not necessarily with the technology, or even necessarily with the direction of travel, but with the word citizen-centric.

A credential held on my phone is not, by that fact alone, a citizen-centric system. It may be a citizen-held system, give me control over presentation, minimise the information disclosed to a relying service, and be considerably better for my privacy than a central database queried behind my back. All of those properties are valuable. None tells us who ultimately controls the system in which the credential operates.

Storage location is not governance.

9.1 Holding The Credential Is Not Defining The Rules

Return to the simple credential model:

issuer → credential → citizen → verifier

The citizen sits in the middle. Visually, that looks empowering. But look at the decisions that surround the transaction.

Who decides which credential exists? Who determines the evidence required to obtain it? Who decides which organisations may issue it, and which issuers a verifier is permitted or required to trust? Who defines its expiry conditions or can revoke it? Who decides which services may request it, what happens when the citizen refuses to present it, and whether an alternative route exists for somebody who cannot, or will not, use the credential system?

Those are governance questions. Possessing the credential does not answer them.

The state could define the credential, determine the evidence required to obtain it, regulate its issuers, determine the services for which it is acceptable, specify when it must be presented and establish the consequences of failing to do so. The resulting credential could still sit entirely on my phone, and I might even press the button that presents it.

Calling that interaction citizen-controlled would stretch the term beyond usefulness. The citizen controls the presentation event. The citizen does not necessarily control the architecture.

9.2 Presentation Control Is Not Architectural Control

This distinction becomes clearer if we separate several ideas that are too easily bundled together. A citizen-held credential describes where the credential resides. Citizen-controlled presentation describes who initiates or approves its disclosure. Selective disclosure describes how much information the presentation reveals. Citizen-centric provisioning describes whether services are designed around the needs and circumstances of the person using them rather than around departmental structures. Citizen-centric governance concerns something harder: the rights, constraints and distribution of power governing the system itself.

Those properties can coexist, but they do not automatically do so. A system can be excellent at selective disclosure while giving the citizen little practical choice about whether to participate. It can place credentials in a personal wallet while making possession of those credentials a precondition for ordinary activities. It can eliminate centralised data sharing while still enabling widespread verification. It can give the individual complete technical control over the act of presenting a credential while making refusal functionally equivalent to exclusion.

The difference matters because consent behaves strangely when access depends upon it. “Would you like to prove that you satisfy this condition?” means one thing when declining has no consequence. It means something rather different when the next sentence is: “Otherwise you cannot continue.”

Sometimes that is entirely appropriate. I cannot reasonably demand that a regulated financial institution ignore legal requirements because I would prefer not to establish facts it is obliged to know. But the existence of legitimate compulsory verification does not tell us where the boundary should be drawn. That is a governance decision.

9.3 The Right Not To Prove

A genuinely citizen-centric architecture would therefore need to be judged partly by what happens when the citizen does not present a credential. That is an uncomfortable test because most identity architecture is designed around successful verification.

• Can the user prove the required thing?
• Can the verifier trust the result?
• Can the credential be checked?
• Can fraud be prevented?

Those are necessary engineering questions. They are not sufficient. We also need to ask when verification is justified in the first place.

• Can a person remain unidentified where identification is unnecessary?
• Can they use a pseudonymous credential?
• Can a credential establish an attribute without exposing a persistent identifier?
• Can presentations to unrelated services be prevented from becoming a correlation mechanism?
• Can a service be used without persistent binding to civil identity where such binding serves no legitimate purpose?
• Is there an offline or alternative route for somebody without a compatible device?
• Can credential requirements introduced for one regulated purpose expand into unrelated transactions simply because the mechanism is available?
• Can a citizen stop using the system without effectively withdrawing from ordinary digital life?

These questions are not arguments against verifiable credentials. They are what determine what kind of credential ecosystem has been built.

9.4 Citizen-Centric Requires Rights, Not Just Wallets

The stronger version of citizen-centricity therefore has to contain more than technical possession. It requires constraints around the surrounding system.

Some of those constraints may be technical. Unlinkable presentations, selective disclosure and the absence of unnecessary persistent identifiers can make correlation more difficult by design. Others will have to be institutional: issuers and verifiers need rules governing what may be requested, retained and combined. Some will have to be legal, including circumstances in which demanding a particular credential is prohibited even though doing so is technically straightforward. And some concern basic service design: a person who loses a phone, lacks the necessary technology or cannot satisfy the preferred digital process cannot simply cease to exist as a citizen.

There is also a question of scope. A credential system can be highly privacy-preserving at the point of presentation while still making verified participation increasingly ordinary. That possibility matters, but it deserves separate treatment; I return to it in Chapter 14.

For present purposes, the more immediate point is about control. This is where the word centric earns its keep. A citizen-centric system is not one in which the citizen happens to occupy the middle box in an architecture diagram; it is one in which the architecture preserves meaningful agency for the citizen. That includes the ability to disclose less. It may include the ability to choose between mechanisms. And where the transaction does not legitimately require verification, it should include the possibility of not proving anything at all.

Jerry’s model therefore presents a useful counterpoint to the more centralised identity architectures discussed throughout this series. His approach shows how trustworthy claims can potentially be presented without repeatedly distributing the underlying personal data, and how the citizen can become the point through which those claims are carried between institutions. That is a better architecture for many of the problems he is trying to solve.

But it still begins with credentials. And a conversation with Simon Freeman pushed me towards an earlier question: before deciding how safely, privately or democratically we can prove things about ourselves, perhaps we should ask why the transaction needs to know them in the first place.

10. Simon Freeman: Why Are We Using Identity At All?

I have known Simon for just as long, and his intervention cuts in a different direction. Simon has an irritating habit, in the best possible sense, of stripping a complicated technical discussion back until the unnecessary assumption becomes impossible to ignore.

Simon is not a big swearer, and his objection to contemporary identity architecture is calmer than this, which is part of why it is difficult to dismiss. Expressed rather less politely than most standards documents would permit, it is: why the fuck are we giving away identity data when the transaction does not need to know who we are?

That question deserves some force because the information involved is not trivial. We routinely construct systems in which names, dates of birth, addresses, photographs, family relationships, government identifiers, biometric characteristics and other details of somebody’s life become part of establishing trust. Some of those attributes are difficult to change. Others cannot meaningfully be changed at all. Once disclosed, copied, correlated or compromised, they do not acquire the convenient reset button of a password or cryptographic key.

And yet the decision the application actually needs to make may be almost absurdly small by comparison.

• Are you over 18?
• Are you resident in this jurisdiction?
• Are you entitled to use this service?
• Are you the same principal who was authorised yesterday?

That is the part of Simon’s argument I find difficult to escape. If the decision is AGE >= 18 = TRUE, why does the application need my name? Why does it need my date of birth? Why should it acquire a document number, photograph or persistent civil-identity binding? Why should any of those things become part of another organisation’s data estate merely to establish a Boolean proposition?

Once the question is put that way, the architecture looks different. The problem is no longer how to make identity disclosure safer. It is why identity entered the transaction in the first place.

Jerry Fishenden’s model asks how we can prove things about ourselves without repeatedly distributing the underlying personal data. Simon Freeman asks an earlier question.

Why are we proving who we are in the first place?

That sounds like a privacy objection. It is more interesting than that. Simon’s argument is architectural. Modern digital systems have a tendency to reach for identity when the problem they actually need to solve is authentication, authorisation, continuity, uniqueness or the verification of a particular attribute. Those are related problems, but they are not the same problem.

We have become rather careless about the distinction. Once identity infrastructure is readily available, that carelessness becomes much easier to turn into software.

10.1 Four Questions That Keep Becoming One

There are four questions worth separating. This is not an entirely novel separation: the NIST SP 800-63-4 Digital Identity Guidelines distinguish identity proofing, authentication and federation as separate functions within digital identity systems. The distinction I want to make here is slightly broader because an application may also need to establish a particular attribute without establishing the person’s civil identity.

Identification asks:

Who is this?

Authentication asks:

Can this principal demonstrate that it controls the account, device, credential, key or session it claims to control?

Authorisation asks:

What is this authenticated principal permitted to do?

Attribute verification asks:

Does this principal satisfy some particular condition?

In everyday digital systems those questions are often collapsed into a single process called “logging in”, “verification” or “identity”. That is understandable from the user’s perspective. You enter something, prove something, and the application lets you continue. Architecturally, however, very different things may have happened.

Suppose I open an application that I have used hundreds of times before. The application may need to establish that I am the same account holder who used it yesterday: that is continuity. It may need to establish that whoever is attempting to use the account possesses a cryptographic key stored on my device: that is authentication. It may need to determine whether the authenticated account can access a particular function: that is authorisation. It may need to establish that the user is over 18: that is attribute verification.

None of those questions necessarily requires the application to establish that the human holding the device is Wayne Horkan. Yet identity can easily become the route through which all of them are solved. That is the problem Simon is pointing at.

10.2 When Did Authentication Come To Mean Identification?

Authentication requires a principal. It does not necessarily require a civil identity. A principal is simply the entity to which the system attaches permissions, state or continuity. It might be an account, a device, a cryptographic key or a credential holder. In some systems it may indeed be a legally identified person, but that last step is additional.

Imagine a service that needs to recognise me each time I return. It creates an account and associates that account with a cryptographic key on my device. On Monday, I authenticate; on Tuesday, I authenticate again. The service can establish that the same principal has returned. It does not inherently need to know the civil identity of the human controlling that principal.

The relationship can remain:

cryptographic principal → authentication → account

rather than:

civil identity → account → authentication

There are obviously services for which that distinction cannot be maintained. A bank operating under customer-identification requirements has reasons for associating an account with a legally identifiable person. HMRC cannot sensibly allow an arbitrary pseudonymous principal to decide which taxpayer’s affairs it wishes to administer. A passport application rather defeats its purpose if the issuing authority has no idea who the applicant is.

But those examples establish the need for identity in those transactions. They do not establish a general need for identity as the foundation of digital authentication. That distinction becomes increasingly relevant as verification infrastructure becomes easier to use.

If a system already has a convenient mechanism for binding an account to a verified human identity, there is a temptation to treat that as stronger authentication. Sometimes it is. It can also be more information than the transaction requires.

10.3 The Stable Principal And The Stable Person

This becomes clearer if we distinguish a stable principal from a stable human identity. Many online services need continuity. A discussion forum may need to know that the person posting today controls the same account that accumulated a reputation over the previous five years. A game may need to know that the returning player controls the character, purchases and achievements associated with an account. A software service may need to know that a subscription belongs to the principal attempting to use it. A messaging service may need to preserve relationships between accounts and cryptographic keys.

All of those systems benefit from stability, but stability does not necessarily mean civil identity. A pseudonym can be stable, a public key can be stable, an account identifier can be stable, and a credential can establish continuity without announcing the legal identity of its holder to every service with which it interacts.

This matters because the synthetic-internet problem examined earlier can otherwise push us towards an unnecessary conclusion. If platforms increasingly need to distinguish persistent participants from disposable automated actors, they may need stronger principals. That does not automatically mean they need named people.

The useful property might be:

SAME PRINCIPAL AS BEFORE = TRUE

or:

UNIQUE HUMAN = TRUE

rather than:

THIS HUMAN IS WAYNE HORKAN

The difference is not cosmetic. The first two assertions solve particular trust problems. The third establishes identity.

10.4 Authorisation Needs Even Less

The distinction becomes sharper again when we reach authorisation. An authorisation system is fundamentally concerned with permission: can this principal read this record, execute this transaction, administer this resource, enter this environment or invoke this capability?

In well-designed security architecture, authorisation is normally constrained by what the principal needs to do. We do not ordinarily argue that somebody should receive every permission available merely because the system knows exactly who they are. Knowing identity and granting authority are separate decisions.

Yet the relationship can become inverted in consumer digital systems: first identify the person, then authenticate the identified account, then inspect the person’s attributes, then determine what they may do. That architecture can be perfectly legitimate where the permissions genuinely attach to a legally identified person.

But consider an adult service. The authorisation decision may be:

AGE >= 18?

If the answer is yes, the service permits access. What additional authorisation value does the person’s name provide?

Or consider a system attempting to prevent one person from creating thousands of accounts. Its relevant proposition might be:

UNIQUE HUMAN?

Knowing the person’s civil identity is one possible mechanism for establishing uniqueness. It is not the same requirement.

This is where Simon’s objection stops being a conventional privacy argument. The question is not simply whether collecting identity creates privacy risk. The question is why identity entered the transaction at all.

10.5 Identity As The Default Trust Anchor

There are practical reasons why it does. Civil identity is extremely useful. Governments already maintain identity records, passports and driving licences are widely recognised evidence, banks and regulated organisations have established identity-checking processes, commercial identity providers can verify people against existing data sources, and biometrics can help bind a person to previously established evidence.

When somebody asks for greater assurance online, reaching for identity is therefore understandable. Identity appears to provide a strong anchor. Once the person is known, other things can be attached to them: accounts, credentials, entitlements, reputation, permissions and transactions.

That produces a familiar trust chain:

identified human → authenticated account → attributes → permissions

The chain can be useful. The danger lies in treating it as universal, because every time identity becomes the root of another trust relationship, systems acquire another opportunity to bind activity back to the same human being. Even where individual disclosures are tightly controlled, the architecture has made civil identity structurally relevant to another transaction.

That is a different concern from whether a website receives my date of birth. It concerns what the system regards as the ultimate source of trust.

10.6 The Question Before The Identity Question

The previous chapter asked whether a citizen-held credential system is genuinely citizen-centric if institutions still determine which proofs are required and what happens when they are withheld. Simon’s argument moves the question one stage earlier.

Before asking who issues the credential, where it is stored, how selectively it can be disclosed or who controls its presentation, ask:

What property does this transaction actually require?

If the service needs continuity, establish continuity. If it needs authentication, authenticate a principal. If it needs an attribute, prove the attribute. If it needs uniqueness, establish uniqueness. If it needs authority, establish the relevant authority. And if it genuinely needs to know who the human being is, identify the human being.

That ordering sounds obvious when written down. Our emerging infrastructure does not guarantee that we will follow it. Indeed, Chapters 3 and 4 described precisely why the opposite may become easier. Once trustworthy identity and attribute assertions are available through common infrastructure, using them becomes cheaper. The technical friction that previously discouraged unnecessary verification begins to disappear.

That is why the next stage of the argument cannot simply be about making digital identity safer. It has to examine what we are putting at risk when we make identity routine.

10. Identity Is A High-Value, Non-Rotatable Asset

Security engineers spend a great deal of time thinking about what happens when secrets escape. Passwords can be changed, session tokens invalidated, API keys revoked, cryptographic keys replaced, and certificates allowed to expire and be reissued. Good security architecture assumes that credentials may eventually be compromised and provides some mechanism for recovering from that compromise.

Civil identity is awkward because many of its most useful components do not behave like credentials at all. I cannot rotate my date of birth, revoke my face or replace my history. That should change how we think about identity in system design.

11.1 Secrets Are Designed To Be Replaceable

Consider an ordinary password. A password is valuable because somebody who knows it may be able to impersonate the account holder. If the password appears in a breach, the appropriate response is familiar: invalidate it and choose another.

The same principle applies, with different mechanics, to stronger authentication systems. A compromised session token can be revoked, a lost hardware authenticator can be removed from an account, a private key can be superseded by another key, and a passkey can be deleted and replaced. Recovery can be painful, and badly designed recovery mechanisms create their own security problems, but the architecture at least recognises that authentication material has a lifecycle:

issue → use → revoke → replace

Identity attributes often do not. My date of birth is useful precisely because it is persistent. A biometric is useful partly because it remains associated with the same body. A government identifier is useful because institutions expect it to continue referring to the same person. Address history, employment history, nationality and other biographical information derive much of their evidential value from being facts about an enduring human rather than disposable technical artefacts.

Persistence makes identity useful. It also makes exposure expensive.

11.2 You Cannot Change Your Birthday After A Data Breach

This is one reason traditional identity verification has always produced uncomfortable security trade-offs. Suppose an organisation asks me for my date of birth as part of an account-recovery process. The date is easy for me to remember, stable and capable of being compared with an existing record. All useful properties.

But it is a terrible secret. I use the same date of birth everywhere because I only have one. Other organisations know it, government records know it, my family knows it, it may appear in leaked datasets, and it may be inferable from public information. If somebody acquires it, I cannot solve the problem by obtaining another birthday.

The same structural problem applies more severely to biometrics. A fingerprint can be a powerful means of establishing that the same physical person is present, and a face can be compared with an identity document or enrolment record. But neither should be treated as though it were simply a very long password.

Passwords are supposed to be secret and replaceable. Faces are neither.

Modern biometric authentication systems can mitigate this by keeping biometric templates locally protected and using the successful biometric check to unlock a cryptographic operation rather than transmitting the biometric itself. In that architecture, the face or fingerprint is not the remote authenticator presented to every service. That distinction is precisely the point: the architecture protects the high-value human characteristic rather than routinely distributing it.

Identity deserves the same treatment.

11.3 Identity Should Be What Authentication Protects

There is a useful inversion available here. We often think of identity information as something that strengthens authentication. Perhaps the better principle is that authentication should protect identity information.

A service should not receive more durable information about a human merely because it wants greater confidence that the same authorised principal has returned. If cryptographic authentication can establish continuity, use cryptographic authentication. If a capability can convey authority, use the capability. If an attribute proof can establish eligibility, use the attribute proof. Identity should enter the transaction when identity itself is required.

That is not an argument for weaker authentication. Quite the opposite. Cryptographic authentication can be considerably stronger than asking somebody to reproduce biographical information that an attacker may already possess. Nor does it imply that identity should never be bound to an account. Sometimes the binding is the point. The question is whether that binding should propagate into every subsequent interaction.

A bank may need to know who opened an account. That does not mean every internal service, external merchant or technical subsystem needs access to the customer’s civil identity merely to establish that a valid payment authority exists. A government may need to establish who is entitled to a particular benefit. That does not automatically mean every service at which the resulting entitlement is exercised needs the evidence from which the government established it.

Jerry’s credential model already separates the evidence from the proof. Simon’s argument suggests another separation: where possible, separate the person from the principal.

11.4 Binding Creates Value And Risk

None of this means that binding digital principals to civil identities is inherently undesirable. Binding can solve real problems: it can make fraud harder, support contractual enforcement, enable recovery, satisfy statutory obligations, prevent somebody from acquiring an entitlement several times under different accounts, and provide accountability where accountability is genuinely required.

But binding also creates something valuable: a durable relationship between digital activity and a human being. That relationship is attractive to more actors than the one that originally created it. A service may establish identity for regulatory reasons, its fraud systems may find the resulting identifier useful, its customer-support systems may use it to resolve ambiguity, other services may want it for account recovery, analytics systems may discover that it improves matching, and risk models may use it because it provides continuity.

The original justification can remain perfectly legitimate while the binding becomes useful elsewhere. This is not necessarily abuse. It is what systems do with reliable keys. A stable identifier is extraordinarily useful for joining records. That is exactly why database architects like them, and it is also why privacy architects worry about them. The same property creates both effects.

11.5 Correlation Is An Architectural Property

Privacy discussions often concentrate on disclosure: what did this service learn about me? That is necessary, but it can miss another dimension: can separate interactions be connected?

Imagine two systems that each know almost nothing. Service A receives a persistent identifier and the fact that its user is over 18. Service B receives the same persistent identifier and the fact that its user holds a particular entitlement. Individually, each service has received very little information. If the identifier can be matched across contexts, the combined system can learn considerably more.

Selective disclosure therefore does not automatically solve correlation. A credential can reveal only one attribute and still provide a stable hook through which repeated presentations become linkable. Conversely, a system can potentially prove the same attribute repeatedly without giving unrelated verifiers a common identifier with which to join those events. The implementation details matter enormously.

This is why privacy-preserving credential systems spend so much effort on concepts such as unlinkability and pairwise or context-specific identifiers. The objective is not merely to reduce the number of fields disclosed in a transaction. It is to avoid creating an unnecessary universal join key for human activity.

That is an architectural constraint, not a privacy notice.

11.6 The Value Of An Identity Increases With Its Connections

There is another consequence. The more systems that rely upon the same identity binding, the more valuable that binding becomes. A verified identity associated with one regulated account tells us something. The same identity connected to employment, qualifications, age, entitlements, payments, reputation, devices and online accounts becomes a substantially richer asset.

No single organisation needs to possess the complete picture for the risk to exist. Correlation can occur through common identifiers, brokers, compromised systems or lawful data exchange. It can occur because future rules permit combinations that current rules prohibit, and it can occur indirectly where sufficiently distinctive collections of attributes allow records to be matched without an explicit common identifier.

Again, none of this means that such systems inevitably become centralised surveillance infrastructures. That would be to make the same mistake this series has tried to avoid throughout: treating architectural capability as proof of institutional intent or inevitable outcome.

The narrower conclusion is enough. Persistent identity binding creates a valuable capability. Good architecture should therefore avoid creating that binding where the transaction does not require it.

11.7 Spend Identity Carefully

Security architecture already contains a principle that helps here: do not grant more privilege than necessary. The principle of least privilege exists because every additional permission creates additional consequences if something goes wrong.

Identity deserves similar treatment. Every additional disclosure creates exposure, every unnecessary binding creates another correlation opportunity, every persistent identifier creates another potential join, and every system that acquires difficult-to-change biographical information creates another place from which that information might escape.

The right response is not to declare identity toxic. There are transactions where civil identity is indispensable. The response is to treat it as expensive, not expensive in pounds per verification, but expensive in architectural consequence.

That leads to a different design instinct. When a developer needs authentication, the first question should not be, What identity information can I obtain? When a service needs authorisation, it should not begin with, How do I discover who this human is? And when a regulator requires a condition to be established, implementation should not automatically expand that requirement into persistent identification.

The system should begin with the property actually needed for the decision. Only if that property requires civil identity should the architecture introduce it.

We are not quite at the principle that follows from this. There are still distinctions to make between principals, people, accounts, attributes and authority. But Simon’s objection gives us the direction. Identity is not just another convenient field in an authentication transaction. It is a persistent, high-value and often effectively non-rotatable asset.

We should design systems accordingly.

12. Opening An App Shouldn’t Require Knowing Who I Am

The argument so far has been fairly abstract. Identity, principals, authentication, authorisation, attributes, credentials and correlation are useful distinctions, but architecture becomes clearer when we ask what an ordinary digital interaction actually requires.

So consider something deliberately mundane. I open an app. What does the app need to know about me?

In many cases, surprisingly little. It may need to know that I am the same principal that previously established an account, that I control the device or cryptographic key associated with it, and that the account is entitled to use particular features, settings, purchases or history. Those are legitimate requirements. None inherently requires the application to know my civil identity.

The question it needs answered is often:

IS THIS THE SAME AUTHORISED PRINCIPAL?

not:

WHO IS THE HUMAN BEING HOLDING THE PHONE?

We have become accustomed to those questions being answered together. They do not have to be.

12.1 A Stable Principal Is Not A Stable Identity

Chapter 9 distinguished the principal from the person. A principal is something a computer system can recognise and to which it can attach state, permissions or authority. It might be represented by an account identifier, a cryptographic key, a credential or some combination of them.

The system can then establish continuity: this principal created these documents, purchased this subscription, belongs to these groups, has these permissions and was here yesterday. The account may accumulate years of history and develop a reputation. It may be extremely persistent.

But persistence and civil identification are different properties. A pseudonym can persist, a public key can persist, an account can persist, and a reputation can persist. The architectural mistake is to assume that persistence becomes trustworthy only when attached to a named human being.

Cryptography gives us other ways of establishing continuity. Possession of the private key associated with an account can demonstrate control without presenting a passport. A device can prove possession of a credential associated with a principal without disclosing a legal name. An application can establish entitlement to a previous purchase without necessarily establishing who the purchaser is in civil society.

The service needs a stable relationship with a principal. It does not automatically need a stable relationship with my identity.

12.2 The App Does Not Need My Birthday Either

Age assurance makes the distinction unusually easy to see. Suppose an application contains functionality restricted to adults. Its policy decision may be:

AGE >= 18 = TRUE

What it does not necessarily need is:

NAME = WAYNE HORKAN

DATE_OF_BIRTH = DD/MM/YYYY

ADDRESS = ...

DOCUMENT_NUMBER = ...

Earlier chapters examined how credentials and attribute proofs can separate the proposition from the evidence used to establish it. The additional point here is that the age attribute does not necessarily need to be bound, from the application’s perspective, to a civil identity.

The application may need to know that the authenticated principal satisfies the age condition. That is enough. If every age-restricted service begins with civil identification because identity infrastructure provides a convenient route to age, the internet acquires identity bindings that the underlying transactions never required.

The individual service may disclose little. The architecture has still acquired another connection between a digital principal and a human identity.

12.3 Proving Humanity Is Not The Same As Naming The Human

The synthetic internet makes the same distinction harder but no less important. Increasingly capable automated systems create legitimate demand for mechanisms that distinguish human participation from machine-generated activity. A platform attempting to limit automated account creation might therefore need to establish:

UNIQUE_HUMAN = TRUE

That is not equivalent to:

HUMAN = WAYNE HORKAN

The first says that a real person exists behind the principal and, depending upon the scheme, perhaps that the person has not already obtained another equivalent credential. The second identifies that person. Those are different assertions.

Providing strong uniqueness without eventually relying upon some form of identity proofing is a harder technical problem. Attackers can create accounts, acquire devices, recruit other people or compromise credentials. But implementation difficulty should not collapse the conceptual distinction.

A system may need proof of humanity, uniqueness, continuity or accountability within a particular community. None logically entails universal civil identification. If we fail to specify the property actually required, identity becomes the default because it appears to answer all of them at once.

12.4 Reputation Does Not Require A Passport

Suppose I have spent ten years contributing to an online technical community under a pseudonym. Other participants may have observed hundreds of contributions, arguments, corrections and interactions. They can form a meaningful judgement about the reputation of that principal without knowing the legal identity of the person behind it. Indeed, the reputation attaches to the principal because that is what the community has observed.

Requiring a passport would establish something different: a relationship between the principal and a civil identity. That might be useful for some purpose. It might deter certain forms of abuse or assist legal enforcement where identification is justified. But it does not create the reputation; the reputation already exists.

This matters as platforms search for ways to distinguish established participants from disposable synthetic accounts. Some contexts may justify stronger evidence about the person behind an account. Others may be better served by strengthening the principal instead. Long-lived cryptographic credentials, costly-to-create reputations, community attestations, account history and rate limits can all contribute to trust without requiring every trusted participant to become a named participant.

The appropriate mechanism depends upon the threat being addressed.

11.5 Ask The Question The Transaction Actually Needs Answered

A useful discipline emerges. Before requesting identity, state the decision the system is trying to make. Not the data it wants to collect, and not the credential it knows how to request: the decision.

Can this principal access the account? Has this principal paid? Is this principal an adult? Is this principal entitled to perform this operation? Is this principal the same participant who accumulated this reputation? Is this principal a unique human?

Only after defining the question should the system determine what evidence is necessary to answer it. Sometimes the answer will require civil identity. Often it will not.

This goes beyond data minimisation. Data minimisation asks how little information an intended relationship requires. The prior question is whether the relationship needs to be identity-based at all. That distinction becomes easier to lose as identity services become cheap, standardised and embedded in the stack. If an API can return a verified identity assertion in milliseconds, it becomes an attractive answer to problems that may not actually require identity.

Technical convenience, however, does not establish architectural necessity. Opening an app should not require knowing who I am unless something the app is doing actually requires knowing who I am. Once stated that plainly, we can examine the three different architectures that follow from taking the requirement seriously.

13. Identity, Authentication And Authorisation Have Become Entangled

There are several ways to build a trustworthy digital relationship. They are too often discussed as though they were variations of the same identity architecture. They are not.

The distinctions developed over the previous chapters allow us to compare three broad models. These are deliberately simplified. Real systems will contain hybrids, exceptions and additional trust relationships. The purpose is not to prescribe implementation diagrams but to expose where each architecture places identity. That placement changes what the system needs to know, what it can correlate, and what must be trusted.

13.1 Architecture A: Identity-Mediated

The first model is familiar:

Civil Identity → Authentication → Account → Authorisation

The system begins by establishing who the person is. An account is bound to that identity, authentication subsequently establishes control of the account, and permissions are attached to it.

There are many circumstances in which this architecture is entirely sensible. If I access my tax records, the service must distinguish my tax affairs from somebody else’s. If I enter a regulated financial relationship, the institution may be required to establish the identity of its customer. If I digitally sign a legal instrument whose validity depends upon the identity of the signatory, identity is not incidental to the transaction.

The architecture becomes questionable when the same pattern is carried into interactions where civil identity is not itself part of the requirement. Its strength is also its weakness. Everything has a strong anchor: accounts, transactions, permissions and attributes can be related back to a known human. That can provide accountability, recovery and fraud controls, but it can also create durable correlation.

Once civil identity sits at the root of the trust chain, systems naturally tend to organise information around it. The person becomes the primary key. For some services, that is exactly what we want. It does not follow that we want it for the internet.

13.2 Architecture B: Credential-Mediated

Jerry Fishenden’s model changes the relationship substantially. In simplified form:

Civil Identity → Credential Issuance → Citizen Wallet → Attribute Proof → Authorisation

The issuing authority establishes whatever it needs to establish when creating the credential. The citizen holds that credential. Later, rather than every relying service obtaining the source information again, the citizen can present an appropriate proof.

This can be a considerable improvement over repeatedly distributing identity documents and personal records. The relying service may not need to know my date of birth; it can receive an assertion that I exceed an age threshold. It may not need the records establishing a professional qualification; it can receive proof that the relevant credential is current. It may not need to contact several government departments and reconcile their records before deciding whether I satisfy some condition; I can present credentials issued by the appropriate authorities.

That changes the flow of information. It can reduce repeated disclosure and unnecessary movement of source data, give the citizen meaningful control over presentation and, with appropriate technical design, make presentations difficult to correlate across unrelated services. Those are substantial architectural advantages. They should not be obscured simply because we are sceptical about the broader identity infrastructure.

But the architecture retains an assumption: identity still commonly sits upstream. The citizen may reveal very little to the verifier, yet the credential itself may have been issued following a strong identity-proofing process. The issuer knows that a credential corresponds to a particular person, even if the relying service does not.

Sometimes that is necessary. Sometimes it is simply how the credential ecosystem has been designed. The distinction matters because a privacy-preserving presentation model answers one question extremely well:

How can I prove something without repeatedly disclosing the underlying identity data?

It does not by itself answer:

Did this proposition need to be anchored to civil identity in the first place?

That is where the third architecture diverges.

13.3 Architecture C: Principal-Mediated

A different starting point looks something like:

Cryptographic Principal → Authentication → Capability / Attribute Proof → Authorisation

Civil identity is not prohibited. It is conditional. The system begins with a principal that can authenticate itself cryptographically. Permissions, capabilities or attributes can then be associated with that principal according to the requirements of the service.

Where an attribute can be established without civil identification, no civil identity need be introduced. Where identity is genuinely necessary, it can be added:

Civil Identity → required binding → Principal

The difference is the direction of travel. In the identity-mediated model, identity is the starting point from which trust is derived. In the principal-mediated model, the system starts with the technical relationship required for the transaction and introduces civil identity only when the transaction demands it.

That sounds like a subtle rearrangement. It is not.

Consider a subscription service. Under an identity-first model, I establish who I am, create an account bound to that identity, authenticate to the account, and the service determines that the identified account possesses a subscription. Under a principal-first model, a cryptographic principal holds or can demonstrate the subscription entitlement. The service authenticates the principal and establishes the entitlement.

Unless the commercial or legal relationship requires civil identification, the chain can stop there. The authority is real, the continuity is real, and the authentication can be strong. The identity binding is absent.

13.4 Capabilities Change The Question

Capabilities are useful here because they express authority directly. A capability is, broadly, something that confers the right to perform an operation. Possession or valid presentation of the capability establishes the relevant authority without requiring the system to begin by asking who the holder is.

Physical life already contains loose analogues. A key opens a door because it is the right key, not because the lock first establishes the legal identity of the person holding it. A bearer ticket grants entry because the ticket is valid. Those analogies are imperfect, particularly because digital capabilities can be copied unless they are cryptographically protected and carefully managed, but they expose a different way of thinking about authorisation.

Identity-based systems tend to ask:

WHO ARE YOU?

then:

WHAT ARE YOU ALLOWED TO DO?

Capability-oriented systems can sometimes ask directly:

CAN THIS PRINCIPAL DEMONSTRATE AUTHORITY TO DO THIS?

That is a different trust model. It does not eliminate accountability where accountability is required. A capability can be issued to an identified person, transactions can be logged, and particular actions can require stronger evidence than others. The architectural point is that those properties do not need to be universal preconditions for authority.

13.5 The Three Models Can Coexist

These architectures should not be mistaken for mutually exclusive futures. A practical digital ecosystem will almost certainly contain all three. Some relationships will remain identity-mediated because civil identity is intrinsic to them. Some will use citizen-held credentials because the transaction depends upon a fact established by a trusted issuer but does not require the verifier to receive the underlying identity data. Some could operate through authenticated principals, capabilities and narrowly scoped attributes without introducing civil identity at all.

The useful question is therefore not which architecture wins. It is which architecture is appropriate to which transaction.

That is where current discussion often becomes muddled. We talk about “digital identity” as though the problem were how to build one sufficiently secure, private and convenient identity layer for everything. But perhaps “everything” is the mistake.

A tax authority, a multiplayer game, an adult website, a messaging application, a professional register and an online discussion forum do not necessarily require the same relationship with the humans using them. Forcing all of them towards a common identity substrate may simplify certain forms of trust management while unnecessarily binding very different kinds of activity to the same underlying person. Conversely, refusing identity where the transaction genuinely requires it can weaken accountability, make fraud easier or render the service legally impossible.

The architecture should follow the requirement.

13.6 Where Identity Enters Matters

This gives us a more precise way to think about the architecture emerging after the age gate. The question is not simply whether identity infrastructure exists, whether credentials are stored centrally or on a citizen’s device, or whether disclosure is selective. All of those things matter.

But another design choice sits underneath them:

At what point does civil identity enter the trust chain?

At the beginning? At credential issuance? Only for particular attributes? Only when a particular transaction legally requires identification? Or nowhere at all?

Two systems may present exactly the same result to an application:

AGE >= 18 = TRUE

Yet one may derive that result from a persistent identity record tied across many services, while another may present an unlinkable credential whose verifier cannot identify the holder. A third might involve an authenticated pseudonymous principal carrying an age entitlement without the application ever acquiring a civil identity binding.

The visible assertion is identical. The surrounding architecture is not.

That is why arguments about digital identity cannot be resolved simply by asking whether a proposed system is secure or privacy-preserving. We need to ask what has been bound to what, which party can observe that binding, whether it persists and, before creating it, whether the transaction required the binding at all.

14. The Principle Of Minimum Identity

The previous section left us with a design question that is easy to state and surprisingly difficult to apply consistently: at what point should civil identity enter the trust chain?

Our existing security disciplines already contain several principles intended to stop systems acquiring more authority, information or access than they need. Least privilege says that a user or process should receive only the permissions necessary to perform its function. Need-to-know limits access to information according to purpose. Data minimisation asks us not to collect personal information simply because we can. Zero-trust architectures, despite the marketing abuse of the term, begin from the useful assumption that access should be established explicitly rather than inherited from an overly broad perimeter of trust.

There is a related principle missing from much of the discussion around digital identity. I am going to call it the Principle of Minimum Identity:

A digital transaction should establish no more about the human participant than is necessary to authorise that transaction.

The wording matters. It does not say that identity is undesirable, that anonymous access should always be available, or that every transaction can be reduced to an unlinkable cryptographic proof. Nor does it suggest that fraud, accountability and regulatory obligations somehow disappear if we design sufficiently elegant protocols.

It says something narrower: before identifying somebody, establish why identification is necessary.

14.1 Start With The Decision

Most identity architecture starts too late in the reasoning process. The system has already decided that it will have users with identities. The remaining questions concern how those identities will be established, authenticated, stored, recovered, protected and presented.

Those are legitimate engineering problems, but they assume the answer to an earlier architectural question:

Why does this transaction require identity?

The Principle of Minimum Identity reverses that sequence. Start with the decision the system must make, then determine the minimum proposition necessary to make it.

If the requirement is continuity, authenticate the principal. If the requirement is age, establish the required age condition. If the requirement is entitlement, establish the entitlement. If the requirement is uniqueness, establish whatever form of uniqueness the system actually needs. If the requirement is authority to perform a particular operation, establish that authority. Only when the transaction genuinely depends upon civil identity should the system identify the human being.

That sounds almost embarrassingly obvious after the distinctions developed in the previous chapters. Yet those distinctions matter precisely because systems routinely blur them. A service wants to prevent multiple registrations and reaches for identity. Another wants stronger account recovery and reaches for identity. Another wants to reduce fraud and reaches for identity. Another needs an age threshold and obtains identity because the available age-assurance mechanism derives the answer from an identity document. Another wants accountability and assumes that accountability means knowing everybody’s legal name.

Each may have a defensible problem. The mistake is treating civil identity as the generic solution.

14.2 Minimum Identity Is Not Data Minimisation

This principle overlaps with data minimisation, but it is not the same thing. Suppose a service decides that every user must establish a verified civil identity. It then designs an admirably restrained system around that decision: it retains very little information, encrypts what it stores, uses selective disclosure, prevents unnecessary internal access, deletes transient evidence and obtains only the identity attributes it considers necessary.

That may be excellent data-minimisation practice. The Principle of Minimum Identity asks the question before all of those controls:

Did the service need to establish civil identity at all?

A system can minimise data within an unnecessarily identity-bound architecture. This is why the distinction matters. If the service needs only to know that I am over eighteen, receiving OVER_18 = TRUE is better than receiving my date of birth. But if the proof is unnecessarily bound to a persistent identifier that allows my activity to be connected across contexts, minimising the disclosed attribute has solved only part of the problem.

Likewise, if the service merely needs to recognise me when I return, collecting fewer identity attributes is less useful than recognising that civil identity was unnecessary to continuity in the first place.

Minimum identity therefore operates one layer above ordinary data minimisation. Data minimisation asks:

How little information should this system collect?

Minimum identity first asks:

What relationship does this system actually need with the human being?

Only then should we decide what information is required to support that relationship.

14.3 Identity Has A Scope

There is another consequence. Identity should have a scope in much the same way that authority has a scope. Modern security engineering is rightly suspicious of credentials that confer unrestricted power. We prefer permissions bounded to particular resources, operations, services or periods of time. Yet identity bindings are often treated differently.

Once established, the fact that a principal corresponds to a particular human being can become reusable across purposes. The same verified identity may support account recovery, age assurance, fraud prevention, payments, reputation, regulatory compliance or access to unrelated services. Technically, reuse can look efficient. Architecturally, it can turn a narrowly justified act of identification into a general-purpose trust anchor.

Minimum identity implies that an identity relationship justified for one purpose should not automatically be treated as necessary for another. My bank may have good reasons to know who I am; that does not mean a discussion forum needs to inherit the bank’s knowledge. A government service may need to establish my identity before granting a particular legal entitlement; that does not mean every subsequent presentation of that entitlement needs to reveal, or even expose a stable route back to, the identity used when it was issued. An employer may legitimately need to establish my right to work; that does not mean every system I use in performing that work needs my civil identity as its authentication substrate.

The trust may originate in an identified relationship while subsequent transactions operate with considerably less identity. That is where credential systems, scoped identifiers, cryptographic principals and attribute proofs become interesting. Their value is not simply that they hide fields on an identity record. Properly designed, they can allow trust to travel without requiring identity to travel with it.

Whether deployed systems actually achieve that is a separate question.

14.4 Minimum Does Not Mean Zero

There is an obvious temptation to turn the principle into an argument for universal anonymity. That would make it weaker.

There are transactions in which the identity of the participant is part of the transaction itself. There are others where accountability requirements may legitimately require an identity binding even if the counterparty does not need to see it during ordinary operation. There will also be contested cases.

Fraud prevention provides a good example. A service may argue that identifying users substantially reduces fraud. Users may argue that the same objective can be achieved through device-bound credentials, payment guarantees, reputation, transaction limits or other controls. Regulators may impose additional requirements. Attackers will adapt to whatever system is built. There is no architectural maxim that can settle those trade-offs automatically.

Minimum identity instead changes the burden of design. Identification becomes something to justify rather than something to assume.

That is closely analogous to least privilege. Least privilege does not say that software should have no permissions. It says that permissions should correspond to demonstrated requirements rather than administrative convenience. Minimum identity should work the same way.

The appropriate question is not:

Can identity help us solve this problem?

It often can.

The question is:

What is the least identity relationship necessary to solve this problem adequately?

Sometimes the answer will be a verified civil identity. Sometimes it will be a pseudonymous but persistent principal. Sometimes it will be a narrowly scoped attribute. Sometimes it will be possession of a capability. Sometimes the system may need nothing persistent about the human participant at all.

The principle does not choose among those outcomes in advance. It requires the architecture to make the choice deliberately.

14.5 A Different Default

This would represent a subtle but consequential change in default assumptions. The emerging identity infrastructure discussed throughout this series makes verified facts about people easier for software to obtain. That can solve real problems: it can replace crude document collection, reduce fraud, support regulatory obligations and allow attributes to be established without exposing the underlying evidence.

But as the cost of obtaining trustworthy assertions falls, the discipline governing when we ask for them becomes more important. The Principle of Minimum Identity provides one such discipline.

Do not identify because identification is available. Do not bind a principal to civil identity because doing so might prove useful later. Do not turn an attribute requirement into an identity requirement because the infrastructure happens to make identity the easiest route to the answer.

Establish what the transaction needs. Prove that. Stop.

That last step becomes harder as verification becomes easier, because good privacy engineering creates a paradox of its own.

15. The Paradox Of Privacy-Preserving Verification

There is a comfortable version of the digital identity debate in which the architectural choices line up neatly. Central databases are intrusive, repeated document sharing is dangerous, large identity providers create attractive targets, and services should not collect dates of birth, passport details and addresses merely to establish simple facts about their users.

The alternative is correspondingly attractive. Put credentials into the hands of the individual, allow selective disclosure, use cryptographic proofs where appropriate, let the relying service receive only the proposition it actually requires, prevent unnecessary movement of source data, reduce retention and reduce correlation. Jerry Fishenden’s model sits substantially on this side of the argument, and there is much to recommend it.

The awkward possibility is that it could work extremely well.

15.1 Better Privacy Can Lower The Cost Of Verification

Consider the economics of a verification decision. If establishing an attribute requires a user to photograph a passport, upload it to an unfamiliar service, take a selfie, wait for a third party to process the result and perhaps repeat the exercise elsewhere, verification carries costs for everyone involved. The user experiences friction and disclosure, the service acquires integration, support and compliance costs, the verifier may process sensitive personal information, and failures create abandoned transactions and angry customers.

Those costs discourage unnecessary verification. They are bad privacy engineering, but they are also friction.

Now replace that process with a mature credential ecosystem. The user already possesses an appropriate credential, a service requests a proposition, the wallet presents the required proof, and the verifier learns only what it needs. The interaction takes seconds, perhaps less. The service never receives the source document and may never receive the underlying identity attribute.

That is a better transaction. It is also a cheaper transaction, and cheaper things get used more often.

This is where the privacy analysis becomes more complicated. We normally assess privacy by asking how much information a particular transaction reveals. Under that measure, selective disclosure and privacy-preserving credentials can be a considerable improvement. But an architecture has another dimension: how many transactions require a verified proposition at all?

Those variables can move in opposite directions. Disclosure per verification can fall while the number of verifications rises, potentially by a great deal.

15.2 Less Disclosure, More Verification

Imagine two versions of the internet. In the first, verification is cumbersome. Most services know whatever users choose to tell them, supplemented by behavioural inference, account history and whatever information the service collects itself. Strong verification is reserved for circumstances where somebody considers the cost worthwhile.

In the second, verified attributes are easy to request and easy to present. Each individual transaction may reveal less, yet the aggregate architecture may nevertheless contain far more moments at which software asks a trusted system to establish something about the person or principal before permitting an action.

Age. Residency. Entitlement. Professional status. Membership. Humanity. Uniqueness.

The specific attributes are not the point. Chapter 3 already examined why reusable verification infrastructure makes additional predicates cheaper to support. The point here is what happens when privacy engineering removes one of the remaining constraints on their use.

A service that would never have asked users to upload identity documents may be perfectly willing to request a minimally disclosing credential. A regulator that would consider universal document checks disproportionate may view an attribute proof differently. A business that would not tolerate the abandonment rate of conventional verification may accept a wallet interaction that users barely notice. None of those decisions needs to be unreasonable. The cumulative effect can still be a more permissioned architecture.

That gives us the paradox:

Less disclosure per transaction can coexist with vastly more verified transactions.

Privacy at the transaction level and permission at the system level are different properties. Improving one does not automatically improve the other.

15.3 The Permission Ratchet

Once verification infrastructure becomes ordinary, adding another condition of access also changes politically and organisationally. Building a new identity system is conspicuous; requesting one additional proposition from an existing credential ecosystem is not. The latter may require no new database of users, no new identity document and no large central repository of personal information. It may be implemented with excellent selective disclosure and strict retention controls.

That is precisely why it can spread. The incremental decision becomes small. A service introduces a credential requirement to reduce fraud; another does so because an insurer prefers stronger assurance; another responds to a regulatory obligation; another wants to distinguish humans from automated agents; another discovers that verified eligibility simplifies an existing process; and another adopts the mechanism because the operating system, wallet or platform has made integration straightforward.

Each decision can be assessed on its own merits and still contribute to a cumulative architectural change. The ratchet is not that verification requirements can never be removed; they plainly can. It is that once the infrastructure exists, the marginal cost of adding another verified condition falls, while institutions continually generate reasons for wanting greater assurance.

Fraud is real. Bots are real. Children do encounter inappropriate material. Eligibility rules exist. Professional qualifications sometimes need to be checked. Synthetic content makes provenance harder. Platforms have legitimate reasons to distinguish trusted participants from disposable accounts. There will never be a shortage of plausible cases for asking one more question.

The relevant constraint therefore cannot be technological difficulty alone.

15.4 Privacy Engineering Cannot Decide Where Verification Belongs

This is why the Principle of Minimum Identity and privacy-preserving credentials solve different problems. Selective disclosure asks how much a verifier should learn, unlinkability asks whether separate presentations can be connected, local storage asks where credentials reside, and cryptographic proof asks how a claim can be established without revealing unnecessary evidence. Minimum Identity asks whether the transaction should require that relationship in the first place.

A system can perform extremely well on the first four and poorly on the fifth. It can reveal almost nothing unnecessary while requiring people to prove something before doing almost everything. That would be an internet with considerably better privacy engineering and considerably more preconditioned access. The two descriptions are not contradictory.

If presenting a credential feels no more consequential than unlocking a phone, users may reasonably prefer it to sending documents around the internet. Developers may prefer it. Governments may prefer it. Service operators may prefer it. The absence of friction tells us little about the distribution of permission underneath.

15.5 Jerry And Simon Are Solving Different Problems

This is where Jerry Fishenden’s and Simon Freeman’s arguments become particularly useful together. Jerry’s model asks how we can escape the repeated copying, reconciliation and central movement of personal data. Citizen-held credentials provide a technically credible answer to part of that problem. A person can carry trustworthy assertions and present them when needed rather than forcing organisations continually to exchange source records behind the scenes.

Simon pushes the question one stage earlier: why is this transaction asking for identity-derived trust at all?

Those positions are not opposites. A system designed according to Jerry’s model could also adopt the Principle of Minimum Identity. Credentials could be issued and presented in ways that minimise correlation. Services could request attributes rather than identities. Identity-bound credentials could be reserved for circumstances where the binding is justified. Other credentials could attach to pseudonymous or scoped principals where civil identity adds nothing necessary to the transaction.

Conversely, a beautifully engineered citizen wallet could become the delivery mechanism for an internet in which ever more activities require a machine-verifiable permission slip. The wallet does not decide which of those futures we get, and neither does selective disclosure. Those are questions of architecture, governance and scope.

15.6 Solving The Wrong Problem Extremely Well

There is a broader lesson here. Bad identity systems make the argument easy. Centralised databases, repeated passport uploads, unnecessary retention and indiscriminate data sharing present obvious targets. We know how to criticise them, and increasingly we know how to build better alternatives.

The harder problem appears when the technology stops being obviously bad.

• Suppose credentials are decentralised.
• Suppose disclosure is minimal.
• Suppose presentations are difficult to correlate.
• Suppose users control the act of presentation.
• Suppose source documents no longer circulate between relying parties.
• Suppose the whole thing is secure, fast and convenient.

We should want those properties. But they still leave one question unanswered:

How often should participation in digital life depend upon proving a machine-verifiable fact about ourselves?

That is the paradox of privacy-preserving verification. We may solve much of the privacy problem associated with digital identity and, by doing so, make verified permission cheap enough, safe enough and painless enough to place almost everywhere.

The danger is not that privacy-preserving verification fails. It is that it succeeds, and we mistake a better way of verifying people for an answer to the separate question of when people should have to be verified at all.

16. The Path Of Least Resistance

The previous chapter ended with an uncomfortable possibility. Privacy-preserving verification may solve many of the problems associated with digital identity while simultaneously making verification cheap enough, unobtrusive enough and reusable enough to spread much further.

That raises another question: given several technically possible ways of satisfying a requirement, which one actually gets built?

Architecture is not selected solely by comparing designs and choosing the most elegant. It emerges from existing systems, budgets, deadlines, procurement rules, legal obligations, institutional risk, user expectations and whatever infrastructure is already available. There is always a path of least resistance, and once we are dealing with regulation, the resistance that matters is not simply technical.

16.1 Easy For Whom?

Software engineers use easy in a particular way. An API is easy to integrate, a protocol has good libraries, a platform capability is already available, or a service can be implemented without operating another database or developing specialist expertise. Those things matter.

But governments, regulators and regulated organisations operate under different forms of friction. A regulator wants an outcome. A government wants a policy implemented. A regulated organisation wants to demonstrate compliance. Its lawyers want a defensible interpretation of the requirement, its risk function wants something it can explain, procurement wants something obtainable, operations wants something supportable, and product teams want users not to abandon the service halfway through the process.

The easiest architecture is therefore not necessarily the one with the least code. It is the one that encounters the least combined resistance across the system.

We can think about that resistance roughly as:

implementation + compliance + institutional risk + procurement + user friction + auditability

There will be other factors, and their relative weight will vary enormously between systems. The point is not to create a formula, but to recognise that technical elegance is only one term.

This helps explain why architectures that appear unnecessarily complicated to engineers can persist for years. They may be technically awkward while remaining institutionally easy: everybody knows how they work, existing contracts support them, auditors understand them, regulators recognise them, and risk models assume them. The reverse is also true. An architecture can be technically superior and still fail to spread because adopting it requires too many other things to change first.

16.2 Regulation Creates Demand For Defensible Assertions

Now consider the problem from the perspective of an organisation faced with a regulatory requirement. Suppose the requirement is, in effect:

DO NOT ALLOW CLASS X TO PERFORM ACTION Y

The exact legal language may be considerably more complicated, but the implementation problem eventually has to become something software can evaluate. The organisation needs some way to determine whether the user belongs to class X.

If no trustworthy mechanism exists, the problem is difficult. The organisation may need to collect evidence itself, contract with a specialist provider, construct a probabilistic assessment, rely upon self-declaration or redesign the service so that the distinction becomes unnecessary. Each option carries cost and risk.

But suppose a platform, wallet, credential provider or operating system already exposes a trustworthy signal capable of answering the relevant question. The implementation problem changes. Instead of inventing another mechanism, the service consumes the signal. That may become the path of least resistance.

The attraction is not necessarily that the signal reveals more. Quite often the opposite may be true. As Fishenden’s model demonstrates, a well-designed credential can reveal substantially less than the underlying records from which it was derived. What matters institutionally is that the assertion is sufficiently trustworthy for the decision being made.

Regulatory obligations create demand for assertions that organisations can rely upon and defend. That does not mean regulators inevitably demand identity, nor that regulation automatically produces centralised identity systems. Often the requirement is an outcome rather than a prescribed architecture. But if a standardised mechanism already produces an assertion sufficiently trustworthy for that outcome, it becomes attractive. Not ideologically attractive. Operationally attractive.

16.3 From Requirement To Software

The movement from policy to implementation is where much of this happens. A government may decide that a category of user should not have access to a particular capability. A regulator may specify the standard expected of the service. Lawyers and compliance teams interpret what that means for the organisation. Product and engineering teams then have to turn the result into software.

By the time the requirement reaches the application, a broad social objective has become a decision problem. Something like:

CONDITION SATISFIED?

If the answer can be obtained from existing infrastructure, there is a powerful incentive to use it. The infrastructure does not need to have been built for that particular purpose. This is where reuse matters.

An age assertion created to satisfy one requirement may be useful elsewhere. A residency credential created for a government service may answer another eligibility question. A professional credential created to replace manual document checks may become a machine-readable authorisation signal. Whether such reuse is desirable depends upon context, governance and technical design, but its economics are straightforward.

The first implementation carries much of the cost of creating the mechanism. Subsequent implementations consume it. That asymmetry changes what becomes practical.

16.4 The Installed Base Has Gravity Too

The path of least resistance is also shaped by what already exists. We are not designing the internet again from scratch. We already have accounts, identity providers, government identity records, mobile operating systems, app stores, payment systems, authentication infrastructure, device security, credential providers and regulatory compliance processes. New architecture lands on top of that installed base.

A design can therefore be more privacy-preserving, more decentralised or more conceptually correct while still losing to a less elegant design that can be deployed next Tuesday. The installed system only has to be good enough.

Suppose an application needs a stable principal rather than a civil identity. If the easiest available SDK says:

GET VERIFIED USER

while the less identifying alternative requires a new credential format, unfamiliar libraries, new recovery mechanisms and a compliance argument that has never been tested, the identity-bound option begins with a considerable advantage.

That advantage has nothing to do with whether civil identity is logically necessary. It comes from the installed base. Change the installed base and the advantage can change with it.

16.5 Compliance Has A User Experience

There is another form of resistance: the experience imposed on the person using the system. A technically sound compliance mechanism that makes a service miserable to use creates abandonment, complaints and support costs.

Privacy-preserving verification can reduce those costs substantially. A narrowly disclosed credential presented in seconds is easier to use than repeated document uploads or lengthy identity checks. That is a genuine improvement. It also means that user friction no longer provides the same practical constraint on introducing verification.

This is the connection to the previous chapter. Chapter 14 dealt with the resulting paradox. The narrower point here is that user experience forms part of the resistance against which implementation decisions are made. Make a mechanism easier for the user and it also becomes easier for the organisation to deploy.

16.6 Infrastructure Gets Reused

The mechanism can now be stated simply. A requirement appears and a mechanism capable of satisfying it already exists, so the mechanism is used. A second requirement appears, and reusing the mechanism is cheaper than inventing another. The mechanism acquires more integrations, those integrations reduce the resistance faced by the next organisation, standards develop around it, vendors support it, auditors become familiar with it, procurement frameworks recognise it, and the unusual becomes ordinary.

This does not determine what the mechanism has to be. Different infrastructures can acquire the advantage. The point is more general:

architecture does not have to be mandated to become dominant. Sometimes it merely has to be easier than the alternatives.

That gives us the mechanism. It also gives us the next question: given several architectures capable of satisfying the requirement, can we describe more precisely the selection pressure acting between them?

That is where the Horkan model begins.

17. The Horkan Model

The Horkan model starts from the less elegant question raised at the end of the previous chapter: what is easiest to build from here? Not easiest in the abstract, but easiest given the infrastructure that already exists, the requirements an organisation has to satisfy, the capabilities platforms already expose, the mechanisms institutions already trust, and the systems developers can deploy without redesigning everything around them.

That makes it different from both the Fishenden and Freeman models. They illuminate what the architecture could optimise for. The Horkan model describes the selection pressure acting between the available alternatives.

17.1 Three Different Starting Points

Fishenden starts with a problem of information movement. Government repeatedly asks citizens for information that government, or some other authoritative institution, already knows. Departments integrate with other departments, records are copied, reconciled and matched, and new interfaces are created. His alternative moves the citizen into the information flow:

Civil Identity → Credential Issuance → Citizen Wallet → Attribute Proof → Authorisation

The optimisation target is:

move trustworthy proofs rather than repeatedly moving the source data required to reconstruct them.

As discussed earlier, that does not automatically make the resulting ecosystem citizen-governed. But it can materially reduce unnecessary data sharing and repeated disclosure.

Freeman begins somewhere else. His question is whether civil identity needed to enter the transaction at all. The architecture therefore starts with the principal:

Cryptographic Principal → Authentication → Capability / Minimum Necessary Proof → Authorisation

Identity can still be introduced where required. It simply ceases to be the assumed root of trust. The optimisation target is:

establish the minimum property necessary to make the decision.

The Horkan model begins neither with the citizen nor with the principal. It begins with the requirement:

Policy Requirement → Available Trusted Signal → Reusable Verification Mechanism → Policy Decision → Permitted Environment

Its optimisation target is:

satisfy the requirement using the lowest-friction defensible mechanism available.

That is not a recommendation. It is a model of institutional and technical selection. Fishenden asks how trust should travel, Freeman asks how much identity needs to travel with it, and Horkan asks which available mechanism institutions will actually find easiest to deploy and defend.

16.2 The Model Does Not Have A Preferred Destination

This distinction matters because it would be easy to misunderstand the argument as:

GOVERNMENTS WANT IDENTITY → IDENTITY WINS

That is too crude. Governments and regulators want many things, often simultaneously and sometimes inconsistently: child protection, fraud reduction, accessible services, enforceable rules, functioning markets, administrative efficiency, privacy and security. Different institutions place different weight on those objectives. Policy changes, governments change and technologies change.

The Horkan model does not require a single coherent institutional objective. It requires only a requirement, several possible mechanisms for satisfying it, and differences in the resistance associated with deploying those mechanisms. The model therefore has no preferred architectural destination.

If citizen-held credentials with selective disclosure become the easiest defensible mechanism to deploy, the path of least resistance can lead towards Fishenden. If cryptographic principals, scoped identifiers and minimum-identity proofs become easier to implement and defend, it can lead towards Freeman. If identity-bound attributes are easier to obtain, better supported by platforms and more familiar to compliance teams, it can lead towards an identity-mediated architecture.

The model selects for deployability, not identity. That distinction is essential.

17.3 The Cheapest Satisfactory Answer

The selection process is better understood as satisficing than as optimisation for architectural purity. Organisations rarely need the theoretically perfect mechanism. They need one that satisfies the requirement sufficiently well at acceptable cost and risk.

Suppose a service needs to establish that a user is an adult. There may be several technically plausible mechanisms. Some may provide stronger privacy, greater assurance, better resistance to circumvention, less correlation or a more intelligible user experience. But if one mechanism is already integrated into the device, accepted within the relevant compliance regime, documented for developers and familiar to the organisation’s lawyers, it starts with a considerable advantage.

The service does not have to believe that mechanism represents the ideal architecture of digital trust. It merely has to conclude that it is a satisfactory answer to the problem immediately in front of it.

This is the Horkan model in its most compact form:

Desired Outcome + Available Capability + Institutional Constraints → Lowest-Resistance Defensible Mechanism

The deployed mechanism then becomes part of the available capability encountered by future implementations. Chapter 15 described that feedback process. The purpose of the model is to identify the selection pressure operating within it.

17.4 The Model Works In Both Directions

There is an important consequence of the model having no preferred destination. Implementation friction is not fixed; it can be designed.

If we want services to authenticate principals without unnecessarily identifying humans, those mechanisms have to be practical. Developers need usable abstractions, recovery has to work, platforms need to support them, auditors and compliance teams need to understand the resulting assurance, and regulators need to be able to recognise when a narrowly scoped proof satisfies a requirement without requiring the underlying identity. Likewise, if Fishenden’s citizen-held credential model is to displace repeated institutional data sharing, presenting a credential has to compete successfully with building another conventional integration. Issuance, revocation, recovery, interoperability and the user experience all have to work. Otherwise the existing mechanism retains its advantage.

The same principle applies in the opposite direction. If obtaining a verified identity is one API call while establishing a pseudonymous entitlement requires six vendors, three standards and an argument with the compliance department, we should not be surprised when developers request identity. If an operating system can instead provide an unlinkable, narrowly scoped proof through a well-supported interface while acquiring identity creates additional liability and user friction, minimum identity can become the easier architecture.

The model is therefore descriptive before it is normative. It tells us why one mechanism may be selected over another. But once that selection pressure is visible, it also tells us where intervention can matter. Standards, platforms, regulation, procurement, developer tooling and liability can alter it, as can what organisations regard as safe, familiar and defensible.

The path of least resistance is not necessarily the path we inherit. It can also be the path we build.

17.5 What The Model Adds

The model therefore occupies a different level from either Fishenden or Freeman. Fishenden gives us an architecture for carrying trustworthy claims without repeatedly moving the underlying source data. Freeman gives us a discipline for deciding whether civil identity needs to enter the transaction at all. The Horkan model does neither; it asks which of the available mechanisms is most likely to be selected when an organisation has to turn a requirement into a working, defensible system.

That distinction connects this article back to the convergence argument developed in The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex without requiring central coordination or a predetermined destination. Different institutions can want different things, different services can face different requirements, and different engineers can make locally reasonable decisions. What matters to the model is that some mechanisms are easier to deploy than others. If that relative ease changes, the resulting architecture can change with it.

This produces a practical consequence for the Principle of Minimum Identity. Demonstrating that minimum identity is architecturally preferable where civil identity is unnecessary is not enough; the alternative has to survive implementation. If minimum identity is to become the default where minimum identity is sufficient, we have to make it the path of least resistance.

18. What Does The Post-Age-Gated Internet Feel Like?

The phrase age-gated internet suggests something more cumbersome than the architecture described in the preceding chapters. It suggests gates: a page interrupts what you are doing, a service asks your age, another asks you to prove it, and perhaps you photograph a document, submit to an age-estimation process, authenticate through a third party or present some credential. The boundary is obvious because crossing it requires an explicit act.

A mature version could feel very different.

Imagine two people sitting beside one another on a sofa. They are using the same model of phone, connected to the same Wi-Fi network, living in the same jurisdiction, and they install the same application from the same app store at roughly the same time. One is an adult; the other is seventeen.

Neither application asks:

HOW OLD ARE YOU?

Neither displays a conventional age gate or asks for a passport. The applications simply open.

For the adult, a particular communication feature is available, recommendations operate under one set of rules, certain content can appear, and perhaps a marketplace function is enabled. For the seventeen-year-old, some of those capabilities are absent or configured differently: a communication function may be restricted, a recommendation feature may operate under different defaults, and particular categories of content may not appear at all.

Same application, same network, same jurisdiction.

Different permitted environment.

The distinction may have been resolved before either person meaningfully interacted with the service. The application requested an assertion from infrastructure already available to the device or account, that infrastructure supplied an answer, and the application evaluated its policy. What each person saw next followed from the result.

Neither user necessarily experienced a gate.

The gate was the environment.

18.1 The Gate Disappears Into The Transaction

We have already seen the technical ingredients. A device can authenticate a principal, a wallet can hold credentials, an operating system or platform can mediate requests for particular assertions, and an application can make access decisions using those assertions without necessarily receiving the underlying evidence from which they were derived.

None of this requires the internet to become a sequence of digital border checkpoints. Quite the reverse: the better integrated the infrastructure becomes, the less each checkpoint needs to resemble one.

In the example above, the application does not necessarily need the adult’s date of birth or the seventeen-year-old’s name. Depending upon the architecture, it may receive something much narrower:

AGE >= 18 = TRUE

or:

AGE >= 16 AND < 18 = TRUE

or some platform-mediated signal sufficient to apply the relevant policy.

The important experiential change is that verification and policy evaluation no longer have to appear as separate events. A visible age gate asks the user a question and waits for an answer; an integrated system can already possess the answer it needs. The environment simply presents itself in the form the policy engine has decided is applicable.

That is a rather different internet from one covered in prove your age buttons.

18.2 The Environment Becomes Conditional

Earlier in this article I described the emerging model as an attribute-mediated web. Chapter 2 expressed the decision roughly as:

principal + verified attributes + jurisdiction + regulation + platform policy = available environment

The two people on the sofa demonstrate what that means. The internet has always contained conditional environments. Websites differ between countries, accounts receive different permissions, subscription tiers expose different functions, administrators see controls ordinary users do not, and recommendation systems already construct different versions of ostensibly shared platforms.

What changes with verified attributes is the quality of some of the inputs. A platform no longer has to infer every relevant characteristic from behaviour, accept every declaration at face value or perform every verification itself. Some propositions can arrive as trusted assertions from elsewhere in the stack, allowing the resulting environment to become conditional before the user meaningfully interacts with it.

That distinguishes permission from personalisation. Personalisation traditionally observes what I do and changes the service in response; attribute mediation can establish a condition first and use it to determine what I am permitted to encounter or perform.

The two can coexist. A service might combine behavioural history, account reputation, location, subscription status and verified attributes in the same decision-making machinery. Some signals will be probabilistic, some will be assertions, some will be derived locally, and others will come from third parties or credentials. Some determine presentation; others determine permission.

The user need not know which is which.

18.3 You Cannot See A Door That Was Never Rendered

This produces a peculiar property of the experience: absence becomes difficult to observe.

Return to the two users. The adult sees a feature; the seventeen-year-old does not. Unless they compare their screens, the younger user may have no reason to know that the capability exists.

A door you are explicitly refused is visible. A door that is never rendered is not.

A feature disabled after an age check is obviously restricted, while a feature that never appears because the application already possesses the information necessary to determine that it should not appear may simply look as though it does not exist. That does not make the decision illegitimate. Many systems already hide functions users cannot exercise, often for perfectly sensible reasons. It does, however, change the phenomenology of permission.

We are accustomed to imagining internet restrictions as interventions in an otherwise common environment: blocked pages, warning screens, login requirements, parental controls and age gates. An attribute-mediated environment can work differently.

Permission can be expressed through the shape of the environment itself.

18.4 Different People Can Inhabit Different Internets

This complicates the familiar idea of internet fragmentation. We usually describe fragmentation territorially: a service behaves differently in Britain, France, China, Australia or the United States because different laws apply; content may be unavailable in one jurisdiction and available in another; features launch selectively; data may be processed differently depending upon location.

Attribute mediation adds another dimension. The two people on the sofa occupy the same territory, yet the same application can legitimately present them with different functional environments because the system possesses different trusted assertions about them.

Age is only the most immediate example. A qualified professional might have access to a function unavailable to the public; a person holding a particular entitlement might encounter a transaction path somebody else never sees; a supervised account might operate under different communication rules from an unsupervised one; and a principal carrying evidence of membership might receive capabilities absent from an otherwise identical account.

The internet therefore becomes less usefully described as a collection of pages or applications that everybody enters and then navigates. In some contexts, it begins to resemble a collection of environments assembled under conditions.

That does not mean every website will demand credentials or every interaction will become conditional. Public information has little reason to require verified attributes merely because the machinery exists. The change matters where policy, law, commercial incentives or risk management make a trusted distinction valuable.

There, the service may cease asking the user to navigate the gate.

The infrastructure navigates it for them.

18.5 Frictionless Does Not Mean Neutral

There are obvious advantages. Repeatedly handing identity documents to unrelated websites is a poor architecture, requiring every service to become competent at identity proofing is wasteful, and asking users to repeat the same verification process across dozens of applications creates unnecessary disclosure as well as terrible usability.

A system in which narrowly scoped assertions can be reused without repeatedly exposing their source evidence can improve on all three. The resulting experience may be considerably less intrusive, but less intrusive does not mean that fewer decisions are being made.

The two people on the sofa may experience almost no verification friction while, underneath that experience, the application evaluates a substantial set of conditions before determining what either person may do. The user experiences convenience; the system experiences policy evaluation. Those descriptions are compatible.

Chapter 14 dealt with the broader paradox this creates, while Chapters 15 and 16 explained why low-friction mechanisms can become attractive to organisations. We do not need to repeat those arguments here. What matters from the user’s perspective is simpler: the more successfully verification disappears into infrastructure, the less conditionality necessarily feels like restriction.

18.6 The Internet Knows Without Necessarily Knowing Who

There is a final ambiguity. A highly attribute-mediated internet does not necessarily require every service to know my civil identity; in a well-designed system, it may know considerably less. A service might establish that I satisfy an age condition without receiving my date of birth, establish an entitlement without learning the evidence used to create it, or recognise the same cryptographic principal across sessions without knowing the legal identity of the person controlling it.

Return once more to our two users. The application does not necessarily need to know either person’s name; it needs sufficient information to decide which environment applies.

The adult application might know:
AGE >= 18 = TRUE (over-18s)

The younger application might know:
AGE >= 16 AND < 18 = TRUE (16–17-year-olds only)

From the application’s perspective, that may be enough.

Yet consider the system as a whole. Devices authenticate principals, wallets hold credentials, issuers establish propositions, applications request them, policy engines evaluate them, and services alter their behaviour according to the results.

No individual application necessarily receives a dossier. Perhaps nobody asks for a name. And yet verified facts about people have become routine inputs into software behaviour.

Whether that is desirable depends upon which facts can be requested, who may request them, whether presentations can be correlated, what happens when somebody refuses, whether unverified participation remains possible, and whether any relationship between the credential and civil identity is actually necessary. Those questions do not disappear because the user experience is good; good user experience may simply make them harder to see.

The post-age-gated internet, if it develops along these lines, may therefore look surprisingly ordinary. Pages load, applications open, messages arrive and transactions complete.

Two people sit beside one another using the same app. Neither encounters a gate; they simply inhabit different permitted environments. Underneath, services ask what may be assumed about each principal, infrastructure answers, and the environment adjusts.

That is what the age gate looks like when the gate itself has disappeared.

19. The Choice Isn’t Identity Or No Identity

There is a danger at this point of turning the argument into a simple opposition between an identified internet and an anonymous one. That would be tidy, but wrong.

Civil identity is necessary in parts of digital life because identity is necessary to the underlying human transaction. Taxation is not merely an interaction with an arbitrary principal. A passport cannot sensibly be issued without establishing whose passport it is. Many legal contracts depend upon identifiable parties, regulated financial activities can create statutory identification obligations, and government entitlements may depend upon a particular person’s legal status or circumstances. Removing identity from those transactions would not produce a more elegant architecture. It would remove information the transaction actually requires.

The question is therefore not whether the internet should have identity. It is where identity belongs.

19.1 Scope Is The Architectural Question

The Principle of Minimum Identity provides a way of drawing that boundary: start with the requirement of the transaction rather than the availability of an identity mechanism.

Sometimes the requirement really is:

WHO IS THIS PERSON?

Sometimes it is:

IS THIS THE SAME PRINCIPAL AS BEFORE?

Sometimes:

IS THIS PRINCIPAL PERMITTED TO PERFORM THIS OPERATION?

Or:

DOES THIS PRINCIPAL SATISFY THE CONDITION REQUIRED HERE?

Those questions can lead to different architectures because they ask different things. The difficulty is that identity can answer several of them indirectly. If I know exactly who you are, I can create an account around that identity, recognise you later, retrieve attributes associated with you, inspect your entitlements and make an authorisation decision. Identity therefore offers an attractive shortcut: identify the human first, then reason from there.

That can be entirely appropriate when the relationship itself requires identification. The problem begins when it becomes the default for relationships that do not. A service needing continuity does not automatically need civil identity. A service needing an age threshold does not automatically need civil identity. A service trying to prevent one human from creating thousands of accounts does not automatically need civil identity, although solving that problem without identity is considerably harder than stating it. A service authorising access to a resource needs sufficient evidence of authority; whether the legal identity of the person exercising that authority forms part of the requirement depends upon the resource and the transaction.

The distinction is between what identity can answer and what the transaction requires it to answer.

19.2 Legitimate Identification Does Not Imply General Identification

Suppose a government establishes my identity in order to issue a credential confirming an entitlement. There may be perfectly sound reasons for the government to know who received it, but it does not follow that every relying service needs to know who I am when I exercise that entitlement. The identification requirement may belong at issuance. The later transaction may require only evidence that a valid entitlement exists.

Similarly, a regulated financial institution may have obligations to establish the identity of its customer. That tells us something about the relationship between that institution and its customer; it tells us little about whether unrelated services should use the same identity binding as their own trust mechanism.

Scope therefore matters at least as much as strength. A strong identity relationship justified in one context does not acquire universal relevance merely because the infrastructure makes it reusable. The fact that a trustworthy identity can be obtained is not itself a reason to obtain it.

19.3 Requirement Is Not Preference

There is another distinction that matters:

WANT TO KNOW WHO THIS IS

is not the same as:

NEED TO IDENTIFY THIS PERSON

Organisations have many reasons to prefer identified users. Identity can simplify fraud investigation and account recovery, make bans more durable, increase confidence in transactions, support analytics and satisfy risk processes designed around identifiable customers. Some of those benefits may be substantial, but usefulness does not automatically constitute necessity.

A system may begin with a legitimate objective such as preventing fraud and choose identification as one available control. That does not establish that identification is the only adequate control, or that the transaction intrinsically requires identity. Perhaps it does. Other mechanisms may be inadequate, disproportionately expensive or incapable of satisfying legal requirements. But that conclusion should be established rather than embedded in the design by default.

The Principle of Minimum Identity becomes meaningless if every organisational preference can redefine itself as necessity. Making identification easy to obtain does not convert preference into requirement.

19.4 Age Revealed The Boundary

Age assurance brought the distinction into view because age occupies an awkward position between person and permission. Age is an attribute of a human being, but the reason for establishing it in the systems examined throughout this series is usually that an age condition changes what a principal may do or what environment a service should provide. That makes age a particularly clear example of the difference between identification and qualification.

A service may need a trustworthy answer to an age-related proposition without needing the identity from which that proposition was established. Once that distinction is visible for age, the broader question becomes difficult to avoid:

What does this transaction actually require?

Not what information might be useful, what happens to be available from the credential infrastructure, or what would make every conceivable future investigation easier. What does the transaction require in order to make the decision it has to make?

Sometimes the answer will be identity; sometimes authentication, authorisation, an attribute or pseudonymous continuity. Sometimes the transaction may need nothing persistent about the human participant at all. The internet contains all of these relationships. There is no architectural reason to force them into one identity model.

19.5 The Boundary Has To Be Designed

None of this produces an easy rule for every system. Real services operate under legal obligations, adversarial pressure, fraud, safeguarding requirements and commercial constraints. Authentication mechanisms fail, credentials are stolen, users lose devices, attackers create synthetic identities, people share accounts, and recovery processes often become the weakest point in otherwise elegant security models. Identity can solve problems that less identifying architectures struggle with. Identity also introduces risks of its own.

The appropriate boundary therefore cannot be derived from an abstract preference for anonymity any more than from an abstract preference for accountability. It has to be designed around the transaction. That means distinguishing among a range of legitimate relationships: anonymous where nothing more is required; pseudonymous where continuity matters; authenticated where control of a principal matters; attribute-bearing where a condition must be established; identified where the transaction genuinely depends upon the person.

The Principle of Minimum Identity tells us where to begin: with the minimum relationship necessary to satisfy the requirement. The Horkan model adds the practical constraint. A suitable architecture may still lose if another mechanism is substantially easier to deploy. Conversely, if scoped identifiers, pseudonymous authentication and minimally disclosed attributes become easier to consume than civil identity, the path of least resistance can reinforce minimum identity rather than undermine it.

The boundary therefore has two dimensions. First, what does the transaction require? Second, have we made the architecture appropriate to that requirement practical enough to deploy?

Neither an identified internet nor an anonymous internet is the objective. The design problem lies between them. The architectural choice is whether we build systems capable of knowing only what they need, and whether we make that boundary deliberate rather than allowing whatever trust mechanism happens to be available to define it for us.

20. After The Age Gate

This series began with a fairly narrow observation. Age assurance was being discussed as though it were a feature: something added to particular websites to keep children away from particular material. Yet implementing that feature at internet scale required services to establish something trustworthy about the person using them before deciding what that person could see or do.

The Age-Gated Internet: Child Safety, Identity Infrastructure, and the Not So Quiet Re-Architecting of the Web therefore asked whether child-safety regulation might become one of the forces driving a broader identity layer for the internet. The Age-Gated Internet Revisited: Identity, Trust and the Architecture of Control asked what happens to trust and control once such infrastructure exists. The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex stepped back again and asked whether the apparent convergence between regulation, platform governance, identity systems and technical architecture required a grand design at all. My conclusion was that it did not.

This fourth article began by asking what lies beyond the age gate. It ended somewhere more specific. The question is no longer simply how we establish age online. It is what kinds of trust infrastructure we are building in order to establish it, what else that infrastructure can establish, and how much identity any of those transactions actually require.

What lies beyond the gate is more interesting than the gate.

20.1 The Question Changed

Age remains the starting point, but it is no longer the whole problem. Once applications can consume trusted assertions about people, age becomes one possible assertion among many. Once operating systems, wallets and platforms can mediate those assertions, verification no longer has to be implemented independently by every website. Once software can make policy decisions against those assertions, the result need not even resemble a visible gate. As Chapter 17 showed, it can simply be a differently configured environment.

That changes the architectural question. It is not enough to ask whether verification can be made private, secure and convenient. We also have to ask what the system should be verifying in the first place.

Jerry Fishenden and Simon Freeman approach that problem from different directions. Fishenden shows how credentials can allow trustworthy claims to move without repeatedly moving the underlying source data. Freeman asks an earlier question: whether civil identity needs to enter the transaction at all. The Horkan model adds a third question: given several mechanisms capable of satisfying the requirement, which one will institutions actually find practical to deploy and defend?

Those are different questions, and keeping them separate is one of the central conclusions of this article.

20.2 Three Models, Three Questions

Fishenden begins with the provisioning and movement of trustworthy claims. If an authoritative organisation already knows something about me, why should another organisation repeatedly acquire the underlying data and reconstruct that knowledge for itself? A credential can allow the relevant proposition to travel without requiring all of its source data to travel with it. Fishenden asks how trust should travel.

Freeman starts earlier. Before deciding how to transport a trustworthy claim, ask whether civil identity is required to establish the thing the service actually needs to know. Authentication, authorisation, continuity, uniqueness and attribute verification are different problems. Identity can sometimes solve them, but that does not make identification a necessary component of each one. Freeman asks how much identity needs to travel.

The Horkan model operates at a different level. Once a requirement exists and several mechanisms could satisfy it, which one is most practical for the implementing institution to deploy and defend? Horkan asks which available mechanism will actually be selected.

Provisioning, necessity and selection are distinct questions, and none of the three models replaces the others. A Fishenden-style credential can carry considerably less information than a conventional database integration while still being unnecessarily bound to civil identity for the transaction in which it is presented. A Freeman-style minimum-identity architecture can be conceptually appropriate yet remain impractical to deploy. The Horkan model can explain which mechanism is selected without telling us whether that mechanism is normatively preferable.

That separation matters because otherwise three different debates collapse into one argument about whether digital identity is good or bad. That is not the useful question.

20.3 Identity Is One Possible Trust Mechanism

We have spent decades improving digital identity: proofing, authentication, federation, credentials, biometrics, fraud detection, recovery and increasingly sophisticated mechanisms for establishing trustworthy claims without revealing all of the underlying information. Much of that work is useful, but improving a mechanism does not establish that the mechanism belongs in every transaction.

The Principle of Minimum Identity therefore starts somewhere else:

establish the proposition the transaction requires, and introduce civil identity only when civil identity itself is necessary.

The internet contains many transactions in which a system needs confidence without needing biography. A service may need continuity without a name, authority without identity, adulthood without a date of birth, entitlement without the evidence from which that entitlement was derived, or evidence that a participant is human without necessarily knowing which human. Other transactions genuinely require identification.

The distinction is not between identity and anonymity. The distinction is between different trust relationships appropriate to different transactions. Civil identity is one of them; it should not become the definition of trust itself.

20.4 The Consequence Of Getting The Boundary Wrong

The consequence of unnecessary identification is not merely that a service learns an additional fact. Identity is unusually persistent. Once bound to accounts, credentials, devices or other principals, it creates relationships that may be difficult to undo. Those relationships can increase correlation across contexts and turn information originally established for one purpose into a useful trust anchor for another.

The opposite mistake also matters. Refusing to use identity where the transaction genuinely depends upon the person can weaken accountability, make fraud harder to control, frustrate legitimate legal obligations and force systems into elaborate substitutes for information they actually require. Minimum identity therefore means minimum necessary identity, not minimum identity at any cost.

That makes scope the central design problem. The architecture should be capable of anonymous interaction where nothing more is required, pseudonymous continuity where persistence matters, strong authentication where control of a principal matters, attribute proofs where a condition matters, and civil identification where the human being’s legal identity is itself material to the transaction. A mature trust architecture should support those distinctions rather than collapse them.

20.5 Privacy Is Necessary But Not Sufficient

This also changes how we should think about privacy-preserving verification. Selective disclosure, unlinkability, scoped identifiers, zero-knowledge techniques and citizen-held credentials can materially improve the architecture. They can reduce unnecessary disclosure, prevent some forms of correlation and allow propositions to be established without distributing the underlying evidence. Those are genuine improvements.

But Chapter 14 identified the limit of treating privacy engineering as the whole answer. A perfectly private proof can still answer a question that should never have been asked.

The relevant test therefore operates at two levels. First: if this proposition legitimately needs to be established, how little should be disclosed in proving it? Before that: does this proposition need to be established at all?

The second question cannot be answered by better cryptography. It is a question of scope, governance and legitimate purpose.

20.6 Then We Have An Engineering Problem

Once the boundary has been chosen, principle has to survive implementation. If a service requires a stable principal rather than a named human, scoped principals need to be ordinary engineering components rather than specialist constructions. If an application needs to establish adulthood, proving the condition without unnecessarily disclosing identity needs to work reliably. If uniqueness rather than identity is required, appropriate proof-of-personhood mechanisms need to be capable of meeting the relevant assurance standard.

Recovery has to work. Revocation has to work. Fraud controls have to work. The user experience has to work. Organisations operating under regulation need to be able to demonstrate that these mechanisms satisfy their obligations.

The Principle of Minimum Identity cannot remain solely a principle about what systems ought to know; it has to become something systems can readily build. That is partly an engineering challenge and partly an institutional one. Standards, platforms, procurement, liability, certification and regulatory acceptance all affect whether a theoretically available architecture is a practically usable one.

If we want systems to establish only what they need, the mechanisms for doing so have to survive contact with production.

20.7 Beyond The Age-Gated Internet

The title of this series may eventually become obsolete. If age assurance remains a specialised control applied to a bounded class of services, then the broader thesis will have been overstated. That remains a plausible outcome. But if infrastructure developed around age becomes part of a more general mechanism through which services obtain trustworthy propositions about their users, then age-gated will describe the origin of the transition better than its destination.

Age may simply have been the first widely deployed question. The more consequential development would be infrastructure capable of supplying trustworthy answers about the person, principal or device on the other side of a transaction, combined with software capable of changing what happens according to those answers.

That infrastructure does not have to produce one kind of internet. It can support persistent identification or pseudonymity, extensive disclosure or selective disclosure, centralised identity or citizen-held credentials, universal accounts or scoped principals. It can establish who somebody is or deliberately avoid doing so. The technology does not settle those choices.

Fishenden shows how trustworthy claims can travel without repeatedly moving the underlying source data. Freeman asks whether civil identity needs to travel with those claims at all. The Horkan model asks which available mechanism institutions will actually find practical to deploy and defend. The Principle of Minimum Identity provides the constraint connecting them: establish no more about the human participant than the transaction actually requires.

That leaves a question larger than age assurance:

Why should identity be the trust layer of the internet?

In some places, it should. Taxation, passport issuance and other transactions can legitimately depend upon knowing who somebody is. Elsewhere, perhaps the better question is not how to construct ever more sophisticated infrastructure for proving who we are, but how to construct equally sophisticated infrastructure that does not need to know.

We will need both, and the architectural task is to decide deliberately where each belongs. The age gate may have started the question; what matters beyond it is the boundary we choose to build.

Appendices

Appendix A: The Argument at a Glance

The table below provides a concise map of the article, showing how the argument develops from the changing age-assurance landscape through to the Principle of Minimum Identity and the question of where identity belongs in the internet’s trust architecture.

Chapter	Focus	Précis
1. Introduction	Framing	Fishenden’s argument and the changed political landscape provide the starting point for asking what comes after the age gate.
2. Catching Up	What changed	Government changed and Digital ID was cancelled, but the underlying demand for trusted age, identity and entitlement signals continued.
3. After The Age Gate	Configuration	Age assurance moves from a visible gate towards attributes that configure what a user can see and do.
4. Age To Attribute Verification	Reuse	Once trusted-attribute infrastructure exists, other propositions become cheaper and easier to verify.
5. Websites To Operating Systems	Stack movement	Verification and policy enforcement move down the stack towards platforms, operating systems and devices.
6. Multiple Environments	Conditionality	The same service can present different permitted environments according to attributes, jurisdiction and policy.
7. The Synthetic Internet	Authenticity	AI makes synthetic participation cheap, increasing the value of provenance, continuity, uniqueness and trustworthy assertions.
8. Jerry Fishenden	Credentials	Citizen-held credentials can prove trustworthy facts without repeatedly distributing the underlying personal data.
9. Citizen-Centric According To Whom?	Governance	Holding a credential does not determine who defines the rules, what must be proved or what happens when proof is refused.
10. Simon Freeman	Necessity	Identification, authentication, authorisation and attribute verification are different problems; identity is not always required.
11. Identity As An Asset	Exposure	Civil identity is valuable, persistent and often non-rotatable, making unnecessary disclosure and correlation consequential.
12. Opening An App	Application	Ask what the transaction actually needs to establish rather than reaching automatically for civil identity.
13. Three Architectures	Trust models	Identity-mediated, credential-mediated and principal-mediated architectures introduce identity at different points in the trust chain.
14. Minimum Identity	Principle	Establish no more about the human participant than is necessary to authorise the transaction.
15. The Verification Paradox	Privacy	Less disclosure per verification can make verification easier and therefore substantially more pervasive.
16. Path Of Least Resistance	Selection pressure	Regulation, installed infrastructure and implementation cost influence which technically adequate architecture gets deployed.
17. The Horkan Model	Selection model	Institutions tend towards the satisfactory mechanism that is easiest to deploy, operate, audit and defend.
18. What It Feels Like	Experience	Verification can disappear from view while applications silently construct different permitted environments for different users.
19. Identity Or No Identity	Scope	The choice is not identity versus anonymity, but where civil identity is actually necessary to the transaction.
20. After The Age Gate	Synthesis	Fishenden asks how trust travels, Freeman how much identity must travel, and the Horkan model which architecture gets selected.

Appendix B: References

1. Horkan, Wayne, “The Age-Gated Internet: Child Safety, Identity Infrastructure, and the Not So Quiet Re-Architecting of the Web”, Horkan, 20 March 2026.
   https://horkan.com/2026/03/20/the-age-gated-internet-child-safety-identity-infrastructure-and-the-not-so-quiet-re-architecting-of-the-web
2. Horkan, Wayne, “The Age-Gated Internet Revisited: Identity, Trust and the Architecture of Control”, Horkan, 3 May 2026.
   https://horkan.com/2026/05/03/the-age-gated-internet-revisited-identity-trust-and-the-architecture-of-control
3. Horkan, Wayne, “The Age-Gated Internet Re-Revisited: Beyond the Censorship Industrial Complex”, Horkan, 17 July 2026.
   https://horkan.com/2026/07/17/the-age-gated-internet-re-revisited-beyond-the-censorship-industrial-complex
4. UK Government, “Prime Minister”, GOV.UK, current ministerial record. Records Andy Burnham becoming Prime Minister on 20 July 2026.
   https://www.gov.uk/government/ministers/prime-minister
5. Cabinet Office, “Machinery of Government changes: Fact Sheet”, GOV.UK, 22 July 2026, updated 27 July 2026. Primary source for the abolition and redistribution of Department for Science, Innovation and Technology functions and the reallocation of digital, AI, science and related responsibilities.
   https://www.gov.uk/government/news/machinery-of-government-changes-fact-sheet
6. UK Government, “Minister of State (Minister for Artificial Intelligence)”, GOV.UK. Documents the joint departmental ministerial structure and responsibilities relating to AI strategy, the AI Taskforce, the AI Security Institute and public-sector AI adoption.
   https://www.gov.uk/government/ministers/minister-of-state-minister-for-artificial-intelligence
7. Prime Minister’s Office, HM Treasury and Department for Energy Security and Net Zero, “New PM cuts tax on household electricity bills to give breathing space on cost of living”, GOV.UK, 21 July 2026. Records the cancellation of the previous Digital ID programme and the reallocation of funding towards the reduction in household electricity costs.
   https://www.gov.uk/government/news/new-pm-cuts-tax-on-household-electricity-bills-to-give-breathing-space-on-cost-of-living
8. Ofcom, “Use of Age Assurance Report 2026”, 15 July 2026, updated 27 July 2026. Report on evidence from the first six months of the Online Safety Act protection-of-children duties and the deployment and effectiveness of age-assurance measures.
   https://www.ofcom.org.uk/online-safety/protecting-children/use-of-age-assurance-report-2026
9. UK Government, “Fact sheet: New rules to protect children online”, GOV.UK, originally published 15 June 2026, updated 18 September 2026. Government position on restrictions applying to social-media services for children under 16 and additional protections for children and young people.
   https://www.gov.uk/government/publications/fact-sheet-new-rules-to-protect-children-online/fact-sheet-new-rules-to-protect-children-online
10. UK Government, “Growing up in the online world: government response (July 2026)”, GOV.UK, July 2026. Government response covering the intended implementation of age-dependent online protections, including measures affecting 16- and 17-year-olds.
    https://www.gov.uk/government/consultations/growing-up-in-the-online-world-a-national-consultation/outcome/growing-up-in-the-online-world-government-response-july-2026
11. Department for Science, Innovation and Technology, “New social media curfews and crackdown on addictive features to better protect 16- and 17-year-olds online”, GOV.UK, 15 July 2026. Source for proposed overnight restrictions, notification controls, autoplay defaults and personalised recommendation settings for 16- and 17-year-olds.
    https://www.gov.uk/government/news/new-social-media-curfews-and-crackdown-on-addictive-features-to-better-protect-16-and-17-year-olds-online
12. Department for Digital, Culture, Media and Sport, “UK to have world’s strongest online child safety laws as government prepares legislation on nude images”, GOV.UK, 9 September 2026. Source for proposed device- and platform-level requirements concerning under-18s taking, viewing or sending nude images.
    https://www.gov.uk/government/news/uk-to-have-worlds-strongest-online-child-safety-laws-as-government-prepares-legislation-on-nude-images
13. Apple Inc., “Requesting People’s Age Range Information in Your App”, Apple Developer Documentation, accessed September 2026. Describes the Declared Age Range framework, application-specified age gates, age-range responses, regional regulatory behaviour and mechanisms by which an age declaration may have been established.
    https://developer.apple.com/documentation/declaredagerange/requesting-people-share-their-age-range-with-your-app
14. Apple Inc., “Declared Age Range”, Apple Developer Documentation, accessed September 2026. Framework documentation for requesting age-range information and receiving age-range declarations.
    https://developer.apple.com/documentation/DeclaredAgeRange
15. Apple Inc., “Age Assurance Frameworks Q&A”, Apple Developer Support, accessed September 2026. Describes the responsibilities of application developers and the operation of Apple’s age-assurance mechanisms across regulatory environments.
    https://developer.apple.com/support/age-assurance/
16. Google LLC, “Request Age Signals”, Android Developers / Google Play Age Signals, accessed September 2026. Describes the Play Age Signals API, including shared, not-shared and verification-required states and differences between voluntary and legally mandated age-signal sharing.
    https://developer.android.com/google/play/age-signals/request-age-signals
17. Apple Inc., “AgeRangeService”, Apple Developer Documentation, accessed September 2026. Documents regulatory features associated with Declared Age Range, including circumstances in which an age range is required to be shared with an application.
    https://developer.apple.com/documentation/declaredagerange/agerangeservice
18. Fishenden, Jerry, “What went wrong with data in government — and how do we fix it?”, New tech observations from the UK, 25 September 2026. Discussion of persistent government data problems and a citizen-centred model in which organisations issue credentials and citizens present proofs rather than government repeatedly moving underlying personal data between organisations.
    https://ntouk.wordpress.com/2026/09/25/what-went-wrong-with-data-in-government-and-how-do-we-fix-it/
19. Freeman, Simon, personal communication with the author, September 2026. Discussion concerning the architectural distinction between identification, authentication and authorisation; the use of identity as a high-value trust anchor; and whether civil identity is necessary for routine authentication and authorisation transactions.
20. National Institute of Standards and Technology, NIST SP 800-63-4: Digital Identity Guidelines, July 2025. Defines the distinct functions and assurance requirements associated with identity proofing, authentication and federation in digital systems.
    https://csrc.nist.gov/pubs/sp/800/63/4/final
21. National Institute of Standards and Technology, NIST SP 800-63A-4: Digital Identity Guidelines — Identity Proofing and Enrollment, July 2025. Defines identity proofing as a distinct process through which evidence is used to establish an applicant’s identity at an appropriate assurance level.
    https://csrc.nist.gov/pubs/sp/800/63/A/4/final
22. FIDO Alliance, “User Authentication Specifications Overview”, FIDO Alliance. Describes FIDO2, WebAuthn, CTAP and passkey-based authentication using service-bound public-key cryptography rather than reusable shared secrets, including privacy properties intended to prevent cross-service correlation.
    https://fidoalliance.org/specifications/
23. World Wide Web Consortium, Verifiable Credentials Data Model v2.0, W3C Recommendation, 15 May 2025. Defines a standard model for cryptographically secure, privacy-respecting and machine-verifiable digital credentials.
    https://www.w3.org/TR/vc-data-model-2.0/
24. World Wide Web Consortium, Bitstring Status List v1.0, W3C Recommendation, 15 May 2025. Defines a privacy-preserving mechanism for communicating credential status, including suspension and revocation, without requiring a separate identifying status endpoint for each credential.
    https://www.w3.org/TR/vc-bitstring-status-list/
25. OpenID Foundation, OpenID for Verifiable Presentations 1.0, Final Specification, 9 July 2025. Defines a protocol for requesting and presenting digital credentials, including W3C Verifiable Credentials and other credential formats.
    https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
26. Information Commissioner’s Office, “Principle (c): Data minimisation”, ICO. UK data-protection guidance explaining the requirement that personal data be adequate, relevant and limited to what is necessary for the specified purpose.
    https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/
27. National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture, NIST. Defines zero-trust architecture around explicit evaluation of access rather than implicit trust inherited from network location or a broad trusted perimeter.
    https://csrc.nist.gov/pubs/sp/800/207/final
28. Horkan, Wayne, “Remembering Kim Cameron: The Man Who Changed Identity”, Horkan, 19 February 2026. Discussion of Cameron’s Seven Laws of Identity, user-centric identity, minimum disclosure, identity metasystems and their relationship to the Government Gateway and subsequent identity architectures.
    https://horkan.com/2026/02/19/remembering-kim-cameron-the-man-who-changed-identity