Hvorfor blokkjede er valgfritt for fremtidens internasjonale førerkort (IDP)

Et fremtidig internasjonalt førerkort (IDP) trenger åpenhet, tillitsankere og offentlig ansvarlighet. Det det ikke trenger – som standard – er å plassere sjåførene selv på en distribuert hovedbok.

Enhver seriøs samtale om et digitalt, grenseoverskridende IDP tiltrekker seg til slutt det samme forslaget: «Bare legg det på blokkjede.» Appellen er forståelig. Blokkjeder tilbyr manipuleringssikkerhet, delt synlighet og en historikk som bare kan utvides. Det er reelle egenskaper. Men i sammenheng med grenseoverskridende sjåføridentitet brukes de svært ofte på feil lag.

Denne artikkelen forklarer hvorfor, gjennomgår hva standardene faktisk sier, og presenterer et bedre arkitekturmønster.

Hva standardene faktisk sier om blokkjede

W3Cs datamodell for verifiserbare legitimasjoner er eksplisitt på at et verifiserbart dataregister kan ha mange former, inkludert:

• Pålitelige databaser
• Desentraliserte databaser
• Statlige identitetsdatabaser
• Distribuerte hovedbøker

DID Core er like tydelig: mange DID-metoder bruker distribuert hovedbokteknologi, men ikke alle gjør det. Med andre ord avviser standardene allerede ideen om at blokkjede er et obligatorisk fundament for digitale legitimasjoner.

Det er det rette utgangspunktet for et fremtidig IDP. Det nyttige spørsmålet er ikke «blokkjede eller ikke blokkjede?» Det er:

Hvilket lag trenger egentlig åpenhet, og hvilket lag absolutt ikke bør bli offentlig infrastruktur som standard?

Blokkjede er en samling egenskaper, ikke et krav

Den første feilen er å behandle «blokkjede» som ett enkelt krav. Det er det ikke. Det er en samling mulige egenskaper, inkludert:

• Delt publisering
• Historikk som bare kan utvides
• Distribuert drift
• Kvitteringsgenerering
• Motstand mot ensidige endringer

Noen av disse er nyttige for et fremtidig IDP. Noen er irrelevante. Og noen er aktivt farlige når de brukes på menneskelige legitimasjonssubjekter. W3Cs registermodell tillater bevisst flere implementeringer fordi ulike økosystemer trenger ulike avveininger.

Tre problemer som ikke bør slås sammen

Den andre feilen er å slå tre ulike problemer sammen til ett system. For et fremtidig IDP må disse holdes adskilt:

1. Hvor den juridiske sannheten finnes. Retten til å kjøre hører hjemme i autoritative nasjonale førerkorregistre.
2. Hvordan tillitsmateriale distribueres. Utstedernøkler og verifiserersertifikater hører hjemme i kontrollerte tillitsregistre.
3. Hvordan økosystemet reviderer endringer. Dette hører hjemme i et åpenhetslag.

Virkelige økosystemer fungerer allerede slik. AAMVAs digitale tillitsjeneste distribuerer utstederes offentlige nøkler i en nedlastbar liste før en verifiserer noen gang samhandler med et mDL. EUs håndbok for mobilt førerkort spesifiserer at medlemsstatene varsler Kommisjonen om autoriserte mDL-utstedere, og Kommisjonen publiserer en verifiseringsliste over disse myndighetene. Det er tillitsdistribusjon uten blokkjede.

Hva sertifikatgjennomsiktighet lærer oss

Den mest effektive åpenhetsmodellen på det offentlige internett er ikke en forbrukerblokkjede. Det er sertifikatgjennomsiktighet (CT).

RFC 9162 beskriver CT som en protokoll for offentlig logging av TLS-serversertifikater slik at hvem som helst kan:

• Revidere sertifiseringsmyndigheters aktivitet
• Oppdage problematiske eller feilutstedte sertifikater
• Revidere loggene selv

Den viktigste designlærdommen fra CT: åpenhet er mest verdifull når den registrerer utstederatferd og tillitsmateriale – ikke sluttbrukeraktivitet.

Anvendt på et fremtidig IDP betyr det logging av ting som:

• Utstedelse og rotasjon av utstedernøkler
• Publisering av tillitsankere
• Registrering av verifisererkategorier
• Policyendringer
• Samsvarserklæringer
• Sikkerhetsmessig relevante hendelser

Det betyr ikke å opprette en offentlig eller semi-offentlig hovedbok over innehavere, legitimasjonsidentifikatorer eller presentasjonshendelser. Det er ikke åpenhet. Det er overdreven datainnsamling.

SCITT: Hvorfor åpenhet ikke er det samme som sannhet

IETFs SCITT-arkitekturutkast utvider denne tankegangen. SCITT definerer en åpenhetstjeneste som vedlikeholder en verifiserbar datastruktur og utsteder kryptografiske kvitteringer som beviser inkludering av signerte utsagn. Identiteten til åpenhetstjenesten fanges opp av en offentlig nøkkel kjent for avhengige parter, og tillitsankere og registreringspolicyer gjøres selv transparente.

Dette er en kraftfull modell for IDP-infrastruktur fordi den gjør åpenhet til en reviderbar tjeneste rundt tillitsmateriale og policy – ikke rundt personlige reisehendelser.

SCITT er også tydelig på åpenhetens begrensninger:

• Et registrert utsagn beviser bare at en utsteder produserte og registrerte det – ikke at utsagnet er korrekt på ubestemt tid.
• Et senere signert utsagn kan erstatte et tidligere.
• Åpenhet forhindrer ikke uærlige eller kompromitterte utstedere; den holder dem ansvarlige.

For sjåføridentitet betyr dette skillet enormt mye: en åpenhetslogg er bevis og revisjonshistorikk, ikke den autoritative juridiske tilstanden til noens kjørerett.

SCITT bemerker også at en åpenhetstjeneste kan beskytte sin utvidelsesbegrensede sekvens ved hjelp av en kombinasjon av pålitelig maskinvare, konsensusprotokoll og kryptografiske bevis. Selv åpenhetslaget krever ikke én spesifikk blokkjededesign. Konsensus er ett alternativ, ikke det eneste.

Korrekt arkitekturinndeling for et fremtidig IDP

Et fremtidig IDP bør separere ansvarsområder i fire distinkte lag:

1. Autoritative registre over hvem som har lov til å kjøre (nasjonale lisensieringsmyndigheter)
2. Tillitsregistre for utsteder- og verifiserernøkler
3. Statusinfrastruktur for ferskhet og tilbakekalling
4. Et valgfritt åpenhetslag for offentlig revisjon av policyer, tillitsankere, kvitteringer og samsvarserklæringer

Når du separerer disse lagene, blir blokkjedespørsmålet mye skarpere. Det er ikke lenger «bør fremtidens IDP være på en blokkjede?» Det blir:

Hvilket lag, om noe, har faktisk nytte av en offentlig revisjon med kun-utvidbar historikk?

Fem grunner til at on-chain sjåføridentitet er feil standard

1. Det skaper varige sporingssignaler

EUDIs personvernarbeid forklarer at attestasjonspresentasjoner kan inneholde unike verdier som:

• Salter
• Hashverdier
• Tilbakekallings­identifikatorer
• Enhetsbundne offentlige nøkler
• Signaturer
• Tidsstempler

Fordi disse verdiene er faste for den samme attestasjonen, lar de avhengige parter koble sammen ulike transaksjoner og bygge en atferdsprofil av brukeren. EUDI advarer eksplisitt om at dette bryter den rimelige forventningen om at separate lommebokaktiviteter ikke vil bli kombinert.

Hvis du publiserer stabile innehaveridentifikatorer, stabile legitimasjonsidentifikatorer, gjenbrukbare hasher eller individuelt sporbare tilbakekallelseshendelser på en offentlig hovedbok, løser du ikke sporingsproblemet – du gjør det permanent.

2. Det eksponerer tilbakekallings- og freshetshendelser

W3Cs Bitstring Status List-anbefaling beskriver problemet tydelig: hvis det er en en-til-en-kobling mellom en legitimasjon og URL-adressen der statusen publiseres, kan utgiveren koble innehaveren, verifisereren og tidspunktet for sjekken. Spesifikasjonen bruker et eksempel med førerkort for å illustrere hvorfor det å bli sporet av utstederen når man går inn på et etablissement, bryter en vanlig personvernforventning.

Den bedre standarden som Bitstring Status List foreslår:

• Store, komprimerbare statuslister der mange legitimasjoner deler én statusressurs
• En standard listelengde på 131 072 oppføringer
• Avhengige parter laster ned nye versjoner separat, uten å autentisere seg selv
• Randomiserte indekser og gruppebaserte personverngarantier

Det er det motsatte av individualiserte, on-chain tilbakekallelseshistorikker.

3. Det forveksler legitimasjonsstatus med juridisk kjørestatus

En digital legitimasjon kan tilbakekalles fordi signeringsmekanismen ble kompromittert – selv mens den faktiske kjøreretten i den virkelige verden forblir gyldig. En offentlig hovedbok over legitimasjonshendelser er ikke en ren erstatning for den autoritative tilstanden til et nasjonalt førerkorregister.

SCITT understreker poenget: et registrert utsagn kan senere erstattes av et nytt, og avhengige parter bestemmer hva de skal stole på basert på policy og historikk. Loggen er ikke permanent sannhet. Den er bevis på hvem som sa hva, når, under hvilken policy. Den nasjonale lisensieringsmyndigheten forblir roten til den juridiske sannheten.

4. Det retter seg mot feil styringsproblem

Grenseoverskridende sjåføridentitet er primært ikke et konsensusproblem. Det er et styringsproblem:

• Hvem har lov til å utstede?
• Hvilke offentlige nøkler er gjeldende?
• Hvilke verifiserere er autoriserte?
• Hvilke dataforespørsler samsvarer med deres oppgitte formål?
• Hvilken policyversjon var gjeldende på det aktuelle tidspunktet?

Virkelige økosystemer svarer allerede på disse gjennom styrt tillitsinfrastruktur, ikke desentralisert konsensus:

• AAMVAs digitale tillitsjeneste publiserer utstedende myndigheters offentlige nøkler i en nedlastbar liste.
• EUs håndbok for mobilt førerkort sier at Kommisjonen publiserer listen over autoriserte mDL-utstedere.
• ETSIs arbeid med lommebokavhengige parts-sertifikater gir maskinlesbar verifiseringsautentisering med tiltenkt bruk og registrerte forespurte attributter.

Det er eksplisitt offentlig tillitsforvaltning – ikke desentralisert styring.

5. Det løser ikke veikantvirkeligheten

Mange blokkjedeforslag antar stille at tilgang til et levende nettverk er en fordel. For sjåførkredentialer – særlig ved veikanten eller under reiser – er det ofte ikke tilfelle.

AAMVAs implementeringsveiledning spesifiserer at:

• Enhentshenting fungerer uten ekstern tilkobling for både innehaver og leser ved transaksjonstidspunktet.
• ISO/IEC 18013-5 krever støtte for enhentshenting.
• Verifisererens tilgang til utstedernes offentlige nøkler trenger ikke å skje ved transaksjonstidspunktet. Nøkler kan lastes ned på forhånd.

Hvis en verifiserer allerede kan validere lokalt ved hjelp av bufret tillitsmateriale, er ikke en live blokkjedeavhengighet nødvendig. I beste fall er det et implementeringsvalg for en backend-revisjonsfunksjon.

Hva som bør være transparent i et fremtidig IDP

Et fremtidig IDP trenger absolutt åpenhet – på rett sted.

Gjør dette transparent som standard:

• Utstederes offentlige nøkler og nøkkelrotasjonshendelser
• Tillitsankere og lister over autoriserte utstedere
• Verifiserertilgangssertifikater og metadata om registrerte formål
• Policyversjoner og registreringsregler
• Samsvarserklæringer og sikkerhetsmessig relevante programvareutgivelseskrav
• Reviderbare kvitteringer som beviser at disse utsagnene ble registrert

Ikke gjør dette offentlig som standard:

• Innehaveridentifikatorer på en offentlig hovedbok
• Stabile legitimasjonsidentifikatorer gjenbrukt på tvers av verifiserere
• Per-presentasjonshendelser
• Rå tilbakekallelsesoppføringer som isolerer én person
• Fullstendige signerte utsagn som inneholder personopplysninger når hasher eller metadata ville holde

SCITT advarer eksplisitt utstedere om å gjennomgå inkluderingen av privat, konfidensiell eller personlig identifiserbar informasjon før de sender inn utsagn til en åpenhetstjeneste. Det bemerkes også at åpenhetstjenester kan beholde kun kryptografiske metadata som hasher – ikke fullstendige signerte utsagn.

Et bedre mønster: åpenhet rundt økosystemet, ikke gjennom personen

En ren arkitektur for et fremtidig IDP ser slik ut:

• Autoritativt nasjonalt register – forblir den juridiske sannhetskilden for kjøreretten.
• Legitimasjonslag – bærer maskinverifiserbare kjørerettigheter til innehaverens lommebok.
• Tillitsregisterlag – distribuerer utstedernøkler, verifiserersertifikater og lister over autoriserte utstedere.
• Statuslag – bruker kortlivede attestasjoner eller personvernbevarende statuslister som oppdateres separat.
• Åpenhetslag – kan eventuelt bruke konsensus internt, og logger tillitsankere, nøkkelendringer, policyoppdateringer, kvitteringer og økosystemutsagn som har nytte av offentlig revisjon med kun-utvidbar historikk.

Denne arkitekturen fanger opp de nyttige delene av blokkjedetenkning – kun-utvidbar reviderbarhet, offentlig granskning, manipuleringssikkerhet, kvitteringer – uten å gjøre sjåføren til det offentlige subjektet i systemet. Den samsvarer også med hva standardene allerede beskriver: registre kan ha ulike former, DID-er krever ikke distribuerte hovedbøker, tillitsregistre finnes allerede, og personvernbevarende statusmekanismer er allerede standardiserte.

Kjerneargumentet

Det fremtidige IDP bør adoptere den beste ideen fra blokkjede – offentlig ansvarlighet for infrastruktur – uten å adoptere dens verste standard for mennesker: varig, globalt synlig sporing.

I praksis betyr det:

• Åpenhet for utstedere, ikke eksponering av innehavere
• Reviderbare tillitsankere, ikke offentlige reisehistorikker
• Kvitteringer for policyer og registreringer, ikke permanente tidslinjer for legitimasjonsbruk
• Kun-utvidbart bevis for styringsformål i økosystemet, ikke on-chain sjåføridentitet som standard

Dette er ikke et argument mot blokkjede. Det er et argument mot å anvende blokkjede på feil lag.

Et fremtidig IDP kan godt bruke konsensusbaserte åpenhetstjenester et sted i økosystemet. Men hvis designet starter med å plassere sjåføren, legitimasjonen eller presentasjonshistorikken på en hovedbok, har det allerede valgt feil standard.