Politi, Udlejningsskranker, Arbejdsgivere, Forsikringsselskaber: Hvorfor De Ikke Må Se De Samme Data

Den største designfejl i et fremtidigt Internationalt Kørekort (IKK) ville være at behandle alle verificerende parter som den samme verificerende part. En politibetjent, en biludlejningsskranke, en arbejdsgiver og et forsikringsselskab stiller ikke det samme spørgsmål — så de bør heller ikke få det samme svar.

Én fører. Én underliggende ret til at køre. Én tegnebog. Men fire meget forskellige verificerende parter:

• En politibetjent ved vejkanten
• En biludlejningsskranke ved afhentning
• En arbejdsgiver der kontrollerer køretøjsrettigheder
• Et forsikringsselskab der behandler en skadesanmeldelse

Hvis det fremtidige IKK viser de samme data til alle fire, er systemet allerede fejlslagent. Ikke fordi legitimationsbeviset er usikkert, men fordi udleveringsmodellen er for simpel.

Standardiseringssamfundet bevæger sig allerede væk fra den simple model. W3C’s arbejde med verificerbare legitimationsoplysninger beskriver økosystemet omkring udstedere, indehavere og verificerende parter, med arbejdsgivere og hjemmesider som eksempler på verificerende parter. EU’s arbejde med mobile kørekort behandler allerede vejkontroller og biludlejninger som separate verifikationsscenarier, herunder fjernforhåndsdeling til udlejninger og personlige kontroller for politiet. Arkitekturen er allerede designet til flere typer verificerende parter. Fejlen ville være at designe brugeroplevelsen, som om der kun fandtes én type.

Hvorfor Det Fysiske Kort Lærte Os at Tænke Forkert

Et fysisk kørekort lærte os en vis-alt-tilgang. Du afleverer kortet. Den anden person ser, hvad der står på kortet. Det er hele interaktionen.

Denne tilgang er acceptabel i en papirverden, fordi der ikke er noget alternativ. Den bliver uacceptabel i en digital verden.

W3C VC Data Model 2.0 fastslår direkte: et kørekort kan indeholde ID-nummer, højde, vægt, fødselsdato og hjemmeadresse — men det kan stadig være langt mere end nødvendigt for en given transaktion. Centrale punkter fra de nuværende standarder:

• W3C’s bedste praksis: understøt selektiv videregivelse, og anmod kun om det strengt nødvendige
• EU’s databeskyttelsesvejledning: behandling skal begrænses til specificerede formål, og de behandlede data skal være nødvendige og forholdsmæssige
• Det første princip for et fremtidigt IKK: samme legitimationsbevis betyder ikke samme ret til indsigt

Den Rette Model Er Politikbaseret Videregivelse

Hvis man ønsker en seriøs arkitektur, er den rette model tættere på attributbaseret adgangskontrol end på digital kortpræsentation.

NIST SP 800-205 definerer adgangskontrolbeslutninger som evalueringer af attributter forbundet med subjektet, objektet, den ønskede handling og miljøbetingelserne — op mod en politik. Det er præcis den rette struktur for et fremtidigt IKK:

• Subjekt: føreren
• Objekt: de ønskede datafelter
• Handling: ikke “se kørekort” i abstrakt forstand, men noget specifikt som “bekræft ret til at køre kategori B ved vejkanten” eller “bekræft udlejningsberettigelse til en booking”
• Miljø: vejkanten, udlejningsskranken, fjernforhåndskontrol, flåderegistrering og skadesbehandling efter hændelse er forskellige miljøer og bør føre til forskellige beslutninger

NIST bemærker også, at attributsystemer kræver granularitet, styring og mekanismer til reduktion, gruppering og minimering af attributter.

Det fremtidige IKK bør derfor ikke spørge: Kan denne verificerende part læse kørekortet? Det bør spørge: Hvilke oplysninger må denne verificerende part modtage, til hvilket tiltænkt formål, i dette miljø, og med hvilke opbevaringsregler?

En Verificerende Part Skal Identificere Sig Selv Inden Enhver Anmodning

Det fremtidige IKK bør ikke begynde med, at tegnebogen viser data. Det bør begynde med, at den verificerende part beviser, hvem den er.

EUDI-arkitekturen er klar på dette punkt. Afhængige parter skal:

• Registrere hvilke attributter de agter at anmode om og til hvilket formål
• Modtage adgangscertifikater
• Autentificere sig over for tegnebogen inden enhver videregivelse
• Blive kontrolleret mod deres registrerede omfang, hvor registreringsoplysninger er tilgængelige

Brugeren kan derefter se, hvem der spørger, hvad der anmodes om, og om anmodningen er inden for det registrerede omfang.

ETSI’s igangværende arbejde med certifikater for afhængige parter i tegnebøger gør dette mere konkret. Et registreringscertifikat for en afhængig part i en tegnebog kan beskrive den afhængige parts tiltænkte brug og de attributter, den er registreret til at anmode om. Det tilhørende adgangscertifikat sikrer, at anmodningen kommer fra en legitim, autoriseret part. ETSI inkluderer også metadata om den afhængige part, såsom:

• Handelsnavn
• Support-URI
• Tiltænkt brug
• Rettigheder
• Register-URI
• Oplysninger om tilsynsmyndighed

Det andet princip for et fremtidigt IKK: ingen verificerbar identitet, ingen videregivelse.

Hvorfor Samtykkeskærme Ikke Er Tilstrækkelige

Der er en anden fejl her: at behandle brugergodkendelse som det samme som retlig legitimitet.

EUDI-arkitekturen fastslår eksplicit, at brugergodkendelse til at præsentere attributter ikke må behandles som retsgrundlag for den afhængige parts behandling af personoplysninger. Den afhængige part skal stadig have sit eget lovlige grundlag. EUDI kræver også brugergodkendelse i alle anvendelsestilfælde, herunder tilfælde hvor den afhængige part kan være en del af retshåndhævelsen eller et andet offentligt organ.

En god tegnebogsbrugerflade kan hjælpe, men den kan ikke løse problemet med verificerende parters overskridelse på egen hånd. Reglen skal eksistere, inden brugerfladen etableres.

Et fremtidigt IKK kræver derfor begge dele:

• Kryptografisk verificeringsautentificering til at bekræfte, hvem der spørger
• Politikbegrænsninger for, hvad den pågældende verificeringskategori må anmode om

Uden begge dele bliver “brugervalg” en måde at vælte politiksvigt over på den enkelte.

1. Politiet: Bekræft Retten til at Køre, Ikke Hele Personen

Politiets vejkantscenarie er det mest fokuserede.

EU’s mDL-manual beskriver det direkte: politi eller andre myndigheder kontrollerer kørekortet, når det kræves, herunder kørekortets gyldighed og køretøjsrettigheder. I brugerrejsen verificerer betjenten kørekortet via et QR-trigget forløb, Bluetooth, Wi-Fi Aware eller NFC. Det er en fokuseret verificeringsopgave:

• Er denne person indehaveren?
• Er legitimationsbeviset gyldigt?
• Hvilke køretøjsrettigheder og -begrænsninger gælder?

Tilladt som standard:

• Navn
• Portræt
• Kørekortstatus
• Udstedelsesdato og udløbsdato
• Kategorier
• Kørerelevante begrænsninger
• Udsteder og jurisdiktion
• Aktualitets-/statusresultat

Ikke tilladt som standard:

• Hjemmeadresse
• Interne identifikatorer, der ikke er nødvendige til brug ved vejkanten
• Ikke-relaterede attributter fra andre attesteringer
• Historiske præsentationslogge
• Kommercielle metadata

AAMVA’s implementeringsvejledning understreger portrætpunktet: hvis portrættet anmodes om, og et andet element frigives, bør portrættet deles, så den verificerende part kan koble dataene til den person, der præsenterer dem. Den samme vejledning fastslår også, at interessenter ikke må spore mDL-indehavere eller mDL-brug, medmindre det er lovpåkrævet.

Politisagen handler ikke om, at staten modtager alt. Den handler om, at staten modtager de kørselsspecifikke data, der er nødvendige for vejkantshåndhævelse. Det er en vigtig forskel.

2. Udlejningsskranker: Berettigelse, Identitetsbekræftelse og Intet Unødvendigt

Udlejningssagen er mere detaljeret, fordi der reelt er to øjeblikke: fjernforhåndskontrol inden ankomst og afhentning, når en person eller en kiosk udleverer nøglerne.

EU’s mDL-manual modellerer allerede begge. En biludlejningstjeneste kan anmode om mDL’et sammen med identitetsbevis under booking, validere attesteringerne og senere verificere kunden personligt ved afhentning inden udlevering af køretøjet. Brugere kan dele deres mDL’er med biludlejningsfirmaer enten personligt eller eksternt på forhånd.

En udlejningsskranke behøver ikke primært at undersøge en hændelse. Den skal afgøre: Kan jeg udleje dette køretøj til denne kunde under denne booking og politik?

Fjernforhåndskontrol bør omfatte:

• Identitetskæde
• Portræt eller tilsvarende identitetsbindende element
• Relevant køretøjskategori
• Udstedelsesdato og udløbsdato
• Aktuel gyldighed
• Eventuelt en aldersgrænse eller aldersgruppe

Afhentning bør bekræfte:

• At indehaveren er den samme person, der gennemførte forhåndskontrollen
• Aktuel gyldighed
• Relevante rettigheder

Ikke nødvendigt som standard:

• Fuld hjemmeadresse, når en bookingprofil allerede indeholder kontaktoplysninger
• Fuld fødselsdato, hvor alder-over eller aldersgruppe er tilstrækkelig
• Ikke-relaterede identitetsattributter
• Gentagen genpræsentation af det fulde legitimationsbevis, hvis der allerede findes en bookingattestering

NIST’s aktuelle mDL-arkitektur viser den afhængige part bruge DCQL til kun at anmode om de nødvendige attributter, og fastslår eksplicit, at dette understøtter dataminimering og indehaversamtykke ved at strukturere anmodningen frem for at behandle legitimationsbeviset som en enkelt enhed. AAMVA tilføjer, at applikationen tydeligt bør vise, hvilke data der blev anmodet om, og om den verificerende part agter at gemme oplysningerne.

3. Arbejdsgivere: En Verificeringskategori, Ikke en Indgang til Fuld Identitet

W3C’s oversigt bruger en arbejdsgivers digitale system, der kontrollerer en universitetsuddannelse, som eksempel på en verificerende part. Det minder os om, at arbejdsgiververifikation allerede er et anerkendt mønster i legitimationsøkosystemer.

En arbejdsgiver eller flådeoperatør kan legitimt have behov for at vide:

• Om en medarbejder i øjeblikket er berettiget til at køre bestemte køretøjskategorier
• Om der eksisterer væsentlige begrænsninger
• Om rettigheden forbliver gyldig

Det er et reelt forretningsbehov. Men det berettiger ikke automatisk permanent adgang til hele kørekortet, de fulde identitetsoplysninger eller en kontinuerlig strøm af gentagne præsentationer.

NIST advarer om, at hyppig transmission af en genbrugelig identifikator og konditionering af brugere til gentagne gange at præsentere et identitetsbærende legitimationsbevis er uønsket, og fastslår, at den daglige autentificering bør basere sig på teknologier, der er designet til autentificering, såsom adgangsnøgler. NIST foretrækker lokal enhedsautentificering frem for serverbaseret biometrisk matchning, fordi det bedre bevarer privatlivets fred.

Et fremtidigt IKK bør ikke blive et adgangskort på arbejdspladsen.

For arbejdsgivere og flådeoperatører er det rette mønster normalt:

• En jobrelevant rettighedskontrol
• Eventuelt en periodisk overensstemmelsesattering
• Eventuelt en oplysning om, at indehaveren fortsat er gyldig for specificerede kategorier
• Men ikke en standardoverførsel af alle kørekortdata, hver gang medarbejderen logger ind i et system eller påbegynder en vagt

Flådeoverholdelse er en separat kategori af afhængige parter med et separat tiltænkt formål og en separat videregivelsesprofil.

4. Forsikringsselskaber: Skadesanmeldelser Er Ikke Tilladelse til Kontinuerlig Indsigt

Forsikringssagen er ofte reel. I EU’s mDL-anvendelsestilfældemateriale optræder forsikringsselskaber indirekte i udlejningsscenariet: forsikringsselskaber kræver, at biludlejningsfirmaer kontrollerer, om den person, der lejer bilen, har ret til at køre. Forsikring påvirker allerede køreverifikationsforløbet.

Men det betyder ikke, at et forsikringsselskab bør modtage de samme data som politiet eller have en permanent ret til at tilgå legitimationsbeviset.

Et fremtidigt IKK bør behandle forsikringsselskaber som en separat verificeringskategori med separate tiltænkte formål:

• Tegning af forsikring
• Udlejningsrisikovurdering
• Skadesbehandling efter hændelse
• Svindelsagsbehandling

Det er ikke det samme formål. I henhold til EU’s databeskyttelsesprincipper skal personoplysninger indsamles til specificerede formål og begrænses til det, der er nødvendigt og forholdsmæssigt for det pågældende formål. W3C’s VC-vejledning når den samme konklusion teknisk: verificerende parter bør kun anmode om det strengt nødvendige.

Legitime, hændelsesspecifikke eksempler:

• Bevis for at kørekortet var gyldigt på det relevante tidspunkt
• Bevis for relevant køretøjsrettighed
• Bevis for identitetskæde, hvor det er nødvendigt for en skadesanmeldelse
• Skadesspecifik videregivelse

Ikke tilladt som standard:

• Vedvarende adgang til det underliggende legitimationsbevis
• Gentagen generisk verificering, hver gang kunden interagerer med forsikringsselskabet
• Brug af kørekortet som login-token
• Indsamling af ikke-relaterede attributter

Et kørekort er ikke et overvågningsabonnement. Og det bør ikke stille og roligt blive til et.

Hvorfor Mellemmænd Skal Være Synlige

Reelle markeder involverer mellemmænd. Udlejningsplatforme, flådeleverandører, arbejdsgivernes HR-systemer og forsikringsskadesbehandlere handler ofte gennem tredjeparter.

EUDI-arkitekturen håndterer dette ved at:

• Behandle mellemmænd som afhængige parter
• Kræve, at de registrerer sig
• Kræve, at attributter anmodet om for den formidlede afhængige part er registreret
• Vise både mellemmanden og den endelige afhængige part til brugeren
• Forbyde mellemmænd at gemme data om transaktionens indhold

Et fremtidigt IKK bør aldrig tillade et mønster, hvor brugeren tror, de videregiver til udlejningsfirmaet, mens de i virkeligheden videregiver til en usynlig verificeringsmægler, analysebehandler og skadesbehandlerkæde.

ETSI hjælper her. Dets certifikatmodel for afhængige parter i tegnebøger inkluderer support-URI’er, tiltænkt brug, register-URI’er og metadata om tilsynsmyndigheder. Det er den type maskinlæsbar infrastruktur, der er nødvendig for, at brugerne kan forstå, hvem der faktisk befinder sig i den anden ende af anmodningen, og hvor de skal henvende sig, hvis de ønsker sletning eller rettelse.

Opbevaring Er En Del af Adgangskontrol

De fleste diskussioner om selektiv videregivelse slutter for tidligt. De fokuserer på, hvad der videregives. De fokuserer ikke nok på, hvor længe det forbliver efterfølgende.

Den nuværende vejledning er allerede ved at konvergere:

• AAMVA: tegnebogen skal tydeligt informere indehaveren om, hvilke data der blev anmodet om, og om den verificerende part agter at gemme dem; interessenter må ikke spore indehavere eller mDL-brug, medmindre det er lovpåkrævet
• W3C: indehaversoftware bør give logge over oplysninger delt med verificerende parter, så overdrevne anmodninger kan identificeres
• EUDI: brugere bør have adgang til transaktionslogge, kunne indberette mistænkelige anmodninger og anmode om sletning

Opbevaringsklasse bør være en del af videregivelsespolitikken selv:

• Politiets vejkantskontrol: ingen opbevaring som standard ud over lovpligtigt driftsregister
• Udlejningsforhåndskontrol: transaktionspost knyttet til booking, ikke en genbrugelig identitetskopi
• Arbejdsgiverens flådeoverholdelse: overensstemmelsespost eller attesteringsresultat, ikke rå legitimationsbevisdata
• Forsikringsselskabets skadesanmeldelse: skadespost begrænset til den pågældende sag, ikke permanent adgang

Et fremtidigt IKK, der ignorerer opbevaring, er kun delvist privatlivsbevarende.

Hvad Tegnebogen Faktisk Bør Afgøre

Hvis jeg skulle reducere hele denne artikel til én implementeringsregel, ville det være denne:

Tegnebogen bør ikke besvare “Kan jeg præsentere dette legitimationsbevis?” Den bør besvare “Kan jeg præsentere dette sæt af oplysninger til denne autentificerede verificerende part, til dette tiltænkte formål, i denne kontekst, under denne opbevaringsklasse?”

Denne afgørelse bør som minimum drives af følgende input:

• Verificerende parts identitet
• Verificerende parts kategori
• Tiltænkt formål
• Registreret attributomfang
• Videregivelsespolitik fra udstederen, hvis til stede
• Miljø (vejkant, afhentning, fjern, flåde, skadesanmeldelse)
• Indehaverens godkendelse
• Gældende opbevaringspolitik

Standarderne indeholder allerede meget af mekanikken til dette: selektiv videregivelse, autentificering af afhængige parter, registreret tiltænkt brug, adgangscertifikater, evaluering af videregivelsespolitik og formålsbundne anmodninger. Det, der stadig mangler, er disciplinen til at behandle disse dele som én sammenhængende videregivelsesarkitektur.

Kerneargumentet

Det fremtidige IKK bør ikke spørge, om data kan videregives. Det bør spørge:

• Hvem spørger?
• Til hvilket formål?
• Under hvilken myndighed?
• I hvilken kontekst?
• Med hvilke opbevaringskonsekvenser?

Politi, udlejningsskranker, arbejdsgivere og forsikringsselskaber er ikke fire logoer i den anden ende af en anmodning. De er fire forskellige risikomodeller, fire forskellige juridiske kontekster, fire forskellige grunde til at spørge — og de bør producere fire forskellige videregivelsessæt.

Det er ikke unødvendig kompleksitet. Det er, hvad et moderne kørekort ser ud som, når det holder op med at behandle alle verificerende parter som den samme verificerende part.