eu.europa.ec.av.1 Explained: How a Verifier Validates an EU Proof-of-Age Attestation Against the Trusted List

If you have started integrating the EU age-verification app, you have almost certainly hit two phrases that nobody explains in plain language: the namespace eu.europa.ec.av.1, and the instruction to validate the Proof of Age attestation against the trusted list.

Both matter, because together they are what separates a real age check from a forgeable one. A cryptographically signed "yes, this person is over 18" is worthless if you cannot answer the next question: who signed it, and are they allowed to? This post walks through what lives in eu.europa.ec.av.1, and the precise steps a verifier takes to prove an attestation is genuine using the EU Age Verification Trusted List.

What eu.europa.ec.av.1 actually is

The EU Age Verification Solution — the white-label app the Commission made feature-ready on 15 April 2026, with an open-source reference implementation (ageverification.dev) — issues a specific credential called a Proof of Age Attestation. In the ISO/IEC 18013-5 mso_mdoc encoding, that attestation's document type and its single namespace are both eu.europa.ec.av.1.

The namespace is deliberately tiny. It carries only these attributes:

And a hard rule from the specification: a Proof of Age Attestation SHALL NOT include any other attribute. There is no name, no document number, no date of birth — a Proof of Age Attestation is an electronic attestation of attributes within the meaning of Article 3(44) of the EUDI Regulation, confirming a threshold and nothing more. That is the data-minimisation guarantee baked into the format itself: even if it wanted to, the attestation cannot leak an identity.

The trust problem: a boolean needs an issuer you can prove

Here is the catch every integrator eventually meets. Your verifier receives a signed object that says age_over_18: true. The signature proves the object hasn't been tampered with — but it does not, on its own, prove the signer is a legitimate age-attestation issuer. Anyone can generate a key pair and sign {age_over_18: true}.

So the real trust decision is not "is the signature valid?" It is "is the certificate that produced this signature on the list of entities the EU has authorised to issue Proof of Age attestations?" That list is the Age Verification Trusted List.

The Age Verification Trusted List

The EU Age Verification Trusted List is an ETSI-style trusted list, hosted by the European Commission in the eIDAS Dashboard, that acts as the central trust anchor for age verification across all Member States. Each Member State notifies the Commission of the Proof of Age Attestation Providers established in its territory, and their signing certificates are published on the list.

It is identified by a dedicated list type, and age issuers by a dedicated service type:

<TSLType>http://ec.europa.eu/tools/lotl/av/TrstSvc/TrustedList/TSLType/AVTL</TSLType>
...
<TSPService>
  <ServiceInformation>
    <ServiceTypeIdentifier>http://ec.europa.eu/tools/lotl/av/TrstSvc/Svctype/PAA</ServiceTypeIdentifier>
    <ServiceName><Name xml:lang="en">Age Verification Issuer</Name></ServiceName>
    <ServiceDigitalIdentity>
      <DigitalId><X509Certificate>...</X509Certificate></DigitalId>
    </ServiceDigitalIdentity>
  </ServiceInformation>
</TSPService>

PAA = Proof of Age Attestation Provider. The X509Certificate under each service is the trust anchor your verifier checks against. The Commission also hosts an acceptance (test) trusted list in the ACC environment so you can integrate against multiple national test issuers before go-live.

How a verifier validates an attestation — step by step

When a Proof of Age Attestation arrives, a correct verifier does all of the following, and refuses access if any step fails:

1. Parse and scope-check. Decode the mso_mdoc, confirm the document type is eu.europa.ec.av.1, and read only the attribute you asked for (e.g. age_over_18). Ignore anything else.
2. Verify the issuer signature. Check the Mobile Security Object (MSO) signature so you know the attestation's contents are authentic and unmodified.
3. Validate the signer against the Trusted List. Take the document-signer certificate that produced that signature and confirm it chains to a certificate published on the AV Trusted List under the PAA service type. This is the step that turns a signature into trust. No match → reject.
4. Check validity. Enforce expiry_date and the mdoc ValidityInfo window.
5. Confirm holder binding. Verify the attestation is bound to the presenting device (the wallet proves control of the private key tied to the public key in the attestation), so a copied attestation can't be replayed.
6. Fail closed. If the issuer isn't on the list, the signature doesn't verify, or the proof is expired or unbound — deny. Never "allow on error."

Steps 2–3 are the heart of it, and they mirror the passive-authentication model used for e-passports: verify the signature, then validate the signing certificate against an authoritative list of legitimate issuers. The trusted list is that authoritative list.

Presentation and privacy: DC API, OID4VP, ZKP and one-time mdocs

Two things worth knowing, because they shape how you build the verifier:

Two transport mechanisms. The Digital Credentials API (DC API) is the browser-integrated, primary path; OpenID for Verifiable Presentations (OID4VP) is the fallback where DC API isn't available. A production verifier supports both and picks the best at runtime.

Two proof types, both designed against tracking. A Zero-Knowledge Proof presentation gives the same yes/no with no linkable identifier disclosed. The standard mdoc attestation achieves unlinkability differently: proofs are single-use and issued in batches (the spec recommends 30 per batch), and issuers deliberately coarsen the ValidityInfo timestamps (same hh:mm:ss across a batch, per the ISO 18013-5 recommendation) so the attestation itself carries no fingerprint that lets services correlate a user across visits.

The takeaway for anyone enforcing an age policy: you receive a threshold answer, and by design you cannot turn it into a tracking identifier.

Why this is exactly the plumbing we handle

None of the above is hard to get wrong. Skip step 3 and you have an age check that any attacker can forge. Hard-code a single issuer certificate and you break the moment a new Member State notifies a provider. Parse the ETSI XML by hand and you own trusted-list refresh, certificate-chain validation, and revocation forever.

This is precisely the layer eIDAS Pro operates for you: our verifier speaks eu.europa.ec.av.1, validates every attestation against the live AV Trusted List (with the test/ACC list for integration), supports DC API and OID4VP, and returns a clean boolean to your application — while storing no personal data in the process. When the standalone AV attestation and the broader EUDI Wallet paths converge, the same verification call covers both.

If your compliance obligation is "verify age against a trusted, government-authorised source," the trusted list is that source — and getting its validation right is the whole job.

eIDAS Pro provides privacy-first, EUDI-ready age and identity verification for European platforms — trusted-list validation, layered eID, and a boolean-out API, with no personal data stored. Book a consultation →

This article is technical general information, not legal advice. Always work from the current EU Age Verification specifications and your own compliance counsel.