Politsei, rendilauad, tööandjad, kindlustajad: miks neil ei tohi olla juurdepääs samadele andmetele

Suurim disainiviga tulevases rahvusvahelises juhiloas (RJL) oleks kohelda iga kontrollijat sama kontrollijana. Politseinik, autorendi laud, tööandja ja kindlustaja ei esita sama küsimust — seega ei tohiks nad saada sama vastust.

Üks juht. Üks põhiõigus juhtida. Üks rahakott. Kuid neli väga erinevat kontrollijat:

• Politseinik teel
• Autorendi laud autoüleandmisel
• Tööandja, kes kontrollib sõiduki kasutamise õigust
• Kindlustaja, kes vaatab läbi kahjuhüvitise nõude

Kui tulevane RJL näitab kõigile neljale samu andmeid, on süsteem juba läbi kukkunud. Mitte sellepärast, et mandaat on ebaturvaline, vaid sellepärast, et avalikustamismudel on liiga lihtne.

Standardikogu liigub juba sellest lihtsast mudelist eemale. W3C kontrollitavate mandaatide töö kirjeldab väljastajate, hoidjate ja kontrollijate ümber olevat ökosüsteemi, kasutades tööandjaid ja veebisaite kontrollijate näidetena. EL-i mobiilse juhiloa töö käsitleb juba teekontrolle ja autorentimist eraldi kontrollimise stsenaariumidena, sealhulgas kaugemat eelnevat jagamist rendi jaoks ja isiklikku kohapealset kontrolli politsei jaoks. Arhitektuur on juba kavandatud mitme kontrollijatüübi jaoks. Viga oleks kasutajakogemuse kujundamine, nagu eksisteeriks ainult üks tüüp.

Miks füüsiline kaart õpetas meid valesti mõtlema

Füüsiline litsents õpetas meid kõike-näitava lähenemiseni. Annad kaardi üle. Teine inimene näeb, mis on kaardil. See ongi kogu suhtlus.

See lähenemine on pabermaailmas vastuvõetav, kuna alternatiivi pole. Digitaalses maailmas muutub see vastuvõetamatuks.

W3C VC andmemudel 2.0 ütleb otse: juhiluba võib sisaldada isikukoodi, pikkust, kaalu, sünnikuupäeva ja kodust aadressi — kuid see võib olla konkreetse tehingu jaoks palju rohkem kui vajalik. Praeguste standardite põhipunktid:

• W3C parim praktika: toetada selektiivset avalikustamist ja nõuda ainult rangelt vajalikku
• EL-i andmekaitsejuhis: töötlemine peab olema piiratud kindlaksmääratud eesmärkidega ning töödeldavad andmed peavad olema vajalikud ja proportsionaalsed
• Tulevase RJL-i esimene põhimõte: sama mandaat ei tähenda sama õigust kontrollida

Õige mudel on poliitikupõhine avalikustamine

Kui soovite tõsist arhitektuuri, on õige mudel lähemal atribuudipõhisele juurdepääsukontrollile kui digitaalse kaardi esitamisele.

NIST SP 800-205 määratleb juurdepääsukontrolli otsused kui subjekti, objekti, taotletud toimingu ja keskkonnatingimustega seotud atribuutide hindamist poliitika suhtes. See on täpselt õige struktuur tulevase RJL-i jaoks:

• Subjekt: juht
• Objekt: taotletud andmeväljad
• Toiming: mitte abstraktne „vaata litsentsi”, vaid midagi konkreetset, näiteks „kinnita õigus juhtida kategooriat B teel” või „kinnita rendiõigus broneeringu jaoks”
• Keskkond: tee, rendilaud, kaugkontroll eelnevalt, flootide kasutuselevõtt ja kahjujärgne nõude läbivaatamine on erinevad keskkonnad ja peaksid viima erinevate otsusteni

NIST märgib ka, et atribuudisüsteemid vajavad granulaarsust, juhtimist ning atribuutide vähendamise, rühmitamise ja minimeerimise mehhanisme.

Seega ei peaks tulevane RJL küsima: Kas see kontrollija saab litsentsi lugeda? See peaks küsima: Milliseid väiteid võib see kontrollija saada, millise kavandatud kasutuse jaoks, selles keskkonnas, milliste säilitamisreeglitega?

Kontrollija peaks enne millegi nõudmist oma identiteedi tõendama

Tulevane RJL ei peaks algama rahakotiga, mis näitab andmeid. See peaks algama kontrollijaga, kes tõendab, kes ta on.

EUDI arhitektuur on selles osas selge. Tuginevad osapooled peavad:

• Registreerima, milliseid atribuute nad kavatsevad nõuda ja mis eesmärgil
• Saama juurdepääsusertifikaate
• Autentima rahakotti enne mis tahes avalikustamist
• Olema kontrollitud nende registreeritud ulatuse suhtes, kui registreerimisinfo on saadaval

Kasutaja saab seejärel näha, kes küsib, mida küsitakse ja kas taotlus on registreeritud ulatuses.

ETSI praegune rahakoti-tugineva-osapoole sertifikaadi töö muudab selle konkreetsemaks. Rahakoti-tugineva-osapoole registreerimissertifikaat võib kirjeldada tugineva osapoole kavandatud kasutust ja atribuute, mille ta registreeris nõudmiseks. Seotud juurdepääsusertifikaat on olemas tagamaks, et taotlus tuleb seaduslikult volitatud osapoolelt. ETSI sisaldab ka tugineva osapoole metaandmeid, näiteks:

• Kaubanimi
• Toe URI
• Kavandatud kasutus
• Õigused
• Registri URI
• Järelevalveasutuse teave

Tulevase RJL-i teine põhimõte: ilma kontrollija identiteedita ei toimu avalikustamist.

Miks nõusolekuekraanid ei ole piisavad

Siin on veel üks viga: kasutaja heakskiidu käsitlemine seadusliku legitiimsusega sama asjana.

EUDI arhitektuur ütleb selgesõnaliselt, et kasutaja heakskiitu atribuutide esitamiseks ei tohi käsitleda tugineva osapoole isikuandmete töötlemise seadusliku alusena. Tuginevas osapoolel peab endiselt olema oma seaduslik alus. EUDI nõuab kasutaja heakskiitu kõikides kasutusjuhtudes, sealhulgas juhtudel, kus tuginev osapool võib olla osa õiguskaitseasutustest või mõnest muust valitsusasutusest.

Hea rahakoti liides võib aidata, kuid see ei suuda üksi lahendada kontrollija ülemääraseid nõudmisi. Reegel peab eksisteerima enne liidest.

Tulevane RJL vajab seetõttu mõlemat:

• Krüptograafilist kontrollija autentimist kinnitamaks, kes küsib
• Poliitika piiranguid selle kohta, mida see kontrollijate kategooria võib nõuda

Ilma mõlemata muutub „kasutaja valik” viisiks, kuidas lükata poliitika ebaõnnestumine üksikisikule.

1. Politsei: kinnita sõiduõigus, mitte kogu isik

Politsei teekontrolli stsenaarium on kõige fokuseeritum.

EL-i mDL käsiraamat kirjeldab seda otse: politsei või muud ametnikud kontrollivad litsentsi vajadusel, sealhulgas litsentsi kehtivust ja sõiduki kasutusõigusi. Kasutajateekonnal kontrollib ametnik litsentsi QR-koodi käivitatud voo, Bluetoothi, Wi-Fi Aware’i või NFC kaudu. See on fokuseeritud kontrollimisülesanne:

• Kas see isik on hoidja?
• Kas mandaat on kehtiv?
• Millised sõiduki kasutusõigused ja piirangud kehtivad?

Vaikimisi lubatud:

• Nimi
• Portree
• Litsentsi staatus
• Väljaandmise ja aegumise kuupäevad
• Kategooriad
• Juhtimisega seotud piirangud
• Väljaandja ja jurisdiktsioon
• Värskuse/staatuse tulemus

Vaikimisi keelatud:

• Kodune aadress
• Sisemised identifikaatorid, mida teekasutuseks pole vaja
• Mitteseotud atribuudid muudest atesteeringutest
• Ajaloolised esitluslogid
• Äriline metaandmed

AAMVA rakendamisjuhis tugevdab portree punkti: kui portree on nõutud ja mõni muu element vabastatakse, tuleks portree jagada, et kontrollija saaks andmed siduda seda esitava isikuga. Sama juhis ütleb ka, et sidusrühmad ei tohi jälgida mDL-i hoidjaid ega mDL-i kasutust, välja arvatud seal, kus seadus seda nõuab.

Politsei juhtum ei ole seotud riigiga, kes saab kõike. See on seotud riigiga, kes saab tee jõustamiseks vajalikud juhtimisega seotud andmed. See on oluline erinevus.

2. Rendilauad: sobivus, identiteedi vastavus ja mitte midagi ebavajalikku

Rendijuhtum on üksikasjalikum, kuna on tegelikult kaks hetke: kaugkontroll enne saabumist ja üleandmine, kui isik või kiosk annab võtmed üle.

EL-i mDL käsiraamat modelleerib juba mõlemat. Autorenditeenistus võib broneeringu ajal nõuda mDL-i koos isikutõendiga, kinnitada atesteeringuid ja hiljem klienti isiklikult üleandmisel kontrollida enne sõiduki väljastamist. Kasutajad saavad oma mDL-e autorendifirmadega jagada kas isiklikult või kaugelt ette.

Rendilaud ei pea peamiselt juhtumit uurima. See peab otsustama: Kas ma saan seda sõidukit selle kliendile selle broneeringu ja poliitika alusel rentida?

Kaugkontroll peaks sisaldama:

• Identiteedi sidet
• Portree või samaväärset identiteeti siduva elemendi
• Asjakohast sõiduki kategooriat
• Väljaandmise ja aegumise kuupäevi
• Praegust kehtivust
• Võimalusel vanusepiirangu või vanusevahemiku

Üleandmine peaks kinnitama:

• Hoidja on sama isik, kes sooritas eelkontrolli
• Praegust kehtivust
• Asjakohaseid õigusi

Vaikimisi pole vaja:

• Täielikku kodust aadressi, kui broneerimiprofiil sisaldab juba kontaktandmeid
• Täielikku sünnikuupäeva, kus vanuse-üle või vanusevahemik on piisav
• Mitteseotud identiteediattribuute
• Täismandaadi korduvat esitamist, kui broneeringuatesteerng juba eksisteerib

NIST-i praegune mDL-i arhitektuur näitab, et tuginev osapool kasutab DCQL-i ainult vajalike atribuutide nõudmiseks, ja ütleb selgesõnaliselt, et see toetab andmete minimeerimist ja hoidja nõusolekut taotluse struktureerimise teel, mitte mandaadi ühe tervikuna käsitlemise kaudu. AAMVA lisab, et rakendus peaks selgelt näitama, milliseid andmeid nõuti ja kas kontrollija kavatseb teavet säilitada.

3. Tööandjad: kontrollijate kategooria, mitte ava täielikku identiteeti

W3C ülevaade kasutab tööandja digitaalset süsteemi, mis kontrollib ülikoolikraadi, kontrollijate näitena. See tuletab meile meelde, et tööandja kontroll on mandaadi ökosüsteemides juba tunnustatud muster.

Tööandjal või floodioperaatoril võib olla seaduslik vajadus teada:

• Kas töötajal on praegu õigus juhtida teatud sõiduki kategooriaid
• Kas olulised piirangud eksisteerivad
• Kas õigus jääb kehtima

See on tõeline ärivajadus. Kuid see ei õigusta automaatselt püsivat juurdepääsu kogu juhimismandaadile, täielikele identiteediandmetele ega pidevale korduva esitluse voole.

NIST hoiatab, et korduvkasutatava identifikaatori sagedane edastamine ja kasutajate harjutamine identiteeti kandvat mandaati korduvalt esitama on ebasoovitav, ning ütleb, et igapäevane autentimine peaks põhinema autentimiseks loodud tehnoloogiatel, näiteks passkey’del. NIST eelistab kohalikku seadme autentimist serveri-poolse biomeetrilise sobitamise asemel, kuna see säilitab privaatsuse paremini.

Tulevane RJL ei tohiks muutuda töökoha juurdepääsumärgiks.

Tööandja ja floodi kasutuse jaoks on õige muster tavaliselt:

• Tööga seotud õiguste kontroll
• Võib-olla perioodiline vastavusatesteerng
• Võib-olla väide, et hoidja jääb kehtivaks määratud kategooriate jaoks
• Kuid mitte kõigi litsentsandmete vaikimisi ülekanne iga kord, kui töötaja süsteemi sisse logib või vahetust alustab

Floodi vastavus on eraldi tugineva osapoole kategooria, eraldi kavandatud kasutusega ja eraldi avalikustamisprofiiliga.

4. Kindlustajad: nõuded ei ole luba pidevaks nähtavuseks

Kindlustusjuhtum on sageli reaalne. EL-i mDL kasutusjuhtude materjalis ilmuvad kindlustajad rendistsenaariumis kaudselt: kindlustusseltsid nõuavad autorendifirmadelt kontrollida, kas autot rentiv isik on juhtimisõigusega. Kindlustus mõjutab juba juhtimise kontrollimise voogu.

Kuid see ei tähenda, et kindlustaja peaks saama sama andmeid kui politsei või püsiva õiguse mandaadile juurdepääsuks.

Tulevane RJL peaks kohtlema kindlustajaid eraldi kontrollijate kategooriana eraldi kavandatud kasutustega:

• Kindlustamine
• Rendi-riski kontrollimine
• Kahjujärgne nõude käsitlemine
• Pettuse läbivaatamine

Need ei ole sama eesmärk. EL-i andmekaitsepoliitika kohaselt tuleb isikuandmeid koguda kindlaksmääratud eesmärkidel ning piirata see sellega, mis on selle eesmärgi jaoks vajalik ja proportsionaalne. W3C VC juhis jõuab tehniliselt samale järeldusele: kontrollijad peaksid nõudma ainult rangelt vajalikku.

Seaduslikud, sündmusepõhised näited:

• Tõend, et litsents kehtis asjakohases hetkel
• Tõend asjakohase sõiduki kasutusõiguse kohta
• Tõend identiteedi sideme kohta, kus see on nõude jaoks vajalik
• Nõudepõhine avalikustamine

Vaikimisi ei ole lubatud:

• Püsiv juurdepääs aluseks olevale mandaadile
• Korduv üldine kontroll iga kord, kui klient kindlustajaga suhtleb
• Juhimismandaadi kasutamine sisselogimistõendina
• Mitteseotud atribuutide kogumine

Juhimismandaat ei ole seiretellimus. Ja see ei tohiks vaikselt selleks muutuda.

Miks vahendajad peavad olema nähtavad

Päristurud hõlmavad vahendajaid. Rendiplatvormid, floodi müüjad, tööandja personalisüsteemid ja kindlustuse nõudetöötlejad tegutsevad sageli kolmandate osapoolte kaudu.

EUDI arhitektuur tegeleb sellega:

• Koheldes vahendajaid tuginevate osapooltena
• Nõudes neilt registreerimist
• Nõudes, et vahendatud tugineva osapoole jaoks taotletud atribuudid oleksid registreeritud
• Näidates kasutajale nii vahendajat kui ka lõpptuginevat osapoolt
• Keelates vahendajatel tehingu sisu kohta andmeid salvestada

Tulevane RJL ei tohiks kunagi lubada mustrit, kus kasutaja usub, et ta avalikustab rendiettevõttele, kuid tegelikkuses avalikustab ta nähtamatule kontrollivahendajale, analüütikatöötlejale ja nõuete müüja ahelale.

ETSI aitab siin. Selle rahakoti-tugineva-osapoole sertifikaadimudel sisaldab toe URI-sid, kavandatud kasutust, registri URI-sid ja järelevalveasutuse metaandmeid. See on masinloetava infrastruktuuri tüüp, mida kasutajad vajavad mõistmaks, kes tegelikult on taotluse teisel poolel ja kuhu minna, kui soovitakse kustutamist või parandamist.

Säilitamine on juurdepääsukontrolli osa

Enamik selektiivse avalikustamise arutelusid lõpeb liiga vara. Need keskenduvad sellele, mis avalikustatakse. Need ei keskendu piisavalt sellele, kui kaua see pärast seda jääb.

Praegune juhendamine koondub juba:

• AAMVA: rahakott peab hoidjale selgelt ütlema, milliseid andmeid nõuti ja kas kontrollija kavatseb neid säilitada; sidusrühmad ei tohi hoidjaid ega mDL-i kasutust jälgida, välja arvatud seal, kus seadus seda nõuab
• W3C: hoidja tarkvara peaks pakkuma logisid kontrollijatega jagatud teabest, et liigse nõude saaks tuvastada
• EUDI: kasutajad peaksid saama juurdepääsu tehingulogidele, teavitama kahtlastest taotlustest ja taotlema kustutamist

Säilitamisklass peaks olema avalikustamispoliitika osa:

• Politsei teel: vaikimisi ei säilitata rohkem kui seaduslik operatsiooniline kirje
• Rendi eelkontroll: tehingukirje on seotud broneeringuga, mitte korduvkasutatava identiteedikoopiana
• Tööandja floodi vastavus: vastavuskirje või atesteeringu tulemus, mitte toored mandaadiandmed
• Kindlustaja nõue: nõudekirje piiratud nõudega, mitte püsiva juurdepääsuga

Tulevane RJL, mis ignoreerib säilitamist, on vaid osaliselt privaatsust säilitav.

Mida rahakott peaks tegelikult otsustama

Kui peaksin kogu selle artikli üheks rakenduseeskirjaks taandama, oleks see järgmine:

Rahakott ei peaks vastama küsimusele „Kas ma saan seda mandaati esitada?” See peaks vastama küsimusele „Kas ma saan esitada selle väidete kogumi sellele autenditud kontrollijale, selle kavandatud kasutuse jaoks, selles kontekstis, selle säilitamisklassi all?”

Seda otsust peaks juhtima vähemalt need sisendid:

• Kontrollija identiteet
• Kontrollijate kategooria
• Kavandatud kasutus
• Registreeritud atribuudi ulatus
• Avalikustamispoliitika väljaandjalt, kui see on olemas
• Keskkond (teel, üleandmisel, kaugelt, floodi, nõude puhul)
• Hoidja heakskiit
• Kohaldatav säilitamispoliitika

Standardid sisaldavad juba suure osa selleks vajalikust mehhanismist: selektiivne avalikustamine, tugineva osapoole autentimine, registreeritud kavandatud kasutus, juurdepääsusertifikaadid, avalikustamispoliitika hindamine ja eesmärgipõhised taotlused. Puudu on veel distsipliin käsitleda neid osi ühe sidusa avalikustamisarhitektuurina.

Põhiargument

Tulevane RJL ei peaks küsima, kas andmeid saab avalikustada. See peaks küsima:

• Kes küsib?
• Mis eesmärgil?
• Millise asutuse all?
• Millises kontekstis?
• Milliste säilitamise tagajärgedega?

Politsei, rendilauad, tööandjad ja kindlustajad ei ole neli logo taotluse teisel poolel. Need on neli erinevat riskimudelit, neli erinevat õiguslikku konteksti, neli erinevat põhjust küsida — ja need peaksid andma neli erinevat avalikustamiskomplekti.

See ei ole ebavajalik keerukus. See on see, milline näeb välja kaasaegne juhimismandaat, kui see lõpetab iga kontrollija kohtlemise sama kontrollijana.