Stacken Bakom det Framtida IDP:et: Varför en Skiktad Standardsarkitektur Krävs för att Ersätta Papperstillståndet

Ingen enskild standard kommer att ersätta det internationella körtillståndet (IDP) på papper. Den verkliga efterföljaren är en stack av standarder som arbetar tillsammans — och att förstå den stacken är nyckeln till att förstå vart gränsöverskridande digitala körkortsuppgifter faktiskt är på väg.

Varför Ingen Enskild Standard Kommer att Ersätta Papper-IDP:et

De flesta diskussioner om det framtida IDP:et börjar med fel fråga: vilken standard kommer att ersätta papperstillståndet? Det antagandet förutsätter att en enda specifikation kan utföra hela jobbet. Det kan den inte.

NIST:s arbete med mDL (mobilt körkort) konstaterar uttryckligen att nya standarder för digitala intyg håller på att växa fram inom separata problemområden. ISO 18013-familjen i sig är redan uppdelad i flera delar som täcker fysisk design, säkerhet, mobil presentation och internetextensioner. Ett framtida gränsöverskridande körkortsbevis är därför inte en enda specifikation — det är en samordnad stack av specifikationer, där var och en hanterar ett specifikt problem.

Det Framtida IDP-stacken i Korthet

Här är de åtta lagren som tillsammans definierar hur ett framtida IDP ser ut:

Lager 0 — Fysisk och databaslinjen: ISO/IEC 18013-1
Lager 1 — Intygets säkerhet: ISO/IEC 18013-3
Lager 2 — Närhets- (personlig) presentation: ISO/IEC 18013-5
Lager 3 — Fjärr- / internetpresentation: ISO/IEC 18013-7
Lager 4 — Intygets semantik: W3C Verifiable Credentials Data Model 2.0
Lager 5 — Utfärdandeprotokoll: OpenID4VCI
Lager 6 — Förfrågnings- och presentationsprotokoll: OpenID4VP
Lager 7 — Förtroendefördelning och verifieringsbehörighet: Förtroenderegister (AAMVA:s VICAL-modell, EUDI:s certifikatbaserade modell för förlitande parter)

Varje lager är grundat i nuvarande standarder eller aktiv ekosystemdokumentation. Avsnitten nedan förklarar vad varje lager gör — och, lika viktigt, vad det inte gör.

Lager 0 — ISO/IEC 18013-1: Den Fysiska och Semantiska Grunden

Del 1 är viktigare än de flesta inser, eftersom den inte bara handlar om kortdesign.

ISO/IEC 18013-1 definierar de fysiska egenskaperna och den grundläggande datauppsättningen för ett ISO-kompatibelt körkort, vilket skapar en gemensam grund för internationell användning och ömsesidigt erkännande. Det bygger på ett säkert ID-1-kort kombinerat med en häfte för internationellt bruk och ersätter den äldre pappers-IDP-modellen. ISO konstaterar också att ett enda kort i många fall kan ersätta behovet av två separata dokument.

Den praktiska konsekvensen är enkel: det framtida IDP:et kan inte börja på plånboksnivå. Om den underliggande dokumentstrukturen, datamodellen och layouten inte standardiseras först, blir varje digitalt lager ovan en kompatibilitetskorrigering ovanpå fragmenterade nationella format. Del 1 är grunden som resten av stacken bygger på.

Lager 1 — ISO/IEC 18013-3: Intygets Säkerhet

Del 3 är där intyget övergår från att vara data på ett dokument till att bli ett säkerhetsobjekt. ISO beskriver 18013-3 som den del som specificerar mekanismer för:

Åtkomstkontroll till maskinläsbar data
Dokumentautentisering
Integritetsvalidering

ISO är dock tydlig med att Del 3 inte behandlar integritetsfrågor relaterade till senare användning av data — och den gränsen är viktig.

Kort sagt levererar 18013-3 intygets säkerhet, inte fullständig ekosystemstyrning. Det hjälper till att besvara frågor som: Utfärdades detta intyg av den påstådda myndigheten? Har data ändrats? Det besvarar inte fullt ut: Borde denna verifierare ens begära detta fält? Borde denna begäran tillåtas i detta sammanhang?

Detta är också ett aktivt lager snarare än en färdig produkt. ISO listar en ändring från 2022 för PACE-protokollet, en ändring från 2023 för uppdateringar av passiv autentisering, och ett nytt utkast till 18013-3 som för närvarande är under utveckling.

Lager 2 — ISO/IEC 18013-5: Personlig Mobil Presentation

Om Del 1 definierar dokumentet och Del 3 säkrar det, förvandlar Del 5 körkortet till ett mobilt intyg.

ISO specificerar att 18013-5 täcker gränssnittet mellan mDL och läsaren, och mellan läsaren och utfärdande myndigheters infrastruktur. Det gör det också möjligt för tredje parter — inklusive myndigheter och verifierare i andra länder — att:

Hämta mDL-data maskinellt
Koppla den datan till innehavaren
Autentisera dess ursprung
Verifiera dess integritet

Vad 18013-5 inte täcker är lika viktigt. ISO listar uttryckligen poster utanför räckvidden, inklusive hur innehavarens samtycke till att dela data erhålls och kraven för lagring av mDL-data och privata nycklar. Del 5 är inte en komplett plånboksprodukt, inte en komplett modell för användarsamtycke, och inte ett komplett styrningssystem. Det är transport- och verifieringslagret för mobil presentation.

AAMVA:s implementeringsvägledning skärper detta ytterligare genom att skilja mellan två hämtningsmodeller:

Enhetshämtning, där data läses direkt från innehavarens enhet.
Serverhämtning, vilket kan göra det möjligt för den utfärdande myndigheten att observera när mDL används, vilken data som delas, och till och med uppskatta fysisk plats genom IP-analys.

Den andra punkten är inte ett skäl att avvisa standarden — det är ett skäl att vara precis om vilken hämtningsmodell ett framtida IDP bör använda som standard. AAMVA kräver också att plånboken ger innehavaren full kontroll över vilka dataelement som delas, vilket passar ett framtida IDP mycket bättre än den äldre “visa hela dokumentet”-modellen.

Lager 3 — ISO/IEC 18013-7: Internetpresentation

Del 5 löser det personliga problemet. Del 7 utökar den modellen till fjärranvändning.

ISO beskriver 18013-7:2025 som en utökning av 18013-5 med internetpresentation av ett mDL för en läsare. Internet är inte en sekundär hänsyn i denna arkitektur; det är en uttrycklig del av standarden.

EU:s handbok för mobila körkort behandlar redan internetpresentation som praktisk snarare än teoretisk och beskriver scenarier som:

Incheckning vid biluthyrning, där användare delar sitt mDL antingen personligen eller på distans i förväg
Vägkontroller av polis
En allmän mDL-användningsprofil byggd på ISO/IEC 18013-5 och 18013-7

Det sagt är AAMVA:s nuvarande vägledning ärlig om begränsningarna: mDL-användning över internet är mycket önskvärd, men vissa stödjande standarder håller fortfarande på att mogna. Det finns verkliga luckor i nuvarande integrering mellan plånbok och webbläsare, och utan en lista över betrodda läsare kanske mdoc-sidan inte har något tillförlitligt sätt att bekräfta vissa säkerhetsegenskaper. Fjärrpresentation är verklig — och fortfarande under utveckling.

Även med dessa förbehåll är 18013-7 det första seriösa svaret på ett problem som papper-IDP:et aldrig ens försökte lösa: att presentera körrätt på distans, innan personen når disken eller kontrollpunkten.

Lager 4 — W3C VC Data Model 2.0: Semantiklagret

W3C:s Verifiable Credentials Data Model 2.0 är inte en körkortsstandard — och det är precis därför den är viktig.

Rekommendationen definierar en utbyggbar datamodell för verifierbara intyg, förklarar hur de kan skyddas mot ändringar, och beskriver ekosystemet utifrån tre kärnroller: utfärdare, innehavare och verifierare. Ett körkort förekommer som ett av dess centrala exempel.

För ett framtida IDP bidrar VC 2.0 med ett allmänt vokabulär för påståenden, presentationer och verifierbara dataregister. W3C är tydlig med att sådana register kan ta flera former, inklusive:

Betrodda databaser
Statliga identitetsdatabaser
Decentraliserade databaser
Distribuerade liggare

Det bryter den falska dikotomin mellan ett blockchain-exklusivt tillvägagångssätt och ett helt proprietärt sådant. Datamodellen är bredare än båda.

VC 2.0 är också tydlig kring selektivt utlämnande. W3C konstaterar att ett körkort kan bära mer data än vad som behövs för ett givet användningsfall, och rekommenderar antingen att information delas upp i mindre delar eller att mekanismer som möjliggör selektivt utlämnande används. För ett framtida IDP är detta inte ett valfritt integritetsmässigt trevligt tillägg — det är skillnaden mellan ett modernt intyg och en digital fotokopia av ett plastkort.

VC 2.0 är dock inte en fullständig ersättning för ISO 18013. W3C påpekar att datamodellen inte kräver en traditionell kedja-av-förtroende-modell baserad på certifikatmyndigheter. I praktiken är VC 2.0 ett starkt semantiklager, men explicita lager för förtroendefördelning och verifieringsstyrning behöver fortfarande placeras ovanpå.

Lager 5 — OpenID4VCI: Utfärdandeprotokollet

Ett framtida IDP behöver ett standardiserat sätt att flytta ett intyg från en utfärdare till en plånbok. Det är rollen för OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0.

Specifikationen definierar ett OAuth-skyddat API för utfärdande av verifierbara intyg, och det är avsiktligt formatoberoende. Bland de intygformat det stöder:

ISO mdoc
SD-JWT VC
W3C VCDM-intyg

Det stöder också innehavarbindning och senare presentationer utan ytterligare inblandning från utfärdaren. OpenID4VCI 1.0 godkändes som en slutgiltig specifikation i september 2025.

Detta gör OpenID4VCI strategiskt viktigt för ett framtida IDP-ekosystem. Istället för att bygga skräddarsydda utfärdare-till-plånbok-pipelines för varje jurisdiktion eller plånboksleverantör kan ekosystemet definiera en styrd utfärdandeprofil ovanpå ett standardiserat utfärdanderamverk — samtidigt som man väljer om det resulterande intyget kodas som mdoc, VC eller ett annat stöttande format. Den flexibiliteten är ett av de starkaste argumenten för att hålla det framtida IDP-stacken modulär.

Lager 6 — OpenID4VP: Förfrågnings- och Presentationsprotokollet

Om OpenID4VCI flyttar intyget till plånboken, flyttar OpenID for Verifiable Presentations (OpenID4VP) tillbaka det på ett kontrollerat sätt.

Specifikationen definierar en mekanism för att begära och presentera intyg. Dess baslinje använder HTTPS-meddelanden och omdirigeringar, men den stöder också användning via W3C Digital Credentials API istället för omdirigeringsflöden. OpenID4VP 1.0 nådde status som slutgiltig specifikation i juli 2025.

Det är viktigt eftersom det ger det framtida IDP-stacken ett webbnativt presentationslager som webbplatser, applikationer och onlineverifierare kan implementera direkt. Flera nyliga händelser understryker detta:

I augusti 2025 tillkännagav OpenID Foundation en formell säkerhetsanalys av OpenID4VP använt över Digital Credentials API, utan att några nya sårbarheter hittades i den verifierade protokollmodellen.
NIST:s nuvarande mDL-utkast bygger sin hotmodell kring att begära och presentera mDL:er via OpenID4VP över W3C Digital Credentials API, med FIDO CTAP som används för att upprätthålla närvaro och motstå nätfiske i relevanta flöden.

Webbsidan av stacken och mDL-sidan konvergerar. OpenID4VP bör inte läsas som en konkurrent till ISO 18013-7 — det är webbprotokolllagret som gör internetpresentation praktisk i verkliga webbläsar-, plånboks- och verifierarmiljöer.

Lager 7 — Förtroenderegister: Där Stacken Blir ett Ekosystem

Detta är lagret som många diskussioner hoppar över — och lagret som avgör om hela systemet faktiskt fungerar.

En verifierare kan inte göra mycket med ett signerat intyg om den inte känner till tre saker:

Vilka utfärdare som är legitima
Vilka offentliga nycklar som är aktuella
Om den begärande parten själv är behörig

På utfärdarsidan erbjuder AAMVA:s Digital Trust Service ett konkret svar. Det tillhandahåller ett enda, säkert och motståndskraftigt sätt för förlitande parter att erhålla utfärdande myndigheters offentliga nycklar, distribuerade genom Verified Issuer Certificate Authority List (VICAL). AAMVA:s vägledning beskriver VICAL-leverantörens roll i praktiska termer: samla in offentliga nycklar från legitima utfärdande myndigheter, verifiera att dessa myndigheter hanterar sina nycklar säkert, kombinera nycklarna i en enda VICAL och leverera den till verifierare.

På verifierarsidan angriper Europa förtroendeproblemet från ett annat håll. I EUDI:s arkitektur och referensramverk registrerar sig förlitande parter, erhåller åtkomstcertifikat och använder dessa certifikat för att autentisera sig mot plånboksapplikationer när de begär attribut. Plånboken verifierar sedan certifikatkedjan, kontrollerar återkallelsestatus, presenterar begäran för användaren och släpper bara de godkända attributen.

W3C:s VC-modell bidrar här också, genom att behandla verifierbara dataregister som en distinkt ekosystemroll. Som nämnts tidigare kan dessa register vara betrodda databaser, statliga identitetsdatabaser, decentraliserade databaser eller distribuerade liggare. Ett framtida IDP-förtroenderegister behöver inte byggas på blockchain. Det behöver vara styrt, granskningsbart och maskinläsbart.

Om ISO 18013 definierar hur intyget ser ut och färdas, avgör förtroenderegister om någon bör tro på det.

Ett framtida IDP är en stack, inte en enda specifikation

Hur en Framtida IDP-transaktion Fungerar från Början till Slut

Här är stacken i drift, uppdelad i de fyra nyckelögonblicken i ett intygs livscykel.

1. Utfärdande. En nationell myndighet — eller en strikt styrd behörig utfärdare — verifierar den underliggande körkortsposten och utfärdar ett intyg till innehavarens plånbok. OpenID4VCI är det mest praktiska utfärdandelagret som finns idag, eftersom det redan stöder ISO mdoc-, SD-JWT VC- och W3C VCDM-format. ISO 18013-5 i sig lämnar insamling av samtycke och lagring av privata nycklar utanför räckvidden, vilket är precis varför utfärdande och plånboksstyrning måste fungera ovanför det grundläggande ISO-transportlagret.

2. Personlig presentation. Vid en vägkontroll eller biluthyrningsdisk presenterar plånboken intyget med hjälp av ett närhetflöde baserat på 18013-5. Läsaren validerar ursprung och integritet med hjälp av utfärdarnycklar som hämtats från ett förtroenderegister — snarare än att fatta förtroendebeslut på egen hand. Innehavaren godkänner bara de fält som behövs för den specifika situationen.

3. Fjärrpresentation. För förhandskontroller vid biluthyrning eller andra onlineprocesser begär verifieraren en minimal uppsättning attribut via ett internetkapabelt flöde med 18013-7 och/eller OpenID4VP. Plånboken visar vilka attribut som begärs, innehavaren godkänner, och verifieraren tar emot en strukturerad presentation snarare än en skanning eller PDF-uppladdning. NIST:s nuvarande arkitektur, byggd kring OpenID4VP plus Digital Credentials API, visar att detta nu är en praktisk ingenjörsväg.

4. Förtroende och verifieringsbehörighet. Plånboken litar inte blint på varje begärande. Ett moget ekosystem autentiserar den förlitande parten, validerar certifikatkedjor, kontrollerar återkallelsestatus och ger användaren insyn i vem som frågar efter vilken data. EUDI-modellen är särskilt stark här, och behandlar verifierarregistrering och åtkomstcertifikat som väsentliga delar av systemet snarare än valfria tillägg.

Detta kompletta flöde är exakt varför ett framtida IDP måste vara en stack. Inget enskilt lager kan leverera det. Inte ISO ensamt. Inte VC ensamt. Inte OpenID ensamt. Och definitivt inte en PDF bifogad till ett formulär.

Vad som Fortfarande Saknas i det Framtida IDP-stacken

Det svåraste återstående problemet är inte längre att skapa ny kryptografi — det är att uppnå styrd interoperabilitet.

Betrakta var ekosystemet befinner sig idag:

NIST har beskrivit det nuvarande standardlandskapet som under utveckling inom separata områden.
AAMVA har byggt en regional förtroendetjänst för Nordamerika.
Europa bygger certifikatbaserat förtroende för förlitande parter in i sin plånboksarkitektur.
OpenID har slutfört specifikationer för utfärdande och presentation och utökar sin infrastruktur för konformitetstestning.

Dessa är fortfarande ekosystemspecifika svar. Det finns ännu inte ett globalt gränsöverskridande förtroendelager för körkortsuppgifter. Det återstående arbetet är att definiera:

Vilka delar av stacken som är obligatoriska
Vilka intygformat som är acceptabla
Hur förtroende för utfärdare och verifierare distribueras
Hur konformitet testas
Hur gränsöverskridande erkännande styrs utan att integritet komprometteras

Slutsats: Det Framtida IDP:et är en Stack, Inte ett Dokument

Ett framtida IDP kommer inte att uppstå för att en standardiseringsorganisation skriver ett enda dokument. Det kommer att framträda när en sammanhängande stack definieras, styrs och antas av jurisdiktioner. Den stacken har redan identifierbara lager: