How the EU Age Verification Blueprint actually works

The problem age verification usually creates

Verifying someone's age sounds simple until you think about what it requires. Traditional approaches ask for a government ID, a selfie, or both — collecting exactly the kind of personal data that GDPR's minimization principle says you shouldn't be processing unless you absolutely need to.

This is the tension the European Commission had to solve when it built the EU Age Verification Blueprint: a technical standard that satisfies Article 28(1) DSA without violating Article 5(1)(f) GDPR in the process. Article 28(3) of the DSA makes this explicit — platforms are not required to process additional personal data solely to determine whether a user is a minor.

What the platform actually receives

The result for the relying party — the platform doing the verifying — is a single boolean: age_over_18: true or false. Nothing else. No name, no date of birth, no document number, no persistent identifier tying that verification back to a specific person.

This isn't a simplified summary — it's the literal design goal. The official technical portal describes the result as "completely anonymous" in practice: the relying party learns only the yes/no answer it needs, no linkable identifier is ever disclosed, and no biometric scan or document image is transmitted.

The mechanism behind it

The credential lives in a dedicated app — referred to informally as the "mini-wallet" — built on the same technical specifications as the broader European Digital Identity Wallet, but operating independently of it. Users don't need a full EUDI Wallet to use age verification; the AV app works standalone, which is precisely why this is viable as a near-term solution while full EUDI Wallets are still rolling out across member states.

The protocol is OpenID for Verifiable Presentations (OID4VP), the same standard underlying the broader EUDI ecosystem. A relying party requests a presentation, the user's app responds with a credential, and the cryptographic signature is checked against the issuer's certificate — which must appear on the EU's official Trusted List for that verification to be considered valid.

The specification also defines a path toward Zero-Knowledge Proofs as the underlying cryptographic mechanism evolves — letting the user's device prove "this user is over 18" without even the issuer's signed claim being directly disclosed. Current production implementations rely on credentials with selective disclosure (a signed age_over_18 claim), which already meets the privacy bar the guidelines require; ZKP is positioned as a further-reinforcing layer as the standard matures.

Why this matters for whoever builds the relying party integration

For a platform implementing this, the technical surface is smaller than it sounds: detect whether the request_type is QR-based (OID4VP) or browser-native (DC API for supporting browsers), generate a verification request, and handle the result. The complexity isn't in your integration — it's in the protocol layer underneath: maintaining the Trusted List, validating issuer certificates, and keeping pace with a specification that's still actively evolving.

That's the layer a service like espuni exists to absorb. The platform calls one API; the protocol complexity — Trusted List validation, wallet compatibility, specification updates — happens underneath, without becoming the platform's problem to maintain.

Where to look if you want the primary source

The reference implementation is fully open source. The technical specification, Android and iOS reference apps, and reference issuer/verifier code are all public on GitHub under the eu-digital-identity-wallet organization. If you're evaluating whether a vendor's implementation is faithful to the standard, that's the place to check it against.