What is a mobile driver license (mDL)?

An mDL is the digital equivalent of a plastic driver's license, issued by your state DMV (or national authority) and stored in a wallet app on your phone. It is governed by ISO/IEC 18013-5, an international standard that specifies how attributes are signed, transferred, and verified. US states including Arizona, Colorado, Maryland, Georgia, Iowa, Mississippi, Ohio, Utah, Virginia, and a growing list are issuing mDLs; California has it in production; the EU is rolling out its own variant under EUDI Wallet (eIDAS 2.0).

What's encoded in the QR?

Under ISO/IEC 18013-5 section 8.2, the QR carries a CBOR-encoded DeviceEngagement structure. That structure declares the wallet's ephemeral public key (eDeviceKey), the cipher suite used (currently P-256 / ECDH-ES), and the list of transfer methods the wallet supports (NFC, Bluetooth LE, Wi-Fi Aware). It does NOT carry the actual license attributes (name, DOB, license number, photo). Those are sent over the chosen transfer channel AFTER the verifier requests specific attributes and the holder approves.

How is this different from the PDF417 barcode on the back of a plastic license?

Completely different. The PDF417 barcode on plastic AAMVA cards encodes every attribute on the card in plaintext, name, address, DOB, license number, restrictions, donor status, and any scanner can read all of it. An mDL QR is just a handshake. The verifier has to ASK for specific attributes (e.g. 'over 21? yes/no') and the holder has to APPROVE the release on their phone. The wallet can answer 'over 21 = yes' without disclosing the actual date of birth, that's called selective disclosure.

What does selective disclosure mean in practice?

A bartender scanning your mDL needs to know one thing: are you of legal drinking age? With a plastic license, you hand over the card and they see your full address, DOB, and license number. With an mDL the bartender's verifier app requests only the age_over_21 attribute. Your phone shows you that request, you approve, and a signed boolean is transferred. Nothing else. ISO/IEC 18013-5 supports a long list of such derived attributes (age_over_18, age_over_21, age_over_65), plus full attributes when actually needed (a car rental probably needs full name and license number; a bouncer doesn't).

What's a hostile verifier and how do I spot one?

A hostile verifier is a verifier app that asks for more attributes than the transaction needs, e.g. a bar asking for full address, license number, and photo when it only needs age_over_21. This is a real risk because verifier apps are not centrally regulated; anyone can build one. The mDL standard requires the wallet to display the full list of requested attributes before the holder approves, so the defense is reading that list. If the bar wants your home address to pour a beer, decline. ISO/IEC 18013-5 also supports verifier authentication (the verifier signs its request with a certificate from a trust list), so a scrupulous wallet warns when the verifier isn't on a known trust list. The list of recognized verifiers is jurisdiction-specific and still maturing.

Standards · Mobiler Führerschein (mDL)

QR-Codes für mobile Führerscheine: ISO/IEC 18013-5

Wenn ein Barkeeper, ein TSA-Mitarbeiter oder ein Autovermieter den QR in der Führerschein-App Ihres Telefons scannt, ist dieser QR nicht der Führerschein. Er ist ein Handshake. Die eigentlichen Attribute werden erst übertragen, nachdem der Prüfer bestimmte Felder angefordert hat und Sie die Freigabe auf Ihrem Telefon bestätigen. Richtig eingesetzt gibt ein mDL weit weniger preis als eine Plastikkarte. Falsch eingesetzt (feindlicher Prüfer, pauschale Freigabe) gibt er genauso viel preis oder mehr. So erkennen Sie den Unterschied.

mDL QR prüfen → Alle Standards →

Was ist der Standard

ISO/IEC 18013-5:2021, Persönliche Identifikation, ISO-konformer Führerschein, Teil 5: Mobile Driving Licence (mDL)-Anwendung.

Die Einführung ist weit fortgeschritten: Ein Dutzend US-Bundesstaaten geben mDLs produktiv oder im Pilotbetrieb in Apple Wallet und Google Wallet aus; Kaliforniens mDL ist allgemein verfügbar; die TSA akzeptiert mDLs an den Sicherheitskontrollen der meisten großen US-Flughäfen; die EU integriert ihre Variante im Rahmen von eIDAS 2.0 in die EUDI Wallet (Verordnung in Kraft seit Ende 2024, Wallets fällig 2026–2027). Der Standard bildet auch die Grundlage für ISO/IEC 23220 (allgemeines Framework für mobile Berechtigungsnachweise, das über Führerscheine hinausgeht).

Was steckt tatsächlich im QR

Der mDL QR kodiert ein DeviceEngagement-Objekt.

{
  0: "1.0",                         // version
  1: [1, 2, [eDeviceKey bytes]],    // security: cipher suite 1, EC P-256 key
  2: [                              // device retrieval methods
    [1, 1, {...NFC options...}],
    [2, 1, {...BLE options...}],
    [3, 1, {...Wi-Fi Aware options...}]
  ],
  3: {...optional server retrieval...}
}

Schlüsselfelder, dekodiert:

Version

Immer "1.0" für aktuelle Deployments. Künftige Revisionen können dies ändern.

Cipher-Suite

Derzeit immer 1.

eDeviceKey

Ein ephemerer Schlüssel.

Übertragungsmethoden

Die Wallet teilt dem Verifier mit, über welche Kanäle die eigentliche Attributübertragung stattfinden soll: NFC (Tap), Bluetooth LE oder Wi-Fi Aware (Peer-to-Peer-Wi-Fi ohne Access Point). Die meisten mDLs unterstützen BLE und NFC; Wi-Fi Aware ist plattformabhängig.

Server-Abfrage (optional)

Wenn vorhanden, unterstützt die Wallet den Modus nach 18013-7: Der Verifier kann Attribute über die Online-API des Ausstellers anfordern, anstatt direkt von der Wallet. Der QR enthält die URL des Ausstellers. Unser Scanner extrahiert diese und zeigt, welche Behörde die Abfrage erhalten würde.

Worin unterscheidet sich das vom AAMVA PDF417 auf der Plastikkarte?

Es handelt sich um eine andere Art von Ausweis. Der AAMVA-PDF417-Barcode auf der Rückseite eines US-Plastikführerscheins enthält alle Angaben der Karte im Klartext: Name, Adresse, Geburtsdatum, Führerscheinnummer, Größe, Gewicht, Augenfarbe, Beschränkungen, Organspenderstatus. Jeder Scanner kann alles lesen. Die Karte ist ein „Alles-oder-nichts“-Ausweis: Entweder geben Sie sie heraus und legen alles offen, oder Sie tun es nicht.

Ein mDL funktioniert anders. Der QR enthält keine Attribute, nur einen Handshake. Der Verifier muss bestimmte Attribute anfordern (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges usw.), die Wallet zeigt Ihnen die Anfrage, und nur die von Ihnen genehmigten Attribute werden übertragen. Die Übertragung ist außerdem kryptografisch von der ausstellenden Behörde signiert.

Deshalb bevorzugen datenschutzbewusste Nutzer mDLs, auch wenn der Standard komplexer ist: Er ermöglicht eine auf die jeweilige Transaktion begrenzte Offenlegung. Ein Türsteher braucht Ihre Adresse nicht; ein TSA-Beamter braucht Ihren Organspenderstatus nicht; ein Kassierer braucht Ihre Führerscheinnummer nicht.

Selektive Offenlegung: der eigentliche Vorteil

Der mDL-Standard definiert eine Reihe von abgeleiteten Attributen.

age_over_18, age_over_21, age_over_65, für altersgebundene Käufe ohne Angabe des Geburtsdatums.
resident_state, für die Frage „Sind Sie Einwohner dieses Bundesstaates?" ohne Preisgabe der Adresse.
driving_privileges, Führerscheinklasse und Einschränkungen; für Autovermietungen.

Eine sorgfältig gestaltete Verifier-App für eine Bar fragt nur age_over_21 ab. Die Wallet zeigt: „Bar XYZ möchte wissen, ob Sie über 21 sind." Sie tippen auf Genehmigen, ein einzelner signierter Boolean ("true") wird zurückgesendet. Die App der Bar prüft die Signatur gegen den veröffentlichten mDL-Trust-Anker Ihres Bundesstaates. Fertig. Kein Geburtsdatum, kein Name, keine Führerscheinnummer, kein Foto. Verglichen mit dem Vorzeigen der Plastikkarte ist das ein erheblicher Datenschutzgewinn.

Feindliche Verifier: das neue Bedrohungsmodell

Das Bedrohungsmodell der Plastikkarte war einfach: verlieren, kopieren, ausspionieren. Das mDL-Bedrohungsmodell ist anders. Das Format ist solide; die Kryptografie ist belastbar; das Risiko verlagert sich auf die Verifier-App auf der anderen Seite der Transaktion.

Jeder kann eine Verifier-App bauen. Es gibt keine zentrale Zulassungsbehörde. So könnte eine Bar eine handelsübliche Verifier-App einsetzen, die nach vollem Geburtsdatum, vollem Namen und Foto fragt, obwohl sie nur age_over_21 benötigt. Ein Autovermieter könnte alles „für die Akte" anfordern. Ein Kassierer könnte nach der Adresse fragen. All das ist technisch nicht durch den Standard verboten – er schreibt lediglich vor, dass die Wallet dem Inhaber anzeigen muss, was angefordert wird, und eine explizite Genehmigung erfordert.

Die Verteidigung liegt daher beim Inhaber: Lesen Sie die Anforderungsanzeige.

Wichtig zu wissen: Der Verifier sieht Ihren eDeviceKey, die Cipher-Suite und welche Übertragungsmethoden Sie unterstützen – das ist alles.

Was unser Scanner anzeigt

Laden Sie einen mDL DeviceEngagement QR (Bild, Einfügen oder Kamera) in unseren Scanner. Das Ergebnis zeigt:

Standard
Version
Cipher-Suite
Übertragungsmethoden
Server-Abfrage-Host
eDeviceKey-Länge

Wir dekodieren keine Attribute – der QR enthält per Design keine Attribute. Die eigentlichen Führerscheindaten würden verschlüsselt über die gewählte Übertragungsmethode an einen echten Verifier übermittelt.

Die Dekodierung erfolgt in Ihrem Browser; nur die strukturellen Metadaten erreichen unseren Server für die Sicherheitsklassifizierung.

Bevor Sie eine Verifier-Anfrage genehmigen

Lesen Sie die Anforderungsanzeige.
Entspricht die Anfrage der Transaktion? Wenn ein Barkeeper das vollständige Geburtsdatum statt age_over_21 verlangt = ablehnen oder nachfragen. Wenn ein Autovermietungsmitarbeiter den Organspenderstatus abfragt = ablehnen.
Ist der Verifier auf einer Vertrauensliste?
Online-Abfrage (18013-7) ist leistungsstärker und stärker in die Privatsphäre eingreifend.
Sie können immer ablehnen.

Einen mDL DeviceEngagement QR prüfen

Laden Sie den QR (Bild, Einfügen oder Kamera). Das Ergebnis zeigt Version, Cipher-Suite, Übertragungsmethoden und eine optionale Server-Abfrage-URL. Keine Attribute – diese werden ausschließlich verschlüsselt in der Post-Handshake-Sitzung an einen echten Verifier übertragen.

Scanner öffnen →