Onder eIDAS 2.0 — de informele benaming voor Verordening (EU) 2024/1183, die Verordening (EU) nr. 910/2014 wijzigt — verliest een ingetrokken attestatie onmiddellijk zijn geldigheid voor verificatiedoeleinden. Elke relying party die de status controleert, ontvangt een signaal dat aangeeft dat de attestatie niet langer vertrouwd kan worden. Intrekking is een kernonderdeel van de manier waarop het European Digital Identity (EUDI) Wallet-ecosysteem zijn integriteit waarborgt: het zorgt ervoor dat aan gebruikers uitgegeven attestaties ongeldig kunnen worden gemaakt wanneer omstandigheden veranderen, of dat nu te wijten is aan gegevensfouten, wettelijke vereisten of een verzoek van de gebruiker zelf. De onderstaande secties beschrijven hoe intrekking in de praktijk werkt, wie het beheert en wat organisaties moeten doen om er klaar voor te zijn.
Wat gebeurt er wanneer een digitale attestatie wordt ingetrokken onder eIDAS 2.0?
Wanneer een attestatie wordt ingetrokken onder eIDAS 2.0, wordt deze gemarkeerd als ongeldig in een statusregister dat wordt bijgehouden door de uitgevende autoriteit. Vanaf dat moment zal elke verificatiepoging een negatief statusresultaat opleveren. De attestatie kan nog steeds zijn opgeslagen in de EUDI-wallet van de gebruiker, maar wordt gemarkeerd als ingetrokken en mag door relying parties niet worden geaccepteerd voor authenticatie- of autorisatiedoeleinden.
Het praktische effect hangt af van het type attestatie en de dienst die erop vertrouwt. Een ingetrokken kwalificatie-attestatie zou iemand er bijvoorbeeld van weerhouden toegang te krijgen tot een gereguleerde dienst die bewijs van die kwalificatie vereist. Een ingetrokken identiteitsattest zou herauthenticatiestromen blokkeren die daarvan afhankelijk zijn. Intrekking verwijdert de attestatie niet automatisch uit de wallet. De gebruiker behoudt de gegevens lokaal in de wallet unit, maar de betrouwbaarheid ervan is verdwenen vanuit het perspectief van verificateurs.
Dit onderscheid is belangrijk voor organisaties die verificatieworkflows ontwerpen. Een systeem dat alleen controleert of een attestatie bestaat, is niet voldoende. Het moet ook verifiëren dat de attestatie momenteel geldig is, wat betekent dat de status bij elke verificatie moet worden opgevraagd.
Welke intrekkingsmechanismen zijn relevant binnen het EUDI Wallet-ecosysteem?
Binnen het EUDI Wallet-ecosysteem zijn twee primaire intrekkingsmechanismen relevant voor verifieerbare attestaties: Bitstring Status List en realtime statusopvragen vergelijkbaar met OCSP. Het Architecture and Reference Framework (ARF), ontwikkeld door de eIDAS Expert Group, beschrijft hoe deze mechanismen van toepassing zijn op attestaties die zijn uitgegeven binnen het ecosysteem, met een sterke voorkeur voor privacybeschermende benaderingen. De ARF bevat de technische uitwerking; de juridisch bindende vereisten volgen uit de verordening en de bijbehorende uitvoeringshandelingen.
De Bitstring Status List-aanpak werkt door een verwijzing naar een gepubliceerde lijst in de attestatie zelf op te nemen. Deze lijst bevat een compacte, gecodeerde weergave van de intrekkingsstatus van veel attestaties tegelijk. Een verificateur downloadt de lijst en controleert het relevante item zonder voor elke afzonderlijke attestatie een server te hoeven raadplegen. Dit vermindert de latentie en beperkt, wanneer correct geïmplementeerd, de mogelijkheid van uitgevers om bij te houden wanneer en waar attestaties worden geverifieerd.
Realtime statusopvragen houden in dat de verificateur op het moment van verificatie rechtstreeks contact opneemt met een statusendpoint. Dit biedt nauwkeurigheid tot op de seconde, maar introduceert privacyrisico’s, omdat de uitgever verificatiegebeurtenissen kan waarnemen. Het kader erkent beide methoden en laat ruimte voor implementatiekeuzes, maar privacyoverwegingen beïnvloeden in de praktijk sterk welke aanpak de voorkeur verdient.
Wie kan een attestatie intrekken in het EUDI Wallet-ecosysteem?
In het EUDI Wallet-ecosysteem is de attestatie-uitgever de primaire partij met de bevoegdheid om een attestatie in te trekken. Dit is doorgaans een overheidsinstantie, een gekwalificeerde verlener van vertrouwensdiensten of een andere bevoegde organisatie die de attestatie oorspronkelijk heeft uitgegeven. De uitgever beheert het statusregister en kan de status op elk moment bijwerken.
Verordening (EU) 2024/1183 geeft gebruikers ook betekenisvolle rechten over hun eigen gegevens. Een gebruiker kan verzoeken om intrekking of verwijdering van een attestatie, met name wanneer de gegevens niet langer accuraat zijn of wanneer zij hun goedkeuring voor gegevensdeling intrekken. Dit sluit aan bij de bredere gegevensbeschermingsprincipes die in de verordening zijn verankerd, waaronder het recht op verwijdering onder de AVG. Het is daarbij van belang onderscheid te maken tussen de goedkeuring van een dataverzoek in de wallet en AVG-toestemming als rechtsgrond: goedkeuring in de wallet is niet automatisch toestemming in de zin van artikel 6, lid 1, onder a, AVG.
In sommige scenario’s kan een regelgevende autoriteit of toezichthoudend orgaan ook een intrekking initiëren, bijvoorbeeld wanneer een beroepslicentie wordt ingetrokken of een juridische status verandert. Het belangrijkste punt voor organisaties om te begrijpen is dat de intrekkingsbevoegdheid geen enkelvoudige, gecentraliseerde functie is. Deze kan afkomstig zijn van de uitgever, de gebruiker of een regelgevende actor, en systemen moeten in staat zijn om updates van elk van deze bronnen snel te verwerken.
Hoe controleren relying parties of een attestatie is ingetrokken?
Relying parties controleren de intrekkingsstatus van attestaties door de statusverwijzing te lezen die in de attestatie zelf is opgenomen en vervolgens het bijbehorende statusendpoint te raadplegen of de relevante statuslijst te downloaden. Dit proces is doorgaans geautomatiseerd binnen de verificatiesoftware of SDK die door de relying party wordt gebruikt. Het resultaat is een geldig- of ingetrokken-signaal waarop de applicatielogica kan reageren.
Volledige verificatie van een attestatie omvat drie afzonderlijke controles:
- Verificatie van de handtekening van de uitgever tegen de relevante nationale trusted list volgens ETSI TS 119 612, en via de EU List of Trusted Lists (LOTL). Alleen deze controle kan volledig offline plaatsvinden.
- Controle van de intrekkingsstatus via statusinformatie van de uitgever, waarvoor doorgaans contact met een extern endpoint of lijst nodig is.
- Verificatie van de wallet unit attestation, waarmee wordt vastgesteld dat de presenterende wallet draait op een gecertificeerde wallet solution.
Voor organisaties die verificatiesystemen bouwen of aanschaffen, betekent dit dat twee zaken op orde moeten zijn:
- Statuscontrole moet worden geïntegreerd in elke verificatiestroom, niet alleen bij het onboarden, maar bij elke daaropvolgende interactie die op de attestatie vertrouwt.
- De verificatie-infrastructuur moet in staat zijn statuslijst-URI’s op te lossen of statusendpoints in realtime te raadplegen, wat betrouwbare connectiviteit en actuele softwarebibliotheken vereist.
Relying parties moeten ook overwegen hoe vaak zij gecachte statuslijsten vernieuwen. Een lijst die eenmaal per dag wordt gedownload, kan voldoende zijn voor laagrisico-use cases, maar scenario’s met hogere inzet, zoals financiële transacties of toegang tot gevoelige gezondheidsgegevens, vereisen mogelijk versere statuscontroles om het risicovenster tussen intrekking en detectie te verkleinen.
Wat zijn de privacyimplicaties van intrekkingscontroles?
Intrekkingscontroles brengen reële privacyrisico’s met zich mee als ze niet zorgvuldig worden geïmplementeerd. De kernzorg is dat elke keer dat een verificateur een statusendpoint raadpleegt voor een specifieke attestatie, de uitgever potentieel kan waarnemen dat de attestatie wordt gebruikt, door wie en in welke context. Dit creëert een vorm van surveillance die de gebruikerssouvereiniteitsprincipes ondermijnt die centraal staan in het EUDI Wallet-ecosysteem.
De Bitstring Status List-aanpak pakt dit aan door verificateurs toe te staan een grote batchlijst te downloaden in plaats van individuele attestaties op te vragen. Omdat de lijst veel attestaties tegelijk omvat, kan de uitgever niet gemakkelijk bepalen welke specifieke attestatie op een bepaald moment wordt gecontroleerd. Dit wordt soms kudde-privacy genoemd: het individu wordt beschermd doordat het niet te onderscheiden is binnen de menigte.
Organisaties die persoonsgegevens verwerken via attestatieverificatie moeten ook hun verplichtingen onder de AVG in overweging nemen. Het loggen van resultaten van intrekkingscontroles, het bewaren van statusgegevens of het koppelen van verificatiegebeurtenissen aan individuele profielen vereist een rechtmatige grondslag en passende bewaartermijnen. Financiële dienstverleners en zorgverleners moeten hun verificatiepraktijken afstemmen op hun bestaande gegevensbeschermingskaders. Voor gezondheidsgegevens moet daarnaast een toepasselijke grond uit artikel 9, lid 2, AVG bestaan, aangezien het hier bijzondere categorieën persoonsgegevens betreft.
Wat moeten organisaties doen om hun systemen voor te bereiden op de intrekkingsvereisten van eIDAS 2.0?
Organisaties moeten beginnen met het auditeren van hun huidige identiteitsverificatie-infrastructuur om hiaten in de verwerking van attestatiestatus te identificeren. De meeste legacy-systemen zijn niet ontworpen met dynamische intrekkingscontrole in gedachten, en het integreren van deze mogelijkheid vereist vaak wijzigingen op zowel technisch als procesniveau.
Relevante voorbereidingsstappen zijn:
- Beoordeel je verificatiestromen om te bevestigen dat statuscontroles worden uitgevoerd bij elk relevant contactpunt, niet alleen bij de initiële onboarding.
- Evalueer je statuscontrolemethode en of deze voldoet aan de privacyvereisten die zijn vastgelegd in het eIDAS 2.0-kader en het ARF.
- Werk je gegevensbeheerbeleid bij om te verduidelijken hoe intrekkingsstatusgegevens worden opgeslagen, bewaard en gebruikt in overeenstemming met de AVG.
- Test je systemen met ingetrokken attestaties om te bevestigen dat jouw applicatie deze correct afwijst en de gebruikerservaring op een nette manier afhandelt.
- Blijf in lijn met het ARF en de uitvoeringshandelingen, die blijven evolueren naarmate het EUDI Wallet-ecosysteem volwassener wordt. Houd daarbij rekening met nieuwe ARF-revisies.
Houd ook rekening met de relevante tijdlijn: de deadline voor wallet-uitgifte en publieke acceptatie door overheidsinstanties ligt op 24 december 2026. Vanaf dat moment moeten publieke instanties genotificeerde EUDI-wallets accepteren voor onlinediensten waarvoor elektronische identificatie vereist is. Voor relevante gereguleerde private sectoren geldt artikel 5f vanaf 24 december 2027. Organisaties in overheidsdiensten en gereguleerde sectoren moeten kennismaken met de resultaten van de Large Scale Pilots die tussen april 2023 en 2025 liepen, en met de technische richtlijnen van de Europese Commissie, om ervoor te zorgen dat hun implementaties echte praktijktests weerspiegelen.
Hoe ondersteunt de ID Connector van TrustTech bij attestatie-intrekking onder eIDAS 2.0
Intrekking van attestaties is een van de meer technisch veeleisende aspecten van eIDAS 2.0-compliance, en het goed uitvoeren ervan vereist zowel diepgaande regelgevingskennis als solide implementatie-expertise. 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.
Specifiek voor attestatie-intrekking biedt de ID Connector:
- Verificatie van de handtekening van de uitgever tegen de relevante nationale trusted lists, samengebracht in de EU List of Trusted Lists (LOTL), zodat alleen attestaties van erkende uitgevers worden geaccepteerd.
- Geautomatiseerde intrekkingscontrole via Bitstring Status List en realtime statusendpoints, geïntegreerd in onboarding-, authenticatie- en ondertekeningsworkflows gedurende de volledige identiteitslevenscyclus.
- Validatie van de wallet unit attestation, waarmee wordt vastgesteld dat de presenterende wallet draait op een gecertificeerde wallet solution.
- Bewaking van de geregistreerde attributenscope, zodat alleen de attributen worden opgevraagd die de relying party heeft geregistreerd bij de nationale autoriteit onder CIR (EU) 2025/848.
- Ondersteuning voor sectoroverschrijdende use cases in financiële dienstverlening, overheid, gezondheidszorg en farmacie, waar intrekkingsvereisten samenkomen met sectorspecifieke complianceverplichtingen.
Het platform van TrustTech is gebouwd op Europese digitale identiteitsstandaarden en is van de grond af ontworpen om eIDAS 2.0-klaar te zijn. Als jouw organisatie de implicaties van attestatie-intrekking wil doorwerken, neem dan contact op met TrustTech om jouw specifieke situatie te bespreken.