Policija, Rent-a-car šalteri, Poslodavci, Osiguravatelji: Zašto ne smiju vidjeti iste podatke

Najveća greška u dizajnu budućeg Međunarodne vozačke dozvole (MVD) bila bi tretirati svakog verifikatora kao istog verifikatora. Policijski službenik, šalter rent-a-car agencije, poslodavac i osiguravatelj ne postavljaju isto pitanje — pa ne bi trebali dobivati isti odgovor.

Jedan vozač. Jedno temeljno pravo na vožnju. Jedan novčanik. Ali četiri vrlo različita verifikatora:

• Policijski službenik na cesti
• Šalter rent-a-car agencije pri preuzimanju vozila
• Poslodavac koji provjerava podobnost za vozni park
• Osiguravatelj koji razmatra odštetni zahtjev

Ako budući MVD prikazuje iste podatke sva četiri verifikatora, sistem je već zakazao. Ne zato što akreditiv nije siguran, nego zato što je model otkrivanja podataka previše jednostavan.

Zajednica za standardizaciju već se odmičuje od tog jednostavnog modela. W3C-ov rad na provjerljivim akreditivima opisuje ekosistem izdavatelja, nositelja i verifikatora, koristeći poslodavce i web stranice kao primjere verifikatora. Rad EU-a na mobilnoj vozačkoj dozvoli već tretira provjere na cesti i iznajmljivanje automobila kao odvojene scenarije verifikacije, uključujući daljinsko prethodno dijeljenje za iznajmljivanje i provjere licem u lice za policiju. Arhitektura je već dizajnirana za više vrsta verifikatora. Greška bi bila dizajnirati korisničko iskustvo kao da postoji samo jedna vrsta.

Zašto nas je fizička kartica naučila pogrešno razmišljati

Fizička dozvola nas je navikla na pristup pokazivanja svega. Predate karticu. Druga osoba vidi što piše na kartici. To je cijela interakcija.

Taj pristup je prihvatljiv u papirnom svijetu jer nema alternative. U digitalnom postaje neprihvatljiv.

W3C VC Data Model 2.0 direktno navodi: vozačka dozvola može sadržavati broj dokumenta, visinu, težinu, datum rođenja i kućnu adresu — ali to može biti daleko više nego što je potrebno za određenu transakciju. Ključne točke iz trenutnih standarda:

• W3C najbolja praksa: podržati selektivno otkrivanje podataka i zahtijevati samo ono što je nužno potrebno
• Smjernice EU-a o zaštiti podataka: obrada mora biti ograničena na određene svrhe, a podaci koji se obrađuju moraju biti nužni i proporcionalni
• Prvi princip budućeg MVD-a: isti akreditiv ne znači isto pravo na uvid

Pravi model je otkrivanje podataka zasnovano na politikama

Ako želite ozbiljnu arhitekturu, pravi model je bliži kontroli pristupa zasnovanoj na atributima nego prezentaciji digitalne kartice.

NIST SP 800-205 definira odluke o kontroli pristupa kao evaluacije atributa povezanih s subjektom, objektom, zatraženom radnjom i uvjetima okoline, u skladu s politikom. To je upravo prava struktura za budući MVD:

• Subjekt: vozač
• Objekt: zatražena podatkovna polja
• Radnja: ne “vidi dozvolu” u apstraktnom smislu, već nešto konkretno poput “verificiraj pravo na upravljanje vozilom kategorije B na cesti” ili “verificiraj podobnost za iznajmljivanje za određenu rezervaciju”
• Okolina: cesta, šalter rent-a-car agencije, daljinska prethodna provjera, priključivanje u vozni park i pregled odštetnog zahtjeva nakon gubitka — to su različite okoline i trebaju voditi do različitih odluka

NIST također napominje da sistemi atributa trebaju granularnost, upravljanje i mehanizme za smanjenje, grupiranje i minimizaciju atributa.

Dakle, budući MVD ne bi trebao pitati: Može li ovaj verifikator čitati dozvolu? Trebao bi pitati: Koje tvrdnje ovaj verifikator smije primiti, za koju namjeravanu upotrebu, u ovoj okolini, uz koja pravila zadržavanja?

Verifikator se mora identificirati prije nego što išta zatraži

Budući MVD ne bi trebao početi time da novčanik prikazuje podatke. Trebao bi početi time da verifikator dokaže ko je.

EUDI arhitektura je jasna u ovom pogledu. Oslonjena strana mora:

• Registrirati koje atribute namjerava zatražiti i u koju svrhu
• Primiti pristupne certifikate
• Autentificirati se prema novčaniku prije bilo kakvog otkrivanja podataka
• Biti provjeren u odnosu na registrirani opseg, gdje su dostupne informacije o registraciji

Korisnik tada može vidjeti ko pita, što se traži i je li zahtjev unutar registriranog opsega.

ETSI-jev trenutni rad na certifikatima oslonjenoj strani novčanika ovo čini konkretnijim. Registracijski certifikat oslonjenoj strani novčanika može opisati namjeravanu upotrebu oslonjenoj strani i atribute koje je registrirala za traženje. Povezani pristupni certifikat postoji kako bi se osiguralo da zahtjev dolazi od legitimne, ovlaštene strane. ETSI također uključuje metapodatke oslonjenoj strani kao što su:

• Trgovački naziv
• URI za podršku
• Namjeravana upotreba
• Ovlaštenja
• URI registra
• Informacije o nadzornom tijelu

Drugi princip budućeg MVD-a: nema identiteta verifikatora, nema otkrivanja podataka.

Zašto ekrani za saglasnost nisu dovoljni

Ovdje postoji još jedna greška: tretirati odobrenje korisnika kao isto što i pravna legitimnost.

EUDI arhitektura eksplicitno navodi da odobrenje korisnika za prezentiranje atributa ne smije biti tretirano kao zakonita osnova za obradu ličnih podataka oslonjenoj strani. Oslonjena strana i dalje mora imati vlastitu zakonitu osnovu. EUDI također zahtijeva odobrenje korisnika u svim slučajevima upotrebe, uključujući slučajeve u kojima oslonjena strana može biti dio tijela za provođenje zakona ili druge vladine agencije.

Dobro sučelje novčanika može pomoći, ali samo po sebi ne može riješiti problem prekoračenja ovlaštenja verifikatora. Pravilo mora postojati prije sučelja.

Budući MVD stoga treba oboje:

• Kriptografsku autentifikaciju verifikatora radi potvrde ko pita
• Ograničenja politike o tome što ta kategorija verifikatora smije zatražiti

Bez oboje, “korisnički izbor” postaje način prenošenja propusta politike na pojedinca.

1. Policija: Verificiraj pravo na vožnju, ne cijelu osobu

Scenario provjere policije na cesti je najfokusiraniji.

EU-ov priručnik za mDL direktno to opisuje: policija ili drugi službenici provjeravaju dozvolu kada je potrebno, uključujući valjanost dozvole i ovlaštenja za vozilo. U korisničkom putu, službenik verificira dozvolu putem toka pokrenutog QR kodom, Bluetootha, Wi-Fi Aware ili NFC-a. To je fokusiran zadatak verifikacije:

• Je li ova osoba nositelj?
• Je li akreditiv valjan?
• Koja ovlaštenja za vozilo i ograničenja se primjenjuju?

Podrazumijevano dozvoljeno:

• Ime
• Fotografija
• Status dozvole
• Datumi izdavanja i isteka
• Kategorije
• Ograničenja relevantna za vožnju
• Izdavatelj i nadležnost
• Rezultat aktualnosti/statusa

Podrazumijevano nije dozvoljeno:

• Kućna adresa
• Interni identifikatori koji nisu potrebni za upotrebu na cesti
• Nepovezani atributi iz drugih potvrda
• Historijski zapisi prezentacija
• Komercijalni metapodaci

AAMVA-ove smjernice za implementaciju pojačavaju točku o fotografiji: ako se fotografija traži i bilo koji drugi element se otkrije, fotografija bi trebala biti podijeljena kako bi verifikator mogao povezati podatke s osobom koja ih prezentira. Iste smjernice također kažu da dionici ne smiju pratiti nositelje mDL-a ili upotrebu mDL-a osim kada je to zahtijevano zakonom.

Policijski slučaj nije o tome da država prima sve. Radi se o tome da država prima podatke specifične za vožnju potrebne za provođenje zakona na cesti. To je važna razlika.

2. Rent-a-car šalteri: Podobnost, podudaranje identiteta i ništa nepotrebno

Slučaj iznajmljivanja je detaljniji jer zapravo postoje dva trenutka: daljinska prethodna provjera prije dolaska i preuzimanje vozila kada osoba ili kiosk predaje ključeve.

EU-ov priručnik za mDL već modelira oboje. Usluga iznajmljivanja automobila može zatražiti mDL zajedno s dokazom identiteta pri rezervaciji, validirati potvrde i kasnije osobno verificirati korisnika pri preuzimanju vozila prije puštanja vozila. Korisnici mogu dijeliti svoje mDL-ove s rent-a-car kompanijama bilo osobno ili daljinski unaprijed.

Šalter rent-a-car agencije primarno ne treba istraživati incident. Treba donijeti odluku: Mogu li iznajmiti ovo vozilo ovom korisniku u okviru ove rezervacije i police?

Daljinska prethodna provjera trebala bi uključivati:

• Vezu identiteta
• Fotografiju ili ekvivalentni element vezivanja identiteta
• Relevantnu kategoriju vozila
• Datume izdavanja i isteka
• Trenutnu valjanost
• Eventualno prag starosti ili dobnu grupu

Preuzimanje vozila trebalo bi potvrditi:

• Da je nositelj ista osoba koja je završila prethodnu provjeru
• Trenutnu valjanost
• Relevantna ovlaštenja

Podrazumijevano nije potrebno:

• Puna kućna adresa kada profil rezervacije već sadrži kontaktne podatke
• Pun datum rođenja gdje je dovoljan pokazatelj starosti ili dobna grupa
• Nepovezani atributi identiteta
• Ponavljano ponovno prezentiranje punog akreditiva ako već postoji potvrda rezervacije

NIST-ova trenutna arhitektura mDL-a pokazuje oslonjenuj strani kako koristi DCQL za traženje samo potrebnih atributa i eksplicitno kaže da ovo podržava minimizaciju podataka i saglasnost nositelja strukturiranjem zahtjeva umjesto tretiranja akreditiva kao jedinstvene cjeline. AAMVA dodaje da aplikacija treba jasno prikazati koje podatke je zatraženo i namjerava li verifikator zadržati informacije.

3. Poslodavci: Kategorija verifikatora, ne ulaz u puni identitet

W3C-ov pregled koristi digitalni sistem poslodavca koji provjerava univerzitetsku diplomu kao primjer verifikatora. To nas podsjeća da je verifikacija od strane poslodavca već priznat obrazac u ekosistemima akreditiva.

Poslodavac ili operater voznog parka može legitimno trebati znati:

• Je li radnik trenutno ovlašten upravljati određenim kategorijama vozila
• Postoje li ključna ograničenja
• Je li ovlaštenje i dalje valjano

To je stvarna poslovna potreba. Ali to automatski ne opravdava stalni pristup cjelokupnom vozačkom akreditivu, punim podacima o identitetu ili kontinuiranom toku ponavljanih prezentacija.

NIST upozorava da je često prenošenje višekratno upotrebljivog identifikatora i navikavanje korisnika na ponavljano prezentiranje akreditiva koji nosi identitet nepoželjno, te kaže da bi svakodnevna autentifikacija trebala se oslanjati na tehnologije dizajnirane za autentifikaciju, kao što su pristupni ključevi. NIST preferira lokalnu autentifikaciju uređaja nad biometrijskim podudaranjem na strani servera jer bolje čuva privatnost.

Budući MVD ne bi trebao postati propusnica za pristup radnom mjestu.

Za upotrebu od strane poslodavca i voznog parka, pravi obrazac je obično:

• Provjera ovlaštenja relevantnog za posao
• Možda periodična potvrda usklađenosti
• Možda tvrdnja da nositelj ostaje valjan za određene kategorije
• Ali ne podrazumijevani prijenos svih podataka o dozvoli svaki put kada se zaposlenik prijavi u sistem ili počne smjenu

Usklađenost voznog parka je zasebna kategorija oslonjenoj strani, s posebnom namjeravanom upotrebom i posebnim profilom otkrivanja podataka.

4. Osiguravatelji: Odštetni zahtjevi nisu dozvola za kontinuirani nadzor

Slučaj osiguranja je često stvaran. U materijalu EU-a o slučajevima upotrebe mDL-a, osiguravatelji se pojavljuju indirektno u scenariju iznajmljivanja: osiguravajuće kompanije zahtijevaju od rent-a-car kompanija da provjere ima li osoba koja iznajmljuje automobil pravo na vožnju. Osiguranje već utječe na tok verifikacije vožnje.

Ali to ne znači da osiguravatelj treba primati iste podatke kao policija ili trajno pravo pristupa akreditivu.

Budući MVD trebao bi tretirati osiguravatelje kao zasebnu kategoriju verifikatora s posebnim namjeravanim upotrebama:

• Upis u osiguranje
• Verifikacija rizika iznajmljivanja
• Obrada odštetnog zahtjeva nakon gubitka
• Pregled prijevare

To nije ista svrha. Prema načelima EU-a o zaštiti podataka, lični podaci moraju biti prikupljeni za određene svrhe i ograničeni na ono što je nužno i proporcionalno toj svrsi. W3C-ove smjernice za VC dolaze do istog tehničkog zaključka: verifikatori bi trebali tražiti samo ono što je nužno potrebno.

Legitimni, događajno-specifični primjeri:

• Dokaz da je dozvola bila valjana u relevantnom trenutku
• Dokaz relevantnog ovlaštenja za vozilo
• Dokaz veze identiteta gdje je potrebno za odštetni zahtjev
• Otkrivanje specifično za zahtjev

Podrazumijevano nije dozvoljeno:

• Stalni pristup temeljnom akreditivu
• Ponavljana generička verifikacija svaki put kada korisnik stupi u kontakt s osiguravateljem
• Upotreba vozačkog akreditiva kao tokena za prijavu
• Prikupljanje nepovezanih atributa

Vozački akreditiv nije pretplata na praćenje. I ne bi smio tiho to postati.

Zašto posrednici moraju biti vidljivi

Stvarna tržišta uključuju posrednike. Platforme za iznajmljivanje, dobavljači voznih parkova, HR sistemi poslodavaca i procesori odštetnih zahtjeva osiguravajućih kompanija često djeluju putem trećih strana.

EUDI arhitektura ovo rješava na sljedeće načine:

• Tretira posrednike kao oslonjenoj stranama
• Zahtijeva od njih da se registriraju
• Zahtijeva da atributi zatraženi za posredovanu oslonjenuj stranu budu registrirani
• Prikazuje korisniku i posrednika i krajnju oslonjenuj stranu
• Zabranjuje posrednicima pohranjivanje podataka o sadržaju transakcije

Budući MVD nikada ne bi smio dozvoliti obrazac u kojem korisnik vjeruje da otkriva podatke rent-a-car kompaniji, ali u stvarnosti otkriva nevidljivom posredniku za verifikaciju, procesoru analitike i lancu dobavljača odštetnih zahtjeva.

ETSI ovdje pomaže. Njegov model certifikata za oslonjenuj stranu novčanika uključuje URI-je za podršku, namjeravanu upotrebu, URI-je registra i metapodatke nadzornog tijela. To je vrsta čitljive infrastrukture za mašine koja je potrebna korisnicima da razumiju ko je zapravo na drugom kraju zahtjeva i gdje se obratiti kada žele brisanje ili ispravku.

Zadržavanje je dio kontrole pristupa

Većina rasprava o selektivnom otkrivanju podataka završava prerano. Fokusiraju se na to što se otkriva. Ne fokusiraju se dovoljno na to koliko dugo to ostaje nakon toga.

Trenutne smjernice već konvergiraju:

• AAMVA: novčanik mora jasno obavijestiti nositelja koji su podaci zatraženi i namjerava li verifikator zadržati informacije; dionici ne smiju pratiti nositelje ili upotrebu mDL-a osim kada je to zahtijevano zakonom
• W3C: softver nositelja trebao bi pružati zapise o informacijama podijeljenim s verifikatorima, kako bi se mogli identificirati prekomjerni zahtjevi
• EUDI: korisnici bi trebali moći pristupiti zapisima transakcija, prijaviti sumnjive zahtjeve i zatražiti brisanje

Klasa zadržavanja trebala bi biti dio same politike otkrivanja podataka:

• Policija na cesti: podrazumijevano bez zadržavanja osim zakonskog operativnog zapisa
• Prethodna provjera za iznajmljivanje: zapis transakcije vezan za rezervaciju, a ne višekratno upotrebljiva kopija identiteta
• Usklađenost voznog parka poslodavca: zapis usklađenosti ili rezultat potvrde, a ne sirovi podaci akreditiva
• Odštetni zahtjev osiguravatelja: zapis zahtjeva ograničen na zahtjev, a ne stalni pristup

Budući MVD koji zanemaruje zadržavanje samo je djelimično usmjeren na zaštitu privatnosti.

Šta bi novčanik zapravo trebao odlučiti

Kada bih morao svesti cijeli ovaj članak na jedno pravilo implementacije, bilo bi ovo:

Novčanik ne bi trebao odgovarati na pitanje “Mogu li prezentirati ovaj akreditiv?” Trebao bi odgovarati na pitanje “Mogu li prezentirati ovaj skup tvrdnji ovom autentificiranom verifikatoru, za ovu namjeravanu upotrebu, u ovom kontekstu, u okviru ove klase zadržavanja?”

Ta odluka trebala bi biti pokrenuta barem sljedećim ulaznim podacima:

• Identitet verifikatora
• Kategorija verifikatora
• Namjeravana upotreba
• Registrirani opseg atributa
• Politika otkrivanja od strane izdavatelja, ako postoji
• Okolina (cesta, preuzimanje vozila, daljinska, vozni park, zahtjev)
• Odobrenje nositelja
• Primjenjiva politika zadržavanja

Standardi već sadrže veći dio mehanizama za ovo: selektivno otkrivanje, autentifikaciju oslonjenoj strani, registriranu namjeravanu upotrebu, pristupne certifikate, evaluaciju politike otkrivanja i zahtjeve vezane za svrhu. Ono što još nedostaje je disciplina da se ti dijelovi tretiraju kao jedna koherentna arhitektura otkrivanja podataka.

Ključni argument

Budući MVD ne bi trebao pitati može li se otkriti podatak. Trebao bi pitati:

• Ko pita?
• U koju svrhu?
• Na osnovu kojeg ovlaštenja?
• U kojem kontekstu?
• S kakvim posljedicama po zadržavanje podataka?

Policija, rent-a-car šalteri, poslodavci i osiguravatelji nisu četiri loga na drugom kraju zahtjeva. To su četiri različita modela rizika, četiri različita pravna konteksta, četiri različita razloga za pitanje — i trebaju rezultirati četiri različita skupa otkrivenih podataka.

To nije nepotrebna složenost. To je ono kako izgleda moderan vozački akreditiv kada prestane tretirati svakog verifikatora kao istog verifikatora.