EUDI-wallet accepteren: verificatie, logging en uitzonderingen inrichten

Je kunt een EUDI-wallet technisch laten terugkomen als een QR-code en toch een onbetrouwbare onboarding bouwen. De echte fout zit meestal erna: een claim wordt aan het verkeerde klantrecord gekoppeld, een verlopen credential wordt als geldig opgeslagen, of een medewerker ziet alleen ‘mislukt’ zonder te weten waarom.

Deze gids is voor de eigenaar of productverantwoordelijke van een dienst, portaal of klantomgeving die één relying-party-flow goed wil inrichten. Je werkt van registratie en minimale scopes naar verificatie, klantkoppeling, auditlog, fallback en vrijgave. De technische uitvoeringshandelingen blijven bewust verwisselbaar, want nationale registers, profielen en walletimplementaties bewegen nog.

Een relying party is de organisatie die gegevens uit een EUDI-wallet opvraagt en controleert voor een digitale dienst. Zij moet zich herkenbaar maken aan de wallet, vooraf aangeven welk doel en welke attributen zij nodig heeft, de ontvangen presentatie zelf valideren en de uitkomst verantwoord aan een klantrecord koppelen. Toestemming in de wallet is dus één stap in de keten, geen eindbesluit.

Stand 4 oktober 2026: de Europese Commissie houdt vast aan minstens één wallet per lidstaat eind 2026. De Nederlandse overheidsuitleg noemt de wallet vrijwillig voor de burger en beschrijft private acceptatie als een latere verplichting. De precieze plicht hangt af van je sector, sterke klantauthenticatie en de uitzonderingen voor micro- en kleine ondernemingen. Voor de juridische aanleiding kun je de verschillen tussen vrijwillig gebruik en acceptatieplicht per organisatie nalezen.

Wat je nodig hebt voordat je koppelt

Begin niet met een walletknop. Begin met één afgebakende handeling, bijvoorbeeld een nieuwe zakelijke klant laten aantonen dat zij namens een onderneming mag bestellen. Leg vast welke beslissing je met de presentatie wilt nemen en welke gegevens daarvoor strikt nodig zijn.

De wet noemt dit het intended use. Bij registratie geef je aan welke gegevens je wilt opvragen en waarom. Artikel 5b van de herziene eIDAS-verordening verbiedt je daarna om buiten die aangemelde gegevens te gaan. De registratieverplichting en verantwoordelijkheid voor authenticatie en validatie zijn dus geen documentatie achteraf, maar input voor je ontwerp.

Voor één eerste flow heb je het volgende nodig:

• Een gebruiksdoel: één zin die een klant en een toezichthouder begrijpen, zoals ‘controleer de identiteit van de vertegenwoordiger en zijn bevoegdheid om voor onderneming X te handelen’.
• Een claimlijst: de exacte attributen, credentialtypen, issuercategorieën en geldigheidsvoorwaarden die je werkelijk gebruikt.
• Een relying-partyregistratie: bedrijfsnaam, vestigingsland, officiële registratiegegevens, contactpunt, privacybeleids-URL, doel en aangevraagde gegevens.
• Een verifier: een component die OpenID4VP-requests maakt, presentaties ontvangt en cryptografische controles uitvoert.
• Een klantkoppeling: een bestaande sleutel of een expliciete procedure voor nieuwe records. Naam en e-mailadres zijn geen betrouwbare primaire sleutel.
• Een auditmodel: events voor gestart, geweigerd, ontvangen, gevalideerd, afgewezen, ter beoordeling gezet en vrijgegeven.
• Een uitzonderingsroute: eigenaar, reactietijd, redenencodes en bewijs dat een medewerker mag zien.
• Een testomgeving: een wallet, issuer, proefcredentials en een veilige callback op HTTPS.

Je hebt daarnaast deze rollen en vaardigheden nodig: een product- of procesverantwoordelijke die het intended use en de risicoklasse vastlegt, een backend- of integratie-engineer met kennis van OpenID4VP, VC-formaten, TLS en API-foutafhandeling, iemand voor PKI, keystores en monitoring, en een privacy- of securityverantwoordelijke voor grondslag, DPIA, threat model en bewaartermijnen. Reserveer ook een supportmedewerker of operations-eigenaar voor de reviewwachtrij. Eén persoon mag meerdere rollen combineren in een pilot, maar cryptografische validatie en de uiteindelijke businessbeslissing mogen niet alleen op vendorconfiguratie rusten.

Reken voor planning op deze orde van grootte, niet op alleen een licentiesignaal:

Dit zijn transparante planningsramingen voor de totale implementatie, geen offerte of publieke productprijs. Neem naast de verifier ook registratie, certificaten, KMS, integratie met klantrecords, logging, conformance-tests, DPIA, monitoring en incidentrespons mee.

De huidige bouwblokken hebben verschillende volwassenheidsniveaus. De definitieve OpenID4VP 1.0-specificatie werd op 9 juli 2025 gepubliceerd. De EUDI-architectuur beschrijft daarnaast mdoc, SD-JWT VC en W3C Verifiable Credentials als mogelijke credentialformaten. Kies daarom geen product omdat het alleen een QR-code kan tonen. Kies op ondersteunde profielen, trust-listbeheer, revocatie, replaybescherming, logs en de manier waarop een fout bij jou aankomt.

Concrete stappen: van registratie naar klantrecord

Met deze aanpak bouw je een controleerbare EUDI-walletflow: je registreert het intended use, vraagt alleen noodzakelijke claims op, valideert presentatie en trust, koppelt veilig aan één klantrecord, logt het besluit en routeert uitzonderingen naar retry, review of afwijzing. Je eindigt met tien proefclaims en een expliciete productie-vrijgave zonder verborgen verlaging van de assurance.

Zo pak je de flow stap voor stap aan:

1. Schrijf je intended use als een beslisregel

Zet het doel om in een zin met drie delen: welke dienst lever je, welke beslissing neem je en welke gegevens zijn daarvoor nodig. Bijvoorbeeld: ‘Voor toegang tot het leveranciersportaal controleer ik de naam van de vertegenwoordiger, het ondernemingsnummer en een geldig mandaat.’

Maak daarna een tabel met per claim de reden, bron, minimale waarde en actie bij ontbrekende data. Vraag voor leeftijdscontrole bijvoorbeeld een leeftijdsuitkomst en geen geboortedatum als de exacte datum niets aan je beslissing toevoegt. Vraag voor een bedrijfsportaal het ondernemingsnummer en de vertegenwoordigingsbevoegdheid, niet de volledige PID als die geen rol speelt.

Gebruik OpenID4VP met een DCQL-query of het profiel dat je verifier aanbiedt om alleen die claims op te vragen. De definitieve OpenID4VP-specificatie beschrijft zowel same-device als cross-device flows, claimselectie en foutuitkomsten. Behandel een scope dus als een technische en beleidsmatige allowlist, niet als een algemeen verzoek om ‘identiteit’.

2. Regel de relying-partyregistratie en certificaten

Registreer je in het lidstaatregister waar je onderneming gevestigd is. De registratie bevat minstens je vestigingslidstaat, naam en eventuele officiële registratiegegevens, contactgegevens, bedoeld gebruik en de gegevens die je wilt opvragen. Versioneer deze registratie in je eigen configuratie, bijvoorbeeld ‘rp-registration-v1’, en leg vast welke release van je software erbij hoort.

Vanaf 24 december 2026 is Uitvoeringsverordening (EU) 2025/848 van toepassing. Die verordening werkt nationale registers, een gemeenschappelijke API en wallet-relying-party-accesscertificaten uit. Een accesscertificaat identificeert je verifier tegenover de wallet. Een registratiecertificaat kan daarnaast het intended use en de toegestane attributen dragen. De lidstaat bepaalt welke certificaten worden uitgegeven, dus zet deze onderdelen achter configuratie en niet hard in je applicatielogica.

Controleer na registratie drie dingen: staat je organisatie publiek en machineleesbaar in het register, komt het certificaat overeen met je productie-verifier en is de privacybeleids-URL bereikbaar? Bij een wijziging van doel, claimset, domein of juridische entiteit moet je de registratie bijwerken. Een oude claimset in je software laten staan is dan een acceptatierisico.

3. Kies een verifier die je werkelijk kunt beheren

Voor een proefopstelling kun je het open-source EUDI Verifier Endpoint gebruiken. De release-index vermeldt op 4 oktober 2026 v0.12.0 als meest recente gelabelde release. Pin in je testconfiguratie die versie in plaats van latest. De reference implementation implementeert OpenID4VP 1.0, heeft een Verifier API voor het starten van een transactie en het ophalen van een walletresponse, en een Wallet API voor request objects en direct_post. De repository noemt het expliciet een ontwikkeltool. De API’s moeten op HTTPS staan, de Verifier API moet worden afgeschermd en de release waarschuwt dat de software niet als productieapplicatie moet worden gebruikt.

Heb je al Keycloak 26.8.0, uitgebracht op 1 oktober 2026, dan is dat een bruikbare proefroute. De release kan OID4VP-presentaties verifiëren, ondersteunt cross-device en direct_post.jwt, en heeft mappers om SD-JWT-attributen naar gebruikers- of sessievelden te brengen. OID4VP staat in deze release nog als experimentele functie vermeld. Gebruik het dus om je integratie te leren kennen, niet als argument om een productieflow zonder eigen acceptatietest vrij te geven.

Een beheerde API kan sneller zijn. Digidentity beschrijft op de op 4 oktober 2026 gecontroleerde productpagina een verifier-API die een request, QR-code of deeplink maakt en resultaten via SAML of OpenID Connect teruggeeft. Diezelfde pagina noemt mDoc, SD-JWT en JWT als ondersteunde credentialformaten. walt.id heeft volgens de op 4 oktober 2026 gecontroleerde product- en prijsinformatie een self-managed Community Stack, een Enterprise Stack en een beheerde Cloud Platform met diensten en API’s. De open-source kern valt onder Apache 2.0; Enterprise voegt onder meer persistentie, RBAC en audit- of eventlogging toe. De actuele Community-documentatie raadt voor nieuwe projecten Verifier2 met OID4VP 1.0 aan en markeert de oorspronkelijke Verifier API als deprecated. Behandel deze productclaims als startpunt voor een leveranciersonderzoek. Vraag naar de precieze credentialprofielen, trust-listupdates, subverwerkers, dataretentie, incidentmeldingen, support-SLA en exitmogelijkheden.

De verifier is een aparte API-integratie, ook als hij naast je bestaande identity provider draait. Je wilt de walletprotocollen niet vermengen met je klantdomein. Laat de verifier een duidelijke, versieerbare uitkomst teruggeven aan jouw domeinlaag.

4. Bouw de request- en responsegrenzen

Maak voor elke transactie een kortlevende transaction_id, state, nonce en een doelgebonden request. De QR-code of deeplink bevat geen klantdata. De callback accepteert alleen de verwachte response-URI, valideert de state één keer en markeert de transactie als gebruikt. Een tweede presentatie met dezelfde nonce is een replay, geen tweede poging.

Gebruik TLS, onderteken requests waar je profiel dat vereist en bewaar private sleutels in een keystore of KMS. De reference verifier gebruikt bijvoorbeeld een externe keystore voor het accesscertificaat. Stel time-outs in voor een walletrequest en laat een verlopen transactie niet alsnog verdergaan omdat de gebruiker een oude browserpagina opent.

Teken in je eigen systeem de grens tussen REQUEST_CREATED, WALLET_DECLINED, VP_RECEIVED en VALIDATION_FINISHED. Zo kun je onderscheiden of de gebruiker afhaakte, de wallet niet beschikbaar was of de inhoud ongeldig bleek. Dat verschil bepaalt je foutmelding en je fallback.

5. Valideer de presentatie in vaste lagen

Laat je applicatie nooit beslissen op basis van een veld als verified: true zonder de onderliggende controles te kennen. De validatie heeft minstens deze volgorde:

1. Protocol en transport: controleer state, nonce, response mode, audience, request-id, éénmalig gebruik en de toegestane callback.
2. Formaat en schema: controleer of het credentialtype, de claims en de datatypen passen bij je geregistreerde profiel.
3. Handtekening en issuer: controleer de cryptografische handtekening, certificaatketen, trust anchor en bevoegdheid van de issuer voor dit credentialtype.
4. Geldigheid en intrekking: controleer issued_at, valid_from, valid_until en een status- of revocationlijst.
5. Binding: controleer waar het profiel dat vereist de device binding, proof of possession en user binding.
6. Selectieve claimset: controleer dat je alleen de aangevraagde en goedgekeurde attributen hebt ontvangen.
7. Zakelijke regels: controleer of de claim bij het doel past, bijvoorbeeld een geldig mandaat voor deze onderneming.

De ARF beschrijft voor relying parties handtekeningcontrole, revocatie, device binding en user binding. Voor credentials met een geldigheid langer dan 24 uur hoort revocatie-informatie in de credential te staan, met een URL naar een status- of revocatielijst. Als die lijst niet bereikbaar is, krijg je geen geldig-antwoord cadeau. Neem dan een expliciete risico-uitkomst, bijvoorbeeld RETRY of REVIEW, en accepteer alleen automatisch als je vooraf hebt vastgelegd waarom dat voor deze dienst verantwoord is.

Maak de einduitkomst klein en uitlegbaar: ACCEPT, REJECT, REVIEW of RETRY. Koppel aan elke uitkomst een reden zoals ISSUER_NOT_TRUSTED, CREDENTIAL_EXPIRED, STATUS_UNAVAILABLE, CLAIM_OUTSIDE_REGISTERED_SCOPE of RECORD_CONFLICT. Een medewerker moet aan de reden kunnen zien welke vervolgstap toegestaan is.

6. Koppel de bewezen identiteit aan het juiste klantrecord

Maak eerst een pending-transactie aan voordat je de wallet opent. Koppel die transactie aan de ingelogde sessie, aanvraag of uitnodigingscode. Bij nieuwe klanten is het record nog leeg; bij bestaande klanten gebruik je een vooraf bekende record-id. Zo komt een late callback niet per ongeluk bij de eerstvolgende browsergebruiker terecht.

Gebruik een officieel ondernemingsnummer of een RP-gebonden pseudoniem als matchwaarde wanneer je use case dat toelaat. Gebruik naam en e-mailadres alleen als ondersteunend gegeven. Een EUDI-wallet is juist ontworpen om selectief gegevens of een pseudoniem te delen. Een universele, overal herbruikbare persoonsidentifier hoort daarom niet je standaardmatch te zijn.

Maak drie uitkomsten voor de koppeling:

• Exacte match: de geverifieerde sleutel hoort bij precies één record en alle zakelijke voorwaarden kloppen.
• Geen match: er bestaat geen record. Maak alleen automatisch een nieuw record als je dat in je proces hebt toegestaan en de claimset voldoende is.
• Conflict: meerdere records, afwijkend ondernemingsnummer, verlopen mandaat of afwijkende naam. Zet de transactie op REVIEW; overschrijf geen klantdata.

Bewaar standaard de minimale set: transaction-id, credentialtype, issuer-id, relevante claimwaarden, geldigheidsperiode, verifierprofiel, trust-listversie, validatie-uitkomst en gekoppelde record-id. Sla de volledige VP of PID alleen op als je een aantoonbare grond, bewaardoel, beveiligingsmaatregel en verwijderprocedure hebt. Een hash van een ontvangen payload kan soms helpen bij onderzoek, maar is geen vervanging voor een correcte auditbeslissing.

7. Maak een auditlog die een beslissing kan verklaren

Log niet alleen het eindresultaat. Een controleerbare auditregel bevat minimaal:

• tijd in UTC en transaction-id;
• relying-party-id, verifierinstantie en softwareversie;
• intended-use-id en versie van de opgevraagde claimset;
• walletresponse-type en credentialtype;
• issuer-id en relevante trust-listbron of trust-listversie;
• uitkomsten van handtekening, geldigheid, revocatie, binding en scopecontrole;
• record-id, matchmethode en conflictcode;
• eindbesluit, reden, medewerker of service-account en tijd van vrijgave;
• bewaartermijn en verwijderstatus.

Log claimnamen en beslisuitkomsten, niet automatisch alle claimwaarden. Masker persoonsgegevens in foutmeldingen. Geef supportmedewerkers geen toegang tot private sleutels of volledige credentials wanneer een redenencode volstaat. Houd operationele logs, beveiligingslogs en het bewijs van een klantbesluit logisch gescheiden.

De wallet zelf krijgt een transactiehistorie, ook wanneer een transactie niet wordt afgerond. Dat helpt de gebruiker, maar ontslaat jou niet van je eigen AVG-verplichtingen. Toestemming in de wallet is geen rechtsgrond voor jouw verwerking. Bepaal doel, grondslag, bewaartermijn, betrokkenenrechten en zo nodig een DPIA vóór je productiegegevens verwerkt.

Let ook op het verschil tussen registerbewaring en klantdata. Uitvoeringsverordening 2025/848 verplicht de registrar om registratie-informatie en wijzigingen tien jaar te bewaren. Dat betekent niet dat jij iedere ontvangen persoonsclaim tien jaar mag bewaren.

8. Ontwerp fallback en menselijke behandeling als aparte paden

Een gebruiker kan weigeren, de wallet kan niet beschikbaar zijn, de presentatie kan buiten je profiel vallen, of de statusdienst kan tijdelijk niet reageren. Geef bij elk geval een begrijpelijke melding en een volgende stap. STATUS_UNAVAILABLE is iets anders dan CREDENTIAL_REVOKED; een medewerker moet dat verschil zien.

Een fallback mag de dienst toegankelijk houden, maar niet je assurance stilletjes verlagen. Mogelijke paden zijn een bestaande login voor een laagrisicodienst, een handmatige documentcontrole voor een tijdelijke uitzondering of een nieuwe walletpoging. Voor een gereguleerde onboarding moet je vooraf bepalen welke alternatieve route juridisch en operationeel gelijkwaardig genoeg is.

Gebruik per risicoklasse deze vaste grens. De classificatie hoort bij de handeling, niet bij de gebruikte tool.

De menselijke wachtrij krijgt een eigenaar, maximale wachttijd en vaste beslisregels. Toon de medewerker alleen de claims die voor het conflict nodig zijn. Laat de medewerker kiezen uit ACCEPT_AFTER_REVIEW, REJECT en REQUEST_NEW_PRESENTATION, met een verplichte reden. Een losse vrije tekst zonder redenencode maakt je auditlog later onbruikbaar.

Valkuilen die je acceptatieflow breken

Je vraagt de volledige PID omdat dat makkelijk lijkt. Daarmee verlies je dataminimalisatie en maak je de walletprompt minder begrijpelijk. Schrijf per claim op welk besluit hij ondersteunt en verwijder de rest uit de request.

Je behandelt gebruikersgoedkeuring als juridische toestemming. De wallet registreert de keuze van de gebruiker. Jij blijft verantwoordelijk voor rechtsgrond, transparantie, doelbinding en bewaartermijn. Laat privacy en security de flow vóór productie beoordelen.

Je vertrouwt op de issuernaam uit de payload. Een tekstveld met de naam van een overheidsinstantie is geen trust anchor. Controleer de handtekening, certificaatketen, trust list en bevoegdheid van de issuer.

Je controleert revocatie alleen tijdens de pilot. Een credential kan na uitgifte ongeldig worden. Cache statusinformatie alleen met een expliciete versheidsgrens en kies bij een onbereikbare statusdienst voor retry of review.

Je gebruikt demo-software als productiecomponent. De Europese reference verifier is nuttig om het protocol te leren en je API-contract te testen. De repository waarschuwt zelf voor beperkte security, stabiliteit en documentatie. Bouw voor productie een eigen hardeninglaag of kies een leverancier met een contractuele support- en incidentroute.

Je koppelt op naam en e-mail. Dat geeft false positives door dubbele namen, gedeelde mailboxen en wijzigingen. Koppel op een voor deze relying party passende, geverifieerde sleutel en laat conflicten naar review gaan.

Je logt de hele credential omdat dat later handig lijkt. Een brede kopie vergroot de impact van een lek en maakt verwijdering moeilijk. Bewaar het bewijs van de beslissing en alleen de attributen die je proces nodig heeft.

Je bouwt een fallback die de controle overslaat. Een alternatief kanaal is geen reden om een ongeldige walletpresentatie te accepteren. Geef de gebruiker een nieuwe verificatiepoging of stuur naar een procedure met dezelfde risicoklasse.

Je vergeet wijzigingen in registratie en profielen. Een nieuwe claim, domeinnaam, issuer of technisch profiel is niet alleen een softwarewijziging. Zet een wijziging door naar registratie, privacytekst, verifierconfiguratie, tests en auditversie.

Beslis-kader: kopen, koppelen of zelf bouwen?

Voor de meeste organisaties is de juiste keuze een bestaande verifier met een dunne eigen domeinlaag. Je bouwt dan zelf de koppeling naar klantrecords, beleid, logs en menselijke review, maar neemt geen cryptografie of protocolimplementatie over die je niet hoeft te bezitten.

Kies een beheerde verifier als je snel meerdere walletprofielen wilt bereiken, weinig eigen cryptografische expertise hebt en contractueel kunt vastleggen waar data wordt verwerkt. Controleer of de dienst werkelijk jouw relying-partyregistratie, trust-listupdates, revocatie, dataminimalisatie en auditbewijs afdekt. Een API die alleen een naam teruggeeft is geen complete complianceflow.

Kies een identity-platformroute als Keycloak al je sessies, gebruikers en autorisatie beheert. Keycloak 26.8.0 maakt een eerste OID4VP-proef praktisch, maar de officiële release markeert de OID4VP-verifier als experimenteel. Plan dus een onafhankelijke test op validatie, foutafhandeling, versie-upgrades en logging vóór je een besluit neemt.

Kies self-hosted open source als data- en sleutelbeheer zwaar wegen en je een team hebt dat updates, trust lists, keystores, monitoring en incidenten kan dragen. De walt.id Community Stack is een concreet voorbeeld met Apache 2.0-licentie en eigen infrastructuur. De EUDI reference implementation is bruikbaar als ontwikkelbasis, maar vraagt meer engineering en hardening dan de naam ‘reference’ suggereert.

Kies maatwerk rond een bestaande verifier zodra je matchregels, mandaten, meerdere juridische entiteiten, fysieke en online flows of een zware menselijke uitzonderingsroute hebt. Maatwerk betekent hier vooral dat je de vertaallaag beheerst: van walletuitkomst naar een uitlegbaar bedrijfsbesluit. Het betekent niet dat je zelf een nieuwe walletstandaard moet ontwerpen.

Uitgewerkt voorbeeld: een zakelijk leveranciersportaal

Onderstaand is een fictief rekenvoorbeeld om de beslissingen zichtbaar te maken, geen bestaand klantverhaal. Stel dat een leveranciersportaal nieuwe vertegenwoordigers van bedrijven toelaat om bestellingen te plaatsen. Het portaal heeft al een klantrecord per onderneming, met een intern company_id. De walletflow moet twee vragen beantwoorden: is dit de persoon die de onderneming beweert te vertegenwoordigen, en mag deze persoon namens die onderneming bestellen?

De producteigenaar definieert één intended use: ‘toegang tot het leveranciersportaal en controle van vertegenwoordigingsbevoegdheid’. De claimset bestaat illustratief uit een PID met naamgegevens, een bedrijfsattestatie met ondernemingsnummer en een mandaatclaim met einddatum. De exacte claimpaden verschillen per profiel en issuer. De software gebruikt dus geen losse veldnamen als beleid, maar een versieerbare mapping supplier-portal-v1.

De gebruiker start op een uitnodigingslink die al aan company_id=NL-042 is gebonden. Het portaal maakt een pending-transactie met transaction_id=tx-20261004-001, een nonce en een vervaltijd van vijf minuten. De verifier maakt een OpenID4VP-request met het doel en de drie noodzakelijke claimgroepen. De wallet toont de naam van de relying party, vraagt goedkeuring en stuurt een presentatie terug.

De validatieservice verwerkt de respons als volgt:

1. State en nonce kloppen met de pending-transactie en zijn nog niet gebruikt.
2. De credentialformaten en claimpaden passen bij supplier-portal-v1.
3. De issuerketen is geldig tegen de bijgewerkte trust-listbron en de issuer mag dit type bedrijfsattestatie uitgeven.
4. De geldigheid en revocatiestatus zijn positief.
5. De presentatie bevat proof of possession en de walletbinding die het gekozen profiel vereist.
6. Het ondernemingsnummer in de attestatie is NL-042 en het mandaat eindigt op 31 december 2026.
7. Het klantrecord is uniek, dus de flow krijgt ACCEPT.

Het klantrecord krijgt niet de volledige presentatie als bijlage. Het portaal bewaart company_id, een RP-gebonden gebruikersreferentie, credentialtype, issuer-id, mandaat-einddatum, transaction-id, profielversie, trust-listversie en de einduitkomst. Een medewerker kan later zien waarom de gebruiker toegang kreeg zonder een compleet identiteitsdossier uit een mobiele wallet te kopiëren.

Dezelfde flow moet ook kunnen weigeren. Bij een geldig persoonlijk credential met een ondernemingsnummer dat niet bij NL-042 hoort, is de uitkomst REVIEW, niet ‘maak een nieuw klantrecord’. Bij een ingetrokken credential is de uitkomst REJECT. Bij een tijdelijke statusstoring is de uitkomst RETRY, met een melding dat de verificatie niet kon worden afgerond. Bij een geweigerde walletprompt is de uitkomst CANCELLED_BY_USER.

Voor de acceptatieomgeving voer je tien proefclaims uit:

De vrijgave-eis is eenvoudig te controleren: alle tien proefclaims hebben een verwachte uitkomst, iedere uitkomst verschijnt met een reden in het auditlog en er blijft nul onverklaarde verificatie over. De producteigenaar tekent pas vrij nadat ook een mislukte presentatie, een herhaalde callback en een onbereikbare statusdienst zijn bekeken.

Vergelijkingstabel: welke verifier past bij jouw situatie?

De volgende vergelijking gebruikt actuele productinformatie die op 4 oktober 2026 is gecontroleerd. De versie- en capabilityclaims over de EUDI Verifier Endpoint, Keycloak, Digidentity en walt.id zijn op die datum opnieuw nagekeken in de release notes, productpagina’s en documentatie. Licentiekosten zijn niet hetzelfde als totale kosten: certificaten, privacywerk, integratie, beheer en incidentrespons bepalen de productierekening.

De keuze is pas goed als je niet alleen een geldige presentation kunt ontvangen, maar ook kunt uitleggen waarom een record is gekoppeld, waarom een twijfelgeval niet automatisch is vrijgegeven en hoe je een wijziging in trust of registratie uitrolt.

Een EUDI-wallet maakt het delen van identiteit korter, niet je verantwoordelijkheid kleiner. Wie de flow bouwt als een serie bewijsbare beslissingen, geeft de klant controle over zijn gegevens én houdt zelf grip op de vraag wat er precies is gecontroleerd, waarom een record is gekozen en wanneer een mens moet meekijken. Dat is het verschil tussen een walletknop en betrouwbare identiteitsinfrastructuur.