eIDAS 2.0 gebruikt OID4VP als het standaardprotocol voor het presenteren van attestaties die zijn opgeslagen in de EUDI-wallet aan relying parties. OID4VP definieert hoe een wallethouder specifieke attribuutgegevens op een privacybeschermende manier deelt met een verifier. De onderstaande secties beschrijven hoe dit technisch werkt, wat organisaties moeten weten en hoe ze zich kunnen voorbereiden op implementatie.
Welke rol speelt OID4VP in de EUDI-wallet-architectuur?
OID4VP is de presentatielaag van het EUDI-wallet-ecosysteem. Het protocol bepaalt hoe een wallethouder reageert op een verzoek om attribuutgegevens, zodat specifieke attributen uit de EUDI-wallet kunnen worden gedeeld met een relying party zoals een bank, overheidsportaal of zorgverlener. Zonder OID4VP bestaat er geen gestandaardiseerde manier voor wallet instances en relying parties om attestatiepresentaties uit te wisselen over grenzen en sectoren heen.
Binnen de bredere EUDI-wallet-architectuur staat OID4VP naast andere componenten zoals het Architecture and Reference Framework (ARF), nationale trusted lists en de attestatie-uitgiftelaag. Het protocol verbindt de wallet unit met de relying party en zorgt ervoor dat presentaties op een consistente, interoperabele manier plaatsvinden, ongeacht welke lidstaat de wallet solution heeft uitgegeven of in welke sector de relying party actief is.
Dit is bijzonder relevant onder eIDAS 2.0, dat Verordening (EU) 910/2014 wijzigt en vereist dat EU-lidstaten wallet solutions uitgeven die werken over grenzen heen en voor zowel publieke als private diensten. OID4VP maakt die grensoverschrijdende, sectoroverstijgende interoperabiliteit technisch haalbaar. Organisaties in de financiële dienstverlening en andere gereguleerde sectoren kijken al naar hoe dit protocol past in hun bestaande verificatieprocessen.
Hoe werkt de OID4VP attestatiepresentatiestroom?
De OID4VP attestatiepresentatiestroom verloopt in vier hoofdstappen: de relying party stuurt een presentatieverzoek naar de wallet instance, de wallethouder beoordeelt en keurt goed wat er wordt gedeeld, de wallet unit genereert een verifieerbare presentatie met alleen de gevraagde attributen, en de relying party ontvangt en valideert de presentatie. Deze stroom zorgt ervoor dat de gebruiker bij elke stap de controle behoudt over welke gegevens de wallet verlaten.
Hieronder volgt een gedetailleerdere beschrijving van hoe de stroom verloopt:
- Presentatieverzoek: De relying party stuurt een Authorization Request naar de wallet instance. Dit verzoek specificeert welke attestaties of attributen nodig zijn, met behulp van een formaat dat een Presentation Definition wordt genoemd.
- Goedkeuring door de gebruiker: De wallet-app presenteert het verzoek aan de houder, die beoordeelt wat er wordt gevraagd en de openbaarmaking expliciet goedkeurt. De houder kan ervoor kiezen om alleen het noodzakelijke te delen. Deze goedkeuring in de wallet is iets anders dan toestemming als grondslag onder de AVG: de relying party heeft een eigen AVG-grondslag nodig voor de verwerking van de ontvangen gegevens.
- Aanmaken van de presentatie: De wallet unit maakt een verifieerbare presentatie aan met de goedgekeurde attributen, cryptografisch ondertekend om authenticiteit en tamper-evidentie te bewijzen.
- Respons en validatie: De wallet instance stuurt de presentatie terug naar de relying party via een beveiligde redirect of een direct post-eindpunt. De relying party voert vervolgens drie afzonderlijke controles uit: verificatie van de handtekening van de uitgever tegen de relevante nationale trusted list, controle van de intrekkingsstatus via de statusinformatie van de uitgever, en verificatie van de wallet unit attestation om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste controle kan volledig offline plaatsvinden.
Deze stroom weerspiegelt het principe van selective disclosure dat centraal staat in eIDAS 2.0 en het EUDI-wallet-ontwerp. Een gebruiker die bewijst dat hij of zij ouder is dan 18 jaar, hoeft zijn of haar volledige geboortedatum, adres of andere persoonsgegevens niet te delen. Alleen de minimaal noodzakelijke informatie verlaat de wallet unit.
Wat is het verschil tussen OID4VP en OID4VCI?
OID4VP en OID4VCI richten zich op twee verschillende fasen van de attestatie-levenscyclus. OID4VCI (OpenID for Verifiable Credential Issuance) regelt hoe attestaties worden uitgegeven aan een wallet instance, terwijl OID4VP regelt hoe die attestaties later worden gepresenteerd aan een relying party. Samen vormen ze het kernprotocolpaar voor het EUDI-wallet-ecosysteem, maar ze bedienen tegengestelde richtingen van gegevensstroom.
Concreet: OID4VCI wordt gebruikt wanneer een overheidsinstantie een digitaal rijbewijs uitgeeft aan de wallet instance van een burger. OID4VP wordt gebruikt wanneer diezelfde burger dat rijbewijs presenteert aan een autoverhuurbedrijf om te bewijzen dat hij bevoegd is om te rijden. Het uitgifteprotocol en het presentatieprotocol zijn ontworpen om samen te werken, maar functioneren onafhankelijk van elkaar.
Voor organisaties die zich voorbereiden op eIDAS 2.0-naleving is dit onderscheid praktisch relevant, omdat de twee protocollen verschillende technische integraties vereisen. Een attestatie-uitgever zoals een nationale autoriteit of een bank moet OID4VCI implementeren. Een relying party die attestaties wil accepteren en verifiëren, moet OID4VP implementeren. Veel organisaties zullen beide moeten implementeren, afhankelijk van hun rol in het ecosysteem. Dit onderscheid vroeg begrijpen helpt teams hun technische roadmap nauwkeuriger te plannen.
Hoe gaat OID4VP om met vertrouwen en authenticatie van de relying party?
OID4VP regelt vertrouwen door te vereisen dat relying parties zichzelf authenticeren voordat een wallet instance reageert op een presentatieverzoek. Onder eIDAS 2.0 en CIR (EU) 2025/848 van 6 mei 2025 moeten relying parties zich registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging en een ondertekend verzoek indienen dat de wallet kan valideren. Dit betekent dat de wallethouder kan zien wie om zijn of haar gegevens vraagt en kan bevestigen dat de relying party een geregistreerde, erkende entiteit is voordat er iets wordt gedeeld.
In de praktijk publiceert een relying party zijn metadata, inclusief zijn publieke sleutel en de typen attestaties waarvoor hij is geregistreerd, op een manier die wallet instances kunnen ontdekken en verifiëren. Wanneer een presentatieverzoek binnenkomt, controleert de wallet unit de identiteit van de relying party aan de hand van de vertrouwensketen voordat de gebruiker zelfs maar wordt gevraagd. Belangrijk daarbij is dat een relying party per intended use registreert welke attributen en attestaties worden opgevraagd. Een verzoek buiten deze geregistreerde scope kan door de wallet worden geweigerd en kan gevolgen hebben voor de registratie.
Binnen het eIDAS 2.0-kader verbindt deze vertrouwensketen zich met de nationale en Europese vertrouwensinfrastructuur via nationale trusted lists volgens ETSI TS 119 612, samengebracht in de EU List of Trusted Lists. Relying parties die actief zijn in gereguleerde sectoren zoals de gezondheidszorg of overheidsdiensten moeten voldoen aan specifieke registratie- en autorisatievereisten voordat zij gevoelige attribuutgegevens kunnen opvragen. Dit geeft zowel gebruikers als toezichthouders de zekerheid dat attestatiepresentaties niet kunnen worden aangevraagd door ongeregistreerde partijen. Een leverancier die walletdata technisch namens een klant verwerkt, wordt daardoor niet automatisch zelf relying party. De registratieplicht ligt bij de organisatie die de dienst aan de eindgebruiker levert.
Welke attestatieformaten ondersteunt OID4VP onder eIDAS 2.0?
Onder eIDAS 2.0 ondersteunt OID4VP twee primaire attestatieformaten: ISO/IEC 18013-5 mdoc (voor proximity-presentaties zoals het mobiele rijbewijs) en SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credentials). Beide formaten zijn opgenomen in het EUDI Wallet Architecture and Reference Framework en zijn getest in de grootschalige pilotprogramma’s die liepen tot en met 2025.
De twee formaten dienen enigszins verschillende doeleinden en contexten:
- mdoc (ISO/IEC 18013-5): Oorspronkelijk ontwikkeld voor mobiele rijbewijzen, is dit formaat goed geschikt voor proximity-presentaties, zoals het tonen van een identiteitsdocument op een fysieke locatie via Bluetooth of NFC. Voor online presentaties van mdoc is ISO/IEC TS 18013-7 relevant. Het formaat is sterk gestructureerd en breed ondersteund in gebruiksscenario’s voor identiteitsdocumenten.
- SD-JWT VC: Een JSON-gebaseerd formaat ontworpen voor online attestatiepresentaties. Het ondersteunt selective disclosure van nature, wat betekent dat de houder individuele attributen kan onthullen zonder de volledige attestatie bloot te stellen. Dit formaat is bijzonder relevant voor digitale onboarding, authenticatie en gegevensdeling in online diensten.
Beide formaten zijn cryptografisch ondertekend, waardoor de attribuutgegevens tamper-evident zijn tussen uitgifte en presentatie. De keuze van het formaat hangt af van het gebruiksscenario: proximity-interacties hebben de voorkeur voor mdoc, terwijl online en grensoverschrijdende digitale diensten neigen naar SD-JWT VC. Organisaties die OID4VP implementeren, moeten beoordelen welk formaat of welke combinatie van formaten aansluit bij hun specifieke verificatiescenario’s. Het High Assurance Interoperability Profile (HAIP) geeft daarbij aanvullende richting voor interoperabele implementaties.
Wat hebben organisaties nodig om OID4VP te implementeren voor eIDAS 2.0-naleving?
Om OID4VP te implementeren voor eIDAS 2.0-naleving hebben organisaties drie fundamentele elementen nodig: technische integratie met het OID4VP-protocol, registratie onder CIR (EU) 2025/848 bij de bevoegde nationale autoriteit en afstemming op de attestatieformaten en presentatiedefinities die door hun sector worden vereist. De exacte vereisten zijn afhankelijk van of de organisatie optreedt als relying party, uitgever of beide binnen het EUDI-wallet-ecosysteem.
Vanuit technisch perspectief moeten relying parties een OID4VP-compatibel verificatie-eindpunt bouwen of integreren, ondersteuning implementeren voor de relevante attestatieformaten (mdoc en/of SD-JWT VC) en ervoor zorgen dat hun systemen drie afzonderlijke controles kunnen uitvoeren: verificatie van de handtekening van de uitgever tegen de relevante nationale trusted list, controle van de intrekkingsstatus via statusinformatie van de uitgever en verificatie van de wallet unit attestation om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste controle kan volledig offline plaatsvinden. Dit houdt doorgaans in dat er wordt samengewerkt met aanbieders van identiteitsplatforms of open-source toolkits die zijn afgestemd op de ARF-specificaties.
Vanuit compliance- en governanceperspectief moeten organisaties zich registreren als relying party onder CIR (EU) 2025/848 bij de bevoegde nationale autoriteit, per intended use de minimale attributen definiëren die zij moeten opvragen (in lijn met de principes van gegevensminimalisatie onder de AVG en eIDAS 2.0) en audittrails van attestatiepresentaties bijhouden. Sectoren zoals overheidsdiensten en financiën hebben aanvullende sectorspecifieke vereisten die bovenop de basisverplichtingen van eIDAS 2.0 komen. Publieke instanties moeten genotificeerde EUDI-wallets accepteren voor onlinediensten waarvoor elektronische identificatie vereist is vanaf 24 december 2026. Voor gereguleerde private sectoren, waaronder banken, zorg en telecom, geldt de acceptatieplicht onder artikel 5f van eIDAS 2.0 vanaf 24 december 2027, binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Micro- en kleine ondernemingen met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal €10 miljoen zijn van deze private acceptatieplicht uitgezonderd.
Organisaties die nog in de beginfase zijn van het beoordelen van hun gereedheid, moeten beginnen met het in kaart brengen van hun huidige identiteitsverificatieprocessen aan de hand van het OID4VP-model, het identificeren van hiaten in de technische infrastructuur en het in contact treden met de relevante nationale autoriteiten in hun lidstaat. De beschikbare resources over digitale identiteitsstandaarden en EUDI Wallet-specificaties kunnen teams helpen een duidelijker beeld te vormen van wat implementatie in de praktijk inhoudt.
Hoe de ID Connector van TrustTech OID4VP-implementatie ondersteunt
De ID Connector van TrustTech is een integratie waarmee relying parties elke gecertificeerde Europese wallet accepteren, ongeacht de lidstaat van uitgifte, voor identificatie, login en gekwalificeerd tekenen. Acceptatie van de EUDI-wallet staat voorop; via dezelfde koppeling lopen ook andere identiteitsmiddelen, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.
Voor OID4VP-implementatie ondersteunt de ID Connector concreet de volgende technische taken:
- Verificatie tegen trusted lists: Automatische validatie van uitgeverhandtekeningen tegen de relevante nationale trusted lists en de EU List of Trusted Lists
- Controle van intrekkingsstatus: Raadpleging van statusinformatie van de uitgever om te bevestigen dat een attestatie op het moment van presentatie geldig is
- Validatie van de wallet unit attestation: Verificatie dat de presenterende wallet draait op een gecertificeerde wallet solution
- Bewaking van de geregistreerde attributenscope: Controle dat verzoeken beperkt blijven tot de attributen waarvoor de relying party is geregistreerd onder CIR (EU) 2025/848
- Ondersteuning van mdoc en SD-JWT VC: Verwerking van beide door de ARF voorgeschreven attestatieformaten voor zowel proximity- als online presentatiescenario’s
- Gekwalificeerd tekenen via een aangesloten QTSP: Mogelijkheid voor gebruikers om een gekwalificeerde elektronische handtekening te plaatsen via een aangesloten qualified trust service provider
De ID Connector is relevant voor relying parties in financiële dienstverlening, gezondheidszorg, farma en overheid die zich voorbereiden op de deadlines van 24 december 2026 en 24 december 2027. Neem contact op met TrustTech om te bespreken hoe jouw organisatie de ID Connector kan inzetten voor OID4VP en eIDAS 2.0-naleving.