De EU Proof-of-Age-attestatie integreren: een ontwikkelaarsgids voor de namespace eu.europa.ec.av.1

Als u leeftijdsverificatie integreert tegen de oplossing van de EU, zal één string vaker in uw code voorkomen dan enige andere: eu.europa.ec.av.1. Het is de namespace van de "Proof of Age"-attestatie, en begrijpen wat het is — en wat het bewust niet is — is het fundament van een correcte integratie.

Deze gids is de praktische tegenhanger van onze conceptuele uitsplitsing van de EU-leeftijdsverificatie-app. Hier blijven we op het niveau van protocol en datamodel: het credentialformaat, de uitgifteflow, en hoe u uw code aansluit op de live referentie-uitgever.

De attestatie, precies

De officiële Age Verification Issuer van de EU is een (Q)EAA Provider — een aanbieder van (gekwalificeerde) elektronische attestaties van attributen, in de zin van eIDAS 2.0. Het implementeert de Age Verification Specification en geeft een "Proof of Age"-attestatie uit met deze bepalende eigenschappen:

• Formaat: mso_mdoc — het ISO/IEC 18013-5 mobile-documentformaat, dezelfde familie die wordt gebruikt door mobiele rijbewijzen en de PID van de EUDI Wallet. Als u Hoe eIDAS-verificatie werkt heeft gelezen, is dit het credentialformaat daaronder.
• Namespace: eu.europa.ec.av.1. Elke claim in de attestatie is gekwalificeerd door deze namespace. De versie zit ingebakken in de namespace zelf — de afsluitende .1 — zodat een toekomstige breaking change eu.europa.ec.av.2 wordt, en uw code hierop kan vertakken.
• Semantiek: het bevestigt dat de houder boven een gegeven leeftijdsdrempel zit, zonder de geboortedatum bloot te leggen. Dat is het hele punt. De attestatie beantwoordt "is deze persoon ouder dan N?" en niets meer.

In eIDAS-termen is dit een elektronische attestatie van attributen onder artikel 3(44) van de verordening. Die juridische inkadering is geen decoratie — het is wat een leeftijdsbewijs-presentatie grensoverschrijdend rechtsgeldig maakt, op dezelfde manier als een grensoverschrijdende verificatie van identiteit dat doet.

Waarom een namespace in plaats van gewoon "leeftijd ≥ 18"

Nieuwkomers vragen vaak waarom de EU iets zo eenvoudigs als een ouder-dan-18-boolean heeft verpakt in een formele mdoc-namespace. Drie redenen, die u elk later werk besparen:

1. Meerdere drempels, één model. Leeftijdsgrenzen liggen niet allemaal op 18. Alcohol, gokken, bepaalde content en regels voor "op kinderen gerichte diensten" gebruiken 16, 18, 21 en andere. Een namespace-attestatie kan drempelclaims uniform uitdrukken, in plaats van elke relying party te dwingen zijn eigen codering te verzinnen.
2. Verifieerbare herkomst. Omdat de claim zich binnen een ondertekende mdoc bevindt, controleert uw verifier een handtekening en een vertrouwensketen — geen zelfverklaarde waarde. De handtekening is wat dit fundamenteel anders maakt dan het leeftijdsvinkje dat het vervangt.
3. Onkoppelbaarheid door constructie. De standaardattestatie is eenmalig bruikbaar en wordt in batches uitgegeven, specifiek zodat herhaalde presentaties niet tot een profiel kunnen worden gecorreleerd. We komen hier verderop op terug, want het is de meest voorkomende overclaimde eigenschap van het systeem.

Uitgifte: OpenID4VCI

De uitgever volgt OpenID for Verifiable Credential Issuance (OpenID4VCI). Als uw team heeft gewerkt met OpenID4VP voor presentatie, is VCI de uitgiftezijdige tegenhanger daarvan: waar VP is hoe een credential aan u wordt gepresenteerd, is VCI hoe het om te beginnen in de wallet terechtkomt.

De flow, op het niveau waarop u erover moet redeneren:

1. Een gebruiker onboardt naar de leeftijdsverificatie-app of -wallet, en bewijst zijn of haar leeftijd eenmalig via een vertrouwde bron (een eID, of — sinds blueprint v2 — een paspoort of nationale identiteitskaart).
2. De wallet voert een OpenID4VCI-uitwisseling uit met de uitgever om een batch aan Proof-of-Age-attestaties te verkrijgen.
3. Elke attestatie in de batch is eenmalig bruikbaar. Naarmate de gebruiker in de loop van de tijd bewijzen presenteert, put de wallet de batch uit en vult deze naar behoefte aan.

Als integrerende relying party bedient u doorgaans niet de uitgiftezijde — dat is de taak van de (Q)EAA Provider. Maar dit begrijpen verklaart de eigenschappen die u op presentatiemoment zult waarnemen: kortlevende, eenmalig bruikbare bewijzen, zonder stabiele identifier om op te ankeren.

De live referentie-uitgever — en het voorbehoud dat ertoe doet

De EU publiceert een werkende referentie-implementatie. De backend van de uitgever (av-srv-web-issuing-avw-py) is open source onder de officiële GitHub-organisatie EU Digital Identity Wallet, auteursrechtelijk bij de Europese Commissie, en er is een live, publiek gehoste referentie-uitgever die u tijdens de ontwikkeling kunt aanspreken.

Lees dit zorgvuldig: het is een referentie- en testimplementatie. Het is expliciet geen productieklare, burgergeschikte uitgever. Gebruik het om uw integratie, uw credential-parsing en uw presentatieflow te valideren. Bouw geen lanceerplan dat ervan uitgaat dat dit het productie-endpoint is dat uw echte gebruikers zullen aanspreken — dat endpoint zijn de nationale leeftijdsverificatie-apps en -wallets die de koploper-lidstaten uitrollen. Behandel de referentie-uitgever zoals u elke sandbox zou behandelen: onmisbaar om mee te bouwen, geen productieafhankelijkheid.

De privacyclaim, accuraat gesteld

Hier scheiden zorgvuldige engineers zich van marketingtekst. U zult lezen dat de EU-leeftijdsverificatieoplossing Zero-Knowledge Proofs (ZKP) gebruikt, zodat een relying party alleen een ja/nee-antwoord verneemt zonder enige mogelijkheid tot correlatie. Wees precies:

• Wat solide is: de standaard mdoc-attestatie is eenmalig bruikbaar en in batches uitgegeven, precies om koppelbaarheid te frustreren. Het bewijs onthult boven-drempel-status, niet de geboortedatum of identiteit. Dat is een echte, uitgeleverde privacyeigenschap.
• Waar u voorzichtig mee moet zijn: ZKP wordt in de verifier-richtlijn beschreven als een ondersteund, geprefereerd bewijstype — niet als een universeel uitgeleverde, volledig niet-correleerbare garantie die in een of andere bijlage gespecificeerd staat. Schrijf geen documentatie die stelt "het systeem is zero-knowledge, dus correlatie is onmogelijk." Schrijf: "onkoppelbaarheid wordt bereikt door eenmalig bruikbare, in batches uitgegeven bewijzen; ZKP wordt ondersteund als verbeterd bewijstype."

Dit is geen muggenzifterij. Als uw compliance-verhaal een cryptografische garantie claimt die het uitgerolde systeem nog niet uniform biedt, is dat precies de claim waar een auditor aan zal trekken. De eerlijke versie is nog steeds een uitstekend privacyverhaal — zie Privacy-First leeftijdsverificatie voor hoe wij dit inkaderen.

Een minimale integratiechecklist

Stap 6 verbindt deze ontwikkelaarstaak terug met de verplichtingen rond relying party-registratie en WRPAC. Een relying party die zich uitsluitend registreert voor leeftijdsbewijs is structureel niet in staat om te veel te vragen — het schoonst mogelijke antwoord aan een gegevensbeschermingsregulator.

De kern van de zaak

De namespace eu.europa.ec.av.1 is klein van omvang en groot van gevolg. Het is een mso_mdoc-, artikel 3(44)-attestatie, uitgegeven via OpenID4VCI, die een leeftijdsdrempel bewijst en niets meer. Bouw tegen de live referentie-uitgever om uw parsing en presentatieflow goed te krijgen — maar behandel deze als een sandbox, niet als productie. En wanneer u de privacyeigenschappen documenteert, beschrijf wat is uitgeleverd (eenmalig gebruik, batchuitgifte, alleen drempel) in plaats van wat aspirationeel is (universele ZKP). Krijg deze twee dingen goed, en uw integratie overleeft het contact met zowel echte wallets als echte auditors.

Dit artikel weerspiegelt de EU Age Verification-specificatie en referentie-implementatie per juni 2026. De referentie-uitgever is een testimplementatie, geen productie. Verifieer het credentialschema tegen de officiële repository van de uitgever voordat u bouwt.