Online age verification the German eID way🔗

Age checks are coming if you want them or not...🔗

Governments are pushing online platforms to get serious about age verification.

The idea sounds noble at first: "protect the children" from harmful content and online dangers.

The problem is not asking whether someone is old enough. The problem is that most implementations answer this tiny question by identifying the whole person.

And in a fragmented landscape like the internet, spanning multiple jurisdictions, platforms and technologies, this quickly becomes a privacy nightmare.

Think of the children
Think of the children

In the EU there currently is a push for the EU age-verification solution and, in parallel, for the EUDI Wallet. Both should eventually provide mechanisms for online age verification.

But they are still being rolled out and most online services currently have to rely on existing techniques.

The bad trade-off: prove your age by revealing your whole identity🔗

Some services use an indirect method by asking the user to link a bank account or credit card. They then outsource the age check to the financial institution's existing KYC process.

If you buy some "online bucks" for your favourite game, one could argue there already is a business relationship and more information has to flow anyway.

But a lot of online services need no payment method at all. Think messenger apps, social-media platforms or online forums.

These services often rely on third-party age-verification providers:

Upload your ID card, let a third-party company identify you, and receive some reusable "this person is an adult" account marker.

Usually these providers require uploading complete official identification documents, recording a video of the user's face or letting some AI take an "age guess" from a photo.

All of that to answer a yes or no question.

Privacy nightmare
Privacy nightmare

There is a proverb in German: "Wo ein Trog ist, da sammeln sich die Schweine."

Roughly translated: "Where there is a trough, the pigs will gather."

It gained a bit of popularity during the German debate about Vorratsdatenspeicherung, aka mass data retention. And it fits this situation surprisingly well.

Imagine you want to use $FavoriteOnlineService, but it requires age verification through "AgeVerify Company X".

AgeVerify Company X asks you nicely to upload your government-issued ID. It only needs the birthdate, but it now got your:

  • Full name
  • Date of birth
  • Government-issued ID number
  • Address, depending on the document
  • A photo of your face
  • Whatever else happens to be printed on the ID

You can see this is a pretty well-filled trough for the pigs to come.

It seems to taste better...
It seems to taste better...

$FavoriteOnlineService might honestly promise to never misuse your data. That promise does not stop the "AgeVerify Company X" from being hacked, sold or simply changing its mind later.

And who says that your data won't be misused or sold to other parties without your consent and even that the $FavoriteOnlineService itself won't have access to it?

Since in the legal requirement is only known that you are of a certain age, there is no need for the service to have access to all the other personal information collected by the "AgeVerify Company X".

We all see the news day in and day out about data brokers being hacked, ID verification companies forgetting do secure their S3 buckets and leaking raw data so this is a real risk.

Even if $FavoriteOnlineService promises to not misuse your data it might get bought by some Venture Capital firm and they then decide to leverage all the collected personal information for profit. Building online profile from $FavoriteOnlineService to $FavoriteOnlineService2 and matching their database of users to build ad profiles, track your online movements or what you say online.

What does the service actually need?🔗

Imagine $FavoriteOnlineService asks:

Is the account xXx_dragonslayer_xXx over 18?

The useful answer is:

Yes, the holder of this ID card is over 18.

No name.
No birthdate.
No address.
No photo of the ID card.
Nothing else.

I mean given the username we could guess already that the person might be an oldschool gamer from the early 2000s but thats not a hard fact.

Funny enough, the German eID card can help us proving xXx_dragonslayer_xXx is over 18 without revealing any other personal information about them.

How the German eID solves this🔗

The German eID brings a few useful guarantees by design:

  • The transaction requires the physical card and its PIN, proving possession and explicit consent of the card holder.
  • The card only releases data which the service is authorised to request. Data minimalism
  • It can generate a pseudonym unique to the combination of card and authorised service sector. No cross-service tracking
  • It does not create a reusable signed identity statement the service could take somewhere else and impersonate the cardholder with. Single-use identification

This does not prove which face is currently sitting in front of the screen but why should it if the question was simply "is the account holder over 18?".

During an eID identification the reading party can simply "call" two special functions on the eID card for Age Verification and Restricted Identification.

Age Verification🔗

The service does not read the date of birth from the card.

Instead, an authorised eID Server sends a threshold date to the chip — for an over-18 check, that is today's date minus 18 years. The requested threshold is cryptographically bound into the eID session. The chip compares it internally with the date of birth stored in DG8 and returns, conceptually:

{ "over_18": true }

The birthdate never leaves the chip. The service does not learn if the person turned 18 yesterday or is 69 years old.

It gets one bit(true or false) of useful information and nothing more.

Restricted Identification🔗

Age Verification proves the fact of being over the required age. But $FavoriteOnlineService still needs a way to recognise that the card is unique and if it comes back later to enforce a rule such as "one verified card per account".

This is what Restricted Identification (RI) is for.

The chip generates a stable pseudonym unique to the combination of:

  • this eID card
  • this authorised service
{ "eid_pseudonym": "4da2...9bc1" }

$FavoriteOnlineService always receives the same pseudonym for the same card and sector key. A different authorised service receives a completely different one.

So $FavoriteOnlineService and some unrelated platform cannot simply compare their databases and discover that both pseudonyms belong to the same person.

Age Verification proves the fact. Restricted Identification provides identity ( a pseudonymous one ).

A fair trade.
A fair trade.

What the service stores🔗

$FavoriteOnlineService needs an authorised eID service with terminal rights for Age Verification and Restricted Identification.

Nothing else.

The card rejects requests for fields which are not explicitly authorised for that service. Even a compromised eID Server cannot suddenly decide to read the name, address or birthdate without the corresponding certificate rights.

The service could store:

{
  "account": "xXx_dragonslayer_xXx",
  "eid_pseudonym": "4da2...9bc1",
  "over_18": true,
  "verified_at": "2026-09-30"
}

No scan of the ID card. No legal name. No exact age. No reusable global identifier.

Simply the data the service actually needs.

There is one important detail: the RI pseudonym is pseudonymous, not magically anonymous.

Once $FavoriteOnlineService stores it next to an account, it may still be personal data under GDPR. But it is vastly more privacy-friendly than storing a passport scan, birthday, address and legal name just to answer a yes/no question.

It is also useful for re-identification or access to a privileged section of an account. The service can simply ask for the RI pseudonym again without reading any other data from the card.

The only caveat is that the pseudonym changes when the card is replaced, so the platform needs a recovery or re-verification flow. That is a manageable trade-off for the privacy benefits it provides.


Conclusion🔗

Given the german eID infrastructure, it is possible to verify age online without unnecessarily exposing personal identity information. There is no need for storing full identity documents or personal details just to verify age.

So IF you have/want to verify age online, do it in a privacy-preserving way:

Ask the eID card the smallest possible question and only store the smallest useful answer.

If video ID providers could read...
If video ID providers could read...

If you want to know how the eID Server, PACE, Terminal Authentication, Chip Authentication, CHAT permissions and the cryptography behind RI fit together, read The German eID explained.


eIDAS funfact🔗

Take a look at eIDAS Network

eIDAS Network

26 Memberstates of the european Union already provide the DateOfBirth attribute through the eIDAS network. This enables online services to perform age verification in a privacy-preserving manner across the EU. So there is no need for databrokers or other third-party age verification services IMHO.

References🔗

Age-verification policy🔗

German eID technical foundations🔗