Wie die eIDAS-Verifizierung funktioniert: eine technische Tiefenanalyse

Korrigiert am 20. Oktober 2026: In einer früheren Fassung hieß es, die PID der EUDI-Wallet könne ein Attribut age_over_18 offenlegen. Das ist nicht der Fall – die PID enthält kein Altersattribut; die prüfende Stelle fordert allein das Geburtsdatum an und leitet das Ja/Nein selbst ab. age_over_18 gibt es nur im separaten Altersnachweis (Proof-of-Age-Attestation, eu.europa.ec.av.1). Außerdem stellen wir ID Austria, Smart-ID und BankID nicht mehr als EUDI-Wallets dar (es sind bestehende nationale eID-Apps) und haben klargestellt, dass die prüfende Stelle die Signatur des PID-Anbieters gegen die Vertrauenslisten prüft, statt während der Verifikation ein staatliches System abzufragen.

Überblick über den Verifizierungsablauf

eIDAS-basierte Identitätsverifizierung folgt einer präzise orchestrierten Abfolge, die Sicherheit, Datenschutz und Nutzererlebnis in Balance bringt. Dieses Ablaufverständnis ist entscheidend für Entwickler, die Identitätsverifizierung in ihre Anwendungen integrieren.

Der vollständige Verifizierungsprozess umfasst vier Hauptakteure:

Relying Party (Ihre Anwendung): Der Dienst, der die Identitätsverifizierung anfordert
eIDAS-Dienstanbieter: Vermittlungsschicht, die Ihre Anwendung mit dem eIDAS-Netzwerk verbindet
EUDI-Wallet: Die Wallet-App des Nutzers, bereitgestellt im Rahmen des Systems seines Mitgliedstaats
PID-Anbieter: Die vom Mitgliedstaat benannte Stelle, die die Personenidentifizierungsdaten an die Wallet ausgibt und deren Signaturzertifikate über die Vertrauenslisten veröffentlicht werden

Gehen wir jeden Schritt dieses Prozesses im Detail durch.

Schritt 1: Initialisierung der Verifizierungssitzung

Wenn Ihre Anwendung die Identität eines Nutzers verifizieren muss, beginnt der Prozess mit der Erstellung einer Verifizierungssitzung.

Anfrage zur Sitzungserstellung

Ihre Anwendung sendet einen API-Aufruf an Ihren eIDAS-Dienstanbieter:

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

Das Feld verificationType legt fest, welche Frage beantwortet werden soll. eIDAS Pro fokussiert sich auf boolesche Ergebnisse – Sie erhalten true/false-Antworten statt personenbezogener Daten:

Altersverifizierung (AGE):

Aus einer PID legt die Wallet ausschließlich das Geburtsdatum offen (die PID kennt kein Attribut age_over_18); die prüfende Stelle berechnet „18 oder älter?“ und behält nur das Ja/Nein
Aus einem Altersnachweis (eu.europa.ec.av.1) legt die Wallet age_over_18 direkt offen – ganz ohne Geburtsdatum

Länderverifizierung (COUNTRY):

Liegt das Wohnsitzland des Nutzers auf Ihrer Allow-List? (Das Wohnsitzland ist in der PID optional, nicht jede PID kann die Frage also beantworten.)

Warum boolesche Ergebnisse?

Dieser Ansatz bietet maximalen Datenschutz bei minimalem DSGVO-Haftungsrisiko:

Sie erfahren nur, was Sie wissen müssen (Ja/Nein)
Keine Namen, Geburtsdaten oder Adressen, die gespeichert oder abgesichert werden müssen
Keine Verarbeitung besonderer Kategorien personenbezogener Daten
Deutlich reduziertes Risiko im Fall eines Datenvorfalls

Datenschutzhinweis: eIDAS Pro beschränkt seine Rückgaben bewusst auf boolesche Antworten; das aus einer PID gelesene Geburtsdatum wird weder zurückgegeben noch gespeichert oder protokolliert. Wenn Sie vollständige Identitätsdaten (Namen, Adressen) benötigen, sind dokumentbasierte Verifizierungsansätze erforderlich – mit den entsprechenden DSGVO-Pflichten und Kosten. Viele Organisationen nutzen eIDAS für EU-spezifische Minimaldaten-Anwendungsfälle und dokumentbasierte Verifizierung für Szenarien, die vollständige Identitätsdaten erfordern.

Hinweis für Verantwortliche: Auch wenn eIDAS die Datenerhebung minimiert, bleibt Ihre Organisation Verantwortlicher für alle gespeicherten Verifizierungsergebnisse. Details zu den verbleibenden Pflichten finden Sie in unserem Leitfaden zur DSGVO-Compliance.

Sitzungsantwort

Der Dienstanbieter erzeugt eine eindeutige Verifizierungssitzung und gibt Folgendes zurück:

{
  "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"
}

Die Sitzung läuft typischerweise nach 5-10 Minuten ab, um veraltete Verifizierungsanfragen zu verhindern.

Schritt 2: Erzeugung und Anzeige des QR-Codes

Der QR-Code bildet die Brücke zwischen Ihrer Webanwendung und dem mobilen Gerät des Nutzers.

Inhalte des QR-Codes

Der QR-Code kodiert mehrere kritische Informationen:

Protokoll-Handler: eidas:// oder länderspezifische Schemes wie at.gv.eid://
Sitzungskennung: Verknüpft diese Verifizierung mit Ihrer Backend-Sitzung
Endpunkt des Dienstanbieters: Wohin die Wallet die Verifizierungsanfrage senden soll
Angeforderte Attribute: Welche Informationen verifiziert werden müssen

Moderne Standards: OpenID4VP

Moderne eIDAS-Implementierungen verwenden OpenID for Verifiable Presentations (OpenID4VP). Dieser Standard definiert, wie verifizierbare Nachweise angefordert und präsentiert werden. Der QR-Code enthält:

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

Die request_uri verweist auf ein signiertes JWT mit der vollständigen Verifizierungsanfrage. Das stellt Integrität sicher und verhindert Manipulation.

Empfehlungen für die Anzeige

Responsives Design: Auf Mobilgeräten statt QR-Code einen „Tippen zum Öffnen“-Button anzeigen und Direktlinks (Deep Links) nutzen, um die passende Wallet-App direkt zu starten.

Ladezustände: Eine Scan-Animation und klare Hinweise anzeigen („Mit Ihrer nationalen eID-App scannen“).

Alternativoptionen: Alternative Verifizierungsmethoden für Nutzer ohne eID-Wallet anbieten.

Schritt 3: Authentifizierung in der Wallet-App

Sobald der Nutzer den QR-Code scannt, übernimmt die nationale eID-Wallet-App.

Validierung der Anfrage

Die Wallet-App:

Lädt die vollständige Anfrage: Ruft die signierte Anfrage über die request_uri ab
Prüft Signaturen: Stellt sicher, dass die Anfrage von einem legitimen Dienstanbieter stammt
Prüft den Umfang: Verifiziert, dass die angeforderten Attribute angemessen und rechtlich zulässig sind
Zeigt den Einwilligungsbildschirm: Zeigt dem Nutzer exakt, welche Informationen geteilt werden

Nutzerauthentifizierung

Bevor Informationen freigegeben werden, verlangt die Wallet eine starke Authentifizierung. Die Methoden variieren je nach Land, umfassen typischerweise jedoch:

Biometrische Authentifizierung (am häufigsten):

Fingerabdruckscan
Gesichtserkennung
Iris-Scan

PIN/Passwort: Eine numerische PIN oder ein alphanumerisches Passwort

Hardware-Sicherheit: Viele nationale eID-Wallets nutzen Secure Elements (SE) oder Trusted Execution Environments (TEE) auf dem Gerät. Dadurch verlassen kryptografische Schlüssel niemals die sichere Ausführungsumgebung.

Beispiel: Wallet-Ablauf

Nutzer öffnet seine EUDI-Wallet-App durch Scannen des QR-Codes
Die App zeigt an: „eidas-pro.com fordert an: Geburtsdatum (für eine Altersprüfung)“
Nutzer prüft die Anfrage und tippt auf „Zustimmen“
Biometrie-Prompt: „Fingerabdruck zur Bestätigung verwenden“
Nutzer authentifiziert sich per Fingerabdruck
Die App erzeugt und signiert die Verifizierungsantwort

Der gesamte In-App-Ablauf dauert für wiederkehrende Nutzer 3-5 Sekunden.

Schritt 4: Attributaustausch und Validierung

Nach der Nutzerauthentifizierung erstellt die Wallet eine kryptografisch signierte Antwort mit den angeforderten Attributen.

Antwortstruktur

Die Wallet erzeugt eine verifizierbare Präsentation mit SD-JWT VC (Selective Disclosure JWT Verifiable Credentials), dem tatsächlich in der EU Digital Identity Wallet verwendeten Format:

// SD-JWT VC (PID, vct urn:eudi:pid:1) mit selektiver Offenlegung - es wird nur birthdate offengelegt
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5laWRhcy5ldSIsImlhdCI6MTY0MzI4NDgwMCwiZXhwIjoxNjQzMjg4NDAwLCJ2Y3QiOiJ1cm46ZXVkaTpwaWQ6MSIsInN1YiI6ImRpZDpqd2s6ZXlKdUlqb2lSRk5CSWl3aWVTSTZJalkzTnpZeE1qRTJNeUo5IiwiX3NkIjpbIkc1RW5oT0FPb1U5WF84UUFBQUFBQUFBQUFBIiwiSjZVVnJPbkFBQUFBQUFBQUFBQUFBQUEiXSwiX3NkX2FsZyI6InNoYS0yNTYifQ.
kLJkC5RhcvkKU-VU8-U5Ng7Iq4r8KxP9I_gKU8U8U8U8U

// Disclosures-Array (nur birthdate wird offengelegt, andere Attribute bleiben verborgen)
~WyJhQUFBQUFBQSIsImJpcnRoZGF0ZSIsIjE5OTAtMDUtMTQiXQ

// Key-Binding-JWT (belegt, dass der Inhaber die Wallet kontrolliert)
eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.
eyJub25jZSI6IjEyMzQ1Njc4OTAiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmNvbSIsImlhdCI6MTY0MzI4NDgwMCwic2RfaGFzaCI6ImtoMlA1LVl0QmQzSnVIbVFQQUFBQUFBIn0.
signature_proving_holder_possession

Hinweis zur selektiven Offenlegung: Das obige Beispiel nutzt SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), den aktuellen Standard aus den eIDAS-2.0-Durchführungsrechtsakten. Zero-Knowledge-Proofs (ZKP) werden für zukünftige Datenschutzverbesserungen erforscht; die aktuelle EUDI-Wallet-Implementierung verwendet jedoch selektive Offenlegung über SD-JWT VC- und mdoc-Formate. Altersverifizierung mit einer PID funktioniert durch Offenlegung ausschließlich der Aussage birthdate, die die prüfende Stelle auf ein Ja/Nein reduziert; ein Attribut age_over_18 hat die PID nicht. Ein age_over_18 ganz ohne Geburtsdatum gibt es nur im separaten Altersnachweis (eu.europa.ec.av.1).

Zentrale Komponenten von SD-JWT VC:

Header + Payload: Enthalten Aussteller, Ausstellungszeitpunkt und selektiv offenlegbare Aussagen (gehasht)
Disclosures: Nur die Attribute, die der Nutzer freigibt (in diesem Fall birthdate)
Key Binding: Kryptografischer Nachweis, dass die präsentierende Person die Wallet kontrolliert

Datenschutzvorteil: Die prüfende Stelle erfährt NUR das Geburtsdatum, das sie einmalig zur Berechnung des 18+-Ergebnisses braucht. Andere Attribute wie Name, Adresse und Staatsangehörigkeit bleiben kryptografisch verborgen, und eIDAS Pro reduziert das Datum auf ein Ja/Nein, bevor irgendetwas gespeichert wird.

Kryptografische Validierung

Ihr Dienstanbieter validiert:

Signaturprüfung: Bestätigt, dass die Antwort vom legitimen nationalen Identitätsanbieter signiert wurde
Zertifikatskette: Validiert die vollständige Vertrauenskette bis zur nationalen Stammzertifizierungsstelle
Sperrstatus: Prüft, ob das Signaturzertifikat widerrufen wurde
Zeitstempelvalidierung: Stellt sicher, dass die Antwort aktuell ist und nicht durch einen Replay-Angriff wiederverwendet wurde

Diese Validierung erfolgt in Millisekunden mit vorgecachten öffentlichen Schlüsseln und Zertifikatswiderrufslisten.

Attributextraktion

Nach erfolgreicher Validierung werden die relevanten Attribute extrahiert und an Ihre Anwendung zurückgegeben:

{
  "status": "success",
  "sessionId": "vs_a8f2b3c1...",
  "result": {
    "ageVerified": true  // aus dem Geburtsdatum abgeleitet, das nicht zurückgegeben wird
  },
  "verifiedAt": "2026-01-22T12:00:05Z",
  "providerId": "AT",  // Österreich
  "assuranceLevel": "high"  // eIDAS-Vertrauensniveau
}

Schritt 5: Echtzeit-Statusupdates

Während der Nutzer sich auf seinem Mobilgerät authentifiziert, muss Ihre Webanwendung wissen, wann der Prozess abgeschlossen ist.

Server-Sent Events (SSE)

Die eleganteste Lösung sind Server-Sent Events für Echtzeit-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') {
    // Nutzer hat den QR-Code gescannt
    showMessage('Warten auf Authentifizierung...');
  } else if (data.status === 'completed') {
    // Verifizierung erfolgreich
    redirectToSuccessPage();
  } else if (data.status === 'failed') {
    // Verifizierung fehlgeschlagen
    showError(data.reason);
  }
});

Polling als Alternative

Für Umgebungen ohne SSE-Unterstützung sollte Polling mit exponentiellem Backoff implementiert werden:

async function pollStatus(sessionId) {
  const maxAttempts = 60;  // 5 Minuten
  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;
    }

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

  throw new Error('Zeitüberschreitung bei der Verifizierung');
}

Sicherheitsprotokolle und Verschlüsselung

eIDAS-Verifizierung nutzt mehrere Sicherheitsebenen, um unterschiedliche Angriffsvektoren abzuwehren.

Transport Layer Security

Alle Kommunikationskanäle verwenden TLS 1.3 mit starken Cipher Suites. Für mobile Anwendungen wird Certificate Pinning empfohlen, um Man-in-the-Middle-Angriffe zu verhindern.

Signierung von Anfragen

Verifizierungsanfragen werden mit JSON Web Signatures (JWS) signiert:

Algorithmus: ES256 (ECDSA mit P-256 und SHA-256)
Schlüsselspeicherung: Hardware Security Modules (HSMs) für Dienstanbieter-Schlüssel
Rotation: Regelmäßige Schlüsselrotation mit überlappenden Gültigkeitszeiträumen

Validierung von Antworten

Antworten werden über folgende Mechanismen geprüft:

Digitale Signaturen: Jede Antwort ist vom nationalen Identitätsanbieter digital signiert
Zeitstempelprüfung: Antworten dürfen nur innerhalb eines kurzen Zeitfensters genutzt werden (typischerweise 60 Sekunden)
Nonce-Verifizierung: Jede Anfrage enthält eine kryptografische Nonce, die in der Antwort enthalten sein muss
Session-Bindung: Antworten sind an spezifische Sitzungen gebunden und können nicht wiederverwendet werden

Datenschutzfreundliche Techniken

Selektive Offenlegung: Nutzer können wählen, welche Attribute sie teilen, selbst wenn mehr angefordert wurden.

Zero-Knowledge-Proofs (ZKP): Eigenschaften von Daten nachweisen, ohne die Daten selbst offenzulegen. Beispiel: nachweisen, dass man über 18 ist, ohne das Geburtsdatum preiszugeben. In der EU-Spezifikation zur Altersverifizierung gilt das für den separaten Altersnachweis und nur über die W3C Digital Credentials API, nicht über OpenID4VP; eine PID-Präsentation legt das Geburtsdatum weiterhin offen.

Attributverschlüsselung: Während der Übertragung sind Attribute mit sitzungsspezifischen Schlüsseln verschlüsselt. Dadurch kann selbst die Infrastruktur des Dienstanbieters erst dann zugreifen, wenn die Daten an Ihre Anwendung ausgeliefert werden.

Integrationsmuster

Unterschiedliche Anwendungsarchitekturen erfordern unterschiedliche Integrationsansätze.

Muster 1: Backend-zu-Backend (serverseitig)

Optimal für serverseitig gerenderte Anwendungen oder native mobile Apps:

// 1. Sitzung im eigenen Backend erstellen
POST /api/verification/create
→ { sessionId, qrCodeData }

// 2. QR-Code für Nutzer anzeigen
// 3. Status im Backend pollen oder streamen
GET /api/verification/:sessionId/status

// 4. Nach Abschluss das Ergebnis abrufen
GET /api/verification/:sessionId/result
→ { result: { ageVerified: true } }

Vorteile: Volle Kontrolle, höhere Sicherheit, Attribute berühren nie das Frontend.

Optimal für SPAs und schnelle Integrationen:

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

await init({
  containerId: 'age-check',
  baseUrl: 'https://yourapp.com/eidas', // Ihr Proxy hält den API-Schlüssel serverseitig
  verificationType: 'age',
  onVerified: (verified, { sessionId }) => {
    console.log('Age check passed:', verified, sessionId);
  },
  onError: (error) => {
    console.error('Verification failed:', error);
  }
});

Vorteile: Schnelle Integration, die Benutzeroberfläche wird automatisch gehandhabt, responsives Design.

Muster 3: E-Commerce-Plugin

Vorgefertigte Plugins für Plattformen wie WooCommerce und Shopify übernehmen den gesamten Ablauf:

Fügt im Bezahlvorgang einen Verifizierungsschritt hinzu
Speichert den Verifizierungsstatus zur Bestellung
Bietet ein Admin-Dashboard für Compliance-Berichte
Behandelt Sonderfälle und Fehler automatisch

Fehlerbehandlung und Sonderfälle

Robuste Implementierungen müssen unterschiedliche Fehlerszenarien beherrschen.

Häufige Fehlerszenarien

Timeout: Nutzer scannt den QR-Code nicht innerhalb des Ablaufzeitfensters

Lösung: Neuen QR-Code anzeigen, Sitzung verlängern, sofern der Nutzer noch aktiv ist

Abbruch durch den Nutzer: Nutzer lehnt die Freigabe von Attributen ab

Lösung: Alternative Verifizierungsmethoden anbieten oder erklären, warum die Verifizierung erforderlich ist

Netzwerkfehler: Verbindungsprobleme während der Verifizierung

Lösung: Wiederholungsversuche mit exponentiellem Backoff implementieren, Sitzungsstatus erhalten

Nicht unterstützte Attribute: Angefordertes Attribut ist im eID-Schema des Nutzers nicht verfügbar

Lösung: Kontrollierte Funktionseinschränkung umsetzen oder alternative Attribute anfordern

Abweichung beim Vertrauensniveau: Die eID des Nutzers erfüllt nicht das erforderliche Vertrauensniveau

Lösung: Zusätzlichen Authentifizierungsfaktor anfordern oder die Verifizierung mit klarer Begründung ablehnen

Protokollierung und Überwachung

Implementieren Sie umfassendes Logging für:

Details zu Verifizierungsanfragen (ohne personenbezogene Daten)
Erfolgs-/Fehlerraten nach Land
Durchschnittliche Verifizierungsdauer
Fehlertypen und deren Häufigkeit

Diese Daten sind entscheidend, um Konversionsraten zu optimieren und technische Probleme frühzeitig zu identifizieren.

Performance-Optimierung

Cache-Strategien

Caching öffentlicher Schlüssel: Öffentliche Schlüssel nationaler Identitätsanbieter mit passender TTL (typischerweise 24 Stunden) im Cache halten, um wiederholte Abrufe zu vermeiden.

Validierung der Zertifikatskette: Zertifikatsketten in Zeiten niedriger Last vorab abrufen und validieren.

Caching der Vertrauenslisten: Vertrauenslisten zwischenspeichern und planmäßig aktualisieren. Die Prüfung einer Präsentation erfordert keinen Aufruf beim PID-Anbieter, die Validierungslatenz bleibt also lokal.

Zielwerte für Antwortzeiten

Sitzungserstellung: < 200 ms
QR-Code-Erzeugung: < 50 ms
Attributvalidierung: < 500 ms
End-to-End-Nutzerfluss: 5-10 Sekunden (hauptsächlich Zeit für Nutzerauthentifizierung)

Fazit

eIDAS-Verifizierung basiert auf robusten kryptografischen Grundlagen, standardisierten Protokollen und datenschutzfreundlichen Architekturen. Wer den technischen Ablauf versteht – von der Sitzungsinitialisierung bis zur Attributvalidierung –, kann Integrationen bauen, die sowohl sicher als auch benutzerfreundlich sind.

Die Kombination aus OpenID4VP, verifizierbaren Nachweisen und dezentraler Identität schafft ein System, das in ganz Europa skaliert, die Privatsphäre der Nutzer schützt und gleichzeitig rechtlich belastbar bleibt.

Wenn Sie eIDAS-Verifizierung implementieren, sollten Sie den Fokus auf Fehlerbehandlung, Performance-Optimierung und klare Nutzerkommunikation legen. Die technische Komplexität wird durch die zugrunde liegenden Protokolle getragen; Ihre Aufgabe ist es, ein Erlebnis zu schaffen, das sich nahtlos und vertrauenswürdig anfühlt.

Brauchen Sie technischen Support für Ihre Integration? Unser Technikteam unterstützt Sie bei Architektur-Reviews, Implementierungsfragen und Performance-Optimierung. Kontakt aufnehmen →