EU Age Verification Blueprint — live April 2026
Identity
without
exposure

The EU published its Age Verification Blueprint on 15 April 2026 — open-source, seven pilot states, mandatory eIDAS 2.0 acceptance from December 2026. The specification is already written. The question is whether your integration implements it correctly. veryf.eu is a compliant Relying Party integration layer: one webhook, no personal data, built on the EU's own spec.

See how it works
Apr 2026
Blueprint published — live now
7 states
EU pilot live — FR DE IT ES DK GR IE
1 bit
age_over_18 — the only attribute
Dec 2026
mandatory eIDAS 2.0 acceptance
Proof of Age Attestation
EU Age Verification
Doc type: eu.europa.ec.av.1
Format: ISO mDoc (18013-5)
Session: bound to this request only
Attestation contains exactly one attribute
✓
age_over_18 true
// Spec: attestation SHALL NOT include
// any other attribute. name, birth_date,
// doc_id — verified at enrolment only.
// OpenID4VP request received
// AVI invoked via av:// scheme
// Awaiting holder approval...
eIDAS 2.0 ISO mDoc 18013-5 OpenID4VP eu.europa.ec.av.1 W3C Digital Credentials API OID4VCI AMLR Art. 22 GDPR Art. 5 ISO 23220-2 HPKE RFC 9180 ETSI TS 119 612 eIDAS 2.0 ISO mDoc 18013-5 OpenID4VP eu.europa.ec.av.1 W3C Digital Credentials API OID4VCI AMLR Art. 22 GDPR Art. 5 ISO 23220-2 HPKE RFC 9180 ETSI TS 119 612
Architecture

Three parties.
One verified fact.

I. Attestation Provider (AP)
Government or certified authority

Issues the Proof of Age Attestation — doc type eu.europa.ec.av.1, ISO mDoc format. Verifies name, birth_date, and document identity at enrolment. None of that enters the attestation. The AP must appear on the EU Trusted List (ETSI TS 119 612).

II. Age Verification App (AVI)
The user's phone

Stores the Proof of Age Attestation. When your service requests a check, the user approves the disclosure in the AVI. The mDoc device response includes only age_over_18. Nothing else was ever in the attestation to share.

III. Relying Party (RP)
Your service via veryf.eu

You ask for age_over_18. You receive age_over_18. veryf.eu handles the OpenID4VP / W3C Digital Credentials API request, validates the Issuer-signed MSO, and delivers a verified boolean to your webhook. One call. No PII.

→AP issues mDoc attestation (eu.europa.ec.av.1) — one-time enrolment
AVI stores attestation — name/birth_date used only here, discarded
Not yet involved
Not involved
←AVI receives OpenID4VP request via av:// scheme
→RP sends: present eu.europa.ec.av.1 / age_over_18
Not involved
→User approves — AVI builds mDoc device response
✓RP receives: { age_over_18: true } via webhook
Not involved
The attestation contains only the boolean. name, birth_date, doc_id were never in it.
Session closed. Nothing to store, retain, or report.
The problem it solves

This is not selective disclosure from a full ID.
The attestation only ever contains one thing.

What the AP verifies at enrolment
given_name"Gintare"
birth_date1990-03-14
nationalityLT
document_idLT-28473-X
derived boolean age_over_18: true
→
What enters the Proof of Age Attestation
given_namenever entered
birth_datenever entered
nationalitynever entered
document_idnever entered
age_over_18true
This is structurally different from masking a full ID credential. The EU Blueprint spec is explicit: the Proof of Age Attestation SHALL NOT include any other attribute. There is nothing to filter, nothing to retain, nothing to breach. The personal data was used to derive the boolean — it never entered the attestation.
Who needs this

Any sector that
checks identity.

I.
Age-gated access

Confirm a user is over 18 without receiving their date of birth, name, or document number. The credential asserts the predicate. Your database never receives the underlying data. Simultaneously compliant with DSA Article 28 and MiCA onboarding requirements.

DSAMiCAeIDAS §18
II.
KYB — legal entity verification

Request proof of incorporation jurisdiction or regulatory status without receiving the full company register extract. AMLR Article 22 UBO threshold requirements become structurally addressable without data accumulation.

AMLRAML6DTFR
III.
Financial onboarding

EMIs and CASPs can satisfy AMLR CDD requirements using EUDI Wallet-verified credentials as a recognised mechanism from December 2026. Risk scoring changes when the credential comes from a qualified trust service provider under eIDAS.

AMLR Art. 22MiCAPSD3
IV.
Healthcare access

Present proof of insurance or treatment eligibility without disclosing the underlying diagnosis or policy number. The EUDI Health card is a Day 1 use case under the EU Digital Identity framework — the infrastructure is being built now.

EUDI HealthGDPR Art. 9
Integration

This is what
lands in your system.

One webhook. One response object. No personal data at any point — not in transit, not at rest. Works with any stack that handles HTTP.

Response POST /verify/callback 
{
  "verified":    true,
  "claims": {
    "age_over_18": true
  },
  "issuer":     "https://eidas.gov.ee",
  "verified_at": 1748563247
}

// That is the entire payload.
// No name. No birth date. No document number.
// The credential proved a fact — not a file.
EU Blueprint attestation spec 
// doctype: eu.europa.ec.av.1
// namespace: eu.europa.ec.av.1
// format: ISO mDoc (ISO/IEC 18013-5)

// Only valid claim:
"age_over_18": bool

// Presentation — primary:
// W3C Digital Credentials API + HPKE (RFC 9180)
// Presentation — fallback:
// OpenID4VP, response_mode: direct_post
Early Access

The December 2026
deadline does not wait.

EUDI Wallet interoperability goes live December 2026. MiCA onboarding obligations apply now. The services that integrate selective disclosure first hold the compliance architecture advantage for the next decade.

See how it works