Proof-of-Age valideren tegen de EU Trusted List: de stap die iedereen overslaat

Een Verifier die een Proof-of-Age-attestatie accepteert omdat de signature correct gevormd is, heeft de helft van het werk gedaan en de belangrijke helft overgeslagen. Een geldige signature bewijst alleen dat het credential is ondertekend door een sleutel. Het zegt niets over de vraag of die sleutel toebehoort aan een issuer die de EU daadwerkelijk vertrouwt om leeftijd te attesteren. Die kloof dichten is de taak van de Age Verification Trusted List, en de verifierrichtlijn is expliciet: u moet elke leeftijdsattestatie voordat u toegang verleent, ertegen valideren.

Dit is de stap die teams het vaakst overslaan -- en degene waar een auditor het meest betrouwbaar naar zal vragen.

Vertrouwen is een lijst, geen signature

In het EUDI-ecosysteem is vertrouwen verankerd in gepubliceerde trusted lists: machine-leesbare registers van de entiteiten die gemachtigd zijn een bepaalde rol te vervullen. Voor leeftijdsverificatie is het relevante register de Age Verification Trusted List -- de verzameling issuers wier Proof-of-Age-attestaties een conforme Verifier mag accepteren.

De validatieketen die uw Verifier moet doorlopen:

1. Parse het gepresenteerde mso_mdoc Proof-of-Age (de eu.europa.ec.av.1-attestatie -- zie onze ontwikkelaarshandleiding voor de namespace).
2. Verifieer de signature tegen het certificaat van de issuer.
3. Verankeer dat certificaat in de Age Verification Trusted List -- bevestig dat de issuer daadwerkelijk vermeld staat.
4. Verleen pas dan toegang.

Sla stap 3 over en u accepteert probleemloos een perfect ondertekende attestatie van een issuer die niemand heeft geautoriseerd. Dat is het verschil tussen cryptografische geldigheid en vertrouwen, en dat is precies de reden waarom trusted lists bestaan. We doorlopen de algemene versie van deze keten in Hoe eIDAS-verificatie werkt; deze post is de leeftijdsverificatie-specifieke variant daarvan.

Er is al een testlijst -- in de ACC-omgeving

U hoeft niet te wachten op productie om dit te bouwen. De Commissie host al een test-Age Verification Trusted List in de ACC-(acceptatie-)omgeving van het eIDAS Dashboard. Een opvallend detail voor wie deze verkent: de referentie-testissuer verschijnt in die omgeving onder IJsland -- een testplaatsing, geen uitspraak over IJslandse uitrol. Gebruik de ACC-lijst om uw trust-anchoring-logica nu al te ontwikkelen en te testen tegen de echte lijststructuur, vooruitlopend op de livegang van de productielijst.

Het eIDAS Dashboard is dezelfde infrastructuur die de productie-trusted-list-endpoints zal hosten. Als u uw validatie bouwt tegen de ACC-lijst, verandert u bij publicatie van de productielijst alleen een endpoint en een trust anchor -- in plaats van een capaciteit vanaf nul te bouwen.

Het onderscheid waar mensen over struikelen: AV-lijst ≠ WRPAC-lijst

Dit is de belangrijkste verduidelijking in deze post. Het eIDAS Dashboard zal meerdere trusted lists hosten voor verschillende rollen, en ze door elkaar halen leidt tot echt foutieve integraties:

Ze werken in tegengestelde richtingen. De AV Trusted List beschermt u, de Verifier, tegen het accepteren van bewijzen van malafide issuers. De WRPAC-providerlijst beschermt de wallet van de gebruiker tegen het openbaren van attributen aan niet-geregistreerde relying parties. Zoals we hebben gedocumenteerd, is de WRPAC-providerlijst nog niet gepubliceerd -- de verplichtingen daarvan gelden vanaf 24 december 2026. De AV-testlijst daarentegen is al beschikbaar in ACC. Hetzelfde dashboard, verschillende lijsten, verschillende tijdlijnen, verschillende vertrouwensrichtingen. Behandel ze als één ding en u koppelt uw Verifier aan het verkeerde register.

Operationele realiteiten van trusted-list-validatie

Een paar engineeringpunten die een robuuste implementatie onderscheiden van een broze:

• Cache, maar vernieuw. Trusted lists veranderen -- issuers worden toegevoegd, certificaten worden gerouleerd. Haal de lijst op, cache deze voor performance, maar vernieuw volgens een schema en handel het geval af waarin een eerder vertrouwde anchor verdwijnt.
• Fail closed. Als u de trusted list niet kunt bereiken of valideren, is de juiste standaard voor een leeftijdspoort weigeren, niet de gebruiker doorwuiven. Een vertrouwenscontrole die open faalt, is geen vertrouwenscontrole.
• Onderscheid "nog niet gepubliceerd" van "leeg". Tijdens deze overgangsperiode kan een endpoint legitiem melden dat een lijst niet gepubliceerd is. Dat is een gedefinieerde staat, geen fout om te negeren -- precies zoals we vonden bij de WRPAC-status van eind mei 2026 voor de EU-27, waar het WRPAC-endpoint bewust "niet gepubliceerd" meldt. Uw code moet het verschil herkennen tussen "de lijst zegt geen issuers" en "er is nog geen lijst".
• Scheid test- en productie-anchors strikt. De ACC-lijst (met zijn IJslandse testissuer) mag nooit een trust anchor zijn in uw productie-Verifier. Houd de omgevingsconfiguratie expliciet, zodat een test-anchor nooit kan lekken naar productievertrouwen.

Waarom dit een concurrentievoordeel is, geen afvinkitem

De meeste leeftijdsverificatieleveranciers valideren vandaag een signature en noemen het klaar. Een Verifier die correct verankert aan de EU Age Verification Trusted List, doet iets wezenlijk sterkers: hij handhaaft de governance van de EU over wie leeftijd mag attesteren, niet alleen de cryptografie van één signature. Wanneer een gereguleerde relying party -- een gokoperator, een leeftijdsgebonden marktplaats, een platform onder DSA-artikel 28 -- moet aantonen hoe zij weet dat een leeftijdsbewijs echt is, is "wij verankeren aan de EU Age Verification Trusted List" een veel sterker antwoord dan "de signature klopte". Dezelfde logica ligt ten grondslag aan onze integraties voor WooCommerce en online gaming.

De essentie

Valideren tegen de Age Verification Trusted List is de stap die een ondertekend credential omzet in een vertrouwd credential. De testlijst bestaat vandaag al in de ACC-omgeving van het eIDAS Dashboard, dus er is geen reden om de bouw ervan uit te stellen. Verankeer elk bewijs aan de lijst, faal gesloten wanneer dat niet kan, vernieuw uw cache, houd test- en productie-anchors strikt gescheiden -- en verwar nooit de AV-issuerlijst met de WRPAC-providerlijst. Doe dit goed en uw Verifier handhaaft EU-vertrouwensgovernance, niet alleen rekenwerk.

Deze post weerspiegelt de EU-vertrouwensinfrastructuur voor leeftijdsverificatie per juni 2026. De productie-Age Verification Trusted List was op het moment van schrijven nog niet live; de ACC-testlijst en de plaatsingen daarin dienen uitsluitend voor ontwikkeling. Verifieer tegen het eIDAS Dashboard en de actuele verifierrichtlijn voordat u op specifieke details vertrouwt.