Keine Rückruf-Verifizierung: Warum der künftige digitale IDP den Aussteller nicht bei jeder Nutzung kontaktieren darf

Widerruf ist das schwierigste Problem bei jedem künftigen digitalen Internationalen Führerschein (IDP). Der einfachste Weg, es zu lösen, ist auch der gefährlichste: den Aussteller bei jeder einzelnen Vorlage zum Teilnehmer zu machen. Ein modernes grenzüberschreitendes Fahrberechtigungsnachweis sollte diese Abkürzung standardmäßig verweigern.

Fast jeder Vorschlag für digitale Identitäten enthält denselben beruhigenden Satz:

„Der Nachweis kann sofort verifiziert werden.”

Manchmal beschreibt dieser Satz echten Fortschritt. Manchmal beschreibt er Überwachung mit einer freundlicheren Benutzeroberfläche.

Die heute veröffentlichten Standards machen bereits deutlich, dass ein Prüfer den Aussteller nicht bei jeder Vorlage eines Nachweises kontaktieren muss:

• Die aktuelle mDL-Architektur des NIST besagt, dass ein Prüfer Authentizität und Integrität durch Vertrauen in die Signatur und die öffentlichen Schlüssel des Ausstellers validieren kann – ohne direkten Kontakt mit dem Aussteller.
• AAMVA bestätigt, dass ISO/IEC 18013-5 die Unterstützung für den Gerätenabruf vorschreibt und den Serverabruf nur optional zulässt.
• AAMVA warnt auch davor, dass beim Serverabruf die ausstellende Behörde bei jeder Nutzung in Echtzeit beteiligt ist – was bedeutet, dass sie technisch gesehen protokollieren kann, wann der Nachweis verwendet wird, welche Daten geteilt werden, und sogar den Standort durch IP-Analyse ableiten kann.

Das ist keine unbedeutende Fußnote. Es ist die zentrale Designfrage für die nächste Generation grenzüberschreitender Fahrberechtigungsnachweise.

Die gefährliche Abkürzung: Vier Fragen in einem einzigen Netzwerkaufruf bündeln

Schlechte Architekturen bündeln vier sehr unterschiedliche Fragen in einem einzigen Live-Aufruf an den Aussteller:

1. Ist dieser Nachweis authentisch?
2. Ist die vorlegende Person der rechtmäßige Inhaber?
3. Ist der Nachweis selbst noch gültig?
4. Ist das zugrundeliegende nationale Fahrrecht noch in Kraft?

Ein schlecht konzipiertes System beantwortet alle vier durch einen Echtzeit-Rückruf. Ein gut konzipiertes System trennt sie – denn sie sind nicht dasselbe Problem und sollten keinen gemeinsamen Mechanismus teilen.

Authentizität sollte lokal verifiziert werden, nicht über das Netzwerk

Ein Nachweis kann kryptografisch echt sein, ohne dass der Aussteller die Transaktion jemals beobachtet.

• Das mDL-Vertrauensmodell des NIST besagt, dass Authentizität und Integrität anhand der Signatur und der öffentlichen Schlüssel des Ausstellers validiert werden – kein Live-Kontakt zum Aussteller erforderlich.
• Der Digital Trust Service der AAMVA existiert genau deshalb, um Prüfern Zugang zu gültigen öffentlichen Schlüsseln des Ausstellers zu geben, ohne transaktionsbezogene Rückrufe.

Designprinzip 1: Verwenden Sie keine Live-Konnektivität, um ein Problem zu lösen, das Signaturen bereits lösen.

Wenn ein Prüfer vertrauenswürdige Ausstellerschlüssel besitzt und eine standardkonforme Vorlage erhält, ist die Authentizität eine lokale kryptografische Prüfung – keine Netzwerkabhängigkeit.

Die Inhaberbindung sollte lokal nachgewiesen werden, nicht global gemeldet

Die zweite Frage – Ist dies der rechtmäßige Inhaber? – hat ebenfalls eine netzwerkunabhängige Antwort.

Die aktuelle EUDI-Architektur schreibt die Gerätebindung für PIDs und ISO/IEC 18013-5-Attestierungen vor. Der Prüfer fordert die Wallet auf, eine neue Herausforderung mit dem privaten Schlüssel zu signieren, der dem im Nachweis eingebetteten öffentlichen Schlüssel entspricht:

• In ISO/IEC 18013-5 wird dies als mdoc-Authentifizierung bezeichnet.
• In SD-JWT VC wird es als Schlüsselbindung bezeichnet.

In beiden Fällen wird der Besitz lokal und kryptografisch nachgewiesen. Es müssen niemals persönliche Daten den Aussteller erreichen.

Designprinzip 2: Besitz lokal nachweisen. Identität nicht global beweisen.

Ein künftiger IDP sollte Gerätebindung, lokale Inhaberauthentifizierung und Verifier-Challenge-Response ausschöpfen, bevor er irgendeinen ausstellerseitigen Mechanismus in Betracht zieht.

Nachweistatus und Fahrrechtstatus sind zwei verschiedene Dinge

Viele Designs für digitale Identitäten verwischen diese Unterscheidung, und genau dort gehen sie in die falsche Richtung.

Die Bitstring Status List-Spezifikation des W3C macht den Punkt deutlich: Statusinformationen, die einem verifizierbaren Nachweis beigefügt sind, gelten für den verifizierbaren Nachweis selbst – nicht notwendigerweise für den zugrundeliegenden realen Anspruch. Ein digitaler Nachweis könnte widerrufen werden, weil sein Signaturmechanismus kompromittiert wurde, während das zugrundeliegende Fahrrecht vollkommen gültig bleibt.

Ein künftiger IDP benötigt daher zwei separate Statusebenen:

• Nachweisstatusebene – für den digitalen Nachweis oder den Präsentationskanal selbst.
• Fahrrechtsebene – für den zugrundeliegenden nationalen Anspruch auf das Führen eines Fahrzeugs.

Manchmal ändern sich diese zusammen. Oft tun sie es nicht. Ein System, das beides vermischt, wird überreagieren, mehr Daten als nötig offenlegen oder beides.

Wallet-Kompromittierung sollte sich durch den Status fortpflanzen – keine Verifier-Rückrufe auslösen

Ein künftiger IDP benötigt auch eine klare Antwort auf die Frage, was passiert, wenn eine Wallet kompromittiert wird.

Die EUDI-Architektur bietet eine solche:

• Der Wallet-Anbieter stellt Wallet Unit Attestations aus, die Widerrufsinformationen enthalten.
• Die Wallet-Integrität wird regelmäßig neu überprüft; ist eine Wallet nicht mehr sicher, wird ihre Attestierung widerrufen.
• PID-Anbieter müssen regelmäßig prüfen, ob die Wallet widerrufen wurde. Ist dies der Fall, widerrufen sie die PID.
• Durch die Überprüfung des PID-Status verifiziert die vertrauende Partei den Wallet-Status implizit.

Das ist die Schichtung, die ein künftiger IDP übernehmen sollte. Fordern Sie nicht jeden Prüfer auf, den Wallet-Anbieter unabhängig zu überprüfen. Lassen Sie die Wallet-Kompromittierung durch die bestehende Nachweisstatus-Pipeline propagieren, und ermöglichen Sie Prüfern, diesen einzigen datenschutzfreundlichen Kanal zu nutzen.

Drei praktikable Widerrufsmuster (keine Rückrufe erforderlich)

EUDI schreibt vor, dass Anbieter eine von drei Widerrufsmethoden verwenden:

• Kurzlebige Attestierungen – gültig für 24 Stunden oder weniger, sodass ein Widerruf überflüssig wird.
• Attestierungsstatusliste – eine veröffentlichte Liste, die Prüfer einsehen können.
• Attestierungswiderrufsliste – eine explizite Liste widerrufener Nachweise.

Für länger als 24 Stunden gültige Attestierungen schreibt EUDI vor, Widerrufsinformationen einzubetten, die Folgendes enthalten:

• Eine URL, unter der vertrauende Parteien die Statusliste abrufen können.
• Eine Kennung, die den Nachweis innerhalb dieser Liste lokalisiert.

Sind keine zuverlässigen Widerrufsinformationen verfügbar – beispielsweise wenn die vertrauende Partei offline ist – empfiehlt EUDI der vertrauenden Partei, eine Risikoanalyse durchzuführen, bevor sie den Nachweis akzeptiert oder ablehnt.

Die Schlussfolgerung: Widerruf ist kein einheitlicher Mechanismus und sicherlich keine Rechtfertigung für obligatorische Aussteller-Rückrufe.

Standardmäßig kurzlebig, langlebig nur wo notwendig

Eine der wirksamsten Datenschutzmaßnahmen im gesamten Stack ist auch die einfachste: Das Vorgelegte kurzlebig halten.

• EUDI besagt, dass Attestierungen, die 24 Stunden oder weniger gültig sind, keine Widerrufsinfrastruktur benötigen – sie laufen ab, bevor ein Widerruf relevant würde.
• W3C besagt, dass verifizierbare Präsentationen typischerweise kurzlebig und nicht für die Langzeitspeicherung konzipiert sind.
• NIST warnt ausdrücklich davor, wiederverwendbare Kennungen für den alltäglichen Gebrauch wiederholt zu übermitteln. Die tägliche Authentifizierung sollte auf Technologien basieren, die für diesen Zweck entwickelt wurden, wie etwa Passkeys, und nicht auf der wiederholten Vorlage eines identitätsreichen Nachweises.
• NIST entschied sich auch für lokale Geräteauthentifizierung gegenüber serverseitigem biometrischen Abgleich, weil lokale Authentifizierung die Privatsphäre schützt und betrieblich effizienter ist.

Designprinzip 3: Der Basisnachweis kann eine mittlere Gültigkeitsdauer haben, aber die Präsentation selbst sollte kurzlebig, prüferspezifisch und nicht wiederverwendbar sein.

Statuslisten sind der richtige Standardmechanismus

Wenn nicht alles kurzlebig gemacht werden kann, wird eine Statusinfrastruktur benötigt – und die Statusliste ist der richtige Standard.

Die Bitstring Status List v1.0 des W3C beschreibt einen datenschutzfreundlichen, platzsparenden und leistungsstarken Mechanismus zur Veröffentlichung von Statusdaten wie Sperrung oder Widerruf. Zu den wesentlichen Eigenschaften gehören:

• Jeder Aussteller verwaltet eine Liste für die von ihm ausgestellten Nachweise.
• Das Format lässt sich gut komprimieren, da die meisten Nachweise nicht widerrufen werden.
• Die Standard-Listengröße beträgt 131.072 Einträge, was laut W3C im Durchschnittsfall einen angemessenen Gruppendsatenschutz bietet.
• Größere Listen können verwendet werden, wenn ein stärkerer Gruppendsatenschutz erforderlich ist.

Damit verschiebt sich die Frage von:

„Kann ich den Aussteller jetzt gerade zu diesem Nutzer befragen?”

zu:

„Verfüge ich bereits über eine ausreichend aktuelle, datenschutzfreundliche Statusliste, um lokal zu entscheiden?”

Das ist eine weitaus bessere Frage – sowohl technisch als auch politisch.

„Kein Rückruf” ist ein Download-Muster, kein Slogan

Die wichtigste Regel in den EUDI-Datenschutzleitlinien ist verfahrenstechnischer, nicht philosophischer Natur.

Vertrauende Parteien dürfen die Statusliste nicht bei jeder Vorlage eines Nachweises abrufen. Stattdessen müssen sie:

• Jede neue Version der Liste einmal herunterladen.
• Dies zu einem Zeitpunkt und von einem Ort tun, der in keinem Zusammenhang mit einer Nutzervorlage steht.
• Die Liste intern innerhalb der Organisation der vertrauenden Partei verteilen.
• Die Liste abrufen, ohne sich als vertrauende Partei zu authentifizieren.

Das ist der operative Kern der Rückruf-freien Verifizierung: Status getrennt von Nutzervorlagen aktualisieren – niemals pro Person, niemals pro Transaktion.

Diese eine Designentscheidung verhindert, dass der Aussteller oder Statusanbieter erfährt, welcher Prüfer welchen Nachweis zu welchem Zeitpunkt geprüft hat.

Gruppendsatenschutz: Die Anforderung, die die meisten Designs vergessen

Viele Systeme rühmen sich selektiver Offenlegung innerhalb der Präsentation selbst, ignorieren dabei aber stillschweigend den Datenschutz bei Statusabfragen. Das ist eine erhebliche Lücke.

Die Datenschutzanforderungen von EUDI legen fest, dass:

• Indizes in Statuslisten zufällig zugewiesen werden müssen, damit der Index selbst niemals zum Tracking-Signal wird.
• Jede Liste eine ausreichend große Anzahl von Nachweisen abdecken muss, um Gruppendsatenschutz zu gewährleisten.
• Wenn eine Liste andernfalls zu klein wäre, sollten Anbieter ungenutzte Einträge hinzufügen, um die tatsächliche Nachweisanzahl zu verschleiern.

Ein künftiger IDP kann nicht allein auf Grundlage selektiver Offenlegung behaupten, datenschutzfreundlich zu sein. Wenn der Widerrufsmechanismus das Präsentationsereignis preisgibt, ist das Datenschutzkonzept unvollständig.

Offline-Betrieb ist kein Randfall – er ist eine Kernanforderung

Jedes Reisesystem, das eine perfekte Konnektivität voraussetzt, ist schlecht konzipiert.

• AAMVA bestätigt, dass der Gerätenabruf ohne externe Konnektivität sowohl für das Gerät des Inhabers als auch für das Lesegerät funktioniert, und dass ISO/IEC 18013-5 vorschreibt, dass mDLs den Gerätenabruf unterstützen müssen.
• EUDI akzeptiert, dass vertrauende Parteien offline sein und keine zwischengespeicherte Statusliste besitzen können; in diesem Fall empfiehlt es eine Risikoanalyse vor der Entscheidung.

Diesen Kompromiss frühzeitig akzeptieren:

Perfekter Offline-Betrieb und perfekte Echtzeit-Aktualität sind nicht gleichzeitig möglich.

Jede Architektur, die beides ohne Kompromisse verspricht, ist entweder ungenau oder führt stillschweigend Überwachung wieder ein. Die richtige Antwort besteht darin, Aktualität zu einer politischen Eingabe zu machen, nicht zu einer universellen Netzwerkabhängigkeit.

Protokolle: Wo der Datenschutz still scheitert

Selbst eine hervorragende Statusarchitektur kann durch nachlässige Protokollierung unterlaufen werden.

• EUDI verpflichtet Instanzen vertrauender Parteien, eindeutige Elemente und Zeitstempel zu löschen, sobald sie nicht mehr benötigt werden, und verbietet deren Weiterleitung.
• AAMVA untersagt es Beteiligten, mDL-Inhaber oder die mDL-Nutzung zu verfolgen, es sei denn, dies ist gesetzlich vorgeschrieben; schreibt ausstellenden Behörden vor, die Weitergabe statischer oder langlebiger Metadaten zu minimieren; und beschränkt den Zugriff auf Aktivitätsprotokolle auf den Inhaber.
• AAMVA schreibt außerdem vor, dass die Löschung auf dem Gerät Protokollinformationen und Metadaten entfernen muss, die die Nutzungshistorie offenbaren könnten – und dass diese Löschung auch offline möglich sein muss.

Das ist Protokollverhalten, keine administrative Pflege. Ein künftiger IDP muss langlebige Kennungen, Zeitstempel und Protokolle als potenzielle Tracking-Werkzeuge behandeln, sofern nicht explizit das Gegenteil bewiesen wird.

Eine konkrete Rückruf-freie Architektur für den künftigen IDP

Die Prinzipien zusammengeführt – so sollte das System tatsächlich funktionieren:

1. Einen gerätgebundenen Basisnachweis ausstellen. Den Nachweis an Schlüssel binden, die in der sicheren Umgebung der Wallet geschützt sind – unter EUDI für PIDs und ISO/IEC 18013-5-Attestierungen verpflichtend.
2. Nur das Notwendige mit einer neuen Herausforderung anfordern. In einer OpenID4VP-Transaktion ermöglicht eine DCQL-Abfrage der Wallet, dem Inhaber anzuzeigen, welche Attribute angefordert werden; der Prüfer gibt eine Herausforderung aus, um Wiedergabeangriffe zu verhindern (gemäß der aktuellen mDL-Architektur des NIST).
3. Eine kurzlebige Präsentation generieren, keine wiederverwendbare Kennung. Jede Präsentation sollte spezifisch für den Prüfer, die Anfrage und den Moment sein.
4. Authentizität lokal verifizieren. Ausstellersignaturen und öffentliche Schlüssel offline validieren; der Vertrauensdienst der AAMVA ist genau dafür konzipiert.
5. Status aus zwischengespeicherten, separat aktualisierten Listen prüfen. Wo Nachweise zu langlebig sind, um den Widerruf zu umgehen, lokal zwischengespeicherte Statuslisten verwenden, die nach einem von Nutzervorlagen unabhängigen Zeitplan aktualisiert werden.
6. Eine Risikorichtlinie anwenden, wenn Aktualität nicht verfügbar ist. Offline-Entscheidungen zur expliziten Prüferrichtlinie machen, nicht zu unstrukturiertem Raten.
7. Tracking-Daten konsequent löschen. Transaktionsspezifische Elemente und Zeitstempel verwerfen, sobald sie nicht mehr benötigt werden; keine Protokolle aufbewahren, die die Bewegungshistorie rekonstruieren könnten.

So sieht eine ernsthafte Rückruf-freie Architektur aus – mehrschichtig, datenschutzfreundlich, kryptografisch lokal und operativ ehrlich gegenüber der Offline-Realität.

Drei Muster, die durch das Design verboten werden sollten

Ein reifes künftiges IDP-Ökosystem sollte diese als Architekturversagen behandeln, nicht als Optimierungsoptionen:

• Obligatorische Aussteller-Rückrufe bei jeder Vorlage. Die eigenen Datenschutzleitlinien der AAMVA erläutern, warum dies schädlich ist.
• Den Fahrnachweis als routinemäßiges Login verwenden. NIST warnt ausdrücklich davor, identitätstragende Nachweise für die tägliche Authentifizierung wiederholt vorzulegen.
• Kennungen, Zeitstempel und Protokolle aufbewahren, die die Vorlagenhistorie rekonstruieren können. Sowohl EUDI als auch AAMVA verlangen das Gegenteil.

Das Kernargument in einem Satz

Sofortige Verifizierung darf nicht zur Genehmigung für ausstellerseitige Überwachung werden.

Ein künftiger IDP sollte in der Lage sein:

• Authentizität lokal nachzuweisen.
• Besitz lokal nachzuweisen.
• Aktualität datenschutzfreundlich zu prüfen.
• Die Offline-Realität zu tolerieren.
• Auch dann reibungslos zu funktionieren, wenn keine vollständigen Informationen vorliegen.

Nichts davon macht das System schwächer. Es macht es wert, im großen Maßstab eingesetzt zu werden.

In dem Moment, in dem ein Fahrnachweis zum Werkzeug wird, um aufzuzeichnen, wer was, wo und wann vorgelegt hat, hört er auf, eine sicherere Version des Papiers zu sein. Er wird zur Infrastruktur für Beobachtung.

Genau das sollte der künftige IDP verweigern zu werden.

Häufig gestellte Fragen

Was ist „Rückruf-Verifizierung”?
Es handelt sich um jedes Design, bei dem ein Prüfer den Aussteller in Echtzeit kontaktiert, um einen Nachweis zu validieren. Obwohl es Authentizität und Widerruf gleichzeitig löst, ermöglicht es dem Aussteller auch, jedes Vorlageereignis zu beobachten.

Schreibt ISO/IEC 18013-5 Online-Ausstellerkontakt vor?
Nein. AAMVA bestätigt, dass ISO/IEC 18013-5 die Unterstützung für den Gerätenabruf vorschreibt und den Serverabruf nur optional zulässt.

Wie kann Widerruf ohne Kontakt zum Aussteller funktionieren?
Durch kurzlebige Nachweise, Attestierungsstatuslisten oder Attestierungswiderrufslisten – idealerweise mit der vertrauenden Partei, die Statusdaten getrennt von Nutzervorlagen herunterlädt.

Warum ist „Gruppendsatenschutz” bei Statuslisten wichtig?
Wenn eine Statusliste zu klein ist oder ihre Indizes vorhersehbar sind, kann eine Statusanfrage verraten, welcher spezifische Nachweis gerade vorgelegt wurde. Zufällige Indizes und große Listen verhindern dies.

Ist Offline-Verifizierung wirklich praktikabel?
Ja – und Normungsgremien einschließlich AAMVA und EUDI schreiben sie ausdrücklich vor. Der Kompromiss besteht darin, dass perfekte Echtzeit-Aktualität mit perfektem Offline-Betrieb unvereinbar ist; daher muss Aktualität zu einer Richtlinienentscheidung werden, nicht zu einer harten Abhängigkeit.