Kan EUDI Wallet-authenticatie worden toegevoegd aan een bestaande OpenID Connect-infrastructuur?

Ja, EUDI-wallet-authenticatie kan worden toegevoegd aan een bestaande OpenID Connect-infrastructuur. Het EUDI-wallet-ecosysteem is gebouwd op OpenID Connect-extensies, specifiek OID4VP (OpenID for Verifiable Presentations), wat betekent dat je bestaande OIDC-setup een solide basis biedt. Dat gezegd hebbende, vereist het toevoegen van wallet-ondersteuning specifieke protocolextensies, nieuwe verificatielogica en registratiestappen die verder gaan dan een standaard OIDC-configuratie. De onderstaande secties behandelen elk van de praktische vragen die organisaties stellen terwijl ze zich voorbereiden op deze integratie.

Hoe werkt EUDI-wallet-authenticatie in de praktijk?

EUDI-wallet-authenticatie werkt doordat de wallet cryptografisch ondertekende attestations presenteert aan een relying party, in plaats van een gebruikersnaam en wachtwoord of een token dat is uitgegeven door een centrale identiteitsprovider. De gebruiker keurt elke presentatie goed vanuit de wallet-app, en de relying party verifieert het resultaat aan de hand van drie afzonderlijke controles voordat toegang wordt verleend.

Die drie verificatiecontroles zijn elk afzonderlijk en dienen elk een ander doel:

1. Verificatie van de uitgevershandtekening: De relying party controleert de handtekening van de uitgever op de attestation aan de hand van de relevante nationale trusted list (ETSI TS 119 612), die deel uitmaakt van de EU List of Trusted Lists (LOTL). ARF v3.0.0 introduceert ook Lists of Trusted Entities (LoTE, ETSI TS 119 602) naast de trusted lists. Deze controle kan offline worden uitgevoerd.
2. Controle van de intrekkingsstatus: De uitgever publiceert afzonderlijke statusinformatie voor elke attestation. De relying party moet deze opvragen om te bevestigen dat de attestation niet is ingetrokken. Het overslaan van deze stap betekent dat mogelijk ongeldige credentials worden geaccepteerd.
3. Wallet unit attestation-controle: Dit bevestigt dat de wallet die de gegevens presenteert, draait op een gecertificeerde wallet solution. De wallet unit combineert de geïnstalleerde app (de wallet instance) met de Wallet Secure Cryptographic Application en het Wallet Secure Cryptographic Device waar privésleutels worden opgeslagen. Alleen de eerste controle werkt volledig offline; alle drie zijn vereist voor een volledige verificatie.

De attestations zelf zijn beschikbaar in twee credential-formaten: mdoc (ISO/IEC 18013-5 voor nabijheid, ISO/IEC TS 18013-7 voor online) en SD-JWT VC. Beide ondersteunen selective disclosure, wat betekent dat de gebruiker alleen de specifieke attributen deelt die een relying party geregistreerd heeft om te ontvangen, en niets meer. De wallet handhaaft deze scope automatisch en zal een presentatie afbreken als een verzoek verder gaat dan wat de relying party heeft geregistreerd.

Is OpenID Connect compatibel met EUDI-wallet-protocollen?

OpenID Connect is direct compatibel met het presentatieprotocol van de EUDI-wallet. Het wallet-ecosysteem gebruikt OID4VP (OpenID for Verifiable Presentations) voor het presenteren van attestations aan relying parties en OID4VCI (OpenID for Verifiable Credential Issuance) voor het uitgeven van attestations in de wallet. OID4VP is een extensie van de OAuth 2.0- en OpenID Connect-familie, zodat de onderliggende concepten, flows en tokenstructuren vertrouwd zullen zijn voor elk team dat ervaring heeft met OIDC.

Het High Assurance Interoperability Profile (HAIP) profileert zowel OID4VP als OID4VCI specifiek voor use cases met hoge betrouwbaarheid, wat het niveau is waarop de EUDI-wallet opereert. Dit profiel verscherpt bepaalde parameters en verwijdert optionaliteit die anders interoperabiliteitsproblemen tussen implementaties zou veroorzaken.

De praktische implicatie is dat OIDC en EUDI-wallet-authenticatie geen concurrerende benaderingen zijn. Een organisatie kan beide uitvoeren via dezelfde authenticatielaag, waarbij standaard OIDC-flows worden gebruikt voor bestaande identiteitsproviders en OID4VP-flows voor wallet-presentaties. De uitdaging ligt niet in de compatibiliteit op zich, maar in de specifieke extensies en verificatielogica die OID4VP vereist bovenop wat een standaard OIDC-setup al afhandelt.

Welke wijzigingen zijn nodig in een bestaande OIDC-setup?

Het toevoegen van EUDI-wallet-authenticatie aan een bestaande OIDC-infrastructuur vereist een aantal concrete wijzigingen. De kern-OIDC-flows blijven intact, maar het autorisatieverzoek, de afhandeling van responses en de verificatielogica moeten allemaal worden uitgebreid om OID4VP en de credential-formaten van de wallet te ondersteunen.

De belangrijkste gebieden die moeten worden aangepast zijn:

• Formaat van het autorisatieverzoek: OID4VP introduceert een presentation_definition-parameter die aangeeft welke attestation-typen en attributen de relying party opvraagt. Standaard OIDC-autorisatieverzoeken bevatten dit niet.
• Afhandeling van responses: In plaats van een ID-token ontvangt de relying party een Verifiable Presentation met een of meer attestations in mdoc- of SD-JWT VC-formaat. Je tokenvalidatielogica moet deze formaten kunnen verwerken.
• Verificatiepijplijn: Je moet alle drie de verificatiecontroles implementeren: de handtekening van de uitgever aan de hand van de trusted lists, de intrekkingsstatus en de wallet unit attestation. Een standaard OIDC-bibliotheek bevat geen van deze controles.
• Beheer van vertrouwensankers: Je systeem heeft toegang nodig tot de nationale trusted lists (LOTL) en Lists of Trusted Entities (LoTE) om handtekeningen van uitgevers te valideren. Dit vereist een mechanisme om deze lijsten op te halen, te cachen en actueel te houden.
• Registratie en toegangscertificaten: Voordat je systeem wallet-gegevens kan opvragen, moet je je registreren als relying party op grond van CIR (EU) 2025/848 bij een nationale autoriteit in je lidstaat van vestiging. Geregistreerde relying parties ontvangen toegangscertificaten die wallets bij elk gegevensverzoek controleren. De scope die je registreert is bindend: je kunt alleen de attributen en attestation-typen opvragen die je bij registratie hebt opgegeven, en het opvragen van meer is grond voor intrekking van je registratie.

Kunnen bestaande OIDC-bibliotheken en SDK’s EUDI-wallet-flows verwerken?

Standaard OIDC-bibliotheken kunnen EUDI-wallet-flows niet kant-en-klaar verwerken. Ze zijn niet gebouwd om Verifiable Presentations te parsen, mdoc- of SD-JWT VC-formaten te valideren, de intrekkingsstatus te controleren via door uitgevers gepubliceerde statusinformatie, of wallet unit attestations te verifiëren. Dit zijn allemaal mogelijkheden die bovenop bestaande bibliotheken moeten worden toegevoegd.

Wat bestaande OIDC-bibliotheken wel kunnen verwerken, is de onderliggende OAuth 2.0-transportlaag, de redirect- en callback-mechanismen en delen van de structuur van het autorisatieverzoek. Dat is een nuttige basis, maar het dekt alleen de buitenste envelop van een OID4VP-flow, niet de wallet-specifieke inhoud daarbinnen.

Er zijn diverse open-sourceprojecten en referentie-implementaties in opkomst die OID4VP en OID4VCI implementeren, waaronder de open-source referentie-implementatie die wordt onderhouden als onderdeel van het EUDI-wallet-programma. Deze kunnen als startpunt worden gebruikt, maar vereisen integratiewerk om te verbinden met je bestaande identiteitsinfrastructuur, sessiebeheer en backendsystemen. Teams die hun opties evalueren, moeten beoordelen of ze voortbouwen op een bestaande OIDC-bibliotheek, een speciaal gebouwde OID4VP-bibliotheek adopteren, of verbinding maken via een integratielaag die de wallet-specifieke logica afhandelt en een schonere interface biedt aan de rest van de stack.

Wat zijn de grootste integratie-uitdagingen voor organisaties?

De grootste integratie-uitdagingen gaan niet primair over het OIDC-protocol zelf, maar over de omringende infrastructuur: vertrouwensbeheer, verwerking van credential-formaten, registratienaleving en de operationele vereisten die komen kijken bij het uitvoeren van een relying party onder eIDAS 2.0.

In de praktijk lopen organisaties consequent tegen deze specifieke moeilijkheden aan:

• Beheer van trusted lists: Het actueel houden van nationale trusted lists en Lists of Trusted Entities is een doorlopende operationele taak, geen eenmalige instelling. Lijsten veranderen naarmate nieuwe uitgevers worden toegevoegd of ingetrokken, en verouderde lijsten veroorzaken verificatiefouten.
• Diversiteit aan credential-formaten: Het ondersteunen van zowel mdoc als SD-JWT VC, voor zowel nabijheidsscenario’s (ISO/IEC 18013-5) als onlinescenario’s (ISO/IEC TS 18013-7), vereist afzonderlijke parsing- en validatielogica voor elk formaat.
• Intrekkingsinfrastructuur: Het implementeren van betrouwbare intrekkingscontroles vereist netwerktoegang tot door uitgevers gepubliceerde statusendpoints bij elke authenticatiegebeurtenis. Dit voegt latentie toe en een afhankelijkheid die op een goede manier moet worden afgehandeld wanneer endpoints traag of niet beschikbaar zijn.
• Scopediscipline: De attributen die je kunt opvragen, zijn vastgelegd bij registratie. Als je use cases zich ontwikkelen, moet je je registratie bijwerken. Het bouwen van systemen die binnen de geregistreerde scope blijven en de naleving van die scope vastleggen, vereist bewust ontwerp vanaf het begin.
• Sessie- en accountkoppeling: Koppel klantgegevens niet aan een wallet unit-identifier. Dezelfde persoon kan terugkeren met een andere wallet unit en opnieuw uitgegeven attestations na het wisselen van apparaat, omdat privésleutels het beveiligde element niet kunnen verlaten en attestations opnieuw worden uitgegeven in plaats van gekopieerd. Koppel accounts via stabiele attributen of pseudoniemen.
• Grensoverschrijdende wallet-acceptatie: Een relying party moet elke gecertificeerde EUDI-wallet accepteren, ongeacht welke lidstaat deze heeft uitgegeven. Het bouwen van een systeem dat wallets van verschillende nationale implementaties verwerkt, elk mogelijk met iets andere attribuutsets, vereist flexibele attribuutmapping.

Wanneer moet een organisatie beginnen met het voorbereiden van zijn OIDC-infrastructuur?

Organisaties in gereguleerde sectoren moeten nu beginnen met het voorbereiden van hun OIDC-infrastructuur. De deadline voor publieke sector-organisaties om gecertificeerde EUDI-wallets te accepteren is 24 december 2026. Voor gereguleerde private sector-organisaties, waaronder banken, financiële dienstverleners, gezondheidszorg, telecom, energie, transport en anderen waarbij sterke gebruikersauthenticatie wettelijk of contractueel vereist is, geldt de acceptatieplicht op grond van artikel 5f vanaf 24 december 2027. Zeer grote onlineplatforms (VLOPs) die zijn aangewezen op grond van de DSA met meer dan 45 miljoen EU-gebruikers vallen ook onder de private sector-verplichting. Micro- en kleine ondernemingen met minder dan 50 werknemers en een jaarlijkse omzet of balanstotaal van niet meer dan 10 miljoen euro zijn vrijgesteld.

De registratieverplichting op grond van CIR (EU) 2025/848 van 6 mei 2025 betekent dat relying parties nationale registratie moeten voltooien voordat ze überhaupt wallet-gegevens kunnen opvragen. Registratie kost tijd, en de scope die je bij registratie opgeeft, bepaalt wat je systeem mag opvragen. Die scope goed bepalen vereist een gedetailleerd begrip van je use cases voordat je je registreert.

Een praktische tijdlijnoverweging: de nieuwe Anti-Money Laundering Regulation (AMLR) is van toepassing vanaf juli 2027, vijf maanden vóór de acceptatiedeadline voor de private sector. Organisaties in de financiële dienstverlening die hun identiteitsinfrastructuur plannen rond zowel AMLR- als eIDAS 2.0-verplichtingen hebben minder aanlooptijd dan de datum van december 2027 alleen suggereert.

Beginnen met integratiewerk in 2026 geeft tijd om te testen tegen nationale sandboxes en de open-source referentie-implementatie, registratie te voltooien en je verificatiepijplijn te valideren voordat de deadlines aanbreken. Organisaties in de financiële dienstverlening, overheid en gezondheidszorg in het bijzonder moeten de voorbereidingsperiode beschouwen als een kans om de technische fundamenten goed te leggen, in plaats van een compliancesprint op het laatste moment.

Hoe de ID Connector helpt bij EUDI-wallet-authenticatie

De ID Connector is een integratie waarmee relying parties elke gecertificeerde Europese wallet kunnen accepteren, ongeacht welke lidstaat deze heeft uitgegeven, voor identificatie, inloggen en gekwalificeerd ondertekenen. EUDI-wallet-acceptatie staat voorop; dezelfde interface ondersteunt ook andere ID’s, zoals nationale eID’s, bank-ID’s en identiteitsdocumenten, binnen en buiten de EU.

Voor organisaties die EUDI-wallet-authenticatie toevoegen aan een bestaande OIDC-infrastructuur, verwerkt de ID Connector de onderdelen van de stack die buiten standaard OIDC-bibliotheken vallen:

• Validatie van handtekeningen van uitgevers aan de hand van nationale trusted lists en Lists of Trusted Entities (LoTE)
• Controles van de intrekkingsstatus aan de hand van door uitgevers gepubliceerde statusinformatie
• Verificatie van wallet unit attestations om te bevestigen dat de presenterende wallet draait op een gecertificeerde wallet solution
• Handhaving van de geregistreerde attribuutscope, zodat verzoeken binnen wat bij registratie is opgegeven blijven
• Parsing en verwerking van zowel mdoc- als SD-JWT VC-credential-formaten voor online presentatieflows
• Hergebruik van geverifieerde identiteitsgegevens over interacties heen, waardoor herhaalde verificatie-overhead wordt verminderd

De ID Connector is relevant voor organisaties in de financiële dienstverlening, gezondheidszorg, farmacie en overheid die wallet-authenticatie moeten verbinden met bestaande systemen zonder hun identiteitsstack volledig opnieuw op te bouwen. Neem contact op met TrustTech om te bespreken hoe de ID Connector past bij je huidige OIDC-setup en je tijdlijn richting de deadlines van 24 december 2026 en 24 december 2027.