Policie, půjčovny aut, zaměstnavatelé, pojišťovny: Proč nesmí vidět stejná data

Největší chybou v návrhu budoucího mezinárodního řidičského průkazu (MŘP) by bylo zacházet s každým ověřovatelem jako se stejným ověřovatelem. Policista, přepážka půjčovny aut, zaměstnavatel a pojišťovna si nekládou stejnou otázku – a proto by neměli dostávat stejnou odpověď.

Jeden řidič. Jedno základní právo řídit. Jedna peněženka. Ale čtyři velmi odlišní ověřovatelé:

• Policista u silnice
• Přepážka půjčovny aut při převzetí vozidla
• Zaměstnavatel ověřující způsobilost k řízení firemního vozidla
• Pojišťovna posuzující pojistnou událost

Pokud budoucí MŘP zobrazí stejná data všem čtyřem, systém již selhal. Ne proto, že by přihlašovací údaje nebyly bezpečné, ale proto, že model zveřejňování je příliš jednoduchý.

Normalizační komunita se od tohoto jednoduchého modelu již odklání. Práce W3C na ověřitelných přihlašovacích údajích popisuje ekosystém vydavatelů, držitelů a ověřovatelů a jako příklady ověřovatelů uvádí zaměstnavatele a webové stránky. Práce EU na mobilním řidičském průkazu (mŘP) již považuje silniční kontroly a půjčovny aut za samostatné scénáře ověřování – včetně vzdáleného předchozího sdílení pro půjčovny a osobních kontrol pro policii. Architektura je již navržena pro více typů ověřovatelů. Chybou by bylo navrhovat uživatelskou zkušenost, jako by existoval pouze jeden typ.

Proč nás fyzická karta naučila myslet nesprávně

Fyzický průkaz nás naučil přístupu „ukázat vše”. Předáte kartu. Druhá osoba vidí, co je na kartě. To je celá interakce.

Tento přístup je v papírovém světě přijatelný, protože neexistuje žádná alternativa. V digitálním světě se stává nepřijatelným.

Datový model W3C VC 2.0 přímo uvádí: řidičský průkaz může obsahovat číslo průkazu, výšku, váhu, datum narození a domácí adresu – ale i to může být pro danou transakci mnohem více, než je nutné. Klíčové body ze současných standardů:

• Osvědčený postup W3C: podporovat selektivní zveřejňování a požadovat pouze to, co je nezbytně nutné
• Pokyny EU k ochraně osobních údajů: zpracování musí být omezeno na stanovené účely a zpracovávané údaje musí být nezbytné a přiměřené
• První zásada budoucího MŘP: stejné přihlašovací údaje neznamená stejné právo na nahlížení

Správný model je zveřejňování řízené zásadami

Pokud chcete seriózní architekturu, správný model je blíže řízení přístupu na základě atributů než prezentaci digitální karty.

NIST SP 800-205 definuje rozhodnutí o řízení přístupu jako hodnocení atributů spojených se subjektem, objektem, požadovanou operací a podmínkami prostředí oproti zásadám. To je přesně ta správná struktura pro budoucí MŘP:

• Subjekt: řidič
• Objekt: požadovaná datová pole
• Akce: ne abstraktní „zobrazit průkaz”, ale něco konkrétního, například „ověřit nárok na řízení vozidla kategorie B při silniční kontrole” nebo „ověřit způsobilost k půjčení pro konkrétní rezervaci”
• Prostředí: silniční kontrola, přepážka půjčovny, vzdálená předběžná kontrola, nástup do firemní flotily a posouzení pohledávky po pojistné události jsou různá prostředí a měla by vést k různým rozhodnutím

NIST také poznamenává, že systémy atributů potřebují granularitu, správu a mechanismy pro redukci, seskupování a minimalizaci atributů.

Budoucí MŘP by se tedy neměl ptát: Může tento ověřovatel přečíst průkaz? Měl by se ptát: Které údaje může tento ověřovatel obdržet, k jakému zamýšlenému účelu, v tomto prostředí a s jakými pravidly uchovávání?

Ověřovatel by se měl identifikovat dříve, než o cokoli požádá

Budoucí MŘP by neměl začínat tím, že peněženka zobrazí data. Měl by začínat tím, že ověřovatel prokáže svou totožnost.

Architektura EUDI je v tomto ohledu jasná. Spoléhající se strany musí:

• Zaregistrovat, které atributy hodlají požadovat a za jakým účelem
• Obdržet přístupové certifikáty
• Ověřit se u peněženky před jakýmkoli zveřejněním
• Být kontrolovány vůči své registrované oblasti působnosti, pokud jsou registrační informace dostupné

Uživatel pak může vidět, kdo se ptá, co je požadováno a zda je žádost v rámci registrované oblasti působnosti.

Současná práce ETSI na certifikátech spoléhajících se stran peněženky toto zpřesňuje. Registrační certifikát spoléhající se strany peněženky může popisovat zamýšlené použití spoléhající se strany a atributy, které zaregistrovala k vyžádání. Související přístupový certifikát existuje proto, aby zajistil, že žádost pochází od legitimní, oprávněné strany. ETSI také zahrnuje metadata spoléhající se strany, jako jsou:

• Obchodní název
• Podpůrný identifikátor URI
• Zamýšlené použití
• Oprávnění
• Identifikátor URI registru
• Informace o dozorném orgánu

Druhá zásada budoucího MŘP: bez ověření totožnosti ověřovatele nedojde k žádnému zveřejnění.

Proč obrazovky souhlasu nestačí

Zde se skrývá další chyba: zacházet se souhlasem uživatele jako s totéž, co právní legitimita.

Architektura EUDI výslovně uvádí, že souhlas uživatele s prezentací atributů nesmí být považován za zákonný důvod pro zpracování osobních údajů spoléhající se stranou. Spoléhající se strana musí mít stále svůj vlastní zákonný základ. EUDI také vyžaduje souhlas uživatele ve všech případech použití, včetně případů, kdy by spoléhající se strana mohla být součástí orgánů činných v trestním řízení nebo jiné vládní agentury.

Dobré rozhraní peněženky může pomoci, ale samo o sobě nemůže vyřešit překračování pravomocí ověřovatele. Pravidlo musí existovat před rozhraním.

Budoucí MŘP proto potřebuje obojí:

• Kryptografické ověření totožnosti ověřovatele pro potvrzení, kdo se ptá
• Omezení zásadami týkající se toho, co daná kategorie ověřovatele může požadovat

Bez obojího se „volba uživatele” stává způsobem, jak přenést selhání zásad na jednotlivce.

1. Policie: Ověřte právo řídit, ne celou osobu

Scénář silniční policie je nejvíce zaměřený.

Příručka EU pro mŘP to popisuje přímo: policie nebo jiní úředníci kontrolují průkaz, pokud je to vyžadováno, včetně platnosti průkazu a nároků na vozidlo. Při uživatelské cestě policista ověří průkaz prostřednictvím toku spuštěného QR kódem, Bluetooth, Wi-Fi Aware nebo NFC. Jde o zaměřený ověřovací úkol:

• Je tato osoba držitelem průkazu?
• Je přihlašovací údaj platný?
• Jaké nároky na vozidlo a omezení platí?

Povoleno ve výchozím nastavení:

• Jméno
• Fotografie
• Stav průkazu
• Data vydání a platnosti
• Kategorie
• Omezení relevantní pro řízení
• Vydavatel a jurisdikce
• Výsledek čerstvosti/stavu

Ve výchozím nastavení není povoleno:

• Domácí adresa
• Interní identifikátory nepotřebné pro použití při silniční kontrole
• Nesouvisející atributy z jiných atestací
• Historické záznamy o prezentaci
• Komerční metadata

Implementační pokyny AAMVA posilují bod týkající se fotografie: pokud je fotografie vyžádána a jakýkoli jiný prvek je uvolněn, fotografie by měla být sdílena, aby ověřovatel mohl spojit data s osobou, která je prezentuje. Stejné pokyny také říkají, že zúčastněné strany nesmí sledovat držitele mŘP ani používání mŘP, s výjimkou případů požadovaných zákonem.

Případ policie není o tom, aby stát obdržela vše. Jde o to, aby stát obdržel data specifická pro řízení potřebná pro silniční vymáhání práva. To je důležitý rozdíl.

2. Půjčovny aut: způsobilost, ověření totožnosti a nic zbytečného

Případ půjčovny je podrobnější, protože existují skutečně dva momenty: vzdálená předběžná kontrola před příjezdem a převzetí, kdy osoba nebo kiosek předá klíče.

Příručka EU pro mŘP již modeluje obojí. Služba půjčovny aut může při rezervaci požádat o mŘP spolu s dokladem totožnosti, ověřit atestace a později ověřit zákazníka osobně při převzetí před vydáním vozidla. Uživatelé mohou sdílet své mŘP s půjčovnami aut osobně nebo vzdáleně předem.

Přepážka půjčovny primárně nepotřebuje vyšetřovat incident. Potřebuje rozhodnout: Mohu pronajmout toto vozidlo tomuto zákazníkovi v rámci této rezervace a zásad?

Vzdálená předběžná kontrola by měla zahrnovat:

• Propojení identity
• Fotografii nebo rovnocenný prvek vázající identitu
• Příslušnou kategorii vozidla
• Data vydání a platnosti
• Aktuální platnost
• Případně věkový práh nebo věkové pásmo

Při převzetí by mělo být potvrzeno:

• Že držitel je totožnou osobou, která dokončila předběžnou kontrolu
• Aktuální platnost
• Příslušná oprávnění

Ve výchozím nastavení není potřeba:

• Úplná domácí adresa, pokud profil rezervace již obsahuje kontaktní údaje
• Úplné datum narození, pokud postačuje potvrzení věku nebo věkové pásmo
• Nesouvisející atributy identity
• Opakovaná prezentace celého přihlašovacího dokladu, pokud již existuje atestace rezervace

Současná architektura mŘP NIST ukazuje, že spoléhající se strana používá DCQL k vyžádání pouze potřebných atributů, a výslovně uvádí, že to podporuje minimalizaci dat a souhlas držitele strukturováním žádosti, nikoli zacházením s přihlašovacím dokladem jako s jednou jednotkou. AAMVA dodává, že aplikace by měla jasně zobrazit, jaká data byla vyžádána a zda má ověřovatel v úmyslu informace uchovávat.

3. Zaměstnavatelé: Kategorie ověřovatele, nikoli vstupenka do celé identity

Přehled W3C používá jako příklad ověřovatele digitální systém zaměstnavatele kontrolující univerzitní diplom. To nám připomíná, že ověřování zaměstnavatelem je již uznávaným vzorem v ekosystémech přihlašovacích dokladů.

Zaměstnavatel nebo provozovatel flotily může legitimně potřebovat vědět:

• Zda je pracovník aktuálně oprávněn řídit určité kategorie vozidel
• Zda existují klíčová omezení
• Zda oprávnění zůstává platné

To je skutečná obchodní potřeba. Ale automaticky neopravňuje k trvalému přístupu k celému řidičskému průkazu, úplným identifikačním údajům nebo nepřetržitému toku opakovaných prezentací.

NIST varuje, že časté přenášení opakovaně použitelného identifikátoru a podmínění uživatelů k opakované prezentaci přihlašovacího dokladu obsahujícího identitu je nežádoucí, a říká, že každodenní autentizace by se měla spoléhat na technologie navržené pro autentizaci, jako jsou přístupové klíče. NIST upřednostňuje místní autentizaci zařízení před porovnáváním biometrických údajů na straně serveru, protože lépe chrání soukromí.

Budoucí MŘP by se neměl stát pracovním přístupovým průkazem.

Pro použití zaměstnavatelem a flotilou je správným vzorem obvykle:

• Kontrola oprávnění relevantního pro danou práci
• Případně pravidelná atestace shody
• Případně tvrzení, že držitel zůstává platný pro určené kategorie
• Nikoli však výchozí přenos všech dat průkazu pokaždé, když se zaměstnanec přihlásí do systému nebo nastoupí ke směně

Správa souladu flotily je samostatnou kategorií spoléhající se strany, se samostatným zamýšleným použitím a samostatným profilem zveřejňování.

4. Pojišťovny: Pojistné události nejsou povolením k trvalé viditelnosti

Případ pojišťovnictví je často reálný. V materiálech EU o případech použití mŘP se pojišťovny nepřímo objevují ve scénáři půjčovny: pojišťovny požadují, aby půjčovny aut ověřily, zda má osoba půjčující auto právo řídit. Pojišťovnictví již ovlivňuje tok ověřování řidičů.

To ale neznamená, že pojišťovna by měla dostávat stejná data jako policie nebo trvalé právo přístupu k přihlašovacímu dokladu.

Budoucí MŘP by měl zacházet s pojišťovnami jako se samostatnou kategorií ověřovatelů se samostatnými zamýšlenými účely:

• Upisování pojistného
• Ověření rizika pronájmu
• Vyřizování pojistných událostí po pojistné události
• Šetření podvodů

To není stejný účel. Podle zásad ochrany osobních údajů EU musí být osobní údaje shromažďovány pro stanovené účely a omezeny na to, co je pro daný účel nezbytné a přiměřené. Technické pokyny W3C pro ověřitelné přihlašovací doklady dospívají ke stejnému závěru: ověřovatelé by měli požadovat pouze to, co je nezbytně nutné.

Legitimní příklady specifické pro danou událost:

• Doklad o platnosti průkazu v příslušném okamžiku
• Doklad o příslušném oprávnění pro vozidlo
• Doklad o propojení identity, pokud je to nezbytné pro pojistnou událost
• Zveřejnění specifické pro pojistnou událost

Ve výchozím nastavení není povoleno:

• Trvalý přístup k základnímu přihlašovacímu dokladu
• Opakované obecné ověřování pokaždé, když zákazník komunikuje s pojišťovnou
• Použití řidičského průkazu jako přihlašovacího tokenu
• Shromažďování nesouvisejících atributů

Řidičský průkaz není předplatné monitorování. A neměl by se jím tiše stát.

Proč musí být zprostředkovatelé viditelní

Reálné trhy zahrnují zprostředkovatele. Platformy půjčoven, dodavatelé flotil, systémy HR zaměstnavatelů a zpracovatelé pojistných událostí často jednají prostřednictvím třetích stran.

Architektura EUDI to řeší tím, že:

• Zachází se zprostředkovateli jako se spoléhajícími se stranami
• Vyžaduje jejich registraci
• Vyžaduje, aby atributy požadované pro zprostředkovanou spoléhající se stranu byly registrovány
• Zobrazuje uživateli jak zprostředkovatele, tak koncovou spoléhající se stranu
• Zakazuje zprostředkovatelům uchovávat údaje o obsahu transakce

Budoucí MŘP by nikdy neměl umožňovat situaci, kdy uživatel věří, že sděluje údaje půjčovně aut, ale ve skutečnosti je sděluje neviditelnému řetězci ověřovacích brokerů, analytických procesorů a dodavatelů pojistných pohledávek.

Zde pomáhá ETSI. Jeho model certifikátu spoléhající se strany peněženky zahrnuje podpůrné URI, zamýšlené použití, URI registru a metadata dozorného orgánu. To je typ strojově čitelné infrastruktury potřebné proto, aby uživatelé pochopili, kdo se skutečně nachází na druhém konci žádosti a kam se obrátit, když chtějí smazání nebo opravu.

Uchovávání je součástí řízení přístupu

Většina diskusí o selektivním zveřejňování končí příliš brzy. Zaměřují se na to, co je zveřejněno. Nedostatečně se zaměřují na to, jak dlouho to zůstává poté.

Současné pokyny se již sbližují:

• AAMVA: peněženka musí jasně informovat držitele o tom, jaká data byla vyžádána a zda má ověřovatel v úmyslu je uchovávat; zúčastněné strany nesmí sledovat držitele ani používání mŘP, s výjimkou případů požadovaných zákonem
• W3C: software držitele by měl poskytovat záznamy informací sdílených s ověřovateli, aby bylo možné identifikovat nadměrné požadavky
• EUDI: uživatelé by měli mít přístup k záznamům transakcí, hlásit podezřelé požadavky a žádat o vymazání

Třída uchovávání by měla být součástí samotné zásady zveřejňování:

• Silniční policie: ve výchozím nastavení žádné uchovávání nad rámec zákonného operačního záznamu
• Předběžná kontrola v půjčovně: záznam transakce vázaný na rezervaci, nikoli opakovaně použitelná kopie identity
• Správa souladu firemní flotily zaměstnavatele: záznam o souladu nebo výsledek atestace, nikoli surová data přihlašovacího dokladu
• Pojistná událost pojišťovny: záznam pohledávky omezený na danou pohledávku, nikoli trvalý přístup

Budoucí MŘP, který ignoruje uchovávání, je pouze částečně chránící soukromí.

Co by peněženka měla skutečně rozhodovat

Kdybych měl celý tento článek zredukovat na jedno implementační pravidlo, bylo by to toto:

Peněženka by neměla odpovídat na otázku „Mohu tento přihlašovací doklad prezentovat?” Měla by odpovídat na otázku „Mohu tomuto ověřenému ověřovateli prezentovat tuto sadu tvrzení, pro tento zamýšlený účel, v tomto kontextu, v rámci této třídy uchovávání?”

Toto rozhodnutí by mělo být řízeno přinejmenším těmito vstupy:

• Totožnost ověřovatele
• Kategorie ověřovatele
• Zamýšlený účel
• Registrovaná oblast atributů
• Zásady zveřejňování od vydavatele, pokud jsou k dispozici
• Prostředí (silniční kontrola, převzetí, vzdálené, flotila, pohledávka)
• Souhlas držitele
• Platné zásady uchovávání

Standardy již obsahují velkou část mechanismů pro toto: selektivní zveřejňování, ověřování spoléhající se strany, registrované zamýšlené použití, přístupové certifikáty, hodnocení zásad zveřejňování a žádosti vázané na účel. Co stále chybí, je disciplína zacházet s těmito prvky jako s jednou ucelenou architekturou zveřejňování.

Hlavní argument

Budoucí MŘP by se neměl ptát, zda lze data zveřejnit. Měl by se ptát:

• Kdo se ptá?
• Za jakým účelem?
• Na základě jakého oprávnění?
• V jakém kontextu?
• S jakými důsledky pro uchovávání?

Policie, půjčovny aut, zaměstnavatelé a pojišťovny nejsou čtyři loga na druhém konci žádosti. Jsou to čtyři různé modely rizik, čtyři různé právní kontexty, čtyři různé důvody k dotazu – a měly by produkovat čtyři různé sady zveřejněných údajů.

To není zbytečná složitost. Takto vypadá moderní řidičský průkaz, když přestane zacházet s každým ověřovatelem jako se stejným ověřovatelem.