Policija, izposojevalnice, delodajalci, zavarovalnice: Zakaj ne smejo videti istih podatkov

Največja napaka pri oblikovanju prihodnje Mednarodne vozniške dovolilnice (MVD) bi bila, če bi vsakega preveritelja obravnavali enako. Policist, blagajna izposojevalnice avtomobilov, delodajalec in zavarovalnica ne postavljajo istega vprašanja – zato ne bi smeli dobiti istega odgovora.

En voznik. Ena temeljna pravica do vožnje. Ena denarnica. A štirje zelo različni preveritelji:

• Policist ob cesti
• Blagajna izposojevalnice ob prevzemu
• Delodajalec, ki preverja upravičenost do voznega parka
• Zavarovalnica, ki obravnava škodni zahtevek

Če prihodnja MVD pokaže iste podatke vsem štirim, je sistem že propadel. Ne zato, ker poverilnica ni varna, temveč ker je model razkritja preveč preprost.

Skupnost standardov se že odmika od tega preprostega modela. Delo W3C o preverljivih poverilnicah opisuje ekosistem izdajateljev, imetnikov in preveriteljev ter kot primere preveriteljev navaja delodajalce in spletna mesta. Delo EU o mobilni vozniški dovolilnici že obravnava cestne kontrole in izposojevalnice avtomobilov kot ločene scenarije preverjanja, vključno z oddaljenim vnaprejšnjim deljenjem za izposojevalnice in osebnimi kontrolami za policijo. Arhitektura je že zasnovana za več vrst preveriteljev. Napaka bi bila oblikovati uporabniško izkušnjo, kot da obstaja le ena vrsta.

Zakaj nas je fizična kartica naučila napačnega razmišljanja

Fizična dovolilnica nas je navadila na pristop »pokaži vse«. Predaš kartico. Druga oseba vidi, kar je na kartici. To je celotna interakcija.

Ta pristop je sprejemljiv v papirnatem svetu, ker ni alternative. V digitalnem svetu postane nesprejemljiv.

Podatkovni model W3C VC 2.0 neposredno navaja: vozniška dovolilnica lahko vsebuje številko osebne izkaznice, višino, težo, rojstni dan in domači naslov – a to je lahko še vedno veliko več, kot je potrebno za posamezno transakcijo. Ključne točke trenutnih standardov:

• Najboljša praksa W3C: podpirati selektivno razkritje in zahtevati le tisto, kar je nujno potrebno
• Smernice EU za varstvo podatkov: obdelava mora biti omejena na določene namene, obdelani podatki pa morajo biti nujni in sorazmerni
• Prvo načelo prihodnje MVD: enaka poverilnica ne pomeni enake pravice do vpogleda

Pravi model je razkritje na podlagi pravilnikov

Če želite resno arhitekturo, je pravi model bližje nadzoru dostopa na podlagi atributov kot predstavitvi digitalne kartice.

NIST SP 800-205 opredeljuje odločitve o nadzoru dostopa kot vrednotenje atributov, povezanih s subjektom, objektom, zahtevano operacijo in okoljskimi pogoji, glede na pravilnik. To je natanko prava struktura za prihodnjo MVD:

• Subjekt: voznik
• Objekt: zahtevana podatkovna polja
• Dejanje: ne »ogled dovolilnice« v abstraktnem smislu, temveč nekaj konkretnega, kot je »preveritev upravičenosti do vožnje kategorije B ob cesti« ali »preveritev upravičenosti do izposoje za rezervacijo«
• Okolje: ob cesti, izposojevalnica, oddaljeno predhodno preverjanje, uvajanje voznega parka in pregled zahtevkov po škodnem dogodku so različna okolja in bi morala voditi do različnih odločitev

NIST prav tako opozarja, da sistemi atributov potrebujejo granularnost, upravljanje ter mehanizme za zmanjšanje, združevanje in minimizacijo atributov.

Prihodnja MVD torej ne bi smela spraševati: Ali lahko ta preveritelj prebere dovolilnico? Temveč: Katere trditve lahko ta preveritelj prejme, za kateri predvideni namen, v tem okolju in s kakšnimi pravili hrambe?

Preveritelj se mora identificirati, preden kaj zahteva

Prihodnja MVD se ne bi smela začeti z denarnico, ki prikazuje podatke. Začeti bi se morala s preveriteljem, ki dokaže, kdo je.

Arhitektura EUDI je v tem jasna. Odvisne stranke morajo:

• Registrirati, katere atribute nameravajo zahtevati in za kateri namen
• Prejeti dostopna potrdila
• Preveriti pristnost pri denarnici pred vsakim razkritjem
• Biti preverjene glede na njihov registrirani obseg, kjer so informacije o registraciji na voljo

Uporabnik lahko nato vidi, kdo sprašuje, kaj se zahteva in ali je zahteva v registriranem obsegu.

Trenutno delo ETSI na področju potrdil denarnice za odvisne stranke to konkretizira. Registracijsko potrdilo denarnice za odvisne stranke lahko opisuje predvideno uporabo odvisne stranke in atribute, ki jih je registrirala za zahtevanje. Povezano dostopno potrdilo zagotavlja, da zahteva prihaja od legitimne, pooblaščene stranke. ETSI prav tako vključuje metapodatke odvisnih strank, kot so:

• Trgovsko ime
• URI za podporo
• Predvidena uporaba
• Upravičenja
• URI registra
• Informacije o nadzornem organu

Drugo načelo prihodnje MVD: brez identitete preveritelja, brez razkritja.

Zakaj zasloni za soglasje niso zadostni

Tu je še ena napaka: obravnavanje uporabnikove odobritve kot enakovredne pravni legitimnosti.

Arhitektura EUDI izrecno navaja, da se odobritev uporabnika za predstavitev atributov ne sme obravnavati kot zakonita podlaga za obdelavo osebnih podatkov s strani odvisne stranke. Odvisna stranka mora imeti še vedno svojo zakonito podlago. EUDI prav tako zahteva odobritev uporabnika v vseh primerih uporabe, vključno s primeri, ko je odvisna stranka del organov pregona ali druge vladne agencije.

Dober vmesnik denarnice lahko pomaga, a sam ne more rešiti prekoračitve pooblastil preveritelja. Pravilo mora obstajati pred vmesnikom.

Prihodnja MVD zato potrebuje oboje:

• Kriptografsko preverjanje pristnosti preveritelja za potrditev, kdo sprašuje
• Omejitve pravilnika glede tega, kaj lahko ta kategorija preveritelja zahteva

Brez obojega »uporabnikova izbira« postane način prenašanja napake pravilnika na posameznika.

1. Policija: preverite pravico do vožnje, ne celotne osebe

Policijski cestni scenarij je najbolj osredotočen.

Priročnik EU za mDL to neposredno opisuje: policija ali drugi uradniki preverijo dovolilnico po potrebi, vključno z veljavnostjo dovolilnice in pravicami do vozila. V uporabniški poti uradnik preveri dovolilnico s tokom, sproženim s QR-kodo, prek tehnologij Bluetooth, Wi-Fi Aware ali NFC. To je osredotočena naloga preverjanja:

• Je ta oseba imetnik?
• Je poverilnica veljavna?
• Katere pravice do vozila in omejitve veljajo?

Privzeto dovoljeno:

• Ime
• Portret
• Status dovolilnice
• Datumi izdaje in poteka veljavnosti
• Kategorije
• Omejitve, pomembne za vožnjo
• Izdajatelj in jurisdikcija
• Rezultat svežosti/statusa

Privzeto ni dovoljeno:

• Domači naslov
• Notranji identifikatorji, ki niso potrebni za cestno uporabo
• Nepovezani atributi iz drugih attestacij
• Zgodovinski dnevniki predstavitev
• Komercialni metapodatki

Izvedbene smernice organizacije AAMVA krepijo točko portreta: če je portret zahtevan in je sproščen kateri koli drug element, je treba portret deliti, da lahko preveritelj poveže podatke z osebo, ki ga predstavlja. Iste smernice prav tako navajajo, da deležniki ne smejo slediti imetnikom mDL ali uporabi mDL, razen kadar to zahteva zakon.

Policijski primer ni o tem, da država prejme vse. Gre za to, da država prejme podatke, specifične za vožnjo, potrebne za izvajanje ukrepov ob cesti. To je pomembna razlika.

2. Izposojevalnice: upravičenost, ujemanje identitete in nič nepotrebnega

Primer izposojevalnice je podrobnejši, ker sta dejansko dva trenutka: oddaljeno predhodno preverjanje pred prihodom in prevzem, ko oseba ali kiosk preda ključe.

Priročnik EU za mDL že modelira oboje. Storitev izposoje avtomobilov lahko med rezervacijo zahteva mDL skupaj z dokazilom o identiteti, potrdi attestacije in pozneje osebno preveri stranko ob prevzemu, preden sprosti vozilo. Uporabniki lahko delijo svoje mDL-je z izposojevalnicami avtomobilov osebno ali na daljavo vnaprej.

Izposojevalnica v prvi vrsti ne potrebuje preiskave incidenta. Odločiti se mora: Ali lahko izposodim to vozilo tej stranki v okviru te rezervacije in pravilnika?

Oddaljeno predhodno preverjanje bi moralo vključevati:

• Povezavo identitete
• Portret ali enakovreden element vezave identitete
• Ustrezno kategorijo vozila
• Datume izdaje in poteka veljavnosti
• Trenutno veljavnost
• Morebitno starostno mejo ali starostni razpon

Prevzem bi moral potrditi:

• Da je imetnik ista oseba, ki je opravila predhodno preverjanje
• Trenutno veljavnost
• Ustrezne pravice

Privzeto ni potrebno:

• Celoten domači naslov, kadar profil rezervacije že vsebuje kontaktne podatke
• Celoten datum rojstva, kadar zadostuje potrdilo o preseženem starosti ali starostni razpon
• Nepovezani atributi identitete
• Ponavljajoča se ponovna predstavitev celotne poverilnice, če attestacija rezervacije že obstaja

Trenutna arhitektura mDL organizacije NIST prikazuje, kako odvisna stranka uporablja DCQL za zahtevanje samo potrebnih atributov, in izrecno navaja, da to podpira minimizacijo podatkov in soglasje imetnika z strukturiranjem zahteve, namesto da bi poverilnico obravnavali kot enoto. AAMVA dodaja, da bi aplikacija morala jasno prikazati, kateri podatki so bili zahtevani in ali namerava preveritelj informacije obdržati.

3. Delodajalci: kategorija preveriteljev, ne vstopnica do celotne identitete

Pregled W3C kot primer preveritelja navaja digitalni sistem delodajalca, ki preverja univerzitetno diplomo. To nas opominja, da je preverjanje pri delodajalcu že priznan vzorec v ekosistemih poverilnic.

Delodajalec ali upravljavec voznega parka ima morda legitimno potrebo po vedenju:

• Ali je delavec trenutno upravičen voziti določene kategorije vozil
• Ali obstajajo ključne omejitve
• Ali pravica ostaja veljavna

To je resnična poslovna potreba. A to samodejno ne upravičuje stalnega dostopa do celotne vozniške poverilnice, vseh podatkov o identiteti ali neprekinjenega toka ponavljajočih se predstavitev.

NIST opozarja, da je pogosto prenašanje večkrat uporabnega identifikatorja in navajanje uporabnikov na ponavljajoče predstavljanje poverilnice z identiteto nezaželeno, ter navaja, da bi moralo vsakodnevno preverjanje pristnosti temeljiti na tehnologijah, zasnovanih za preverjanje pristnosti, kot so passkeys. NIST daje prednost lokalnemu preverjanju pristnosti naprave pred strežniškim biometričnim ujemanjem, ker bolje ohranja zasebnost.

Prihodnja MVD ne bi smela postati delovni dostopni žeton.

Za delodajalce in vozni park je pravi vzorec navadno:

• Preverjanje upravičenosti, relevantnega za delovno mesto
• Morebitna periodična attestacija skladnosti
• Morebitna trditev, da imetnik ostaja veljaven za določene kategorije
• Toda ne privzeti prenos vseh podatkov dovolilnice vsakič, ko se zaposleni prijavi v sistem ali začne izmeno

Skladnost voznega parka je ločena kategorija odvisnih strank z ločenim predvidenim namenom in ločenim profilom razkritja.

4. Zavarovalnice: zahtevki niso dovoljenje za stalni vpogled

Primer zavarovalništva je pogosto realen. V gradivu EU o primerih uporabe mDL se zavarovalnice pojavljajo posredno v scenariju izposojevalnice: zavarovalnice od izposojevalnic avtomobilov zahtevajo, da preverijo, ali ima oseba, ki si izposoja avtomobil, pravico do vožnje. Zavarovalništvo že vpliva na tok preverjanja vožnje.

To pa ne pomeni, da bi zavarovalnica morala prejeti enake podatke kot policija ali imeti trajno pravico do dostopa do poverilnice.

Prihodnja MVD bi morala zavarovalnice obravnavati kot ločeno kategorijo preveriteljev z ločenimi predvidenimi nameni:

• Zavarovalniška ocena tveganja
• Preverjanje tveganja izposoje
• Obravnava zahtevkov po škodnem dogodku
• Pregled goljufij

Ti nameni niso enaki. V skladu z načeli EU o varstvu podatkov je treba osebne podatke zbirati za določene namene in jih omejiti na tisto, kar je nujno in sorazmerno za ta namen. Smernice W3C za VC tehnično dosežejo isti zaključek: preveritelji bi morali zahtevati le tisto, kar je nujno potrebno.

Legitimni, z dogodkom specifični primeri:

• Dokazilo, da je bila dovolilnica veljavna v ustreznem trenutku
• Dokazilo o ustrezni pravici do vozila
• Dokazilo o vezavi identitete, kjer je to potrebno za zahtevek
• Razkritje, specifično za zahtevek

Privzeto ni dovoljeno:

• Stalni dostop do temeljne poverilnice
• Ponavljajoče generično preverjanje vsakič, ko stranka komunicira z zavarovalnico
• Uporaba vozniške poverilnice kot žetona za prijavo
• Zbiranje nepovezanih atributov

Vozniška poverilnica ni naročniška storitev nadzora. In tiho ne bi smela postati.

Zakaj morajo biti posredniki vidni

Realni trgi vključujejo posrednike. Platforme za izposojo, dobavitelji voznih parkov, kadrovski sistemi delodajalcev in obdelovalci zavarovalniških zahtevkov pogosto delujejo prek tretjih oseb.

Arhitektura EUDI to rešuje z:

• Obravnavanjem posrednikov kot odvisnih strank
• Zahtevanjem, da se registrirajo
• Zahtevanjem, da so atributi, zahtevani za posredovano odvisno stranko, registrirani
• Prikazovanjem tako posrednika kot končne odvisne stranke uporabniku
• Prepovedjo posrednikom shranjevanja podatkov o vsebini transakcije

Prihodnja MVD ne bi smela nikoli dopustiti vzorca, pri katerem uporabnik verjame, da razkriva podatke izposojevalnici, v resnici pa jih razkriva nevidnemu posredniku za preverjanje, obdelovalcu analitike in verigi prodajalcev zahtevkov.

ETSI tu pomaga. Njegov model potrdil denarnice za odvisne stranke vključuje URI-je za podporo, predvideno uporabo, URI-je registra in metapodatke nadzornega organa. To je vrsta strojno berljive infrastrukture, ki jo uporabniki potrebujejo, da razumejo, kdo je dejansko na drugi strani zahteve in kam se obrniti, ko zahtevajo izbris ali popravek.

Hramba je del nadzora dostopa

Večina razprav o selektivnem razkritju se konča prezgodaj. Osredotočajo se na to, kaj se razkrije. Ne posvečajo dovolj pozornosti temu, kako dolgo razkriti podatek ostane po tem.

Trenutne smernice se že poenotijo:

• AAMVA: denarnica mora imetniku jasno sporočiti, kateri podatki so bili zahtevani in ali namerava preveritelj informacije obdržati; deležniki ne smejo slediti imetnikom ali uporabi mDL, razen kadar to zahteva zakon
• W3C: programska oprema imetnika bi morala zagotavljati dnevnike informacij, deljenih s preveritelji, da je mogoče identificirati prekomerne zahteve
• EUDI: uporabniki bi morali imeti dostop do dnevnikov transakcij, poročati o sumljivih zahtevah in zahtevati izbris

Razred hrambe bi moral biti del samega pravilnika o razkritju:

• Policija ob cesti: privzeto brez hrambe, razen zakonito zahtevanega operativnega zapisa
• Predhodno preverjanje pri izposojevalnici: zapis transakcije vezan na rezervacijo, ne kopija identitete za večkratno uporabo
• Skladnost voznega parka pri delodajalcu: zapis skladnosti ali rezultat attestacije, ne neobdelani podatki poverilnice
• Zavarovalniški zahtevek: zapis zahtevka omejen na zahtevek, ne stalni dostop

Prihodnja MVD, ki prezre hrambo, le delno ohranja zasebnost.

Kaj bi morala denarnica dejansko odločiti

Če bi moral celoten ta članek zreducirati na eno izvedbeno pravilo, bi bilo to:

Denarnica ne bi smela odgovarjati na vprašanje »Ali lahko predstavim to poverilnico?« Odgovarjati bi morala na vprašanje »Ali lahko predstavim ta nabor trditev temu preverjenemu preveritelju, za ta predvideni namen, v tem kontekstu, pod tem razredom hrambe?«

Ta odločitev bi morala temeljiti vsaj na teh vnosih:

• Identiteta preveritelja
• Kategorija preveritelja
• Predvideni namen
• Registrirani obseg atributov
• Pravilnik o razkritju s strani izdajatelja, če obstaja
• Okolje (ob cesti, prevzem, na daljavo, vozni park, zahtevek)
• Odobritev imetnika
• Veljavni pravilnik o hrambi

Standardi že vsebujejo velik del mehanizmov za to: selektivno razkritje, preverjanje pristnosti odvisnih strank, registrirani predvideni namen, dostopna potrdila, vrednotenje pravilnika o razkritju in namenu vezane zahteve. Kar še manjka, je disciplina za obravnavanje teh delov kot ene koherentne arhitekture razkritja.

Osrednji argument

Prihodnja MVD ne bi smela spraševati, ali je mogoče podatke razkriti. Spraševati bi morala:

• Kdo sprašuje?
• Za kateri namen?
• Pod katero pristojnostjo?
• V katerem kontekstu?
• S kakšnimi posledicami hrambe?

Policija, izposojevalnice, delodajalci in zavarovalnice niso štirje logotipi na drugi strani zahteve. So štiri različni modeli tveganja, štiri različni pravni konteksti, štiri različni razlogi za spraševanje – in morali bi producirati štiri različne nabore razkritij.

To ni nepotrebna kompleksnost. Tako izgleda sodobna vozniška poverilnica, ko preneha obravnavati vsakega preveritelja kot enakega preveritelja.