Relying parties authenticeren gebruikers met eIDAS 2.0-wallets door een presentatieverzoek te sturen naar de EUDI-wallet van de gebruiker, een cryptografisch ondertekend antwoord te ontvangen met geverifieerde identiteitsattributen, en dat antwoord te valideren aan de hand van het EU-vertrouwenskader. Het volledige proces is gestandaardiseerd in alle lidstaten, wat betekent dat één enkele integratiebenadering werkt voor gebruikers in de hele EU. De onderstaande secties beschrijven elk onderdeel van de flow, van het eerste verzoek tot de uiteindelijke verificatiecontrole.
Wat gebeurt er tijdens een op een wallet gebaseerde authenticatieflow?
Tijdens een op een wallet gebaseerde authenticatieflow onder eIDAS 2.0 stuurt de relying party een presentatieverzoek naar de EUDI-wallet van de gebruiker, beoordeelt de gebruiker welke gegevens worden gedeeld en keurt deze goed, en retourneert de wallet een cryptografisch ondertekend antwoord dat de relying party verifieert. De gebruiker behoudt gedurende het hele proces de controle en er worden geen gegevens gedeeld zonder expliciete goedkeuring.
In de praktijk ziet de flow er doorgaans als volgt uit:
- De relying party genereert een presentatieverzoek waarin wordt aangegeven welke identiteitsattributen nodig zijn, zoals naam, geboortedatum of nationaliteit.
- Het verzoek wordt afgeleverd bij de wallet van de gebruiker, via een QR-code, een deep link of een doorverwijzing, afhankelijk van het kanaal.
- De gebruiker ziet precies wat er wordt gevraagd en kiest er actief voor om het delen van elk attribuut goed te keuren of te weigeren.
- De wallet retourneert een ondertekende presentatie met alleen de goedgekeurde attributen.
- De relying party voert drie afzonderlijke controles uit: verificatie van de handtekening van de uitgever aan de hand van de relevante nationale trusted list, controle van de intrekkingsstatus via de statusinformatie van de uitgever, en verificatie van de wallet unit attestation waarmee wordt vastgesteld dat de presenterende wallet draait op een gecertificeerde wallet solution.
Deze flow is ontworpen om snel en privacyvriendelijk te zijn. Omdat de wallet vooraf geverifieerde attestaties bevat die zijn uitgegeven door vertrouwde autoriteiten zoals overheden of gekwalificeerde verleners van vertrouwensdiensten, hoeft de relying party de onderliggende gegevens niet zelf opnieuw te verifiëren. Het zware werk van identiteitsverificatie is al eerder gedaan.
Welke attestaties vraagt een relying party op bij de wallet?
Een relying party vraagt specifieke identiteitsattributen op bij de wallet, niet het volledige identiteitsdocument. Het meest gebruikelijke startpunt is de Persoonsidentificatiedata (PID), die kernattributen bevat zoals volledige naam, geboortedatum, geboorteplaats en nationaliteit. Afhankelijk van de gebruikssituatie kunnen relying parties ook Elektronische Attesteringen van Attributen (EAA’s) opvragen. Binnen de categorie EAA’s maakt eIDAS 2.0 onderscheid tussen gekwalificeerde EAA’s (QEAA), door publieke instanties uitgegeven EAA’s (PuB-EAA) en niet-gekwalificeerde EAA’s. PuB-EAA’s vallen in een eigen juridische categorie en worden niet onder niet-gekwalificeerde EAA’s geplaatst.
EAA’s breiden de wallet uit voorbij de basisidentiteit. Ze kunnen een breed scala aan geverifieerde attestaties bevatten, zoals beroepskwalificaties, rijbewijzen, zorgverzekeringsgegevens of onderwijscertificaten. Relying parties in gereguleerde sectoren hebben vaak een combinatie van PID en een of meer EAA’s nodig om aan hun nalevingsvereisten te voldoen.
Een belangrijk principe dat is ingebouwd in het eIDAS 2.0-kader is dataminimalisatie. Van relying parties wordt verwacht dat ze alleen de attributen opvragen die ze daadwerkelijk nodig hebben voor een specifieke transactie. Een leeftijdsverificatiecontrole vereist bijvoorbeeld alleen bevestiging dat de gebruiker boven een bepaalde drempel is, niet de exacte geboortedatum. Dit kan via selective disclosure van bijvoorbeeld het attribuut “ouder dan 18”. Bovendien registreert een relying party onder CIR (EU) 2025/848 per intended use 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. Deze aanpak beschermt de privacy van gebruikers en vermindert het risico op overmatige verzameling van persoonsgegevens.
Hoe verifieert een relying party de authenticiteit van wallet-attestaties?
Een relying party verifieert de authenticiteit van wallet-attestaties door drie afzonderlijke controles uit te voeren. Verificatie van de handtekening van de uitgever kan volledig offline plaatsvinden aan de hand van de openbare sleutels die zijn gepubliceerd op de relevante nationale trusted list volgens ETSI TS 119 612, die op haar beurt deel uitmaakt van de EU List of Trusted Lists (LOTL). De controle van de intrekkingsstatus vereist contact met de statusinformatie van de uitgever en kan dus niet volledig offline worden uitgevoerd. De verificatie van de wallet unit attestation stelt vast dat de presenterende wallet instance draait op een gecertificeerde wallet solution. Alleen wanneer alle drie controles slagen, kan een relying party de gepresenteerde attestatie vertrouwen.
Elke attestatie in de EUDI-wallet is digitaal ondertekend door de uitgever op het moment van uitgifte. Wanneer de wallet een attestatie presenteert aan een relying party, draagt die attestatie een handtekening die tamper-evident is: latere wijzigingen zijn detecteerbaar. De verificatiesoftware van de relying party voert deze controles uit als onderdeel van het standaardverwerkingsproces.
De technische standaarden die aan dit proces ten grondslag liggen, zijn vastgelegd in het Architecture and Reference Framework (ARF) dat is ontwikkeld door de eIDAS Expert Group. Het ARF specificeert de attestatieformaten, waaronder mdoc en SD-JWT VC, de handtekeningalgoritmen en de uitwisselingsprotocollen die alle EUDI-wallet-implementaties moeten volgen. Voor online presentatie van mdoc-attestaties geldt ISO/IEC TS 18013-7; voor proximity-presentatie geldt ISO/IEC 18013-5. Het uitwisselingsprotocol voor presentatie is OID4VP. Het High Assurance Interoperability Profile (HAIP) specificeert aanvullende vereisten voor interoperabiliteit op hoog betrouwbaarheidsniveau. De juridisch bindende vereisten volgen echter uit Verordening (EU) 2024/1183 en de bijbehorende uitvoeringshandelingen, niet uit het ARF zelf.
Wat is de rol van het vertrouwenskader bij de authenticatie van relying parties?
Het vertrouwenskader is de ruggengraat van de authenticatie van relying parties onder eIDAS 2.0. Het definieert welke wallet solutions, attestatie-uitgevers en relying parties worden erkend als betrouwbare actoren binnen het ecosysteem. Zonder een functionerend vertrouwenskader zouden relying parties geen betrouwbare manier hebben om echte wallet-attestaties te onderscheiden van frauduleuze.
De kern van het vertrouwenskader bestaat uit:
- Nationale trusted lists: Officiële registers die worden bijgehouden door lidstaten volgens ETSI TS 119 612 en die gecertificeerde wallet solutions, gekwalificeerde verleners van vertrouwensdiensten en erkende attestatie-uitgevers vermelden. Deze lijsten zijn via de EU List of Trusted Lists (LOTL) machineleesbaar beschikbaar.
- Certificeringsvereisten: Wallet solutions moeten worden gecertificeerd aan de hand van vastgestelde beveiligings- en interoperabiliteitsnormen voordat ze kunnen worden opgenomen in de nationale trusted list.
- Registratie van relying parties: Organisaties die EUDI-wallet-attestaties willen opvragen, moeten zich registreren als relying party bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848. Dit register van relying parties staat los van de nationale trusted lists.
- Grensoverschrijdende erkenning: Omdat het kader is geharmoniseerd in de hele EU, kan een relying party in één lidstaat attestaties vertrouwen die zijn uitgegeven door autoriteiten in een andere lidstaat.
Dit kader maakt wallet-authenticatie schaalbaar over grenzen heen. Relying parties hebben geen individuele overeenkomsten nodig met elke attestatie-uitgever. Ze vertrouwen op het kader, en het kader staat in voor de uitgevers. Dat is wat grensoverschrijdende digitale identiteit op schaal praktisch maakt.
Wat zijn de technische en juridische vereisten om een relying party te worden?
Om attestaties uit een EUDI-wallet te mogen opvragen, moet een organisatie zich registreren bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848, dat op 6 mei 2025 in werking is getreden. Registratie is een formele juridische vereiste. Bij registratie legt de relying party per intended use vast welke attributen en attestaties worden opgevraagd. Een leverancier die wallet-data 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 technisch vlak moeten relying parties ondersteuning implementeren voor de protocollen en interfaces die zijn gespecificeerd in het ARF. Dit omvat OID4VP, het protocol dat bepaalt hoe presentatieverzoeken worden verzonden en hoe wallet-antwoorden worden ontvangen en verwerkt. De backend van de relying party moet in staat zijn de drie verificatiecontroles uit te voeren: handtekeningvalidatie aan de hand van de nationale trusted list, controle van de intrekkingsstatus, en validatie van de wallet unit attestation.
Relying parties moeten ook hun eigen ondertekeningssleutels beheren, die worden gebruikt om de presentatieverzoeken te ondertekenen die ze naar wallets sturen. Wallet instances kunnen deze sleutels verifiëren aan de hand van de geregistreerde vermelding van de relying party, wat bevestigt dat het verzoek afkomstig is van een geregistreerde dienst. Een relying party heeft geen QTSP nodig om een EUDI-wallet te accepteren. Een QTSP wordt relevant wanneer de dienst ook gekwalificeerde attestaties uitgeeft of gekwalificeerd tekenen aanbiedt.
Voor organisaties in financiële dienstverlening of overheidsdiensten kunnen aanvullende sectorspecifieke vereisten van toepassing zijn bovenop de basisverplichtingen van eIDAS 2.0. Publieke instanties moeten genotificeerde EUDI-wallets accepteren voor onlinediensten waarvoor elektronische identificatie vereist is vanaf 24 december 2026. Voor relevante gereguleerde private sectoren, waaronder banken en financiële dienstverlening, zorg, telecom, energie, transport, onderwijs, sociale zekerheid en digitale diensten, geldt de acceptatieplicht onder artikel 5f van Verordening (EU) 2024/1183 vanaf 24 december 2027. Micro- en kleine ondernemingen zijn van die private acceptatieplicht uitgezonderd: organisaties met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal 10 miljoen euro vallen buiten de verplichting.
Hoe verschilt eIDAS 2.0 wallet-authenticatie van bestaande inlogmethoden?
eIDAS 2.0 wallet-authenticatie verschilt van bestaande inlogmethoden voornamelijk in waar het vertrouwen vandaan komt. Bij wachtwoorden of sociale logins moet de relying party de identiteit van de gebruiker zelf verifiëren of een extern platform vertrouwen. Bij EUDI-wallet-authenticatie presenteert de gebruiker attestaties die al zijn geverifieerd en uitgegeven door een vertrouwde autoriteit, waardoor het vertrouwensanker stroomopwaarts wordt verlegd naar de uitgevende instantie.
Vergeleken met combinaties van gebruikersnaam en wachtwoord elimineert wallet-authenticatie de risico’s van credential stuffing, phishing en hergebruik van wachtwoorden. Er is geen gedeeld geheim dat uit een database kan worden gestolen, omdat de authenticatie is gebaseerd op cryptografisch bewijs.
Vergeleken met bestaande eID-gebaseerde logins voegt de EUDI-wallet selective disclosure toe. Een gebruiker kan alleen de specifieke attributen delen die nodig zijn voor een transactie, in plaats van een volledig identiteitsdocument te presenteren. Dit is een betekenisvolle privacyverbetering, vooral voor diensten die slechts één attribuut hoeven te bevestigen.
Vergeleken met gefedereerde logins via commerciële identiteitsproviders geeft wallet-authenticatie gebruikers directe controle over hun gegevens. Er is geen tussenliggend platform dat de authenticatiegebeurtenis registreert of een profiel opbouwt op basis van waar de gebruiker inlogt. De interactie vindt plaats tussen de gebruiker, hun wallet unit en de relying party.
Hier is ook een privacygrens van belang: de goedkeuring die een gebruiker in de wallet geeft voor het delen van gegevens, is geen AVG-toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG. Een relying party heeft een zelfstandige AVG-grondslag nodig voor de verwerking van de ontvangen persoonsgegevens. Bij wettelijke identificatieverplichtingen kan een wettelijke verplichting als grondslag gelden.
Voor organisaties die momenteel vertrouwen op kennisgebaseerde authenticatie of het uploaden van documenten voor identiteitsverificatie, vermindert de overgang naar op wallets gebaseerde identiteitsoplossingen ook de operationele kosten. Vooraf geverifieerde attestaties betekenen minder handmatige beoordeling, minder wrijvingspunten bij onboarding en een consistentere gebruikerservaring voor alle diensten.
Hoe de ID Connector van TrustTech relying party-integratie 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 de technische taken die in dit artikel zijn beschreven, ondersteunt de ID Connector:
- Verificatie tegen nationale trusted lists en de EU List of Trusted Lists, zodat handtekeningen van uitgevers worden gevalideerd aan de hand van de juiste vertrouwensankers
- Controle van de intrekkingsstatus via de statusinformatie van de uitgever, als onderdeel van het standaard verificatieproces
- Validatie van de wallet unit attestation, waarmee wordt vastgesteld dat de presenterende wallet instance draait op een gecertificeerde wallet solution
- Bewaking van de geregistreerde attributenscope, zodat verzoeken binnen de grenzen blijven van de registratie onder CIR (EU) 2025/848
- Hergebruik van geverifieerde identiteitsdata voor onboarding, authenticatie en andere diensten op één platform
- Gekwalificeerd tekenen via een aangesloten gekwalificeerde verlener van vertrouwensdiensten, voor diensten die een QES vereisen
De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en gezondheidszorg, en voor publieke instanties die zich voorbereiden op de deadlines van 24 december 2026 en 24 december 2027. Het platform ondersteunt zowel mdoc als SD-JWT VC als attestatieformaten.
Als je wilt begrijpen wat er nodig is om een relying party te worden en hoe wallet-authenticatie voor jouw organisatie kan werken, neem dan contact op met TrustTech om jouw specifieke situatie te bespreken.