DC API, OpenID4VP, ZKP: de runtime-fallbackmatrix die elke leeftijdsverificatie-verifier moet implementeren

Er is één enkele ontwerpbeslissing die een leeftijdsverificatie-verifier die voor iedereen werkt, onderscheidt van een die voor de meeste mensen werkt: hoe hij terugvalt. De EU-richtlijn voor leeftijdsverificatie-verifiers laat dit niet aan smaak over. Ze stelt onomwonden dat een verifier meer dan één presentatiemechanisme moet ondersteunen en tijdens runtime de best beschikbare optie moet selecteren. Implementeer alleen het happy path en u sluit stilzwijgend elke gebruiker uit wiens browser of apparaat dit niet ondersteunt.

Dit artikel legt de fallbackmatrix uit, waarom die bestaat en hoe u erover kunt redeneren zonder de privacy-eigenschappen bovenaan de stack te overclaimen.

Twee mechanismen, twee bewijstypen

De matrix heeft twee assen.

Presentatiemechanisme — hoe het verzoek de wallet bereikt en het antwoord terugkomt:

• DC API (Digital Credentials API) — een in de browser geïntegreerde API. De browser bemiddelt de credential-aanvraag rechtstreeks, wat de soepelste gebruikerservaring oplevert. Dit is de primaire methode en ze is in toenemende mate beschikbaar in moderne besturingssystemen en browsers.
• OpenID4VP (OpenID for Verifiable Presentations) — het op OpenID gebaseerde protocol voor het aanvragen en ontvangen van verifieerbare presentaties. Dit is de fallback, gebruikt wanneer de browser van de gebruiker de DC API niet ondersteunt. Wilt u eerst de protocolbasis, begin dan met Het OpenID4VP-protocol begrijpen.

Bewijstype — welke cryptografische vorm het bewijs aanneemt:

• Standaard mdoc-attestatie — de ondertekende mso_mdoc Proof-of-Age, eenmalig bruikbaar gemaakt en in batches uitgegeven om koppelbaarheid te beperken.
• ZKP (Zero-Knowledge Proof) — een verbeterd bewijstype dat sterkere privacy-eigenschappen biedt en, waar beschikbaar, wordt behandeld als de voorkeursoptie.

De richtlijn kadert dit als een runtime-voorkeursvolgorde — sterkste privacy + beste UX eerst, met een gecontroleerde terugval:

Uw verifier moet de combinaties ondersteunen, niet alleen de favoriete, en de optie met de hoogste prioriteit kiezen die elk apparaat daadwerkelijk kan waarmaken.

Waarom de fallback niet optioneel is

Het is verleidelijk om alleen DC API uit te leveren en de lange staart te vragen hun browser te upgraden. Drie redenen om dat niet te doen:

1. Dekking. De DC API is in toenemende mate beschikbaar — precies de formulering die betekent dat ze nog niet universeel beschikbaar is. Elke gebruiker op een browser of besturingssysteem zonder de API is een mislukte leeftijdscontrole als u geen fallback heeft. Voor een leeftijdspoort is een mislukte controle geen verminderde ervaring; het is een geblokkeerde transactie.
2. De richtlijn vereist het. „Uw verifier moet alle combinaties ondersteunen" is geen advies. Een conforme EU-leeftijdsverificatie-verifier implementeert de fallback.
3. Gecontroleerde degradatie is een betrouwbaarheidseigenschap. Dezelfde discipline die we toepassen op elke veerkrachtige integratie — ervan uitgaan dat het beste pad onbeschikbaar kan zijn en een geteste tweede route hebben — geldt hier. De OpenID4VP-fallback is uw tweede route.

De privacyvolgorde, eerlijk verwoord

ZKP op prioriteit 1 zetten is correct, maar hoe u het beschrijft aan stakeholders is waar teams in de problemen komen. Wees precies over wat is uitgeleverd versus wat de voorkeur heeft:

• Uitgeleverd en reëel: het standaard mdoc-bewijs is eenmalig bruikbaar en in batches uitgegeven, en het onthult alleen de status boven de drempel — niet de geboortedatum, niet de identiteit. Dat alleen al verijdelt de naïeve correlatie-aanval van „hetzelfde credential twee keer gepresenteerd".
• Voorkeur, niet universeel: ZKP staat vermeld als een ondersteund, voorkeursbewijstype. Documenteer uw systeem niet als „zero-knowledge, en dus per constructie niet-correleerbaar", tenzij de specifieke implementatie waarmee u integreert daadwerkelijk ZKP levert voor de betreffende transactie. De accurate zin is: „Waar ZKP beschikbaar is, geven wij er de voorkeur aan; anders berust de onkoppelbaarheid op eenmalig bruikbare, in batches uitgegeven mdoc-bewijzen."

We maken hetzelfde zorgvuldige onderscheid in onze ontwikkelaarsgids voor de leeftijdsbewijs-attestatie en in Privacy-First leeftijdsverificatie. Het is van belang omdat een privacyclaim een compliance-claim is, en een overdreven claim een aansprakelijkheid.

De runtime-selectie implementeren

De logica die uw verifier conceptueel bij elke transactie uitvoert:

1. Detecteer de DC API via feature detection. Biedt deze browser de API aan? Zo ja, geef er de voorkeur aan.
2. Onderhandel over het bewijstype. Vraag binnen DC API een ZKP-bewijs aan; accepteer een standaard mdoc als ZKP niet beschikbaar is.
3. Val terug op OpenID4VP wanneer de DC API ontbreekt, met een standaard mdoc-bewijs.
4. Valideer voordat u toegang verleent. Ongeacht het pad moet het gepresenteerde bewijs worden gevalideerd tegen de EU Age Verification Trusted List voordat u de gebruiker doorlaat. Die validatiestap is een onderwerp op zich — zie ons begeleidende artikel over het valideren van het leeftijdsbewijs tegen de trusted list.
5. Behandel het bewijs als eenmalig. Sla het niet op, speel het niet opnieuw af, leid er geen stabiele identifier uit af. Dat zou precies de koppelbaarheid opnieuw introduceren die het batch-ontwerp juist moet voorkomen.

Let op: stappen 1–3 gaan over het bereiken van de wallet, en stappen 4–5 gaan over het vertrouwen en verwerken van het antwoord. Een correcte verifier doet beide. Een veelvoorkomende faalmodus zijn teams die het aanvraagpad perfect uitvoeren en vervolgens het bewijs verkeerd behandelen — het opslaan „voor audit", wat een privacyvriendelijke controle stilzwijgend omzet in een trackingrecord.

Hoe dit in het grotere geheel past

De fallbackmatrix is de verifier-zijdige mechaniek van dezelfde flow die, aan de identiteitszijde van de relying party, afhangt van WRPAC-registratie: uw verifier authenticeert zich als geregistreerde relying party, doet het verzoek via DC API of OpenID4VP, ontvangt een bewijs, valideert het tegen de trust list, en verleent of weigert toegang. Voor een uitgebreidere vergelijking van hoe dit verifiermodel verschilt van klassieke identiteitscontroles, zet onze ontwikkelaarsvergelijking EUDI Wallet vs. KYC de twee naast elkaar.

De conclusie

De verifierrichtlijn geeft u een voorkeursvolgorde — DC API + ZKP, dan DC API + mdoc, dan OpenID4VP + mdoc — en een instructie: ondersteun de combinaties en kies tijdens runtime de beste. De DC API geeft u de ervaring; OpenID4VP geeft u de dekking; de bewijstype-volgorde geeft u de privacy. Levert u alleen de top van de matrix uit, dan levert u een leeftijdspoort uit die faalt voor de gebruikers die het minst waarschijnlijk op een bijdetijdse browser zitten. Levert u de hele matrix uit, beschrijft u de ZKP-eigenschap eerlijk en behandelt u elk bewijs als eenmalig, dan heeft u een verifier die correct, inclusief en verdedigbaar is.

Dit artikel weerspiegelt de EU Age Verification-verifierrichtlijn per juni 2026. De runtime-fallback en de bewijstype-volgorde berusten op de officiële verifiergids; verifieer tegen de actuele specificatie voordat u implementeert.