Lögregla, bílaleiguafgreiðslur, vinnuveitendur, tryggingafélög: Af hverju mega þau ekki sjá sömu gögn

Stærsta hönnunarmistakið í framtíðarlegum alþjóðlegum ökuskilríkjum (IDP) væri að meðhöndla hvern staðfestingaraðila sem sama staðfestingaraðilann. Lögreglumann, bílaleiguafgreiðslu, vinnuveitanda og tryggingafélag spyrja ekki sömu spurningarnar — þannig ættu þau ekki að fá sömu svarið.

Einn ökumaður. Ein undirliggjandi réttindi til að aka. Eitt veski. En fjórir mjög ólíkir staðfestingaraðilar:

• Lögreglumann við veginn
• Bílaleiguafgreiðsla við afhendingu
• Vinnuveitandi sem athugar hæfi til að aka bílflota
• Tryggingafélag sem fer yfir kröfu

Ef framtíðar IDP sýnir öllum fjórum sömu gögnin, hefur kerfið þegar brugðist. Ekki vegna þess að skilríkin eru óörugg, heldur vegna þess að upplýsingagjafarlíkanið er of einfalt.

Staðlasamfélagið er þegar að hreyfast frá þessu einfalta líkani. W3C verk um staðfestanlegar skilríki lýsir vistkerfinu í kringum útgefendur, handhafa og staðfestingaraðila, og notar vinnuveitendur og vefsíður sem dæmi um staðfestingaraðila. Verk Evrópusambandsins (ESB) um farsímaökuskilríki meðhöndlar þegar vegalegar athuganir og bílaleigu sem aðskildar staðfestingarsviðsmyndir, þar á meðal fjarlæga fyrirframdeilingu fyrir leigur og persónulegar athuganir fyrir lögreglu. Arkitektúrinn er þegar hannaður fyrir margar gerðir staðfestingaraðila. Mistakið væri að hanna notendaupplifunina eins og aðeins ein tegund sé til.

Af hverju efnislegt kortið þjálfaði okkur til að hugsa rangt

Efnisleg ökuskilríki þjálfuðu okkur í sýna-allt nálgunina. Þú réttir yfir kortið. Hinn aðilinn sér hvað er á kortinu. Þetta er öll samskiptin.

Þessi nálgun er viðunandi í pappírsheimi vegna þess að engin önnur leið er fyrir hendi. Hún verður óviðunandi í stafrænum heimi.

W3C VC gagnalíkan 2.0 segir beint: ökuskilríki geta innihaldið kennitölu, hæð, þyngd, fæðingardag og heimilisfang — en það getur enn verið miklu meira en nauðsynlegt er fyrir tiltekið viðskipti. Lykilatriði úr núgildandi stöðlum:

• Bestu starfsvenjur W3C: styðja sértæka upplýsingagjöf og óska aðeins eftir því sem er stranglega nauðsynlegt
• Leiðbeiningar ESB um gagnavernd: vinnsla verður að takmarka sig við tilgreind markmið og gögn sem unnin eru verða að vera nauðsynleg og í réttu hlutfalli
• Fyrsta meginregla framtíðar IDP: sömu skilríki þýða ekki sama rétt til að skoða

Rétta líkanið er stefnumiðuð upplýsingagjöf

Ef þú vilt alvarlegan arkitektúr er rétta líkanið nær eigindamiðaðri aðgangsstýringu en stafrænum kortakynningu.

NIST SP 800-205 skilgreinir aðgangsstýringarákvarðanir sem mat á eigindum tengdum viðfangi, hlut, umbeðinni aðgerð og umhverfisskilyrðum, gagnvart stefnu. Þetta er nákvæmlega rétt uppbygging fyrir framtíðar IDP:

• Viðfang: ökumaðurinn
• Hlutur: umbeðnir gagnareitir
• Aðgerð: ekki „sjá ökuskilríki” í óáþreifanlegum skilningi, heldur eitthvað sérstakt eins og „staðfesta rétt til að aka flokki B við veginn” eða „staðfesta leiguhæfi fyrir bókun”
• Umhverfi: vegkant, bílaleiguafgreiðsla, fjarlæg forkönnun, bílflotatengsl og kröfuyfirferð eftir tjón eru mismunandi umhverfi og ættu að leiða til mismunandi ákvarðana

NIST bendir einnig á að eigindakerfi þurfi nákvæmni, stjórnun og aðferðir til að draga úr, flokka og lágmarka eigindi.

Þannig ætti framtíðar IDP ekki að spyrja: Getur þessi staðfestingaraðili lesið ökuskilríkin? Hann ætti að spyrja: Hvaða fullyrðingar má þessi staðfestingaraðili fá, fyrir hvaða fyrirhugaða notkun, í þessu umhverfi, með hvaða varðveisluskilmálum?

Staðfestingaraðili ætti að auðkenna sig áður en hann biður um eitthvað

Framtíðar IDP ætti ekki að byrja á því að veskið sýni gögn. Það ætti að byrja á því að staðfestingaraðilinn sanni hvern hann er.

EUDI arkitektúrinn er skýr um þetta. Treystingaraðilar verða að:

• Skrá hvaða eigindi þeir hyggjast óska eftir og í hvaða tilgangi
• Fá aðgangsvottorð
• Auðkenna sig gagnvart veskinu áður en nokkrar upplýsingar eru gefnar
• Vera athugaðir gagnvart skráðu umfangi sínu, þar sem skráningarupplýsingar eru tiltækar

Notandinn getur þá séð hvern er að spyrja, hvað er beðið um og hvort beiðnin er innan skráðs umfangs.

Núverandi veski-treystingaraðilavottorðavinna ETSI gerir þetta meira áþreifanlegt. Skráningarvottorð veski-treystingaraðila getur lýst fyrirhugaðri notkun treystingaraðilans og eigindunum sem hann skráði sig til að óska eftir. Tengda aðgangsvottorðið er til til að tryggja að beiðnin komi frá lögmætum, viðurkenndum aðila. ETSI felur einnig í sér lýsigögn treystingaraðila eins og:

• Viðskiptanafn
• Þjónusta-URI
• Fyrirhuguð notkun
• Réttindi
• Skrá-URI
• Upplýsingar um eftirlitsyfirvald

Önnur meginregla framtíðar IDP: engin auðkenning staðfestingaraðila, engar upplýsingar.

Af hverju samþykktarskjáir eru ekki nægir

Hér er annað mistök: að meðhöndla samþykki notanda sem sama hlut og lögmæti.

EUDI arkitektúrinn segir skýrt að samþykki notanda til að kynna eigindi má ekki meðhöndla sem lögmætan grundvöll fyrir vinnslu treystingaraðilans á persónuupplýsingum. Treystingaraðilinn verður enn að hafa sinn eigin lögmætan grundvöll. EUDI krefst einnig samþykkis notanda í öllum notkunartilvikum, þar á meðal tilvikum þar sem treystingaraðilinn gæti verið hluti af lögreglu eða annarri ríkisstofnun.

Gott veskiviðmót getur hjálpað, en það getur ekki eitt og sér leyst ofgrip staðfestingaraðila. Reglan verður að vera til áður en viðmótið.

Framtíðar IDP þarfnast því beggja:

• Dulmálsauðkenning staðfestingaraðila til að staðfesta hvern er að spyrja
• Stefnuþvinganir á hvað sú tegund staðfestingaraðila má óska eftir

Án beggja verður „val notanda” leið til að færa stefnubrest yfir á einstakling.

1. Lögregla: Staðfestu rétt til að aka, ekki alla manneskjuna

Lögreglusviðsmyndin við veginn er sú sem er mest einbeitt.

Handbók ESB um farsímaökuskilríki lýsir þessu beint: lögregla eða aðrir embættismenn athugast ökuskilríkin þegar þess er krafist, þar á meðal gildi ökuskilríkis og ökuréttindi. Í ferðalagi notandans staðfestir lögreglumann ökuskilríkin í gegnum QR-kveiktan flæði, Bluetooth, Wi-Fi Aware eða NFC. Þetta er einbeitt staðfestingarverkefni:

• Er þessi einstaklingur handhafinn?
• Eru skilríkin gild?
• Hvaða ökuréttindi og takmarkanir gilda?

Leyfilegt sjálfgefið:

• Nafn
• Mynd
• Staða ökuskilríkis
• Útgáfu- og gildistímadagsetningar
• Flokkar
• Takmarkanir sem tengjast akstri
• Útgefandi og lögsaga
• Nýlægi/stöðuniðurstaða

Ekki leyfilegt sjálfgefið:

• Heimilisfang
• Innri auðkenni sem ekki þarf við veginn
• Ótengd eigindi frá öðrum vottorðum
• Söguleg kynningarskrá
• Viðskiptalýsigögn

Framkvæmdarleiðbeiningar AAMVA styrkja myndarmálið: ef mynd er beðin um og einhver annar þáttur er gefinn upp, ætti myndinni að vera deilt svo staðfestingaraðilinn geti tengt gögnin við þann sem kynnir þau. Sömu leiðbeiningar segja einnig að hagsmunaaðilar mega ekki rekja handhafa farsímaökuskilríkja eða notkun þeirra nema þar sem lög kveða á um það.

Lögreglutilfellið snýst ekki um að ríkið fái allt. Það snýst um að ríkið fái aksturssértæk gögn sem þarf fyrir framfylgni við veginn. Það er mikilvægur munur.

2. Bílaleiguafgreiðslur: Hæfi, auðkennissamsvörun og ekkert óþarft

Leigutilfellið er nákvæmara vegna þess að í raun eru tveir augnablikar: fjarlæg forkönnun fyrir komu og afhending þegar einstaklingur eða sjálfsafgreiðsluvél gefur lyklana.

Handbók ESB um farsímaökuskilríki líkani þegar bæði. Bílaleiguþjónusta getur beðið um farsímaökuskilríkin samhliða staðfestingu á auðkenni við bókun, staðfest vottorðin og síðar staðfest viðskiptavininn persónulega við afhendingu áður en farið er með bílinn. Notendur geta deilt farsímaökuskilríkjum sínum með bílaleigufyrirtækjum annað hvort persónulega eða fjarlægt fyrirfram.

Bílaleiguafgreiðsla þarf ekki fyrst og fremst að rannsaka atvik. Hún þarf að ákveða: Get ég leigt þennan bíl þessum viðskiptavini undir þessari bókun og stefnu?

Fjarlæg forkönnun ætti að fela í sér:

• Auðkennistengsl
• Mynd eða jafngildt auðkenningartengiþáttur
• Viðeigandi ökutækjaflokkur
• Útgáfu- og gildistímadagsetningar
• Núverandi gildi
• Mögulega aldursþröskuldur eða aldursband

Afhending ætti að staðfesta:

• Handhafinn er sami einstaklingurinn sem lauk forkönnuninni
• Núverandi gildi
• Viðeigandi réttindi

Ekki þörf sjálfgefið:

• Fullt heimilisfang þegar bókunarsnið inniheldur þegar samskiptaupplýsingar
• Fullur fæðingardagur þar sem aldursþröskuldur eða aldursband er nóg
• Ótengd auðkenniseigindir
• Endurtekin endurkynnning fullra skilríkja ef bókunarvottorð er þegar til

Núverandi farsímaökuskilríkjaarkitektúr NIST sýnir treystingaraðilann nota DCQL til að óska aðeins eftir þörfum eigindum og segir skýrt að þetta styður gagnalágmörkun og samþykki handhafa með því að skipuleggja beiðnina frekar en að meðhöndla skilríkin sem eina einingu. AAMVA bætir við að forritið ætti skýrt að sýna hvaða gögn voru beðin um og hvort staðfestingaraðilinn ætli að geyma upplýsingarnar.

3. Vinnuveitendur: Tegund staðfestingaraðila, ekki inngangur í fulla auðkenni

Yfirlit W3C notar stafrænt kerfi vinnuveitanda sem athugar háskólagráðu sem dæmi um staðfestingaraðila. Það minnir okkur á að staðfesting vinnuveitanda er þegar viðurkennt mynstur í skilríkjavistkerfum.

Vinnuveitandi eða bílflotatengill gæti lögmætt þurft að vita:

• Hvort starfsmaður á rétt til að aka tilteknum ökutækjaflokki
• Hvort lykilar takmarkanir séu til
• Hvort réttindin eru enn gild

Það er raunveruleg viðskiptaþörf. En það réttlætir ekki sjálfkrafa varanlegan aðgang að öllum ökuskilríkjum, fullum auðkennisgögnum eða stöðugri straum endurtekinna kynninga.

NIST varar við því að senda oft aftur nothæft auðkenni og þjálfa notendur til að kynna aftur og aftur auðkennisberandi skilríki sé óæskilegt, og segir að dagleg auðkenning ætti að byggja á tækni sem er hönnuð fyrir auðkenningu, eins og leynilyklar. NIST kýs staðbundna tækjauðkenningu umfram líffræðilega samsvörun á miðlarhlið vegna þess að hún verndar friðhelgi betur.

Framtíðar IDP ætti ekki að verða aðgangskort á vinnustað.

Fyrir notkun vinnuveitenda og bílflotar er rétta mynstrið vanalega:

• Athugun á starfstengdum réttindum
• Kannski reglubundin samræmisvottorð
• Kannski fullyrðing um að handhafinn sé enn gildur fyrir tilgreinda flokka
• En ekki sjálfgefinn flutningur á öllum ökuskilríkjagögnum í hvert skipti sem starfsmaðurinn skráir sig inn í kerfi eða byrjar vakt

Samræmi bílflotar er aðskilin tegund treystingaraðila, með aðskilda fyrirhugaða notkun og aðskilið upplýsingagjafarsniðmát.

4. Tryggingafélög: Kröfur eru ekki leyfi fyrir stöðuga sýnileika

Tryggingatilfellið er oft raunverulegt. Í notkunartilfellisefni ESB um farsímaökuskilríki koma tryggingafélög óbeint fram í leigusviðsmyndinni: tryggingafélög krefjast þess að bílaleigufyrirtæki athugist hvort sá sem leigir bílinn hafi rétt til að aka. Trygging hefur þegar áhrif á staðfestingarflæðið.

En það þýðir ekki að tryggingafélag ætti að fá sömu gögn og lögregla, eða varanlegan rétt til að nálgast skilríkin.

Framtíðar IDP ætti að meðhöndla tryggingafélög sem aðskilda tegund staðfestingaraðila með aðskilinni fyrirhugaðri notkun:

• Áhættumat
• Leiguáhættustaðfesting
• Meðhöndlun krafna eftir tjón
• Svikayfirferð

Það eru ekki sama markmið. Samkvæmt gagnafriðhelgisreglum ESB verður persónuupplýsingum að vera safnað í tilgreindum tilgangi og takmarka sig við það sem er nauðsynlegt og í réttu hlutfalli fyrir þann tilgang. Leiðbeiningar W3C um staðfestanlegar skilríki ná sömu niðurstöðu tæknilega: staðfestingaraðilar ættu aðeins að óska eftir því sem er stranglega nauðsynlegt.

Lögmæt, atviksértæk dæmi:

• Sönnun um að ökuskilríkin voru gild á viðkomandi tímamarki
• Sönnun um viðeigandi ökutækjaréttindi
• Sönnun um auðkennistengsl þar sem nauðsynlegt er fyrir kröfu
• Kröfusértæk upplýsingagjöf

Ekki leyfilegt sjálfgefið:

• Varanlegur aðgangur að undirliggjandi skilríkjum
• Endurtekin almenn staðfesting í hvert skipti sem viðskiptavinurinn hefur samskipti við tryggingafélagið
• Notkun ökuskilríkjanna sem innskráningarmerki
• Söfnun á ótengdum eigindum

Ökuskilríki eru ekki vaktarásáskrift. Og þau ættu ekki hljóðlega að verða það.

Af hverju milliliðar verða að vera sýnilegir

Raunverulegir markaðir fela í sér milliliði. Leigupallarnir, bílflotatargar, mannauðskerfi vinnuveitenda og tryggingakröfuvinnsluaðilar starfa oft í gegnum þriðja aðila.

EUDI arkitektúrinn meðhöndlar þetta með:

• Meðhöndlun milliliða sem treystingaraðila
• Kröfu um að þeir skrái sig
• Kröfu um að eigindi sem beðið er um fyrir milliliðs-treystingaraðilann séu skráð
• Að sýna notandanum bæði milliliðinn og endanlega treystingaraðilann
• Banni á milliliðum að geyma gögn um efni viðskiptanna

Framtíðar IDP ætti aldrei að leyfa mynstur þar sem notandinn telur sig gefa upplýsingar til bílaleigufyrirtækisins, en í raun er hann að gefa upplýsingar til ósýnilegs staðfestingarmiðlara, greiningarvinnsluaðila og kröfuseljandakeðju.

ETSI hjálpar hér. Veski-treystingaraðilavottorðalíkan þess felur í sér þjónustu-URI-ar, fyrirhugaða notkun, skrá-URI-ar og lýsigögn eftirlitsyfirvalds. Þetta er tegund vélaalesanlegrar innviðar sem notendur þurfa til að skilja hvern er í raun á hinum endanum á beiðninni og hvert eigi að fara þegar þeir vilja eyðingu eða leiðréttingu.

Varðveisla er hluti af aðgangsstýringu

Flestar umræður um sértæka upplýsingagjöf enda of snemma. Þær einblína á hvað er gefið upp. Þær einblína ekki nóg á hversu lengi það er til staðar á eftir.

Núverandi leiðbeiningar eru þegar að sameinast:

• AAMVA: veskið verður skýrt að segja handhafanum hvaða gögn voru beðin um og hvort staðfestingaraðilinn ætli að geyma þau; hagsmunaaðilar mega ekki rekja handhafa eða notkun farsímaökuskilríkja nema þar sem lög kveða á um það
• W3C: hugbúnaður handhafa ætti að bjóða upp á skrár yfir upplýsingar sem deilt er með staðfestingaraðilum, svo hægt sé að bera kennsl á óhóflegar beiðnir
• EUDI: notendur ættu að geta nálgast viðskiptaskrár, tilkynnt grunsamlegar beiðnir og beðið um eyðingu

Varðveisluflokkur ætti að vera hluti af upplýsingagjafarstefnunni sjálfri:

• Lögregla við veginn: engin varðveisla sjálfgefið umfram lögmætar rekstrarskrár
• Leiguforkönnun: viðskiptaskrá tengd bókun, ekki afnotanlegur auðkennisafrit
• Samræmi bílflotar vinnuveitanda: samræmisskrá eða vottorðaúrslit, ekki hrá skilríkjagögn
• Tryggingakrafa: kröfuskrá takmörkuð við kröfuna, ekki varanlegur aðgangur

Framtíðar IDP sem hunsar varðveislu er aðeins að hluta til friðhelgisvarandi.

Hvað veskið ætti í raun að ákveða

Ef ég þyrfti að draga þessa heilu grein saman í eina framkvæmdarreglu, væri það þetta:

Veskið ætti ekki að svara „Get ég kynnt þetta skilríki?” Það ætti að svara „Get ég kynnt þetta safn fullyrðinga fyrir þennan auðkennda staðfestingaraðila, fyrir þessa fyrirhugaðu notkun, í þessum samhengi, undir þessum varðveisluflokki?”

Sú ákvörðun ætti að vera knúin af a.m.k. þessum inntakum:

• Auðkenni staðfestingaraðila
• Tegund staðfestingaraðila
• Fyrirhuguð notkun
• Skráð umfang eiginda
• Upplýsingagjafarstefna frá útgefanda, ef til staðar
• Umhverfi (vegkant, afhending, fjarlægt, bílflotar, krafa)
• Samþykki handhafa
• Viðeigandi varðveislustefna

Staðlarnir innihalda þegar mikið af vélbúnaðinum fyrir þetta: sértæk upplýsingagjöf, auðkenning treystingaraðila, skráð fyrirhuguð notkun, aðgangsvottorð, mat á upplýsingagjafarstefnu og tilgangsbundnar beiðnir. Hvað vantar enn er agann til að meðhöndla þessi stykki sem eina samþætta upplýsingagjafar arkitektúr.

Kjarninn í rökstuðningnum

Framtíðar IDP ætti ekki að spyrja hvort hægt er að gefa upp gögn. Það ætti að spyrja:

• Hvern er að spyrja?
• Í hvaða tilgangi?
• Undir hvaða yfirvaldi?
• Í hvaða samhengi?
• Með hvaða varðveisluafleiðingum?

Lögregla, bílaleiguafgreiðslur, vinnuveitendur og tryggingafélög eru ekki fjórar merki á öðrum enda beiðni. Þau eru fjórar mismunandi áhættuflíkur, fjórar mismunandi lagalegar samhengisskilyrði, fjórar mismunandi ástæður til að spyrja — og þau ættu að framleiða fjórar mismunandi upplýsingagjafarsafnar.

Það er ekki óþarfa flækjustig. Þetta er hvernig nútímaleg ökuskilríki líta út þegar þau hætta að meðhöndla hvern staðfestingaraðila sem sama staðfestingaraðilann.