Ingen «ring-hjem»-verifisering: Hvorfor fremtidens digitale internasjonale førerkort ikke må kontakte utstederen ved hver bruk

Tilbakekalling er det vanskeligste problemet i ethvert fremtidig digitalt internasjonalt førerkort (IDP). Den enkleste måten å løse det på er også den farligste: å gjøre utstederen til en deltaker i enhver enkelt presentasjon. En moderne grensekryssende kjørerettighet bør avvise dette snarveien som standard.

Nesten alle forslag til digital identitet inneholder den samme betryggende setningen:

“Legitimasjonen kan verifiseres umiddelbart.”

Noen ganger beskriver denne setningen ekte fremgang. Noen ganger beskriver den overvåkning med et vennligere brukergrensesnitt.

Dagens publiserte standarder gjør det allerede klart at en verifiserer ikke trenger å kontakte utstederen hver gang en legitimasjon vises:

• NISTss gjeldende mDL-arkitektur slår fast at en verifiserer kan validere autentisitet og integritet ved å stole på utstederens signatur og offentlige nøkler – uten direkte kontakt med utstederen.
• AAMVA bekrefter at ISO/IEC 18013-5 krever støtte for enhetsinnhenting og kun valgfritt tillater serverinnhenting.
• AAMVA advarer også om at ved serverinnhenting er den utstedende myndigheten involvert i sanntid ved hver bruk – noe som betyr at den teknisk sett kan logge når legitimasjonen brukes, hvilke data som deles, og til og med utlede plassering fra IP-analyse.

Dette er ikke en ubetydelig fotnote. Det er det sentrale designspørsmålet for neste generasjon av grensekryssende kjørerettigheter.

Det farlige snarveien: Å slå sammen fire spørsmål til ett nettverkskall

Dårlige arkitekturer bundler fire svært ulike spørsmål inn i ett enkelt direktekall til utstederen:

1. Er denne legitimasjonen autentisk?
2. Er personen som presenterer den den rettmessige innehaveren?
3. Er legitimasjonen i seg selv fortsatt gyldig?
4. Er den underliggende nasjonale kjøreretten fortsatt i kraft?

Et dårlig designet system besvarer alle fire ved å ringe hjem i sanntid. Et godt designet system skiller dem fra hverandre – fordi de ikke er det samme problemet og de bør ikke dele en mekanisme.

Autentisitet bør verifiseres lokalt, ikke over nettverket

En legitimasjon kan være kryptografisk ekte uten at utstederen noen gang observerer transaksjonen.

• NISTss mDL-tillitsmodell sier at autentisitet og integritet valideres fra utstederens signatur og offentlige nøkler – ingen direktekontakt med utstederen er nødvendig.
• AAMVAs Digital Trust Service eksisterer nettopp for å gi verifiserere tilgang til gyldige offentlige nøkler fra utstedere uten tilbakekall per transaksjon.

Designprinsipp 1: Ikke bruk direktetilkobling for å løse et problem som signaturer allerede løser.

Dersom en verifiserer besitter betrodde utstedersnøkler og mottar en standardkompliant presentasjon, er autentisitet en lokal kryptografisk sjekk, ikke en nettverksavhengighet.

Innehaverbinding bør bevises lokalt, ikke rapporteres globalt

Det andre spørsmålet – er dette den rettmessige innehaveren? – har også et svar som ikke krever nettverk.

Den gjeldende EUDI-arkitekturen pålegger enhetsbinding for PID-er og ISO/IEC 18013-5-attester. Verifisereren ber lommeboken om å signere en fersk utfordring ved hjelp av den private nøkkelen som svarer til den offentlige nøkkelen som er innebygd i legitimasjonen:

• I ISO/IEC 18013-5 kalles dette mdoc-autentisering.
• I SD-JWT VC kalles det nøkkelbinding.

I begge tilfeller bevises besittelse lokalt og kryptografisk. Ingen personopplysninger trenger noen gang å nå utstederen.

Designprinsipp 2: Bevis besittelse lokalt. Ikke bevis identitet globalt.

Et fremtidig IDP bør uttømme enhetsbinding, lokal innehaverautentisering og verifisererutfordring-respons før det vurderer noen mekanisme på utstederens side.

Legitimasjonsstatus og kjørerettighetsstatus er to forskjellige ting

Mange digitale identitetsdesign visker ut dette skillet, og det er der de går galt.

W3Cs Bitstring Status List-spesifikasjon gjør poenget klart: statusinformasjon knyttet til en verifiserbar legitimasjon gjelder den verifiserbare legitimasjonen i seg selv – ikke nødvendigvis den underliggende reelle rettigheten. En digital legitimasjon kan tilbakekalles fordi dens signeringsmekanisme ble kompromittert, mens den underliggende kjøreretten forblir fullt ut gyldig.

Et fremtidig IDP trenger derfor to distinkte statuslag:

• Legitimasjonsstatuslag – for den digitale legitimasjonen eller presentasjonskanalen i seg selv.
• Kjørerettighetslagg – for den underliggende nasjonale kjørerettigheten.

Noen ganger endres disse samtidig. Ofte gjør de ikke det. Et system som forveksler dem, vil overreagere, eksponere mer data enn nødvendig, eller begge deler.

Lommebokkompromittering bør forplante seg gjennom status – ikke utløse verifiserertilbakekall

Et fremtidig IDP trenger også et klart svar på hva som skjer når en lommebok kompromitteres.

EUDI-arkitekturen gir ett:

• Lommebok-leverandøren utsteder Wallet Unit Attestations som inneholder tilbakekallingsinformasjon.
• Lommebokintegritet re-verifiseres over tid; dersom en lommebok ikke lenger er sikker, tilbakekalles attesten.
• PID-leverandører må regelmessig sjekke om lommeboken er tilbakekalt. Dersom den er det, tilbakekalles PID-en.
• Ved å verifisere PID-status verifiserer den avhengige parten implisitt lommebokstatus.

Dette er lagdelingen et fremtidig IDP bør adoptere. Ikke be hver verifiserer om å sjekke lommeboksleverandøren uavhengig. La lommebokkompromittering forplante seg gjennom den eksisterende rørledningen for legitimasjonsstatus, og la verifiserere konsultere den ene personvernbevarende kanalen.

Tre brukbare tilbakekallingsmønstre (ingen tilbakekall nødvendig)

EUDI krever at leverandører bruker én av tre tilbakekallingsmetoder:

• Kortvarige attester – gyldige i 24 timer eller mindre, slik at tilbakekalling blir unødvendig.
• Atteststatusliste – en publisert liste verifiserere kan konsultere.
• Attesttilbakekallsliste – en eksplisitt liste over tilbakekalte legitimasjoner.

For attester som er gyldige lenger enn 24 timer, krever EUDI at tilbakekallingsinformasjon innebygd inkluderer:

• En URL der avhengige parter kan hente statuslisten.
• En identifikator som angir legitimasjonens plassering i den listen.

Dersom pålitelig tilbakekallingsinformasjon ikke er tilgjengelig – for eksempel når den avhengige parten er frakoblet – anbefaler EUDI at den avhengige parten utfører en risikoanalyse før legitimasjonen godtas eller avvises.

Konklusjonen: tilbakekalling er ikke én enkelt mekanisme, og absolutt ikke en begrunnelse for obligatoriske tilbakekall til utstederen.

Kortvarig som standard, langvarig kun der det er nødvendig

Et av de mest effektive personverntiltakene i hele systemstakken er også det enkleste: hold det som presenteres kortvarig.

• EUDI sier at attester som er gyldige i 24 timer eller mindre, ikke krever tilbakekallingsinfrastruktur – de utløper før tilbakekalling ville hatt betydning.
• W3C sier at verifiserbare presentasjoner typisk er kortvarige og ikke utformet for langtidslagring.
• NIST advarer eksplisitt mot gjentatt overføring av gjenbrukbare identifikatorer til daglig bruk. Daglig autentisering bør basere seg på teknologier bygget for det formålet, som passkeys, ikke gjentatt presentasjon av en identitetsrik legitimasjon.
• NIST valgte også lokal enhetsautentisering fremfor serverbasert biometrisk matching nettopp fordi lokal autentisering bevarer personvernet og er operasjonelt mer effektivt.

Designprinsipp 3: Basislegitimsjonen kan ha en middels gyldighetsperiode, men presentasjonen i seg selv bør være kortvarig, verifiserspesifikk og ikke-gjenbrukbar.

Statuslister er den riktige standardmekanismen

Når du ikke kan gjøre alt kortvarig, trenger du statusinfrastruktur – og statuslisten er det riktige standardvalget.

W3Cs Bitstring Status List v1.0 beskriver en personvernbevarende, plasseffektiv og høyytelsesmekanisme for publisering av statusdata som suspensjon eller tilbakekalling. Sentrale egenskaper inkluderer:

• Hver utsteder administrerer en liste for legitimasjonene den har utstedt.
• Formatet komprimerer godt, siden de fleste legitimasjoner forblir ikke-tilbakekalte.
• Standard listestørrelse er 131 072 oppføringer, som W3C sier gir tilstrekkelig gruppeintegritet i gjennomsnittlig tilfelle.
• Større lister kan brukes der sterkere gruppepersonvern er nødvendig.

Dette skifter spørsmålet fra:

“Kan jeg spørre utstederen om denne brukeren akkurat nå?”

til:

“Har jeg allerede en ny nok personvernbevarende statusliste til å avgjøre lokalt?”

Det er et langt bedre spørsmål – både teknisk og politisk.

«Ingen ring-hjem» er et nedlastingsmønster, ikke et slagord

Den viktigste regelen i EUDIs personvernveiledning er prosedyremessig, ikke filosofisk.

Avhengige parter må ikke be om statuslisten hver gang en legitimasjon presenteres. I stedet må de:

• Laste ned hver ny versjon av listen én gang.
• Gjøre det på et tidspunkt og fra et sted som er urelatert til noen brukerpresentasjon.
• Distribuere listen internt i den avhengige partens organisasjon.
• Hente listen uten å autentisere den avhengige parten.

Det er den operasjonelle kjernen i ingen-ring-hjem-verifisering: oppdater status separat fra brukerpresentasjoner – aldri per person, aldri per transaksjon.

Dette ene designvalget forhindrer at utstederen eller statusleverandøren får vite hvilken verifiserer som sjekket hvilken legitimasjon på hvilket tidspunkt.

Gruppepersonvern: Kravet de fleste design glemmer

Mange systemer trompeter selektiv utlevering inne i selve presentasjonen, og ignorerer deretter stille personvernet ved statusoppslag. Det er et betydelig hull.

EUDIs personvernkrav spesifiserer at:

• Indekser i statuslister må være tilfeldig tildelt, slik at selve indeksen aldri blir et sporingssignal.
• Hver liste må dekke et tilstrekkelig stort antall legitimasjoner for å sikre gruppepersonvern.
• Dersom en liste ellers ville være for liten, bør leverandører legge til ubrukte oppføringer for å skjule det reelle antallet legitimasjoner.

Et fremtidig IDP kan ikke hevde å være personvernbevarende utelukkende på grunnlag av selektiv utlevering. Dersom tilbakekallingsmekanismen lekker presentasjonshendelsen, er personverndesignet ufullstendig.

Frakoblet drift er ikke et kanttilfelle – det er et kjernekrav

Ethvert reisesystem som forutsetter perfekt tilkobling, er dårlig designet.

• AAMVA bekrefter at enhetsinnhenting fungerer uten ekstern tilkobling for både innehaverenheten og leseren, og at ISO/IEC 18013-5 krever at mDL-er støtter enhetsinnhenting.
• EUDI aksepterer at avhengige parter kan være frakoblet og mangle en bufret statusliste, og anbefaler i så fall en risikoanalyse før beslutning fattes.

Aksepter denne avveiningen tidlig:

Du kan ikke ha perfekt frakoblet drift og perfekt sanntidsferskthet samtidig.

Enhver arkitektur som lover begge uten kompromiss, er enten upresis eller gjeninnfører overvåkning i det stille. Den riktige responsen er å gjøre ferskthet til et policy-innspill, ikke en universell nettverksavhengighet.

Logger er der personvernet stille feiler

Selv en utmerket statusarkitektur kan undergraves av uforsiktig logging.

• EUDI krever at avhengige parts instanser kasserer unike elementer og tidsstempler så snart de ikke lenger er nødvendige, og forbyr videresending av dem.
• AAMVA forbyr interessenter å spore mDL-innehavere eller mDL-bruk unntatt der det er påkrevd ved lov, krever at utstedende myndigheter minimerer deling av statiske eller langvarige metadata, og begrenser tilgang til aktivitetslogger til innehaveren.
• AAMVA krever også at sletting på enheten fjerner logginformasjon og metadata som kan avsløre brukshistorikk – og at denne slettingen skal være mulig frakoblet.

Dette er protokollatferd, ikke administrativ hushold. Et fremtidig IDP må behandle langvarige identifikatorer, tidsstempler og logger som potensielle sporingsverktøy med mindre det eksplisitt er bevist noe annet.

En konkret ingen-ring-hjem-arkitektur for fremtidens IDP

Når prinsippene settes sammen, er dette hva systemet faktisk bør gjøre:

1. Utstede en enhetsbehandlet basislegitimsjonen. Bind legitimasjonen til nøkler beskyttet i lommebokens sikre miljø – obligatorisk under EUDI for PID-er og ISO/IEC 18013-5-attester.
2. Be kun om det som er nødvendig, med en fersk utfordring. I en OpenID4VP-transaksjon lar en DCQL-spørring lommeboken vise innehaveren hvilke attributter som etterspørres, og verifisereren utsteder en utfordring for å forhindre avspilling (i henhold til NISTss gjeldende mDL-arkitektur).
3. Generer en kortvarig presentasjon, ikke en gjenbrukbar identifikator. Hver presentasjon bør være spesifikk for verifisereren, forespørselen og øyeblikket.
4. Verifiser autentisitet lokalt. Valider utstederens signaturer og offentlige nøkler frakoblet; AAMVAs tillitejeneste er bygget nettopp for dette.
5. Sjekk status fra bufrede, separat oppdaterte lister. Der legitimasjoner er for langvarige til å hoppe over tilbakekalling, bruk lokalt bufrede statuslister som oppdateres etter en tidsplan urelatert til brukerpresentasjoner.
6. Anvend en risikopolicy når ferskthet ikke er tilgjengelig. Gjør frakoblede beslutninger til eksplisitt verifiserpolicy, ikke ustrukturert gjetning.
7. Slett sporingsdata aggressivt. Kasser transaksjonsunike elementer og tidsstempler når de ikke lenger er nødvendige; ikke behold logger som kan rekonstruere bevegelseshistorikk.

Dette er hva en seriøs ingen-ring-hjem-arkitektur ser ut som – lagdelt, personvernbevarende, kryptografisk lokal og operasjonelt ærlig om frakoblet virkelighet.

Tre mønstre som bør forbudt ved design

Et modent fremtidig IDP-økosystem bør behandle disse som arkitektoniske feil, ikke optimaliseringsvalg:

• Obligatoriske utsteder-tilbakekall ved hver presentasjon. AAMVAs egne personvernretningslinjer forklarer hvorfor dette er skadelig.
• Bruk av kjørerettighetslegitimsjonen som rutineinnlogging. NIST advarer eksplisitt mot gjentatt presentasjon av identitetsbærende legitimasjoner til daglig autentisering.
• Lagring av identifikatorer, tidsstempler og logger som kan rekonstruere presentasjonshistorikk. Både EUDI og AAMVA krever det motsatte.

Kjerneargumentet i én setning

Umiddelbar verifisering må ikke bli tillatelse til overvåkning fra utstederens side.

Et fremtidig IDP bør kunne:

• Bevise autentisitet lokalt.
• Bevise besittelse lokalt.
• Sjekke ferskthet privat.
• Tolerere frakoblet virkelighet.
• Fungere grasiøst når perfekt informasjon ikke er tilgjengelig.

Ingenting av dette gjør systemet svakere. Det gjør det verdt å distribuere i stor skala.

I det øyeblikket en kjørerettighetslegitimsjonen blir et verktøy for å registrere hvem som viste hva, hvor og når, slutter den å være en tryggere versjon av papir. Den blir infrastruktur for observasjon.

Det er nøyaktig det fremtidens IDP bør nekte å bli.

Ofte stilte spørsmål

Hva er «ring-hjem-verifisering»?
Det er ethvert design der en verifiserer kontakter utstederen i sanntid for å validere en legitimasjon. Selv om det løser autentisitet og tilbakekalling samtidig, lar det også utstederen observere enhver presentasjonshendelse.

Krever ISO/IEC 18013-5 online utsteder-kontakt?
Nei. AAMVA bekrefter at ISO/IEC 18013-5 krever støtte for enhetsinnhenting og kun valgfritt tillater serverinnhenting.

Hvordan kan tilbakekalling fungere uten å kontakte utstederen?
Gjennom kortvarige legitimasjoner, atteststatuslister eller attesttilbakekallslister – ideelt sett med den avhengige parten som laster ned statusdata separat fra brukerpresentasjoner.

Hvorfor er «gruppepersonvern» viktig for statuslister?
Dersom en statusliste er for liten eller indeksene er forutsigbare, kan en statusforespørsel avsløre hvilken spesifikk legitimasjon som nettopp ble presentert. Tilfeldige indekser og store lister forhindrer dette.

Er frakoblet verifisering virkelig praktisk?
Ja – og standardorganer inkludert AAMVA og EUDI krever det eksplisitt. Avveiningen er at perfekt sanntidsferskthet er uforenlig med perfekt frakoblet drift, slik at ferskthet må bli en policy-beslutning, ikke en hard avhengighet.