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.

Standardit · Mobiili ajokortti (mDL)

Mobiili ajokortti QR-koodit: ISO/IEC 18013-5

Kun baarimikko, TSA-virkailija tai autonvuokrauksen toimihenkilö skannaa QR-koodin puhelimesi ajokorttisovelluksesta, tuo QR-koodi ei ole ajokortti. Se on kättely. Varsinaiset attribuutit siirtyvät vasta sen jälkeen, kun heidän vahvistajansa pyytää tiettyjä kenttiä ja sinä hyväksyt julkistamisen puhelimessasi. Oikein tehtynä mDL paljastaa paljon vähemmän kuin fyysinen kortti. Väärin tehtynä (vihamielinen vahvistaja, kaikenkattava hyväksyntä) se paljastaa saman verran tai enemmän. Näin voit erottaa nämä toisistaan.

Tutki mDL-QR-koodi → Kaikki standardit →

Mikä standardi on kyseessä

ISO/IEC 18013-5:2021, Henkilöllisyys, ISO-yhteensopiva ajokortti, Osa 5: Mobiili ajokortti (mDL) -sovellus. Kansainvälinen standardi, joka määrittelee, miten digitaaliset ajokortit myönnetään, tallennetaan, siirretään vahvistajalle ja vahvistetaan offline-tilassa. QR-koodipinta (osa, jonka useimmat ihmiset näkevät) on kohta 8.2 "Laitehaku, QR-koodiliitosmoduuli". Kumppanistandardi ISO/IEC 18013-7 kattaa verkkohaun (vahvistaja kysyy myöntäjältä suoraan haltijan suostumuksella).

Käyttöönotto on pitkällä: tusina Yhdysvaltain osavaltioita on tuotanto- tai pilotti-mDL:iä Apple Walletissa ja Google Walletissa; Kalifornian mDL on yleisessä saatavuudessa; TSA hyväksyy mDL:iä turvatarkastuksissa useimmilla suurimmilla Yhdysvaltain lentokentillä; EU vie varianttinsa EUDI Walletiin eIDAS 2.0:n alla (asetus astui voimaan 2024, lompakot erääntyvät 2026–2027). Standardi on myös ISO/IEC 23220:n perusta (yleinen mobiilitunnisteviitekehys, joka kattaa muutakin kuin ajokortit).

Mitä QR-koodin sisällä oikeasti on

mDL-QR-koodi koodaa DeviceEngagement-CBOR-rakenteen. CBOR (Concise Binary Object Representation, RFC 8949) on kompakti binäärivaihtoehto JSON:lle. Purettu rakenne näyttää suunnilleen tältä:

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

Avainkentät purettuna:

Versio

Aina "1.0" nykyisissä käyttöönotoissa. Tulevat revisiot voivat muuttaa tätä.

Salausalgoritmijoukko

Toistaiseksi aina 1: ECDH-avainsopimus P-256:lla, AES-GCM-istuntosalaus. Cipher suite 2 on varattu brainpoolP320r1:lle (EU-käyttötapaukset).

eDeviceKey

Lompakko luo istuntokohtaisesti väliaikaisen EC-julkisen avaimen. Vahvistaja käyttää sitä salatun istunnon muodostamiseen. Poistetaan transaktion jälkeen. Skannerimme näyttää sinulle tämän kentän pituuden, mutta ei koskaan toista avaintavuja – ne ovat väliaikaisia ja merkityksellisiä vain meneillään olevan vahvistajaistunnon kannalta.

Siirtomenetelmät

Lompakko kertoo vahvistajalle, mitkä kanavat se on valmis käyttämään varsinaiseen attribuutinsiirtoon: NFC (napauta), Bluetooth LE tai Wi-Fi Aware (vertaisverkko Wi-Fi ilman tukiasemaa). Useimmat mDL:t tarjoavat BLE:n ja NFC:n; Wi-Fi Aware on alustarajoitettu.

Palvelinhaku (valinnainen)

Jos saatavilla, lompakko tukee 18013-7-tilaa: vahvistaja voi pyytää attribuutteja myöntäjän verkko-API:sta suoraan lompakosta hakemisen sijaan. QR-koodi sisältää myöntäjän URL:n. Skannerimme poimii tämän ja näyttää, mikä taho vastaanottaisi haun.

Miten tämä eroaa fyysisen kortin AAMVA PDF417:stä?

Kyseessä on eri tunnisteluokka. AAMVA PDF417 -viivakoodi yhdysvaltalaisen fyysisen ajokortin takapuolella sisältää kaikki kortin attribuutit selkokielisenä – nimi, osoite, syntymäpäivä, korttinumero, pituus, paino, silmienväri, rajoitukset, elinluovuttajalippu. Mikä tahansa skanneri voi lukea kaiken. Kortti on "kaikki tai ei mitään" -tunniste: joko luovutat sen ja paljastat kaiken tai et.

mDL kääntää tämän. QR-koodi ei sisällä attribuutteja – vain kättelyn. Vahvistajan on pyydettävä tiettyjä attribuutteja (given_name, family_name, birth_date, age_over_21, portrait, document_number, driving_privileges jne.), lompakko näyttää sinulle pyynnön, ja vain hyväksymäsi attribuutit siirretään. Siirto on myös myöntävän viranomaisen (osavaltiosi DMV) kryptografisesti allekirjoittama, joten vahvistaja voi vahvistaa attribuuttien aitouden soittamatta kotiin – offline-vahvistus toimii.

Siksi tietosuojastaan huolta pitävät suosivat mDL:iä, vaikka standardi on monimutkaisempi: se mahdollistaa transaktion laajuisen luovuttamisen. Ovivartija ei tarvitse osoitettasi; TSA-virkailija ei tarvitse elinluovuttajastatustasi; 7-Eleven-virkailija ei tarvitse korttinumeroasi.

Valikoiva luovuttaminen: varsinainen tarkoitus

mDL-standardi määrittelee joukon johdettuja attribuutteja, joiden avulla vahvistaja voi esittää kyllä/ei-kysymyksen raa'an arvon sijaan. Tärkeimmät:

age_over_18, age_over_21, age_over_65 – ikärajoitetuille ostoille paljastamatta syntymäpäivää.
resident_state – "oletko osavaltion asukas?" -kysymyksiin paljastamatta osoitetta.
driving_privileges – ajokortin luokka ja rajoitukset; autonvuokraukseen.

Hyvin suunniteltu vahvistajasovellus baariin pyytää vain age_over_21. Lompakko näyttää "Baari XYZ haluaa tietää, oletko yli 21." Napauta Hyväksy, ja yksi allekirjoitettu totuusarvo ("tosi") palautetaan. Baarin sovellus vahvistaa allekirjoituksen osavaltiosi julkaistua mDL-luottamusjuurta vasten. Valmis. Ei syntymäpäivää, ei nimeä, ei korttinumeroa, ei kuvaa. Verrattuna fyysisen kortin luovuttamiseen tämä on massiivinen tietosuojaparannus.

Vihamieliset vahvistajat: uusi uhkamalli

Fyysisen kortin uhkamalli oli yksinkertainen: hukkaa se, kopioi se, kurkistele olkapään yli. mDL-uhkamalli on erilainen. Formaatti on vahva; kryptografia on vankka; riski siirtyy transaktion toisella puolella olevaan vahvistajasovellukseen.

Kuka tahansa voi rakentaa vahvistajasovelluksen. Ei ole keskitettyä lisenssiviranomaista. Niinpä baari voi käyttää valmisvahvistajaa, joka on konfiguroitu pyytämään koko syntymäpäivä, koko nimi ja kuva, vaikka se tarvitsee vain age_over_21. Autonvuokrauksen toimihenkilö voi pyytää kaikkea "asiakirjaan". Myymälävirkailija voi pyytää osoitteen. Mikään näistä ei ole teknisesti kiellettyä standardissa – standardi vain sanoo, että lompakon on näytettävä haltijalle, mitä pyydetään, ja vaadittava nimenomainen hyväksyntä.

Puolustus on siis haltijan puolella: lue pyyntökehote. Jos vahvistaja pyytää enemmän kuin transaktio vaatii, kieltäydy. Jotkin lompakot varoittavat, kun vahvistaja ei ole tunnetulla luottamuslistalla; ISO/IEC 18013-5 tukee vahvistajan todentamista sertifikaattien kautta, mutta luottamuslistainfrastruktuuri kypsyy vielä (osavaltiokohtaiset listat Yhdysvalloissa; EU:n luottamuslista eIDAS 2.0:n alla).

Kannattaa myös tietää: vahvistaja näkee eDeviceKey:si, cipher suiten ja tuettavat siirtomenetelmäsi – siinä kaikki. He eivät saa attribuutteja pelkästä QR-koodista. Joten QR-koodin skannaaminen tarralapusta tai jonkun näytöltä ja sen kanssa lähtö ei anna hyökkääjälle mitään hyödyllistä. Attribuutit siirtyvät vain salatun istunnon sisällä kättelynjälkeen.

Mitä skannerimme näyttää sinulle

Pudota mDL-DeviceEngagement-QR-koodi (kuva, liitä tai kamera) skannerimme. Tulos näyttää:

Standardi – ISO/IEC 18013-5 §8.2 DeviceEngagement (CBOR).
Versio – yleensä 1.0.
Cipher suite – nimetty cipher suite (P-256 / brainpool / jne.).
Siirtomenetelmät – mitkä kanavat lompakko tarjoaa (NFC, BLE, Wi-Fi Aware).
Palvelinhakuisäntä – jos lompakko tarjoaa 18013-7-tilan, mikä myöntäjä-URL käsittelisi attribuuttipyynnöt.
eDeviceKey-pituus – vahvistaa, että avain on läsnä ja oikein muodostettu, toistamatta tavuja.

Emme pura MITÄÄN attribuutteja – QR-koodissa ei ole attribuutteja, se on suunnitelmallista. Varsinaiset lisenssitiedot siirtyisivät salattuina valitun siirtomenetelmän kautta oikealle vahvistajalle.

Purku tapahtuu selaimessasi; vain rakenteelliset metatiedot lähetetään palvelimillemme turvallisuusluokittelua varten.

Ennen kuin hyväksyt vahvistajapyynnön

Lue pyyntökehote. Lompakon on standardin mukaan näytettävä sinulle koko lista pyydetyistä attribuuteista. Lue se.
Vastaako pyyntö transaktiota? Baarimikko, joka pyytää koko syntymäpäivää age_over_21:n sijaan = kieltäydy tai kysy miksi. Autonvuokrauksen virkailija, joka pyytää elinluovuttajastatusta = kieltäydy.
Onko vahvistaja luottamuslistalla? Joissakin lompakoissa näytetään valintamerkki tunnetuille vahvistajille (osavaltiosi DMV:n luottamusjuuren myöntämät sertifikaatit). Tuntemattomat vahvistajat kannattaa pysäyttää pohtimaan.
Verkon kautta haku (18013-7) on tehokkaampi ja tunkeilevampi. Jos lompakko kysyy, haluatko antaa vahvistajan hakea tietoja osavaltiosi DMV:ltä suoraan, se luo tarkistushistorian DMV:lle. Sopii tiettyihin transaktioihin (TSA, viralliset henkilöllisyystarkistukset), ei tarpeellinen muihin (oluen ostaminen).
Voit aina sanoa ei. Valikoivan luovuttamisen koko ideana on, että sinä hallitset, mitä puhelimestasi lähtee. Jos vahvistaja ei hyväksy rajoitettua luovutusta, voit turvautua fyysiseen korttiin tai poistua transaktiosta.

Aiheeseen liittyvää

AAMVA ajokortti PDF417 – fyysisen kortin viivakoodi, jonka tämä formaatti korvaa.
FIDO2 salasanaavain QR – toinen laitteiden välinen kättely-QR.
QR-huijauksia, joihin kannattaa varautua 2026
Kaikki tarkastamamme QR-standardit
Koko kattavuuslista

Tutki mDL-DeviceEngagement-QR-koodi

Pudota QR-koodi (kuva, liitä tai kamera). Tulos näyttää version, cipher suiten, siirtomenetelmät ja mahdollisen valinnaisen palvelinhaku-URL:n. Ei attribuutteja – ne siirtyvät vain salatun kättelynjälkeisen istunnon sisällä oikealle vahvistajalle.

Avaa skanneri →