Policija, Iznajmljivači Vozila, Poslodavci, Osiguratelji: Zašto Ne Smiju Vidjeti Iste Podatke

Najveća pogreška u dizajnu buduće Međunarodne vozačke dozvole (MVD) bila bi tretiranje svakog verifikatora kao istog verifikatora. Policajac, šalter za iznajmljivanje vozila, poslodavac i osiguratelj ne postavljaju isto pitanje — stoga ne bi smjeli primiti isti odgovor.

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

• Policajac uz cestu
• Šalter za iznajmljivanje vozila pri preuzimanju
• Poslodavac koji provjerava podobnost za vozni park
• Osiguratelj koji razmatra zahtjev za odštetu

Ako buduća MVD prikazuje iste podatke svim četirima, sustav je već zakazao. Ne zato što vjerodajnica nije sigurna, već zato što je model otkrivanja podataka previše jednostavan.

Zajednica za standarde već se odmakla od tog jednostavnog modela. W3C-ov rad na provjerljivim vjerodajnicama opisuje ekosustav oko izdavatelja, nositelja i verifikatora, koristeći poslodavce i web stranice kao primjere verifikatora. EU-ov rad na mobilnoj vozačkoj dozvoli već tretira provjere uz cestu i iznajmljivanje vozila kao zasebne scenarije verifikacije, uključujući udaljeno prethodno dijeljenje za iznajmljivanje i osobne provjere za policiju. Arhitektura je već dizajnirana za više vrsta verifikatora. Pogreška bi bila dizajniranje korisničkog iskustva kao da postoji samo jedna vrsta.

Zašto Nas je Fizička Kartica Naučila Razmišljati Pogrešno

Fizička dozvola naučila nas je pristupu prikazivanja svega. Predajete karticu. Druga osoba vidi što piše na kartici. To je cijela interakcija.

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

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

• W3C najbolja praksa: podržavati selektivno otkrivanje i zahtijevati samo ono što je strogo nužno
• Smjernice EU za zaštitu podataka: obrada mora biti ograničena na navedene svrhe, a podaci koji se obrađuju moraju biti nužni i proporcionalni
• Prvo načelo buduće MVD: ista vjerodajnica ne znači isto pravo na uvid

Pravi Model Je Otkrivanje Temeljeno na Politikama

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

NIST SP 800-205 definira odluke o kontroli pristupa kao procjene atributa povezanih s subjektom, objektom, zahtijevanom operacijom i uvjetima okruženja, u odnosu na politiku. To je upravo prava struktura za buduću MVD:

• Subjekt: vozač
• Objekt: zahtijevana podatkovna polja
• Radnja: ne “vidjeti dozvolu” apstraktno, već nešto konkretno poput “verificirati pravo vožnje kategorije B uz cestu” ili “verificirati podobnost za iznajmljivanje za određenu rezervaciju”
• Okruženje: uz cestu, šalter za iznajmljivanje, udaljena prethodna provjera, uvođenje u vozni park i pregled zahtjeva nakon gubitka — to su različita okruženja koja trebaju voditi do različitih odluka

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

Stoga buduća MVD ne bi trebala pitati: Može li ovaj verifikator pročitati dozvolu? Trebala bi pitati: Koje tvrdnje ovaj verifikator može primiti, za koju namjeravanu upotrebu, u ovom okruženju, s kojim pravilima zadržavanja?

Verifikator Bi Se Trebao Identificirati Prije Nego Što Zatraži Bilo Što

Buduća MVD ne bi trebala počinjati prikazivanjem podataka iz novčanika. Trebala bi počinjati verifikatorovim dokazivanjem tko je.

EUDI arhitektura je o tome jasna. Oslanjajuće stranke moraju:

• Registrirati koje atribute namjeravaju zatražiti i u koju svrhu
• Primiti pristupne certifikate
• Autentificirati se u novčanik prije bilo kakvog otkrivanja podataka
• Biti provjerene u odnosu na registrirani opseg, gdje su registracijske informacije dostupne

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

Trenutni rad ETSI-a na certifikatima oslanjajućih stranaka novčanika ovo čini konkretnijim. Registracijski certifikat oslanjajuće stranke novčanika može opisati namjeravanu upotrebu oslanjajuće stranke i atribute koje je registrirala za zahtijevanje. Povezani pristupni certifikat postoji kako bi se osiguralo da zahtjev dolazi od legitimne, ovlaštene stranke. ETSI također uključuje metapodatke oslanjajuće stranke kao što su:

• Trgovački naziv
• URI podrške
• Namjeravana upotreba
• Ovlaštenja
• URI registra
• Informacije nadzornog tijela

Drugo načelo buduće MVD: bez identiteta verifikatora, nema otkrivanja podataka.

Zašto Ekrani za Suglasnost Nisu Dostatni

Ovdje postoji još jedna pogreška: tretiranje korisničkog odobrenja kao istovjetnog zakonskoj legitimnosti.

EUDI arhitektura izričito navodi da se korisničko odobrenje za prezentaciju atributa ne smije tretirati kao zakonska osnova za obradu osobnih podataka oslanjajuće stranke. Oslanjajuća stranka i dalje mora imati vlastitu zakonsku osnovu. EUDI također zahtijeva korisničko odobrenje u svim slučajevima upotrebe, uključujući slučajeve kada oslanjajuća stranka može biti dio tijela za provedbu zakona ili druge vladine agencije.

Dobro korisničko sučelje novčanika može pomoći, ali ne može samo po sebi riješiti prekoračenje ovlasti verifikatora. Pravilo mora postojati prije sučelja.

Buduća MVD stoga treba oboje:

• Kriptografsku autentifikaciju verifikatora za potvrdu tko pita
• Ograničenja politike na ono što ta kategorija verifikatora može zatražiti

Bez obojeg, “korisnički izbor” postaje način prebacivanja neuspjeha politike na pojedinca.

1. Policija: Verificirajte Pravo na Vožnju, Ne Cijelu Osobu

Scenarij policijske provjere uz cestu je najfokusiraniji.

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

• Je li ova osoba nositelj dozvole?
• Je li vjerodajnica valjana?
• Koja ovlaštenja i ograničenja za vozilo se primjenjuju?

Dozvoljeno po zadanom:

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

Nije dozvoljeno po zadanom:

• Kućna adresa
• Interni identifikatori koji nisu potrebni za upotrebu uz cestu
• Nepovezani atributi iz drugih atestacija
• Povijesni zapisi prezentacija
• Komercijalni metapodaci

AAMVA-ine implementacijske smjernice pojačavaju točku o portretu: ako se zatraži portret i pusti bilo koji drugi element, portret treba biti podijeljen kako bi verifikator mogao povezati podatke s osobom koja ih prezentira. Iste smjernice također navode da dionici ne smiju pratiti nositelje mDL-a ili upotrebu mDL-a osim gdje to zahtijeva zakon.

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 provedbu propisa uz cestu. To je važna razlika.

2. Iznajmljivači Vozila: Podobnost, Podudaranje Identiteta i Ništa Nepotrebno

Slučaj iznajmljivanja je detaljniji jer postoje zapravo dva trenutka: udaljeno prethodno provjeravanje prije dolaska i preuzimanje kada osoba ili kiosk predaje ključeve.

EU-ov priručnik za mDL već modelira oboje. Usluga iznajmljivanja vozila može zatražiti mDL zajedno s dokazom identiteta tijekom rezervacije, validirati atestacije i kasnije osobno verificirati kupca pri preuzimanju prije predaje vozila. Korisnici mogu dijeliti svoje mDL-ove s tvrtkama za iznajmljivanje vozila osobno ili udaljeno unaprijed.

Iznajmljivač vozila primarno ne treba istraživati incident. Treba odlučiti: Mogu li iznajmiti ovo vozilo ovom kupcu pod ovom rezervacijom i politikom?

Udaljeno prethodno provjeravanje trebalo bi uključivati:

• Povezivanje identiteta
• Portret ili ekvivalentni element koji povezuje identitet
• Relevantnu kategoriju vozila
• Datume izdavanja i isteka
• Trenutnu valjanost
• Možda dobnu granicu ili dobnu skupinu

Preuzimanje bi trebalo potvrditi:

• Da je nositelj ista osoba koja je završila prethodno provjeravanje
• Trenutnu valjanost
• Relevantna ovlaštenja

Nije potrebno po zadanom:

• Puna kućna adresa kada profil rezervacije već sadrži kontaktne podatke
• Puni datum rođenja gdje je dovoljno “stariji od” ili dobna skupina
• Nepovezani atributi identiteta
• Ponavljana re-prezentacija potpune vjerodajnice ako već postoji atestacija rezervacije

NIST-ova trenutna arhitektura mDL-a prikazuje oslanjajuću stranku koja koristi DCQL za zahtijevanje samo potrebnih atributa, i izričito navodi da ovo podržava minimizaciju podataka i suglasnost nositelja strukturiranjem zahtjeva umjesto tretiranja vjerodajnice kao jedne cjeline. AAMVA dodaje da aplikacija treba jasno prikazati koji su podaci zatraženi i namjerava li verifikator zadržati te informacije.

3. Poslodavci: Kategorija Verifikatora, Ne Ulaz u Puni Identitet

W3C-ov pregled koristi digitalni sustav poslodavca koji provjerava sveučilišnu diplomu kao primjer verifikatora. To nas podsjeća da je verifikacija od strane poslodavca već prepoznati obrazac u ekosustavima vjerodajnica.

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

• Ima li radnik trenutno pravo voziti određene kategorije vozila
• Postoje li ključna ograničenja
• Ostaje li ovlaštenje valjano

To je stvarna poslovna potreba. Ali ona ne opravdava automatski trajni pristup cijeloj vozačkoj vjerodajnici, svim podacima o identitetu ili kontinuiranom toku ponavljanih prezentacija.

NIST upozorava da je često prenošenje identifikatora koji se može koristiti više puta i uvjetovanje korisnika na ponavljano prezentiranje vjerodajnice koja nosi identitet nepoželjno, te navodi da se svakodnevna autentifikacija treba oslanjati na tehnologije dizajnirane za autentifikaciju, poput pristupnih ključeva. NIST preferira lokalnu autentifikaciju uređaja nad biometrijskim podudaranjem na strani poslužitelja jer bolje čuva privatnost.

Buduća MVD ne bi smjela postati pristupna bedža na 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 atestacija usklađenosti
• Možda tvrdnja da nositelj ostaje valjan za navedene kategorije
• Ali ne zadano prenošenje svih podataka o dozvoli svaki put kada se zaposlenik prijavi u sustav ili počne smjenu

Usklađenost voznog parka zasebna je kategorija oslanjajuće stranke, sa zasebnom namjeravenom upotrebom i zasebnim profilom otkrivanja podataka.

4. Osiguratelji: Zahtjevi za Odštetu Nisu Dozvola za Kontinuiranu Vidljivost

Slučaj osiguranja je često stvaran. U EU-ovim materijalima o slučajevima upotrebe mDL-a, osiguratelji se neizravno pojavljuju u scenariju iznajmljivanja: osiguravajuće tvrtke zahtijevaju od tvrtki za iznajmljivanje vozila 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 osiguratelj treba primiti iste podatke kao policija ili trajno pravo pristupa vjerodajnici.

Buduća MVD trebala bi tretirati osiguratelje kao zasebnu kategoriju verifikatora sa zasebnim namjeravenim upotrebama:

• Pokretanje osiguranja
• Verifikacija rizika iznajmljivanja
• Obrada zahtjeva za odštetu nakon gubitka
• Pregled prijevara

To nisu iste svrhe. Prema načelima EU za zaštitu podataka, osobni podaci moraju biti prikupljeni za navedene svrhe i ograničeni na ono što je nužno i proporcionalno za tu svrhu. W3C-ove VC smjernice tehnički dolaze do istog zaključka: verifikatori trebaju zatražiti samo ono što je strogo nužno.

Legitimni, događajno specifični primjeri:

• Dokaz da je dozvola bila valjana u relevantnom trenutku
• Dokaz relevantnog ovlaštenja za vozilo
• Dokaz poveznice identiteta gdje je to nužno za zahtjev za odštetu
• Otkrivanje specifično za zahtjev

Nije dozvoljeno po zadanom:

• Trajni pristup temeljnoj vjerodajnici
• Ponavljana generička verifikacija svaki put kada kupac stupi u interakciju s osigurateljem
• Upotreba vozačke vjerodajnice kao tokena za prijavu
• Prikupljanje nepovezanih atributa

Vozačka vjerodajnica nije pretplata na praćenje. I ne bi smjela tiho to postati.

Zašto Posrednici Moraju Biti Vidljivi

Stvarna tržišta uključuju posrednike. Platforme za iznajmljivanje, dobavljači voznih parkova, HR sustavi poslodavaca i procesori zahtjeva za odštetu osiguranja često djeluju putem trećih stranaka.

EUDI arhitektura se nosi s time na sljedeće načine:

• Tretiranjem posrednika kao oslanjajućih stranaka
• Zahtijevanjem registracije od njih
• Zahtijevanjem da atributi koji se traže za posredovanu oslanjajuću stranku budu registrirani
• Prikazivanjem i posrednika i krajnje oslanjajuće stranke korisniku
• Zabranom posrednicima da pohranjuju podatke o sadržaju transakcije

Buduća MVD nikada ne bi smjela dopustiti obrazac u kojem korisnik vjeruje da otkriva podatke tvrtki za iznajmljivanje, dok u stvarnosti ih otkriva nevidljivom brokeru verifikacije, procesoru analitike i lancu dobavljača zahtjeva.

ETSI tu pomaže. Njegov model certifikata oslanjajuće stranke novčanika uključuje URI-je podrške, namjeravanu upotrebu, URI-je registra i metapodatke nadzornog tijela. To je vrsta strojno čitljive infrastrukture potrebne korisnicima da razumiju tko je zapravo na drugom kraju zahtjeva i gdje se obratiti kada žele brisanje ili ispravak podataka.

Zadržavanje Je Dio Kontrole Pristupa

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

Trenutne smjernice već konvergiraju:

• AAMVA: novčanik mora jasno reći nositelju koji su podaci zatraženi i namjerava li ih verifikator zadržati; dionici ne smiju pratiti nositelje ili upotrebu mDL-a osim gdje to zahtijeva zakon
• W3C: softver nositelja treba osigurati zapise informacija dijeljenih 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 podataka

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

• Policijska provjera uz cestu: bez zadržavanja po zadanom osim zakonskog operativnog zapisa
• Udaljeno prethodno provjeravanje iznajmljivanja: zapis transakcije vezan uz rezervaciju, ne kopija identiteta koja se može koristiti više puta
• Usklađenost voznog parka poslodavca: zapis usklađenosti ili rezultat atestacije, ne sirovi podaci vjerodajnice
• Zahtjev osiguratelja: zapis zahtjeva ograničen na taj zahtjev, ne trajni pristup

Buduća MVD koja ignorira zadržavanje podataka samo je djelomično privacitet-očuvavajuća.

Što Novčanik Zapravo Treba Odlučiti

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

Novčanik ne bi trebao odgovarati “Mogu li prezentirati ovu vjerodajnicu?” Trebao bi odgovarati “Mogu li prezentirati ovaj skup tvrdnji ovom autenticiranom verifikatoru, za ovu namjeravanu upotrebu, u ovom kontekstu, pod ovom klasom zadržavanja?”

Ta odluka trebala bi biti vođena barem ovim ulazima:

• Identitet verifikatora
• Kategorija verifikatora
• Namjeravana upotreba
• Registrirani opseg atributa
• Politika otkrivanja od izdavatelja, ako postoji
• Okruženje (uz cestu, preuzimanje, udaljeno, vozni park, zahtjev za odštetu)
• Odobrenje nositelja
• Primjenjiva politika zadržavanja

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

Temeljni Argument

Buduća MVD ne bi trebala pitati može li se podacima pristupiti. Trebala bi pitati:

• Tko pita?
• U koju svrhu?
• Pod kojim ovlaštenjem?
• U kojem kontekstu?
• S kakvim posljedicama zadržavanja?

Policija, iznajmljivači vozila, poslodavci i osiguratelji nisu četiri loga na drugom kraju zahtjeva. To su četiri različita modela rizika, četiri različita pravna konteksta, četiri različita razloga za postavljanje pitanja — i trebaju proizvesti četiri različita skupa otkrivenih podataka.

To nije nepotrebna složenost. Tako izgleda moderna vozačka vjerodajnica kada prestane tretirati svakog verifikatora kao istog verifikatora.