Hoe verifiëren bedrijven eIDAS 2.0 wallet-credentials?

Bedrijven verifiëren eIDAS 2.0 wallet-attestaties door op te treden als een relying party: ze sturen een presentatieverzoek naar de EUDI-wallet van een gebruiker, ontvangen een cryptografisch ondertekend antwoord en voeren een reeks validatiestappen uit aan de hand van nationale trusted lists en statusinformatie van de uitgever. De volledige uitwisseling vindt plaats in seconden. De onderstaande secties lichten elk onderdeel van dat proces in detail toe, van de betrokken technische standaarden tot de wettelijke verplichtingen die jouw organisatie op zich neemt wanneer je als relying party optreedt.

Wat gebeurt er tijdens het eIDAS 2.0 attestatie-verificatieproces?

Tijdens eIDAS 2.0 attestatie-verificatie stuurt een relying party een presentatieverzoek naar de EUDI-wallet van de gebruiker, vraagt de wallet de gebruiker om goedkeuring en om te selecteren welke attestaties worden gedeeld, waarna de wallet een cryptografisch ondertekend antwoord teruggeeft dat de relying party geautomatiseerd kan verifiëren. Er is geen handmatige documentcontrole of telefonische bevestiging nodig.

Zo werkt de stroom in de praktijk:

1. De relying party stuurt een presentatieverzoek. Via een gestandaardiseerd protocol geeft de relying party exact aan welke attributen zij nodig heeft, bijvoorbeeld een leeftijdsbevestiging, een beroepskwalificatie of een geverifieerd adres. Dit verzoek valt binnen de attributenscope die bij registratie is opgegeven.
2. De gebruiker beoordeelt en geeft goedkeuring. De wallet toont wat er wordt gevraagd. De gebruiker beslist of hij of zij de attestatie wil delen. Niets verlaat de wallet zonder expliciete goedkeuring van de gebruiker. Deze goedkeuring in de wallet is niet automatisch een AVG-toestemming als rechtsgrond; de relying party heeft een zelfstandige verwerkingsgrondslag nodig.
3. De wallet geeft een verifieerbare presentatie terug. Het antwoord is digitaal ondertekend door de attestatie-uitgever, wat een overheidsinstantie, een bank of een andere erkende uitgever kan zijn, en is gebonden aan de specifieke transactie.
4. De relying party voert drie afzonderlijke validatiestappen uit. Zij controleert de handtekening van de uitgever aan de hand van de relevante nationale trusted list, verifieert de intrekkingsstatus via statusinformatie van de uitgever, en valideert de wallet unit attestation om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste stap kan volledig offline plaatsvinden.

Een belangrijk gevolg van deze aanpak is dat de relying party geen onbewerkte identiteitsdocumenten opslaat. Zij ontvangt uitsluitend de attributen waarnaar zij heeft gevraagd, ondersteund door meerdere validatielagen, wat zowel het frauderisico als de verwerkingsverplichtingen onder de AVG aanzienlijk beperkt.

Welke soorten attestaties kunnen bedrijven opvragen uit een wallet?

Bedrijven kunnen elke attestatie opvragen die door een erkende uitgever in de EUDI-wallet van een gebruiker is opgeslagen. Het meest voorkomende type is de Person Identification Data (PID)-attestatie, die kernidentiteitsattributen zoals naam, geboortedatum en nationaliteit omvat. Naast PID kunnen wallets een breed scala aan Electronic Attribute Attestations (EAA’s) bevatten. Daarbinnen is onderscheid relevant: een Qualified EAA (QEAA) wordt uitgegeven door een gekwalificeerde trust service provider, een Public Body EAA (PuB-EAA) door een overheidsinstantie die op een trusted list staat, en een non-qualified EAA door andere erkende uitgevers.

Praktische voorbeelden van attestaties die bedrijven kunnen opvragen zijn:

• Leeftijdsverificatie (voor leeftijdsgebonden diensten of producten)
• Adresbewijs
• Beroepskwalificaties of -licenties
• Mobiele rijbewijzen
• Europese ziekteverzekeringskaart of socialezekerheidgegevens
• Academische diploma’s of certificaten
• Arbeidsstatus of werkgeversattestaties
• KYC-geverifieerde identiteitsgegevens voor financiële onboarding

Een belangrijk principe dat in eIDAS 2.0 is ingebouwd, is selective disclosure. Een relying party mag alleen de attributen opvragen die zij daadwerkelijk nodig heeft voor een specifiek, vooraf opgegeven doel. Als je alleen hoeft te bevestigen dat iemand ouder is dan 18, vraag je een leeftijdsattestatie op, niet de volledige geboortedatum van de gebruiker. Dit beschermt de privacy van gebruikers en beperkt jouw gegevensvoetafdruk, wat ook de naleving van de AVG vereenvoudigt.

Voor organisaties in gereguleerde sectoren zoals financiële dienstverlening is de mogelijkheid om een vooraf geverifieerde KYC-attestatie van een erkende uitgever te ontvangen praktisch relevant. Een klant die al een identiteitsverificatie bij zijn bank heeft doorlopen, kan die attestatie opnieuw gebruiken bij jouw organisatie. Of hergebruik van KYC-gegevens in een specifieke situatie volstaat, hangt af van de toepasselijke AML-regelgeving en sectorale vereisten; eIDAS 2.0 regelt dit niet zelfstandig. Organisaties in de financiële sector hebben veel te winnen bij dit model, mits zij de grenzen van eIDAS 2.0 op dit punt goed in kaart brengen.

Hoe wordt een bedrijf een geregistreerde relying party onder eIDAS 2.0?

Om als relying party EUDI-wallet-attestaties te mogen opvragen, moet een organisatie zich registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging, op grond van CIR (EU) 2025/848, de uitvoeringshandeling over de registratie van wallet-relying parties die op 6 mei 2025 is vastgesteld. Registratie is een voorwaarde voordat walletdata kan worden opgevraagd. Dit register staat los van de nationale trusted lists waarop uitgevers van attestaties worden bijgehouden.

Het registratieproces omvat doorgaans:

1. Het identificeren van de bevoegde nationale autoriteit. Elke lidstaat wijst een instantie aan die verantwoordelijk is voor het beheer van relying party-registraties binnen zijn jurisdictie.
2. Het indienen van een aanvraag met opgave van de attributenscope. De relying party verklaart per intended use welke attestatietypen en attributen zij van plan is op te vragen en voor welke doeleinden. Een verzoek buiten deze geregistreerde scope kan door de wallet worden geweigerd en kan gevolgen hebben voor de registratie.
3. Het ontvangen van een relying party-certificaat. Dit certificaat is ingebed in presentatieverzoeken zodat wallets en gebruikers de identiteit van de aanvrager kunnen verifiëren voordat er gegevens worden gedeeld.
4. Het handhaven van voortdurende naleving. Relying parties moeten blijven voldoen aan de vereisten van de verordening, inclusief gegevensminimalisatie, doelbinding en beveiligingsverplichtingen.

Vanuit het perspectief van gebruikerservaring is registratie ook functioneel relevant: EUDI-wallets tonen gebruikers de geverifieerde identiteit van de aanvragende partij voordat zij goedkeuring geven om iets te delen. Een niet-geregistreerde aanvrager zal een waarschuwing in de wallet activeren, wat er in de praktijk toe leidt dat de gebruiker het verzoek weigert. Registratie is daarmee zowel een wettelijke vereiste als een voorwaarde voor een werkende gebruikersstroom. 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.

Op welke technische standaarden is eIDAS 2.0 wallet-verificatie gebaseerd?

eIDAS 2.0 wallet-verificatie is gebaseerd op een reeks open, interoperabele technische standaarden die zijn uitgewerkt in het Architecture and Reference Framework (ARF), ontwikkeld door de Europese Commissie en de lidstaten. De juridisch bindende vereisten volgen uit Verordening (EU) 2024/1183, die Verordening (EU) 910/2014 wijzigt, en de bijbehorende uitvoeringshandelingen; de ARF geeft de technische uitwerking daarvan. De twee primaire attestatieformaten zijn mdoc (gebaseerd op ISO/IEC 18013-5 voor proximity-presentatie en ISO/IEC TS 18013-7 voor online presentatie) en SD-JWT VC (Selective Disclosure JSON Web Tokens voor verifiable credentials). Beide formaten ondersteunen selective disclosure en cryptografische binding aan de wallet unit.

Voor de uitwisselingsprotocollen die worden gebruikt tussen wallets en relying parties maakt het framework gebruik van:

• OID4VP (OpenID for Verifiable Presentations) voor online attestatie-presentatiestromen
• OID4VCI (OpenID for Verifiable Credential Issuance) voor het uitgeven van attestaties in wallets
• ISO/IEC 18013-5 proximity-protocollen voor persoonlijke, offline verificatiescenario’s

Het High Assurance Interoperability Profile (HAIP) specificeert welke combinaties van formaten en protocollen verplicht worden ondersteund voor interoperabiliteit binnen het EUDI-wallet-ecosysteem.

Trusted lists spelen een centrale rol in de technische architectuur. Wanneer een relying party een attestatie ontvangt, verifieert zij de handtekening van de uitgever aan de hand van de relevante nationale trusted list volgens ETSI TS 119 612, die op haar beurt is opgenomen in de EU List of Trusted Lists (LOTL). Daarnaast controleert zij de intrekkingsstatus via statusinformatie van de uitgever en valideert zij de wallet unit attestation. Alleen de handtekeningcontrole kan volledig offline plaatsvinden; de overige twee stappen vereisen contact met externe bronnen. Schrijf daarom niet zonder nuance dat een attestatie volledig kan worden geverifieerd zonder verbinding met externe systemen.

Voor organisaties die verificatie-infrastructuur bouwen of integreren, is inzicht in deze standaarden essentieel. Conforme wallet-SDK’s en verificatiebibliotheken handelen veel van de onderliggende complexiteit af. Het belangrijkste is het kiezen van een platform dat van de grond af op deze standaarden is gebouwd. Je kunt verkennen hoe TrustTech dit aanpakt in zijn identiteitsoplossingen.

Wat zijn de wettelijke verplichtingen voor bedrijven die wallet-attestaties verifiëren?

Bedrijven die EUDI-wallet-attestaties verifiëren, nemen een bepaalde reeks wettelijke verplichtingen op zich onder Verordening (EU) 2024/1183 en aanverwante EU-wetgeving. Als relying party ben je verantwoordelijk voor het verwerken van alleen de gegevens die je gemachtigd bent op te vragen, het gebruik ervan uitsluitend voor het verklaarde doel, en de bescherming ervan in overeenstemming met de AVG en toepasselijke sectorale regelgeving.

De kernverplichtingen omvatten:

• Gegevensminimalisatie: Je mag alleen de attributen opvragen die strikt noodzakelijk zijn voor jouw opgegeven doel. Meer opvragen dan je nodig hebt, is een schending van zowel de verordening als de AVG.
• Doelbinding: Gegevens die via een wallet-presentatie zijn ontvangen, mogen alleen worden gebruikt voor het specifieke doel dat is opgegeven op het moment van het verzoek en dat overeenkomt met de geregistreerde attributenscope.
• Zelfstandige AVG-verwerkingsgrondslag: De goedkeuring die een gebruiker in de wallet geeft, is niet automatisch een toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG. Je hebt een zelfstandige grondslag nodig. Bij wettelijke KYC-verplichtingen kan een wettelijke verplichting de toepasselijke grondslag zijn. Voor gezondheidsgegevens moet daarnaast een toepasselijke grond uit artikel 9, lid 2, AVG bestaan.
• Beveiligingsverplichtingen: Je moet passende technische en organisatorische maatregelen implementeren om de geverifieerde gegevens die je ontvangt te beschermen.
• Transparantie naar gebruikers: Gebruikers moeten duidelijk worden geïnformeerd over welke gegevens je opvraagt en waarom, voordat zij goedkeuring geven.
• Registratieplicht onder CIR (EU) 2025/848: Je moet geregistreerd zijn bij de bevoegde nationale autoriteit voordat je walletdata kunt opvragen. Afhankelijk van jouw sector kunnen aanvullende verplichtingen gelden rond het bijhouden van audittrails voor compliance- en verantwoordingsdoeleinden.
• Sectorspecifieke vereisten: In gereguleerde sectoren zoals financiën, gezondheidszorg en overheid kunnen aanvullende verplichtingen uit AML-, KYC- of gezondheidszorggegevensregelgeving bovenop de basislijn van de verordening van toepassing zijn.

Een praktische implicatie: omdat wallet-attestaties cryptografisch worden geverifieerd en van een tijdstempel worden voorzien, kunnen zij dienen als tamper-evident bewijs bij een audit. Een goed geïmplementeerde verificatiestroom voldoet daarmee aan een wettelijke vereiste en genereert tegelijk een fraudebestendig compliance-record. Organisaties in de gezondheidszorg en de overheid zullen deze functionaliteit bijzonder waardevol vinden. Lees meer over hoe digitale identiteit van toepassing is in zorgsectorcontexten en overheidsdiensten.

Hoe ondersteunt de ID Connector van TrustTech eIDAS 2.0 attestatie-verificatie

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 het onderwerp van dit artikel ondersteunt de ID Connector concreet:

• Verificatie van uitgevershandtekeningen tegen nationale trusted lists en de EU List of Trusted Lists (LOTL)
• Controle van de intrekkingsstatus via statusinformatie van de uitgever
• Validatie van de wallet unit attestation, waarmee wordt vastgesteld dat de presenterende wallet op een gecertificeerde wallet solution draait
• Bewaking van de geregistreerde attributenscope, zodat verzoeken binnen de grenzen van de CIR (EU) 2025/848-registratie blijven
• Hergebruik van geverifieerde identiteitsgegevens binnen jouw onboarding- en compliance-workflows
• Gekwalificeerd tekenen via een aangesloten gekwalificeerde trust service provider

De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en overheid die zich voorbereiden op de deadline van 24 december 2026 voor publieke instanties en 24 december 2027 voor gereguleerde private sectoren onder artikel 5f van de verordening. Micro- en kleine ondernemingen met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal 10 miljoen euro zijn van de private acceptatieplicht uitgezonderd. Als jouw organisatie zich voorbereidt op eIDAS 2.0 en wil weten wat de ID Connector concreet voor jouw situatie doet, neem dan contact op met TrustTech.