Naar hoofdinhoud

Wat is een vertrouwende partij in het EUDI Wallet-ecosysteem?

Een vertrouwende partij is elke organisatie die een persoon of een bedrijf om bewijs van iets vraagt en vervolgens op het antwoord afgaat om een beslissing te nemen. In het European Digital Identity Wallet-ecosysteem is dat de ontvangende partij: zij vraagt gegevens op uit een wallet, controleert ze en handelt op het resultaat. De officiële term is wallet-relying party, en in het dagelijks taalgebruik zeggen de meeste mensen gewoon verifier.

De rol in gewone taal

De rol is niet nieuw. Uw organisatie is al een vertrouwende partij elke keer dat zij een paspoort, een uittreksel of een diploma controleert. Wat verandert, is dat de controle niet langer een mens is die een document leest, maar een automatisch antwoord dat u binnen seconden kunt vertrouwen.

Vertrouwende partij is een rol, geen soort bedrijf. Dezelfde organisatie kan in het ene proces vertrouwende partij zijn en in het andere uitgever: een universiteit vraagt een student bij inschrijving om een identiteitsbewijs en reikt aan het eind een diploma uit. Wat u op een bepaald moment tot vertrouwende partij maakt, is simpelweg dat u degene bent die vraagt, controleert en beslist.

De belangrijke verschuiving zit in de vraag waar het bewijs vandaan komt. Vandaag draagt de persoon tegenover u de last om aan te tonen dat een document echt is, en draagt u de kosten van het beoordelen daarvan. Met een wallet is het bewijs ondertekend door de organisatie die het feit al heeft, waardoor de controle een berekening wordt in plaats van een inschatting.

Daarom is het de moeite waard de rol te begrijpen, ook als niets u nu al verplicht haar op te pakken. Zodra een klant binnen enkele seconden kan aantonen wie hij is, oogt elk proces dat nog om een upload en een handmatige beoordeling vraagt daarnaast traag.

Drie alledaagse voorbeelden

Het patroon is altijd hetzelfde. Iemand moet een feit weten, iemand anders heeft het al, en tot nu toe waren een document en een zekere mate van vertrouwen de enige manier om die twee te verbinden.

Wat de drie gemeen hebben, is dat geen van hen het document eigenlijk wil hebben. De bank wil weten dat een bedrijf bestaat en dat de persoon die tekent daarvoor mag optreden, en de winkel wil alleen weten dat een klant oud genoeg is. Het ging nooit om het document, het was alleen de enige beschikbare drager van het feit.

Het feit losmaken van het document verandert wat u uiteindelijk in handen heeft. Een leeftijdscontrole die ja of nee teruggeeft, laat u niets gevoeligs om te beschermen, terwijl een gescand paspoort in een ticketsysteem een risico is dat u moet beveiligen, verantwoorden en uiteindelijk verwijderen.

Wat de gebruiker ziet als u iets opvraagt

Als uw dienst gegevens opvraagt, komt dat verzoek niet ongemerkt binnen. De wallet opent een scherm dat de vragende organisatie bij naam noemt, precies opsomt welke gegevens worden opgevraagd en het doel vermeldt dat die organisatie daarvoor heeft geregistreerd. Er wordt niets gedeeld totdat de persoon op akkoord tikt.

De naam op dat scherm typt u niet zelf in. Die komt uit het certificaat dat u bij uw registratie heeft gekregen, en daarom kan de wallet hem tonen als een gecontroleerd feit in plaats van een bewering. Een verzoek van een niet-geregistreerde partij levert dat scherm helemaal niet op.

De persoon kan weigeren, en kan dat elke keer opnieuw doen in plaats van eenmalig voorgoed. Wallets houden bovendien een overzicht bij van wat er is gedeeld en met wie, zodat de beslissing achteraf te bekijken is en niet in een mailbox verdwijnt. Toestemming is geen vinkje meer, maar iets dat de gebruiker daadwerkelijk kan inzien.

Voor uw organisatie is dat precies waar het om draait. De bekende fraude, een overtuigende pagina die om een kopie van een paspoort vraagt, werkt niet meer als mensen gewend zijn een geverifieerde naam te zien voordat zij iets delen. Vragen via de wallet zet u aan de vertrouwde kant van die gewoonte, en verzoeken die betrouwbaar ogen worden vaker afgerond.

Waarom de wallet controleert wie er vraagt

Een wallet vol geverifieerde identiteitsgegevens is alleen veilig als hij kieskeurig is over met wie hij praat. Als elke website hem een vraag zou kunnen stellen, zou de wallet vooral een snellere manier zijn om identiteitsdocumenten af te geven aan wie het overtuigendst vraagt. Het ontwerp begint daarom bij de omgekeerde aanname: een onbekende partij krijgt niets.

Daar zijn registratie en certificaten voor. Als u zich registreert als vertrouwende partij, krijgt u certificaten die uw organisatie identificeren, en elke lidstaat publiceert lijsten van de instanties die ze uitgeven. De wallet toetst het certificaat aan die gepubliceerde lijsten voordat hij de gebruiker iets laat zien.

U hoeft de cryptografie niet te volgen om hier rekening mee te houden, maar u moet wel op de gevolgen plannen. Certificaten verlopen en moeten worden verlengd, vertrouwenslijsten veranderen als instanties worden toegevoegd of verwijderd, en een verzoek met iets verouderds mislukt gewoon. Het lijkt meer op het geldig houden van een vergunning dan op het schrijven van software.

Dezelfde machinerie werkt in uw voordeel. Omdat er wordt getoetst aan gepubliceerde lijsten en niet aan een onderlinge afspraak, kan een wallet die in een andere lidstaat is uitgegeven uw verzoek beoordelen zonder dat u eerst iets met dat land heeft afgesproken. Dat is wat één registratie in de hele Unie bruikbaar maakt.

Wie moet de wallet accepteren, en vanaf wanneer

eIDAS 2.0, de verordening die de European Digital Identity Wallet in het leven riep, laat acceptatie niet volledig aan de markt over. Lidstaten leveren hun wallets vanaf eind 2026, en een afgebakende groep organisaties moet een jaar later klaar zijn om ze te accepteren.

Gereguleerde sectoren

Waar Europese of nationale wetgeving al sterke gebruikersauthenticatie vereist, moet de wallet worden geaccepteerd: bank- en financiële dienstverlening, telecom, energie, vervoer, zorg, onderwijs, sociale zekerheid, drinkwater, postdiensten en digitale infrastructuur. Micro-ondernemingen en kleine ondernemingen zijn van die verplichting uitgezonderd. Voor overheidsinstanties geldt een aparte regel, overal waar zij elektronische identificatie vereisen voor een onlinedienst.

Zeer grote onlineplatforms

Platforms die onder de Digital Services Act als zeer groot zijn aangewezen, moeten de wallet accepteren en het gebruik ervan faciliteren wanneer een gebruiker daarom vraagt. Zij mogen alleen de minimale gegevens vragen die de dienst werkelijk nodig heeft.

In de praktijk is die lijst minder abstract dan hij klinkt. Hij raakt retailbanken, betaalinstellingen en verzekeraars, telecomaanbieders die abonnees aanmelden, energie- en waterbedrijven, luchtvaart- en spoorvervoerders, ziekenhuizen, apotheken en zorgverzekeraars, universiteiten en examenorganisaties, en de overheidsdiensten die al een nationale inlogvoorziening beheren. Vraagt uw onboarding vandaag om een identiteitsbewijs omdat een regel dat voorschrijft, dan valt u er vrijwel zeker onder.

De wallet accepteren betekent niet dat u vervangt wat u heeft. Het betekent dat u de wallet aanbiedt als een van de manieren waarop iemand zich kan identificeren daar waar u al om sterke identificatie vraagt, naast de methoden die u nu ondersteunt. Bestaande klanten houden hun route, en nieuwe krijgen een snellere.

De data zijn het noteren waard. Lidstaten geven hun wallets uit vanaf eind 2026, de regels over registratie als vertrouwende partij gelden vanaf december 2026, en de plicht om de wallet te accepteren komt eind 2027. Registratie hangt af van een nationale autoriteit en van interne besluiten over welke gegevens u nodig heeft, waardoor de kalender krapper is dan één datum in 2027 doet vermoeden.

Alle anderen mogen de wallet vrijwillig accepteren, en heel veel organisaties zullen dat doen. Zodra een klant al geverifieerde identiteits- en bedrijfsgegevens bij zich draagt, is hem vragen om in plaats daarvan een scan te uploaden een stap terug die hij zal opmerken.

Wat een organisatie daadwerkelijk moet regelen

Vertrouwende partij worden is meer dan een knop aan een formulier toevoegen. Vier dingen moeten op orde zijn, en alleen het laatste is puur technisch.

Registreer u in uw eigen land

Elke lidstaat houdt een openbaar register bij van de vertrouwende partijen die op zijn grondgebied gevestigd zijn. U geeft aan wie u bent, waarvoor u de wallet gaat gebruiken en welke gegevens u wilt opvragen. Meer opvragen dan u heeft geregistreerd is niet toegestaan.

Verkrijg uw certificaten

Met de registratie krijgt u certificaten waarmee een wallet u kan herkennen. Zij maken van een anoniem verzoek een verzoek dat de wallet aan de gebruiker kan tonen als afkomstig van een met naam geregistreerde organisatie.

Werk samen met elke nationale wallet

Er is niet één Europese wallet-app. Elke lidstaat levert er minstens één, dus u sluit aan op een veld van wallets in plaats van op één. De standaarden zijn gedeeld, maar elke wallet heeft eigen vertrouwensankers en een eigen releaseschema waar u bij moet blijven.

Controleer of de gegevens nog geldig zijn

Een credential dat vorige maand klopte, kan sindsdien zijn ingetrokken. Een vertrouwende partij moet de gepubliceerde status van een credential controleren op het moment dat het wordt gebruikt. Zelf vastleggen wat u heeft gecontroleerd is goede praktijk en geen voorschrift, maar het is wel wat u later laat aantonen dat de controle heeft plaatsgevonden.

De volgorde van die lijst telt zwaarder dan de lengte ervan. De eerste twee stappen zijn administratief en gaan op het tempo van een nationale autoriteit, dus zij bepalen wanneer u live kunt. Teams die met de integratie beginnen en de registratie voor later laten, zijn meestal klaar met de software en moeten dan wachten.

Ook de vraag welke gegevens u nodig heeft, is een zakelijke en geen technische vraag, en het loont om die zorgvuldig te beantwoorden. U registreert een doel en een set gegevens, en die set vroeg versmallen kost één overleg, terwijl hem later verbreden betekent dat u terug moet naar het register.

Wat aansluiten op meer dan dertig wallets kost

Er is niet één Europese wallet-app. Elke lidstaat levert er minstens één, sommige zullen er meerdere hebben, en uw klanten komen binnen met de wallet die hun land heeft uitgegeven. Een organisatie met klanten in een handvol landen koppelt daarom niet met één tegenpartij, maar met een steeds veranderende groep.

De standaarden eronder zijn gedeeld, en dat is wat dit überhaupt mogelijk maakt. Wat verschilt, is alles eromheen: elke wallet heeft eigen vertrouwensankers, een eigen nationaal profiel, een eigen testomgeving en een eigen releasekalender. Een geslaagde test met de ene wallet zegt heel weinig over de volgende.

De eerste integratie is zelden de dure. De kosten zitten in de jaren daarna: updates van specificaties volgen, opnieuw testen als een nationale wallet een nieuwe versie uitbrengt, wijzigingen in vertrouwenslijsten bijhouden en certificaten geldig houden in elk land waar u gevestigd bent. Het is een onderhoudspost in de begroting, geen projectpost.

Een eenvoudige manier om dit in te schatten is twee dingen tellen: het aantal lidstaten waar uw klanten vandaan komen, en het aantal releases dat elk van die wallets per jaar waarschijnlijk uitbrengt. Vermenigvuldig ze en u heeft het aantal keren dat iemand in uw team moet stoppen waar hij mee bezig is. Dat getal, en niet de eerste bouw, is waar de keuze tussen zelf bouwen en inkopen echt om draait.

Zelf bouwen of een dienst gebruiken

Aan de vier eisen hierboven kunt u intern voldoen of u kunt ze inkopen. Geen van beide antwoorden is fout, maar ze kosten verschillende dingen, en het verschil gaat vooral over wie het doorlopende werk draagt.

Het zelf doen

  • U regelt de registratie, de certificaten en hun verlengingen zelf, in elk land waar u gevestigd bent.
  • Uw team volgt de standaarden en de vertrouwenslijsten terwijl die veranderen, en levert een update zodra een nationale wallet dat doet.
  • Er verlaat niets uw infrastructuur, wat het sterkst mogelijke antwoord is op een vraag over gegevensbescherming.
  • Het is een doorlopende technische verplichting, geen project dat een keer af is.

Een verificatiedienst gebruiken

  • Eén integratie dekt elke wallet, en het koppelwerk blijft bij de aanbieder.
  • Wijzigingen in standaarden, updates van vertrouwenslijsten en statuscontrole worden voor u afgehandeld.
  • U gaat live in weken in plaats van kwartalen, en uw team blijft aan uw eigen product werken.
  • Draait u het on-premise, dan blijven de gegevens binnen uw eigen infrastructuur, precies zoals wanneer u het zelf had gebouwd.
  • U bent afhankelijk van een leverancier, dus zijn beschikbaarheid, zijn releasetempo en zijn verwerkingsvoorwaarden worden uw zorg.

Het sterkste argument om het zelf te bouwen is meestal dat er niets uw infrastructuur verlaat, wat het schoonste antwoord is op een vraag over gegevensbescherming. Dat antwoord is echter niet voorbehouden aan zelf bouwen. Dezelfde verificatiesoftware, on-premise uitgerold binnen uw eigen omgeving, houdt de gegevens precies waar ze toch al zouden blijven, terwijl de aanbieder het standaardenwerk en de koppelingen met de nationale wallets blijft dragen.

Een bruikbare manier om te kiezen is uzelf af te vragen in welke business u zit. Is walletverificatie onderdeel van wat u verkoopt, dan is het logisch om het van begin tot eind zelf te bezitten. Is het een stap binnen onboarding, een login of een afrekenproces, dan is het leidingwerk, en leidingwerk kunt u beter kopen bij iemand die er zijn beroep van maakt het te onderhouden.

Hoe u een verificatiedienst kiest

Kiest u voor inkopen in plaats van bouwen, dan gaan de vragen die ertoe doen minder over functies dan over waar de verantwoordelijkheid ligt en wat er gebeurt als er iets verandert. Deze acht vragen halen aanbiedingen uit elkaar die op een slide op elkaar lijken.

  1. Wie staat geregistreerd als vertrouwende partij? Dat hoort uw organisatie te zijn, op uw eigen naam, zodat het opgegeven doel van u is en van u blijft als u van leverancier wisselt.
  2. Welke nationale wallets en welke lidstaten worden vandaag ondersteund, in plaats van beloofd op een roadmap?
  3. Kan het zowel on-premise als gehost draaien, en als het gehost is, in welk land worden de gegevens dan verwerkt?
  4. Wat wordt er bewaard, hoe lang, en wat houdt u over als bewijs dat een controle heeft plaatsgevonden?
  5. Hoe worden intrekking en geldigheid gecontroleerd op het moment van gebruik, en niet eenmalig bij de inrichting?
  6. Wie draagt de kosten als een standaard, een vertrouwenslijst of een nationale wallet verandert, en hoe snel?
  7. Is er een testomgeving waarin u een echte flow kunt uitproberen voordat u zich ergens aan verbindt?
  8. Hoe zou u weer weggaan? Exporteerbare vastleggingen en een registratie op uw eigen naam maken dat mogelijk.

Op de eerste vraag moet u blijven staan. Staat de registratie op uw eigen naam, dan behoudt u de relatie met het register, het opgegeven doel en de mogelijkheid om van leverancier te wisselen zonder opnieuw te beginnen. Al het andere op de lijst is onderhandelbaar, en dit punt echt niet.

Aan de slag: use case, pilot, planning

Begin met één use case, en kies de smalste die u vandaag iets meetbaars kost. Een leeftijdscontrole, een bedrijfscontrole bij het aanmelden van een leverancier of de identiteitsstap bij het openen van een rekening zijn allemaal klein genoeg om af te maken en specifiek genoeg om iets aan te tonen. Een programma om alle identiteit overal te moderniseren is geen eerste project.

Draai de pilot naast uw bestaande proces en niet in de plaats daarvan. Bied de wallet aan als extra route voor een deel van het verkeer, houd de oude weg open en vergelijk beide op de cijfers die u al bijhoudt: hoe lang het duurt, hoeveel mensen het afmaken, hoeveel handmatige beoordeling er overblijft. Die vergelijking maakt de business case, niet een demonstratie.

Begin vroeg met de registratie, want dat is het deel waarover u de minste controle heeft. Die hangt af van een nationale autoriteit en van een intern besluit over welke gegevens u echt nodig heeft, en beide duren langer dan ze lijken. De technische integratie is meestal de kortere helft van het werk, zeker als u de koppelingen met de wallets niet zelf bouwt.

Een realistisch beeld voor een organisatie die nu begint, is een besluit en een registratie in het eerste kwartaal, een werkende pilot in het tweede en daarna een verbredende uitrol, wat ruimte laat vóór de verplichting van 2027 in plaats van er tegenaan te lopen. Geldt de verplichting niet voor u, dan houdt dezelfde volgorde stand, alleen wordt de deadline dan bepaald door uw concurrenten in plaats van door de regelgeving.

Hoe Credenco helpt

Credenco voert de kant van de vertrouwende partij voor u uit, terwijl u de beslissing houdt. U blijft de geregistreerde organisatie en u houdt de gegevens, en het koppelwerk naar de wallets ligt bij ons.

Beide draaien als gehoste dienst of on-premise in uw eigen omgeving, zodat het uitrolmodel een keuze is die u maakt en niet een die het product voor u maakt. In beide gevallen blijft de registratie op uw naam staan en toont de wallet uw organisatie aan de gebruiker.

Veelgestelde vragen

Wat is een vertrouwende partij in gewone taal?

Het is elke organisatie die iemand om bewijs vraagt en vervolgens handelt op het antwoord. Een bank, een webshop, een werkgever en een overheidsloket zijn allemaal vertrouwende partijen. In het EUDI Wallet-ecosysteem komt het bewijs uit een wallet en kan het automatisch worden gecontroleerd, zodat de organisatie vertrouwt op de controle in plaats van op een document dat zij moet geloven.

Moet mijn organisatie de EUDI Wallet accepteren?

Ja, als Europese of nationale wetgeving u nu al verplicht gebruikers sterk te authenticeren. Dat geldt voor sectoren als bank- en financiële dienstverlening, telecom, energie, vervoer, zorg, onderwijs, sociale zekerheid, postdiensten en digitale infrastructuur, en ook als u een zeer groot onlineplatform bent dat is aangewezen onder de Digital Services Act. Micro-ondernemingen en kleine ondernemingen zijn van die sectorverplichting uitgezonderd. Alle anderen mogen de wallet vrijwillig accepteren, en velen zullen dat doen, omdat klanten met een wallet verwachten die te kunnen gebruiken.

Moeten wij ook credentials uitgeven?

Nee. Credentials accepteren en credentials uitgeven zijn aparte rollen, en de meeste organisaties hebben alleen de eerste nodig. Verifiëren is het kleinere werk: u vraagt gegevens op, controleert ze tegen een gepubliceerde vertrouwenslijst en leest het antwoord, zonder de identiteitsvaststelling en het sleutelbeheer die een uitgever op zich neemt.

Mogen wij alle gegevens opvragen die wij willen?

Nee, en dat is bewust zo. U registreert welke gegevens u nodig heeft en met welk doel, en een verzoek daarbuiten kan worden geweigerd. In de praktijk brengt dit organisaties ertoe minder te vragen, wat de wetgeving over gegevensbescherming altijd al heeft gevraagd.

Wanneer moeten wij beginnen?

Als de acceptatieplicht voor u geldt, is de deadline eind 2027, en registratie, inkoop en testen gaan daar allemaal aan vooraf. Geldt de plicht niet voor u, dan is er nog steeds reden om te bewegen: onboarding die seconden duurt in plaats van dagen is het waard, of een regel daar nu om vraagt of niet.

Technische verdieping

Deze pagina blijft op het niveau van wat de rol voor uw organisatie betekent. Hoe een verzoek precies wordt samengesteld en beantwoord, via het OpenID4VP-protocol, staat in de technische documentatie. Lees de technische documentatie

Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen over de vraag of een verplichting op uw organisatie van toepassing is rechtstreeks de Europese Commissie en uw nationale toezichthouder.

Praat met ons over het accepteren van de EUDI Wallet