Tijdens een enterprise EUDI Wallet-integratiedemo moet een leverancier live wallet-acceptatie demonstreren voor meerdere gecertificeerde Europese wallets, laten zien hoe geverifieerde identiteitsgegevens doorstromen naar echte bedrijfsprocessen, en aantonen dat hun integratie de eIDAS 2.0-nalevingsvereisten namens jou afhandelt. De demo moet identificatie, inloggen en gekwalificeerd ondertekenen omvatten in een werkende omgeving, niet alleen slides of wireframes. De vragen hieronder lopen precies door wat je per onderdeel moet controleren.
Welke mogelijkheden moeten live en werkend zijn tijdens de demo?
Een geloofwaardige enterprise EUDI Wallet-integratiedemo moet drie kernfunctionaliteiten laten zien die draaien in een echte omgeving: identiteitsverificatie op het moment van onboarding, wallet-gebaseerde authenticatie op een hoog betrouwbaarheidsniveau, en gekwalificeerd ondertekenen binnen één sessie. Als een van deze alleen als mockup wordt getoond of wordt omschreven als “binnenkort beschikbaar”, beschouw dat dan als een tekortkoming.
Vraag de leverancier specifiek het volgende te demonstreren:
- Een gebruiker die een gecertificeerde EUDI Wallet presenteert en het systeem dat de identiteitsattributen accepteert die cryptografisch zijn ondertekend door de uitgevende partij
- Een inlogflow met wallet-gebaseerde authenticatie, geïntegreerd in een bestaande sessiebeheeropzet
- Een gekwalificeerde ondertekeningsflow waarbij de identiteit die tijdens onboarding is vastgesteld doorloopt naar de ondertekeningsstap zonder dat een tweede identiteitscontrole nodig is
- Acceptatie van wallets uit meer dan één lidstaat, niet alleen één nationale wallet
De identiteitsattributen moeten al geverifieerd bij de bron aankomen. Dat betekent dat de gegevens cryptografisch zijn ondertekend door de partij die ze heeft uitgegeven, zodat jouw bedrijfsproces niet opnieuw hoeft te verifiëren wat de wallet al heeft bevestigd. Als de leverancier dit niet live kan tonen, is de integratie niet klaar voor productie.
Hoe moet een leverancier eIDAS 2.0- en ARF-naleving aantonen?
Een leverancier toont eIDAS 2.0- en Architecture and Reference Framework (ARF)-naleving aan door te demonstreren dat hun integratie de drie verificatiecontroles uitvoert die de verordening vereist, en door te laten zien dat hun systeem opereert binnen de geregistreerde attribuutreikwijdte die is vastgelegd onder CIR (EU) 2025/848. Naleving is geen certificaat dat de leverancier bezit; het is een set gedragingen die het systeem bij elk verzoek correct moet uitvoeren.
Vraag de leverancier elk van de drie verificatiestappen tijdens de demo te doorlopen:
- Verificatie van de uitgevershandtekening aan de hand van de nationale trusted list van de lidstaat die de attestation heeft uitgegeven
- Controle van de intrekkingsstatus aan de hand van de statusinformatie die door de uitgever is gepubliceerd, omdat een geldige handtekening niet betekent dat de attestation nog actief is
- Validatie van de wallet unit attestation, waarmee wordt bevestigd dat de wallet die de gegevens presenteert draait op een gecertificeerde wallet solution
Alleen de eerste controle werkt volledig offline. Het overslaan van de tweede betekent dat jouw systeem ingetrokken attestations zou kunnen accepteren. Vraag de leverancier expliciet hoe zij intrekking afhandelen en of die controle bij elke transactie wordt uitgevoerd.
Aan de registratiekant moeten relying parties onder CIR (EU) 2025/848 zich registreren bij een nationale autoriteit voordat ze walletgegevens opvragen, en de reikwijdte van de attributen die ze mogen opvragen ligt vast bij registratie. De integratie van de leverancier moet die reikwijdte automatisch afdwingen en elk verzoek dat die reikwijdte zou overschrijden afwijzen of markeren. Het opvragen van meer attributen dan geregistreerd is grond voor intrekking van de registratie zelf.
Welke interoperabiliteitsnormen moet de demo valideren?
De demo moet ondersteuning valideren voor beide credential-formaten die door de ARF zijn voorgeschreven: mdoc (ISO/IEC 18013-5 voor nabijheidspresentatie en ISO/IEC TS 18013-7 voor onlinepresentatie) en SD-JWT VC. Een leverancier die slechts één formaat ondersteunt, zal hiaten laten ontstaan omdat verschillende lidstaten en gebruikssituaties op beide vertrouwen.
Naast de formaten zijn de uitwisselingsprotocollen van belang. OID4VP verzorgt de presentatie van credentials en OID4VCI verzorgt de uitgifte. Vraag de leverancier een volledige presentatieflow te demonstreren met OID4VP, en bevestig dat de integratie deze protocollen profileert volgens het High Assurance Interoperability Profile (HAIP) waar gebruikssituaties met hoge betrouwbaarheid in het spel zijn.
Selective disclosure is een praktische vereiste, geen optionele functie. De demo moet laten zien dat een gebruiker alleen de attributen deelt die nodig zijn voor een specifieke transactie, bijvoorbeeld het bevestigen van leeftijd zonder een geboortedatum te onthullen, of het delen van een naam zonder een adres te delen. Als de integratie van de leverancier standaard volledige attribuutsets opvraagt, is dat in strijd met het beginsel van dataminimalisatie en met de geregistreerde reikwijdteregels onder CIR (EU) 2025/848.
Bevestig ten slotte dat de integratie wallets accepteert van overal in de EU, niet alleen uit één of twee landen. De ARF vereist interoperabiliteit tussen alle gecertificeerde wallet solutions, ongeacht welke lidstaat ze heeft uitgegeven.
Welke enterprise-integratiescenario’s moeten in de demo worden getest?
Enterprise-teams moeten de scenario’s testen die direct aansluiten op hun eigen bedrijfsprocessen: klantregistratie met identiteitsverificatie, authenticatie van terugkerende gebruikers en het ondertekenen van documenten met rechtskracht. Elk scenario moet van begin tot eind worden doorlopen in de demo-omgeving, niet alleen theoretisch worden beschreven.
Voor onboarding moet de demo laten zien dat geverifieerde identiteitsattributen vanuit de wallet aankomen en zonder handmatige herinvoer of aanvullende verificatiestappen worden doorgegeven aan het bedrijfsproces. De gegevens zijn al ondertekend door de uitgevende autoriteit, zodat het onboardingsysteem er direct op kan handelen.
Voor authenticatie moet de demo wallet-gebaseerd inloggen op het hoogste betrouwbaarheidsniveau laten zien, geïntegreerd in een bestaande inlogflow. De kernvraag is of de integratie van de leverancier past binnen jouw huidige authenticatiearchitectuur of dat die moet worden vervangen.
Voor ondertekening vereist een gekwalificeerde elektronische handtekening een identiteitscontrole met hoge betrouwbaarheid. Als die identiteit al via de wallet is vastgesteld, moet de ondertekeningsstap in dezelfde sessie volgen zonder de gebruiker te vragen zich opnieuw te identificeren. Vraag de leverancier deze continuïteit expliciet te demonstreren. Let op: de gekwalificeerde handtekening zelf wordt geproduceerd door een gekwalificeerde trust service provider; de integratie van de leverancier verbindt de identiteitslaag met die ondertekeningsdienst.
Test ook wat er gebeurt wanneer een gebruiker een wallet presenteert uit een andere lidstaat dan jouw primaire markt. Grensoverschrijdende acceptatie is een kernvereiste van eIDAS 2.0, en de demo moet bevestigen dat dit werkt zonder handmatige tussenkomst.
Welke vragen moeten enterprise-teams stellen over beveiliging en gegevensbeheer?
Enterprise-teams moeten vragen hoe de leverancier de handhaving van de attribuutreikwijdte regelt, welke gegevens na een transactie worden gelogd en hoe de integratie zich gedraagt wanneer een wallet unit attestation mislukt. Deze vragen onthullen of het systeem van de leverancier is gebouwd voor productienaleving of alleen voor demo-omstandigheden.
Over attribuutreikwijdte: de integratie mag alleen de attributen opvragen die jouw organisatie heeft geregistreerd onder CIR (EU) 2025/848. Vraag de leverancier hoe het systeem reikwijdtecreep voorkomt en wat er gebeurt als een configuratiefout ertoe zou leiden dat een verzoek de geregistreerde reikwijdte overschrijdt.
Over logging: relying parties moeten loggen dat ze binnen hun geregistreerde attribuutreikwijdte zijn gebleven, niet de volledige set gepresenteerde attributen. Het loggen van de volledige gepresenteerde dataset maakt selective disclosure aan de achterkant ongedaan. Vraag de leverancier wat hun integratie standaard logt en of dat kan worden geconfigureerd.
Over het mislukken van wallet unit attestation: als de wallet die credentials presenteert niet draait op een gecertificeerde wallet solution, moet de transactie worden afgewezen. Vraag de leverancier dit scenario in de demo te activeren en te laten zien hoe het systeem reageert.
Een belangrijk onderscheid voor teams die leveranciers evalueren als verwerkers: de registratieverplichting onder CIR (EU) 2025/848 rust bij de organisatie die de dienst aan de gebruiker levert, niet bij de leverancier die walletgegevens namens die organisatie verwerkt. Een leverancier die optreedt als verwerker onder artikel 28 AVG is zelf geen relying party. Zorg ervoor dat jouw contracten dit duidelijk weerspiegelen.
Hoe beoordeel je de langetermijngereedheid van een leverancier voorbij de demo?
Langetermijngereedheid hangt af van drie dingen: hoe de leverancier ARF-updates bijhoudt, hoe zij omgaan met de toevoeging van nieuwe gecertificeerde wallets vanuit de hele EU, en of hun roadmap rekening houdt met de deadline voor acceptatie door de private sector op 24 december 2027.
De ARF bevindt zich momenteel op versie 3.0.0 en blijft zich ontwikkelen naarmate implementing acts worden verfijnd. Vraag de leverancier hoe zij ARF-wijzigingen monitoren en hoe snel die wijzigingen worden doorgevoerd in de integratie. Een leverancier zonder duidelijk antwoord op deze vraag zal waarschijnlijk na verloop van tijd nalevingsschulden creëren.
Over wallet-dekking: het aantal gecertificeerde EUDI Wallets zal groeien naarmate lidstaten hun oplossingen uitrollen. Jouw integratie moet nieuwe gecertificeerde wallets accepteren zonder dat voor elke wallet een aangepaste update nodig is. Vraag de leverancier hoe trustbeheer voor nieuwe wallets wordt afgehandeld en of dat automatisch gebeurt via de trusted lists of handmatige configuratie vereist.
Over de regelgevingstijdlijn: gereguleerde private-sectororganisaties in financiële dienstverlening, gezondheidszorg, telecom, energie, transport en andere sectoren die worden genoemd in artikel 5f moeten EUDI Wallets accepteren vóór 24 december 2027, overal waar sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Zeer grote onlineplatforms onder de DSA staan voor dezelfde deadline. Micro- en kleine ondernemingen met minder dan 50 werknemers en een jaarlijkse omzet of balanstotaal van niet meer dan 10 miljoen euro zijn vrijgesteld. Vraag de leverancier hoe hun productroadmap aansluit op deze deadline en hoe hun updateproces eruitziet naarmate implementing acts zich blijven ontwikkelen tot 2026 en daarna.
Hoe de ID Connector jouw EUDI Wallet-leveranciersevaluatie ondersteunt
De ID Connector is een integratie waarmee relying parties elke gecertificeerde Europese wallet kunnen accepteren, ongeacht welke lidstaat die heeft uitgegeven, voor identificatie, inloggen 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.
Wanneer je de bovenstaande evaluatievragen toepast op de ID Connector, doet de integratie in de praktijk het volgende:
- Voert alle drie de verificatiecontroles uit bij elke transactie: uitgevershandtekening aan de hand van de nationale trusted list, intrekkingsstatus en wallet unit attestation
- Dwingt de geregistreerde attribuutreikwijdte automatisch af, zodat verzoeken niet kunnen overschrijden wat jouw organisatie heeft geregistreerd onder CIR (EU) 2025/848
- Ondersteunt beide door de ARF voorgeschreven credential-formaten, mdoc en SD-JWT VC, en de uitwisselingsprotocollen OID4VP en OID4VCI
- Draagt geverifieerde identiteitsgegevens door onboarding, authenticatie en ondertekening binnen één sessie, zonder dat de gebruiker zich opnieuw hoeft te identificeren
- Verzorgt trustbeheer voor nieuwe gecertificeerde wallets wanneer die worden toegevoegd in de hele EU, zonder dat voor elke wallet een aangepaste update nodig is
Organisaties in financiële dienstverlening, gezondheidszorg, overheid en farmacie gebruiken de ID Connector om geverifieerde identiteit te integreren in de bedrijfsprocessen die daarvan afhankelijk zijn. Om de integratie te zien draaien op jouw eigen scenario’s, neem contact op met TrustTech.