Relying parties verbinden zich met het EUDI-wallet-ecosysteem door zich te registreren bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848, gestandaardiseerde protocollen te implementeren voor het opvragen en verifiëren van attestaties, en cryptografisch ondertekende attestaties van wallethouders te accepteren. Zij worden daarmee erkende ontvangers van identiteitsgegevens die gebruikers rechtstreeks vanuit hun EUDI-wallet delen. Dit artikel behandelt de belangrijkste vragen die elke organisatie moet beantwoorden voordat zij die verbinding aangaat.
Wat doet een relying party in het EUDI-wallet-ecosysteem?
Een relying party is elke organisatie of dienst die identiteitsattributen of attestaties opvraagt en verifieert vanuit de EUDI-wallet van een gebruiker. In plaats van identiteitsgegevens zelf te verzamelen en op te slaan, ontvangt een relying party cryptografisch ondertekende attestaties rechtstreeks vanuit de wallet, en vertrouwt zij op die attestaties omdat ze afkomstig zijn van een erkende uitgever binnen het ecosysteem.
In de praktijk kan een relying party een bank zijn die een nieuwe klant vraagt om hun geverifieerde naam en geboortedatum te delen tijdens het onboardingproces, een overheidsportaal dat bewijs van adres opvraagt, of een zorgverlener die een professionele kwalificatie verifieert. De gemeenschappelijke noemer is dat de relying party bepaalt wat zij nodig heeft, de gebruiker beslist wat er gedeeld wordt, en de wallet de veilige overdracht afhandelt.
Dit model verandert de inrichting van identiteitsverificatie. In plaats van gebruikers te vragen documenten te uploaden of formulieren in te vullen, ontvangt de relying party gestructureerde, machineleesbare gegevens die al zijn geverifieerd door een erkende uitgever. Dat maakt het proces sneller, betrouwbaarder en minder fraudegevoelig. Tegelijkertijd brengt het concrete registratie- en nalevingsverplichtingen met zich mee die hieronder worden toegelicht.
Hoe maakt een relying party technisch verbinding met de EUDI-wallet?
Een relying party maakt verbinding met de EUDI-wallet door de technische protocollen te implementeren die zijn uitgewerkt in het Architecture and Reference Framework (ARF). Voor online presentatie van attestaties wordt OID4VP gebruikt als uitwisselingsprotocol. Voor proximity-presentatie van mobiele documenten in mdoc-formaat geldt ISO/IEC 18013-5, en voor online presentatie van mdoc geldt ISO/IEC TS 18013-7. Naast mdoc ondersteunt het ecosysteem ook SD-JWT VC als credentialformaat. Deze open standaarden zorgen ervoor dat elke conforme wallet kan communiceren met elke conforme relying party, ongeacht welke lidstaat de wallet heeft uitgegeven.
De verbindingsstroom werkt globaal als volgt:
- De relying party stuurt een presentatieverzoek waarin wordt aangegeven welke attributen of attestaties zij nodig heeft, binnen de scope die bij registratie is vastgelegd.
- De wallet unit van de gebruiker toont het verzoek en vraagt de gebruiker om goedkeuring voor het delen van de relevante gegevens.
- De wallet genereert een verifieerbare presentatie, ondertekend door de wallet en de oorspronkelijke uitgever.
- De relying party ontvangt de presentatie en voert de vereiste verificatiestappen uit voordat zij toegang verleent of de transactie voltooit.
Verificatie bestaat uit meer dan het controleren van een cryptografische handtekening. Een relying party moet drie afzonderlijke controles 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 waarmee wordt vastgesteld dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste controle kan volledig offline plaatsvinden. De overige twee vereisen contact met externe bronnen.
Om dit in de praktijk te laten werken, moeten relying parties een verificatieoplossing integreren die deze drie controles uitvoert, vertrouwensankers beheert via de nationale trusted lists en de EU List of Trusted Lists (LOTL), en up-to-date blijft met wijzigingen in het ARF. Dit zelf bouwen is mogelijk, maar vraagt doorlopende aandacht voor revisies van het ARF en nieuwe uitvoeringshandelingen.
Onder welk vertrouwenskader moeten relying parties zich registreren?
Relying parties moeten zich registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging op grond van CIR (EU) 2025/848, de uitvoeringshandeling die op 6 mei 2025 is vastgesteld en de registratieprocedure voor wallet-relying parties regelt. Registratie is een voorwaarde voordat walletdata kan worden opgevraagd. Zonder geldige registratie kan een wallet het verzoek weigeren.
Bij registratie legt de relying party per intended use vast 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 zelf. Het is daarom belangrijk om de attributenscope bij registratie zorgvuldig en volledig te definiëren.
Het vertrouwenskader dient twee doelen. Ten eerste beschermt het gebruikers doordat zij alleen gegevens delen met geregistreerde en geverifieerde organisaties. Ten tweede geeft het relying parties toegang tot de cryptografische vertrouwensankers die zij nodig hebben om attestaties te valideren die zijn uitgegeven door walletproviders in andere lidstaten.
Elke lidstaat beheert zijn eigen trusted list van erkende walletproviders en uitgevers, conform ETSI TS 119 612. Deze nationale trusted lists maken deel uit van de bredere EU List of Trusted Lists (LOTL). Het register van geregistreerde relying parties is een afzonderlijk nationaal register en moet niet worden verward met de trusted lists. Voor organisaties die grensoverschrijdend opereren, is het begrijpen van dit onderscheid een belangrijk onderdeel van de voorbereiding.
Welke attributen kan een relying party opvragen uit de EUDI-wallet?
Een relying party kan elk attribuut opvragen dat is gedefinieerd binnen een erkend attestatietype, dat de wallet van de gebruiker bevat, en dat binnen de geregistreerde scope valt. De meest fundamentele attestatie is de Persoonsidentificatiegegevens (PID), die attributen bevat zoals naam, geboortedatum, nationaliteit en adres. Naast de PID kunnen wallets gekwalificeerde elektronische attribuutattestaties (QEAA), door publiekrechtelijke instanties uitgegeven attestaties (PuB-EAA) en niet-gekwalificeerde EAA’s bevatten. Deze kunnen documenten omvatten zoals rijbewijzen, beroepskwalificaties, diploma’s en gezondheidsgegevens. PuB-EAA’s vallen in een eigen juridische categorie en worden niet gelijkgesteld aan niet-gekwalificeerde EAA’s.
Relying parties mogen niet meer gegevens opvragen dan noodzakelijk is voor het specifieke doel. Het beginsel van gegevensminimalisatie is verankerd in het eIDAS 2.0-kader, wat betekent dat verzoeken beperkt moeten blijven tot wat daadwerkelijk noodzakelijk is voor de aangeboden dienst. Een platform dat alleen de leeftijd van een gebruiker hoeft te verifiëren, vraagt een leeftijdsattestatie op in plaats van een volledige set identiteitsattributen.
Selective disclosure is een kernfunctionaliteit van het EUDI-wallet-model. Gebruikers kunnen één enkel attribuut delen, zoals bewijs dat zij ouder zijn dan 18, zonder hun volledige naam of geboortedatum te onthullen. Voor relying parties betekent dit dat zij hun attestatieverzoeken doordacht moeten ontwerpen en alleen mogen vragen wat de use case daadwerkelijk vereist. Verzoeken buiten de geregistreerde scope kunnen door de wallet worden geweigerd.
Wat zijn de belangrijkste nalevingsverplichtingen voor relying parties onder eIDAS 2.0?
Onder Verordening (EU) 2024/1183, die Verordening (EU) 910/2014 wijzigt, hebben relying parties concrete nalevingsverplichtingen die verder gaan dan het implementeren van de juiste technische protocollen. Deze verplichtingen zijn ontworpen om gebruikers te beschermen en het vertrouwen binnen het ecosysteem te handhaven.
- Registratie: Relying parties moeten zich registreren bij de bevoegde nationale autoriteit op grond van CIR (EU) 2025/848 voordat zij attestaties opvragen uit EUDI-wallets.
- Doelbinding: Elk attestatieverzoek moet een duidelijk en rechtmatig doel specificeren, en relying parties mogen de ontvangen gegevens alleen gebruiken voor dat opgegeven doel.
- Gegevensminimalisatie: Verzoeken moeten beperkt blijven tot de attributen die strikt noodzakelijk zijn voor de beoogde dienst.
- Transparantie: Gebruikers moeten duidelijk worden geïnformeerd over wie hun gegevens opvraagt, waarom, en wat er mee zal gebeuren.
- AVG-conformiteit: Alle via de wallet ontvangen gegevens blijven onderworpen aan AVG-verplichtingen, inclusief opslaglimieten, toegangsrechten en beveiligingsvereisten. Goedkeuring van gegevensdeling in de wallet is niet automatisch toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG. Een relying party heeft een zelfstandige AVG-grondslag nodig voor de verwerking.
- Auditgereedheid: Relying parties dienen gegevens bij te houden van attestatieverzoeken en verificaties om naleving aan te tonen indien vereist.
Organisaties in gereguleerde sectoren zoals financiële dienstverlening of gezondheidszorg moeten hun EUDI-wallet-integratie ook afstemmen op sectorspecifieke regelgeving, zoals PSD3-vereisten voor sterke klantauthenticatie of regels voor de bescherming van patiëntgegevens. Voor gezondheidsgegevens geldt daarnaast dat een toepasselijke grond uit artikel 9, lid 2, AVG aanwezig moet zijn.
Hoe moeten organisaties beginnen met de voorbereiding om relying party te worden?
Organisaties beginnen met het in kaart brengen van de use cases binnen hun diensten waar EUDI-wallet-integratie de meeste waarde toevoegt, en beoordelen vervolgens de technische en juridische stappen die nodig zijn om die use cases te ondersteunen. De voorbereiding omvat zowel een nalevingstraject als een technisch traject, en die twee moeten parallel lopen.
Een praktisch startpunt ziet er als volgt uit:
- Identificeer je use cases. Welke diensten vereisen identiteitsverificatie? Waar zou het accepteren van wallet-attestaties wrijving verminderen of de beveiliging verbeteren?
- Beoordeel de regelgevende vereisten. Begrijp welke registratie vereist is in jouw lidstaat op grond van CIR (EU) 2025/848 en welke verplichtingen van toepassing zijn op jouw sector.
- Beoordeel je technische gereedheid. Ondersteunen jouw bestaande systemen de protocollen die nodig zijn om EUDI-wallet-attestaties te ontvangen en te verifiëren, inclusief de drie afzonderlijke verificatiestappen?
- Plan je aanpak voor gegevensminimalisatie. Bepaal precies welke attributen je nodig hebt voor elke use case en definieer je attestatieverzoeken en geregistreerde scope dienovereenkomstig.
- Test met beschikbare referentie-implementaties. Open-source referentie-implementaties bieden mogelijkheden om je integratie te testen vóór volledige uitrol. De eerste vier Large Scale Pilots (EWC, POTENTIAL, NOBID en DC4EU) liepen van april 2023 tot 2025 en zijn afgerond. EWC richtte zich op Digital Travel Credentials, betalingen en organisational digital identity. POTENTIAL piloteerde overheidsdiensten, het openen van bankrekeningen, SIM-registratie, mobiel rijbewijs, gekwalificeerde handtekening op afstand en e-recepten. NOBID had betalingen als focus, en DC4EU richtte zich op onderwijs en sociale zekerheid. Een tweede pilotgolf, waaronder WE BUILD (business wallets en betalingen) en APTITUDE (reizen, ticketing, voertuigregistratie en betalingen), is in 2025 gestart.
Uiterlijk op 24 december 2026 moet elke EU-lidstaat minimaal één gecertificeerde EUDI-wallet beschikbaar hebben voor burgers, inwoners en bedrijven, en moeten publieke instanties genotificeerde wallets accepteren als identificatiemiddel voor onlinediensten waarvoor elektronische identificatie vereist is. Voor gereguleerde private partijen in sectoren zoals banken en financiële dienstverlening, zorg, telecom, energie, transport, onderwijs en digitale diensten geldt op grond van artikel 5f van Verordening (EU) 2024/1183 een acceptatieplicht 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 acceptatieplicht uitgezonderd. Organisaties die te lang wachten, lopen het risico niet voorbereid te zijn wanneer deze deadlines naderen en de adoptie van wallets onder hun gebruikers en klanten versnelt. Jouw implementatieaanpak nu herzien geeft je de tijd om hiaten aan te pakken voordat ze urgent worden.
Hoe de ID Connector van TrustTech relying parties 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 verificatie die relying parties moeten uitvoeren, biedt de ID Connector de volgende functionaliteiten:
- Walletacceptatie: De ID Connector accepteert elke gecertificeerde Europese wallet, ongeacht de lidstaat van uitgifte, zodat relying parties geen keuze hoeven te maken voor één specifieke walletprovider.
- Verificatie tegen nationale trusted lists: De ID Connector voert verificatie uit tegen nationale trusted lists en de LOTL, zodat de handtekening van de uitgever wordt gecontroleerd aan de hand van de juiste vertrouwensankers.
- Intrekkingscontrole: De intrekkingsstatus van attestaties wordt gecontroleerd via de statusinformatie van de uitgever.
- Validatie van wallet unit attestations: De ID Connector valideert de wallet unit attestation om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait.
- Bewaken van geregistreerde attributenscope: De ID Connector bewaakt de geregistreerde attributenscope per intended use, zodat verzoeken binnen de grenzen blijven die bij registratie zijn vastgelegd.
- Gekwalificeerd tekenen via een aangesloten QTSP: Voor organisaties die gekwalificeerd tekenen willen aanbieden, ondersteunt de ID Connector de koppeling met een aangesloten QTSP.
TrustTech werkt samen met organisaties in de publieke sector, financiële dienstverlening, gezondheidszorg en andere gereguleerde sectoren. Of je nu net begint te verkennen wat de status van relying party betekent voor jouw organisatie of klaar bent om met de integratie te beginnen, neem contact op met TrustTech om jouw volgende stappen te bespreken.