eu.europa.ec.av.1 uitgelegd: hoe een verifier een EU-leeftijdsattestatie valideert tegen de Trusted List

Als je begonnen bent met het integreren van de EU-leeftijdsverificatie-app, ben je vrijwel zeker twee begrippen tegengekomen die zelden in gewone taal worden uitgelegd: de namespace eu.europa.ec.av.1, en de instructie om de Proof-of-Age-attestatie te valideren tegen de trusted list.

Beide zijn belangrijk, want samen bepalen ze het verschil tussen een echte leeftijdscheck en een vervalsbare. Een cryptografisch ondertekend "ja, deze persoon is ouder dan 18" is waardeloos als je de volgende vraag niet kunt beantwoorden: wie heeft dit ondertekend, en mocht die partij dat? Dit artikel behandelt wat er in eu.europa.ec.av.1 staat, en de exacte stappen die een verifier neemt om te bewijzen dat een attestatie echt is met behulp van de EU Age Verification Trusted List.

Wat eu.europa.ec.av.1 eigenlijk is

De EU Age Verification Solution — de white-label-app die de Commissie op 15 april 2026 functioneel klaar heeft gemaakt, met een open-source referentie-implementatie (ageverification.dev) — geeft een specifieke credential uit: een Proof of Age Attestation. In de ISO/IEC 18013-5 mso_mdoc-codering zijn het documenttype van die attestatie en de enige namespace ervan beide eu.europa.ec.av.1.

De namespace is bewust minimaal. Hij bevat alleen deze attributen:

En een harde regel uit de specificatie: een Proof of Age Attestation MAG GEEN andere attributen bevatten. Geen naam, geen documentnummer, geen geboortedatum — een Proof of Age Attestation is een elektronische attestatie van attributen in de zin van artikel 3(44) van de EUDI-verordening, die alleen een drempel bevestigt en niets meer. Dat is de dataminimalisatie die in het formaat zelf verankerd zit: zelfs als het zou willen, kan de attestatie geen identiteit lekken.

Het vertrouwensprobleem: een boolean heeft een bewijsbare uitgever nodig

Hier ligt het knelpunt waar elke integrator vroeg of laat tegenaan loopt. Je verifier ontvangt een ondertekend object dat zegt age_over_18: true. De handtekening bewijst dat het object niet is gemanipuleerd — maar bewijst niet op zichzelf dat de ondertekenaar een legitieme uitgever van leeftijdsattestaties is. Iedereen kan een sleutelpaar genereren en {age_over_18: true} ondertekenen.

De echte vertrouwensbeslissing is dus niet "is de handtekening geldig?" Het is: "staat het certificaat dat deze handtekening heeft geproduceerd op de lijst van partijen die de EU heeft geautoriseerd om Proof of Age-attestaties uit te geven?" Die lijst is de Age Verification Trusted List.

De Age Verification Trusted List

De EU Age Verification Trusted List is een trusted list in ETSI-stijl, gehost door de Europese Commissie in het eIDAS Dashboard, die dient als het centrale vertrouwensanker voor leeftijdsverificatie in alle lidstaten. Elke lidstaat meldt bij de Commissie de Proof of Age Attestation Providers die op zijn grondgebied zijn gevestigd, en hun ondertekeningscertificaten worden op de lijst gepubliceerd.

De lijst wordt geïdentificeerd door een eigen lijsttype, en leeftijdsuitgevers door een eigen diensttype:

<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. Het X509Certificate onder elke dienst is het vertrouwensanker waartegen je verifier controleert. De Commissie host ook een acceptatie(test)trusted list in de ACC-omgeving, zodat je vóór de go-live tegen meerdere nationale testuitgevers kunt integreren.

Hoe een verifier een attestatie valideert — stap voor stap

Wanneer een Proof of Age Attestation binnenkomt, voert een correcte verifier alle volgende stappen uit en weigert toegang als een van deze stappen faalt:

1. Parsen en scope controleren. Decodeer de mso_mdoc, bevestig dat het documenttype eu.europa.ec.av.1 is, en lees alleen het attribuut dat je hebt opgevraagd (bijv. age_over_18). Negeer al het andere.
2. Uitgeversignatuur verifiëren. Controleer de handtekening van het Mobile Security Object (MSO), zodat je weet dat de inhoud van de attestatie authentiek en ongewijzigd is.
3. Ondertekenaar valideren tegen de Trusted List. Neem het document-signer-certificaat dat die handtekening heeft geproduceerd en bevestig dat het terugleidt naar een certificaat dat op de AV Trusted List is gepubliceerd onder het PAA-diensttype. Dit is de stap die een handtekening in vertrouwen omzet. Geen match → afwijzen.
4. Geldigheid controleren. Handhaaf expiry_date en het ValidityInfo-venster van de mdoc.
5. Holder binding bevestigen. Verifieer dat de attestatie is gebonden aan het presenterende apparaat (de wallet bewijst controle over de privésleutel die hoort bij de publieke sleutel in de attestatie), zodat een gekopieerde attestatie niet kan worden herhaald.
6. Fail closed. Als de uitgever niet op de lijst staat, de handtekening niet verifieert, of het bewijs is verlopen of niet gebonden — weiger. Nooit "toestaan bij fout."

Stappen 2–3 vormen de kern, en ze weerspiegelen het passive-authentication-model dat wordt gebruikt voor e-paspoorten: verifieer de handtekening, valideer dan het ondertekeningscertificaat tegen een gezaghebbende lijst van legitieme uitgevers. De trusted list is die gezaghebbende lijst.

Presentatie en privacy: DC API, OID4VP, ZKP en eenmalige mdocs

Twee dingen zijn goed om te weten, omdat ze bepalen hoe je de verifier bouwt:

Twee transportmechanismen. De Digital Credentials API (DC API) is het primaire, in de browser geïntegreerde pad; OpenID for Verifiable Presentations (OID4VP) is de fallback wanneer DC API niet beschikbaar is. Een productieverifier ondersteunt beide en kiest tijdens runtime de beste optie.

Twee bewijstypen, beide ontworpen tegen tracking. Een Zero-Knowledge Proof-presentatie geeft hetzelfde ja/nee-antwoord zonder een koppelbare identifier prijs te geven. De standaard mdoc-attestatie bereikt onlinkbaarheid op een andere manier: bewijzen zijn eenmalig te gebruiken en worden in batches uitgegeven (de specificatie beveelt 30 per batch aan), en uitgevers vergroven bewust de ValidityInfo-tijdstempels (dezelfde hh:mm:ss binnen een batch, volgens de ISO 18013-5-aanbeveling), zodat de attestatie zelf geen vingerafdruk draagt waarmee diensten een gebruiker over meerdere bezoeken heen kunnen correleren.

De conclusie voor iedereen die een leeftijdsbeleid handhaaft: je ontvangt een drempelwaarde-antwoord, en door het ontwerp kun je dit niet omzetten in een tracking-identifier.

Waarom dit precies de leidingen zijn die wij beheren

Niets van het bovenstaande is moeilijk fout te doen. Sla stap 3 over en je hebt een leeftijdscheck die elke aanvaller kan vervalsen. Hardcodeer één uitgeverscertificaat en je integratie breekt op het moment dat een nieuwe lidstaat een provider meldt. Parseer de ETSI-XML handmatig en je bent voor altijd verantwoordelijk voor trusted-list-verversing, certificaatketenvalidatie en intrekking.

Dit is precies de laag die eIDAS Pro voor je uitvoert: onze verifier spreekt eu.europa.ec.av.1, valideert elke attestatie tegen de live AV Trusted List (met de test-/ACC-lijst voor integratie), ondersteunt DC API en OID4VP, en levert een schone boolean terug aan je applicatie — zonder daarbij persoonsgegevens op te slaan. Wanneer het losstaande AV-attestatiepad en de bredere EUDI Wallet-paden samenkomen, dekt dezelfde verificatieaanroep beide af.

Als jouw compliance-verplichting is "leeftijd verifiëren tegen een betrouwbare, door de overheid geautoriseerde bron," dan is de trusted list die bron — en de validatie ervan correct implementeren is het hele werk.

eIDAS Pro biedt privacy-first, EUDI-klare leeftijds- en identiteitsverificatie voor Europese platforms — trusted-list-validatie, gelaagde eID en een boolean-out API, zonder opslag van persoonsgegevens. Boek een consult →

Dit artikel bevat algemene technische informatie, geen juridisch advies. Werk altijd vanuit de actuele EU-specificaties voor leeftijdsverificatie en je eigen compliance-adviseur.