Een relying party onder eIDAS 2.0 is elke organisatie of dienst die identiteitsattributen opvraagt vanuit de EUDI-wallet van een gebruiker of een andere eIDAS-conforme identiteitsbron, en op die informatie vertrouwt om een beslissing te nemen. De term is afkomstig uit Verordening (EU) 2024/1183, die Verordening (EU) nr. 910/2014 wijzigt en de rol formeel definieert. Als jouw organisatie moet verifiëren wie iemand is voordat toegang tot een dienst wordt verleend, treedt je op als relying party. Dit artikel beschrijft wat dat juridisch en technisch betekent, welke verplichtingen je hebt en hoe je je kunt voorbereiden.
Wat doet een relying party precies onder eIDAS 2.0?
Een relying party vraagt geverifieerde identiteitsattributen op van een gebruiker en vertrouwt op die informatie om een beslissing te nemen, zoals het verlenen van toegang, het afronden van een onboardingproces of het ondertekenen van een contract. Onder eIDAS 2.0 is deze rol geformaliseerd: relying parties moeten aan specifieke vereisten voldoen om te kunnen communiceren met EUDI-wallets en het bredere Europese digitale identiteitsecosysteem.
In de praktijk stuurt een relying party een verzoek naar de EUDI-wallet van een gebruiker om een of meer geverifieerde attributen op te vragen. Dit kan zo eenvoudig zijn als bevestigen dat iemand ouder is dan 18 via selective disclosure van het betreffende attribuut, of zo gedetailleerd als het ontvangen van een geverifieerde beroepskwalificatie in de vorm van een attestatie. De gebruiker beslist vervolgens welke gegevens worden gedeeld. Zodra de gegevens zijn gedeeld, ontvangt de relying party cryptografisch ondertekende informatie waarvan de authenticiteit kan worden geverifieerd aan de hand van de relevante nationale trusted list, de intrekkingsstatus van de attestatie en de wallet unit attestation van de presenterende wallet.
Dit verschilt wezenlijk van de huidige aanpak, waarbij organisaties doorgaans hun eigen identiteitscontroles uitvoeren. Onder eIDAS 2.0 reizen geverifieerde attestaties mee met de gebruiker in de wallet unit, en relying parties kunnen die gegevens accepteren omdat ze worden ondersteund door vertrouwde uitgevers binnen een gereguleerd kader. Walletgebruik is vrijwillig: artikel 5a van de verordening beschermt gebruikers tegen benadeling wanneer zij geen wallet gebruiken.
Hoe verschilt een relying party van een identiteitsprovider?
Een relying party ontvangt en gebruikt identiteitsattributen, terwijl een identiteitsprovider of attestatie-uitgever deze uitgeeft en authenticeert. Dit zijn afzonderlijke rollen binnen het digitale identiteitsecosysteem, ook al kan dezelfde organisatie in verschillende contexten beide rollen vervullen.
Een attestatie-uitgever, zoals een overheidsinstantie of een gekwalificeerde trust service provider, is verantwoordelijk voor het verifiëren van iemands identiteit en het uitgeven van attestaties. Een relying party staat aan de ontvangende kant en vertrouwt op de attestatie van de uitgever om een dienst te leveren.
Een praktisch voorbeeld: een overheid geeft een mobiel rijbewijs uit als attestatie in de EUDI-wallet (de rol van uitgever), en een autoverhuurbedrijf vraagt dat rijbewijs op voordat het een voertuig overhandigt (de rol van relying party). Onder eIDAS 2.0 geldt dezelfde logica digitaal. De EUDI-wallet bevat attestaties die zijn uitgegeven door vertrouwde bronnen, en relying parties vragen specifieke attributen op uit de wallet unit van de gebruiker wanneer zij iets moeten verifiëren. Een relying party heeft daarvoor niet automatisch een QTSP nodig. Een QTSP komt onder andere in beeld wanneer de relying party ook gekwalificeerde handtekeningen of gekwalificeerde attestaties wil gebruiken.
Welke organisaties worden beschouwd als relying parties onder eIDAS 2.0?
Elke organisatie die geverifieerde identiteitsattributen opvraagt vanuit een EUDI-wallet of een andere eIDAS-conforme identiteitsbron om een dienst te leveren, kwalificeert als relying party. Dit omvat een breed scala aan sectoren en toepassingen in zowel de publieke als de private sector.
Veelvoorkomende voorbeelden van relying parties zijn:
- Financiële instellingen die de identiteit van klanten verifiëren bij het openen van een rekening of in KYC-processen
- Zorgaanbieders die de identiteit van patiënten of beroepscredentials bevestigen voordat toegang wordt verleend tot gevoelige dossiers
- Overheidsinstanties die burgers authenticeren voor toegang tot publieke diensten zoals belastingaangifte of uitkeringsaanvragen
- Werkgevers die kwalificaties en het recht om te werken verifiëren tijdens de aanwerving
- Telecomoperators die simkaarten registreren met geverifieerde identiteit
- Online platforms die leeftijdsverificatie of toegangscontrole uitvoeren
- Farmaceutische en life sciences-organisaties die beroepscredentials controleren voor gereguleerde toegang
Als jouw organisatie momenteel identiteitscontroles uitvoert als onderdeel van onboarding, toegangsbeheer of compliance, functioneer je waarschijnlijk al als relying party. Onder eIDAS 2.0 brengt die rol formele verplichtingen met zich mee. Organisaties in de financiële dienstverlening en gezondheidszorg behoren tot de meest direct betrokkenen. Belangrijk om te weten: een leverancier die walletdata technisch namens jouw organisatie verwerkt, wordt daardoor niet automatisch zelf relying party. De registratieplicht ligt bij de organisatie die de dienst aan de eindgebruiker levert.
Wat zijn de registratie- en nalevingsverplichtingen voor relying parties?
Onder eIDAS 2.0 moeten relying parties zich registreren bij de bevoegde nationale autoriteit van de lidstaat van vestiging voordat zij walletdata kunnen opvragen. Deze verplichting is vastgelegd in CIR (EU) 2025/848, de uitvoeringshandeling over de registratie van wallet-relying parties, die op 6 mei 2025 in werking trad. De registratieplicht geldt voor zowel publieke als private organisaties.
Registratie dient een concreet doel: het zorgt ervoor dat gebruikers kunnen zien wie hun gegevens opvraagt en dat alleen legitieme, geregistreerde organisaties toegang kunnen krijgen tot geverifieerde identiteitsattributen. Per intended use registreert een relying party 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. Nationale registers van wallet-relying parties zijn iets anders dan de nationale trusted lists waarop uitgevers van attestaties worden vermeld.
Naast registratie moeten relying parties ook:
- Het doel van elk gegevensverzoek definiëren en verklaren zodat gebruikers een weloverwogen beslissing kunnen nemen over wat zij delen
- Alleen de minimaal noodzakelijke gegevens opvragen in overeenstemming met het dataminimalisatiebeginsel van de AVG
- Ervoor zorgen dat hun systemen attestaties kunnen verwerken in de formaten die zijn vastgelegd in de technische normen van eIDAS 2.0, zoals mdoc en SD-JWT VC
- Een zelfstandige AVG-grondslag hebben voor de verwerking van de ontvangen persoonsgegevens. Goedkeuring van een dataverzoek in de wallet is geen toestemming als rechtsgrond onder artikel 6, lid 1, onder a, AVG. Bij wettelijke KYC-verplichtingen is een wettelijke verplichting als grondslag doorgaans relevanter
- Op de hoogte blijven van technische specificaties naarmate het Architecture and Reference Framework (ARF) voor de EUDI-wallet zich verder ontwikkelt
Niet-naleving is geen theoretisch risico. Organisaties die verzuimen zich te registreren of die identiteitsattributen buiten het regelgevend kader verwerken, lopen juridische risico’s en verlies van gebruikersvertrouwen. Gezien de overlapping van eIDAS 2.0 met AVG-, AML-, KYC- en PSD2-vereisten is naleving werkelijk veellagig. Micro- en kleine ondernemingen, dat wil zeggen organisaties met minder dan 50 medewerkers en een jaaromzet of balanstotaal van maximaal 10 miljoen euro, zijn uitgezonderd van de private acceptatieplicht onder artikel 5f.
Hoe communiceert een relying party in de praktijk met de EUDI-wallet?
Een relying party communiceert met de EUDI-wallet via gestandaardiseerde protocollen die zijn vastgelegd in het technische kader van eIDAS 2.0. Voor de presentatie van attestaties wordt OID4VP gebruikt, wat interoperabiliteit tussen alle EU-lidstaten mogelijk maakt. Attestaties worden aangeboden in mdoc-formaat (conform ISO/IEC TS 18013-7 voor online presentatie) of als SD-JWT VC.
Een gebruiker arriveert bij een dienst, zoals het openen van een bankrekening of het raadplegen van een overheidsportaal. De relying party stuurt een verzoek voor specifieke geverifieerde attributen, bijvoorbeeld naam, geboortedatum en nationaliteit. De gebruiker ontvangt dit verzoek in de wallet instance op zijn toestel, beoordeelt wat er wordt gevraagd en kiest ervoor het goed te keuren of te weigeren. Bij goedkeuring stuurt de wallet de cryptografisch ondertekende attributen terug naar de relying party.
Verificatie door de relying party omvat drie afzonderlijke controles: de handtekening van de uitgever wordt geverifieerd aan de hand van de relevante nationale trusted list, samengebracht in de EU List of Trusted Lists (conform ETSI TS 119 612), de intrekkingsstatus van de attestatie wordt gecontroleerd via statusinformatie van de uitgever, en de wallet unit attestation wordt gevalideerd om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait. Alleen de eerste controle kan volledig offline plaatsvinden. Een attestatie kan daarom niet zonder voorbehoud worden geverifieerd zonder enig contact met externe bronnen.
Dit model heeft twee directe praktische gevolgen. De gebruiker heeft altijd de controle: er wordt niets gedeeld zonder uitdrukkelijke goedkeuring van elk afzonderlijk verzoek. De relying party ontvangt attestaties waarop zij kan vertrouwen, omdat deze worden ondersteund door geregistreerde uitgevers binnen het gereguleerde ecosysteem. Dat vermindert de noodzaak van herhaalde handmatige controles en verlaagt de onboardingfrictie, met name voor organisaties die momenteel langdurige verificatieprocessen uitvoeren.
Wat moeten organisaties nu doen om zich voor te bereiden als relying party?
Organisaties moeten nu beginnen met voorbereiden door in kaart te brengen waar identiteitsverificatie plaatsvindt in hun huidige processen, te begrijpen welke attributen zij daadwerkelijk nodig hebben en te beoordelen of hun technische infrastructuur attestaties en wallet-gebaseerde interacties kan verwerken.
De relevante deadlines zijn als volgt. Op 24 december 2026 moet elke EU-lidstaat minimaal één gecertificeerde EUDI-wallet beschikbaar hebben voor burgers 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, sociale zekerheid, drinkwater, post, digitale infrastructuur en digitale diensten geldt de acceptatieplicht onder artikel 5f vanaf 24 december 2027, binnen de context waarin sterke gebruikersauthenticatie wettelijk of contractueel vereist is. Voor zeer grote onlineplatforms met meer dan 45 miljoen gebruikers in de EU geldt een afzonderlijke bepaling van artikel 5f: zij moeten walletacceptatie aanbieden waar het platform gebruikersauthenticatie vereist, op vrijwillig verzoek van de gebruiker en voor de minimaal noodzakelijke gegevens. De periode tot die deadlines is beperkt, waardoor tijdige voorbereiding nu al noodzakelijk is.
Concrete stappen zijn onder meer het beoordelen van jouw huidige onboarding- en authenticatiestromen om te bepalen waar EUDI-wallet-integratie zinvol is, het betrekken van jouw compliance- en juridische teams om de registratievereisten onder CIR (EU) 2025/848 in jouw lidstaat te begrijpen, en het beoordelen van de gereedheid van jouw technische systemen voor de relevante protocollen en attestatieformaten.
Het is ook nuttig om te kijken hoe andere organisaties in jouw sector dit hebben aangepakt. De vier Large Scale Pilots, EWC, POTENTIAL, NOBID en DC4EU, liepen van april 2023 tot 2025 en testten reële wallet-interacties in uiteenlopende toepassingen. EWC richtte zich op Digital Travel Credentials, betalingen en organisational digital identity. POTENTIAL piloteerde overheidsdiensten, het openen van een bankrekening, SIM-registratie, het mobiel rijbewijs, gekwalificeerde handtekening op afstand en e-recepten. NOBID concentreerde zich op betalingen, en DC4EU op onderwijs en sociale zekerheid. De inzichten uit deze pilots hebben de definitieve technische specificaties mede gevormd. In 2025 startte een tweede pilotgolf, waaronder WE BUILD, gericht op business wallets en betalingen, en APTITUDE, gericht op reizen, ticketing, voertuigregistratie en betalingen. Op de hoogte blijven van de uitkomsten helpt je effectiever plannen. Het verkennen van de beschikbare resources over digitale identiteit en eIDAS 2.0 is een praktisch startpunt.
Hoe helpt TrustTech organisaties zich voor te bereiden als relying party
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.
Concreet voert de ID Connector de volgende taken uit:
- Verificatie van uitgevershandtekeningen aan de hand van de relevante nationale trusted lists, samengebracht in de EU List of Trusted Lists
- Controle van de intrekkingsstatus van ontvangen attestaties via de statusinformatie van de uitgever
- Validatie van de wallet unit attestation om vast te stellen dat de presenterende wallet op een gecertificeerde wallet solution draait
- Bewaking van de geregistreerde attributenscope zodat verzoeken binnen de grenzen van de registratie onder CIR (EU) 2025/848 blijven
- Hergebruik van geverifieerde identiteitsdata zodat gebruikers geverifieerde attributen kunnen delen via diensten
- Gekwalificeerd tekenen via een aangesloten QTSP voor toepassingen waarbij een gekwalificeerde elektronische handtekening vereist is
De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farma en de publieke sector, sectoren waar de acceptatieplicht het vroegst van toepassing is en waar de eisen aan identiteitsverificatie het zwaarst wegen. Neem contact op met TrustTech om te bespreken welke stap als eerste past bij jouw situatie.