Je kunt EUDI Wallet-integratie vandaag al testen met de open-source referentie-implementatie die door de Europese Commissie is gepubliceerd, nationale sandboxomgevingen en conformiteitstesttools die zijn gebouwd rond het Architecture and Reference Framework (ARF). Wachten tot nationale wallets breed beschikbaar zijn, is geen vereiste om zinvol integratiewerk te doen. De testinfrastructuur die al beschikbaar is, stelt relying parties in staat om protocollen, credential-formaten en gebruikersstromen te valideren ruim vóór de deadline van 24 december 2026 voor acceptatie door de publieke sector.
Voor organisaties in financiële dienstverlening, gezondheidszorg, overheid en andere gereguleerde sectoren betekent nu beginnen met integratietesten minder verrassingen wanneer gecertificeerde wallets in productie komen. De onderstaande secties beschrijven de beschikbare omgevingen, de referentie-implementatie, de te valideren standaarden, de scenario’s die het testen waard zijn en hoe je afgestemd blijft op conformiteitsvereisten terwijl het framework zich blijft ontwikkelen.
Welke testomgevingen bestaan er vandaag voor EUDI Wallet-integratie?
Er zijn momenteel verschillende testomgevingen beschikbaar voor EUDI Wallet-integratie. De Europese Commissie onderhoudt een open-source referentie-implementatie die elke organisatie lokaal kan draaien of op afstand mee kan verbinden. Nationale sandboxomgevingen komen beschikbaar in een groeiend aantal lidstaten, en de Large Scale Pilots die liepen van 2023 tot 2025 hebben herbruikbare testinfrastructuur en gedocumenteerde bevindingen opgeleverd die de huidige testpraktijk informeren.
Het meest toegankelijke startpunt is de referentie-implementatie van de Commissie, die een wallet instance, een issuer-component en een verifier-component bevat. Deze drie onderdelen samen stellen een relying party in staat om de volledige credential-presentatiestroom te simuleren zonder dat een live nationale wallet nodig is. De referentie-implementatie is open source, zodat teams precies kunnen inzien hoe de protocollen zijn geïmplementeerd en de verifier-component kunnen aanpassen aan hun eigen systeemarchitectuur.
Naast de referentie-implementatie hebben sommige lidstaten developer-sandboxen gepubliceerd die zijn gekoppeld aan hun nationale wallet-programma’s. Oostenrijks ID Austria is al live in productie, en Denemarken’s AltID draait sinds juni 2026 naast MitID. Nederland ontwikkelt de open-source NL Wallet, met een testomgeving beschikbaar voor relying parties die willen valideren tegen een wallet gebouwd op DigiD- en eHerkenning-infrastructuur. De beschikbaarheid en volwassenheid van deze nationale sandboxen variëren aanzienlijk, dus het is de moeite waard om de actuele status van elke sandbox te controleren voordat je je vastlegt op een specifieke omgeving.
De tweede golf Large Scale Pilots, WE BUILD en APTITUDE, is in 2025 van start gegaan en omvat zakelijke wallets, betalingen, reizen, ticketing en voertuigregistratie. Deze pilots genereren echte interoperabiliteitsdata en technische bevindingen die terugvloeien in het ARF en de implementing acts. Organisaties kunnen niet deelnemen aan de oorspronkelijke vier consortia, maar de gepubliceerde resultaten van alle pilotgolven zijn openbaar beschikbaar en bieden concrete testcases en protocol-validatieresultaten.
Hoe werkt de EUDI Wallet-referentie-implementatie als testtool?
De EUDI Wallet-referentie-implementatie is een set open-source componenten gepubliceerd door de Europese Commissie die het volledige wallet-ecosysteem simuleert: een wallet instance, een credential-issuer en een verifier. Het implementeert de technische specificaties uit het ARF en de implementing acts, waardoor het de dichtstbijzijnde beschikbare benadering is van hoe gecertificeerde wallets zich in productie zullen gedragen.
Voor een relying party is de verifier de meest relevante component. Die verwerkt de presentatieverzoekstroom, valideert de cryptografische handtekeningen op inkomende credentials en controleert de wallet unit attestation die bevestigt dat de presenterende wallet draait op een gecertificeerde wallet solution. Door je eigen dienst te verbinden met de referentieverifier kun je de integratielogica testen voordat er een echte wallet bij betrokken is.
De referentie-implementatie ondersteunt beide credential-formaten die door het ARF zijn voorgeschreven: mdoc (ISO/IEC 18013-5 voor nabijheid, ISO/IEC TS 18013-7 voor online presentatie) en SD-JWT VC. Testen tegen beide formaten is belangrijk omdat wallet-providers en credential-issuers beide kunnen gebruiken, en je verifier beide correct moet kunnen verwerken. De implementatie dekt ook de uitwisselingsprotocollen OID4VCI voor credential-uitgifte en OID4VP voor credential-presentatie, de normatieve protocollen voor het EUDI Wallet-ecosysteem.
Een praktisch voordeel van de referentie-implementatie is dat teams er snel mee kunnen itereren. Je kunt je integratie aanpassen, een presentatiestroom opnieuw uitvoeren en de protocolberichten inspecteren zonder dat je hoeft te coördineren met een wallet-provider of een nationale autoriteit. Het ARF staat momenteel op versie 3.0.0 en wordt voortdurend bijgewerkt, dus het is de moeite waard om de repository bij te houden op wijzigingen die het verifier-gedrag tussen testcycli beïnvloeden.
Welke standaarden en protocollen zijn essentieel om te valideren tijdens het testen?
De belangrijkste standaarden en protocollen om te valideren tijdens EUDI Wallet-integratietesten zijn OID4VP voor credential-presentatie, OID4VCI voor credential-uitgifte, SD-JWT VC en mdoc als de twee verplichte credential-formaten, en het High Assurance Interoperability Profile (HAIP) dat beide protocollen profileert voor gebruik met hoge zekerheid. Het samen valideren van al deze elementen bevestigt dat je integratie werkt met elke gecertificeerde Europese wallet, ongeacht welke lidstaat die heeft uitgegeven.
Hier is wat elk element omvat en waarom het relevant is bij het testen:
- OID4VP (OpenID for Verifiable Presentations): Het protocol dat je verifier gebruikt om credential-presentaties van een wallet op te vragen en te ontvangen. Test of je presentatieverzoek correct is opgesteld en of je dienst de respons correct verwerkt, inclusief selective disclosure van individuele attributen.
- OID4VCI (OpenID for Verifiable Credential Issuance): Relevant als je organisatie credentials uitgeeft naast het verifiëren ervan. Ook pure relying parties profiteren van inzicht in uitgiftestromen om te begrijpen wat ze ontvangen.
- SD-JWT VC: Het credential-formaat gebaseerd op het IETF SD-JWT-mechanisme, gebruikt voor online presentatie. Valideer of je verifier de openbaargemaakte claims correct parseert en de handtekening van de issuer controleert.
- mdoc (ISO/IEC 18013-5 en ISO/IEC TS 18013-7): Het andere verplichte formaat. 18013-5 dekt nabijheidspresentatie via BLE of NFC; 18013-7 dekt online presentatie. Test beide als je use case in-person-scenario’s omvat.
- HAIP (High Assurance Interoperability Profile): Profileert OID4VCI en OID4VP voor het hoge zekerheidsniveau dat eIDAS 2.0 vereist. Conformiteit met HAIP is wat een wallet-klare integratie onderscheidt van een generieke OpenID-implementatie.
Valideer tijdens het testen ook de drie verificatiecontroles die elke productie-integratie moet uitvoeren: de handtekening van de issuer tegen de nationale trusted list (ETSI TS 119 612), de intrekkingsstatus via de statusinformatie die de issuer afzonderlijk publiceert, en de wallet unit attestation die bevestigt dat de presenterende wallet draait op een gecertificeerde wallet solution. Alleen de eerste van deze werkt volledig offline. Het overslaan van de intrekkingscontrole betekent dat je dienst credentials kan accepteren die al zijn ingetrokken.
Welke relying party-scenario’s moeten worden getest voordat wallets live gaan?
Voordat wallets live gaan, moeten relying parties minimaal drie kernscenario’s testen: identiteitsverificatie bij onboarding, wallet-gebaseerde login en gekwalificeerd ondertekenen. Elk scenario komt overeen met een afzonderlijke protocolstroom en een afzonderlijke set attributen, en elk heeft zijn eigen compliance-implicaties onder eIDAS 2.0 en CIR (EU) 2025/848.
Het vroeg testen van deze scenario’s brengt ook een praktische beperking aan het licht die veel organisaties laat ontdekken: de reikwijdte van attributen die je kunt opvragen is vastgelegd bij registratie. Onder CIR (EU) 2025/848 moeten relying parties zich registreren bij een nationale autoriteit voordat ze wallet-gegevens opvragen, en bij registratie specificeren ze exact welke attributen en attestations ze per beoogd gebruik zullen opvragen. De wallet controleert elk verzoek aan de hand van die geregistreerde reikwijdte en stopt de presentatie als het verzoek die overschrijdt. Meer opvragen dan geregistreerd is grond voor intrekking van de registratie. Het uitvoeren van testscenario’s binnen je geregistreerde reikwijdte vóór go-live bevestigt dat je integratie binnen de grenzen blijft.
De scenario’s die het waard zijn om op te nemen in een gestructureerd testplan zijn:
- PID-gebaseerde identificatie: Vraag de minimale set Person Identification Data-attributen op die nodig zijn voor je use case. Verifieer dat selective disclosure werkt zoals verwacht en dat je dienst geen attributen opvraagt buiten je geregistreerde reikwijdte.
- Wallet-gebaseerde login: Test de authenticatiestroom op het hoge zekerheidsniveau dat de wallet biedt. Bevestig dat je bestaande logininfrastructuur de wallet-gebaseerde bewering kan accepteren en dat accountkoppeling werkt via een stabiel attribuut of pseudoniem in plaats van een wallet unit-identifier.
- Gekwalificeerd ondertekenen: Als je use case gekwalificeerde elektronische handtekeningen omvat, test dan de stroom waarbij identiteit wordt vastgesteld via de wallet en de handtekening wordt geproduceerd door een gekwalificeerde trust service provider. De wallet verzorgt de identiteitscontrole; de QTSP produceert de handtekening.
- Grensoverschrijdende presentatie: Test met credentials uitgegeven door een wallet uit een andere lidstaat. Dit valideert of je verifier de trusted list-vermelding van de issuer correct oplost en credential-formaten van buiten je eigen jurisdictie verwerkt.
- Pseudoniem-only stroom: Waar identificatie niet wettelijk vereist is, test dan of je dienst een pseudoniem accepteert en de interactie niet weigert. Een pseudoniem weigeren waar identificatie niet vereist is, is niet toegestaan onder eIDAS 2.0.
Organisaties in financiële dienstverlening en gezondheidszorg moeten bijzondere aandacht besteden aan de discipline rondom de reikwijdte van attributen, omdat die sectoren onderworpen zijn aan de private acceptatieplicht per 24 december 2027 en te maken krijgen met toetsing op dataminimalisatie vanuit zowel eIDAS als de AVG.
Hoe kunnen organisaties afgestemd blijven op de conformiteitsvereisten van de EUDI Wallet?
Organisaties kunnen afgestemd blijven op de conformiteitsvereisten van de EUDI Wallet door ARF-updates bij te houden, de implementing acts gepubliceerd onder eIDAS 2.0 te monitoren en integratietesten uit te voeren tegen de referentie-implementatie telkens wanneer de ARF-versie wijzigt. Het ARF staat momenteel op versie 3.0.0 en wordt vaker bijgewerkt dan de wetgeving zelf, dus een testsuite die zes maanden geleden slaagde, moet mogelijk opnieuw worden uitgevoerd tegen een nieuwere versie.
Het conformiteitsbeoordelingskader dat samen met het ARF is gepubliceerd, definieert wat gecertificeerde wallet solutions moeten aantonen. Als relying party ben je zelf niet onderworpen aan conformiteitscertificering, maar je integratie moet de protocollen en formaten die gecertificeerde wallets gebruiken correct implementeren. De praktische implicatie is dat je verifier-logica actueel moet blijven met de normatieve specificaties, met name naarmate implementing acts in 2026 worden gewijzigd.
Een aantal concrete stappen helpt om de afstemming in de loop van de tijd te handhaven:
- Abonneer je op updates van de European Digital Identity Cooperation Group, die het ARF beheert en open discussieonderwerpen publiceert over privacy, zero-knowledge proofs, wallet-to-wallet-interacties en andere zich ontwikkelende gebieden.
- Voer je testsuite opnieuw uit tegen de referentie-implementatie telkens wanneer een nieuwe ARF-versie wordt uitgebracht. Besteed bijzondere aandacht aan wijzigingen in het wallet unit attestation-formaat en de logica voor trusted list-resolutie.
- Monitor de EU List of Trusted Lists (LOTL) en de nationale trusted lists (ETSI TS 119 612) op nieuwe vermeldingen naarmate lidstaten hun wallet solutions notificeren. Je verifier moet issuer-handtekeningen in productie oplossen aan de hand van deze lijsten.
- Volg de Lists of Trusted Entities (LoTE, ETSI TS 119 602) die zijn geïntroduceerd in ARF v3.0.0 en die naast de trusted lists fungeren als vertrouwensankers voor wallet-gerelateerde entiteiten.
- Herzie je geregistreerde attribuutreikwijdte onder CIR (EU) 2025/848 telkens wanneer je use case wijzigt. Een wijziging in de attributen die je opvraagt, vereist dat je je registratie bijwerkt voordat de nieuwe reikwijdte in productie van kracht wordt.
Voor overheidsorganisaties die te maken hebben met de deadline van 24 december 2026 voor publieke acceptatie, is conformiteitsafstemming tijdkritisch. Voor relying parties in de private sector in gereguleerde sectoren is de deadline 24 december 2027, maar het registratieproces onder CIR (EU) 2025/848 moet ruim vóór die datum worden gestart, omdat de toegangscertificaten die na registratie worden uitgegeven, zijn wat wallets bij elk gegevensverzoek controleren.
Hoe ondersteunt de ID Connector EUDI Wallet-integratietesten
De ID Connector is een integratie waarmee relying parties elke gecertificeerde Europese wallet kunnen accepteren, ongeacht welke lidstaat die heeft uitgegeven, voor identificatie, login en gekwalificeerd ondertekenen. EUDI Wallet-acceptatie staat voorop; dezelfde interface ondersteunt ook andere ID’s, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.
Voor organisaties die de hierboven beschreven testscenario’s doorlopen, verzorgt de ID Connector de protocol- en vertrouwensbeheerlaag die zich bevindt tussen je bedrijfsprocessen en het wallet-ecosysteem. Concreet dekt het:
- Handtekeningvalidatie van inkomende credentials tegen de nationale trusted lists en de LOTL
- Intrekkingsstatuscontroles via de door de issuer gepubliceerde statusinformatie
- Wallet unit attestation-validatie, waarmee wordt bevestigd dat de presenterende wallet draait op een gecertificeerde wallet solution
- Handhaving van de geregistreerde attribuutreikwijdte, zodat je integratie binnen de grenzen blijft die bij registratie zijn vastgelegd onder CIR (EU) 2025/848
- Hergebruik van geverifieerde identiteitsgegevens voor identificatie, login en ondertekeningsstromen binnen dezelfde sessie
Dit geldt voor de sectoren waar de private acceptatieplicht het zwaarst weegt: financiële dienstverlening, gezondheidszorg, farmacie en overheid. In plaats van elk van deze verificatiecontroles afzonderlijk te bouwen en te onderhouden, biedt de ID Connector ze via één verbinding die het volledige wallet-ecosysteem dekt naarmate het zich uitbreidt over de lidstaten.
Om te bespreken hoe de ID Connector past bij je integratietijdlijn en testomgeving, neem contact op met TrustTech.