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.

Standaarden · Mobiel rijbewijs (mDL)

Mobiele rijbewijs QR-codes: ISO/IEC 18013-5

Wanneer een barkeeper, TSA-medewerker of autoverhuurmedewerker de QR op de rijbewijsapp van uw telefoon scant, is die QR niet het rijbewijs. Het is een handshake. De eigenlijke attributen reizen pas nadat hun verificateur om specifieke velden vraagt en u de vrijgave op uw telefoon goedkeurt. Goed gedaan lekt een mDL veel minder dan een plastic kaart. Slecht gedaan (vijandige verificateur, blinde goedkeuring) lekt het evenveel of meer. Zo herkent u het verschil.

Inspecteer een mDL QR → Alle standaarden →

Wat is de standaard

ISO/IEC 18013-5:2021, Persoonsidentificatie, ISO-conform rijbewijs, Deel 5: Mobiele rijbewijsapplicatie (mDL). De internationale standaard die specificeert hoe digitale rijbewijzen worden uitgegeven, opgeslagen, overgedragen aan een verificateur en offline geverifieerd. Het QR-code-oppervlak (het deel dat de meeste mensen zien) is sectie 8.2 "Device retrieval, QR code engagement". Een aanvullende standaard, ISO/IEC 18013-7, dekt online ophaling (verificateur vraagt de uitgever rechtstreeks met toestemming van de houder).

Adoptie is al goed op gang: een dozijn Amerikaanse staten hebben productie-uitgevende of pilot mDL's in Apple Wallet en Google Wallet; Californië's mDL is algemeen beschikbaar; de TSA accepteert mDL's bij beveiliging op de meeste grote Amerikaanse luchthavens; de EU integreert zijn variant in de EUDI Wallet onder eIDAS 2.0 (verordening van kracht eind 2024, wallets verwacht 2026-2027). De standaard is ook de basis voor ISO/IEC 23220 (algemeen mobiel-referentiekader, ook voor dingen buiten rijbewijzen).

Wat er eigenlijk in de QR zit

De mDL QR codeert een DeviceEngagement CBOR-structuur. CBOR (Concise Binary Object Representation, RFC 8949) is een compact binair alternatief voor JSON. De gedecodeerde structuur ziet er globaal zo uit:

{
  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...}
}

Sleutelvelden, gedecodeerd:

Versie

Altijd "1.0" voor huidige implementaties. Toekomstige versies kunnen dit verhogen.

Cipher suite

Momenteel altijd 1: ECDH-sleutelovereenkomst op P-256, AES-GCM sessie-encryptie. Cipher suite 2 is gereserveerd voor brainpoolP320r1 (EU-gebruiksgevallen).

eDeviceKey

Een efemere EC publieke sleutel die per sessie door de wallet wordt gegenereerd. Gebruikt door de verificateur om een versleutelde sessie op te zetten. Vernietigd na de transactie. Onze scanner toont u de lengte van dit veld maar echoot de sleutelbytes nooit — ze zijn efemeer en alleen zinvol voor de lopende verificateursessie.

Overdrachtsmethoden

De wallet vertelt de verificateur welke kanalen hij bereid is te gebruiken voor de eigenlijke attribuutoverdracht: NFC (tappen), Bluetooth LE of Wi-Fi Aware (peer-to-peer Wi-Fi zonder toegangspunt). De meeste mDL's bieden BLE en NFC; Wi-Fi Aware is platformgebonden.

Server ophaling (optioneel)

Als aanwezig ondersteunt de wallet de 18013-7-modus: de verificateur kan attributen opvragen bij de online API van de uitgever in plaats van rechtstreeks bij de wallet. De QR bevat de URL van de uitgever. Onze scanner extraheert dit en toont u welke instantie de opvraging zou ontvangen.

Hoe verschilt dit van de AAMVA PDF417 op de plastic kaart?

Het is een andere categorie referentie. De AAMVA PDF417-streepjescode op de achterkant van een Amerikaans plastic rijbewijs bevat elk attribuut op de kaart in platte tekst — naam, adres, geboortedatum, rijbewijsnummer, lengte, gewicht, oogkleur, beperkingen, orgaandonorvlag. Elke scanner kan alles lezen. De kaart is een "alles of niets"-referentie: u overhandigt hem en onthult alles, of niet.

Een mDL keert dat om. De QR bevat geen attributen, alleen een handshake. De verificateur moet specifieke attributen opvragen (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges, etc.), de wallet toont u het verzoek en alleen de attributen die u goedkeurt worden overgedragen. De overdracht is ook cryptografisch ondertekend door de uitgevende instantie (uw staat-DMV), zodat de verificateur kan bevestigen dat de attributen echt zijn zonder thuis te bellen — offline verificatie werkt.

Dat is waarom mensen die om privacy geven de voorkeur geven aan mDL's, ook al is de standaard complexer: het maakt openbaarmaking mogelijk die is afgestemd op de transactie. Een uitsmijter heeft uw adres niet nodig; een TSA-medewerker heeft uw orgaandonorstatus niet nodig; een 7-Eleven-medewerker heeft uw rijbewijsnummer niet nodig.

Selectieve openbaarmaking: het eigenlijke punt

De mDL-standaard definieert een reeks afgeleide attributen waarmee de verificateur een ja/nee-vraag kan stellen in plaats van een ruwe waarde te ontvangen. De grote:

age_over_18, age_over_21, age_over_65, voor leeftijdsgecontroleerde aankopen zonder geboortedatum te onthullen.
resident_state, voor vragen als "bent u staatsinwoner?" zonder adres te onthullen.
driving_privileges, klasse van gehouden rijbewijs, beperkingen; voor autoverhuur.

Een goed ontworpen verificateur-app voor een bar vraagt alleen age_over_21. De wallet toont "Bar XYZ wil weten of u ouder bent dan 21". U tikt op Goedkeuren, een enkel ondertekende boolean ("true") gaat terug. De app van de bar verifieert de handtekening aan de hand van de gepubliceerde mDL-vertrouwenswortel van uw staat. Klaar. Geen geboortedatum, geen naam, geen rijbewijsnummer, geen foto. Vergeleken met het overhandigen van de plastic kaart is dit een enorme privacyverbetering.

Vijandige verificateurs: het nieuwe dreigingsmodel

Het dreigingsmodel van de plastic kaart was eenvoudig: hem kwijtraken, kopiëren of over de schouder laten afkijken. Het dreigingsmodel van de mDL is anders. Het formaat is sterk; de cryptografie is solide; het risico verschuift naar de verificateur-app aan de andere kant van de transactie.

Iedereen kan een verificateur-app bouwen. Er is geen centrale licentie-instantie. Een bar kan een kant-en-klare verificateur draaien die is geconfigureerd om te vragen naar volledige geboortedatum, volledige naam en foto terwijl hij alleen age_over_21 nodig heeft. Een autoverhuurmedewerker vraagt misschien alles "voor het dossier". Een winkelmedewerker vraagt misschien om het adres. Niets hiervan is technisch verboden door de standaard — de standaard zegt alleen dat de wallet de houder moet tonen wat er wordt gevraagd en expliciete goedkeuring moet vereisen.

De verdediging ligt dus bij de houder: lees de verzoekprompt. Als de verificateur meer vraagt dan de transactie nodig heeft, weiger dan. Sommige wallets waarschuwen wanneer de verificateur niet op een bekende vertrouwenslijst staat; ISO/IEC 18013-5 ondersteunt verificateurverificatie via certificaten, maar de vertrouwenslijstinfrastructuur is nog volwassen aan het worden (per-staat lijsten in de VS; EU-vertrouwenslijst onder eIDAS 2.0).

De verificateur ziet uw eDeviceKey, de cipher suite en welke overdrachtsmethoden u ondersteunt — dat is alles. Ze krijgen geen attributen uit de QR alleen. Dus een QR scannen van een sticker of iemands scherm en weglopen geeft een aanvaller niets bruikbaars. De attributen reizen alleen binnenin de versleutelde sessie na de handshake.

Wat onze scanner u toont

Sleep een mDL DeviceEngagement QR (afbeelding, plakken of camera) in onze scanner. Het vonnis toont:

Standaard, ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
Versie, doorgaans 1.0.
Cipher suite, de genoemde cipher suite (P-256 / brainpool / etc.).
Overdrachtsmethoden, welke kanalen de wallet aanbiedt (NFC, BLE, Wi-Fi Aware).
Server-ophaalhost, als de wallet de 18013-7-modus aanbiedt, welke uitgever-URL attribuutverzoeken zou afhandelen.
eDeviceKey-lengte, bevestigt dat de sleutel aanwezig en goed gevormd is, zonder de bytes te echoon.

We decoderen GEEN attributen — er zitten geen attributen in de QR, by design. De eigenlijke rijbewijsgegevens zouden versleuteld reizen via de gekozen overdrachtsmethode naar een echte verificateur.

Decodering vindt plaats in uw browser; alleen de structurele metadata bereikt onze server voor de veiligheidsclassificatie.

Voordat u een verificateurverzoek goedkeurt

Lees de verzoekprompt. Uw wallet is verplicht door de standaard u de volledige lijst van gevraagde attributen te tonen. Lees die.
Komt het verzoek overeen met de transactie? Een barkeeper die om de volledige geboortedatum vraagt in plaats van age_over_21 = weigeren of navragen. Een autoverhuurmedewerker die vraagt naar orgaandonorstatus = weigeren.
Staat de verificateur op een vertrouwenslijst? Sommige wallets tonen een vinkje voor bekende verificateurs (uitgegeven certificaten van de vertrouwenswortel van uw staat-DMV). Onbekende verificateurs moeten u aan het denken zetten.
Online ophaling (18013-7) is krachtiger en ingrijpender. Als de wallet vraagt of u de verificateur uw staat-DMV rechtstreeks wilt laten opvragen, wordt daarbij een auditspoor bij de DMV aangemaakt. Prima voor sommige transacties (TSA, officiële identiteitscontroles), niet nodig voor andere (bier kopen).
U kunt altijd nee zeggen. Het hele punt van selectieve openbaarmaking is dat u bepaalt wat uw telefoon verlaat. Als een verificateur geen verminderde openbaarmaking accepteert, kunt u terugvallen op de plastic kaart of de transactie afbreken.

Gerelateerd

AAMVA rijbewijs PDF417, de plastic kaart-streepjescode die dit formaat vervangt.
FIDO2 passkey-QR, een andere cross-device handshake-QR.
QR-oplichting om op te letten in 2026
Alle QR-standaarden die wij controleren
Volledige dekkingslijst

Een mDL DeviceEngagement QR inspecteren

Sleep de QR erin (afbeelding, plakken of camera). Het vonnis toont versie, cipher suite, overdrachtsmethoden en eventuele optionele server-ophaal-URL. Geen attributen — die reizen alleen binnenin de versleutelde post-handshake sessie naar een echte verificateur.

Scanner openen →