~/artikel/eidas-grenzueberschreitende-identitaetspruefung

eIDAS 2.0: Grenzüberschreitende Identitätsprüfung für Relying Parties

KI-generiert, menschlich reviewt

7.10.2026 · eudi-wallet

Eine Kanzlei in Berlin will einen Mandanten aus Krakau identifizieren, eine Bank in München eine Kundin aus Helsinki. Heute heißt das: Video-Ident mit Länderabdeckung und manuelle Prüfung. Mit eIDAS 2.0 wird grenzüberschreitende Identitätsprüfung zum Normalfall. Die Wallet aus Polen spricht dasselbe Protokoll wie die deutsche d-you, und die prüfende Stelle registriert sich genau einmal.

Wir entwickeln mit id-call.eu einen verifizierten Videoanruf auf Basis der EUDI-Wallet und sind Launch-Partner der deutschen Wallet. Aus dieser Arbeit stammt die folgende Einordnung.

Einmal registrieren, überall prüfen: Art. 5b eIDAS 2.0

„Passporting” ist ein Begriff aus der Finanzaufsicht und steht nicht in der Verordnung (EU) 2024/1183. Das Prinzip trifft es trotzdem. Art. 5b verpflichtet jede Relying Party, sich in dem Mitgliedstaat zu registrieren, in dem sie niedergelassen ist. Dabei gibt sie an, wofür sie die Wallet nutzt und welche Attribute sie anfragen will. Die Details regelt die Durchführungsverordnung (EU) 2025/848: nationale Register, Prüfung durch einen Registrar, öffentlich abrufbare Einträge.

Grenzüberschreitend funktioniert das, weil das Vertrauen an der Registrierung hängt und nicht am Wohnsitz der Person. Ein deutsches Unternehmen erhält über die deutsche Registrierung ein Zugangszertifikat (access certificate). Die finnische Wallet prüft dieses Zertifikat gegen die von der Kommission veröffentlichten Vertrauensanker. Eine finnische Zulassung braucht es nicht. Umgekehrt prüft das deutsche Backend die finnische PID gegen die notifizierten PID-Aussteller Finnlands.

Zwei Einschränkungen gehören zur ehrlichen Lesart:

  • Die Registrierung ist eine Zweckbindung, keine Blankovollmacht. Fragt eine Relying Party mehr Attribute an als registriert, darf die Wallet das anzeigen oder ablehnen.
  • Nationales Fachrecht bleibt. Ob ein Notar, eine Bank oder eine Praxis eine Identifizierung per Wallet für den konkreten Vorgang nutzen darf, regelt nicht eIDAS, sondern GwG, BeurkG oder das jeweilige Berufsrecht.

Die deutsche Wallet startet am 2. Januar 2027, die Akzeptanzpflicht für regulierte Branchen folgt voraussichtlich Ende 2027 (Details im Überblick zur EUDI-Wallet-Integration).

Der Maschinenraum: Was ein paneuropäischer Verifier braucht

Föderiertes Vertrauen statt bilateraler Verträge

Ein Verifier vertraut Listen, nicht einzelnen Partnern. Die EU-Kommission führt die List of Trusted Lists (LOTL), die auf die nationalen Vertrauenslisten verweist. Für das Wallet-Ökosystem kommen eigene Listen hinzu: PID-Aussteller, Wallet-Anbieter, Zertifizierungsstellen für Zugangszertifikate. Für das Backend heißt das:

  • Trust-Anker automatisiert laden, Signaturen der Listen prüfen, Zertifikatsketten bis zum Anker validieren.
  • Aktualität überwachen. Unser Verifier EUDIPLO stempelt eine konfigurierte Trust List mit einer Gültigkeit von 30 Tagen. Danach lehnt er jede Präsentation ab, die Wallet zeigt nur einen generischen Fehler, und erst das Log nennt die Ursache. Diese Fail-closed-Logik ist richtig, braucht aber einen Cronjob und ein Monitoring.

Format-Dualismus: SD-JWT VC und mdoc

Das Architecture and Reference Framework (ARF) lässt zwei Nachweisformate zu, und ein Verifier, der nur eines davon beherrscht, deckt nicht alle Wallets und Nachweise ab:

  • SD-JWT VC (dc+sd-jwt): JSON-basiert, selektive Offenlegung über gehashte Disclosures, Bindung an das Gerät über ein Key-Binding-JWT. Verbreitet bei Attribut-Attestierungen.
  • ISO mdoc (mso_mdoc, ISO/IEC 18013-5): CBOR-basiert, signiertes Mobile Security Object, Herkunft aus dem mobilen Führerschein. Pflicht für die Prüfung vor Ort.

Wir lösen das in id-call.eu über eine formatneutrale Profilschicht. Jedes Profil beschreibt einen Nachweis in genau einem Format mit eigenen Claim-Pfaden. Die Anfrage bietet beide Formate als Alternativen an, und die Wallet legt vor, was sie hat. Eine Normalisierung führt beide Antworten auf ein gemeinsames Vokabular zurück: Die Fachanwendung sieht family_name, nicht den mdoc-Namespace.

OpenID4VP als Schnittstelle

Zwischen Web-Anwendung und Wallet steht OpenID for Verifiable Presentations (OpenID4VP). Die Relying Party beschreibt per DCQL-Abfrage, welche Nachweise und Attribute sie braucht, signiert die Anfrage mit ihrem Zugangszertifikat und erhält die Präsentation verschlüsselt zurück. Die Kryptografie muss man dafür nicht selbst schreiben. Wir betreiben EUDIPLO, einen quelloffenen Verifier der OpenWallet Foundation, als eigenständigen Dienst. Die Anwendung erhält das geprüfte Ergebnis über einen authentifizierten Webhook.

Praxisfall id-call.eu: Identität an den Kanal binden

Eine gültige Wallet-Präsentation beweist, dass eine echte Wallet beteiligt war. Sie beweist nicht, dass diese Wallet am anderen Ende dieses Videoanrufs sitzt. Diese Lücke nutzen Relay-Angriffe: Die Identifizierung einer echten Person wird durchgereicht, im Video sitzt jemand anderes, im Zweifel ein Deepfake.

Unser Ansatz koppelt beide Ebenen kryptografisch:

  1. Der Client erzeugt das DTLS-Zertifikat für die WebRTC-Verbindung, bevor er sich ausweist, und meldet dessen SHA-256-Fingerprint.
  2. Der Fingerprint geht als transaction_data in die OpenID4VP-Anfrage.
  3. Die Wallet signiert den Hash dieser Daten im Key-Binding-JWT.
  4. Der Verifier prüft den Hash. Der Signalisierungsserver gleicht den Fingerprint mit dem im SDP ausgehandelten ab, und die Gegenseite erhält ihn zum eigenen Vergleich.

Eine abgefangene und anderswo wiederverwendete Präsentation fällt damit auf, denn sie gehört zu einem anderen DTLS-Schlüssel. Das schützt Remote-Beratung bei Notaren, Banken oder Ärzten gegen Man-in-the-Middle und Relay, egal aus welchem Land die Wallet stammt.

Der ehrliche Stand gehört dazu:

  • Das Binding ist gebaut, aber standardmäßig aus. OpenID4VP verlangt, dass Wallets unbekannte transaction_data-Typen ablehnen. Die SPRIND-Testwallet tut das mit unserem Typ, korrekterweise. Produktiv wird das Binding erst mit einem von Wallets unterstützten Typ.
  • Es funktioniert nur mit SD-JWT. EUDIPLO prüft transaction_data nur auf dem SD-JWT-Pfad. Bei mdoc würde das Feld still ignoriert. Deshalb schaltet id-call.eu das Binding nur ein, wenn jedes angebotene Profil SD-JWT ist. Lieber kein Binding behaupten als eines, das niemand prüft.
  • Es schützt nicht gegen den eigenen Server. Ein vollständig kompromittierter Betreiber kann Ergebnis und Anzeige fälschen. Die belastbare Aussage lautet „an den Kanal gebunden”, nicht „Ende-zu-Ende gegen den Betreiber gesichert”.

Was Sie jetzt tun sollten

2027 ist kein Starttermin für Integrationsprojekte, sondern das Datum, an dem sie fertig sein müssen.

  • Registrierung vorbereiten. Use Cases und benötigte Attribute festlegen, und zwar so knapp wie fachlich vertretbar. Das ist Datenminimierung und spätere Registerangabe zugleich.
  • In der Sandbox testen. Einen Verifier aufsetzen, OpenID4VP gegen Testwallets fahren und dabei beide Formate anfragen.
  • Trust-Betrieb einplanen. Listenaktualisierung, Zertifikatsrotation und Monitoring sind Betriebsaufgaben, keine Projektaufgaben.
  • Verifier und Fachanwendung trennen. Das ARF wird weiter versioniert. Steckt die Kryptografie in einem eigenen Dienst, tauschen Sie einen Container statt Ihre Anwendung umzubauen.

Fazit

  • Art. 5b eIDAS 2.0 und die DVO 2025/848 machen eine einzige Registrierung im Sitzland zur Grundlage für Identitätsprüfungen in allen 27 Mitgliedstaaten.
  • Ein paneuropäischer Verifier braucht automatisiertes Trust-List-Management, SD-JWT VC und mdoc sowie OpenID4VP als Schnittstelle.
  • Channel Binding über transaction_data bindet eine Identität an eine konkrete WebRTC-Verbindung. Es hängt heute aber noch an der Unterstützung durch die Wallets und am SD-JWT-Format.

Wie das in einem laufenden Produkt aussieht, zeigt unsere Case Study zu EUDI Verified Call. Wenn Sie Ihre eigene Relying-Party-Integration planen, sprechen Sie mit uns über EUDI-Wallet-Integration.