Polis, Hyrbilsdiskar, Arbetsgivare, Försäkringsbolag: Varför De Inte Får Se Samma Data

Det största designmisstaget i ett framtida Internationellt Körkort (IKK) skulle vara att behandla varje verifierare som om de vore samma verifierare. En polisofficer, en hyrbilsdisk, en arbetsgivare och ett försäkringsbolag ställer inte samma fråga — därför bör de inte heller få samma svar.

En förare. En grundläggande rätt att köra. En plånbok. Men fyra mycket olika verifierare:

• En polisofficer vid vägkanten
• En hyrbilsdisk vid avhämtning
• En arbetsgivare som kontrollerar behörighet för fordonsflotta
• Ett försäkringsbolag som granskar ett skadeärende

Om det framtida IKK:et visar samma data för alla fyra har systemet redan misslyckats. Inte för att intyget är osäkert, utan för att utlämningsmodellen är alltför enkel.

Standardiseringsgemenskapen rör sig redan bort från den enkla modellen. W3C:s arbete med verifierbara intyg beskriver ekosystemet kring utfärdare, innehavare och verifierare, med arbetsgivare och webbplatser som exempel på verifierare. EU:s arbete med mobila körkort behandlar redan vägkantskontroller och hyrbilsuthyrning som separata verifieringsscenarier, inklusive fjärrutdelning i förväg för hyrbilsuthyrning och kontroller på plats för polis. Arkitekturen är redan utformad för flera typer av verifierare. Misstaget vore att utforma användarupplevelsen som om bara en typ existerade.

Varför Det Fysiska Kortet Lärde Oss att Tänka Fel

Ett fysiskt körkort lärde oss ett visa-allt-tillvägagångssätt. Du räcker över kortet. Den andra personen ser vad som står på kortet. Det är hela interaktionen.

Det tillvägagångssättet är acceptabelt i en pappersvärd eftersom det inte finns något alternativ. Det blir oacceptabelt i en digital värld.

W3C VC Data Model 2.0 konstaterar direkt: ett körkort kan innehålla ID-nummer, längd, vikt, födelsedag och hemadress — men det kan ändå vara långt mer än nödvändigt för en given transaktion. Viktiga punkter från nuvarande standarder:

• W3C:s bästa praxis: stöd selektiv utlämning och begär endast vad som är absolut nödvändigt
• EU:s dataskyddsvägledning: behandling måste begränsas till angivna ändamål, och de uppgifter som behandlas måste vara nödvändiga och proportionerliga
• Den första principen för ett framtida IKK: samma intyg innebär inte samma rätt att granska

Den Rätta Modellen Är Policybaserad Utlämning

Om man vill ha en seriös arkitektur är den rätta modellen närmare attributbaserad åtkomstkontroll än digital kortpresentation.

NIST SP 800-205 definierar åtkomstkontrollbeslut som utvärderingar av attribut kopplade till subjektet, objektet, den begärda åtgärden och miljöförhållandena, mot policy. Det är exakt rätt struktur för ett framtida IKK:

• Subjekt: föraren
• Objekt: de begärda datafälten
• Åtgärd: inte “se körkort” i abstrakt mening, utan något specifikt som “verifiera rätt att köra kategori B vid vägkanten” eller “verifiera behörighet för en hyrbilsbokning”
• Miljö: vägkanten, hyrbilsdisken, fjärrkontroll i förväg, registrering av fordonsflotta och skadegranskning efter förlust är olika miljöer och bör leda till olika beslut

NIST påpekar också att attributsystem behöver granularitet, styrning och mekanismer för reducering, gruppering och minimering av attribut.

Det framtida IKK:et bör alltså inte fråga: Kan den här verifieraren läsa körkortet? Det bör fråga: Vilka påståenden får den här verifieraren ta emot, för vilket avsett ändamål, i den här miljön, med vilka lagringsregler?

En Verifierare Bör Identifiera Sig Innan Den Begär Något

Det framtida IKK:et bör inte börja med att plånboken visar data. Det bör börja med att verifieraren bevisar vem den är.

EUDI-arkitekturen är tydlig på denna punkt. Förlitande parter måste:

• Registrera vilka attribut de avser att begära och för vilket ändamål
• Ta emot åtkomstcertifikat
• Autentisera sig mot plånboken innan någon utlämning sker
• Kontrolleras mot deras registrerade omfång, där registreringsinformation finns tillgänglig

Användaren kan sedan se vem som frågar, vad som efterfrågas och om begäran ryms inom det registrerade omfånget.

ETSI:s pågående arbete med certifikat för plånboksförlitande parter konkretiserar detta ytterligare. Ett registreringscertifikat för en plånboksförlitande part kan beskriva den förlitande partens avsedda användning och de attribut den har registrerat sig för att begära. Det relaterade åtkomstcertifikatet finns för att säkerställa att begäran kommer från en legitim, behörig part. ETSI inkluderar även metadata för förlitande parter såsom:

• Handelsnamn
• Support-URI
• Avsedd användning
• Rättigheter
• Register-URI
• Information om tillsynsmyndighet

Den andra principen för ett framtida IKK: ingen verifieraridentitet, ingen utlämning.

Varför Samtycksskärmar Inte Är Tillräckliga

Det finns ytterligare ett misstag här: att behandla användargodkännande som samma sak som rättslig legitimitet.

EUDI-arkitekturen slår uttryckligen fast att användargodkännande för att presentera attribut inte får behandlas som rättslig grund för den förlitande partens behandling av personuppgifter. Den förlitande parten måste fortfarande ha en egen rättslig grund. EUDI kräver också användargodkännande i alla användningsfall, inklusive fall där den förlitande parten kan ingå i brottsbekämpande myndigheter eller annan statlig myndighet.

Ett bra plånboksgränssnitt kan hjälpa till, men det kan inte lösa problemet med överträdande verifierare på egen hand. Regeln måste finnas på plats innan gränssnittet.

Ett framtida IKK behöver därför båda:

• Kryptografisk verifierarautentisering för att bekräfta vem som frågar
• Policybegränsningar för vad den verifierarkategorin får begära

Utan båda blir “användarens val” ett sätt att vältra över policymisslyckanden på individen.

1. Polis: Verifiera Rätten att Köra, Inte Hela Personen

Polisens vägkantscenario är det mest avgränsade.

EU:s mDL-handbok beskriver det direkt: polis eller andra tjänstemän kontrollerar körkortet när det krävs, inklusive körkortets giltighet och fordonsbehörigheter. I användarresan verifierar officeren körkortet via ett QR-utlöst flöde, Bluetooth, Wi-Fi Aware eller NFC. Det är en avgränsad verifieringsuppgift:

• Är den här personen innehavaren?
• Är intyget giltigt?
• Vilka fordonsbehörigheter och begränsningar gäller?

Tillåtet som standard:

• Namn
• Porträtt
• Körkortsstatus
• Utfärdande- och utgångsdatum
• Kategorier
• Körkortsrelevanta begränsningar
• Utfärdare och jurisdiktion
• Färskhet/statusresultat

Inte tillåtet som standard:

• Hemadress
• Interna identifierare som inte behövs vid vägkantskontroll
• Orelaterade attribut från andra intyg
• Historiska presentationsloggar
• Kommersiell metadata

AAMVA:s implementeringsvägledning förstärker portättaspekten: om porträttet begärs och något annat element lämnas ut, bör porträttet delas så att verifieraren kan koppla data till den person som presenterar det. Samma vägledning anger också att intressenter inte får spåra mDL-innehavare eller mDL-användning utom när det krävs enligt lag.

Polisfallet handlar inte om att staten ska ta emot allt. Det handlar om att staten tar emot de körkortsspecifika uppgifter som behövs för vägkantskontroll. Det är en viktig skillnad.

2. Hyrbilsdiskar: Behörighet, Identitetsmatchning och Ingenting Onödigt

Hyrbilsfallet är mer detaljerat eftersom det egentligen rör sig om två moment: fjärrkontroll före ankomst och avhämtning när en person eller kiosk lämnar över nycklarna.

EU:s mDL-handbok modellerar redan båda. En hyrbilstjänst kan begära mDL:et tillsammans med identitetsbevis vid bokning, validera intygen och senare verifiera kunden personligen vid avhämtning innan fordonet lämnas ut. Användare kan dela sina mDL:er med hyrbilsföretag antingen personligen eller på distans i förväg.

En hyrbilsdisk behöver i första hand inte utreda ett incident. Den behöver avgöra: Kan jag hyra ut det här fordonet till den här kunden under den här bokningen och policyn?

Fjärrkontroll i förväg bör inkludera:

• Identitetskoppling
• Porträtt eller motsvarande identitetsbindande element
• Relevant fordonskategori
• Utfärdande- och utgångsdatum
• Aktuell giltighet
• Möjligen en åldersgräns eller åldersintervall

Avhämtning bör bekräfta:

• Att innehavaren är samma person som genomförde förhandskontrollen
• Aktuell giltighet
• Relevanta behörigheter

Inte nödvändigt som standard:

• Fullständig hemadress när en bokningsprofil redan innehåller kontaktuppgifter
• Fullständigt födelsedatum när ålder-över eller åldersintervall räcker
• Orelaterade identitetsattribut
• Upprepad ompresentation av hela intyget om ett bokningsintyg redan finns

NIST:s nuvarande mDL-arkitektur visar hur den förlitande parten använder DCQL för att begära endast de nödvändiga attributen, och anger uttryckligen att detta stöder dataminimering och innehavarens samtycke genom att strukturera begäran snarare än att behandla intyget som en enda enhet. AAMVA tillägger att applikationen tydligt bör visa vilka uppgifter som begärdes och om verifieraren avser att behålla informationen.

3. Arbetsgivare: En Verifierarkategori, Inte en Öppning in i Full Identitet

W3C:s översikt använder en arbetsgivares digitala system som kontrollerar en universitetsexamen som ett verifierarexempel. Det påminner oss om att arbetsgivarverifiering redan är ett etablerat mönster i intygekosystem.

En arbetsgivare eller flottoperatör kan legitimt behöva veta:

• Om en anställd för närvarande har rätt att köra vissa fordonskategorier
• Om viktiga begränsningar föreligger
• Om behörigheten fortfarande är giltig

Det är ett reellt affärsbehov. Men det motiverar inte automatiskt permanent tillgång till hela körkortsuppgiften, fullständiga identitetsuppgifter eller en kontinuerlig ström av upprepade presentationer.

NIST varnar för att frekvent överföring av en återanvändbar identifierare och att vänja användare vid att upprepade gånger presentera ett identitetsbärande intyg är oönskat, och säger att daglig autentisering bör förlita sig på tekniker utformade för autentisering, såsom passnycklar. NIST föredrar lokal enhetsautentisering framför biometrisk matchning på serversidan eftersom det bättre skyddar integriteten.

Ett framtida IKK bör inte bli ett arbetsplatsbehörighetskort.

För arbetsgivar- och flottanvändning är det rätta mönstret vanligtvis:

• En arbetsrelevant behörighetskontroll
• Kanske ett periodiskt regelefterlevnadsintyg
• Kanske ett påstående om att innehavaren fortfarande är giltig för angivna kategorier
• Men inte en standardöverföring av all körkortsinformation varje gång den anställde loggar in i ett system eller börjar ett arbetspass

Flottans regelefterlevnad är en separat kategori av förlitande part, med ett separat avsett ändamål och en separat utlämningsprofil.

4. Försäkringsbolag: Skadeärenden Är Inte Tillstånd för Kontinuerlig Insyn

Försäkringsfallet är ofta verkligt. I EU:s mDL-användningsmaterial förekommer försäkringsbolag indirekt i hyrbilsscenariot: försäkringsbolag kräver att hyrbilsföretag kontrollerar om den person som hyr bilen har rätt att köra. Försäkringar påverkar redan flödet för körkortsverifiering.

Men det betyder inte att ett försäkringsbolag bör ta emot samma uppgifter som polisen, eller ha permanent rätt att komma åt intyget.

Ett framtida IKK bör behandla försäkringsbolag som en separat verifierarkategori med separata avsedda ändamål:

• Riskbedömning vid tecknande
• Verifiering av hyrbilsrisk
• Skadehantering efter förlust
• Bedrägerigranskning

Det är inte samma ändamål. Enligt EU:s dataskyddsprinciper måste personuppgifter samlas in för angivna ändamål och begränsas till vad som är nödvändigt och proportionerligt för det ändamålet. W3C:s VC-vägledning når samma slutsats tekniskt: verifierare bör bara begära vad som är absolut nödvändigt.

Legitima, händelsespecifika exempel:

• Bevis på att körkortet var giltigt vid den relevanta tidpunkten
• Bevis på relevant fordonsbehörighet
• Bevis på identitetskoppling där det är nödvändigt för ett skadeärende
• Ärendespecifik utlämning

Inte tillåtet som standard:

• Permanent tillgång till det underliggande intyget
• Upprepad generisk verifiering varje gång kunden interagerar med försäkringsbolaget
• Användning av körkortsuppgiften som inloggningstoken
• Insamling av orelaterade attribut

En körkortsuppgift är inte en övervakningsprenumeration. Och den bör inte tyst bli en sådan.

Varför Mellanhänder Måste Vara Synliga

Verkliga marknader innefattar mellanhänder. Hyrbilsplattformar, flottleverantörer, arbetsgivares HR-system och skadehanterare för försäkringsbolag agerar ofta via tredje parter.

EUDI-arkitekturen hanterar detta genom att:

• Behandla mellanhänder som förlitande parter
• Kräva att de registrerar sig
• Kräva att attribut som begärs för den förmedlade förlitande parten är registrerade
• Visa både mellanhanden och den slutliga förlitande parten för användaren
• Förbjuda mellanhänder från att lagra uppgifter om transaktionens innehåll

Ett framtida IKK bör aldrig tillåta ett mönster där användaren tror att de lämnar ut uppgifter till hyrbilsföretaget, men i verkligheten lämnar ut till en osynlig kedja av verifieringsmäklare, analysleverantörer och skadehanterare.

ETSI hjälper till här. Dess certifikatmodell för plånboksförlitande parter inkluderar support-URI:er, avsedd användning, register-URI:er och metadata om tillsynsmyndighet. Det är den typ av maskinläsbar infrastruktur som behövs för att användare ska förstå vem som faktiskt finns i andra änden av begäran och vart de kan vända sig när de vill ha uppgifter raderade eller korrigerade.

Lagring Är En Del av Åtkomstkontroll

De flesta diskussioner om selektiv utlämning slutar för tidigt. De fokuserar på vad som lämnas ut. De fokuserar inte tillräckligt på hur länge det finns kvar efteråt.

Nuvarande vägledning konvergerar redan:

• AAMVA: plånboken måste tydligt informera innehavaren om vilka uppgifter som begärdes och om verifieraren avser att behålla informationen; intressenter får inte spåra innehavare eller mDL-användning utom när det krävs enligt lag
• W3C: innehavarens programvara bör tillhandahålla loggar över information som delats med verifierare, så att överdrivna begäranden kan identifieras
• EUDI: användare bör kunna komma åt transaktionsloggar, rapportera misstänkta begäranden och begära radering

Lagringsklass bör vara en del av utlämningspolicyn i sig:

• Polisens vägkantskontroll: ingen lagring som standard utöver lagstadgad operativ dokumentation
• Hyrbilsförhandskontroll: transaktionspost kopplad till bokning, inte en återanvändbar identitetskopia
• Arbetsgivarens flottregelefterlevnad: regelefterlevnadspost eller intygsresultat, inte råa intygsuppgifter
• Försäkringsskadeärende: skadepost begränsad till ärendet, inte permanent tillgång

Ett framtida IKK som ignorerar lagring är bara delvis integritetsskyddande.

Vad Plånboken Faktiskt Bör Avgöra

Om jag måste reducera hela den här artikeln till en implementeringsregel skulle det vara denna:

Plånboken bör inte svara på “Kan jag presentera det här intyget?” Den bör svara på “Kan jag presentera den här uppsättningen påståenden för den här autentiserade verifieraren, för det här avsedda ändamålet, i det här sammanhanget, under den här lagringsklassen?”

Det beslutet bör styras av åtminstone dessa indata:

• Verifieraridentitet
• Verifierarkategori
• Avsett ändamål
• Registrerat attributomfång
• Utlämningspolicy från utfärdaren, om sådan finns
• Miljö (vägkant, avhämtning, fjärr, flotta, skadeärende)
• Innehavarens godkännande
• Tillämplig lagringspolicy

Standarderna innehåller redan mycket av maskineriet för detta: selektiv utlämning, autentisering av förlitande part, registrerat avsett ändamål, åtkomstcertifikat, utvärdering av utlämningspolicy och ändamålsbundna begäranden. Vad som fortfarande saknas är disciplinen att behandla dessa delar som en sammanhängande utlämningsarkitektur.

Kärnargumentet

Det framtida IKK:et bör inte fråga om uppgifter kan lämnas ut. Det bör fråga:

• Vem frågar?
• För vilket ändamål?
• Under vilken befogenhet?
• I vilket sammanhang?
• Med vilka lagringskonsekvenser?

Polis, hyrbilsdiskar, arbetsgivare och försäkringsbolag är inte fyra logotyper i andra änden av en begäran. De är fyra olika riskmodeller, fyra olika rättsliga sammanhang, fyra olika skäl att fråga — och de bör ge upphov till fyra olika utlämningsuppsättningar.

Det är inte onödig komplexitet. Det är vad ett modernt körkort ser ut som när det slutar behandla varje verifierare som samma verifierare.