Age Verification Done Right: Privacy & Interoperability Frameworks

November 19, 2024

Privado ID Solutions

Age verification has rapidly emerged as a critical topic on the Internet, triggered by a pressing wave in global regulations aimed at protecting minors online.

This article digests how decentralized, privacy-preserving age verification systems can be built without compromising user privacy:

The Need for Privacy-Preserving Age Verification: As countries implement stricter laws to prevent minors accessing adult content, gambling, and potentially harmful social networks, the need for privacy-preserving age verification systems has never been greater.
Challenges of Centralized Age Verification: Relying on large tech providers for verification poses risks like tracking and cross-application tracking, which jeopardizes privacy and limits user control over their data.
Decentralized and Interoperable Age Verification: Solutions like decentralized identity systems, zero-knowledge proofs, and nullified DIDs enable secure, user-controlled age verification that preserves privacy across different apps.

Why Is Age Verification a Hot Topic Now?

Over the last year, several countries have introduced guidelines, regulations and proofs of concept around age verification for digital service providers. Some examples are:

America: Several USA states, including Arkansas, Texas, Louisiana, Utah, and California, have passed laws requiring stricter age verification measures, particularly for accessing adult content or opening social media accounts. Kids Online Safety Act (KOSA)–scheduled for 2024– is a federal bill that seeks to enforce stricter rules on social media and other platforms, requiring age verification for minors and regular audits of the system's effectiveness.
Europe: UK (Online Safety Act), Spain, France and Italy are leading the national initiatives, while the EU prepares a standard for age verification under its Better Internet for Kids strategy, expected to be formalized by 2024. The EU has also opened a tender for Age Verification solutions in order to equip the member states with a white-label solution that can be easily adopted in each country.

Although these regulations can be seen as a response to concerns about the early access to porn, gambling and other hazardous online activities, access to social networks (whether cyber bullying, synthetic porn and other toxic dynamics) are increasing the mental health issues in the youth.

This means that we will see age verification controls not only in porn and gambling, but as another needed step just to browse the internet (social networks, app stores, content providers and even operating systems)

The 5 Challenges of Digital Age Verification

Internet freedom activists such as EEF, Internet Society and EDRi are challenging the need for these controls and have expressed their concerns about how this is just another excuse to remove our privacy rights and how it could marginalize certain groups of our population from the access to information.

Most of the criticism focuses on 5 areas:

Accuracy and Reliability

Developing systems that accurately verify age without being easily circumvented is challenging. There's a constant arms race between verification technologies and methods to bypass them.

There are inherent limitations in current technologies, such as facial recognition and document verification, including issues with accuracy across diverse demographics and the potential for spoofing.

Regulatory Compliance

The industry must navigate a complex landscape of global and local regulations, including data protection laws like GDPR in Europe and COPPA in the United States, which dictate how personal information can be collected, stored, and used.

Accessibility

Ensuring that age verification solutions are accessible to all users, including those with disabilities or those without access to traditional forms of ID, is a significant challenge.

Privacy

Ensuring the privacy and security of personal information is paramount. Users are often hesitant to share sensitive data, such as government-issued ID details, due to fears of data breaches and misuse.

Interoperability

The lack of a standardized approach to age verification across different countries and industries complicates the development of universal solutions.

A Solution with Multiple Actors

For the scale we are discussing in this article (world-wide ecosystems of trust), the problem of Age Verification can’t be (and shouldn’t be) solved by a single actor.

Putting this in the hands of few tech giants like Google and Apple (that could just embed this verification into their operating systems and act as a single provider) is a bad idea for the same reasons we mentioned before (privacy, accessibility) but also from a political and strategic point of view –no single company should regulate our access to information at their discretion.

The alternative is an open ecosystem of trust where multiple credential providers (the companies verifying your age) can provide their services by adopting clear rules defined by the governing bodies of that ecosystem of trust and implementing well-known standards in digital identity systems that guarantee the user right to privacy and consent.

Each actor plays a different role in this solution:

Credential providers are responsible for the accuracy and reliability of their attestations, that must be compliant to the applicable regulations and accessible to all citizens.
Digital Identity Systems act as the communication channel between the credential provider and the relying party (the company asking for the verification proof) and they are responsible to guard the user privacy and to facilitate the interoperability across the ecosystem.
The governing bodies of the ecosystem (i.e. the European Union) will define and enforce the rules of the ecosystem (who is an authorized provider of credentials, what attestations methods are accepted, what credentials must be accepted, etc.)

Governments can also play the role of credential providers. The digitalization of our national ID creates an easy way to get age credentials directly from the government –but also removes the possibility for an open market of private business initiatives around age verification. eIDAS has faced some criticism for not making clear what will be the role of the private sector in the economy of credentials.

In this article, we will focus on the 2 challenges that must be solved by the digital identity systems: privacy and interoperability.

When Privacy Matters The Most

Although all these challenges are equally important, privacy is probably the biggest concern and blocker for adoption in this type of verifications.

There are several reasons why privacy is crucial in age verification –some are obvious, some are more subtle:

Adults don’t want to share the use of this type of credentials: It’s not the content of the credential what is so important (although a lot of people would not want to publicly disclose their date of birth) –it is to whom I presented that credential. Age verification is only required when the regulators have made it mandatory, and that’s adult content, gambling and other activities that people don’t want attached to their identities.
Adults don’t want to share that they own a credential like this. For the same reason mentioned above, if only people that want to have access to adult content sites need to have age verification credentials, these credentials get a bad reputation. Why do you need to have that installed in your phone? Why do you need to pay an age verification provider?
Governments don’t want this to become another profiling tool: As described in the excellent guide published by the Spanish Agency for Data Protection Decalogue of principles Age verification and protection of minors from inappropriate content: “The system must guarantee the non-linking of a user's activity across different services” (Principle 7).
Nobody wants centralized databases or systems that can become a resource to identify minors on the Internet.

This creates a very interesting set of privacy requirements, where the information shared (What) is not as sensitive as how it is obtained, stored and shared (How).

This “how” involves all the checks and verifications required for a user to prove to a verifier that he/she is the rightful owner of a credential that satisfies the verifier query (Age >18). We can see all the verifications required in the following illustration:

The Good, The Bad and The Ugly in Credentials Verification

Obtaining Credentials

There are 2 privacy-related design decisions to be made in this step:

The assessment mechanism to determine the age of the user
The identifier to which the credential will be attached to (”issued to”)

For the first, there seems to be a growing consensus in the industry on-going for doing the verification on the user device instead of sending the user information (national documents, biometrics) through the network to a server. An example of this are providers like privately.eu, outdid.io, regulaforensics.com. This is clearly the most privacy preserving option and the preferred by the regulators.

For the second, the challenge with identifiers is that they can be tracked across multiple applications and doxxed (linked to real world identities). For example, imagine that your credentials are linked to your e-mail address or to your phone number –how easy would it be to know which adult sites you visited and to link that to your persona?

The good-enough solution would be to link the age credential to your DID (decentralized identifier) –this identifier is not linked to any social public profile, but it can still be used to track you across applications (and it also can be doxxed).

The best solution is a nullified DID (like the Profiles feature included in PrivadoID) that would create a single-use DID for each issuer and verifier. This way, you can still prove that you are the rightful owner of the credential without disclosing your permanent DID.

Although the technical implementation of Nullified DID is a bit complex, it’s easy to understand how they work:

The Identity wallet managed the permanent DID –the original DID that was created from the private user keys, also called the Genesis DID. This is the one we want to keep private.
On every interaction (issuer or verifier), a nullified DID is created. This nullified DID is cryptographically derived from the genesis DID (in a process similar to a hash function)
When the user receives credentials, they are received on a Nullified DID. When the user presents credentials, they are presented by a nullified DID + Linked DID Zero Knowledge Proof. This ZKP is a cryptographically verifiable proof that the user is in control of a Genesis DID that can originate the nullified DID –without disclosing that genesis DID.

The benefit is obvious –it’s impossible to track this user across applications, and even if a nullified DID is doxxed (linked to your real world identity), that will only provide information on the context of one application (it won’t reveal your entire history). Also, any data breach on the issuer would not compromise you in the context of other applications.

Storing Credentials

If privacy is the only concern, then the obvious answer is to store the credentials on the user’s device, especially if the credentials are generated locally. But privacy is not the only requirement here –user experience and low friction verification processes are also an important aspect for the mass adoption of these solutions.

From an user experience perspective, the ideal scenario would be “set it and forget it”: pass the verification process once and be free to reuse that verification seamlessly across all applications and devices. Isolating the credentials to one device implies that the process has to be repeated several times across all user devices. It also puts the custody responsibility of the credential on the user (backup & recovery).

The next best thing in terms of privacy is storing the credentials outside the device (e.g. in the Cloud) in a way that the credential information is only readable in the device. This allows for a multidevice experience and keeps the information only visible to the user.

To achieve this most identity solutions that rely on external storage encrypt the credential using the user's private keys (e.g. the same keys used to create the genesis DID). The credential information is stored encrypted and can only be decrypted by the identity client (on device) that holds the private keys.

Privado ID follows this pattern. In its current implementation of the Web Wallet, a message signed with the user crypto wallet is used to generate and derive all the necessary keys (for DID creation and storage encryption), as follows:

Presenting Credentials

We can divide the presentation of credentials to a verifier in 2 major blocks:

Presenting a valid credential (issued by a trusted issuer, not revoked or expired, following the right schema),
Satisfying the query presented by the verifier (meets the criteria). I could have a valid credential stating that I was born on January 1st 2020 (valid) that doesn’t satisfy the query presented by the verifier (Age > 18).

For the first part, the privacy challenges come from the level of issuer involvement needed for the credential to be accepted as valid.

Is the issuer involvement needed in order to:

Proof the credential provenance?
Access the credential data?
Proof the “non-revoked” status of the credential?
Generate the Zero Knowledge proof of the credential?

For a privacy preserving credential presentation, the answer to all these questions should be NO. The issuer should not be aware of when, how or where a credential is being used –especially in a Age-Verification context, where the age verification provider could track the activity of the user across all verifiers.

The best combination of answers the the four previous questions are:

Credential Provenance: Proven through Issuer signature (PKI).
Credential data: Offered by the identity wallet (local or external encrypted storage).
Non-revocation: Private on-chain revocation registries (only accessible by the user and presented as proof of non-revocation to the verifier).
Zero Knowledge proof generation on the identity client (user device).

Last, but not least, there is the topic of Schemas. Schemas are files that contain the “structure” of the credential, and are needed for the verifier to understand the format and semantic of the credential. These schemas must be hosted somewhere where they are publicly accessible for all parties (issuers, verifiers and identity wallets).

The challenge here is that every time the schema is used, the downloading of that file could leave a trace –especially in the case of identity wallets. The best way to prevent this is to treat these files as a public good, beyond the control of any single organization. For that, Privado ID offers the Schema Repository, based on IPFS. Schemas hosted on IPFS are out of the control of any single organization.

For the second part (satisfying the query), the privacy risks come from oversharing (sharing more information that is strictly required).

There are 3 levels of “disclosure” in sharing a credential:

Full Disclosure: sharing the entire content of the credential (e.g. all the fields in your national ID)
Selective Disclosure: sharing some specific fields (e.g. your birth date)
Zero Knowledge Proof: sharing a cryptographic proof that you can hold a credential which information can satisfy the query (e.g. ZK proof that you are over 18 years old)

There are no questions here –privacy preserving Age Verification needs to implement Zero Knowledge proofs, the only question is how. There are 3 approaches to this:

Server side, dynamic ZK generation: When a hosted web wallet is used (provided by a wallet provider or by the credential issuer itself), the proof can be generated “on the fly” to satisfy different queries (over 18, over 21, over 25). The problem is obvious –to generate the proof the server needs to have access to the credential information (at least until Full Homomorphic Encryption matures enough to be feasible at mass-scale). This approach is non-compatible with client-side credential generation, so a step backwards in terms of privacy for Age Verification.
Client Side, static proofs: When the credential is created, a number of pre-defined ZK proofs (over 18, over 21, etc.) are generated. This approach is better than the previous one since both the credential and the proofs can be generated in the device. It’s not very flexible since the proofs are pre-defined, but it could be “good enough” for the specific case of age verification (where few proofs could solve all queries about age).
Client side, dynamic proofs: This is the best possible implementation, where the proofs are generated on the client side “on the fly”, providing both privacy and flexibility. This is what Privado ID offers.

Interoperability in an Open Ecosystem

More Important That it Seems

When it comes to age verification, privacy is the topic of choice for most regulators and credential providers. The challenges are clearly defined and there are a number of solutions and implementations that can be combined to offer the needed levels of privacy (as presented above).

Interoperability seems in comparison a “nice to have” property for these solutions, but that would be a deadly mistake for the entire age verification industry.

Age Verification providers are under the constant menace of being disrupted by the big tech companies that already dominate the user browsing experience –Google, Apple, Meta, Microsoft. Any of these players could add age verification to their user accounts and offer that as a service for any application that uses their social logins –sign in with Google to prove your age!

There are very good reasons to avoid that scenario (especially from a privacy point of view) –but the threat is real– both for the industry of credential providers and for the users and regulators trying to preserve their data sovereignty and privacy. And who gets to decide which side wins? As usual –the user convenience.

These big players can easily create the “set it and forget it” solution –one single verification that opens all doors at once, across all devices and with minimum friction. If the alternative offered by the credential providers is “pass the process in every single application and every single device, with different experiences and outcomes”, then the decision for the user is easy.

It’s in our society's interest to foster an open ecosystem of competing credential providers that work to improve the accuracy, accessibility and reliability of their methods and have a business model that doesn’t consist of selling the user data. But the industry needs to create the same “set it and forget it” experience. And that is a complex task that requires standards, consensus and governance.

How Does Interoperability Look Like?

Interoperability can be achieved with a single global issuer (if all credentials are issued by one or very few issuers, then it is easy to ensure credentials are compatible or that verifiers will accept multiple credential formats) –but that’s not the goal. Our goal is to achieve interoperability in an open, dynamic ecosystem of issuers and verifiers.

From a user perspective, looks like this:

I obtain a credential that allows me to prove my age in any given provider (chosen by me or by the verifier).
I can use the same credential in any other verifier. I will not have to pass the verification again, since all verifiers accept the credential (even if they are not directly working with that issuer)

From an Issuer point of view:

When I join the ecosystem, my credentials are automatically accepted by any verifier in the ecosystem (all the time I follow the rules)
I will be fairly compensated for every use of the credential that I have issued (reusability doesn’t play against me) –I will get paid by verifiers that have never contacted me (permissionless use).

From a Verifier point of view:

I can use credentials from any issuer that meets minimum standards of trust (as defined by a trusted organization overseeing the ecosystem).
I don’t need to keep track of all the trusted issuers –I can benefit from all issuers.
I don’t need to establish a business relationship to every single issuer in order to use and pay for the verification

Architecture of an Open Ecosystem of Interoperable Credentials

An open ecosystem where N number of providers can deliver reusable credentials to be used in a M number of applications, where N and M will grow organically over time.

The first step to meet this requirement is to standardize the components of a Self Sovereign Identity:

Identifiers: as we discussed, nullified DID are the best option for this.
Credential Types (Schemas): The industry must push for an standard credential schema (as Privado ID is doing for the standardization of the KYC schema across the Privado ID ecosystem of issuers)
Verifiable Presentation: We want to follow the Verifiable Credentials standards. We will choose a verifiable presentation that is ZK-friendly (allows for efficient generation of ZK proof on the client side). The iden3 protocol can provide this.
Credential Exchange Protocol: We want the flexibility of ZK proofs generated on the fly on the client side –iden3 can provide this.

This would allow for any credential issued by the credentials providers to be consumed by any application. It solves the technical interoperability of the ecosystem, but it doesn’t make it economically sustainable, compliant or easy to use by the end user.

For these challenges we need to add some infrastructure services like

Permissionless Payment Rails: That will allow any verifier to pay for the use/reuse of the credential to its original issuer in a “self-service” way (without creating offline 1:1 relationships with each issuer in the ecosystem). I can pay you even if we haven’t done business before.
Trust Registry: A public registry of the issuers that can be trusted according to certain criteria (compliant in my region, with a certain level of assurance, with certain methods of attestation, etc.) This is a governance tool that will be managed by industry associations and that allows the verifier to trust “any issuer that meets this criteria” instead of being forced to manually pick a list of issuers. How to get in the registry and continue there is a big part of the ecosystem governance.
Identity Client (aka the identity wallet): The identity wallet is crucial for a frictionless user experience. Besides any privacy and security requirements, it should follow some UX design principles such as:some text
- Minimum requirements for onboarding (e.g. zero-install, use existing authenticators, free to use).
- In-app issuance (all providers follow a protocol to offer their credentials through the wallet in a way that the user experience is always consistent and focused in one app).
- Multidevice (I can access from any device and use my credentials from there).
Custodial Key Management We need private keys to manage DID, to encrypt the user credentials in the storage and other operations, but most users don’t want the responsibility of keeping their keys in custody. For real mass adoption, we need to support keyless authentication methods (like Sign in with Google, Apple, etc.) For this reason, the solution has to integrate some key custody component (e.g. HSM or MPC networks).

Here we lay out all the components of the architecture (in purple the solution offered by Privado ID):

Given these components, any application could easily benefit from the entire ecosystem of issuers and from all the past issued credentials. The question (query) to the user identity wallet would look like this:

I need a ZK proof that you are over 18 years old that is based on a credential following the schema “AgeVerification_v1” and signed by any issuer that is included in the trust registry as compliant in the EU. If you don’t have such credential, my preferred issuer is “Privately” and here is the payment token for the issuer (that will pay for your credential issuance).

From a user point of view, the experience would look like this (including the first time issuance and the reuse of the same credential in a different application)

Unsolved Problems

Parental Control & Delegated Consent

In the debate about an “Age aware” Internet, age verification is just one side of the story. Age Verification is (should be) the mechanism to make sure that only adults can access certain services and content. It is not intended to track or identify minors, just to exclude them from certain areas of the Internet.

But what about the services and content that is intended for minors but needs parental approval? Most countries define an “age of consent”, where a minor needs to be at least of a certain age to consent to the terms of use of that service. In some cases, the parental consent (or refusal) has to be taken into account.

Managing parental consent is a different and complex topic that needs to take into account multiple challenges:

How to verify the relationship between minors and parents or responsible adults.
The different legal and familiar circumstances (parents in jail, abusing parents, legal custodians, etc.).
How to implement the parental controls in an interoperable way across services.

Most of these challenges are not technological in nature and won’t be solved by technology –an interoperable ecosystem of credentials could be a good foundation layer, but this is a challenge that requires clear regulations and perhaps a public debate on the consequences of implementing these controls.

In Summary

Age Verification is a fast-growing industry with a thriving ecosystem of age verification providers. We have seen innovation efforts in the development of new assessment mechanisms that can offer accuracy and reliability in the era of deepfakes and AI but the full-scale adoption of an Age-aware Internet requires a stronger focus on how these credentials are shared after they have been created.

We presented an architecture for a privacy-preserving and interoperable ecosystem of credentials that can meet regulatory requirements and allow the industry to compete with technology giants such as Google and Apple in delivering a “set it and forget it” experience for age verification.

The technology exists –the next is to work with industry leaders (such as avpassociation.com, euconsent.eu) to rally the key players of the industry to adopt them.

What’s Next?

‍

Share this post