Der Stack hinter dem zukünftigen IDP: Warum eine geschichtete Normenarchitektur notwendig ist, um den Papier-Führerschein zu ersetzen

Kein einzelner Standard wird den internationalen Führerschein (IDP) aus Papier ersetzen. Der eigentliche Nachfolger ist ein aufeinander abgestimmter Stapel von Standards – und das Verständnis dieses Stapels ist der Schlüssel dazu, wohin sich grenzüberschreitende digitale Fahrausweise tatsächlich entwickeln.

Warum kein einzelner Standard den Papier-IDP ersetzen wird

Die meisten Diskussionen über den zukünftigen IDP beginnen mit der falschen Frage: Welcher Standard wird den Papierausweis ersetzen? Diese Fragestellung geht davon aus, dass eine einzige Spezifikation die gesamte Aufgabe erfüllen kann. Das kann sie nicht.

NISTdie mDL-Arbeit (Mobile Driving License) weist ausdrücklich darauf hin, dass neue Standards für digitale Nachweise in verschiedenen Problembereichen entstehen. Die ISO-18013-Familie selbst ist bereits auf mehrere Teile aufgeteilt, die physisches Design, Sicherheit, mobile Präsentation und Interneterweiterungen abdecken. Ein zukünftiger grenzüberschreitender Fahrausweis ist daher keine einzelne Spezifikation – sondern ein koordinierter Stapel von Spezifikationen, von denen jede ein bestimmtes Anliegen behandelt.

Der zukünftige IDP-Stack auf einen Blick

Hier sind die acht Schichten, die zusammen genommen definieren, wie ein zukünftiger IDP aussieht:

Schicht 0 — Physische und datenbezogene Grundlage: ISO/IEC 18013-1
Schicht 1 — Nachweissicherheit: ISO/IEC 18013-3
Schicht 2 — Näherungs- (persönliche) Präsentation: ISO/IEC 18013-5
Schicht 3 — Fern- / Internetpräsentation: ISO/IEC 18013-7
Schicht 4 — Nachweissemantik: W3C Verifiable Credentials Data Model 2.0
Schicht 5 — Ausstellungsprotokoll: OpenID4VCI
Schicht 6 — Anfrage- und Präsentationsprotokoll: OpenID4VP
Schicht 7 — Vertrauensverteilung und Verifizierungsautorisierung: Vertrauensregister (AAMVAs VICAL-Modell, das zertifikatsbasierte Relying-Party-Modell der EUDI)

Jede Schicht basiert auf aktuellen Standards oder aktiver Ökosystem-Dokumentation. Die folgenden Abschnitte erläutern, was jede Schicht leistet – und ebenso wichtig, was sie nicht leistet.

Schicht 0 — ISO/IEC 18013-1: Die physische und semantische Grundlage

Teil 1 ist bedeutsamer als die meisten Menschen erkennen, denn es geht darin nicht nur um Kartendesign.

ISO/IEC 18013-1 definiert die physischen Eigenschaften und den grundlegenden Datensatz eines ISO-konformen Führerscheins und schafft damit eine gemeinsame Basis für die internationale Nutzung und gegenseitige Anerkennung. Er basiert auf einer sicheren ID-1-Karte in Verbindung mit einem Heftchen für die internationale Verwendung und ersetzt das ältere Papier-IDP-Modell. ISO weist zudem darauf hin, dass in vielen Fällen eine einzige Karte zwei separate Dokumente ersetzen kann.

Die praktische Konsequenz ist einfach: Der zukünftige IDP kann nicht auf der Wallet-Ebene beginnen. Wenn die zugrundeliegende Dokumentenstruktur, das Datenmodell und das Layout nicht zuerst standardisiert werden, wird jede digitale Schicht darüber zu einem Kompatibilitäts-Patch über fragmentierten nationalen Formaten. Teil 1 ist das Fundament, auf das der Rest des Stacks aufbaut.

Schicht 1 — ISO/IEC 18013-3: Nachweissicherheit

In Teil 3 vollzieht der Nachweis den Übergang von Daten auf einem Dokument zu einem Sicherheitsobjekt. ISO beschreibt 18013-3 als den Teil, der Mechanismen für Folgendes festlegt:

Zugriffskontrolle auf maschinenlesbare Daten
Dokumentenauthentifizierung
Integritätsprüfung

ISO stellt jedoch auch klar, dass Teil 3 keine Datenschutzfragen bezüglich der späteren Verwendung der Daten behandelt – und diese Grenze ist wichtig.

Kurz gesagt: 18013-3 gewährleistet die Nachweissicherheit, jedoch keine vollständige Ökosystem-Governance. Es beantwortet Fragen wie: Wurde dieser Nachweis von der angegebenen Behörde ausgestellt? Wurden die Daten verändert? Es beantwortet jedoch nicht vollständig: Sollte dieser Verifizierer dieses Feld überhaupt anfordern? Sollte diese Anfrage in diesem Kontext erlaubt sein?

Dies ist auch eine aktive Schicht und kein fertiges Produkt. ISO listet eine Änderung von 2022 für das PACE-Protokoll auf, eine Änderung von 2023 für Aktualisierungen der passiven Authentifizierung sowie einen neuen Entwurf von 18013-3, der sich derzeit in Entwicklung befindet.

Schicht 2 — ISO/IEC 18013-5: Persönliche mobile Präsentation

Wenn Teil 1 das Dokument definiert und Teil 3 es sichert, verwandelt Teil 5 den Führerschein in einen mobilen Nachweis.

ISO legt fest, dass 18013-5 die Schnittstelle zwischen dem mDL und dem Lesegerät sowie zwischen dem Lesegerät und der Infrastruktur der ausstellenden Behörde abdeckt. Es ermöglicht auch Dritten – einschließlich Behörden und Verifizierern in anderen Ländern –:

mDL-Daten maschinell zu erfassen
diese Daten mit dem Inhaber zu verknüpfen
deren Ursprung zu authentifizieren
deren Integrität zu überprüfen

Was 18013-5 nicht abdeckt, ist ebenso wichtig. ISO listet ausdrücklich Punkte auf, die außerhalb des Geltungsbereichs liegen, darunter wie die Einwilligung des Inhabers zur Datenweitergabe eingeholt wird und die Anforderungen für die Speicherung von mDL-Daten und privaten Schlüsseln. Teil 5 ist kein vollständiges Wallet-Produkt, kein vollständiges Nutzereinwilligungsmodell und kein vollständiges Governance-System. Es ist die Transport- und Verifikationsschicht für die mobile Präsentation.

Der Implementierungsleitfaden der AAMVA schärft dies weiter, indem er zwischen zwei Abrufmodellen unterscheidet:

Geräteabruf, bei dem die Daten direkt vom Gerät des Inhabers ausgelesen werden.
Serverabruf, der es der ausstellenden Behörde ermöglichen kann, zu beobachten, wann der mDL verwendet wird, welche Daten weitergegeben werden, und sogar den physischen Standort durch IP-Analyse zu schätzen.

Dieser zweite Punkt ist kein Grund, den Standard abzulehnen – er ist ein Grund, genau festzulegen, welches Abrufmodell ein zukünftiger IDP standardmäßig verwenden sollte. AAMVA verlangt außerdem, dass die Wallet dem Inhaber die vollständige Kontrolle darüber gibt, welche Datenelemente weitergegeben werden – was für einen zukünftigen IDP weitaus besser geeignet ist als das ältere Modell „zeige das gesamte Dokument”.

Schicht 3 — ISO/IEC 18013-7: Internetpräsentation

Teil 5 löst das Problem der persönlichen Vorlage. Teil 7 erweitert dieses Modell auf die Fernnutzung.

ISO beschreibt 18013-7:2025 als Erweiterung von 18013-5 um die Internetpräsentation eines mDL an ein Lesegerät. Das Internet ist in dieser Architektur keine Nebensache, sondern ein expliziter Bestandteil des Standards.

Das europäische Handbuch für mobile Führerscheine behandelt die Internetpräsentation bereits als praktisch und nicht nur theoretisch und beschreibt Szenarien wie:

Check-in bei der Autovermietung, bei dem Nutzer ihren mDL entweder persönlich oder im Voraus aus der Ferne vorzeigen
Straßenkontrollen durch die Polizei
Ein allgemeines mDL-Nutzungsprofil, das auf ISO/IEC 18013-5 und 18013-7 aufbaut

Allerdings ist der aktuelle Leitfaden der AAMVA ehrlich hinsichtlich der Einschränkungen: Die mDL-Nutzung über das Internet ist sehr wünschenswert, aber einige unterstützende Standards reifen noch. Es gibt echte Lücken bei der aktuellen Wallet-Browser-Integration, und ohne eine Liste vertrauenswürdiger Lesegeräte hat die mdoc-Seite möglicherweise keine zuverlässige Möglichkeit, bestimmte Sicherheitseigenschaften zu bestätigen. Die Fernpräsentation ist real – und noch in der Entwicklung.

Trotz dieser Einschränkungen ist 18013-7 die erste ernsthafte Antwort auf ein Problem, das der Papier-IDP nie zu lösen versucht hat: die Vorlage von Fahrberechtigungen aus der Ferne, bevor die Person den Schalter oder Kontrollpunkt erreicht.

Schicht 4 — W3C VC Data Model 2.0: Die Semantikschicht

Das W3C Verifiable Credentials Data Model 2.0 ist kein Führerschein-Standard – und genau das macht es so bedeutsam.

Die Empfehlung definiert ein erweiterbares Datenmodell für verifizierbare Nachweise, erklärt, wie diese vor Veränderungen geschützt werden können, und beschreibt das Ökosystem anhand von drei Kernrollen: Aussteller, Inhaber und Verifizierer. Ein Führerschein wird als eines der zentralen Beispiele angeführt.

Für einen zukünftigen IDP liefert VC 2.0 ein allgemeines Vokabular für Aussagen, Präsentationen und verifizierbare Datenregister. W3C stellt klar, dass solche Register verschiedene Formen annehmen können, darunter:

Vertrauenswürdige Datenbanken
Staatliche Identitätsdatenbanken
Dezentralisierte Datenbanken
Verteilte Ledger

Das bricht die falsche Dichotomie zwischen einem reinen Blockchain-Ansatz und einem vollständig proprietären auf. Das Datenmodell ist breiter als beides.

VC 2.0 ist auch klar in Bezug auf selektive Offenlegung. W3C weist darauf hin, dass ein Führerschein möglicherweise mehr Daten enthält, als für einen bestimmten Anwendungsfall benötigt werden, und empfiehlt entweder die Aufteilung der Informationen in kleinere Einheiten oder die Verwendung von Mechanismen, die eine selektive Offenlegung ermöglichen. Für einen zukünftigen IDP ist dies keine optionale Datenschutzmaßnahme – es ist der Unterschied zwischen einem modernen Nachweis und einer digitalen Kopie einer Plastikkarte.

VC 2.0 ist jedoch kein vollständiger Ersatz für ISO 18013. W3C weist darauf hin, dass das Datenmodell kein traditionelles Zertifizierungsstellen-Vertrauenskettenmodell erfordert. In der Praxis ist VC 2.0 eine starke Semantikschicht, aber explizite Schichten für Vertrauensverteilung und Verifizierer-Governance müssen noch darauf aufgesetzt werden.

Schicht 5 — OpenID4VCI: Das Ausstellungsprotokoll

Ein zukünftiger IDP benötigt eine standardisierte Methode, um einen Nachweis von einem Aussteller in eine Wallet zu übertragen. Das ist die Rolle von OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0.

Die Spezifikation definiert eine OAuth-geschützte API zur Ausstellung verifizierbarer Nachweise und ist absichtlich formatunabhängig. Zu den unterstützten Nachweisformaten gehören:

ISO mdoc
SD-JWT VC
W3C VCDM-Nachweise

Es unterstützt außerdem die Inhaberbindung und spätere Präsentationen ohne weitere Beteiligung des Ausstellers. OpenID4VCI 1.0 wurde im September 2025 als finale Spezifikation verabschiedet.

Dies macht OpenID4VCI strategisch bedeutsam für ein zukünftiges IDP-Ökosystem. Anstatt für jede Jurisdiktion oder jeden Wallet-Anbieter individuelle Aussteller-zu-Wallet-Pipelines zu entwickeln, kann das Ökosystem ein gesteuertes Ausstellungsprofil auf der Grundlage eines standardisierten Ausstellungsrahmens definieren – und dabei weiterhin wählen, ob der resultierende Nachweis als mdoc, VC oder ein anderes unterstütztes Format kodiert wird. Diese Flexibilität ist eines der stärksten Argumente dafür, den zukünftigen IDP-Stack modular zu halten.

Schicht 6 — OpenID4VP: Das Anfrage- und Präsentationsprotokoll

Wenn OpenID4VCI den Nachweis in die Wallet überträgt, führt OpenID for Verifiable Presentations (OpenID4VP) ihn auf kontrollierte Weise wieder heraus.

Die Spezifikation definiert einen Mechanismus zum Anfordern und Präsentieren von Nachweisen. Als Basismechanismus werden HTTPS-Nachrichten und Weiterleitungen verwendet, aber es wird auch die Nutzung über die W3C Digital Credentials API anstelle von Weiterleitungsabläufen unterstützt. OpenID4VP 1.0 erhielt im Juli 2025 den Status einer finalen Spezifikation.

Das ist bedeutsam, weil es dem zukünftigen IDP-Stack eine webnativen Präsentationsschicht bietet, die Websites, Anwendungen und Online-Verifizierer direkt implementieren können. Mehrere aktuelle Entwicklungen untermauern dies:

Im August 2025 kündigte die OpenID Foundation eine formelle Sicherheitsanalyse von OpenID4VP in Verbindung mit der Digital Credentials API an, wobei im verifizierten Protokollmodell keine neuen Schwachstellen gefunden wurden.
Der aktuelle mDL-Entwurf des NIST baut sein Bedrohungsmodell auf der Anforderung und Präsentation von mDLs über OpenID4VP und die W3C Digital Credentials API auf, wobei FIDO CTAP eingesetzt wird, um Nähe zu gewährleisten und Phishing in relevanten Abläufen zu verhindern.

Die Webseite des Stacks und die mDL-Seite konvergieren. OpenID4VP sollte nicht als Konkurrent zu ISO 18013-7 verstanden werden – es ist die Webprotokollschicht, die Internetpräsentation in realen Browser-, Wallet- und Verifizierer-Umgebungen praktisch umsetzbar macht.

Schicht 7 — Vertrauensregister: Wo der Stack zum Ökosystem wird

Dies ist die Schicht, die viele Diskussionen überspringen – und die Schicht, die bestimmt, ob das gesamte System tatsächlich funktioniert.

Ein Verifizierer kann mit einem signierten Nachweis wenig anfangen, wenn er nicht drei Dinge weiß:

Welche Aussteller legitim sind
Welche öffentlichen Schlüssel aktuell sind
Ob die anfragende Partei selbst autorisiert ist

Auf der Ausstellerseite bietet der Digital Trust Service der AAMVA eine konkrete Antwort. Er bietet einen einzigen, sicheren und belastbaren Weg für vertrauende Parteien, die öffentlichen Schlüssel von Ausstellungsbehörden zu erhalten, verteilt über die Verified Issuer Certificate Authority List (VICAL). Der Leitfaden der AAMVA beschreibt die Rolle des VICAL-Anbieters in praktischen Begriffen: Öffentliche Schlüssel von legitimen Ausstellungsbehörden sammeln, überprüfen, ob diese Behörden ihre Schlüssel sicher verwalten, die Schlüssel zu einer einzigen VICAL zusammenfassen und an Verifizierer verteilen.

Auf der Verifiziererseite nähert sich Europa dem Vertrauensproblem aus einer anderen Richtung. Im EUDI-Architektur- und Referenzrahmen registrieren sich vertrauende Parteien, erhalten Zugangszertifikate und nutzen diese, um sich gegenüber Wallet-Anwendungen zu authentifizieren, wenn sie Attribute anfordern. Die Wallet überprüft dann die Zertifikatskette, prüft den Sperrstatus, legt dem Nutzer die Anfrage vor und gibt nur die genehmigten Attribute frei.

Das VC-Modell des W3C leistet hier ebenfalls einen Beitrag, indem es verifizierbare Datenregister als eigenständige Ökosystemrolle behandelt. Wie bereits erwähnt, können diese Register vertrauenswürdige Datenbanken, staatliche Identitätsdatenbanken, dezentralisierte Datenbanken oder verteilte Ledger sein. Ein zukünftiges IDP-Vertrauensregister muss nicht auf einer Blockchain aufgebaut sein. Es muss verwaltet, überprüfbar und maschinenlesbar sein.

Wenn ISO 18013 definiert, wie der Nachweis aussieht und übermittelt wird, entscheiden Vertrauensregister darüber, ob ihm jemand glauben sollte.

Ein zukünftiger IDP ist ein Stack, keine einzelne Spezifikation

Wie eine zukünftige IDP-Transaktion von Anfang bis Ende funktioniert

Hier ist der Stack in Betrieb, aufgeteilt in die vier wichtigsten Momente im Lebenszyklus eines Nachweises.

1. Ausstellung. Eine nationale Behörde – oder ein streng gesteuerter autorisierter Aussteller – überprüft den zugrundeliegenden Führerscheineintrag und stellt einen Nachweis in die Wallet des Inhabers aus. OpenID4VCI ist die heute praktikabelste Ausstellungsschicht, da sie bereits ISO mdoc, SD-JWT VC und W3C VCDM-Formate unterstützt. ISO 18013-5 selbst lässt die Einholung der Einwilligung und die Speicherung privater Schlüssel außerhalb des Anwendungsbereichs, weshalb Ausstellung und Wallet-Governance oberhalb der grundlegenden ISO-Transportschicht angesiedelt sein müssen.

2. Persönliche Vorlage. Bei einer Straßenkontrolle oder am Mietschalter präsentiert die Wallet den Nachweis über einen Nahbereichsablauf auf Basis von 18013-5. Das Lesegerät validiert Ursprung und Integrität mithilfe von Ausstellerschlüsseln, die aus einem Vertrauensregister bezogen wurden – anstatt Vertrauensentscheidungen eigenständig zu treffen. Der Inhaber genehmigt nur die Felder, die für die jeweilige Situation benötigt werden.

3. Fernpräsentation. Für Vor-Mietprüfungen oder andere Online-Prozesse fordert der Verifizierer einen minimalen Satz von Attributen über einen internetfähigen Ablauf mittels 18013-7 und/oder OpenID4VP an. Die Wallet zeigt an, welche Attribute angefordert werden, der Inhaber stimmt zu, und der Verifizierer erhält eine strukturierte Präsentation anstatt einen Scan oder ein PDF-Upload. Die aktuelle Architektur des NIST, die auf OpenID4VP und der Digital Credentials API aufbaut, zeigt, dass dies heute ein praktisch umsetzbarer technischer Weg ist.

4. Vertrauen und Verifiziererautorisierung. Die Wallet vertraut nicht blind jedem Anforderer. Ein reifes Ökosystem authentifiziert die vertrauende Partei, validiert Zertifikatsketten, prüft den Sperrstatus und gibt dem Nutzer Einblick, wer welche Daten anfordert. Das EUDI-Modell ist hier besonders stark, da es die Registrierung von Verifizierern und Zugangszertifikate als wesentliche Bestandteile des Systems und nicht als optionale Ergänzungen behandelt.

Dieser vollständige Ablauf ist genau der Grund, warum ein zukünftiger IDP ein Stack sein muss. Keine einzelne Schicht kann ihn allein bereitstellen. Nicht ISO allein. Nicht VC allein. Nicht OpenID allein. Und schon gar nicht ein PDF, das einem Formular beigefügt ist.

Was dem zukünftigen IDP-Stack noch fehlt

Das schwierigste verbleibende Problem ist nicht mehr die Entwicklung neuer Kryptografie – sondern die Erreichung gesteuerter Interoperabilität.

Betrachten wir den aktuellen Stand des Ökosystems:

NIST hat die aktuelle Normenlandschaft als sich in verschiedenen Bereichen entwickelnd beschrieben.
AAMVA hat einen regionalen Vertrauensdienst für Nordamerika aufgebaut.
Europa baut zertifikatsbasiertes Relying-Party-Vertrauen in seine Wallet-Architektur ein.
OpenID hat Ausstellungs- und Präsentationsspezifikationen finalisiert und baut die Konformitätsinfrastruktur aus.

Dies sind noch ökosystemspezifische Antworten. Es gibt noch keine einzige globale grenzüberschreitende Vertrauensschicht für Fahrausweise. Die verbleibende Arbeit besteht darin, Folgendes festzulegen:

Welche Teile des Stacks verpflichtend sind
Welche Nachweisformate akzeptabel sind
Wie das Vertrauen in Aussteller und Verifizierer verteilt wird
Wie die Konformität geprüft wird
Wie die grenzüberschreitende Anerkennung ohne Beeinträchtigung des Datenschutzes geregelt wird

Fazit: Der zukünftige IDP ist ein Stack, kein Dokument

Ein zukünftiger IDP wird nicht entstehen, weil eine Normungsorganisation ein einziges Dokument verfasst. Er wird entstehen, wenn ein kohärenter Stack definiert, gesteuert und über Jurisdiktionen hinweg eingeführt wird. Dieser Stack hat bereits erkennbare Schichten: