Een token en een attestatie zijn niet hetzelfde binnen het eIDAS 2.0-kader, ook al bevatten beide identiteitsgerelateerde informatie. Een attestatie is een gestructureerde, verifieerbare claim over een persoon of organisatie, zoals een diploma of een geverifieerd adres, uitgegeven door een vertrouwde autoriteit. Een token is een kortlevend technisch object dat wordt gebruikt om aan te tonen dat een sessie of authenticatiegebeurtenis heeft plaatsgevonden. Het begrijpen van dit verschil is belangrijk omdat Verordening (EU) 2024/1183 en de EUDI-wallet ze behandelen als afzonderlijke bouwstenen met verschillende doeleinden, levensduren en vertrouwensniveaus. De onderstaande secties lichten elk concept toe en leggen uit hoe ze in de praktijk samenwerken.
Hoe worden tokens en attestaties gebruikt binnen eIDAS 2.0?
Binnen het kader van eIDAS 2.0 vervullen attestaties en tokens complementaire maar afzonderlijke rollen. Attestaties worden gebruikt om geverifieerde identiteitsattributen te dragen, zoals de naam, nationaliteit of beroepskwalificatie van een persoon, in een formaat dat cryptografisch gecontroleerd kan worden. Tokens worden gebruikt om toegang tot een dienst te autoriseren of te bevestigen dat een gebruiker zich succesvol heeft geauthenticeerd tijdens een specifieke sessie. Samen vormen ze de ruggengraat van vertrouwde digitale interacties onder de verordening.
eIDAS 2.0 is de informele benaming voor Verordening (EU) 2024/1183, die Verordening (EU) nr. 910/2014 wijzigt. De verordening bouwt voort op het oorspronkelijke eIDAS-kader, dat zich voornamelijk richtte op de grensoverschrijdende erkenning van nationale elektronische identiteitsschema’s. Het bijgewerkte kader gaat verder door de EUDI-wallet te introduceren, waarmee burgers en organisaties attestaties direct kunnen opslaan en presenteren. Tokens spelen nog steeds een rol, met name in de onderliggende protocollen die wallets verbinden met relying parties, maar de nadruk is duidelijk verschoven naar draagbare, door de gebruiker beheerde attestaties als primair middel voor identiteitsgegevens.
Voor organisaties in gereguleerde sectoren zoals financiën, overheid en gezondheidszorg heeft dit onderscheid echte operationele gevolgen. Complianceprocessen die voorheen afhankelijk waren van sessiegebaseerde tokens voor authenticatie, moeten mogelijk nu attestatie-gebaseerde identiteitsstromen accommoderen die rijkere, herbruikbare gegevens bevatten.
Wat is precies een attestatie binnen eIDAS 2.0?
Een attestatie binnen eIDAS 2.0 is een digitaal ondertekende verklaring uitgegeven door een vertrouwde autoriteit die één of meer feiten over een persoon of organisatie bevestigt. De attestatie bevat de claim zelf, informatie over de uitgever en een cryptografisch bewijs waarmee een relying party de authenticiteit kan verifiëren. Daarvoor zijn in beginsel drie afzonderlijke controles nodig: 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. Schrijf daarom niet zonder nuance dat een attestatie volledig kan worden geverifieerd zonder contact met externe bronnen.
eIDAS 2.0 maakt onderscheid tussen verschillende categorieën attestaties. Een QEAA (Qualified Electronic Attestation of Attributes) wordt uitgegeven door een gekwalificeerde verlener van vertrouwensdiensten en geniet het hoogste vertrouwensniveau. Een PuB-EAA (Public Body Electronic Attestation of Attributes) wordt uitgegeven door of namens een publieke instantie. Daarnaast bestaan non-qualified EAA’s, die niet onder een van de vorige categorieën vallen. PuB-EAA valt niet onder non-qualified EAA; het is een afzonderlijke categorie met eigen vereisten.
Veelvoorkomende voorbeelden in de eIDAS 2.0-context zijn een door de overheid uitgegeven identiteitsattest, een universitair diploma, een beroepsvergunning of een Europese ziekteverzekeringskaart. Elk van deze kan worden opgeslagen in de EUDI-wallet en selectief worden gepresenteerd aan een dienstverlener, waarbij alleen de attributen worden gedeeld die daadwerkelijk nodig zijn voor een bepaalde transactie. Dit mechanisme heet selective disclosure.
De belangrijkste eigenschappen die een attestatie definiëren zijn:
- Vertrouwen in de uitgever: De attestatie is ondertekend door een entiteit die is opgenomen in een nationale trusted list volgens ETSI TS 119 612, zodat de ontvanger de herkomst kan verifiëren via de EU List of Trusted Lists (LOTL).
- Selective disclosure: De houder kan ervoor kiezen om alleen specifieke attributen te onthullen, bijvoorbeeld bevestigen dat ze ouder zijn dan 18 zonder hun exacte geboortedatum te delen.
- Draagbaarheid: De attestatie bevindt zich in de wallet van de gebruiker en kan worden gepresenteerd aan elke compatibele relying party, niet alleen aan de organisatie die de gegevens oorspronkelijk heeft geverifieerd.
- Levensduur: Een attestatie kan maanden of jaren geldig blijven, afhankelijk van het beleid van de uitgever.
Deze structuur maakt attestaties geschikt voor herbruikbare compliance. Een klant die al is geverifieerd door zijn bank of werkgever, kan die attestatie presenteren aan een nieuwe organisatie zonder het volledige verificatieproces opnieuw te doorlopen. Daarbij gelden echter beperkingen: hergebruik van KYC-gegevens wordt niet alleen bepaald door eIDAS 2.0, maar ook door AML-regelgeving en sectorale regels. De wallet draagt de gegevens, maar vormt niet automatisch de juridische grondslag voor hergebruik in een andere context.
Wat is een token in de context van digitale identiteit?
In digitale identiteit is een token een kortlevend, machineleesbaar object dat de uitkomst vertegenwoordigt van een authenticatie- of autorisatiegebeurtenis. Het beschrijft niet wie iemand is in een rijke, draagbare zin. Het vertelt een systeem dat een specifieke gebruiker zich succesvol heeft geauthenticeerd binnen een specifieke sessie en toestemming heeft om toegang te krijgen tot een specifieke resource. Tokens worden doorgaans gegenereerd door een identiteitsprovider en binnen minuten of uren verwerkt door een dienst.
De meest voorkomende typen tokens in digitale identiteitssystemen zijn access tokens en ID tokens, beide geassocieerd met de OpenID Connect- en OAuth 2.0-protocollen. Een access token verleent toestemming om een API aan te roepen of toegang te krijgen tot een beveiligde resource. Een ID token bevestigt de identiteit van de gebruiker die zich heeft geauthenticeerd, vaak inclusief een kleine set attributen zoals een gebruikersidentificator of e-mailadres.
Tokens zijn niet ontworpen om langdurig te worden opgeslagen of hergebruikt te worden door organisaties. Ze verlopen, ze zijn gebonden aan een specifieke sessiecontext en ze zijn niet op dezelfde manier cryptografisch gekoppeld aan de gebruiker als een attestatie. Dit maakt ze goed geschikt voor sessiebeheer, maar ongeschikt voor scenario’s waarbij een persoon een geverifieerde claim moet bewijzen aan meerdere partijen over een langere periode.
Wat is het verschil tussen een SD-JWT VC en een attestatie?
Een SD-JWT VC (Verifiable Credentials using SD-JWT, oftewel Selective Disclosure JSON Web Token) is een specifiek technisch formaat dat wordt gebruikt om een attestatie te coderen op een manier die selective disclosure ondersteunt. Het verschil is er één van abstractie: een attestatie is het conceptuele object, de ondertekende claim over een persoon of entiteit, terwijl SD-JWT VC een van de gegevensformaten is die worden gebruikt om die attestatie te vertegenwoordigen en te verzenden. SD-JWT VC is een credentialformaat, geen afzonderlijk concept naast de attestatie.
De EUDI-wallet-architectuur zoals beschreven in het Architecture and Reference Framework (ARF) ondersteunt twee primaire credentialformaten: SD-JWT VC en mdoc (mobiel document). Voor mdoc geldt ISO/IEC 18013-5 voor proximity-presentatie en ISO/IEC TS 18013-7 voor online presentatie. Beide formaten stellen de houder in staat om alleen geselecteerde attributen uit de attestatie te onthullen in plaats van alles tegelijk te tonen. Voor uitgifte wordt het protocol OID4VCI gebruikt; voor presentatie OID4VP. Het High Assurance Interoperability Profile (HAIP) beschrijft de nadere technische vereisten voor interoperabiliteit binnen het EUDI-ecosysteem.
Het SD-JWT VC-formaat is bijzonder relevant voor organisaties die integraties voor relying parties bouwen, omdat het gebaseerd is op veelgebruikte webstandaarden, waardoor het relatief eenvoudig te implementeren is in bestaande systemen. Het maakt gebruik van JSON Web Token-conventies die veel ontwikkelaars al kennen, met een toegevoegde laag die bepaalde claims verborgen houdt voor een verificateur tenzij de houder er expliciet voor kiest om ze te onthullen.
Voor praktische doeleinden geldt: wanneer iemand verwijst naar een “SD-JWT” in de context van eIDAS 2.0, verwijzen ze bijna altijd naar een attestatie die in dat formaat is gecodeerd, niet naar een traditioneel sessietoken. Het woord “JWT” in de naam kan verwarring veroorzaken, maar het gebruiksscenario en het vertrouwensmodel zijn fundamenteel anders dan een OAuth access token of ID token. W3C Verifiable Credentials zijn geen door de EUDI-wallet voorgeschreven credentialformaat en vallen buiten de primaire formaten die het ARF beschrijft.
Wanneer moet een organisatie een attestatie uitgeven versus vertrouwen op een token?
Een organisatie moet een attestatie uitgeven wanneer de geverifieerde informatie draagbaar, herbruikbaar en vertrouwd moet zijn door derden over een langere periode. Ze moet vertrouwen op een token wanneer ze alleen de toegang van een gebruiker binnen haar eigen systemen tijdens een enkele sessie hoeft te beheren. De juiste keuze hangt af van de vraag of de gegevens verder moeten reizen dan de organisatie die ze oorspronkelijk heeft geverifieerd.
Overweeg deze scenario’s om het onderscheid te illustreren:
- Een bankrekening openen: De bank verifieert de identiteit van de klant en kan een attestatie uitgeven. Die attestatie kan vervolgens worden gepresenteerd aan andere financiële instellingen of dienstverleners. Of hergebruik van die gegevens voor KYC-doeleinden juridisch is toegestaan, hangt echter ook af van AML-regelgeving en sectorale vereisten. Een sessietoken alleen kan dit doel nooit dienen.
- Inloggen op een intern portaal: Een medewerker authenticeert zich bij de bedrijfsidentiteitsprovider en ontvangt een access token. Het token verleent toegang tot interne tools voor die sessie. Hier is geen behoefte aan een draagbare attestatie.
- Een beroepskwalificatie bewijzen: Een zorgprofessional moet zijn registratie aantonen aan meerdere ziekenhuizen of klinieken over de grens. Een attestatie uitgegeven door de relevante autoriteit en opgeslagen in de EUDI-wallet is het juiste mechanisme. De erkenning van beroepskwalificaties volgt echter uit Richtlijn 2005/36/EG; de wallet draagt de gegevens, maar vormt niet zelf de juridische erkenningsgrondslag. Een token zou bovendien verlopen vóór het tweede gebruik.
- Een betalingsautorisatie voltooien: Een gebruiker initieert een betaling en het systeem genereert een kortlevend token om de transactie te autoriseren. Dit is een tokengebruiksscenario, geen attestatiegebruiksscenario.
Het algemene principe is dit: als de geverifieerde claim een enkele sessie moet overleven, organisatorische grenzen moet overschrijden of door de gebruiker moet worden beheerd in plaats van door het uitgevende systeem, is een attestatie het juiste hulpmiddel. Als het doel simpelweg is om toegang binnen een sessie te beheren, blijven tokens de passende en efficiënte keuze.
Hoe werken tokens en attestaties samen binnen de EUDI-wallet?
Binnen de EUDI-wallet werken tokens en attestaties samen in een gelaagde architectuur. De wallet slaat attestaties langdurig op in de wallet unit, maar wanneer een gebruiker een attestatie presenteert aan een relying party, genereren de onderliggende protocollen vaak kortlevende tokens als onderdeel van de uitwisseling. De attestatie draagt de identiteitsgegevens; het token verwerkt de autorisatiemechanica van de presentatiestroom.
Wanneer een gebruiker een attribuut uit zijn wallet wil delen met een dienstverlener, verloopt het proces doorgaans als volgt. De relying party stuurt een presentatieverzoek naar de wallet via OID4VP. De wallet vraagt de gebruiker om goedkeuring om specifieke attributen te delen. De wallet genereert vervolgens een cryptografisch ondertekend antwoord dat de relevante attestatiegegevens bevat. In veel protocolimplementaties is dit antwoord verpakt in of vergezeld van een token dat de relying party kan valideren om te bevestigen dat de uitwisseling legitiem en recent was. Daarbij is het van belang dat privésleutels van attestaties het beveiligde middel in de wallet unit niet kunnen verlaten.
Dit betekent dat zelfs in een attestatie-first architectuur zoals de EUDI-wallet, tokens niet volledig verdwijnen. Ze verschuiven van het zijn van de primaire drager van identiteitsinformatie naar het zijn van een ondersteunend mechanisme voor veilige, tijdgebonden presentatiegebeurtenissen. De attestatie blijft de bron van waarheid over de attributen van de gebruiker, terwijl het token ervoor zorgt dat de presentatie actueel, met goedkeuring van de gebruiker en gebonden aan de juiste sessie is.
Voor organisaties die integraties bouwen met de EUDI-wallet betekent dit gelaagde model dat ze beide moeten kunnen verwerken. Relying parties moeten in staat zijn om attestaties te valideren, inclusief het controleren van uitgevershandtekeningen tegen de nationale trusted list en de EU List of Trusted Lists (LOTL), de intrekkingsstatus en de wallet unit attestation, terwijl ze ook de tokengebaseerde stroom beheren die bepaalt hoe presentaties worden aangevraagd en bevestigd. Daarbij geldt dat een relying party zich onder CIR (EU) 2025/848 moet registreren bij de bevoegde nationale autoriteit voordat walletdata kan worden opgevraagd.
ID Connector: attestatieverificatie en sessiebeheer in één integratie
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 ondersteunt de ID Connector de volgende taken die direct aansluiten op het onderwerp van dit artikel:
- Verificatie van uitgevershandtekeningen tegen nationale trusted lists en de EU List of Trusted Lists (LOTL) volgens ETSI TS 119 612
- 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 buiten de onder CIR (EU) 2025/848 geregistreerde scope worden gesignaleerd
- Ondersteuning van SD-JWT VC en mdoc als credentialformaten, inclusief de bijbehorende uitwisselingsprotocollen OID4VCI en OID4VP
- Facilitering van gekwalificeerd tekenen via een aangesloten gekwalificeerde verlener van vertrouwensdiensten
De ID Connector is relevant voor organisaties in financiële dienstverlening, gezondheidszorg, farmacie en de publieke sector, waar attestaties van uiteenlopende uitgevers en lidstaten correct moeten worden verwerkt binnen bestaande onboarding- en complianceprocessen.
Neem contact op met TrustTech om te bespreken hoe de ID Connector aansluit op de identiteitsarchitectuur van jouw organisatie.