eIDAS 2.0 und die EUDI-Wallet

Einordnung — eine Verordnung mit Stichtag

Die ursprüngliche eIDAS-Verordnung von 2014 schuf in der EU einen gemeinsamen Rahmen für Vertrauensdienste — qualifizierte Signaturen, Siegel, Zeitstempel, die Notifizierung nationaler eID-Systeme. Sie war ein technisch sauberes, aber im Privatsektor wenig sichtbares Werk: Banken, Telekommunikations- und Energieanbieter haben die notifizierten eIDs der Mitgliedstaaten in der Breite ignoriert, der Personalausweis mit Online-Funktion ist in Deutschland zwölf Jahre nach seiner Einführung nicht im Massenmarkt angekommen. eIDAS 2.0 — formal die Verordnung (EU) 2024/1183 vom 11. April 2024 — adressiert diese Lücke an zwei Stellen: sie verpflichtet jeden Mitgliedstaat, eine EUDI-Wallet (European Digital Identity Wallet) bereitzustellen, und sie verpflichtet einen klar definierten Kreis von Verifiern, diese Wallet zu akzeptieren.

Der zentrale Stichtag steht im Raum: 20. November 2026. Bis dahin muss jeder Mitgliedstaat mindestens eine zertifizierte Wallet im Markt haben. Die zugehörigen Durchführungsrechtsakte (vor allem die Commission Implementing Regulation 2024/2982 zu Protokollen, Schnittstellen und Zertifizierung) wurden Ende 2024 erlassen; mehrere CIRs zu Vertrauensdiensten und grenzüberschreitendem Identity-Matching folgten 2025. Realistisch wird der Termin nicht in allen 27 Mitgliedstaaten gleichzeitig gehalten — Italien und Spanien sind erkennbar früher dran, Deutschland und Frankreich verhandeln eher eine Karenzphase. Für die Architektur eines Fachverfahrens, das zwei oder drei Jahre durchhalten soll, ist das aber zweitrangig: bis Ende 2027 wird die Wallet in jedem realistischen Szenario in Deutschland produktiv sein.

Wirtschaftlich relevant ist die Liste der akzeptanzpflichtigen Verifier. Artikel 5f benennt sie ausdrücklich: die öffentliche Verwaltung, Banken und andere nach 6AMLD geldwäscherechtlich verpflichtete Stellen, Telekommunikationsanbieter, Energie- und Versorgungsdienstleister, der Verkehrssektor, Bildungseinrichtungen, das Gesundheitswesen, Postdienste und die sehr großen Online-Plattformen im Sinne des Digital Services Act (VLOPs — Amazon, App Stores, soziale Netzwerke). Wer in dieser Liste auftaucht, kann die Wallet 2027 nicht mehr ignorieren; wer einen Kunden in einer dieser Branchen berät, muss die Anbindung als Wallet-Verifier auf der Roadmap haben. Der häufig vorgebrachte Einwand „das setzen wir später um, wenn sich die Wallet im Markt etabliert hat" verfehlt den Punkt — die Akzeptanzpflicht greift kraft Gesetz, nicht aufgrund von Marktdurchdringung.

Eine zweite Neuerung ist die Einführung der Electronic Attestation of Attributes als eigenständige Vertrauensdienstkategorie. eIDAS 1 kannte qualifizierte Signaturen und Siegel; eIDAS 2 ergänzt drei Sub-Klassen attributbasierter Bescheinigungen: die Personal Identification Data (PID, die staatlich verifizierte Grundidentität), die Qualified Electronic Attestation of Attributes (QEAA, durch einen qualifizierten Vertrauensdienst ausgestellt) und die Public-Sector EAA (PuB-EAA, von einer Behörde ausgestellt). Damit wird das Konzept des qualifizierten Vertrauensdienstes von Signaturen auf die Ausstellung von Fakten erweitert — eine Hochschule, die ein Diplom in die Wallet einstellt, ist nun ein potenzieller QEAA-Provider mit der gleichen rechtlichen Bindungswirkung wie ein qualifizierter Zertifikatsdienst.

Zwei Aspekte sind politisch eingearbeitet und technisch nicht trivial. Erstens schreibt die Verordnung Wallet-Komponenten als Open Source fest, soweit Sicherheitsgründe dem nicht entgegenstehen — die EU-Referenzimplementierungen auf GitHub unter eu-digital-identity-wallet sind nicht eine freundliche Geste der Kommission, sondern eine Verpflichtung aus dem Verordnungstext. Zweitens fordert Artikel 5a Absatz 16 ausdrücklich, dass die Wallet Zero-Knowledge-Proofs und Mindestoffenlegung technisch unterstützt. Was das in der Praxis bedeutet — und warum es 2026 nur teilweise einlösbar ist — wird im Abschnitt zu den Credential-Formaten konkreter.

Trust-Triangle — Holder, Issuer, Verifier

Die EUDI-Wallet baut auf einem altbekannten Architekturmuster auf: drei Rollen, drei kryptographische Bindungen, ein Trust-Anchor pro Mitgliedstaat.

Der Holder ist die natürliche Person und die in ihrem Auftrag betriebene Wallet-Instanz, in den meisten Fällen eine App auf dem Smartphone des Bürgers. Sie verwaltet Credentials und das zugehörige Schlüsselmaterial — letzteres liegt nicht im normalen App-Speicher, sondern in einem Wallet Secure Cryptographic Device (WSCD), in der Praxis dem Secure Element des Smartphones, der eSIM oder einer externen Smartcard. Die normgerechte Implementierung trennt zwischen einer software­seitigen Wallet Secure Cryptographic Application (WSCA) und dem darunterliegenden WSCD; für die Praxis genügt zu wissen, dass der private Schlüssel das Hardware-Element nie verlässt.

Der Issuer stellt Credentials aus. Die Verordnung kennt drei Sub-Klassen: PID Provider (in Deutschland aller Voraussicht nach die Bundesdruckerei, der Anker ist die eID-Funktion des Personalausweises), QEAA Provider (qualifizierte Vertrauensdienste mit Aufsicht durch die BNetzA) und Non-Qualified EAA Provider (jeder, der ein Attribut bestätigen will — eine Hochschule für ein Diplom, ein Arbeitgeber für eine Beschäftigungsbescheinigung, ein Energieversorger für einen Vertragsanker). Die qualifizierte Variante hat höhere Anforderungen an Identifizierung des Antragstellers, Betriebssicherheit und Aufsichts­meldungen, dafür mehr rechtliche Bindungswirkung.

Der Verifier — die Relying Party — ist die anfragende Stelle, etwa die Bank in einem Kontoeröffnungsprozess oder das Polizeigerät in einer Mobile-Driving-Licence-Kontrolle. Anders als in eIDAS 1, wo jeder beliebig eIDs konsumieren konnte, ist hier eine Verifier-Registrierung verpflichtend: jeder Verifier wird vor seiner Tätigkeit in einer nationalen Relying Party Registry eingetragen, mit Angabe der Zwecke und der konkreten Attribute, die er abfragen darf. Die Wallet konsultiert diese Registry beim Authorization Request und lehnt Anfragen ab, die jenseits der Registrierung liegen. Das ist die zentrale Schutzschicht gegen den Über-Abfrage-Anreiz, der jedes Verifier-System ohne Begrenzung der nachgefragten Attribute trifft.

Der Trust-Anchor ist die EU List of Trusted Lists (LOTL), die eIDAS 1 schon kennt und die für eIDAS 2 um vier neue Listen erweitert wird: Wallet Provider, PID Provider, QEAA/PuB-EAA Provider und die Relying-Party-Registries. Jedes Mitgliedsland publiziert seine Liste signiert; die LOTL aggregiert sie. Eine Wallet, die in Spanien notifiziert ist, lässt sich in Deutschland prüfen, weil ihr Issuer-Zertifikat in der spanischen Wallet-Provider-Liste steht — die Wallet-Software auf dem Smartphone trägt zusätzlich ein Wallet Trust Mark, das gegenüber dem Verifier die Authentizität der Wallet-Instanz selbst belegt.

Credential-Formate — SD-JWT VC und mDoc

Die Architecture Reference Framework schreibt zwei Formate verbindlich vor, die jede Wallet und jeder Verifier parallel unterstützen müssen. Wer eine Verifier-Komponente baut, kommt um beide nicht herum.

SD-JWT VC (Selective Disclosure JWT for Verifiable Credentials, IETF-Draft draft-ietf-oauth-sd-jwt-vc) ist der JOSE-stämmige Pfad. Ein Credential ist ein vom Issuer signiertes JWT, in dem sensible Claims nicht im Klartext, sondern als Hashes hinterlegt sind. Die zugehörigen Klartext-Werte (genannt Disclosures) liegen separat — Base64URL-kodierte Tripel aus Salt, Claim-Name und Claim-Wert. Bei der Vorlage gegenüber einem Verifier hängt die Wallet nur jene Disclosures an, die offengelegt werden sollen; der Rest bleibt als Hash im JWT, beweist seine Existenz, aber nicht seinen Wert. Ein Key-Binding-JWT am Ende der Kette signiert die Auswahl mit dem Holder-Schlüssel gegen Verifier-Audience und Nonce. Format auf der Leitung: <jwt>~<disclosure1>~<disclosure2>~...~<kb-jwt>. Der vct-Claim im JWT-Header deklariert den Credential-Typ — typischerweise eine URL wie urn:eu.europa.ec.eudi:pid:1.

mDoc ist der ISO-stämmige Pfad: ISO/IEC 18013-5 in der ursprünglichen Fassung als Mobile Driving Licence, in 18013-7 erweitert um Online-Presentation via OID4VP. Anders als SD-JWT VC ist mDoc CBOR-kodiert und mit COSE_Sign1 signiert — kompakter, dafür weniger entwicklerfreundlich, weil JOSE-Tooling nicht ohne weiteres greift. Die Struktur ist hierarchisch in Namespaces organisiert: org.iso.18013.5.1 für mDL-Felder, eu.europa.ec.eudi.pid.1 für die EU-PID. Das MobileSecurityObject trägt die Issuer-Signatur und die Hashes der Items pro Namespace; bei der Vorlage werden nur die offengelegten Items mitgesendet, der Hash-Vergleich beweist Integrität, ohne den Wert preiszugeben.

Welches Format wo? Für den DACH-Markt und für Bildungs-Use-Cases dominiert SD-JWT VC, weil das Tooling-Ökosystem (JOSE-Bibliotheken, OIDC-Erfahrung) günstiger steht. Für mobile Driving Licences und alles, was in den Automotive- und Behörden-Verkehrsbereich hineinreicht, ist mDoc gesetzt — die Polizeigeräte für Verkehrskontrollen sind nach ISO 18013-5 zertifiziert, das wird nicht durch SD-JWT abgelöst. Eine produktive Verifier-Komponente unterstützt beide; das ist Mehraufwand, aber unumgänglich.

Selective Disclosure ist in beiden Formaten technisch sauber abgedeckt — Mindestoffenlegung wie der Boolean age_over_18 ohne Geburtsdatum funktioniert mit Standard-Werkzeugen. Schwieriger wird es bei der von der Verordnung verlangten Unlinkability: zwei Vorlagen desselben Credentials bei zwei verschiedenen Verifiern sollen nicht verknüpfbar sein, auch nicht durch eine Kollusion zwischen Verifier und Issuer. Reine ECDSA-Signaturen erreichen das nicht — die Issuer-Signatur ist über beide Vorlagen identisch und macht sie verkettbar. Die heutige Best Practice ist Batch Issuance: der Issuer stellt nicht ein Credential aus, sondern fünfzig oder hundert, die Wallet verwendet pro Verifier ein anderes. Das verschiebt das Problem (der Issuer kennt weiterhin die Identität, der Verifier-zu-Verifier-Link wird gebrochen) und kostet Issuance-Ressourcen. Die mathematisch saubere Lösung wären BBS+-Signaturen, die selektive Offenlegung mit unverknüpfbarer Re-Randomisierung aus einer einzigen Issuer-Signatur erlauben — sie sind in der ARF 2.x als Zielzustand benannt, aber 2026 noch nicht hardware-unterstützt, weil kein verfügbares Secure Element BBS+ in Hardware signieren kann.

Revocation ist der dritte technische Knoten. Die EU-Wallet setzt auf die IETF Token Status List (draft-ietf-oauth-status-list) — ein zlib-komprimierter Bitstring, in dem jedes Bit den Status eines Credentials kodiert (gültig, gesperrt, suspendiert). Verifier fetchen die Liste regelmäßig, cachen lokal, prüfen das Bit beim Index aus dem Credential. Das ist effizient, hat aber den Nebeneffekt, dass die Status-Liste vom Issuer mit feinem Korn abgefragt wird — wer hier nicht aufpasst, baut sich ein OCSP-Pendant mit den gleichen Profiling-Risiken.

OID4VCI — Wie ein Credential in die Wallet kommt

OpenID for Verifiable Credential Issuance ist die Spec, die den Weg vom Issuer in die Wallet beschreibt. Sie ist 1.0 final und liegt der EUDI-Implementierung zugrunde.

Issuer-Metadaten werden über /.well-known/openid-credential-issuer publiziert. Der Block credential_configurations_supported deklariert pro angebotenem Credential-Typ das Format (vc+sd-jwt oder mso_mdoc), den vct beziehungsweise Doctype, die unterstützten Claims, die Cryptographic-Binding-Methods und die akzeptierten Proof-Types. Diese Metadaten lesen Wallets als Erstes, bevor sie überhaupt einen Authorization Request beginnen.

Zwei Flows sind zentral. Der Pre-Authorized Code Flow ist die Standardvariante für Szenarien, in denen der Holder im Issuer-Kontext bereits authentifiziert ist — der Studierende ist im Hochschulportal eingeloggt, die Behörde hat den Bürger im Verwaltungsverfahren bereits identifiziert. Der Issuer baut ein Credential Offer mit einem einmaligen pre-authorized_code und optionalem tx_code (eine kurze PIN, die der Holder zusätzlich eintippt) und liefert es an die Wallet als QR-Code oder Deep-Link openid-credential-offer://?.... Die Wallet tauscht den Code am token_endpoint gegen ein Access-Token, baut ein Proof-JWT mit dem Holder-Key gegen die vom Issuer gelieferte c_nonce, ruft credential_endpoint auf und erhält das Credential. Ein Notification-Endpoint bestätigt die erfolgreiche Speicherung.

Der Authorization Code Flow wird verwendet, wenn der Issuer den Holder zum Zeitpunkt der Ausstellung selbst authentifizieren muss — das ist namentlich bei der erstmaligen PID-Ausstellung der Fall, wo eine eID-Auslese des Personalausweises Teil des Flows ist. Die Wallet startet hier mit PKCE einen klassischen OAuth-Flow gegen den Issuer-Authorization-Server, durchläuft eID-Authentifizierung, erhält ein Authorization Code, tauscht es gegen ein Access-Token und holt dann das Credential ab. Der EU-Referenz-PID-Issuer (eudi-srv-pid-issuer auf GitHub) implementiert ausschließlich diesen Flow — Pre-Authorized ist für PID nicht zugelassen.

OID4VP — Wie ein Credential aus der Wallet vorgelegt wird

OpenID for Verifiable Presentations ist die Spec für den umgekehrten Weg: ein Verifier fordert eine Vorlage, die Wallet legt selektiv vor, der Verifier prüft. Hier sitzt das technische Herzstück für jede Anwendung, die EUDI-Wallets konsumiert.

Der Verifier startet, indem er ein signiertes Authorization Request Object erzeugt — ein JWT, das den Client unter client_id deklariert (in der Regel eine X.509-Identität mit DNS-SAN), den response_mode festlegt, die nonce setzt, die presentation_definition (DIF Presentation Exchange) oder die kompaktere dcql_query (Digital Credentials Query Language) einbettet und unter response_uri den Endpunkt benennt, an den die Wallet später ihre Antwort POSTet. Statt das Request-Objekt im Klartext zu übergeben, hinterlegt der Verifier es unter einer URL und gibt der Wallet nur die request_uri mit — wichtig, weil das ganze JWT für einen QR-Code zu groß wäre.

Der response_mode entscheidet über Sicherheits- und Plattform-Eigenschaften. direct_post ist der Default für Cross-Device-Flows: die Wallet POSTet die Antwort als HTTPS-Formular an den Verifier-Endpunkt. direct_post.jwt verschlüsselt diese Antwort zusätzlich als JWE — relevant, wenn der Browser, der den QR-Code zeigt, potenziell kompromittiert sein könnte. dc_api beziehungsweise dc_api.jwt nutzt die Browser-Digital-Credentials-API (W3C WICG): ein JavaScript-Aufruf navigator.credentials.get({digital: {...}}) liefert das vp_token zurück, ohne Custom-Scheme-Roundtrip und ohne separaten HTTPS-Endpunkt. Same-Device-Flows im Browser werden mittelfristig auf diesen Mechanismus konvergieren; Chrome unterstützt ihn seit Mitte 2025 als Standard, Safari und Firefox ziehen nach.

Der Same-Device-Flow auf einem Smartphone funktioniert mit Custom-Scheme-Deep-Links: ein Klick auf openid4vp://?client_id=...&request_uri=... öffnet die Wallet-App. Der Cross-Device-Flow — Desktop-Browser plus Wallet auf dem Smartphone — verwendet QR-Codes mit derselben URL-Struktur. Phishing-Schutz ist hier essentiell: die Wallet validiert die Cert-Chain des Request-Objekts gegen die Trusted-Lists des Mitgliedslandes und akzeptiert nur response_uri-Werte, die mit dem client_id-Cert konsistent sind.

Sequenz — KYC bei einer Bank ohne VideoIdent

Ein konkretes Beispiel zeigt am besten, was bei einer EUDI-Wallet-Anbindung tatsächlich passiert. Szenario: eine Bank in Deutschland eröffnet ein Konto online und ersetzt das bisherige Video-Identifikationsverfahren durch eine OID4VP-Anbindung an die Wallet.

Was die Bank konkret abfragt, steht in der presentation_definition beziehungsweise dcql_query: für KYC üblicherweise given_name, family_name, birthdate, nationality, place_of_birth und die Adresse, gegebenenfalls eine PEP-Indikation. Geht es nur um eine Altersverifikation für ein Tabakgeschäft, reduziert sich die Anfrage auf den Boolean age_over_18 — Name und Geburtsdatum bleiben in der Wallet, das ist die Verordnungsanforderung in Reinform. Die BaFin hat in der Konsultation 2025 signalisiert, dass eine EUDI-Wallet-Identifikation auf Vertrauensniveau high als gleichwertig zur bisherigen Video-Ident­ifikation nach § 12 GwG anerkannt wird — der wirtschaftliche Hebel daraus ist erheblich, weil der manuelle Prüfprozess bei VideoIdent entfällt und nur noch automatisierte Signatur- und Trust-Anchor-Prüfungen ablaufen.

Bibliotheken und Referenzimplementierungen

Die EU-Kommission und mehrere Open-Source-Initiativen liefern hinreichend reifen Code, dass eine Verifier- oder Issuer-Komponente nicht von null gebaut werden muss.

Die EU Reference Implementation unter github.com/eu-digital-identity-wallet umfasst einen Verifier (Spring Boot Kotlin, eudi-srv-web-verifier-endpoint-23220-4-kt), einen PID-Issuer, mobile Wallet-Clients für Android und iOS sowie die Architecture-Reference-Framework-Dokumentation. Der Verifier ist eine sinnvolle Startbasis für eine Java-/Kotlin-basierte Anwendung — er deckt OID4VP mit DCQL und Presentation-Exchange ab, unterstützt direct_post und direct_post.jwt und ist gegen die EUDIW-Spec konformitäts­getestet.

Im JVM-Umfeld bietet walt.id (github.com/walt-id/waltid-identity) einen Kotlin-Multiplatform-Stack, der Issuer, Verifier und Wallet abdeckt — OID4VCI, OID4VP, SD-JWT, mDoc, W3C VC in einer kohärenten Codebasis. Wer in TypeScript arbeitet, findet bei Sphereon OID4VC einen modularen Stack und bei Credo-TS (Open Wallet Foundation) eine Multi-Protokoll-Plattform, die OID4VC und DIDComm kombiniert. eudiplo aus derselben Foundation positioniert sich als HTTP-Middleware: man stellt eine kleine REST-API zwischen Backend und Wallet, anstatt OID4VC-Komplexität direkt in der Anwendung zu haben — sinnvoll, wenn die Geschäftslogik nicht in der gleichen Sprache geschrieben ist wie die Wallet-Bibliothek.

Für mobile Anwendungen ist Multipaz (Kotlin Multiplatform, ebenfalls Open Wallet Foundation) die Wahl für ISO-18013-zentrische Use-Cases mit Bluetooth-Proximity-Flows; Lissi liefert SDKs im DACH-Kontext, die in der deutschen Wallet-Initiative eine tragende Rolle spielen.

Stolperfallen — was am Anfang schiefgeht

Die Spec-Lage ist konsolidiert, die Implementierungen sind aber jung. Drei Klassen von Problemen treten in Pilot­projekten immer wieder auf.

Wallet-Heterogenität. Jeder Mitgliedstaat notifiziert eigene Wallets, alle müssen sich gegenseitig akzeptieren. In der Praxis tauchen Differenzen bei Disclosure-Reihenfolgen, optionalen Feldern, Crypto-Suiten und der Behandlung von Edge-Cases auf. Das High Assurance Interoperability Profile (HAIP) reduziert die Variabilität deutlich — wer einen Verifier baut, sollte gegen HAIP entwickeln, nicht gegen die OID4VP-Spec im Allgemeinen. Trotzdem ist End-to-End-Testing gegen mindestens DE-, IT-, FR- und ES-Wallets vor einem produktiven Roll-out Pflicht.

Phishing über response_uri. Ein Angreifer, der eine Verifier-Domain imitiert, kann ein OID4VP-Request mit der korrekten client_id einer echten Bank vortäuschen und die response_uri auf seinen eigenen Server zeigen lassen. Die Wallet prüft deshalb verbindlich, dass die client_id in der Cert-Chain des Request-Objekts steht und die response_uri unter derselben effektiven Top-Level-Domain liegt. Das HAIP fordert signierte Request-Objekte als verbindlich; Inline-Plain-Authorization-Requests sind nicht mehr zugelassen. Wer die Wallet-Integration eigenhändig baut, sollte diese Validierung als ersten Test in der Pipeline haben.

Schema-Versioning bei vct. Wenn der PID-Issuer 2028 einen zusätzlichen Pflicht-Claim einführt, kollidiert das mit Verifiern, die gegen die alte Version validieren. Best Practice: vct mit Versions-Suffix in der URL versehen (urn:eu.europa.ec.eudi:pid:1 versus :pid:2) und im Verifier eine Versions-Toleranz definieren. Die ARF 2.x macht Vorgaben dazu, sie sind aber noch nicht abschließend ausgehandelt.

Status-Listen-Caching. Eine naive Implementierung fetcht die Status-Liste bei jeder Vorlage frisch — das überlastet den Issuer-Endpunkt und macht die Verifier-Latenz unbrauchbar. Eine produktive Implementierung cached die Liste lokal (typischerweise wenige Minuten bis Stunden, je nach Update-Frequenz des Issuers) und akzeptiert die kleine Lücke zwischen Sperrung und Cache-Refresh. Wer dort Echtzeit-Sperrung verlangt, baut sich ein OCSP-Pendant mit allen seinen Skalierungsproblemen.

Handlungsempfehlung

Wer eine Anwendung in einer akzeptanzpflichtigen Branche betreibt — Bank, Versicherung, Energieversorger, Telekommunikationsanbieter, große Online-Plattform — sollte 2026 nicht abwarten. Die Reihenfolge, die sich in unseren Projekten bewährt: erstens die OID4VP-Verifier-Komponente als isoliertes Modul aufbauen, gegen die EU-Reference-Wallet und gegen eine der DACH-Wallet-Apps (Lissi-Demo, Animo Paradym) testen. Zweitens den Verifier in das bestehende Identity-System integrieren — die Wallet ist eine zusätzliche Authentifizierungsquelle neben dem heutigen Stack, kein Ersatz. Drittens den Trust-Anchor-Fetch, das Status-Listen-Caching und das HAIP-Konformitäts­profil als Hardening-Schicht ergänzen.

Was die EUDI-Wallet für regulatorisch geprägte Branchen attraktiv macht, ist die Eliminierung des manuellen Identifizierungsprozesses. VideoIdent ist teuer, kundenfeindlich und in der Skalierung mühsam. Eine Wallet-basierte Identifikation reduziert den Schritt auf eine kryptographische Signaturprüfung — wenn der Stack einmal steht, sind die Grenzkosten pro Identifikation nahe null. Dafür muss die Investition jetzt erbracht werden, in der Phase, in der die Wallet noch keine Massenverbreitung hat — wer wartet, bis sie da ist, hat eine Schlange am Counter, für die keine Bedienung bereit steht.