Het accepteren van een EUDI Wallet-presentatie is een vertrouwensbeslissing, en uw integratiecode is de plek waar die beslissing wordt genomen. Dit artikel is bedoeld voor relying parties: de gemeenten en dienstverleners die wallet-presentaties gaan accepteren, niet de teams die wallets bouwen. Het bevat de vragen die wij beantwoord zouden willen zien voordat de wallet voor echte gebruikers wordt ingeschakeld, als reviewchecklist en niet als afgerond ontwerp.
Weet tegen welke specificatie u bouwt
De technische basis is het Architecture and Reference Framework (ARF). Het is gepubliceerd in een openbare GitHub-repository en wordt ontwikkeld onder de Common Union Toolbox. De repository vermeldt dat de nieuwste gezaghebbende versie de meest recente getagde release is. Een branch of een samenvatting op een blog is niet gezaghebbend.
De juridische basis is Verordening (EU) nr. 910/2014, zoals gewijzigd bij Verordening (EU) 2024/1183, samen met de bijbehorende uitvoeringsverordeningen van de Commissie. Het ARF verwijst in de secties Introduction en References naar de actuele lijst daarvan.
De eerste vragen zijn dus administratief, maar ze doen ertoe:
- Tegen welke ARF-release heeft uw leverancier of integrator gebouwd?
- Wie bij u houdt nieuwe getagde releases en uitvoeringsverordeningen bij, en hoe komen wijzigingen op uw backlog terecht?
- Noemt uw contract met de identiteitsleverancier een versie, of alleen "eIDAS 2.0 compliant"?
Vragen over de assertion
De wallet levert uw dienst een presentatie aan. Voordat die een sessie kan worden, moet u weten wat u hebt geverifieerd.
- Wie heeft hem uitgegeven? Uw dienst mag alleen presentaties accepteren van uitgevers die u bewust vertrouwt, voor de attribuuttypen die u bewust accepteert. "Elke geldige handtekening" is geen beleid. Leg de acceptatielijst vast, benoem een eigenaar en bepaal hoe items worden toegevoegd en verwijderd.
- Is hij gebonden aan deze transactie? Een presentatie die opnieuw kan worden afgespeeld tegen uw login-endpoint is een gestolen credential die op misbruik wacht. Controleer met uw leverancier hoe een presentatie aan uw sessie wordt gekoppeld, en test dat een oude presentatie wordt geweigerd.
- Wat gebeurt er als verificatie mislukt of niet beschikbaar is? Bepaal of u fail closed werkt. Controleer dat foutafhandeling en piekbelasting gebruikers niet naar een zwakker terugvalpad leiden.
- Wat logt u? U hebt genoeg nodig om een incident te onderzoeken, zonder de persoonsgegevens op te slaan die de wallet juist beperkt wil houden.
Een kanttekening bij het eerste punt: het acceptatiebeleid voor uitgevers en attributen is de maatregel die wij aanbevelen. Het is geen vereiste die uit het ARF wordt geciteerd.
Vragen over attributen
De Commissie beschrijft de wallet als een middel waarmee gebruikers alleen noodzakelijke gegevens delen, zoals leeftijd of nationaliteit, terwijl andere persoonsgegevens verborgen blijven. Dat bepaalt de verwachting waaraan uw integratie als relying party moet voldoen.
Als uw dienst moet weten dat iemand boven een bepaalde leeftijd is, vraag dan daarom, niet om een geboortedatum. Hebt u een inwoner van uw gemeente nodig, vraag dan om het attribuut dat dat aantoont, niet om een volledig adres. Elk extra attribuut dat u opvraagt vergroot de hoeveelheid gegevens die u moet beschermen en in uw eigen privacybeoordeling moet verantwoorden.
Vraag vervolgens wat het attribuut daadwerkelijk bewijst. Een attribuut van een overheidsuitgever en een attribuut van een private uitgever kunnen in dezelfde wallet zitten en in uw code op elkaar lijken. Koppel elk attribuut aan de beslissing die het ondersteunt. Een bibliotheekpasnummer mag geen toegang geven tot belastingaangifte.
Een enkele regel van het acceptatiebeleid kan er zo uitzien. De waarden illustreren het formaat en zijn geen aanbeveling:
| Uitgever | Attribuut | Beslissing relying party | Eigenaar | Reviewinterval |
|---|---|---|---|---|
| Uitgever nationale identiteitsbewijzen (voorbeeld) | Ouder dan 18 jaar | Toegang verlenen tot de leeftijdsgebonden dienst; geen geboortedatum opslaan | Dienstverantwoordelijke | Elke zes maanden |
Als u niet alle vijf kolommen voor een item kunt invullen, is het nog niet klaar om op de lijst te komen.
Voor zakelijk gebruik testen de pilots organisatie-identiteiten als use case: aantonen dat iemand een legitieme vertegenwoordiger van een organisatie is. Als u bedrijven bedient, bepaal dan nu hoe u omgaat met een persoon die namens een bedrijf handelt, en hoe u te weten komt wanneer de bevoegdheid van die persoon eindigt.
Vragen over ondertekenstromen
Het ondertekenen van contracten is een van de pilotscenario's. Behandel het daarom als een aparte assurance-casus naast login.
- Van welke diensten hangt uw onderteken- of zegelstroom af, en wie beheert die?
- Wat bewaart u als bewijs van een handtekening, en hoe lang?
- Als een handtekening over twee jaar wordt aangevochten, kunt u dan aantonen wat er destijds is gepresenteerd en geverifieerd?
Ga er niet van uit dat een geslaagde login een geldige handtekeningketen impliceert. Het zijn aparte controles met aparte faalwijzen. Uw juridische en securityteams moeten het eens worden over wat als acceptabel bewijs geldt voordat het eerste contract wordt ondertekend.
Test de integratie, en test haar opnieuw
De prototype-wallet van de Commissie bevat codebibliotheken en een voorbeeldapplicatie, en de referentie-implementatie is open source. De ARF-repository verwijst naar een conformiteitswebsite. Gebruik deze om te testen, niet als productie-afhankelijkheid die u nooit hebt beoordeeld.
Bij de grootschalige pilots zijn meer dan 350 entiteiten uit 26 lidstaten, Noorwegen, IJsland en Oekraïne betrokken, en ze bestrijken onder meer overheidsdiensten, bankieren en betalingen. Uw eigen endpoints, terugvalpaden en sessieafhandeling moeten daarnaast nog steeds apart worden getest.
Behandel de integratie als nieuwe authenticatiecode. Dat betekent een threat model, abuse-case-tests op replay, misvormde presentaties en onverwachte uitgevers, en een penetratietest van de afgeronde flow vóór livegang. Wat de walletleverancier ook heeft getest, uw relying-party-dienst heeft een eigen review nodig.
Waar te beginnen
- Leg uw uitgangspunt vast: noteer de ARF-release en de uitvoeringsverordeningen waartegen uw integratie is gebouwd, en wijs iemand aan die wijzigingen in de gaten houdt.
- Schrijf een acceptatiebeleid: som de uitgevers en attribuuttypen op die u vertrouwt, de beslissing die elk ondersteunt, de eigenaar en het reviewinterval.
- Beperk uw attribuutverzoeken tot het minimum dat elke dienst nodig heeft, en leg het resultaat vast in uw eigen privacybeoordeling.
- Stel een testplan op met de referentie-implementatie en de conformiteitsmiddelen, inclusief cases voor replay, verkeerde uitgever, faalwijzen en terugvalpaden.
- Scheid login van ondertekening: bepaal welk bewijs u voor elk bewaart en wie dat goedkeurt.
- Laat een onafhankelijke review uitvoeren vóór go-live. Wilt u hulp bij het afbakenen daarvan, neem dan contact op met ons adviesteam.
