Ingen hemringning vid verifiering: Varför framtidens digitala IDP inte får kontakta utfärdaren vid varje användning

Återkallning är det svåraste problemet i alla framtida digitala internationella körkort (IDP). Det enklaste sättet att lösa det är också det farligaste: att göra utfärdaren till en deltagare vid varje enskild presentation. En modern gränsöverskridande körkortshandling bör avvisa denna genväg som standard.

Nästan varje förslag om digital identitet innehåller samma lugnande mening:

“Intyget kan verifieras omedelbart.”

Ibland beskriver den meningen verkliga framsteg. Ibland beskriver den övervakning med ett vänligare användargränssnitt.

Dagens publicerade standarder gör det redan tydligt att en verifierare inte behöver kontakta utfärdaren varje gång ett intyg visas:

• NIST:s nuvarande mDL-arkitektur anger att en verifierare kan validera äkthet och integritet genom att lita på utfärdarens signatur och offentliga nycklar, utan någon direkt kontakt med utfärdaren.
• AAMVA bekräftar att ISO/IEC 18013-5 kräver stöd för enhetshämtning och endast valfritt tillåter serverhämtning.
• AAMVA varnar också för att vid serverhämtning är den utfärdande myndigheten involverad i realtid vid varje användning – vilket innebär att den tekniskt sett kan logga när intyget används, vilka uppgifter som delas och till och med härleda plats via IP-analys.

Det är inte en obetydlig fotnot. Det är den centrala designfrågan för nästa generation av gränsöverskridande körkortshandlingar.

Den farliga genvägen: Att slå ihop fyra frågor i ett nätverksanrop

Dåliga arkitekturer buntar ihop fyra väldigt olika frågor i ett enda direktanrop till utfärdaren:

1. Är detta intyg äkta?
2. Är personen som presenterar det den rättmätiga innehavaren?
3. Är intyget i sig fortfarande giltigt?
4. Är den underliggande nationella körrätten fortfarande i kraft?

Ett dåligt utformat system besvarar alla fyra genom att ringa hem i realtid. Ett väldesignat system separerar dem – eftersom de inte är samma problem och inte bör dela en mekanism.

Äkthet bör verifieras lokalt, inte via nätverket

Ett intyg kan vara kryptografiskt äkta utan att utfärdaren någonsin observerar transaktionen.

• NIST:s mDL-förtroendemodell säger att äkthet och integritet valideras utifrån utfärdarens signatur och offentliga nycklar – ingen direkt kontakt med utfärdaren krävs.
• AAMVA:s Digital Trust Service finns just för att ge verifierare tillgång till giltiga utfärdares offentliga nycklar utan återanrop per transaktion.

Designprincip 1: Använd inte direktanslutning för att lösa ett problem som signaturer redan löser.

Om en verifierare innehar betrodda utfärdarnycklar och tar emot en standardenlig presentation, är äkthet en lokal kryptografisk kontroll, inte ett nätverksberoende.

Innehavarbindning bör bevisas lokalt, inte rapporteras globalt

Den andra frågan – är detta den rättmätiga innehavaren? – har också ett svar som inte kräver nätverk.

Den nuvarande EUDI-arkitekturen kräver enhetsbindning för PID:er och ISO/IEC 18013-5-attesteringar. Verifieraren ber plånboken signera en ny utmaning med den privata nyckel som motsvarar den offentliga nyckel som är inbäddad i intyget:

• I ISO/IEC 18013-5 kallas detta mdoc-autentisering.
• I SD-JWT VC kallas det nyckelkoppling.

I båda fallen bevisas innehav lokalt och kryptografiskt. Inga personuppgifter behöver någonsin nå utfärdaren.

Designprincip 2: Bevisa innehav lokalt. Bevisa inte identitet globalt.

En framtida IDP bör uttömma enhetsbindning, lokal innehavarautentisering och verifierarens utmaning-svar-metod innan den överväger någon mekanism på utfärdarens sida.

Intygsstatus och körrätt-status är två olika saker

Många digitala identitetsdesigner suddar ut denna distinktion, och det är där de går fel.

W3C:s specifikation Bitstring Status List gör detta tydligt: statusinformation kopplad till ett verifierbart intyg gäller det verifierbara intyget i sig – inte nödvändigtvis den underliggande verkliga rättigheten. Ett digitalt intyg kan återkallas eftersom dess signeringsmekanism komprometterades, medan den underliggande körrätten förblir fullt giltig.

En framtida IDP behöver därför två distinkta statuslager:

• Intygstatuslager – för det digitala intyget eller presentationskanalen i sig.
• Körrätt-lager – för den underliggande nationella rätten att köra.

Ibland förändras dessa tillsammans. Ofta gör de det inte. Ett system som blandar ihop dem kommer att överreagera, exponera mer data än nödvändigt, eller båda.

Plånbokskompromiss bör spridas via status – inte utlösa verifierarens återanrop

En framtida IDP behöver också ett tydligt svar på vad som händer när en plånbok komprometteras.

EUDI-arkitekturen ger ett sådant:

• Plånboksleverantören utfärdar plånboksenhetsintyg (Wallet Unit Attestations) som innehåller återkallningsinformation.
• Plånbokens integritet återverifieras över tid; om en plånbok inte längre är säker återkallas dess intyg.
• PID-leverantörer måste regelbundet kontrollera om plånboken har återkallats. Om så är fallet återkallar de PID:et.
• Genom att verifiera PID-status verifierar den förlitande parten implicit plånboksstatus.

Detta är den skiktning som en framtida IDP bör anta. Be inte varje verifierare att självständigt kontrollera plånboksleverantören. Låt plånbokskompromiss spridas genom den befintliga intygsstatus-pipelinen och låt verifierare konsultera den enda integritetsbevarande kanalen.

Tre fungerande återkallningsmönster (inga återanrop krävs)

EUDI kräver att leverantörer använder en av tre återkallningsmetoder:

• Kortlivade intyg – giltiga i 24 timmar eller mindre, så återkallning blir onödig.
• Intygstatuslista (Attestation Status List) – en publicerad lista som verifierare kan konsultera.
• Intygsåterkallningslista (Attestation Revocation List) – en uttrycklig lista över återkallade intyg.

För intyg som är giltiga längre än 24 timmar kräver EUDI att återkallningsinformation bäddas in, vilket inkluderar:

• En URL där förlitande parter kan hämta statuslistan.
• En identifierare som lokaliserar intyget i den listan.

Om tillförlitlig återkallningsinformation inte är tillgänglig – till exempel när den förlitande parten är offline – uppmanar EUDI den förlitande parten att genomföra en riskanalys innan intyget accepteras eller avvisas.

Slutsatsen: återkallning är inte en enda mekanism, och definitivt inte en motivering för obligatoriska utfärdaråteranrop.

Kortlivad som standard, långlivad bara när det är nödvändigt

En av de mest effektiva integritetsåtgärderna i hela stacken är också den enklaste: håll det som presenteras kortlivat.

• EUDI säger att intyg som är giltiga i 24 timmar eller mindre inte kräver återkallningsinfrastruktur – de löper ut innan återkallning skulle ha betydelse.
• W3C säger att verifierbara presentationer vanligtvis är kortlivade och inte utformade för långtidslagring.
• NIST varnar uttryckligen mot att upprepade gånger sända återanvändbara identifierare för vardaglig användning. Daglig autentisering bör förlita sig på tekniker byggda för det ändamålet, såsom lösenordsnycklar (passkeys), inte den upprepade presentationen av ett identitetsrikt intyg.
• NIST valde också lokal enhetsautentisering framför biometrisk matchning på serversidan specifikt eftersom lokal autentisering bevarar integritet och är operativt mer effektivt.

Designprincip 3: Basintygen kan ha en medellång giltighetstid, men presentationen i sig bör vara kortlivad, verifierarspecifik och inte återanvändbar.

Statuslistor är rätt standardmekanism

När du inte kan göra allt kortlivat behöver du statusinfrastruktur – och statuslistan är rätt standard.

W3C:s Bitstring Status List v1.0 beskriver en integritetsbevarande, utrymmeseffektiv och högpresterande mekanism för att publicera statusdata såsom avstängning eller återkallning. Viktiga egenskaper inkluderar:

• Varje utfärdare hanterar en lista för de intyg den har utfärdat.
• Formatet komprimeras väl, eftersom de flesta intyg förblir oåterkallade.
• Standardliststorleken är 131 072 poster, vilket W3C säger ger tillräcklig gruppsekretess i genomsnittsfall.
• Större listor kan användas där starkare gruppsekretess krävs.

Detta förskjuter frågan från:

“Kan jag fråga utfärdaren om den här användaren just nu?”

till:

“Har jag redan en tillräckligt ny integritetsbevarande statuslista för att fatta beslut lokalt?”

Det är en mycket bättre fråga – både tekniskt och politiskt.

“Ingen hemringning” är ett nedladdningsmönster, inte ett slagord

Den viktigaste regeln i EUDI:s integritetsvägledning är procedural, inte filosofisk.

Förlitande parter får inte begära statuslistan varje gång ett intyg presenteras. Istället måste de:

• Ladda ner varje ny version av listan en gång.
• Göra det vid en tidpunkt och från en plats orelaterad till någon användarpresentation.
• Distribuera listan internt inom den förlitande partens organisation.
• Hämta listan utan att autentisera den förlitande parten.

Det är den operativa kärnan i verifiering utan hemringning: uppdatera status separat från användarpresentationer – aldrig per person, aldrig per transaktion.

Detta enstaka designval förhindrar utfärdaren eller statusleverantören från att lära sig vilken verifierare som kontrollerade vilket intyg vid vilket tillfälle.

Gruppsekretess: Kravet som de flesta designs glömmer

Många system framhäver selektiv utlämning inom presentationen i sig, men ignorerar sedan tyst integriteten i statusuppslag. Det är en betydande brist.

EUDI:s integritetskrav specificerar att:

• Index i statuslistor måste tilldelas slumpmässigt, så att indexet i sig aldrig blir en spårningssignal.
• Varje lista måste täcka ett tillräckligt stort antal intyg för att säkerställa gruppsekretess.
• Om en lista annars skulle vara för liten bör leverantörer lägga till oanvända poster för att dölja det faktiska antalet intyg.

En framtida IDP kan inte hävda att vara integritetsbevarande enbart på grund av selektiv utlämning. Om återkallningsmekanismen läcker presentationshändelsen är integritetsdesignen ofullständig.

Offlinedrift är inte ett undantagsfall – det är ett kärnkrav

Alla resesystem som förutsätter perfekt anslutning är dåligt utformade.

• AAMVA bekräftar att enhetshämtning fungerar utan extern anslutning för både innehavarens enhet och läsaren, och att ISO/IEC 18013-5 kräver att mDL:er stöder enhetshämtning.
• EUDI accepterar att förlitande parter kan vara offline och sakna en cachad statuslista, i vilket fall det rekommenderar en riskanalys innan beslut fattas.

Acceptera denna avvägning tidigt:

Du kan inte ha perfekt offlinedrift och perfekt realtidsfräschhet samtidigt.

Varje arkitektur som lovar båda utan kompromiss är antingen oprecis eller återinför tyst övervakning. Det rätta svaret är att göra fräschhet till en policyinput, inte ett universellt nätverksberoende.

Loggar är där integriteten tyst misslyckas

Även en utmärkt statusarkitektur kan undergrävas av slarvig loggning.

• EUDI kräver att instanser av förlitande parter kasserar unika element och tidsstämplar så snart de inte längre behövs, och förbjuder att vidarebefordra dem.
• AAMVA förbjuder intressenter från att spåra mDL-innehavare eller mDL-användning utom när det krävs enligt lag, kräver att utfärdande myndigheter minimerar delning av statisk eller långlivad metadata, och begränsar åtkomst till aktivitetsloggar till innehavaren.
• AAMVA kräver också att borttagning på enheten tar bort logginformation och metadata som kan avslöja användningshistorik – och att denna borttagning är möjlig offline.

Detta är protokollbeteende, inte administrativ skötsel. En framtida IDP måste behandla långlivade identifierare, tidsstämplar och loggar som potentiella spårningsverktyg om inte annat uttryckligen bevisas.

En konkret arkitektur utan hemringning för framtidens IDP

Genom att samla principerna är det här vad systemet faktiskt bör göra:

1. Utfärda ett enhetsanknutet basintyg. Bind intyget till nycklar skyddade i plånbokens säkra miljö – obligatoriskt enligt EUDI för PID:er och ISO/IEC 18013-5-attesteringar.
2. Begär bara det som behövs, med en ny utmaning. I en OpenID4VP-transaktion låter en DCQL-fråga plånboken visa innehavaren vilka attribut som begärs, och verifieraren utfärdar en utmaning för att förhindra återspelning (enligt NIST:s nuvarande mDL-arkitektur).
3. Generera en kortlivad presentation, inte en återanvändbar identifierare. Varje presentation bör vara specifik för verifieraren, begäran och tillfället.
4. Verifiera äkthet lokalt. Validera utfärdarens signaturer och offentliga nycklar offline; AAMVA:s förtroendetjänst är byggd just för detta.
5. Kontrollera status från cachade, separat uppdaterade listor. Där intyg är för långlivade för att hoppa över återkallning, använd lokalt cachade statuslistor som uppdateras på ett schema orelaterat till användarpresentationer.
6. Tillämpa en riskpolicy när fräschhet inte är tillgänglig. Gör offline-beslut till en tydlig verifierarpolicy, inte ostrukturerad gissning.
7. Ta bort spårningsdata aggressivt. Kassera transaktionsunika element och tidsstämplar när de inte längre behövs; behåll inte loggar som kan rekonstruera rörelsehistorik.

Det är vad en seriös arkitektur utan hemringning ser ut – skiktad, integritetsbevarande, kryptografiskt lokal och operativt ärlig om offline-verkligheten.

Tre mönster som bör förbjudas genom design

Ett moget framtida IDP-ekosystem bör behandla dessa som arkitektoniska misslyckanden, inte optimeringsval:

• Obligatoriska utfärdaråteranrop vid varje presentation. AAMVA:s egna integritetsvägledning förklarar varför detta är skadligt.
• Att använda körkortsintygen som en rutinmässig inloggning. NIST varnar uttryckligen mot att upprepade gånger presentera identitetsbärande intyg för daglig autentisering.
• Att behålla identifierare, tidsstämplar och loggar som kan rekonstruera presentationshistorik. Både EUDI och AAMVA kräver det motsatta.

Kärnargumentet i en mening

Omedelbar verifiering får inte bli tillåtelse för övervakning på utfärdarens sida.

En framtida IDP bör kunna:

• Bevisa äkthet lokalt.
• Bevisa innehav lokalt.
• Kontrollera fräschhet privat.
• Tolerera offline-verkligheten.
• Fungera smidigt när perfekt information inte är tillgänglig.

Inget av detta gör systemet svagare. Det gör det värt att driftsätta i stor skala.

Det ögonblick ett körkortsuppgift blir ett verktyg för att registrera vem som visade vad, var och när, slutar det att vara en säkrare version av papper. Det blir infrastruktur för observation.

Det är precis vad den framtida IDP:n bör vägra att bli.

Vanliga frågor

Vad är “hemringningsverifiering”?
Det är en design där en verifierare kontaktar utfärdaren i realtid för att validera ett intyg. Även om det löser äkthet och återkallning simultant, låter det också utfärdaren observera varje presentationshändelse.

Kräver ISO/IEC 18013-5 online-kontakt med utfärdaren?
Nej. AAMVA bekräftar att ISO/IEC 18013-5 kräver stöd för enhetshämtning och endast valfritt tillåter serverhämtning.

Hur kan återkallning fungera utan att kontakta utfärdaren?
Genom kortlivade intyg, intygstatuslister eller intygsåterkallningslistor – helst med den förlitande parten som laddar ner statusdata separat från användarpresentationer.

Varför är “gruppsekretess” viktigt för statuslistor?
Om en statuslista är för liten eller dess index är förutsägbara kan en statusbegäran läcka vilket specifikt intyg som just presenterades. Slumpmässiga index och stora listor förhindrar detta.

Är offline-verifiering verkligen praktisk?
Ja – och standardorgan inklusive AAMVA och EUDI kräver det uttryckligen. Avvägningen är att perfekt realtidsfräschhet är oförenligt med perfekt offlinedrift, så fräschhet måste bli ett policybeslut, inte ett hårt beroende.