Hoe eIDAS-verificatie werkt: een technische deep dive

Een uitgebreide technische uitsplitsing van de eIDAS-verificatieflow, van QR-codegeneratie tot attribuutvalidatie, met protocollen, beveiligingsmaatregelen en integratiepatronen.

eIDAS Pro Team
22 januari 2026
12 min leestijd

Gecorrigeerd op 29 oktober 2026: het voorbeeld van de wallet-flow liet de wallet eidas-pro.com noemen als de partij die de gegevens opvraagt. Via een intermediair zoals eIDAS Pro noemt de wallet de webshop voor wie het verzoek wordt gedaan, niet de intermediair (EUDI Wallet Architecture and Reference Framework v3.0.0, vereiste RPI_07).

Gecorrigeerd op 20 oktober 2026: in een eerdere versie van dit artikel stond dat de PID van de EUDI Wallet een attribuut age_over_18 kan vrijgeven. Dat kan niet — de PID bevat geen leeftijdsattribuut, dus de verifiërende partij vraagt alleen de geboortedatum op en leidt het ja/nee zelf af. age_over_18 bestaat alleen in de afzonderlijke leeftijdsattestatie (proof-of-age attestation, eu.europa.ec.av.1). We presenteren ID Austria, Smart-ID en BankID ook niet langer als EUDI Wallets (het zijn bestaande nationale eID-apps), en we hebben verduidelijkt dat de verifiërende partij de handtekening van de PID-aanbieder controleert tegen de vertrouwenslijsten, zonder tijdens de verificatie een overheidssysteem aan te roepen.

Overzicht van de verificatieflow

eIDAS-gebaseerde identiteitsverificatie volgt een zorgvuldig gechoreografeerde reeks stappen, ontworpen om beveiliging, privacy en gebruikerservaring in balans te brengen. Inzicht in deze flow is essentieel voor ontwikkelaars die identiteitsverificatie in hun applicaties integreren.

Het volledige verificatieproces betrekt vier hoofdrolspelers:

  1. Relying Party (uw applicatie): de dienst die om identiteitsverificatie vraagt
  2. eIDAS-serviceprovider: middleware die uw applicatie verbindt met het eIDAS-netwerk
  3. EUDI Wallet: de wallet-app van de gebruiker, geleverd binnen het stelsel van zijn lidstaat
  4. PID-aanbieder: de door de lidstaat aangewezen instantie die de persoonsidentificatiegegevens aan de wallet uitgeeft en waarvan de ondertekeningscertificaten via de vertrouwenslijsten worden gepubliceerd

Laten we elke stap van dit proces in detail doorlopen.

Stap 1: initialisatie van de verificatiesessie

Wanneer uw applicatie de identiteit van een gebruiker moet verifiëren, begint het proces met het aanmaken van een verificatiesessie.

Verzoek tot sessieaanmaak

Uw applicatie doet een API-aanroep naar uw eIDAS-serviceprovider:

POST /api/verification/create
{
  "verificationType": "AGE",
  "purpose": "Age verification for purchase",
  "returnUrl": "https://yourapp.com/verification/callback"
}

Het veld verificationType bepaalt op welke vraag u een antwoord nodig heeft. eIDAS Pro richt zich op booleaanse uitkomsten — u ontvangt true/false-antwoorden, geen persoonsgegevens:

Leeftijdsverificatie (AGE):

  • Uit een PID geeft de wallet alleen de geboortedatum vrij (de PID kent geen attribuut age_over_18); de verifiërende partij berekent "18 jaar of ouder?" en bewaart alleen het ja/nee
  • Uit een leeftijdsattestatie (eu.europa.ec.av.1) geeft de wallet age_over_18 rechtstreeks vrij, zonder enige geboortedatum

Landverificatie (COUNTRY):

  • Staat het woonland van de gebruiker op uw allow-list? (het woonland is een optioneel PID-attribuut, dus niet elke PID kan die vraag beantwoorden)

Waarom booleaanse uitkomsten?

Deze aanpak biedt maximale privacy met minimale AVG-aansprakelijkheid:

  • U verneemt alleen wat u moet weten (ja/nee)
  • Geen namen, geboortedata of adressen om op te slaan of te beveiligen
  • Geen verwerking van bijzondere categorieën persoonsgegevens
  • Drastisch verminderde aansprakelijkheid bij een datalek

Privacyopmerking: eIDAS Pro beperkt wat het teruggeeft bewust tot booleaanse antwoorden; de geboortedatum die het uit een PID leest, wordt nooit teruggegeven, opgeslagen of gelogd. Heeft u volledige identiteitsgegevens nodig (namen, adressen), dan zijn documentgebaseerde verificatieaanpakken nodig, met de bijbehorende AVG-verplichtingen en kosten. Veel organisaties gebruiken eIDAS voor EU-specifieke use cases met minimale data, en documentverificatie voor scenario's die volledige identiteitsgegevens vereisen.

Opmerking voor verwerkingsverantwoordelijken: hoewel eIDAS de gegevensverzameling minimaliseert, blijft uw organisatie verwerkingsverantwoordelijke voor elk verificatieresultaat dat u opslaat. Zie onze AVG-nalevingsgids voor details over uw resterende verplichtingen.

Sessieantwoord

De serviceprovider genereert een unieke verificatiesessie en retourneert:

{
  "sessionId": "vs_a8f2b3c1...",
  "qrCodeData": "eidas://verify?session=vs_a8f2b3c1...",
  "deepLink": "at.gv.eid://verify?session=vs_a8f2b3c1...",
  "expiresAt": "2026-01-22T15:30:00Z",
  "statusUrl": "https://api.provider.com/verification/vs_a8f2b3c1/status"
}

De sessie verloopt doorgaans na 5-10 minuten, om verlopen verificatieverzoeken te voorkomen.

Stap 2: QR-codegeneratie en -weergave

De QR-code vormt de brug tussen uw webapplicatie en het mobiele apparaat van de gebruiker.

Inhoud van de QR-code

De QR-code codeert diverse kritieke stukjes informatie:

  1. Protocolhandler: eidas:// of landspecifieke schema's zoals at.gv.eid://
  2. Sessie-identificatie: koppelt deze verificatie aan uw backend-sessie
  3. Endpoint van de serviceprovider: waarheen de wallet het verificatieverzoek moet sturen
  4. Aangevraagde attributen: welke informatie geverifieerd moet worden

Moderne standaarden: OpenID4VP

Moderne eIDAS-implementaties gebruiken OpenID for Verifiable Presentations (OpenID4VP), dat standaardiseert hoe verifieerbare credentials worden opgevraagd en gepresenteerd. De QR-code bevat:

openid4vp://?
  client_id=https://yourprovider.com
  &request_uri=https://yourprovider.com/request/vs_a8f2b3c1

De request_uri verwijst naar een ondertekende JWT met het volledige verificatieverzoek, wat integriteit garandeert en manipulatie voorkomt.

Best practices voor weergave

Responsief ontwerp: toon op mobiele apparaten een "tik om te openen"-knop in plaats van een QR-code, met deep links om de juiste wallet-app rechtstreeks te openen.

Laadstatussen: toon een scananimatie en duidelijke instructies ("Scan met uw nationale eID-app").

Terugvalopties: bied alternatieve verificatiemethoden voor gebruikers zonder eID-wallet.

Stap 3: authenticatie in de wallet-app

Zodra de gebruiker de QR-code scant, neemt zijn nationale eID-wallet-app het over.

Validatie van het verzoek

De wallet-app:

  1. Haalt het volledige verzoek op: haalt het ondertekende verzoek op via de request_uri
  2. Valideert handtekeningen: zorgt ervoor dat het verzoek afkomstig is van een legitieme serviceprovider
  3. Controleert de scope: verifieert dat de aangevraagde attributen passend en wettelijk toegestaan zijn
  4. Toont het toestemmingsscherm: laat de gebruiker precies zien welke informatie zal worden gedeeld

Gebruikersauthenticatie

Voordat informatie wordt vrijgegeven, vereist de wallet sterke authenticatie. De methoden variëren per land maar omvatten doorgaans:

Biometrische authenticatie (het meest voorkomend):

  • Vingerafdrukscan
  • Gezichtsherkenning
  • Irisscan

PIN/wachtwoord: een numerieke PIN of alfanumeriek wachtwoord

Hardwarebeveiliging: veel nationale eID-wallets gebruiken secure elements (SE) of trusted execution environments (TEE) op het apparaat, waardoor cryptografische sleutels de beveiligde enclave nooit verlaten.

Voorbeeld: wallet-flow

  1. De gebruiker opent zijn EUDI Wallet-app door de QR-code te scannen
  2. De app toont: "[Naam webshop] vraagt: geboortedatum (voor een leeftijdscontrole)"
  3. De gebruiker controleert en tikt op "Goedkeuren"
  4. Biometrische prompt: "Gebruik vingerafdruk ter bevestiging"
  5. De gebruiker authenticeert met vingerafdruk
  6. De app genereert en ondertekent de verificatierespons

De volledige in-app-flow duurt 3-5 seconden voor terugkerende gebruikers.

Stap 4: attribuutuitwisseling en -validatie

Na gebruikersauthenticatie stelt de wallet een cryptografisch ondertekende respons op met de aangevraagde attributen.

Structuur van de respons

De wallet genereert een Verifiable Presentation met SD-JWT VC (Selective Disclosure JWT Verifiable Credentials), het daadwerkelijke formaat dat de EU Digital Identity Wallet gebruikt:

// SD-JWT VC (PID, vct urn:eudi:pid:1) with selective disclosure - only revealing birthdate
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5laWRhcy5ldSIsImlhdCI6MTY0MzI4NDgwMCwiZXhwIjoxNjQzMjg4NDAwLCJ2Y3QiOiJ1cm46ZXVkaTpwaWQ6MSIsInN1YiI6ImRpZDpqd2s6ZXlKdUlqb2lSRk5CSWl3aWVTSTZJalkzTnpZeE1qRTJNeUo5IiwiX3NkIjpbIkc1RW5oT0FPb1U5WF84UUFBQUFBQUFBQUFBIiwiSjZVVnJPbkFBQUFBQUFBQUFBQUFBQUEiXSwiX3NkX2FsZyI6InNoYS0yNTYifQ.
kLJkC5RhcvkKU-VU8-U5Ng7Iq4r8KxP9I_gKU8U8U8U8U

// Disclosures array (only birthdate disclosed, other attributes hidden)
~WyJhQUFBQUFBQSIsImJpcnRoZGF0ZSIsIjE5OTAtMDUtMTQiXQ

// Key Binding JWT (proves holder controls the wallet)
eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.
eyJub25jZSI6IjEyMzQ1Njc4OTAiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmNvbSIsImlhdCI6MTY0MzI4NDgwMCwic2RfaGFzaCI6ImtoMlA1LVl0QmQzSnVIbVFQQUFBQUFBIn0.
signature_proving_holder_possession

Opmerking over selectieve openbaarmaking: het bovenstaande voorbeeld gebruikt SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), de huidige standaard voorgeschreven door de eIDAS 2.0-uitvoeringshandelingen. Hoewel Zero-Knowledge Proofs (ZKP) worden onderzocht voor toekomstige privacyverbeteringen, gebruikt de huidige EUDI Wallet-implementatie selectieve openbaarmaking via SD-JWT VC- en mdoc-formaten. Leeftijdsverificatie met een PID werkt door alleen de claim birthdate bloot te leggen, die de verifiërende partij terugbrengt tot een ja/nee; een attribuut age_over_18 heeft de PID niet. Een age_over_18 zonder geboortedatum bestaat alleen in de afzonderlijke leeftijdsattestatie (eu.europa.ec.av.1).

Kerncomponenten van SD-JWT VC:

  • Header + payload: bevat de uitgever, uitgiftedatum en selectief openbaar te maken claims (gehasht)
  • Disclosures: alleen de attributen die de gebruiker kiest bloot te geven (in dit geval birthdate)
  • Key binding: cryptografisch bewijs dat degene die de credential presenteert de wallet beheert

Privacyvoordeel: de verifiërende partij verneemt ALLEEN de geboortedatum, die zij één keer nodig heeft om de 18+-uitkomst te berekenen. Andere attributen zoals naam, adres en nationaliteit blijven cryptografisch verborgen, en eIDAS Pro brengt de datum terug tot een ja/nee voordat er iets wordt opgeslagen.

Cryptografische validatie

Uw serviceprovider valideert:

  1. Handtekeningverificatie: bevestigt dat de respons ondertekend is door de legitieme nationale identiteitsprovider
  2. Certificaatketen: valideert de volledige vertrouwensketen tot aan de nationale root-certificeringsinstantie
  3. Intrekkingsstatus: controleert of het ondertekeningscertificaat niet is ingetrokken
  4. Tijdstempelvalidatie: zorgt ervoor dat de respons vers is en niet is hergebruikt (replay)

Deze validatie gebeurt in milliseconden, met behulp van vooraf gecachte publieke sleutels en certificaatintrekkingslijsten.

Attribuutextractie

Na validatie worden de specifieke attributen geëxtraheerd en teruggegeven aan uw applicatie:

{
  "status": "success",
  "sessionId": "vs_a8f2b3c1...",
  "result": {
    "ageVerified": true  // derived from the birth date, which is not returned
  },
  "verifiedAt": "2026-01-22T12:00:05Z",
  "providerId": "AT",  // Austria
  "assuranceLevel": "high"  // eIDAS assurance level
}

Stap 5: real-time statusupdates

Terwijl de gebruiker zich authenticeert op zijn mobiele apparaat, moet uw webapplicatie weten wanneer het proces is voltooid.

Server-Sent Events (SSE)

De meest elegante oplossing is het gebruik van Server-Sent Events voor real-time updates:

const eventSource = new EventSource(
  `https://api.provider.com/verification/${sessionId}/stream`
);

eventSource.addEventListener('status', (event) => {
  const data = JSON.parse(event.data);

  if (data.status === 'scanned') {
    // User scanned QR code
    showMessage('Waiting for authentication...');
  } else if (data.status === 'completed') {
    // Verification successful
    redirectToSuccessPage();
  } else if (data.status === 'failed') {
    // Verification failed
    showError(data.reason);
  }
});

Alternatief: polling

Voor omgevingen die geen SSE ondersteunen, implementeert u polling met exponentiële backoff:

async function pollStatus(sessionId) {
  const maxAttempts = 60;  // 5 minutes
  let attempts = 0;

  while (attempts < maxAttempts) {
    const response = await fetch(
      `https://api.provider.com/verification/${sessionId}/status`
    );
    const data = await response.json();

    if (data.status !== 'pending') {
      return data;
    }

    // Exponential backoff: 1s, 2s, 4s, 8s, then 10s
    const delay = Math.min(1000 * Math.pow(2, attempts), 10000);
    await sleep(delay);
    attempts++;
  }

  throw new Error('Verification timeout');
}

Beveiligingsprotocollen en versleuteling

eIDAS-verificatie zet meerdere beveiligingslagen in om zich tegen uiteenlopende aanvalsvectoren te beschermen.

Transport Layer Security

Alle communicatie verloopt via TLS 1.3 met sterke cipher suites. Certificate pinning wordt aanbevolen voor mobiele applicaties om man-in-the-middle-aanvallen te voorkomen.

Ondertekening van verzoeken

Verificatieverzoeken worden ondertekend met JSON Web Signatures (JWS), met:

  • Algoritme: ES256 (ECDSA met P-256 en SHA-256)
  • Sleutelopslag: Hardware Security Modules (HSM's) voor sleutels van de serviceprovider
  • Rotatie: regelmatige sleutelrotatie met overlappende geldigheidsperiodes

Validatie van responses

Responses worden gevalideerd via:

  1. Digitale handtekeningen: elke respons is digitaal ondertekend door de nationale identiteitsprovider
  2. Tijdstempelcontroles: responses moeten binnen een kort tijdvenster worden gebruikt (doorgaans 60 seconden)
  3. Nonce-verificatie: elk verzoek bevat een cryptografische nonce die in de respons moet worden teruggegeven
  4. Sessiebinding: responses zijn gebonden aan specifieke sessies en kunnen niet worden hergebruikt

Privacybeschermende technieken

Selectieve openbaarmaking: gebruikers kunnen kiezen welke attributen ze delen, zelfs als er meer werden opgevraagd.

Zero-Knowledge Proofs: bewijs eigenschappen over data zonder de data zelf bloot te leggen. Bewijs bijvoorbeeld dat u ouder bent dan 18 zonder uw geboortedatum prijs te geven. In de Europese specificatie voor leeftijdsverificatie geldt dat voor de afzonderlijke leeftijdsattestatie, en alleen via de W3C Digital Credentials API, niet via OpenID4VP; een PID-presentatie geeft de geboortedatum nog steeds vrij.

Attribuutversleuteling: tijdens transport worden attributen versleuteld met sessiespecifieke sleutels, zodat zelfs de infrastructuur van de serviceprovider er geen toegang toe heeft totdat ze bij uw applicatie zijn afgeleverd.

Integratiepatronen

Verschillende applicatiearchitecturen vragen om verschillende integratiebenaderingen.

Patroon 1: backend-naar-backend (server-side)

Het beste voor server-gerenderde applicaties of native mobiele apps:

// 1. Create session on your backend
POST /api/verification/create
→ { sessionId, qrCodeData }

// 2. Display QR code to user
// 3. Poll or stream status on backend
GET /api/verification/:sessionId/status

// 4. Once complete, retrieve the result
GET /api/verification/:sessionId/result
→ { result: { ageVerified: true } }

Voordelen: volledige controle, betere beveiliging, attributen komen nooit in de frontend terecht.

Patroon 2: JavaScript-widget (client-side)

Het beste voor SPA's en snelle integraties:

import { init } from '@eidas-pro/widget';

await init({
  containerId: 'age-check',
  baseUrl: 'https://yourapp.com/eidas', // your proxy keeps the API key server-side
  verificationType: 'age',
  onVerified: (verified, { sessionId }) => {
    console.log('Age check passed:', verified, sessionId);
  },
  onError: (error) => {
    console.error('Verification failed:', error);
  }
});

Voordelen: snelle integratie, handelt de UI automatisch af, responsief ontwerp.

Patroon 3: e-commerceplugin

Kant-en-klare plugins voor platforms zoals WooCommerce en Shopify handelen de volledige flow af:

  • Voegt een verificatiecontrolepunt toe aan de checkout
  • Slaat de verificatiestatus op bij de bestelling
  • Biedt een admin-dashboard voor compliancerapportage
  • Handelt randgevallen en fouten automatisch af

Foutafhandeling en randgevallen

Robuuste implementaties moeten diverse faalscenario's kunnen afhandelen.

Veelvoorkomende foutscenario's

Timeout: gebruiker scant de QR-code niet binnen het verloopvenster

  • Oplossing: toon een nieuwe QR-code, verleng de sessie als de gebruiker nog aanwezig is

Annulering door gebruiker: gebruiker weigert attributen te delen

  • Oplossing: bied alternatieve verificatiemethoden of een uitleg waarom verificatie nodig is

Netwerkfouten: verbindingsproblemen tijdens verificatie

  • Oplossing: implementeer retries met exponentiële backoff, behoud de sessiestatus

Niet-ondersteunde attributen: aangevraagd attribuut is niet beschikbaar voor het eID-schema van de gebruiker

  • Oplossing: gracieus degraderen of alternatieve attributen aanvragen

Mismatch in betrouwbaarheidsniveau: de eID van de gebruiker voldoet niet aan het vereiste betrouwbaarheidsniveau

  • Oplossing: vraag een extra authenticatiefactor of wijs de verificatie af met een duidelijke uitleg

Logging en monitoring

Implementeer uitgebreide logging voor:

  • Details van verificatieverzoeken (zonder PII)
  • Succes-/faalpercentages per land
  • Gemiddelde verificatieduur
  • Foutsoorten en -frequenties

Deze gegevens zijn essentieel om conversiepercentages te optimaliseren en technische problemen te identificeren.

Prestatie-optimalisatie

Cachestrategieën

Caching van publieke sleutels: cache de publieke sleutels van nationale identiteitsproviders met een passende TTL (doorgaans 24 uur) om herhaalde ophaalacties te vermijden.

Validatie van certificaatketens: haal certificaatketens vooraf op en valideer ze tijdens periodes met weinig verkeer.

Caching van vertrouwenslijsten: cache de vertrouwenslijsten en ververs ze volgens een schema. Het verifiëren van een presentatie vereist geen aanroep naar de PID-aanbieder, dus de validatielatentie blijft lokaal.

Responstijddoelen

  • Sessieaanmaak: < 200 ms
  • QR-codegeneratie: < 50 ms
  • Attribuutvalidatie: < 500 ms
  • End-to-end gebruikersflow: 5-10 seconden (voornamelijk tijd voor gebruikersauthenticatie)

Conclusie

eIDAS-verificatie is gebouwd op robuuste cryptografische fundamenten, gestandaardiseerde protocollen en privacybeschermende architecturen. Door de technische flow te begrijpen — van sessie-initialisatie tot attribuutvalidatie — kunnen ontwikkelaars integraties bouwen die zowel veilig als gebruiksvriendelijk zijn.

De combinatie van OpenID4VP, verifieerbare credentials en gedecentraliseerde identiteit creëert een systeem dat schaalt over heel Europa, terwijl het de privacy van gebruikers beschermt en juridisch geldig blijft.

Richt u bij de implementatie van eIDAS-verificatie op foutafhandeling, prestatie-optimalisatie en duidelijke gebruikerscommunicatie. De technische complexiteit wordt afgehandeld door de onderliggende protocollen; uw taak is een ervaring te creëren die naadloos en betrouwbaar aanvoelt.


Technische ondersteuning nodig voor uw integratie? Ons engineeringteam staat klaar om te helpen met architectuurreviews, implementatievragen en prestatie-optimalisatie. Neem contact op →

Gerelateerde artikelen

Dit artikel delen

Help anderen meer te weten komen over eIDAS-verificatie