SD-JWT VC und OpenID4VP: die Protokolle hinter dem EUDI-Wallet

Über das EUDI-Wallet wird viel auf der politischen und organisatorischen Ebene gesprochen: Bereitstellung durch die Mitgliedstaaten bis Ende 2026, Registrierungspflichten, Akzeptanzfristen. Wer das Wallet aber tatsächlich akzeptieren will, steht irgendwann vor einer technischen Frage: Wie prüfe ich konkret, dass ein vorgelegtes Attribut echt, gültig und für meinen Zweck ausreichend ist? Dieser Beitrag schaut auf die Verifikationsseite und die Bausteine, die dort zusammenkommen.

Drei Formate, ein Zusammenspiel

Die Architecture and Reference Framework (ARF), inzwischen in Version 2.x, legt die technischen Standards fest. Für akzeptierende Stellen sind drei davon zentral.

SD-JWT VC (Selective Disclosure JWT Verifiable Credential) ist ein Nachweisformat, das selektive Offenlegung ermöglicht. Der Aussteller signiert ein Bündel von Attributen, aber so, dass die nutzende Person einzelne davon offenlegen kann, ohne die übrigen preiszugeben. Technisch geschieht das über Salted Hashes: Jedes Attribut wird einzeln gehasht, signiert wird über die Hashes. Wer ein Attribut zeigt, liefert den passenden Klartext und Salt mit, der Rest bleibt verborgen, die Signatur bleibt prüfbar.

ISO/IEC 18013-5 (mdoc) ist das aus dem mobilen Führerschein stammende Format, das im EUDI-Kontext für bestimmte Nachweise parallel genutzt wird. Eine akzeptierende Stelle sollte beide Formate verarbeiten können, da die Mitgliedstaaten nicht überall identisch vorgehen.

OpenID for Verifiable Presentations (OpenID4VP) ist das Protokoll, über das die Präsentation läuft. Es definiert, wie eine prüfende Stelle eine Anfrage stellt (welche Attribute, zu welchem Zweck) und wie das Wallet die Antwort signiert zurückliefert.

Was selektive Offenlegung praktisch ändert

Das gängige Beispiel ist die Altersprüfung. Statt das volle Geburtsdatum zu übertragen, kann das Wallet allein das abgeleitete Attribut „über 18" offenlegen. Für die akzeptierende Stelle heißt das: Sie sollte ihre Anfragen so formulieren, dass sie genau das Prädikat erhält, das sie braucht, nicht den vollständigen Datensatz dahinter. Datenminimierung ist hier kein nachgelagerter Datenschutzgedanke, sondern in das Protokoll eingebaut.

Der schwierige Teil: Vertrauen statt Gültigkeit

Eine Signatur zu prüfen ist die leichte Aufgabe. Die schwierige ist die Frage dahinter: Ist der Aussteller, der dieses Attribut signiert hat, überhaupt berechtigt und echt? Hier kommen Vertrauenslisten ins Spiel. Die EU und die Mitgliedstaaten führen Register, über die eine prüfende Stelle verlässlich feststellt, ob ein Wallet und seine Aussteller authentisch und zugelassen sind. Ohne diese Anbindung prüft man zwar eine korrekte Signatur, weiß aber nicht, ob die dahinterstehende Identität vertrauenswürdig ist.

Genauso wichtig ist die umgekehrte Richtung: Die prüfende Stelle selbst muss sich vor der ersten Nutzung bei einem nationalen Register registrieren und dabei angeben, welche Attribute sie zu welchem Zweck anfragt. Erst diese Registrierung ist die rechtliche Grundlage, überhaupt Daten anfragen zu dürfen.

Warum sich der Blick auf Standards lohnt

Wer auf die offenen Formate und Protokolle setzt statt auf proprietäre Adapter, hält die Wallets unterschiedlicher Mitgliedstaaten in Reichweite, ohne pro Land neu integrieren zu müssen. In unserem Modul Datargo ID ist diese akzeptierende Rolle der rote Faden, vom Single Sign-On bis zum EUDI-Pfad. Der technische Kern gilt jedoch unabhängig vom Werkzeug: Wer SD-JWT VC, mdoc und OpenID4VP verarbeiten kann und die Vertrauenslisten korrekt anbindet, ist für die Verifikation gerüstet, gleich aus welchem Mitgliedstaat das Wallet stammt.

Die Bereitstellung des Wallets ist eine politische Frist. Die Verifikation sauber aufzusetzen ist eine technische Aufgabe, und sie beginnt mit dem Verständnis dieser drei Bausteine.