Polizei, Mietschalter, Arbeitgeber, Versicherer: Warum sie nicht dieselben Daten sehen dürfen

Der größte Designfehler bei einem zukünftigen Internationalen Führerschein (IFS) wäre es, jeden Prüfer als denselben Prüfer zu behandeln. Ein Polizeibeamter, ein Autovermietungsschalter, ein Arbeitgeber und ein Versicherer stellen nicht dieselbe Frage – also sollten sie auch nicht dieselbe Antwort erhalten.

Ein Fahrer. Ein zugrundeliegendes Fahrrecht. Eine Wallet. Aber vier sehr unterschiedliche Prüfer:

• Ein Polizeibeamter am Straßenrand
• Ein Autovermietungsschalter bei der Fahrzeugabholung
• Ein Arbeitgeber, der die Fuhrparkberechtigung prüft
• Ein Versicherer, der einen Schadensfall prüft

Wenn der zukünftige IFS allen vier dieselben Daten zeigt, hat das System bereits versagt. Nicht weil der Nachweis unsicher ist, sondern weil das Offenlegungsmodell zu einfach ist.

Die Normungsgemeinschaft bewegt sich bereits weg von diesem einfachen Modell. Die Arbeit des W3C zu verifizierbaren Nachweisen beschreibt das Ökosystem rund um Aussteller, Inhaber und Prüfer und nennt Arbeitgeber und Websites als Beispiele für Prüfer. Die Arbeit der EU zum mobilen Führerschein behandelt Straßenkontrollen und Autovermietungen bereits als separate Prüfungsszenarien, einschließlich der vorherigen Fernübermittlung für Mietvorgänge und persönlicher Kontrollen durch die Polizei. Die Architektur ist bereits für mehrere Prüfertypen ausgelegt. Der Fehler wäre es, die Benutzererfahrung so zu gestalten, als gäbe es nur einen einzigen Typ.

Warum der physische Ausweis uns zu falschen Denkmustern verleitet hat

Ein physischer Führerschein hat uns an einen Alles-zeigen-Ansatz gewöhnt. Man übergibt die Karte. Die andere Person sieht, was auf der Karte steht. Das ist die gesamte Interaktion.

Dieser Ansatz ist in einer papierbasierten Welt akzeptabel, weil es keine Alternative gibt. In einer digitalen Welt wird er inakzeptabel.

Das W3C VC Data Model 2.0 stellt direkt fest: Ein Führerschein kann Ausweisnummer, Größe, Gewicht, Geburtsdatum und Heimatadresse enthalten – aber das kann für eine bestimmte Transaktion immer noch weit mehr sein als notwendig. Wesentliche Punkte aus den aktuellen Standards:

• W3C-Best-Practice: selektive Offenlegung unterstützen und nur das unbedingt Erforderliche anfordern
• EU-Datenschutzvorgaben: die Verarbeitung muss auf festgelegte Zwecke beschränkt sein, und die verarbeiteten Daten müssen notwendig und verhältnismäßig sein
• Das erste Prinzip eines zukünftigen IFS: Gleicher Nachweis bedeutet nicht gleiche Einsichtsberechtigung

Das richtige Modell ist eine richtlinienbasierte Offenlegung

Wer eine ernsthafte Architektur anstrebt, sollte eher auf attributbasierte Zugriffskontrolle als auf die digitale Kartenpräsentation setzen.

NIST SP 800-205 definiert Zugangskontrollentscheidungen als Auswertungen von Attributen, die dem Subjekt, dem Objekt, dem angeforderten Vorgang und den Umgebungsbedingungen zugeordnet sind – und zwar anhand von Richtlinien. Das ist genau die richtige Struktur für einen zukünftigen IFS:

• Subjekt: der Fahrer
• Objekt: die angeforderten Datenfelder
• Aktion: nicht abstrakt „Führerschein einsehen”, sondern etwas Konkretes wie „Berechtigung zum Führen von Fahrzeugen der Klasse B am Straßenrand prüfen” oder „Mietberechtigung für eine Buchung bestätigen”
• Umgebung: Straßenkontrolle, Mietschalter, vorherige Fernprüfung, Fuhrpark-Onboarding und nachträgliche Schadensfallprüfung sind unterschiedliche Umgebungen und sollten zu unterschiedlichen Entscheidungen führen

NIST weist auch darauf hin, dass Attributsysteme Granularität, Governance sowie Mechanismen zur Reduzierung, Gruppierung und Minimierung von Attributen benötigen.

Der zukünftige IFS sollte daher nicht fragen: Darf dieser Prüfer den Führerschein einsehen? Er sollte fragen: Welche Angaben darf dieser Prüfer erhalten, für welchen beabsichtigten Zweck, in welcher Umgebung und mit welchen Aufbewahrungsregeln?

Ein Prüfer sollte sich identifizieren, bevor er etwas anfordert

Der zukünftige IFS sollte nicht damit beginnen, dass die Wallet Daten anzeigt. Er sollte damit beginnen, dass der Prüfer nachweist, wer er ist.

Die EUDI-Architektur ist dabei eindeutig. Vertrauende Parteien müssen:

• Registrieren, welche Attribute sie zu welchem Zweck anfordern wollen
• Zugangszertifikate erhalten
• Sich bei der Wallet authentifizieren, bevor eine Offenlegung erfolgt
• Gegen ihren registrierten Umfang geprüft werden, sofern Registrierungsinformationen verfügbar sind

Der Nutzer kann dann sehen, wer fragt, was angefordert wird und ob die Anfrage im registrierten Umfang liegt.

Die aktuelle Arbeit von ETSI zu Wallet-Vertrauenspartei-Zertifikaten konkretisiert dies weiter. Ein Wallet-Vertrauenspartei-Registrierungszertifikat kann den beabsichtigten Verwendungszweck der vertrauenden Partei und die von ihr zur Anforderung registrierten Attribute beschreiben. Das dazugehörige Zugangszertifikat stellt sicher, dass die Anfrage von einer legitimen, autorisierten Partei stammt. ETSI enthält zudem Metadaten der vertrauenden Partei wie:

• Handelsname
• Support-URI
• Beabsichtigter Verwendungszweck
• Berechtigungen
• Register-URI
• Informationen zur Aufsichtsbehörde

Das zweite Prinzip eines zukünftigen IFS: Keine Prüferidentität, keine Offenlegung.

Warum Zustimmungsbildschirme nicht ausreichen

Hier liegt ein weiterer Fehler: die Nutzerfreigabe mit rechtlicher Legitimität gleichzusetzen.

Die EUDI-Architektur stellt ausdrücklich fest, dass die Zustimmung des Nutzers zur Übermittlung von Attributen nicht als Rechtsgrundlage für die Verarbeitung personenbezogener Daten durch die vertrauende Partei angesehen werden darf. Die vertrauende Partei muss weiterhin über eine eigene Rechtsgrundlage verfügen. EUDI verlangt in allen Anwendungsfällen die Zustimmung des Nutzers, einschließlich der Fälle, in denen die vertrauende Partei Teil der Strafverfolgungsbehörden oder einer anderen Behörde sein könnte.

Eine gute Wallet-Oberfläche kann helfen, aber sie kann allein kein Prüfer-Overreach lösen. Die Regel muss vor der Oberfläche existieren.

Ein zukünftiger IFS benötigt daher beides:

• Kryptografische Prüferauthentifizierung, um zu bestätigen, wer fragt
• Richtlinienbeschränkungen darüber, was diese Prüferkategorie anfordern darf

Ohne beides wird „Nutzerwahlfreiheit” zu einem Mittel, um politisches Versagen auf den Einzelnen abzuwälzen.

1. Polizei: Das Fahrrecht prüfen, nicht die gesamte Person

Das Szenario der Straßenkontrolle durch die Polizei ist das fokussierteste.

Das EU-mDL-Handbuch beschreibt es direkt: Polizei oder andere Behörden prüfen den Führerschein bei Bedarf, einschließlich der Gültigkeit und der Fahrzeugklassen-Berechtigungen. Im Ablauf überprüft der Beamte den Führerschein über einen QR-ausgelösten Vorgang, Bluetooth, Wi-Fi Aware oder NFC. Das ist eine fokussierte Prüfaufgabe:

• Ist diese Person der Inhaber?
• Ist der Nachweis gültig?
• Welche Fahrzeugklassen-Berechtigungen und Einschränkungen gelten?

Standardmäßig zulässig:

• Name
• Lichtbild
• Führerscheinstatus
• Ausstellungs- und Ablaufdatum
• Fahrzeugklassen
• Fahrrelevante Einschränkungen
• Aussteller und Zuständigkeitsgebiet
• Aktualitäts-/Statusergebnis

Standardmäßig nicht zulässig:

• Heimatadresse
• Interne Kennungen, die für den Straßeneinsatz nicht benötigt werden
• Nicht relevante Attribute aus anderen Nachweisen
• Historische Präsentationsprotokolle
• Kommerzielle Metadaten

Der Implementierungsleitfaden der AAMVA bestärkt den Punkt zum Lichtbild: Wenn das Lichtbild angefordert wird und ein anderes Element freigegeben wird, sollte das Lichtbild mitgeteilt werden, damit der Prüfer die Daten mit der vorlegenden Person verknüpfen kann. Derselbe Leitfaden besagt auch, dass Beteiligte mDL-Inhaber oder die mDL-Nutzung nicht verfolgen dürfen, außer wo dies gesetzlich vorgeschrieben ist.

Beim Polizeifall geht es nicht darum, dass der Staat alles erhält. Es geht darum, dass der Staat die fahrspezifischen Daten erhält, die für die Straßenkontrolle benötigt werden. Das ist ein wichtiger Unterschied.

2. Mietschalter: Berechtigung, Identitätsabgleich und nichts Unnötiges

Der Mietfall ist detaillierter, da es wirklich zwei Momente gibt: die vorherige Fernprüfung vor der Ankunft und die Abholung, wenn eine Person oder ein Kiosk die Schlüssel übergibt.

Das EU-mDL-Handbuch modelliert bereits beide. Ein Autovermietungsunternehmen kann den mDL zusammen mit einem Identitätsnachweis bei der Buchung anfordern, die Nachweise validieren und den Kunden später bei der Abholung persönlich überprüfen, bevor das Fahrzeug übergeben wird. Nutzer können ihren mDL Autovermietungsunternehmen entweder persönlich oder vorab aus der Ferne übermitteln.

Ein Mietschalter muss in erster Linie keinen Vorfall untersuchen. Er muss entscheiden: Kann ich dieses Fahrzeug an diesen Kunden unter dieser Buchung und Police vermieten?

Die vorherige Fernprüfung sollte beinhalten:

• Identitätsverknüpfung
• Lichtbild oder gleichwertiges identitätsbindendes Element
• Relevante Fahrzeugklasse
• Ausstellungs- und Ablaufdatum
• Aktuelle Gültigkeit
• Möglicherweise eine Altersschwelle oder Altersgruppe

Die Abholung sollte bestätigen:

• Der Inhaber ist dieselbe Person, die die Vorprüfung abgeschlossen hat
• Aktuelle Gültigkeit
• Relevante Berechtigungen

Standardmäßig nicht erforderlich:

• Vollständige Heimatadresse, wenn ein Buchungsprofil bereits Kontaktdaten enthält
• Vollständiges Geburtsdatum, wenn eine Altersangabe oder Altersgruppe ausreicht
• Nicht relevante Identitätsattribute
• Wiederholte erneute Vorlage des vollständigen Nachweises, wenn bereits ein Buchungsnachweis vorhanden ist

Die aktuelle mDL-Architektur des NIST zeigt, dass die vertrauende Partei DCQL verwendet, um nur die benötigten Attribute anzufordern, und stellt ausdrücklich fest, dass dies die Datensparsamkeit und die Einwilligung des Inhabers unterstützt, indem die Anfrage strukturiert wird, anstatt den Nachweis als Einheit zu behandeln. AAMVA ergänzt, dass die Anwendung klar anzeigen sollte, welche Daten angefordert wurden und ob der Prüfer beabsichtigt, die Informationen aufzubewahren.

3. Arbeitgeber: Eine Prüferkategorie, kein Zugang zur vollständigen Identität

Die Übersicht des W3C nennt das digitale System eines Arbeitgebers, das einen Universitätsabschluss prüft, als Beispiel für einen Prüfer. Das erinnert uns daran, dass die Arbeitgeberverifizierung bereits ein anerkanntes Muster in Nachweis-Ökosystemen ist.

Ein Arbeitgeber oder Fuhrparkbetreiber kann legitimer Weise wissen müssen:

• Ob ein Mitarbeiter derzeit berechtigt ist, bestimmte Fahrzeugklassen zu führen
• Ob wesentliche Einschränkungen bestehen
• Ob die Berechtigung noch gültig ist

Das ist ein echter Geschäftsbedarf. Er rechtfertigt jedoch nicht automatisch dauerhaften Zugang zum gesamten Fahrnachweis, den vollständigen Identitätsdaten oder einem kontinuierlichen Strom wiederholter Präsentationen.

NIST warnt davor, dass die häufige Übertragung eines wiederverwendbaren Identifikators und die Konditionierung von Nutzern, wiederholt einen identitätsbezogenen Nachweis vorzulegen, unerwünscht ist, und empfiehlt, dass die alltägliche Authentifizierung auf für die Authentifizierung konzipierten Technologien wie Passkeys basieren sollte. NIST bevorzugt die lokale Geräteauthentifizierung gegenüber dem serverseitigen biometrischen Abgleich, da sie den Datenschutz besser wahrt.

Ein zukünftiger IFS sollte nicht zum Betriebszugangsausweis werden.

Für Arbeitgeber und Fuhrparknutzung ist das richtige Muster in der Regel:

• Eine aufgabenrelevante Berechtigungsprüfung
• Möglicherweise eine regelmäßige Compliance-Bescheinigung
• Möglicherweise eine Bestätigung, dass der Inhaber für bestimmte Fahrzeugklassen weiterhin gültig ist
• Aber keine standardmäßige Übertragung aller Führerscheindaten jedes Mal, wenn sich der Mitarbeiter in ein System einloggt oder eine Schicht beginnt

Fuhrpark-Compliance ist eine separate Kategorie der vertrauenden Partei, mit einem separaten beabsichtigten Verwendungszweck und einem separaten Offenlegungsprofil.

4. Versicherer: Schadensfälle sind keine Erlaubnis zur dauerhaften Einsicht

Der Versicherungsfall ist oft real. Im EU-mDL-Anwendungsfall-Material tauchen Versicherer indirekt im Mietszenario auf: Versicherungsunternehmen verlangen von Autovermietungsunternehmen, zu prüfen, ob die Person, die das Auto mietet, das Recht hat, es zu fahren. Versicherungen beeinflussen bereits den Ablauf der Fahrberechtigungsprüfung.

Das bedeutet jedoch nicht, dass ein Versicherer dieselben Daten wie die Polizei erhalten sollte oder ein dauerhaftes Zugriffsrecht auf den Nachweis hat.

Ein zukünftiger IFS sollte Versicherer als separate Prüferkategorie mit separaten beabsichtigten Verwendungszwecken behandeln:

• Risikoprüfung (Underwriting)
• Mietrisikoprüfung
• Schadensbearbeitung nach einem Verlust
• Betrugsüberprüfung

Das sind nicht dieselben Zwecke. Nach den EU-Datenschutzgrundsätzen müssen personenbezogene Daten für festgelegte Zwecke erhoben werden und auf das für diesen Zweck Notwendige und Verhältnismäßige beschränkt sein. Die VC-Leitlinien des W3C kommen technisch zum gleichen Schluss: Prüfer sollten nur das unbedingt Erforderliche anfordern.

Legitime, ereignisspezifische Beispiele:

• Nachweis, dass der Führerschein zum relevanten Zeitpunkt gültig war
• Nachweis der relevanten Fahrzeugklassen-Berechtigung
• Nachweis der Identitätsverknüpfung, sofern für einen Schadensfall erforderlich
• Schadensfallspezifische Offenlegung

Standardmäßig nicht zulässig:

• Dauerhafter Zugang zum zugrundeliegenden Nachweis
• Wiederholte allgemeine Prüfung bei jeder Interaktion des Kunden mit dem Versicherer
• Verwendung des Fahrnachweises als Anmelde-Token
• Erhebung nicht relevanter Attribute

Ein Fahrnachweis ist kein Überwachungsabonnement. Und er sollte es auch nicht stillschweigend werden.

Warum Intermediäre sichtbar sein müssen

Reale Märkte beinhalten Intermediäre. Mietplattformen, Fuhrparkdienstleister, betriebliche HR-Systeme und Schadenssachbearbeiter von Versicherungen handeln häufig über Dritte.

Die EUDI-Architektur begegnet dem durch:

• Behandlung von Intermediären als vertrauende Parteien
• Pflicht zur Registrierung
• Pflicht zur Registrierung der für die vermittelte vertrauende Partei angeforderten Attribute
• Anzeige sowohl des Intermediärs als auch der endgültigen vertrauenden Partei gegenüber dem Nutzer
• Verbot für Intermediäre, Daten über den Inhalt der Transaktion zu speichern

Ein zukünftiger IFS sollte niemals ein Muster zulassen, bei dem der Nutzer glaubt, er legt Daten gegenüber dem Vermietungsunternehmen offen, in Wirklichkeit aber gegenüber einem unsichtbaren Prüfvermittler, Analyseprozessor und einer Schadenssachbearbeiterkette offenlegt.

ETSI hilft hier weiter. Sein Wallet-Vertrauenspartei-Zertifikatsmodell umfasst Support-URIs, beabsichtigte Verwendungszwecke, Register-URIs und Metadaten der Aufsichtsbehörden. Das ist die Art maschinenlesbarer Infrastruktur, die Nutzer benötigen, um zu verstehen, wer tatsächlich auf der anderen Seite der Anfrage steht und an wen sie sich wenden können, wenn sie Löschung oder Berichtigung wünschen.

Aufbewahrung ist Teil der Zugriffskontrolle

Die meisten Diskussionen über selektive Offenlegung enden zu früh. Sie konzentrieren sich auf das, was offengelegt wird. Sie widmen der Frage, wie lange es danach gespeichert bleibt, nicht genug Aufmerksamkeit.

Die aktuellen Leitlinien konvergieren bereits:

• AAMVA: Die Wallet muss dem Inhaber klar mitteilen, welche Daten angefordert wurden und ob der Prüfer beabsichtigt, sie aufzubewahren; Beteiligte dürfen Inhaber oder die mDL-Nutzung nicht verfolgen, außer wo dies gesetzlich vorgeschrieben ist
• W3C: Inhabersoftware sollte Protokolle der mit Prüfern geteilten Informationen bereitstellen, damit übermäßige Anfragen erkannt werden können
• EUDI: Nutzer sollten auf Transaktionsprotokolle zugreifen, verdächtige Anfragen melden und die Löschung beantragen können

Die Aufbewahrungsklasse sollte Teil der Offenlegungsrichtlinie selbst sein:

• Polizeiliche Straßenkontrolle: standardmäßig keine Aufbewahrung über den gesetzlich vorgeschriebenen Betriebsnachweis hinaus
• Vorherige Mietprüfung: Transaktionsnachweis an die Buchung gebunden, keine wiederverwendbare Identitätskopie
• Arbeitgeber-Fuhrpark-Compliance: Compliance-Nachweis oder Bescheinigungsergebnis, keine Rohdaten des Nachweises
• Versicherer-Schadensfall: Schadensfall-Nachweis auf den Schadensfall beschränkt, kein dauerhafter Zugang

Ein zukünftiger IFS, der die Aufbewahrung ignoriert, ist nur teilweise datenschutzwahrend.

Was die Wallet tatsächlich entscheiden sollte

Wenn ich diesen gesamten Artikel auf eine Implementierungsregel reduzieren müsste, wäre es diese:

Die Wallet sollte nicht antworten: „Kann ich diesen Nachweis präsentieren?” Sie sollte antworten: „Kann ich diesen Satz von Angaben an diesen authentifizierten Prüfer, für diesen beabsichtigten Verwendungszweck, in diesem Kontext, unter dieser Aufbewahrungsklasse präsentieren?”

Diese Entscheidung sollte mindestens auf diesen Eingaben basieren:

• Prüferidentität
• Prüferkategorie
• Beabsichtigter Verwendungszweck
• Registrierter Attributumfang
• Offenlegungsrichtlinie des Ausstellers, sofern vorhanden
• Umgebung (Straßenkontrolle, Abholung, Fernzugriff, Fuhrpark, Schadensfall)
• Zustimmung des Inhabers
• Geltende Aufbewahrungsrichtlinie

Die Standards enthalten bereits einen Großteil der dafür erforderlichen Mechanismen: selektive Offenlegung, Authentifizierung der vertrauenden Partei, registrierter Verwendungszweck, Zugangszertifikate, Auswertung von Offenlegungsrichtlinien und zweckgebundene Anfragen. Was noch fehlt, ist die Disziplin, diese Teile als eine kohärente Offenlegungsarchitektur zu behandeln.

Das Kernargument

Der zukünftige IFS sollte nicht fragen, ob Daten offengelegt werden können. Er sollte fragen:

• Wer fragt?
• Zu welchem Zweck?
• Auf Basis welcher Befugnis?
• In welchem Kontext?
• Mit welchen Aufbewahrungsfolgen?

Polizei, Mietschalter, Arbeitgeber und Versicherer sind nicht vier Logos am anderen Ende einer Anfrage. Sie sind vier verschiedene Risikomodelle, vier verschiedene rechtliche Kontexte, vier verschiedene Gründe zu fragen – und sie sollten vier verschiedene Offenlegungssätze ergeben.

Das ist keine unnötige Komplexität. So sieht ein moderner Fahrnachweis aus, wenn er aufhört, jeden Prüfer als denselben Prüfer zu behandeln.