Tulevaisuuden IDP:n taustalla oleva teknologiapino: Miksi paperisen kansainvälisen ajokortin korvaaminen edellyttää kerrostettua standardiarkkitehtuuria

Yksikään standardi ei korvaa paperista kansainvälistä ajokorttia (IDP). Todellinen seuraaja on yhdessä toimivien standardien kokoelma — ja tämän kokonaisuuden ymmärtäminen on avain siihen, mihin rajat ylittävät digitaaliset ajokortit todella ovat menossa.

Miksi yksikään standardi ei korvaa paperista IDP:tä

Useimmat tulevaisuuden IDP:tä koskevat keskustelut alkavat väärällä kysymyksellä: mikä standardi korvaa paperisen luvan? Tämä lähtökohta olettaa, että yksi määrittely voi hoitaa koko työn. Se ei pysty siihen.

NISTin mDL-työ (mobiili ajokortti) toteaa nimenomaisesti, että uusia digitaalisten tunnistetietojen standardeja on syntymässä eri ongelma-alueille. ISO 18013 -perhe on jo itsessään jaettu useisiin osiin, jotka kattavat fyysisen suunnittelun, tietoturvan, mobiiliesittämisen ja internet-laajennukset. Tuleva rajat ylittävä ajotieto ei siis ole yksi määrittely — se on koordinoitu standardikokoelma, jonka kukin osa käsittelee omaa erityistä osa-aluettaan.

Tulevaisuuden IDP-pino lyhyesti

Tässä ovat kahdeksan kerrosta, jotka yhdessä määrittelevät, miltä tuleva IDP näyttää:

Kerros 0 — Fyysinen ja tietopohja: ISO/IEC 18013-1
Kerros 1 — Tunnistetietojen tietoturva: ISO/IEC 18013-3
Kerros 2 — Lähiesittäminen (henkilökohtainen): ISO/IEC 18013-5
Kerros 3 — Etä- / internet-esittäminen: ISO/IEC 18013-7
Kerros 4 — Tunnistetietojen semantiikka: W3C Verifiable Credentials Data Model 2.0
Kerros 5 — Myöntämisprotokolla: OpenID4VCI
Kerros 6 — Pyyntö- ja esittämisprotokolla: OpenID4VP
Kerros 7 — Luottamuksen jakelu ja varmentajien valtuutus: Luottamusrekisterit (AAMVA:n VICAL-malli, EUDI:n sertifikaattipohjainen riippuvainen osapuoli -malli)

Jokainen kerros perustuu nykyisiin standardeihin tai aktiiviseen ekosysteemidokumentaatioon. Alla olevat osiot selittävät, mitä kukin kerros tekee — ja yhtä tärkeänä, mitä se ei tee.

Kerros 0 — ISO/IEC 18013-1: Fyysinen ja semanttinen perusta

Osa 1 on tärkeämpi kuin useimmat ihmiset ymmärtävät, sillä se ei koske pelkästään korttien suunnittelua.

ISO/IEC 18013-1 määrittelee ISO-yhteensopivan ajokortin fyysiset ominaisuudet ja perustietojoukon luoden yhteisen pohjan kansainväliselle käytölle ja vastavuoroiselle tunnustamiselle. Se pohjautuu turvalliseen ID-1-korttiin yhdistettynä kansainväliseen käyttöön tarkoitettuun vihkoseen, korvaten vanhemman paperisen IDP-mallin. ISO toteaa myös, että monissa tapauksissa yksi kortti voi korvata kahden erillisen asiakirjan tarpeen.

Käytännön seuraus on yksinkertainen: tulevaisuuden IDP ei voi alkaa lompakkokerroksesta. Jos taustalla olevia asiakirjarakennetta, tietomallia ja asettelua ei ensin standardisoida, jokainen sen yläpuolella oleva digitaalinen kerros muuttuu paikaksi, jolla paikataan yhteensopivuusongelmia pirstaloituneissa kansallisissa formaateissa. Osa 1 on perusta, johon koko muu pino nojaa.

Kerros 1 — ISO/IEC 18013-3: Tunnistetietojen tietoturva

Osassa 3 tunnistieto siirtyy olemasta pelkkää dataa asiakirjalla tietoturvaobjektiksi. ISO kuvaa 18013-3:a osana, joka määrittelee mekanismit seuraaviin tarkoituksiin:

Koneluettavien tietojen pääsynhallinta
Asiakirjan todennus
Eheyden varmennus

ISO kuitenkin toteaa nimenomaisesti, että Osa 3 ei käsittele tietojen myöhempään käyttöön liittyviä yksityisyysasioita — ja tällä rajauksella on merkitystä.

Lyhyesti sanottuna 18013-3 tarjoaa tunnistetietojen tietoturvan, ei kokonaisvaltaista ekosysteemihallintoa. Se auttaa vastaamaan kysymyksiin kuten: Onko tämä tunniste myönnetty väitetyn viranomaisen toimesta? Onko dataa muutettu? Se ei täysin vastaa kysymyksiin: Pitäisikö tämän varmentajan ylipäätään pyytää tätä kenttää? Pitäisikö tämä pyyntö sallia tässä asiayhteydessä?

Tämä on myös aktiivinen kerros eikä valmis tuote. ISO luettelee PACE-protokollaa koskevan vuoden 2022 muutoksen, passiivista todennusta koskevien päivitysten vuoden 2023 muutoksen sekä parhaillaan kehitettävänä olevan uuden 18013-3-luonnoksen.

Kerros 2 — ISO/IEC 18013-5: Henkilökohtainen mobiiliesittäminen

Jos Osa 1 määrittelee asiakirjan ja Osa 3 suojaa sen, Osa 5 muuttaa ajokortin mobiilitunnisteeksi.

ISO määrittelee, että 18013-5 kattaa rajapinnan mDL:n ja lukijan välillä sekä lukijan ja myöntävän viranomaisen infrastruktuurin välillä. Se myös mahdollistaa kolmansille osapuolille — mukaan lukien muiden maiden viranomaisille ja varmentajille — seuraavat toiminnot:

mDL-tietojen hankkiminen koneellisesti
Tietojen yhdistäminen haltijaan
Alkuperän todentaminen
Eheyden varmennus

Se, mitä 18013-5 ei kata, on yhtä tärkeää. ISO luettelee nimenomaisesti soveltamisalan ulkopuolelle jäävät asiat, mukaan lukien se, miten haltijan suostumus tietojen jakamiseen hankitaan, sekä vaatimukset mDL-tietojen ja yksityisten avainten tallentamiselle. Osa 5 ei ole täydellinen lompakkotuote, ei täydellinen käyttäjän suostumuksen malli eikä täydellinen hallintojärjestelmä. Se on mobiiliesittämisen kuljetus- ja varmennutuskerros.

AAMVA:n toteutusohjeistus tarkentaa tätä edelleen erottamalla kaksi hakumallia:

Laitenouto, jossa tiedot luetaan suoraan haltijan laitteelta.
Palvelinnouto, joka voi antaa myöntävälle viranomaiselle mahdollisuuden seurata, milloin mDL:ää käytetään, mitä tietoja jaetaan ja jopa arvioida fyysistä sijaintia IP-analyysin avulla.

Jälkimmäinen seikka ei ole syy hylätä standardi — se on syy olla täsmällinen siinä, mitä noutamallia tulevaisuuden IDP:n tulisi oletuksena käyttää. AAMVA vaatii myös, että lompakko antaa haltijalle täyden hallinnan siitä, mitkä tietokentät jaetaan, mikä sopii tulevaisuuden IDP:hen paljon paremmin kuin vanha “näytä koko asiakirja” -malli.

Kerros 3 — ISO/IEC 18013-7: Internet-esittäminen

Osa 5 ratkaisee henkilökohtaisen esittämisen ongelman. Osa 7 laajentaa tämän mallin etäkäyttöön.

ISO kuvaa 18013-7:2025:tä standardina, joka laajentaa 18013-5:tä mDL:n internet-esittämisellä lukijalle. Internet ei ole tässä arkkitehtuurissa toissijainen näkökohta; se on standardin eksplisiittinen osa.

EU:n mobiiliajokorttikäsikirja käsittelee jo internet-esittämistä käytännöllisenä eikä teoreettisena asiana, kuvaten skenaarioita kuten:

Autonvuokrauksen sisäänkirjautuminen, jossa käyttäjät jakavat mDL:nsä joko henkilökohtaisesti tai etukäteen etänä
Poliisin tienvarsikohtaukset
Yleinen mDL-käyttöprofiili, joka perustuu ISO/IEC 18013-5:een ja 18013-7:ään

Siitä huolimatta AAMVA:n nykyinen ohjeistus on rehellinen rajoitusten suhteen: mDL:n käyttö internetin kautta on erittäin toivottavaa, mutta jotkin tukistandardit ovat vielä kehitteillä. Nykyisessä lompakko-selain-integraatiossa on todellisia puutteita, ja ilman luotettujen lukijoiden listaa mdoc-puolella ei välttämättä ole luotettavaa tapaa varmistaa tiettyjä turvaominaisuuksia. Etäesittäminen on totta — ja vielä kehittymässä.

Näistä varauksista huolimatta 18013-7 on ensimmäinen vakava vastaus ongelmaan, jota paperinen IDP ei edes yrittänyt ratkaista: ajotieto-oikeuksien esittäminen etänä ennen kuin henkilö saapuu tiskille tai tarkastuspisteelle.

Kerros 4 — W3C VC Data Model 2.0: Semantiikkakerros

W3C:n Verifiable Credentials Data Model 2.0 ei ole ajokorttia koskeva standardi — ja juuri siksi se on tärkeä.

Suositus määrittelee laajennettavan tietomallin todennettaville tunnistetiedoille, selittää, miten niitä voidaan suojata muutoksilta, ja kuvaa ekosysteemin kolmen keskeisen roolin kautta: myöntäjät, haltijat ja varmentajat. Ajokortti mainitaan yhtenä sen keskeisistä esimerkeistä.

Tulevaisuuden IDP:lle VC 2.0 tuo yleisen sanaston väitteille, esityksille ja todennettaville tietorekistereille. W3C toteaa nimenomaisesti, että tällaiset rekisterit voivat olla useassa muodossa, mukaan lukien:

Luotetut tietokannat
Valtion henkilöllisyystietokannat
Hajautetut tietokannat
Hajautetut tilikirjat

Tämä purkaa väärän vastakkainasettelun pelkän lohkoketjupohjaisen lähestymistavan ja täysin omistusoikeudellisen lähestymistavan välillä. Tietomalli on laajempi kuin kumpikaan niistä.

VC 2.0 on myös selkeä valikoivan tiedonluovutuksen suhteen. W3C toteaa, että ajokortti saattaa sisältää enemmän tietoa kuin tietyssä käyttötapauksessa tarvitaan, ja suosittelee joko tietojen jakamista pienempiin osiin tai sellaisten mekanismien käyttöä, jotka mahdollistavat valikoivan tiedonluovutuksen. Tulevaisuuden IDP:lle tämä ei ole valinnainen yksityisyydensuojan lisäominaisuus — se on ero modernin tunnistetiedon ja muovisen kortin digitaalisen valokopion välillä.

VC 2.0 ei kuitenkaan ole täydellinen korvaaja ISO 18013:lle. W3C huomauttaa, että tietomalli ei edellytä perinteistä varmentajaketjuun perustuvaa luottamusmallia. Käytännössä VC 2.0 on vahva semantiikkakerros, mutta sen päälle tarvitaan silti eksplisiittiset luottamuksen jakelu- ja varmentajien hallintakerrokset.

Kerros 5 — OpenID4VCI: Myöntämisprotokolla

Tulevaisuuden IDP tarvitsee standardoidun tavan siirtää tunnistieto myöntäjältä lompakkoon. Tämä on OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0:n rooli.

Määrittely määrittelee OAuth-suojatun API:n todennettavien tunnistetietojen myöntämiseen, ja se on tarkoituksellisesti formaatista riippumaton. Sen tukemiin tunnistetietoformaatteihin kuuluvat:

ISO mdoc
SD-JWT VC
W3C VCDM -tunnistetiedot

Se tukee myös haltijasidontaa ja myöhempiä esittämisiä ilman myöntäjän lisäosallistumista. OpenID4VCI 1.0 hyväksyttiin lopulliseksi määrittelyksi syyskuussa 2025.

Tämä tekee OpenID4VCI:stä strategisesti tärkeän tulevaisuuden IDP-ekosysteemille. Sen sijaan, että jokaiselle lainkäyttöalueelle tai lompakkotoimittajalle rakennettaisiin räätälöityjä myöntäjä-lompakko-putkilinjoja, ekosysteemi voi määritellä hallitun myöntämisprofiilin standardoivan myöntämiskehyksen päälle — valiten silti, koodataanko tuleva tunnistieto mdoc-, VC- vai muussa tuetussa formaatissa. Tämä joustavuus on yksi vahvimmista argumenteista tulevaisuuden IDP-pinon modulaarisuuden puolesta.

Kerros 6 — OpenID4VP: Pyyntö- ja esittämisprotokolla

Jos OpenID4VCI siirtää tunnisteen lompakkoon, OpenID for Verifiable Presentations (OpenID4VP) siirtää sen takaisin ulos hallitusti.

Määrittely määrittelee mekanismin tunnistetietojen pyytämiseen ja esittämiseen. Sen perusta käyttää HTTPS-viestejä ja uudelleenohjausta, mutta se tukee myös käyttöä W3C Digital Credentials API:n kautta uudelleenohjausvirtojen sijaan. OpenID4VP 1.0 saavutti lopullisen määrittelytilan heinäkuussa 2025.

Tämä on merkittävää, koska se antaa tulevaisuuden IDP-pinolle verkkopohjaisen esittämiskerroksen, jonka verkkosivustot, sovellukset ja verkkotoimiset varmentajat voivat ottaa suoraan käyttöön. Useat viimeaikaiset kehityskulut vahvistavat tätä:

Elokuussa 2025 OpenID Foundation ilmoitti muodollisesta tietoturva-analyysista, joka koski OpenID4VP:n käyttöä Digital Credentials API:n yli — eikä varmennetusta protokollamallista löydetty uusia haavoittuvuuksia.
NISTin nykyinen mDL-luonnos rakentaa uhkamallinsa mDL:ien pyytämisen ja esittämisen ympärille OpenID4VP:n kautta W3C Digital Credentials API:n avulla, käyttäen FIDO CTAP:ia läheisyyden valvontaan ja tietojenkalastelun torjuntaan asiaankuuluvissa virroissa.

Pinon verkko-osapuoli ja mDL-osapuoli lähestyvät toisiaan. OpenID4VP:tä ei pidä lukea ISO 18013-7:n kilpailijaksi — se on web-protokollakerros, joka tekee internet-esittämisestä käytännöllistä todellisissa selain-, lompakko- ja varmentajaympäristöissä.

Kerros 7 — Luottamusrekisterit: Missä pinosta tulee ekosysteemi

Tämä on kerros, jonka monet keskustelut ohittavat — ja kerros, joka ratkaisee, toimiiko koko järjestelmä käytännössä.

Varmentaja ei voi tehdä paljon allekirjoitetulla tunnisteella, ellei se tiedä kolmea asiaa:

Mitkä myöntäjät ovat laillisia
Mitkä julkiset avaimet ovat voimassa
Onko pyytävä osapuoli itse valtuutettu

Myöntäjien osalta AAMVA:n Digital Trust Service tarjoaa konkreettisen vastauksen. Se tarjoaa riippuvaisille osapuolille yhden, turvallisen ja kestävän tavan hankkia myöntävien viranomaisten julkiset avaimet, jotka jaellaan Verified Issuer Certificate Authority List (VICAL) -luettelon kautta. AAMVA:n ohjeistus kuvaa VICAL-toimittajan roolia käytännöllisesti: kerätä julkiset avaimet laillisilta myöntäviltä viranomaisilta, varmistaa, että nämä viranomaiset hallitsevat avaimiaan turvallisesti, yhdistää avaimet yhdeksi VICAL:ksi ja toimittaa se varmentajille.

Varmentajien osalta Eurooppa lähestyy luottamusongelmaa toisesta suunnasta. EUDI:n arkkitehtuurissa ja viitekehyksessä riippuvaiset osapuolet rekisteröityvät, hankkivat käyttösertifikaatit ja käyttävät niitä todentaakseen itsensä lompakkosovelluksille pyytäessään ominaisuuksia. Lompakko sitten varmistaa sertifikaattiketjun, tarkistaa peruutustilan, esittää pyynnön käyttäjälle ja luovuttaa vain hyväksytyt ominaisuudet.

W3C:n VC-malli myötävaikuttaa myös tähän, käsitellen todennettavia tietorekistereitä erillisenä ekosysteemiroolina. Kuten aiemmin todettiin, nämä rekisterit voivat olla luotettuja tietokantoja, valtion henkilöllisyystietokantoja, hajautettuja tietokantoja tai hajautettuja tilikirjoja. Tulevaisuuden IDP:n luottamusrekisterin ei tarvitse perustua lohkoketjuun. Sen täytyy olla hallittu, auditoitavissa ja koneluettava.

Jos ISO 18013 määrittelee, miltä tunnistieto näyttää ja miten se liikkuu, luottamusrekisterit päättävät, pitäisikö siihen uskoa.

Tulevaisuuden IDP on pino, ei yksittäinen määrittely

Kuinka tulevaisuuden IDP-transaktio toimii päästä päähän

Tässä pino toiminnassa, jaettuna tunnistetiedon elinkaaren neljään keskeiseen hetkeen.

1. Myöntäminen. Kansallinen viranomainen — tai tiukasti hallittu valtuutettu myöntäjä — varmentaa taustalla olevan ajokorttitietueen ja myöntää tunnistetiedon haltijan lompakkoon. OpenID4VCI on käytännöllisin saatavilla oleva myöntämiskerros tänään, koska se tukee jo ISO mdoc-, SD-JWT VC- ja W3C VCDM -formaatteja. ISO 18013-5 itse jättää suostumuksen hankkimisen ja yksityisten avainten tallentamisen soveltamisalansa ulkopuolelle, minkä vuoksi myöntämisen ja lompakon hallinnan on toimittava perustason ISO-kuljetuskerroksen yläpuolella.

2. Henkilökohtainen esittäminen. Tienvarsikohtauksessa tai vuokrauspisteellä lompakko esittää tunnistetiedon 18013-5:een perustuvalla läheisyysvirralla. Lukija validoi alkuperän ja eheyden käyttämällä luottamusrekisteristä hankittuja myöntäjän avaimia — eikä tee luottamuspäätöksiä itsenäisesti. Haltija hyväksyy vain kyseisessä tilanteessa tarvittavat kentät.

3. Etäesittäminen. Ennakkovuokraustarkistuksia tai muita verkkoprosesseja varten varmentaja pyytää minimaalista ominaisuusjoukkoa internet-yhteensopivaa virtaa käyttäen 18013-7:n ja/tai OpenID4VP:n kautta. Lompakko näyttää, mitä ominaisuuksia pyydetään, haltija hyväksyy, ja varmentaja saa jäsennellyn esityksen skannauksen tai PDF-latauksen sijaan. NISTin nykyinen arkkitehtuuri, joka on rakennettu OpenID4VP:n ja Digital Credentials API:n ympärille, osoittaa, että tämä on nyt käytännöllinen tekninen polku.

4. Luottamus ja varmentajan valtuutus. Lompakko ei luota sokeasti jokaiseen pyytäjään. Kypsä ekosysteemi todentaa riippuvaisen osapuolen, validoi sertifikaattiketjut, tarkistaa peruutustilan ja antaa käyttäjälle näkyvyyden siihen, kuka pyytää mitäkin dataa. EUDI-malli on erityisen vahva tässä, käsitellen varmentajan rekisteröintiä ja käyttösertifikaatteja järjestelmän olennaisina osina eikä valinnaisina lisäosina.

Tämä täydellinen virta on juuri syy siihen, miksi tulevaisuuden IDP:n on oltava pino. Yksikään kerros ei pysty toteuttamaan sitä yksin. Ei ISO yksin. Ei VC yksin. Ei OpenID yksin. Eikä varsinkaan lomakkeeseen liitetty PDF.

Mitä tulevaisuuden IDP-pinosta vielä puuttuu

Vaikein jäljellä oleva ongelma ei enää ole uuden kryptografian luominen — se on hallitun yhteentoimivuuden saavuttaminen.

Harkitaan, missä ekosysteemi on tänään:

NIST on kuvannut nykyistä standardimaisemaa erillisillä alueilla kehittyvänä.
AAMVA on rakentanut alueellisen luottamuspalvelun Pohjois-Amerikalle.
Eurooppa rakentaa sertifikaattipohjaista riippuvainen osapuoli -luottamusta lompakkoarkkitehtuuriinsa.
OpenID on viimeistellyt myöntämis- ja esittämismäärittelyt ja laajentaa vaatimustenmukaisuusinfrastruktuuria.

Nämä ovat silti ekosysteemikohtaisia vastauksia. Ei ole vielä olemassa yhtä globaalia rajat ylittävää luottamuskerrosta kuljettajatunnistetiedoille. Jäljellä oleva työ on määritellä:

Mitkä pinon osat ovat pakollisia
Mitkä tunnistetietoformaatit ovat hyväksyttäviä
Miten myöntäjän ja varmentajan luottamus jaellaan
Miten vaatimustenmukaisuus testataan
Miten rajat ylittävä tunnustaminen hallitaan yksityisyyttä vaarantamatta

Johtopäätös: Tulevaisuuden IDP on pino, ei asiakirja

Tulevaisuuden IDP ei synny siksi, että yksi standardointijärjestö kirjoittaa yhden asiakirjan. Se syntyy, kun yhtenäinen pino on määritelty, hallittu ja otettu käyttöön eri lainkäyttöalueilla. Tuossa pinossa on jo tunnistettavissa olevat kerrokset: