Poliisi, vuokraamojen tiskit, työnantajat, vakuutusyhtiöt: Miksi niiden ei pidä nähdä samoja tietoja

Suurin suunnitteluvirhe tulevassa kansainvälisessä ajoluvassa (IDP) olisi kohdella jokaista tarkastajaa samanlaisena. Poliisiviranomainen, autonvuokraamon tiski, työnantaja ja vakuutusyhtiö eivät esitä samaa kysymystä – joten niille ei pidä antaa samaa vastausta.

Yksi kuljettaja. Yksi taustalla oleva ajamisoikeus. Yksi lompakko. Mutta neljä hyvin erilaista tarkastajaa:

• Poliisiviranomainen tien varrella
• Autonvuokraamon tiski noutamisen yhteydessä
• Työnantaja, joka tarkistaa ajoneuvokaluston kelpoisuuden
• Vakuutusyhtiö, joka käsittelee korvausvaatimusta

Jos tuleva IDP näyttää kaikille neljälle samat tiedot, järjestelmä on jo epäonnistunut. Ei siksi, että tunniste olisi epäturvallinen, vaan siksi, että tietojen luovuttamismalli on liian yksinkertainen.

Standardointiyhteisö siirtyykin jo pois tästä yksinkertaisesta mallista. W3C:n todennettavia valtuutuksia koskeva työ kuvaa ekosysteemiä, jossa ovat myöntäjät, haltijat ja tarkastajat, käyttäen esimerkkinä työnantajia ja verkkosivustoja. EU:n mobiiliajokorttityö kohtelee jo tienvarren tarkastuksia ja autonvuokrauksia erillisinä varmennusskenaarioina, mukaan lukien etukäteen tapahtuva etäjako vuokrausta varten ja henkilökohtaiset tarkastukset poliisille. Arkkitehtuuri on jo suunniteltu useita tarkastajatyyppejä varten. Virhe olisi suunnitella käyttökokemus ikään kuin vain yksi tyyppi olisi olemassa.

Miksi fyysinen kortti opetti meidät ajattelemaan väärin

Fyysinen ajokortti opetti meidät “näytä kaikki” -lähestymistapaan. Annat kortin. Toinen henkilö näkee, mitä kortissa lukee. Siinä koko vuorovaikutus.

Tämä lähestymistapa on hyväksyttävä paperisessa maailmassa, koska vaihtoehtoa ei ole. Digitaalisessa maailmassa se muuttuu kuitenkin sopimattomaksi.

W3C VC -tietomalli 2.0 toteaa suoraan: ajokortti voi sisältää henkilötunnuksen, pituuden, painon, syntymäpäivän ja kotiosoitteen – mutta tämä voi silti olla paljon enemmän kuin tiettyä tapahtumaa varten on tarpeen. Keskeisiä seikkoja nykyisistä standardeista:

• W3C:n paras käytäntö: tukee valikoivaa tietojen luovuttamista ja pyytää vain ehdottomasti välttämätöntä
• EU:n tietosuojaohjeet: käsittelyn on rajoituttava määriteltyihin tarkoituksiin, ja käsiteltävien tietojen on oltava tarpeellisia ja oikeasuhteisia
• Tulevan IDP:n ensimmäinen periaate: sama tunniste ei tarkoita samaa oikeutta tarkastella

Oikea malli on käytäntöpohjainen tietojen luovuttaminen

Jos haluat vakavan arkkitehtuurin, oikea malli on lähempänä attribuuttipohjaista pääsynhallintaa kuin digitaalisen kortin esittämistä.

NIST SP 800-205 määrittelee pääsynhallintapäätökset kohteeseen, objektiin, pyydettyyn toimintoon ja ympäristöolosuhteisiin liittyvien attribuuttien arvioinneiksi käytäntöä vasten. Tämä on täsmälleen oikea rakenne tulevalle IDP:lle:

• Kohde: kuljettaja
• Objekti: pyydetyt tietokentät
• Toiminto: ei “näe ajokortin” abstraktisti, vaan jokin tarkempi asia, kuten “vahvista oikeus ajaa B-luokan ajoneuvoja tien varrella” tai “vahvista vuokrauskelpoisuus varaukselle”
• Ympäristö: tienvarsi, vuokraamon tiski, etukäteen tehtävä etätarkastus, kaluston käyttöönotto ja vahingon jälkeinen korvausvaatimusten käsittely ovat erilaisia ympäristöjä ja niiden pitäisi johtaa erilaisiin päätöksiin

NIST huomauttaa myös, että attribuuttijärjestelmät tarvitsevat tarkkuutta, hallintoa sekä mekanismeja attribuuttien vähentämiseen, ryhmittelyyn ja minimointiin.

Joten tulevan IDP:n ei pidä kysyä: Voiko tämä tarkastaja lukea ajokortin? Sen pitää kysyä: Mitä vaatimuksia tämä tarkastaja saa vastaanottaa, mihin käyttötarkoitukseen, missä ympäristössä ja millä säilytyssäännöillä?

Tarkastajan on tunnistauduttava ennen kuin pyytää mitään

Tulevan IDP:n ei pidä alkaa lompakon näyttämistä tiedoista. Sen pitää alkaa tarkastajan todistamisesta, kuka se on.

EUDI-arkkitehtuuri on tässä selkeä. Luottavien osapuolten on:

• Rekisteröitävä, mitä attribuutteja ne aikovat pyytää ja mihin tarkoitukseen
• Saatava pääsytodistukset
• Todennettava itsensä lompakossa ennen mitään tietojen luovuttamista
• Tarkistuttava rekisteröityä laajuuttaan vasten, kun rekisteröintitiedot ovat saatavilla

Käyttäjä voi sitten nähdä, kuka pyytää, mitä pyydetään ja onko pyyntö rekisteröidyn laajuuden mukainen.

ETSI:n nykyinen lompakko–luottava osapuoli -sertifikaattityö tekee tästä konkreettisempaa. Lompakko–luottavan osapuolen rekisteröintisertifikaatti voi kuvata luottavan osapuolen aiottua käyttöä ja attribuutteja, joiden pyytämiseen se on rekisteröitynyt. Siihen liittyvä pääsytodistus on olemassa sen varmistamiseksi, että pyyntö tulee lailliselta, valtuutetulta osapuolelta. ETSI sisältää myös luottavan osapuolen metatietoja, kuten:

• Toiminimi
• Tukisivusto-URI
• Aiottu käyttötarkoitus
• Käyttöoikeudet
• Rekisteri-URI
• Valvontaviranomaisen tiedot

Tulevan IDP:n toinen periaate: ei tarkastajan henkilöllisyyttä, ei tietojen luovuttamista.

Miksi suostumusnäytöt eivät riitä

Tässä on myös toinen virhe: käyttäjän hyväksynnän pitäminen samana asiana kuin oikeudellinen laillisuus.

EUDI-arkkitehtuuri sanoo nimenomaisesti, että käyttäjän hyväksyntää attribuuttien esittämiselle ei saa pitää laillisena perusteena luottavan osapuolen henkilötietojen käsittelylle. Luottavalla osapuolella on silti oltava oma oikeudellinen perustansa. EUDI edellyttää myös käyttäjän hyväksyntää kaikissa käyttötapauksissa, mukaan lukien tapaukset, joissa luottava osapuoli saattaa olla osa lainvalvontaa tai muuta viranomaista.

Hyvä lompakkorajapinta voi auttaa, mutta se ei yksinään voi ratkaista tarkastajan ylitöiden ongelmaa. Sääntöjen on oltava olemassa ennen rajapintaa.

Tulevassa IDP:ssä tarvitaan siksi molemmat:

• Kryptografinen tarkastajan todennus sen vahvistamiseksi, kuka pyytää
• Käytäntörajoitukset sille, mitä kyseinen tarkastajaryhmä saa pyytää

Ilman molempia “käyttäjän valinta” muuttuu tavaksi siirtää käytäntövika yksilön harteille.

1. Poliisi: Vahvista ajamisoikeus, ei koko henkilö

Poliisin tienvarren skenaario on kaikkein tarkin.

EU:n mobiiliajokorttikäsikirja kuvaa sen suoraan: poliisi tai muut viranomaiset tarkistavat ajokortin vaadittaessa, mukaan lukien ajokortin voimassaolo ja ajoneuvoluokat. Käyttäjäpolussa virkailija tarkistaa ajokortin QR-koodilla käynnistyvän kulun, Bluetoothin, Wi-Fi Awaren tai NFC:n kautta. Kyseessä on tarkennettu varmennustehtävä:

• Onko tämä henkilö haltija?
• Onko tunniste voimassa?
• Mitkä ajoneuvoluokat ja rajoitukset ovat voimassa?

Oletuksena sallittu:

• Nimi
• Valokuva
• Ajokortin tila
• Myöntämis- ja voimassaolopäivät
• Luokat
• Ajamiseen liittyvät rajoitukset
• Myöntäjä ja lainkäyttöalue
• Tuoreus-/tilatulos

Oletuksena ei sallittu:

• Kotiosoite
• Sisäiset tunnisteet, joita ei tarvita tienvarren käyttöön
• Muihin todistuksiin liittymättömät attribuutit
• Historialliset esittämislokit
• Kaupalliset metatiedot

AAMVA:n toteutusohjeet vahvistavat valokuvan osalta: jos valokuvaa pyydetään ja jokin muu tieto luovutetaan, valokuva on jaettava, jotta tarkastaja voi yhdistää tiedot sen esittävään henkilöön. Sama ohje sanoo myös, että sidosryhmät eivät saa seurata mobiiliajokortin haltijoita tai mobiiliajokortin käyttöä paitsi lain niin vaatiessa.

Poliisitapaus ei ole se, että valtio saa kaiken. Se tarkoittaa sitä, että valtio saa tienvarren lainvalvontaa varten tarvittavat ajamiskohtaiset tiedot. Tämä on tärkeä ero.

2. Vuokraamojen tiskit: Kelpoisuus, henkilöllisyyden vastaavuus ja ei mitään tarpeetonta

Vuokraustapaus on yksityiskohtaisempi, koska siinä on todella kaksi hetkeä: etukäteen tehtävä etätarkistus ennen saapumista ja nouto, kun henkilö tai kioski luovuttaa avaimet.

EU:n mobiiliajokorttikäsikirja mallintaa molemmat jo. Autonvuokrauspalvelu voi pyytää mobiiliajokorttia yhdessä henkilöllisyystodistuksen kanssa varauksen yhteydessä, vahvistaa todistukset ja myöhemmin tarkistaa asiakkaan henkilökohtaisesti noudettaessa ennen ajoneuvon luovuttamista. Käyttäjät voivat jakaa mobiiliajokorttinsa autonvuokrausyrityksille joko henkilökohtaisesti tai etukäteen etänä.

Vuokraamon tiskin ei ensisijaisesti tarvitse tutkia tapahtumaa. Sen on päätettävä: Voinko vuokrata tämän ajoneuvon tälle asiakkaalle tämän varauksen ja käytännön perusteella?

Etukäteen tehtävän etätarkistuksen tulisi sisältää:

• Henkilöllisyyden linkitys
• Valokuva tai vastaava henkilöllisyyden sidontaelementti
• Asiaankuuluva ajoneuvoluokka
• Myöntämis- ja voimassaolopäivät
• Nykyinen voimassaolo
• Mahdollisesti ikäraja tai ikäryhmä

Noudon yhteydessä tulisi vahvistaa:

• Haltija on sama henkilö, joka suoritti etutarkistuksen
• Nykyinen voimassaolo
• Asiaankuuluvat oikeudet

Oletuksena ei tarvita:

• Koko kotiosoite, kun varausprofiili sisältää jo yhteystiedot
• Täydellinen syntymäaika, kun ikäraja tai ikäryhmä riittää
• Liittymättömät henkilöllisyysattribuutit
• Toistuvat koko tunnisteen uudelleenesimiset, jos varauksen todistus on jo olemassa

NIST:n nykyinen mobiiliajokorttiarkkitehtuuri osoittaa, että luottava osapuoli käyttää DCQL:ää pyytääkseen vain tarvittavat attribuutit, ja sanoo nimenomaisesti, että tämä tukee tietojen minimointia ja haltijan suostumusta jäsentämällä pyynnön sen sijaan, että tunniste käsiteltäisiin yhtenä kokonaisuutena. AAMVA lisää, että sovelluksen tulee selkeästi näyttää, mitä tietoja pyydettiin ja aikooko tarkastaja säilyttää tiedot.

3. Työnantajat: Tarkastajaryhmä, ei avain koko henkilöllisyyteen

W3C:n yleiskatsaus käyttää työnantajan digitaalista järjestelmää, joka tarkistaa yliopistotutkinnon, tarkastajan esimerkkinä. Tämä muistuttaa meitä siitä, että työnantajan varmennus on jo tunnistettu malli tunnistusekosysteemeissä.

Työnantaja tai kalustonhaltija voi perustellusti tarvita tietää:

• Onko työntekijällä tällä hetkellä oikeus ajaa tiettyjä ajoneuvoluokkia
• Onko olemassa keskeisiä rajoituksia
• Pysyykö oikeus voimassa

Tämä on todellinen liiketoimintatarve. Mutta se ei automaattisesti oikeuta pysyvään pääsyyn koko ajokorttitunnisteeseen, kaikkiin henkilötietoihin tai jatkuvaan toistuvien esitysten virtaan.

NIST varoittaa, että uudelleenkäytettävän tunnisteen toistuvaa lähettämistä ja käyttäjien ehdollistamista toistuvasti esittämään henkilöllisyyttä kantava tunniste on epätoivottavaa, ja sanoo, että päivittäisessä todennuksessa tulisi käyttää todennukseen suunniteltuja teknologioita, kuten salasanoja. NIST suosii paikallista laitteen todennusta palvelinpuolen biometrisen vastaavuuden sijaan, koska se suojaa paremmin yksityisyyttä.

Tulevasta IDP:stä ei saa tulla työpaikan kulkukortti.

Työnantajan ja kaluston käyttöön oikea malli on yleensä:

• Työn kannalta merkityksellinen oikeuksien tarkistus
• Ehkä säännöllinen vaatimustenmukaisuustodistus
• Ehkä vaatimus siitä, että haltija pysyy voimassa tietyille luokille
• Mutta ei kaikkien ajokorttitietojen oletusarvoista siirtoa joka kerta, kun työntekijä kirjautuu järjestelmään tai aloittaa vuoronsa

Kalustonhallinta on erillinen luottavan osapuolen ryhmä, jolla on erillinen aiottu käyttötarkoitus ja erillinen tietojen luovuttamisprofiili.

4. Vakuutusyhtiöt: Korvausvaatimukset eivät ole lupa jatkuvaan näkyvyyteen

Vakuutustapauksessa asia on usein todellinen. EU:n mobiiliajokortin käyttöesimerkeissä vakuutusyhtiöt esiintyvät epäsuorasti vuokrausskenaariossa: vakuutusyhtiöt vaativat autonvuokrausyrityksiä tarkistamaan, onko auton vuokraavalla henkilöllä ajamisoikeus. Vakuutus vaikuttaa jo ajamisen varmennusprosessiin.

Mutta tämä ei tarkoita, että vakuutusyhtiöllä pitäisi olla samat tiedot kuin poliisilla tai pysyvä oikeus päästä tunnisteeseen.

Tulevan IDP:n pitäisi kohdella vakuutusyhtiöitä erillisenä tarkastajaryhmänä, jolla on erilliset aiottut käyttötarkoitukset:

• Vakuutuksen myöntäminen
• Vuokrausriskin arviointi
• Vahingon jälkeinen korvausvaatimusten käsittely
• Petostutkinta

Nämä eivät ole sama tarkoitus. EU:n tietosuojaperiaatteiden mukaan henkilötietoja on kerättävä määriteltyihin tarkoituksiin ja rajoitettava siihen, mikä on tarpeellista ja oikeasuhteista kyseiseen tarkoitukseen nähden. W3C:n VC-ohje päätyy samaan teknisesti: tarkastajien pitäisi pyytää vain ehdottomasti välttämätöntä.

Lailliset, tapauskohtaiset esimerkit:

• Todistus siitä, että ajokortti oli voimassa kyseisellä hetkellä
• Todistus asiaankuuluvasta ajoneuvoluokasta
• Todistus henkilöllisyyden linkityksestä, kun se on välttämätöntä vaatimukselle
• Vaatimuskohtainen tietojen luovuttaminen

Oletuksena ei sallittu:

• Pysyvä pääsy taustalla olevaan tunnisteeseen
• Toistuva yleinen varmennus joka kerta, kun asiakas on tekemisissä vakuutusyhtiön kanssa
• Ajokorttitunnisteen käyttäminen kirjautumistunnuksena
• Liittymättömien attribuuttien keruu

Ajokorttitunniste ei ole seurantatilaus. Eikä se saa hiljaisesti sellaiseksi muuttua.

Miksi välittäjien on oltava näkyviä

Todellisilla markkinoilla on välittäjiä. Vuokrausalustat, kalustonhallintapalvelut, työnantajien henkilöstöjärjestelmät ja vakuutuskorvausten käsittelijät toimivat usein kolmansien osapuolten kautta.

EUDI-arkkitehtuuri käsittelee tätä seuraavasti:

• Kohtelemalla välittäjiä luottavina osapuolina
• Vaatimalla niiltä rekisteröitymistä
• Vaatimalla, että välitettyä luottavaa osapuolta varten pyydetyt attribuutit on rekisteröity
• Näyttämällä käyttäjälle sekä välittäjän että lopullisen luottavan osapuolen
• Kieltämällä välittäjiä tallentamasta tietoja tapahtuman sisällöstä

Tulevan IDP:n ei saa koskaan sallia tilannetta, jossa käyttäjä uskoo luovuttavansa tietoja vuokrausyritykselle, mutta todellisuudessa luovuttaa tietoja näkymättömälle varmennusvälittäjälle, analytiikkaprosessorille ja korvausvaatimusten toimittajaketjulle.

ETSI auttaa tässä. Sen lompakko–luottava osapuoli -sertifikaattimalli sisältää tukisivusto-URI:t, aiottun käyttötarkoituksen, rekisteri-URI:t ja valvontaviranomaisten metatiedot. Tämä on sellaista koneluettavaa infrastruktuuria, jota käyttäjät tarvitsevat ymmärtääkseen, kuka todella on pyynnön toisessa päässä ja minne mennä, kun he haluavat poistamisen tai korjauksen.

Säilytys on osa pääsynhallintaa

Useimmat valikoivaa tietojen luovuttamista koskevat keskustelut päättyvät liian aikaisin. Ne keskittyvät siihen, mitä luovutetaan. Ne eivät kiinnitä riittävästi huomiota siihen, kuinka kauan se pysyy sen jälkeen.

Nykyinen ohjeistus on jo lähentymässä:

• AAMVA: lompakon on selkeästi kerrottava haltijalle, mitä tietoja pyydettiin ja aikooko tarkastaja säilyttää ne; sidosryhmät eivät saa seurata haltijoita tai mobiiliajokortin käyttöä paitsi lain niin vaatiessa
• W3C: haltijaohjelmiston tulisi tarjota lokeja tarkastajille jaetuista tiedoista, jotta liiallinen pyyntö voidaan tunnistaa
• EUDI: käyttäjien pitäisi pystyä tutustumaan tapahtumalokeihin, ilmoittamaan epäilyttävistä pyynnöistä ja pyytämään poistamista

Säilytysluokan tulisi olla osa itse tietojen luovuttamiskäytäntöä:

• Poliisin tienvarsi: ei säilytystä oletuksena lainmukaisen operatiivisen kirjanpidon ulkopuolella
• Vuokrauksen etutarkistus: varaukseen sidottu tapahtumakirjanpito, ei uudelleenkäytettävä henkilöllisyyskopio
• Työnantajan kalustonhallinta: vaatimustenmukaisuuskirjanpito tai todistustulos, ei raakatunnistedata
• Vakuutuskorvaus: korvausvaatimukseen rajattu kirjanpito, ei pysyvää pääsyä

Tuleva IDP, joka jättää säilytyksen huomiotta, säilyttää yksityisyyden vain osittain.

Mitä lompakon pitäisi todella päättää

Jos minun pitäisi tiivistää koko tämä artikkeli yhteen toteutussääntöön, se olisi tämä:

Lompakon ei pitäisi vastata “Voinko esittää tämän tunnisteen?” Sen pitäisi vastata “Voinko esittää tämän vaatimusjoukon tälle todennetulle tarkastajalle, tähän aiottuun käyttötarkoitukseen, tässä kontekstissa, tämän säilytysluokan mukaisesti?”

Tämän päätöksen pitäisi perustua vähintään näihin syötteisiin:

• Tarkastajan henkilöllisyys
• Tarkastajan ryhmä
• Aiottu käyttötarkoitus
• Rekisteröity attribuuttilaajuus
• Myöntäjän tietojen luovuttamiskäytäntö, jos saatavilla
• Ympäristö (tienvarsi, nouto, etäyhteys, kalusto, korvausvaatimus)
• Haltijan hyväksyntä
• Sovellettava säilytyskäytäntö

Standardit sisältävät jo suuren osan tästä koneistosta: valikoiva tietojen luovuttaminen, luottavan osapuolen todennus, rekisteröity aiottu käyttötarkoitus, pääsytodistukset, tietojen luovuttamiskäytännön arviointi ja tarkoitukseen sidotut pyynnöt. Vielä puuttuu kurinalaisuus kohdella näitä osia yhtenä johdonmukaisena tietojen luovuttamisarkkitehtuurina.

Ydinargumentti

Tulevan IDP:n ei pidä kysyä, voidaanko tietoja luovuttaa. Sen pitää kysyä:

• Kuka pyytää?
• Mihin tarkoitukseen?
• Minkä viranomaisen alaisuudessa?
• Missä kontekstissa?
• Millä säilytysseuraamuksilla?

Poliisi, vuokraamojen tiskit, työnantajat ja vakuutusyhtiöt eivät ole neljä logoa pyynnön toisessa päässä. Ne ovat neljä erilaista riskimallia, neljä erilaista oikeudellista kontekstia, neljä erilaista syytä pyytää – ja niiden pitäisi tuottaa neljä erilaista tietojen luovuttamisjoukkoa.

Se ei ole tarpeetonta monimutkaisuutta. Se on sitä, miltä moderni ajokorttitunniste näyttää, kun se lakkaa kohtelemasta jokaista tarkastajaa samanlaisena tarkastajana.