Politi, leiebilskranker, arbeidsgivere, forsikringsselskaper: Hvorfor de ikke må se de samme dataene

Den største designfeilen i et fremtidig internasjonalt førerkort (IDP) ville være å behandle alle verifiserere som den samme verifisereren. En politibetjent, en leiebilskranke, en arbeidsgiver og et forsikringsselskap stiller ikke det samme spørsmålet – så de bør heller ikke motta det samme svaret.

Én sjåfør. Én underliggende rett til å kjøre. Én lommebok. Men fire svært forskjellige verifiserere:

• En politibetjent ved veikanten
• En leiebilskranke ved henting
• En arbeidsgiver som kontrollerer flåterettigheter
• Et forsikringsselskap som gjennomgår et krav

Dersom det fremtidige IDP-et viser de samme dataene til alle fire, har systemet allerede feilet. Ikke fordi legitimasjonen er usikker, men fordi utleveringsmodellen er for enkel.

Standardsamfunnet beveger seg allerede bort fra den enkle modellen. W3C sitt arbeid med verifiserbare legitimasjoner beskriver økosystemet rundt utstedere, innehavere og verifiserere, og bruker arbeidsgivere og nettsteder som eksempler på verifiserere. EUs arbeid med mobilt førerkort behandler allerede veikantskontroller og leiebilutleie som separate verifiseringsscenarier, inkludert fjernforberedende deling for leiebiler og kontroll ved personlig fremmøte for politiet. Arkitekturen er allerede utformet for flere verifiseringstyper. Feilen ville være å utforme brukeropplevelsen som om bare én type eksisterer.

Hvorfor det fysiske kortet lærte oss å tenke feil

Et fysisk førerkort lærte oss en vis-alt-tilnærming. Du gir fra deg kortet. Den andre personen ser hva som står på kortet. Det er hele interaksjonen.

Denne tilnærmingen er akseptabel i en papirverden fordi det ikke finnes noe alternativ. Den blir uakseptabel i en digital verden.

W3C VC Data Model 2.0 sier direkte: et førerkort kan inneholde ID-nummer, høyde, vekt, fødselsdato og hjemstedsadresse – men det kan likevel være langt mer enn nødvendig for en gitt transaksjon. Sentrale punkter fra gjeldende standarder:

• W3C beste praksis: støtt selektiv utlevering, og be kun om det som er strengt nødvendig
• EUs databeskyttelsesveiledning: behandling må begrenses til spesifiserte formål, og dataene som behandles må være nødvendige og forholdsmessige
• Det første prinsippet for et fremtidig IDP: samme legitimasjon betyr ikke samme rett til innsyn

Den riktige modellen er policybasert utlevering

Hvis du vil ha en seriøs arkitektur, er den riktige modellen nærmere attributtbasert tilgangskontroll enn digital kortpresentasjon.

NIST SP 800-205 definerer tilgangskontrollbeslutninger som evalueringer av attributter knyttet til subjektet, objektet, den forespurte operasjonen og miljøbetingelsene, opp mot policy. Det er nøyaktig den rette strukturen for et fremtidig IDP:

• Subjekt: sjåføren
• Objekt: de forespurte datafeltene
• Handling: ikke «se førerkort» i abstrakt forstand, men noe spesifikt som «verifiser rett til å kjøre kategori B ved veikanten» eller «verifiser leierettighet for en bestilling»
• Miljø: veikant, leiebilskranke, fjernforhåndssjekk, flåteregistrering og skadesbehandling etter tap er forskjellige miljøer og bør føre til forskjellige beslutninger

NIST bemerker også at attributtsystemer trenger granularitet, styring og mekanismer for reduksjon, gruppering og minimering av attributter.

Så det fremtidige IDP-et bør ikke spørre: Kan denne verifisereren lese førekortet? Det bør spørre: Hvilke påstander kan denne verifisereren motta, for hvilket tiltenkt bruksområde, i hvilket miljø, med hvilke lagringsregler?

En verifiserer bør identifisere seg selv før den ber om noe som helst

Det fremtidige IDP-et bør ikke begynne med at lommeboken viser data. Det bør begynne med at verifisereren beviser hvem den er.

EUDI-arkitekturen er tydelig på dette. Avhengige parter må:

• Registrere hvilke attributter de har til hensikt å be om og til hvilket formål
• Motta tilgangssertifikater
• Autentisere seg overfor lommeboken før noen utlevering
• Kontrolleres mot sin registrerte rekkevidde, der registreringsinformasjon er tilgjengelig

Brukeren kan deretter se hvem som spør, hva det spørres om, og om forespørselen er innenfor den registrerte rekkevidden.

ETSIs nåværende arbeid med sertifikater for lommebokavhengige parter gjør dette mer konkret. Et registreringssertifikat for en lommebokavhengig part kan beskrive partens tiltenkte bruk og attributtene den er registrert til å be om. Det tilhørende tilgangssertifikatet sikrer at forespørselen kommer fra en legitim, autorisert part. ETSI inkluderer også metadata for avhengige parter, som:

• Handelsnavn
• Støtte-URI
• Tiltenkt bruk
• Rettigheter
• Register-URI
• Informasjon om tilsynsmyndighet

Det andre prinsippet for et fremtidig IDP: ingen verifisereridentitet, ingen utlevering.

Hvorfor samtykkeskjermer ikke er tilstrekkelige

Det er en annen feil her: å behandle brukergodkjenning som det samme som juridisk legitimitet.

EUDI-arkitekturen sier eksplisitt at brukergodkjenning til å presentere attributter ikke må behandles som lovlig grunnlag for den avhengige partens behandling av personopplysninger. Den avhengige parten må fortsatt ha sitt eget lovlige grunnlag. EUDI krever også brukergodkjenning i alle brukstilfeller, inkludert tilfeller der den avhengige parten kan være en del av rettshåndhevelse eller et annet statlig organ.

Et godt lommebokgrensesnitt kan hjelpe, men det kan ikke løse verifisererens overtramp alene. Regelen må eksistere før grensesnittet.

Et fremtidig IDP trenger derfor begge deler:

• Kryptografisk verifisererautentisering for å bekrefte hvem som spør
• Policyrestriksjoner på hva den verifisererkategorien kan be om

Uten begge deler blir «brukervalg» en måte å skyve policysvikt over på enkeltpersonen.

1. Politi: Verifiser retten til å kjøre, ikke hele personen

Politiets veikantscenario er det mest fokuserte.

EUs mDL-manual beskriver det direkte: politi eller andre tjenestemenn kontrollerer førekortet når det kreves, inkludert kortets gyldighet og kjøretøyrettigheter. I brukerreisen verifiserer betjenten førekortet via en QR-utløst flyt, Bluetooth, Wi-Fi Aware eller NFC. Det er en fokusert verifiseringsoppgave:

• Er denne personen innehaveren?
• Er legitimasjonen gyldig?
• Hvilke kjøretøyrettigheter og -restriksjoner gjelder?

Tillatt som standard:

• Navn
• Portrettfoto
• Førekortstatus
• Utstednings- og utløpsdatoer
• Kategorier
• Kjøringsrelevante restriksjoner
• Utsteder og jurisdiksjon
• Ferskhet/statusresultat

Ikke tillatt som standard:

• Hjemstedsadresse
• Interne identifikatorer som ikke er nødvendige for veikantbruk
• Ikke-relaterte attributter fra andre attester
• Historiske presentasjonslogger
• Kommersielle metadata

AAMVAs implementeringsveiledning understreker portrettfotopunktet: dersom portrettfotoet er forespurt og et annet element frigis, bør portrettfotoet deles slik at verifisereren kan knytte dataene til personen som presenterer dem. Den samme veiledningen sier også at interessenter ikke må spore mDL-innehavere eller mDL-bruk, bortsett fra der det er påkrevd ved lov.

Politisaken handler ikke om at staten mottar alt. Det handler om at staten mottar de kjøringsspesifikke dataene som trengs for veikanthåndhevelse. Det er en viktig forskjell.

2. Leiebilskranker: Rettighetssjekk, identitetsbekreftelse og ingenting unødvendig

Leiebilsaken er mer detaljert fordi det egentlig er to øyeblikk: fjernforhåndssjekk før ankomst, og henting når en person eller kiosk overleverer nøklene.

EUs mDL-manual modellerer allerede begge. En leiebiltjeneste kan be om mDL-et sammen med identitetsbevis under bestilling, validere attestasjonene, og senere verifisere kunden personlig ved henting før kjøretøyet frigjøres. Brukere kan dele sine mDL-er med leiebilselskaper enten personlig eller på forhånd via fjernkommunikasjon.

En leiebilskranke trenger ikke primært å etterforske en hendelse. Den trenger å avgjøre: Kan jeg leie ut dette kjøretøyet til denne kunden under denne bestillingen og policyen?

Fjernforhåndssjekk bør inkludere:

• Identitetslenkede data
• Portrettfoto eller tilsvarende identitetsbindende element
• Relevant kjøretøykategori
• Utstednings- og utløpsdatoer
• Gjeldende gyldighet
• Eventuelt en aldersgrense eller aldersgruppe

Henting bør bekrefte:

• At innehaveren er den samme personen som fullførte forhåndssjekken
• Gjeldende gyldighet
• Relevante rettigheter

Ikke nødvendig som standard:

• Full hjemstedsadresse når en bestillingsprofil allerede inneholder kontaktopplysninger
• Full fødselsdato der «over-alder» eller aldersgruppe er tilstrekkelig
• Ikke-relaterte identitetsattributter
• Gjentatt re-presentasjon av hele legitimasjonen dersom en bestillingsattest allerede eksisterer

NISTs nåværende mDL-arkitektur viser den avhengige parten som bruker DCQL til å be om bare de nødvendige attributtene, og sier eksplisitt at dette støtter dataminimering og innehaversamtykke ved å strukturere forespørselen i stedet for å behandle legitimasjonen som en enkelt enhet. AAMVA legger til at applikasjonen tydelig bør vise hvilke data som ble forespurt og om verifisereren har til hensikt å beholde informasjonen.

3. Arbeidsgivere: En verifisererkategori, ikke en åpning inn i full identitet

W3C sitt overblikk bruker en arbeidsgivers digitale system som kontrollerer en universitetsgrad som et verifiserereksempel. Det minner oss om at arbeidsgiververifisering allerede er et anerkjent mønster i legitimasjonsøkosystemer.

En arbeidsgiver eller flåteoperatør kan legitimt trenge å vite:

• Om en arbeidstaker for øyeblikket har rett til å kjøre visse kjøretøykategorier
• Om det foreligger viktige restriksjoner
• Om rettigheten fortsatt er gyldig

Det er et reelt forretningsbehov. Men det gir ikke automatisk rett til permanent tilgang til hele førekortet, alle identitetsdata eller en kontinuerlig strøm av gjentatte presentasjoner.

NIST advarer om at hyppig overføring av en gjenbrukbar identifikator og det å venne brukere til å gjentatte ganger presentere en identitetsbærende legitimasjon er uønsket, og sier at daglig autentisering bør baseres på teknologier beregnet for autentisering, som passenøkler. NIST foretrekker lokal enhetsautentisering fremfor biometrisk matching på serversiden fordi det bedre ivaretar personvernet.

Et fremtidig IDP bør ikke bli et adgangskort på arbeidsplassen.

For arbeidsgivers og flåtens bruk er det riktige mønsteret vanligvis:

• En jobbrelevant rettighetssjekk
• Kanskje en periodisk samsvarsattest
• Kanskje en påstand om at innehaveren fortsatt er gyldig for angitte kategorier
• Men ikke en standard overføring av alle kortdata hver gang den ansatte logger inn i et system eller begynner en vakt

Flåtesamsvar er en separat avhengig partskategori, med et separat tiltenkt bruksområde og en separat utleveringsprofil.

4. Forsikringsselskaper: Krav er ikke tillatelse til kontinuerlig innsyn

Forsikringstilfellet er ofte reelt. I EUs mDL-bruksscenariemateriale fremkommer forsikringsselskaper indirekte i leiebilscenariet: forsikringsselskaper krever at leiebilselskaper kontrollerer om personen som leier bilen har rett til å kjøre. Forsikring påvirker allerede kjøreverifiseringsflyten.

Men det betyr ikke at et forsikringsselskap bør motta de samme dataene som politiet, eller en permanent rett til tilgang til legitimasjonen.

Et fremtidig IDP bør behandle forsikringsselskaper som en separat verifisererkategori med separate tiltenkte bruksområder:

• Tegning
• Leiebilrisikobekreftelse
• Skadesbehandling etter tap
• Svindelgjennomgang

Det er ikke samme formål. I henhold til EUs databeskyttelsesprinsipper må personopplysninger innsamles for spesifiserte formål og begrenses til det som er nødvendig og forholdsmessig for det formålet. W3C sitt VC-veiledning kommer til samme konklusjon teknisk: verifiserere bør bare be om det som er strengt nødvendig.

Legitime, hendelsessspesifikke eksempler:

• Bevis for at førekortet var gyldig på det relevante tidspunktet
• Bevis for relevant kjøretøyrettighet
• Bevis for identitetslenkede data der det er nødvendig for et krav
• Kravspesifikk utlevering

Ikke tillatt som standard:

• Vedvarende tilgang til den underliggende legitimasjonen
• Gjentatt generisk verifisering hver gang kunden samhandler med forsikringsselskapet
• Bruk av førekortet som et innloggingstoken
• Innsamling av ikke-relaterte attributter

En kjørekortslegitmasjon er ikke et overvåkingsabonnement. Og den bør ikke stille og rolig bli det.

Hvorfor mellommenn må være synlige

Reelle markeder involverer mellommenn. Leiebilplattformer, flåteleverandører, arbeidsgiverens HR-systemer og behandlere av forsikringskrav handler ofte gjennom tredjeparter.

EUDI-arkitekturen håndterer dette ved å:

• Behandle mellommenn som avhengige parter
• Kreve at de registrerer seg
• Kreve at attributter forespurt for den mellomledige avhengige parten er registrert
• Vise både mellommannen og slutt-avhengig part til brukeren
• Forby mellommenn å lagre data om innholdet i transaksjonen

Et fremtidig IDP bør aldri tillate et mønster der brukeren tror de utleverer til leiebilselskapet, men i virkeligheten utleverer til en usynlig verifiseringsmegler, analyseprosessor og skadebehandlerkjede.

ETSI hjelper her. Sertifikatmodellen for lommebokavhengige parter inkluderer støtte-URIer, tiltenkt bruk, register-URIer og metadata for tilsynsmyndigheter. Det er den typen maskinlesbar infrastruktur som er nødvendig for at brukere skal forstå hvem som faktisk er i den andre enden av forespørselen og hvor de kan henvende seg når de ønsker sletting eller retting.

Oppbevaring er en del av tilgangskontroll

De fleste diskusjoner om selektiv utlevering slutter for tidlig. De fokuserer på hva som utleveres. De fokuserer ikke nok på hvor lenge det forblir etterpå.

Gjeldende veiledning konvergerer allerede:

• AAMVA: lommeboken må tydelig fortelle innehaveren hvilke data som ble forespurt og om verifisereren har til hensikt å beholde dem; interessenter må ikke spore innehavere eller mDL-bruk, bortsett fra der det er påkrevd ved lov
• W3C: innehaverprogramvare bør gi logger over informasjon delt med verifiserere, slik at overdrevne forespørsler kan identifiseres
• EUDI: brukere bør ha tilgang til transaksjonslogger, rapportere mistenkelige forespørsler og be om sletting

Oppbevaringsklasse bør være en del av selve utleveringspolicyen:

• Politiets veikantsjekk: ingen oppbevaring som standard utover lovlig operasjonsregistrering
• Leieforhåndssjekk: transaksjonsregistrering knyttet til bestilling, ikke en gjenbrukbar identitetskopi
• Arbeidsgiverens flåtesamsvar: samsvarsregistrering eller attesteringsresultat, ikke rå legitimasjonsdata
• Forsikringskrav: kravregistrering begrenset til kravet, ikke permanent tilgang

Et fremtidig IDP som ignorerer oppbevaring er bare delvis personvernbevarende.

Hva lommeboken faktisk bør bestemme

Hvis jeg måtte redusere hele denne artikkelen til én implementeringsregel, ville det være denne:

Lommeboken bør ikke svare på «Kan jeg presentere denne legitimasjonen?» Den bør svare på «Kan jeg presentere dette settet med påstander til denne autentiserte verifisereren, for dette tiltenkte bruksområdet, i denne konteksten, under denne oppbevaringsklassen?»

Den beslutningen bør drives av minst disse inndataene:

• Verifisereridentitet
• Verifisererkategori
• Tiltenkt bruk
• Registrert attributtomfang
• Utleveringspolicy fra utsteder, hvis tilgjengelig
• Miljø (veikant, henting, fjernt, flåte, krav)
• Innehavergodkjenning
• Gjeldende oppbevaringspolicy

Standardene inneholder allerede mye av mekanismen for dette: selektiv utlevering, autentisering av avhengig part, registrert tiltenkt bruk, tilgangssertifikater, evaluering av utleveringspolicy og formålsbundne forespørsler. Det som fortsatt mangler er disiplinen til å behandle disse delene som én sammenhengende utleveringsarkitektur.

Kjerneargumentet

Det fremtidige IDP-et bør ikke spørre om data kan utleveres. Det bør spørre:

• Hvem spør?
• For hvilket formål?
• Under hvilken myndighet?
• I hvilken kontekst?
• Med hvilke oppbevaringskonsekvenser?

Politi, leiebilskranker, arbeidsgivere og forsikringsselskaper er ikke fire logoer i den andre enden av en forespørsel. De er fire forskjellige risikomodeller, fire forskjellige juridiske kontekster, fire forskjellige grunner til å spørre – og de bør gi fire forskjellige utleveringssett.

Det er ikke unødvendig kompleksitet. Det er hva en moderne kjørelegitmasjon ser ut som når den slutter å behandle alle verifiserere som den samme verifisereren.