Voordat je een managed EUDI Wallet Connector in gebruik neemt, zou je IT-team vragen moeten stellen over compliance-dekking, gegevensverwerking, integratiewerk, leveranciersafhankelijkheid en beveiligingsstandaarden. Deze vragen bepalen of een connector de technische en regelgevende complexiteit van eIDAS 2.0-acceptatie daadwerkelijk afhandelt, of dat je team de moeilijke onderdelen zelf moet uitzoeken. De onderstaande secties behandelen elke vraag afzonderlijk.
Wat doet een managed EUDI Wallet Connector eigenlijk?
Een managed EUDI Wallet Connector is een integratielaag die je bestaande systemen verbindt met gecertificeerde European Digital Identity Wallets, zodat je diensten wallet-gebaseerde identificatie, inloggen en gekwalificeerd ondertekenen kunnen accepteren zonder die infrastructuur van de grond af op te bouwen. De connector regelt namens jou de technische vereisten voor wallet-acceptatie, inclusief trustverificatie en protocolondersteuning.
In de praktijk bevindt de connector zich tussen je bedrijfsprocessen en het wallet-ecosysteem. Wanneer een gebruiker zijn EUDI-wallet presenteert, verifieert de connector de cryptografische handtekening van de uitgevende instantie aan de hand van de relevante nationale trusted list, controleert de intrekkingsstatus van de attestation en valideert de wallet unit attestation om te bevestigen dat de gepresenteerde wallet op een gecertificeerde wallet solution draait. Identiteitsattributen komen al ondertekend aan door de partij die ze heeft uitgegeven, zodat de gegevens manipulatiebestendig zijn wanneer ze je systeem bereiken.
Een goed gebouwde connector dekt ook identiteitsmethoden buiten de EUDI-wallet. The 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.
Aan welke eIDAS 2.0-compliancevereisten moet de connector voldoen?
Een conforme EUDI Wallet Connector moet de credential-formaten en uitwisselingsprotocollen ondersteunen die zijn voorgeschreven door het Architecture and Reference Framework (ARF): mdoc (ISO/IEC 18013-5 voor proximity, ISO/IEC TS 18013-7 voor online) en SD-JWT VC. De connector moet ook OID4VP implementeren voor presentatie en OID4VCI voor uitgiftestromen, en de drie verificatiecontroles toepassen die eIDAS 2.0 vereist bij elke wallet-interactie.
Die drie controles zijn niet onderhandelbaar:
- Verifieer de handtekening van de uitgever aan de hand van de nationale trusted list van de relevante lidstaat.
- Controleer de intrekkingsstatus van de attestation aan de hand van de statusinformatie die de uitgever afzonderlijk publiceert.
- Valideer de wallet unit attestation om te bevestigen dat de wallet die de credential presenteert op een gecertificeerde wallet solution draait.
De tweede controle overslaan betekent dat je systeem mogelijk attestations accepteert die al zijn ingetrokken. De derde overslaan betekent dat je niet kunt bevestigen dat de wallet zelf aan de certificeringsvereisten voldoet.
Naast verificatie heeft je organisatie ook registratieverplichtingen. Op grond van CIR (EU) 2025/848 van 6 mei 2025 moeten relying parties zich registreren bij een nationale autoriteit in hun lidstaat van vestiging voordat ze wallet-gegevens mogen opvragen. Bij registratie geef je exact aan welke attributen en attestations je per beoogd gebruik zult opvragen. De wallet toetst elk verzoek aan die geregistreerde scope en blokkeert de presentatie als je meer opvraagt dan je hebt opgegeven. Het opvragen van attributen buiten je geregistreerde scope is een uitdrukkelijke grond voor intrekking van je registratie. Vraag elke leverancier van een connector of zijn product scope-grenzen automatisch handhaaft of dat aan jouw team overlaat.
De verplichting voor de private sector om te accepteren op grond van artikel 5f geldt vanaf 24 december 2027 voor gereguleerde sectoren waar sterke gebruikersauthenticatie wettelijk of contractueel verplicht is, waaronder financiële dienstverlening, gezondheidszorg, telecom, energie, transport en zeer grote onlineplatforms onder de DSA. Micro- en kleine ondernemingen met minder dan 50 werknemers en een jaarlijkse omzet of balanstotaal van maximaal 10 miljoen euro zijn vrijgesteld.
Hoe gaat een managed connector om met gegevensprivacy en -soevereiniteit?
Een managed EUDI Wallet Connector moet selective disclosure ondersteunen, wat betekent dat gebruikers alleen de attributen delen die je dienst daadwerkelijk nodig heeft, en dat je systeem alleen die attributen ontvangt. De connector mag niet meer opvragen dan je geregistreerde scope, en je eigen logpraktijken moeten die grens ook weerspiegelen.
Er is een belangrijk onderscheid om in gedachten te houden. Het transactiedashboard van de wallet is van de gebruiker: het toont welke partij welke gegevens heeft ontvangen, en de gebruiker kan van daaruit een verwijderingsverzoek indienen bij de relying party. Dat dashboard is geen logfaciliteit voor je organisatie. Leg voor je eigen administratie vast dat je binnen je geregistreerde attribuutscope bent gebleven, niet de volledige set gepresenteerde attributen. Het loggen van de volledige gepresenteerde set maakt de selective disclosure ongedaan die je aan de voorkant hebt geboden.
Aan de verwerkerszijde: als je een leverancier inschakelt om wallet-verificatie namens jou uit te voeren, is die leverancier een gegevensverwerker op grond van artikel 28 AVG, niet een relying party. De registratieverplichting blijft bij je organisatie. Leg deze taakverdeling vast in je verwerkersovereenkomst vóór de livegang.
Vraag ook of de connector geverifieerde identiteitsgegevens tussen sessies opslaat. Het hergebruiken van geverifieerde gegevens over interacties heen vermindert de wrijving voor terugkerende gebruikers, maar de connector moet die gegevens verwerken onder jouw AVG-verplichtingen, niet die van zichzelf. Begrijp precies waar gegevens worden verwerkt, hoe lang ze worden bewaard en op welke rechtsgrondslag.
Welk integratiewerk mogen IT-teams realistisch verwachten?
Het integratiewerk voor een managed EUDI Wallet Connector hangt voornamelijk af van hoe je bestaande authenticatie- en onboardingstromen zijn opgebouwd. Een connector die één API-eindpunt biedt voor alle wallet-typen en identiteitsmethoden beperkt de omvang aanzienlijk ten opzichte van het bouwen van afzonderlijke integraties per wallet of per lidstaat.
Realistische factoren om vooraf te beoordelen:
- Bestaande identiteitsinfrastructuur: Als je systemen al nationale eID’s of bank-ID’s verwerken via een identity provider, is het toevoegen van wallet-acceptatie via dezelfde interface een kleinere stap dan helemaal opnieuw beginnen.
- Ondersteuning van credential-formaten: Je backend moet zowel mdoc- als SD-JWT VC-responses kunnen verwerken. Als je huidige stack slechts één formaat ondersteunt, plan dan voor dat werk.
- Registratieproces: Het voltooien van de registratie op grond van CIR (EU) 2025/848 kost tijd en vereist dat je je attribuutscope per beoogd gebruik definieert voordat je in productie kunt testen.
- Testomgeving: Vraag of de leverancier een sandbox biedt die gecertificeerde Europese wallets uit meerdere lidstaten dekt, niet slechts één referentie-implementatie.
- Omvang van de uitrol: Identificatie, inloggen en gekwalificeerd ondertekenen omvatten elk verschillende stromen. Gekwalificeerd ondertekenen vereist een gekwalificeerde trust service provider om de handtekening uit te geven; de connector faciliteert de identiteitscontrole die daaraan voorafgaat, maar de QES zelf komt van een QTSP.
Een managed connector moet de trust management-laag abstraheren, zodat je team geen verbindingen hoeft te onderhouden met afzonderlijke nationale trusted lists of de wallet-certificeringsstatus in 27 lidstaten hoeft bij te houden. Als de leverancier verwacht dat je dat zelf beheert, is het integratiewerk aanzienlijk hoger dan geadverteerd.
Hoe moeten IT-teams leveranciersafhankelijkheid en langetermijnflexibiliteit beoordelen?
Het risico op leveranciersafhankelijkheid is reëel in de EUDI-wallet-ruimte, omdat de technische specificaties nog steeds evolueren. Het ARF bevindt zich momenteel op versie 3.0.0 en wordt periodiek herzien. Een connector die aannames uit een eerdere versie hardcodeert, kan bij updates van de uitvoeringshandelingen aanzienlijk herwerk vereisen.
Belangrijke vragen om aan elke leverancier te stellen:
- Hoe ga je om met ARF-versieupdates, en wat is het proces voor het uitrollen van wijzigingen naar klanten?
- Maakt de connector doorlopend gebruik van open, gestandaardiseerde protocollen (OID4VP, OID4VCI, SD-JWT VC, mdoc), of introduceert hij propriëtaire lagen?
- Kan je organisatie overstappen naar een andere connector zonder je identiteitsstromen helemaal opnieuw op te bouwen?
- Wat gebeurt er met je geregistreerde attribuutscope en toegangscertificaten als je naar een andere leverancier migreert?
Gestandaardiseerde protocollen zijn je beste bescherming tegen leveranciersafhankelijkheid. Een connector die volledig is gebouwd op OID4VP, OID4VCI en de door het ARF voorgeschreven formaten geeft je een migratiepad als je dat ooit nodig hebt. Propriëtaire datamodellen of aangepaste authenticatielagen maken dat pad veel moeilijker.
Houd ook rekening met het updateritme van de leverancier ten opzichte van de regelgevingstijdlijn. De private acceptatieverplichting treedt in werking op 24 december 2027, en uitvoeringshandelingen zullen voor en na die datum verder worden verfijnd. Een leverancier die achterloopt op de specificatiecyclus creëert compliancerisico voor je organisatie, niet alleen een technisch ongemak.
Aan welke beveiligings- en beschikbaarheidsstandaarden moet de connector voldoen?
Een managed EUDI Wallet Connector verwerkt geverifieerde identiteitsgegevens op een hoog betrouwbaarheidsniveau, wat betekent dat de beveiligings- en beschikbaarheidsvereisten navenant hoog zijn. De EUDI-wallet opereert op betrouwbaarheidsniveau hoog onder eIDAS 2.0, en je connector moet in staat zijn dat vertrouwensniveau te hanteren zonder zwakke plekken te introduceren.
Vraag op beveiligingsgebied om bewijs van het volgende:
- Certificering: ISO 27001 is een basisnorm voor informatiebeveiligingsbeheer. Voor zorgcontexten is NEN 7510 de relevante Nederlandse norm. Vraag welke certificeringen de leverancier heeft en wanneer de laatste audit heeft plaatsgevonden.
- Cryptografische verwerking: Privésleutels die zijn gekoppeld aan attestations mogen nooit het beveiligde cryptografische apparaat van de wallet unit verlaten. Je connector mag die sleutels niet opslaan of repliceren. Bevestig hoe de leverancier sleutelmateriaal op zijn infrastructuur beheert.
- Manipulatiebestendige logging: De connector moet auditlogs produceren die bevestigen dat je binnen je geregistreerde attribuutscope hebt geopereerd, zonder de volledige set gepresenteerde attributen vast te leggen op een manier die selective disclosure tenietdoet.
Overweeg op het gebied van beschikbaarheid wat er gebeurt als de connector niet bereikbaar is tijdens een gebruikersauthenticatiepoging of een ondertekeningssessie. Vraag om gedocumenteerde SLA’s, incidentresponsprocedures en of de connectorarchitectuur redundantie over regio’s heen omvat. Voor sectoren als financiële dienstverlening en gezondheidszorg heeft uitval in de identiteitslaag directe operationele gevolgen.
Vraag ten slotte hoe de leverancier de intrekkingscontrole uitvoert. De intrekkingsstatus vereist een live aanroep naar het statuseindpunt van de uitgever. Als de connector intrekkingsgegevens cachet, begrijp dan wat de maximale verouderdheid van die cache is en of dat acceptabel is voor je risicoprofiel.
Hoe helpt de ID Connector bij EUDI-wallet-integratie
De ID Connector van TrustTech 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 IT-teams die de bovenstaande vragen doorlopen, pakt de ID Connector de kernuitdagingen van de integratie direct aan:
- Trust management achter wallet-acceptatie wordt automatisch afgehandeld, inclusief handtekeningverificatie aan de hand van nationale trusted lists, intrekkingscontroles en validatie van wallet unit attestations.
- Geverifieerde identiteitsgegevens zijn herbruikbaar over interacties heen, zodat een gebruiker die al is geïdentificeerd het proces niet hoeft te herhalen voor een volgende inlogsessie of ondertekeningssessie.
- De connector dekt identificatie, inloggen op hoog betrouwbaarheidsniveau en gekwalificeerd ondertekenen via een gekoppelde QTSP, binnen één enkele integratie.
- Één interface dekt gecertificeerde Europese wallets naast de eID’s, bank-ID’s en identiteitsdocumenten die je gebruikers vandaag al hebben.
De ID Connector wordt gebruikt door organisaties in financiële dienstverlening, gezondheidszorg, farmacie en de overheid, waar geverifieerde identiteit en naleving van regelgeving operationele vereisten zijn. Neem contact op met TrustTech om te bespreken hoe de ID Connector aansluit op je bestaande systemen en je tijdlijn voor eIDAS 2.0-acceptatie.