Ett framtida internationellt körkort (IDP) behöver transparens, förtroendeankare och offentlig ansvarsskyldighet. Vad det inte behöver – som standard – är att registrera förare på ett distribuerat register.
Varje seriös diskussion om ett digitalt, gränsöverskridande IDP lockar förr eller senare fram samma förslag: “Lägg det bara på blockchain.” Lockelsen är förståelig. Blockkedjor erbjuder manipuleringsskydd, delad synlighet och en historik som bara kan utökas. Det är verkliga egenskaper. Men i sammanhanget av gränsöverskridande föraridentitet appliceras de mycket ofta på fel lager.
Den här artikeln förklarar varför, går igenom vad standarderna faktiskt säger och presenterar ett bättre arkitekturmönster.
Vad Standarderna Faktiskt Säger om Blockchain
W3C:s datamodell för verifierbara intyg är tydlig med att ett verifierbart dataregister kan anta många former, bland annat:
- Betrodda databaser
- Decentraliserade databaser
- Statliga identitetsdatabaser
- Distribuerade register
DID Core är lika tydlig: många DID-metoder använder teknik för distribuerade register, men inte alla. Med andra ord avvisar standarderna redan uppfattningen att blockchain är en obligatorisk grund för digitala intyg.
Det är rätt utgångspunkt för ett framtida IDP. Den användbara frågan är inte “blockchain eller inte blockchain?” Den är:
Vilket lager behöver faktiskt transparens, och vilket lager absolut inte bör bli offentlig infrastruktur som standard?
Blockchain är en Samling Egenskaper, Inte ett Krav
Det första misstaget är att behandla “blockchain” som ett enskilt krav. Så är det inte. Det är ett knippe möjliga egenskaper, bland annat:
- Delad publicering
- Historik som bara kan utökas
- Distribuerad drift
- Kvittogenerering
- Motståndskraft mot ensidiga ändringar
Vissa av dessa är användbara för ett framtida IDP. Vissa är irrelevanta. Och vissa är direkt skadliga när de appliceras på mänskliga innehavare av intyg. W3C:s registermodell tillåter avsiktligt flera implementationer eftersom olika ekosystem behöver olika avvägningar.
Tre Problem som Inte Bör Slås Samman
Det andra misstaget är att kollapsa tre olika problem till ett enda system. För ett framtida IDP måste dessa hållas åtskilda:
- Var den juridiska sanningen finns. Rätten att köra bil hör hemma i auktoritativa nationella körkortsregister.
- Hur förtroendematerial distribueras. Utfärdarnycklar och verifierarcertifikat hör hemma i kontrollerade förtroenderegistren.
- Hur ekosystemet granskar förändringar. Detta hör hemma i ett transparenslager.
Verkliga ekosystem fungerar redan på detta sätt. AAMVA:s Digital Trust Service distribuerar utfärdarens publika nycklar i en nedladdningsbar lista innan en verifierare någonsin interagerar med ett mDL. EU:s manual för mobila körkort anger att medlemsstaterna ska anmäla auktoriserade mDL-utfärdare till kommissionen, och kommissionen publicerar en verifieringslista över dessa myndigheter. Det är förtroendedistribution utan blockchain.
Vad Certificate Transparency Lär Oss
Den mest effektiva transparensmodellen på det offentliga internet är inte en konsumentblockkedja. Det är Certificate Transparency (CT).
RFC 9162 beskriver CT som ett protokoll för offentlig loggning av TLS-servercertifikat så att vem som helst kan:
- Granska certifikatutfärdarnas aktivitet
- Upptäcka problematiska eller felaktigt utfärdade certifikat
- Granska loggarna själva
Den viktigaste designlärdomen från CT: transparens är mest värdefull när den registrerar utfärdarens beteende och förtroendematerial – inte slutanvändaraktivitet.
Tillämpat på ett framtida IDP innebär det att logga saker som:
- Utfärdande och rotation av utfärdarnycklar
- Publicering av förtroendeankare
- Registrering av verifierarkategorier
- Policyändringar
- Överensstämmelsedeklarationer
- Säkerhetsrelevanta händelser
Vad det inte innebär är att skapa ett offentligt eller halvoffent register över innehavare, intygidentifierare eller presentationshändelser. Det är inte transparens. Det är överdriven datainsamling.
SCITT: Varför Transparens Inte är Detsamma som Sanning
IETF:s SCITT-arkitekturutkast utökar detta tankesätt. SCITT definierar en transparenstjänst som upprätthåller en verifierbar datastruktur och utfärdar kryptografiska kvitton som bevisar att signerade påståenden inkluderats. Transparenstjänstens identitet fångas av en publik nyckel som är känd av förlitande parter, och förtroendeankare samt registreringspolicyer görs själva transparenta.
Det är en kraftfull modell för IDP-infrastruktur eftersom den gör transparens till en granskningsbar tjänst kring förtroendematerial och policy – inte kring personliga resehändelser.
SCITT är också tydlig med transparensens begränsningar:
- Ett registrerat påstående bevisar bara att en utfärdare producerade och registrerade det – inte att påståendet är korrekt i all framtid.
- Ett senare signerat påstående kan ersätta ett tidigare.
- Transparens förhindrar inte oärliga eller komprometterade utfärdare; den håller dem ansvariga.
För föraridentitet är den distinktionen oerhört viktig: en transparenslogg är bevis och granskningshistorik, inte det auktoritativa juridiska tillståndet för någons körrätt.
SCITT noterar också att en transparenstjänst kan skydda sin tilläggssekvens med hjälp av en kombination av betrodd hårdvara, konsensusprotokoll och kryptografiska bevis. Även transparenslagret kräver inte en specifik blockkedjedesign. Konsensus är ett alternativ, inte det enda.
Rätt Arkitektonisk Separation för ett Framtida IDP
Ett framtida IDP bör separera ansvarsområden i fyra distinkta lager:
- Auktoritativa register över vem som får köra bil (nationella körkortsmyndigheter)
- Förtroenderegistren för utfärdar- och verifierarnycklar
- Statusinfrastruktur för aktualitet och återkallelse
- Ett valfritt transparenslager för offentlig granskning av policyer, förtroendeankare, kvitton och överensstämmelsedeklarationer
När du väl separerar dessa lager blir blockkedjesfrågan mycket skarpare. Det är inte längre “ska det framtida IDP:t vara på en blockkedja?” Det blir:
Vilket lager, om något, drar faktiskt nytta av en tilläggsbar offentlig granskning?
Fem Skäl till att Föraridentitet På Kedjan är Fel Standard
1. Det Skapar Beständiga Spårningssignaler
EUDI:s integritetsarbete förklarar att attestationspresentationer kan innehålla unika värden såsom:
- Saltvärden
- Hashvärden
- Återkallelseidentifierare
- Enhetsbundna publika nycklar
- Signaturer
- Tidsstämplar
Eftersom dessa värden är fasta för samma attestation gör de det möjligt för förlitande parter att koppla samman olika transaktioner och bygga en beteendeprofil av användaren. EUDI varnar uttryckligen för att detta strider mot den rimliga förväntningen att separata plånboksaktiviteter inte ska kombineras.
Om du publicerar stabila innehavaridentifierare, stabila intygidentifierare, återanvändbara hashvärden eller individuellt spårbara återkallelsehändelser på ett offentligt register löser du inte spårningsproblemet – du gör det permanent.
2. Det Exponerar Återkallelses- och Aktualitetshändelser
W3C:s rekommendation för Bitstring-statuslistor beskriver problemet tydligt: om det finns en ett-till-ett-mappning mellan ett intyg och den URL där dess status publiceras kan utgivaren koppla samman innehavaren, verifieraren och tidpunkten för kontrollen. Specifikationen använder ett körkortsexempel för att illustrera varför det kränker en vanlig integritetsförväntning att bli spårad av utfärdaren när man går in på ett etablissemang.
Det bättre standardalternativ som Bitstring-statuslistan föreslår:
- Stora, komprimerbara statuslistor där många intyg delar en statusresurs
- En standardlistlängd på 131 072 poster
- Förlitande parter laddar ner nya versioner separat, utan att autentisera sig
- Slumpmässiga index och gruppintegritetsgarantier
Det är raka motsatsen till individualiserade, kedjebaserade återkallelsespår.
3. Det Förväxlar Intygsstatus med Juridisk Körstatus
Ett digitalt intyg kan återkallas för att dess signeringsmekanism har komprometterats – även om den verkliga körrätten i den fysiska världen fortfarande är giltig. Ett offentligt register över intygshändelser är inte en ren ersättning för det auktoritativa tillståndet i ett nationellt körkortsregister.
SCITT förstärker poängen: ett registrerat påstående kan senare ersättas av ett nytt, och förlitande parter bestämmer vad de ska lita på utifrån policy och historik. Loggen är inte permanent sanning. Det är bevis om vem som sade vad, när och under vilken policy. Den nationella körkortsmyndigheten förblir roten till den juridiska sanningen.
4. Det Riktar in sig på Fel Styrningsproblem
Gränsöverskridande föraridentitet är i grunden inte ett konsensusproblem. Det är ett styrningsproblem:
- Vem är tillåten att utfärda?
- Vilka publika nycklar är aktuella?
- Vilka verifierare är auktoriserade?
- Vilka dataförfrågningar matchar deras deklarerade syfte?
- Vilken policyversion gällde vid tidpunkten?
Verkliga ekosystem besvarar redan dessa frågor genom styrd förtroendeinfrastruktur, inte decentraliserad konsensus:
- AAMVA:s Digital Trust Service publicerar utfärdande myndigheters publika nycklar i en nedladdningsbar lista.
- EU:s manual för mobila körkort anger att kommissionen publicerar listan över auktoriserade mDL-utfärdare.
- ETSI:s arbete med certifikat för plånboksförlitande parter tillhandahåller maskinläsbar verifierarautentisering med avsett användningsområde och registrerade begärda attribut.
Det är explicit offentlig förtroendeadministration – inte decentraliserad styrning.
5. Det Löser Inte Vägkantens Verklighet
Många blockkedjeförslag förutsätter tyst att live-nätverksåtkomst är en fördel. För körkortsuppgifter – särskilt vid vägkanten eller under resor – är det ofta inte det.
AAMVA:s implementationsvägledning anger att:
- Enhetsåterhämtning fungerar utan extern anslutning för både innehavare och läsare vid transaktionstillfället.
- ISO/IEC 18013-5 kräver stöd för enhetsåterhämtning.
- Verifierarens åtkomst till utfärdarens publika nycklar behöver inte ske vid transaktionstillfället. Nycklar kan laddas ner i förväg.
Om en verifierare redan kan validera lokalt med hjälp av cacheat förtroendematerial är ett live-blockkedjeberoende inte nödvändigt. I bästa fall är det ett implementationsval för en viss bakgrundsgranskning.
Vad som Bör Vara Transparent i ett Framtida IDP
Ett framtida IDP behöver absolut transparens – på rätt ställe.
Gör dessa transparenta som standard:
- Utfärdarens publika nycklar och nyckelrotationshändelser
- Förtroendeankare och listor över auktoriserade utfärdare
- Verifierarcertifikat och metadata för registrerat syfte
- Policyversioner och registreringsregler
- Överensstämmelsedeklarationer och säkerhetsrelevanta programvaruversionsanspråk
- Granskningsbara kvitton som bevisar att dessa påståenden registrerats
Gör inte dessa offentliga som standard:
- Innehavaridentifierare på ett offentligt register
- Stabila intygidentifierare som återanvänds hos olika verifierare
- Händelser per presentation
- Råa återkallelseposter som isolerar en enskild person
- Fullständiga signerade påståenden som innehåller personuppgifter när hashvärden eller metadata skulle räcka
SCITT varnar uttryckligen utfärdare att granska om privat, konfidentiell eller personligt identifierbar information ingår innan påståenden skickas till en transparenstjänst. Det noteras också att transparenstjänster kan behålla enbart kryptografisk metadata såsom hashvärden – inte fullständiga signerade påståenden.
Ett Bättre Mönster: Transparens Kring Ekosystemet, Inte Genom Personen
En ren arkitektur för ett framtida IDP ser ut så här:
- Auktoritativt nationellt register – förblir den juridiska källan till sanning om rätten att köra bil.
- Intygslager – bär maskinverifierbara körberättiganden till innehavarens plånbok.
- Förtroenderegisterlager – distribuerar utfärdarnycklar, verifierarcertifikat och listor över auktoriserade utfärdare.
- Statuslager – använder kortlivade attestationer eller integritetsbevarande statuslistor som uppdateras separat.
- Transparenslager – kan eller kan inte använda konsensus internt, och loggar förtroendeankare, nyckelförändringar, policyuppdateringar, kvitton och ekosystempåståenden som drar nytta av en tilläggsbar offentlig granskning.
Denna arkitektur fångar de användbara delarna av blockkedjetänkandet – tilläggsbar granskningsbarhet, offentlig granskning, manipuleringsskydd, kvitton – utan att göra föraren till det offentliga subjektet i systemet. Den överensstämmer också med vad standarderna redan beskriver: register kan anta olika former, DID:er kräver inte distribuerade register, förtroenderegister finns redan och integritetsbevarande statusmekanismer är redan standardiserade.
Kärnargumentet
Det framtida IDP:t bör anta den bästa idén från blockchain – offentlig ansvarsskyldighet för infrastruktur – utan att anta dess värsta standard för människor: beständig, globalt synlig spårning.
I praktiken innebär det:
- Transparens för utfärdare, inte exponering av innehavare
- Granskningsbara förtroendeankare, inte offentliga reseregister
- Kvitton för policyer och registreringar, inte permanenta tidslinjer för intygAnvändning
- Tilläggsbart bevis för ekosystemstyrning, inte kedjebaserad föraridentitet som standard
Det här är inte ett argument mot blockchain. Det är ett argument mot att applicera blockchain på fel lager.
Ett framtida IDP kan mycket väl använda konsensusbaserade transparenstjänster någonstans i ekosystemet. Men om designen börjar med att placera föraren, intyget eller presentationsspåret på ett register har man redan valt fel standard.
Published May 18, 2026 • 10m to read
