Mobile driver license QR codes: ISO/IEC 18013-5

What's the standard

ISO/IEC 18013-5:2021 — Personal identification, ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application. The international standard that specifies how digital driver licenses are issued, stored, transferred to a verifier, and verified offline. The QR-code surface (the part most people see) is section 8.2 "Device retrieval — QR code engagement". A companion standard, ISO/IEC 18013-7, covers online retrieval (verifier asks the issuer directly with the holder's consent).

Adoption is well underway: a dozen US states have production-issuing or pilot mDLs in Apple Wallet and Google Wallet; California's mDL is in general availability; the TSA accepts mDLs at security at most major US airports; the EU is rolling its variant into the EUDI Wallet under eIDAS 2.0 (regulation effective late 2024, wallets due 2026-2027). The standard is also the basis for ISO/IEC 23220 (general mobile-credential framework, covering things beyond driver licenses).

What's actually inside the QR

The mDL QR encodes a DeviceEngagement CBOR structure. CBOR (Concise Binary Object Representation, RFC 8949) is a compact binary alternative to JSON. The decoded structure looks roughly like:

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

Key fields, decoded:

How is this different from the AAMVA PDF417 on the plastic card?

It's a different category of credential. The AAMVA PDF417 barcode on the back of a US plastic license carries every attribute on the card in plaintext — name, address, DOB, license number, height, weight, eye colour, restrictions, organ-donor flag. Any scanner can read all of it. The card is an "all or nothing" credential: you either hand it over and disclose everything, or you don't.

An mDL flips that. The QR carries no attributes — just a handshake. The verifier has to ask for specific attributes (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges, etc.), the wallet shows you the request, and only the attributes you approve are transferred. The transfer is also cryptographically signed by the issuing authority (your state DMV), so the verifier can confirm the attributes are real without phoning home — offline verification works.

This is why people who care about privacy prefer mDLs even though the standard is more complex: it enables disclosure scoped to the transaction. A bouncer doesn't need your address; a TSA officer doesn't need your organ-donor status; a 7-Eleven clerk doesn't need your license number.

Selective disclosure: the actual point

The mDL standard defines a set of derived attributes that let the verifier ask a yes/no question instead of getting a raw value. The big ones:

• age_over_18, age_over_21, age_over_65 — for age-gated purchases without disclosing DOB.
• resident_state — for "are you a state resident?" questions without disclosing address.
• driving_privileges — class of license held, restrictions; for car rental.

A well-designed verifier app for a bar asks only age_over_21. The wallet shows "Bar XYZ wants to know if you are over 21." You tap Approve, a single signed boolean ("true") goes back. The bar's app verifies the signature against your state's published mDL trust root. Done. No DOB, no name, no license number, no photo. Compared to handing over the plastic card, this is a massive privacy upgrade.

Hostile verifiers: the new threat model

The plastic-card threat model was simple: lose it, get it copied, get it shoulder-surfed. The mDL threat model is different. The format is strong; the cryptography is sound; the risk shifts to the verifier app on the other side of the transaction.

Anyone can build a verifier app. There's no central licensing authority. So a bar might run an off-the-shelf verifier configured to ask for full DOB, full name, and photo even though it only needs age_over_21. A car-rental clerk might ask for everything "for the file." A retail clerk might ask for address. None of these are technically prohibited by the standard — the standard just says the wallet has to show the holder what's being requested and require explicit approval.

So the defense is on the holder side: read the request prompt. If the verifier is asking for more than the transaction needs, decline. Some wallets warn when the verifier isn't on a known trust list; ISO/IEC 18013-5 supports verifier authentication via certificates, but the trust-list infrastructure is still maturing (per-state lists in the US; EU trust list under eIDAS 2.0).

Also worth knowing: the verifier sees your eDeviceKey, the cipher suite, and which transfer methods you support — that's it. They don't get attributes from the QR alone. So scanning a QR off a sticker or someone's screen and walking away with it gives an attacker nothing useful. The attributes only travel inside the encrypted session after handshake.

What our scanner shows you

Drop an mDL DeviceEngagement QR (image, paste, or camera) into our scanner. The verdict shows:

• Standard — ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
• Version — usually 1.0.
• Cipher suite — the named cipher suite (P-256 / brainpool / etc.).
• Transfer methods — which channels the wallet offers (NFC, BLE, Wi-Fi Aware).
• Server retrieval host — if the wallet offers 18013-7 mode, which issuer URL would handle attribute requests.
• eDeviceKey length — confirms the key is present and well-formed, without echoing the bytes.

We do NOT decode any attributes — there are no attributes in the QR, by design. The actual license data would travel encrypted over the chosen transfer method to a real verifier.

Decoding happens in your browser; only the structural metadata reaches our server for the safety classification.

Before you approve a verifier request

• Read the request prompt. Your wallet is required by the standard to show you the full list of requested attributes. Read it.
• Does the request match the transaction? Bartender asking for full DOB instead of age_over_21 = decline or ask why. Car-rental clerk asking for organ-donor status = decline.
• Is the verifier on a trust list? Some wallets show a checkmark for known verifiers (issued certificates from your state DMV's trust root). Unknown verifiers should give you pause.
• Online retrieval (18013-7) is more powerful and more invasive. If the wallet asks whether to let the verifier query your state DMV directly, that creates an audit trail at the DMV. Fine for some transactions (TSA, official ID checks), unnecessary for others (buying beer).
• You can always say no. The whole point of selective disclosure is that you control what leaves your phone. If a verifier won't accept a reduced disclosure, you can fall back to the plastic card or walk away from the transaction.

Related

• AAMVA driver license PDF417 — the plastic-card barcode this format replaces.
• FIDO2 passkey QR — another cross-device handshake QR.
• QR scams to watch for in 2026
• All QR standards we check
• Full coverage list