Ingen Hjem-Opkald-Verifikation: Hvorfor det Fremtidige Digitale IDP Ikke Må Kontakte Udstederen ved Hver Brug

Tilbagekaldelse er det sværeste problem i ethvert fremtidigt digitalt internationalt kørekort (IDP). Den nemmeste måde at løse det på er også den farligste: at gøre udstederen til en aktiv deltager ved hver eneste præsentation. Et moderne grænseoverskridende kørekort bør afvise denne genvej som standard.

Næsten ethvert digitalt identitetsforslag indeholder den samme beroligende sætning:

“Legitimationsbeviset kan verificeres øjeblikkeligt.”

Nogle gange beskriver den sætning ægte fremskridt. Andre gange beskriver den overvågning med en venligere brugergrænseflade.

Nuværende offentliggjorte standarder gør det allerede klart, at en verifikator ikke behøver at kontakte udstederen, hver gang et legitimationsbevis fremvises:

• NISTʼs nuværende mDL-arkitektur fastslår, at en verifikator kan validere ægthed og integritet ved at stole på udstederens signatur og offentlige nøgler – uden nogen direkte kontakt med udstederen.
• AAMVA bekræfter, at ISO/IEC 18013-5 kræver understøttelse af enhedshentning og kun valgfrit tillader serverhentning.
• AAMVA advarer også om, at den udstedende myndighed under serverhentning er involveret i realtid ved hver brug – hvilket betyder, at den teknisk set kan logge, hvornår legitimationsbeviset anvendes, hvilke data der deles, og endda udlede placering via IP-analyse.

Det er ikke en ubetydelig fodnote. Det er det centrale designspørgsmål for næste generation af grænseoverskridende kørekort.

Den Farlige Genvej: At Samle Fire Spørgsmål i Ét Netværksopkald

Dårlige arkitekturer samler fire meget forskellige spørgsmål i ét enkelt live-opkald til udstederen:

1. Er dette legitimationsbevis ægte?
2. Er personen, der fremviser det, den retmæssige indehaver?
3. Er legitimationsbeviset selv stadig gyldigt?
4. Er den underliggende nationale køreretsret stadig i kraft?

Et dårligt designet system besvarer alle fire ved at ringe hjem i realtid. Et veldesignet system adskiller dem – fordi de ikke er det samme problem og ikke bør dele en mekanisme.

Ægthed Bør Verificeres Lokalt, Ikke Over Netværket

Et legitimationsbevis kan være kryptografisk ægte uden at udstederen nogensinde observerer transaktionen.

• NISTʼs mDL-tillidsmodel fastslår, at ægthed og integritet valideres ud fra udstederens signatur og offentlige nøgler – ingen live-kontakt med udstederen er nødvendig.
• AAMVAʼs Digital Trust Service eksisterer netop for at give verifikatorer adgang til gyldige udstederes offentlige nøgler uden per-transaktion-tilbagekald.

Designprincip 1: Brug ikke live-forbindelse til at løse et problem, som signaturer allerede løser.

Hvis en verifikator besidder betroede udstedernøgler og modtager en standardkonform præsentation, er ægthed en lokal kryptografisk kontrol – ikke en netværksafhængighed.

Indehaverbinding Bør Bevises Lokalt, Ikke Rapporteres Globalt

Det andet spørgsmål – er dette den retmæssige indehaver? – har også et svar, der ikke kræver netværk.

Den nuværende EUDI-arkitektur kræver enhedsbinding for PID’er og ISO/IEC 18013-5-attesteringer. Verifikatoren beder tegnebogen om at underskrive en ny udfordring ved hjælp af den private nøgle, der svarer til den offentlige nøgle indlejret i legitimationsbeviset:

• I ISO/IEC 18013-5 kaldes dette mdoc-autentificering.
• I SD-JWT VC kaldes det nøglebinding.

I begge tilfælde bevises besiddelse lokalt og kryptografisk. Ingen personlige data behøver nogensinde at nå udstederen.

Designprincip 2: Bevis besiddelse lokalt. Bevis ikke identitet globalt.

Et fremtidigt IDP bør udtømme enhedsbinding, lokal indehaver-autentificering og verifikator-udfordringssvar inden det overvejer nogen udsteder-baseret mekanisme.

Legitimationsbevisstatus og Køreretsstatus Er To Forskellige Ting

Mange digitale identitetsdesigns slører denne sondring, og det er her, de går galt.

W3Cʼs Bitstring Status List-specifikation gør det klart: statusinformation knyttet til et verificerbart legitimationsbevis gælder for det verificerbare legitimationsbevis selv – ikke nødvendigvis for den underliggende virkelige rettighed. Et digitalt legitimationsbevis kan tilbagekaldes, fordi dets underskriftsmekanisme er blevet kompromitteret, mens den underliggende køreretsret forbliver fuldt ud gyldig.

Et fremtidigt IDP kræver derfor to adskilte statuslag:

• Legitimationsbevis-statuslag – for det digitale legitimationsbevis eller præsentationskanalen selv.
• Køreretslag – for den underliggende nationale ret til at køre.

Nogle gange ændres disse sammen. Ofte gør de ikke. Et system, der sammenblander dem, vil overreagere, eksponere mere data end nødvendigt eller begge dele.

Kompromittering af Tegnebogen Bør Forplante Sig Gennem Status – Ikke Udløse Verifikator-Tilbagekald

Et fremtidigt IDP har også brug for et klart svar på, hvad der sker, når en tegnebog er kompromitteret.

EUDI-arkitekturen giver ét:

• Tegnebogsudbyderen udsteder Wallet Unit Attestations, der indeholder tilbagekaldelsesoplysninger.
• Tegnebogsintegriteten re-verificeres over tid; hvis en tegnebog ikke længere er sikker, tilbagekaldes dens attestering.
• PID-udbydere skal regelmæssigt kontrollere, om tegnebogen er tilbagekaldt. Hvis den er, tilbagekaldes PID’en.
• Ved at verificere PID-status verificerer den afhængige part implicit tegnebogsstatussen.

Dette er den lagdeling, et fremtidigt IDP bør anvende. Undlad at bede hver verifikator om selvstændigt at kontrollere tegnebogsudbyderen. Lad tegnebogskompromittering forplante sig gennem den eksisterende pipeline for legitimationsbevisstatus, og lad verifikatorer konsultere denne ene privatlivsbeskyttende kanal.

Tre Brugbare Tilbagekaldelsesmønstre (Ingen Tilbagekald Nødvendige)

EUDI kræver, at udbydere anvender én af tre tilbagekaldelsesmetoder:

• Kortlivede attesteringer – gyldige i 24 timer eller mindre, så tilbagekaldelse bliver unødvendig.
• Attestation Status List – en offentliggjort liste, som verifikatorer kan konsultere.
• Attestation Revocation List – en eksplicit liste over tilbagekaldte legitimationsbevis.

For attesteringer, der er gyldige i mere end 24 timer, kræver EUDI indlejring af tilbagekaldelsesoplysninger, der inkluderer:

• En URL, hvorfra afhængige parter kan hente statuslisten.
• En identifikator, der angiver legitimationsbevisets placering på listen.

Hvis pålidelige tilbagekaldelsesoplysninger ikke er tilgængelige – for eksempel når den afhængige part er offline – anviser EUDI den afhængige part at foretage en risikoanalyse inden accept eller afvisning af legitimationsbeviset.

Konklusionen: tilbagekaldelse er ikke en enkelt mekanisme, og bestemt ikke en begrundelse for obligatoriske udsteder-tilbagekald.

Kortlivet som Standard, Langlivet Kun Where Nødvendigt

En af de mest effektive privatlivsforanstaltninger i hele stakken er også den enkleste: hold det, der præsenteres, kortlivet.

• EUDI fastslår, at attesteringer, der er gyldige i 24 timer eller mindre, ikke kræver tilbagekaldelsesinfrastruktur – de udløber, inden tilbagekaldelse ville have nogen betydning.
• W3C fastslår, at verificerbare præsentationer typisk er kortlivede og ikke er designet til langtidsopbevaring.
• NIST advarer eksplicit mod gentagen transmission af genanvendelige identifikatorer til daglig brug. Daglig autentificering bør basere sig på teknologier bygget til dette formål, såsom adgangsnøgler, ikke gentagen præsentation af et identitetsrigt legitimationsbevis.
• NIST valgte også lokal enhedsautentificering frem for serverbaseret biometrisk matchning netop fordi lokal autentificering beskytter privatlivet og er driftsmæssigt mere effektivt.

Designprincip 3: Basislegitimationsbeviset kan have en mellemlang gyldighedsperiode, men selve præsentationen bør være kortlivet, verifikator-specifik og ikke-genanvendelig.

Statuslister Er den Rette Standardmekanisme

Når man ikke kan gøre alt kortlivet, er der brug for statusinfrastruktur – og statuslisten er det rette standardvalg.

W3Cʼs Bitstring Status List v1.0 beskriver en privatlivsbeskyttende, pladsbesparing og højtydende mekanisme til offentliggørelse af statusdata såsom suspension eller tilbagekaldelse. Centrale egenskaber inkluderer:

• Hver udsteder administrerer en liste for de legitimationsbeviser, den har udstedt.
• Formatet komprimeres effektivt, da de fleste legitimationsbeviser forbliver ikke-tilbagekaldte.
• Standardlistestørrelsen er 131.072 poster, som W3C anfører giver tilstrækkelig gruppeprivatliv i gennemsnitstilfældet.
• Større lister kan bruges, hvor stærkere gruppeprivatliv er nødvendigt.

Dette forskyver spørgsmålet fra:

“Kan jeg spørge udstederen om denne bruger lige nu?”

til:

“Har jeg allerede en tilstrækkelig ny privatlivsbeskyttende statusliste til at træffe beslutning lokalt?”

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

“Ingen Hjem-Opkald” Er et Downloadmønster, Ikke et Slogan

Den vigtigste regel i EUDIʼs privatlivsvejledning er proceduremæssig, ikke filosofisk.

Afhængige parter må ikke anmode om statuslisten, hver gang et legitimationsbevis præsenteres. De skal i stedet:

• Downloade hver ny version af listen én gang.
• Gøre det på et tidspunkt og fra en placering, der ikke er relateret til nogen brugerpræsentation.
• Distribuere listen internt i den afhængige parts organisation.
• Hente listen uden at autentificere den afhængige part.

Det er den operationelle kerne i ingen-hjem-opkald-verifikation: opdater status adskilt fra brugerpræsentationer – aldrig per person, aldrig per transaktion.

Dette ene designvalg forhindrer udstederen eller statusudbyderen i at erfare, hvilken verifikator der kontrollerede hvilket legitimationsbevis på hvilket tidspunkt.

Gruppeprivatliv: Det Krav, de Fleste Designs Glemmer

Mange systemer trompeterer selektiv offentliggørelse inden for selve præsentationen og ignorerer derefter lydløst privatlivet ved statusopslag. Det er et betydeligt hul.

EUDIʼs privatlivskrav specificerer, at:

• Indeks i statuslister skal tildeles tilfældigt, så selve indekset aldrig bliver et sporingssignal.
• Hver liste skal dække et tilstrækkeligt stort antal legitimationsbeviser for at sikre gruppeprivatliv.
• Hvis en liste ellers ville være for lille, bør udbydere tilføje ubenyttede poster for at skjule det reelle antal legitimationsbeviser.

Et fremtidigt IDP kan ikke hævde at beskytte privatlivet alene på baggrund af selektiv offentliggørelse. Hvis tilbagekaldelsesmekanismen lækker præsentationshændelsen, er privatlivsdesignet ufuldstændigt.

Offlinedrift Er Ikke et Særtilfælde – Det Er et Kernekrav

Ethvert rejsesystem, der forudsætter perfekt forbindelse, er dårligt designet.

• AAMVA bekræfter, at enhedshentning fungerer uden ekstern forbindelse for både indehaverenheden og læseren, og at ISO/IEC 18013-5 kræver, at mDL’er understøtter enhedshentning.
• EUDI accepterer, at afhængige parter kan være offline og mangle en cachet statusliste, i hvilket tilfælde det anbefaler en risikoanalyse inden beslutning.

Acceptér denne afvejning tidligt:

Man kan ikke have perfekt offlinedrift og perfekt realtidsfriskheds på samme tid.

Enhver arkitektur, der lover begge dele uden kompromis, er enten unøjagtig eller genindfører lydløst overvågning. Det rette svar er at gøre friskhed til et politisk input, ikke en universel netværksafhængighed.

Logfiler Er der, hvor Privatlivet Stille Slår Fejl

Selv en fremragende statusarkitektur kan undermineres af skødesløs logning.

• EUDI kræver, at afhængige parts instanser kasserer unikke elementer og tidsstempler, så snart de ikke længere er nødvendige, og forbyder videresendelse af disse.
• AAMVA forbyder interessenter at spore mDL-indehavere eller mDL-brug undtagen hvor det kræves ved lov, kræver, at udstedende myndigheder minimerer deling af statiske eller langlivede metadata, og begrænser adgangen til aktivitetslogfiler til indehaveren.
• AAMVA kræver også, at sletning på enheden fjerner logoplysninger og metadata, der kunne afsløre brugshistorik – og at denne sletning skal være mulig offline.

Dette er protokoladfærd, ikke administrativ oprydning. Et fremtidigt IDP skal behandle langlivede identifikatorer, tidsstempler og logfiler som potentielle sporingsværktøjer, medmindre det modsatte er udtrykkeligt bevist.

En Konkret Ingen-Hjem-Opkald-Arkitektur for det Fremtidige IDP

Samler man principperne, er her hvad systemet faktisk bør gøre:

1. Udsted et enhedsbundet basislegitimationsbevis. Bind legitimationsbeviset til nøgler beskyttet i tegnebogens sikre miljø – obligatorisk under EUDI for PID’er og ISO/IEC 18013-5-attesteringer.
2. Anmod kun om det nødvendige, med en ny udfordring. I en OpenID4VP-transaktion lader en DCQL-forespørgsel tegnebogen vise indehaveren, hvilke attributter der anmodes om, og verifikatoren udsteder en udfordring for at forhindre genafspilning (jf. NISTʼs nuværende mDL-arkitektur).
3. Generer en kortlivet præsentation, ikke en genanvendelig identifikator. Hver præsentation bør være specifik for verifikatoren, anmodningen og øjeblikket.
4. Verificer ægthed lokalt. Valider udstedersignaturer og offentlige nøgler offline; AAMVAʼs tillidsservice er bygget netop til dette.
5. Kontroller status fra cachede, separat opdaterede lister. Hvor legitimationsbeviser er for langlivede til at springe tilbagekaldelse over, brug lokalt cachede statuslister, der opdateres efter en tidsplan uafhængig af brugerpræsentationer.
6. Anvend en risikopolitik, når friskhed ikke er tilgængelig. Gør offlinebeslutninger til eksplicit verifikatorpolitik, ikke ustruktureret gætteri.
7. Slet sporingsdata aggressivt. Kassér transaktionsunikke elementer og tidsstempler, når de ikke længere er nødvendige; gem ikke logfiler, der kan rekonstruere bevægelseshistorik.

Sådan ser en seriøs ingen-hjem-opkald-arkitektur ud – lagdelt, privatlivsbeskyttende, kryptografisk lokal og driftsmæssigt ærlig om offlinevirkeligheden.

Tre Mønstre, der Bør Forbydes ved Design

Et modent fremtidigt IDP-økosystem bør betragte disse som arkitektoniske fejl, ikke optimeringsvalg:

• Obligatoriske udsteder-tilbagekald ved hver præsentation. AAMVAʼs egen privatlivsvejledning forklarer, hvorfor dette er skadeligt.
• Brug af kørekortet som rutinelog-in. NIST advarer eksplicit mod gentagen præsentation af identitetsbærende legitimationsbeviser til daglig autentificering.
• Opbevaring af identifikatorer, tidsstempler og logfiler, der kan rekonstruere præsentationshistorik. Både EUDI og AAMVA kræver det modsatte.

Kerneargumentet i Én Sætning

Øjeblikkelig verifikation må ikke blive tilladelse til overvågning fra udstederens side.

Et fremtidigt IDP bør kunne:

• Bevise ægthed lokalt.
• Bevise besiddelse lokalt.
• Kontrollere friskhed privat.
• Tolerere offline-virkelighed.
• Fungere elegant, når perfekt information ikke er tilgængelig.

Intet af dette gør systemet svagere. Det gør det værd at anvende i stor skala.

I det øjeblik et kørekort bliver et redskab til at registrere, hvem der viste hvad, hvor og hvornår, ophører det med at være en sikrere udgave af papir. Det bliver infrastruktur for observation.

Det er præcis, hvad det fremtidige IDP bør nægte at blive.

Ofte Stillede Spørgsmål

Hvad er “hjem-opkald-verifikation”?
Det er ethvert design, hvor en verifikator kontakter udstederen i realtid for at validere et legitimationsbevis. Selvom det løser ægthed og tilbagekaldelse simultant, giver det også udstederen mulighed for at observere hver præsentationshændelse.

Kræver ISO/IEC 18013-5 online udstederkontakt?
Nej. AAMVA bekræfter, at ISO/IEC 18013-5 kræver understøttelse af enhedshentning og kun valgfrit tillader serverhentning.

Hvordan kan tilbagekaldelse fungere uden at kontakte udstederen?
Via kortlivede legitimationsbeviser, attesteringsstatuslister eller attesteringstilbagekaldelseslister – ideelt med at den afhængige part downloader statusdata adskilt fra brugerpræsentationer.

Hvorfor er “gruppeprivatliv” vigtigt for statuslister?
Hvis en statusliste er for lille, eller dens indeks er forudsigelige, kan en statusforespørgsel afsløre, hvilket specifikt legitimationsbevis der netop blev præsenteret. Tilfældige indeks og store lister forhindrer dette.

Er offlineverifikation virkelig praktisk?
Ja – og standardiseringsorganer, herunder AAMVA og EUDI, kræver det eksplicit. Afvejningen er, at perfekt realtidsfriskhed er uforeneligt med perfekt offlinedrift, så friskhed skal blive en politisk beslutning, ikke en hård afhængighed.