Rendőrség, Autókölcsönzők, Munkaadók, Biztosítók: Miért Nem Láthatják Ugyanazokat az Adatokat

A jövőbeli Nemzetközi Gépjárművezetői Engedély (NGE) tervezésének legnagyobb hibája az lenne, ha minden ellenőrzőt ugyanolyannak kezelnénk. Egy rendőr, egy autókölcsönző pult, egy munkáltató és egy biztosító nem ugyanazt a kérdést teszi fel – ezért nem kaphatják ugyanazt a választ.

Egy sofőr. Egyetlen alapvető vezetési jogosultság. Egyetlen digitális tárca. De négy teljesen különböző ellenőrző:

• Egy rendőr az út szélén
• Egy autókölcsönző pult az átvételkor
• Egy munkáltató, aki a flottahasználati jogosultságot ellenőrzi
• Egy biztosító, aki egy kártérítési igényt vizsgál felül

Ha a jövőbeli NGE mind a négy félnek ugyanazokat az adatokat mutatja, a rendszer már kudarcot vallott. Nem azért, mert a hitelesítő okmány nem biztonságos, hanem mert az adatközlési modell túl egyszerű.

A szabványügyi közösség már elmozdult ettől az egyszerű modelltől. A W3C hitelesíthető hitelesítőkkel (verifiable credentials) kapcsolatos munkája leírja a kibocsátók, tulajdonosok és ellenőrzők körüli ökoszisztémát, ahol munkáltatók és weboldalak szerepelnek ellenőrzőként. Az EU mobil gépjárművezetői engedéllyel kapcsolatos munkája már az útszéli ellenőrzéseket és az autókölcsönzéseket külön ellenőrzési forgatókönyvként kezeli, beleértve a kölcsönzésekhez szükséges előzetes távoli megosztást és a rendőrségi személyes ellenőrzéseket. Az architektúra már több ellenőrzőtípusra van tervezve. A hiba az lenne, ha a felhasználói élményt úgy terveznénk meg, mintha csak egyetlen típus létezne.

Miért Tanított Minket Tévesen a Fizikai Kártya

A fizikai engedély egy „mutass meg mindent” megközelítésre szoktatott minket. Átadod a kártyát. A másik személy látja, mi van rajta. Ez maga az egész interakció.

Ez a megközelítés elfogadható a papíralapú világban, mert nincs alternatíva. A digitális világban azonban már elfogadhatatlan.

A W3C VC Data Model 2.0 közvetlenül kimondja: egy gépjárművezetői engedély tartalmazhat azonosítószámot, testmagasságot, testsúlyt, születési dátumot és lakcímet – de ez még mindig jóval több lehet, mint ami egy adott tranzakcióhoz szükséges. A jelenlegi szabványok főbb pontjai:

• W3C bevált gyakorlat: támogasd a szelektív közzétételt, és csak a feltétlenül szükséges adatokat kérelmezd
• EU adatvédelmi iránymutatás: a feldolgozást meghatározott célokra kell korlátozni, és a feldolgozott adatoknak szükségeseknek és arányosaknak kell lenniük
• A jövőbeli NGE első alapelve: az egységes hitelesítő okmány nem jelent egységes megtekintési jogot

A Helyes Modell a Szabályzatalapú Közzététel

Ha komoly architektúrát szeretnénk, a megfelelő modell közelebb áll az attribútumalapú hozzáférés-vezérléshez, mint a digitális kártyabemutatáshoz.

Az NIST SP 800-205 a hozzáférés-vezérlési döntéseket úgy határozza meg, mint az alannyal, objektummal, kért művelettel és környezeti feltételekkel kapcsolatos attribútumok szabályzattal szembeni értékelését. Ez pontosan a megfelelő struktúra a jövőbeli NGE számára:

• Alany: a sofőr
• Objektum: a kért adatmezők
• Művelet: nem „engedély megtekintése” elvontan, hanem valami konkrét, például „B kategóriás vezetési jogosultság igazolása az út szélén” vagy „bérleti jogosultság igazolása egy foglaláshoz”
• Környezet: az út széle, az autókölcsönző pult, a távoli előzetes ellenőrzés, a flottabeszállás és a kárrendezés utáni felülvizsgálat különböző környezetek, amelyeknek különböző döntésekhez kell vezetniük

Az NIST azt is megjegyzi, hogy az attribútumrendszereknek részletességre, irányításra, valamint az attribútumok csökkentésének, csoportosításának és minimalizálásának mechanizmusaira van szükségük.

Ezért a jövőbeli NGE-nek nem azt kell kérdeznie: Olvashatja-e ez az ellenőrző az engedélyt? Hanem azt: Mely adatokat kaphatja meg ez az ellenőrző, milyen tervezett felhasználás céljából, milyen környezetben, milyen megőrzési szabályok mellett?

Az Ellenőrzőnek Azonosítania Kell Magát, Mielőtt Bármit Kér

A jövőbeli NGE-nek nem az adatok megjelenítésével kell kezdődnie a tárcában. Az ellenőrzőnek kell igazolnia, ki ő.

Az EUDI architektúra ebben egyértelmű. A megbízó feleknek:

• Regisztrálniuk kell, hogy milyen attribútumokat kívánnak kérni és milyen célból
• Hozzáférési tanúsítványokat kell kapniuk
• Hitelesíteniük kell magukat a tárca előtt, mielőtt bármilyen adatközlés történik
• Ellenőrizni kell őket a regisztrált hatókörük alapján, ahol a regisztrációs információ elérhető

A felhasználó ezután láthatja, ki kérdez, mit kér, és hogy a kérés a regisztrált hatókörön belül van-e.

Az ETSI jelenlegi, tárca-megbízófél tanúsítványra vonatkozó munkája ezt konkrétabbá teszi. A tárca-megbízófél regisztrációs tanúsítvány leírhatja a megbízó fél tervezett felhasználását és a kérni regisztrált attribútumokat. A kapcsolódó hozzáférési tanúsítvány annak biztosítására szolgál, hogy a kérés törvényes, felhatalmazott féltől érkezzen. Az ETSI emellett tartalmaz megbízófél-metaadatokat, mint például:

• Kereskedelmi név
• Támogatási URI
• Tervezett felhasználás
• Jogosultságok
• Regisztrációs URI
• Felügyeleti hatóság adatai

A jövőbeli NGE második alapelve: ellenőrző azonosítása nélkül nincs adatközlés.

Miért Nem Elegendők a Hozzájárulási Képernyők

Van itt egy másik hiba is: a felhasználói jóváhagyást ugyanolyannak kezelni, mint a jogi legitimitást.

Az EUDI architektúra kifejezetten kimondja, hogy a felhasználó attribútumok bemutatásához adott jóváhagyása nem tekinthető a megbízó fél személyes adatok feldolgozásának jogszerű alapjaként. A megbízó félnek még mindig szüksége van a saját jogszerű jogalapjára. Az EUDI emellett minden felhasználási esetben megköveteli a felhasználói jóváhagyást, beleértve azokat az eseteket is, ahol a megbízó fél bűnüldöző szerv vagy más kormányzati ügynökség lehet.

Egy jó tárcafelület segíthet, de önmagában nem oldhatja meg az ellenőrzői túlkapásokat. A szabálynak a felületet megelőzően kell léteznia.

Ezért a jövőbeli NGE-nek mindkettőre szüksége van:

• Kriptográfiai ellenőrző-hitelesítés annak megerősítésére, ki kérdez
• Szabályzatbeli korlátok arra vonatkozóan, hogy az adott ellenőrzői kategória mit kérhet

E kettő nélkül a „felhasználói választás” a szakpolitikai kudarcot az egyénre hárítja.

1. Rendőrség: Igazold a Vezetési Jogosultságot, Ne az Egész Személyt

A rendőrségi útszéli helyszíni ellenőrzés a legfókuszáltabb eset.

Az EU mDL kézikönyv közvetlenül leírja: a rendőrség vagy más hatóságok szükség esetén ellenőrzik az engedélyt, beleértve az engedély érvényességét és a jármű-jogosultságokat. A felhasználói folyamatban a tisztviselő QR-kód alapú folyamaton, Bluetooth-on, Wi-Fi Aware-en vagy NFC-n keresztül ellenőrzi az engedélyt. Ez egy fókuszált ellenőrzési feladat:

• Ez a személy a jogosultság tulajdonosa?
• Érvényes-e a hitelesítő okmány?
• Milyen jármű-jogosultságok és korlátozások vonatkoznak rá?

Alapértelmezés szerint megengedett:

• Név
• Fénykép
• Engedély érvényessége
• Kiállítás és lejárat dátumai
• Kategóriák
• Vezetéshez kapcsolódó korlátozások
• Kibocsátó és joghatóság
• Frissesség/érvényességi eredmény

Alapértelmezés szerint nem megengedett:

• Lakcím
• Útszéli felhasználáshoz nem szükséges belső azonosítók
• Más igazolásokból származó, nem kapcsolódó attribútumok
• Korábbi bemutatási naplók
• Kereskedelmi metaadatok

Az AAMVA megvalósítási útmutatója megerősíti a fénykép fontosságát: ha a fényképet kérik, és bármely más elemet megjelenítenek, a fényképet is meg kell osztani, hogy az ellenőrző összeköthesse az adatokat a bemutatót személlyel. Ugyanez az útmutató azt is kimondja, hogy az érdekelteknek nem szabad nyomon követniük az mDL-tulajdonosokat vagy az mDL-használatot, kivéve, ha azt a jog előírja.

A rendőrségi eset nem arról szól, hogy az állam mindent megkap. Arról szól, hogy az állam megkapja az útszéli érvényesítéshez szükséges, vezetésre vonatkozó adatokat. Ez fontos különbség.

2. Autókölcsönzők: Jogosultság, Személyazonosság-egyeztetés és Semmi Felesleges

Az autókölcsönzési eset részletesebb, mert valójában két pillanat van: a megérkezés előtti távoli előzetes ellenőrzés és az átvételkor, amikor egy személy vagy kioszk átadja a kulcsokat.

Az EU mDL kézikönyv már modellezi mindkettőt. Egy autókölcsönző szolgáltatás a foglalás során kérheti az mDL-t a személyazonosság igazolásával együtt, érvényesítheti az igazolásokat, majd később személyesen ellenőrizheti az ügyfelet az átvételkor, mielőtt átadja a járművet. A felhasználók megoszthatják mDL-jüket autókölcsönző cégekkel személyesen vagy előre, távolról is.

Egy autókölcsönző pultnak elsősorban nem egy incidenst kell kivizsgálnia. El kell döntenie: Kikölcsönözhetem-e ezt a járművet ennek az ügyfélnek a jelen foglalás és szabályzat alapján?

A távoli előzetes ellenőrzésnek tartalmaznia kell:

• Személyazonossági kapcsolat
• Fénykép vagy azzal egyenértékű azonosítást kötő elem
• Releváns jármű-kategória
• Kiállítás és lejárat dátumai
• Jelenlegi érvényesség
• Esetleg egy korhatár vagy korcsoport

Az átvételnek meg kell erősítenie:

• A tulajdonos ugyanaz a személy, aki az előzetes ellenőrzést elvégezte
• Jelenlegi érvényesség
• Releváns jogosultságok

Alapértelmezés szerint nem szükséges:

• Teljes lakcím, ha a foglalási profil már tartalmaz elérhetőségi adatokat
• Teljes születési dátum, ahol a korhatár vagy korcsoport elegendő
• Nem kapcsolódó személyazonossági attribútumok
• A teljes hitelesítő okmány ismételt bemutatása, ha már létezik foglalási igazolás

Az NIST jelenlegi mDL architektúrája azt mutatja, hogy a megbízó fél DCQL-t használ csak a szükséges attribútumok kérésére, és kifejezetten kimondja, hogy ez támogatja az adatminimalizálást és a tulajdonosi hozzájárulást azáltal, hogy strukturálja a kérést ahelyett, hogy a hitelesítő okmányt egyetlen egységként kezelné. Az AAMVA hozzáteszi, hogy az alkalmazásnak egyértelműen meg kell mutatnia, milyen adatokat kértek, és hogy az ellenőrző szándékozik-e megőrizni az információkat.

3. Munkaadók: Egy Ellenőrzői Kategória, Nem Belépés a Teljes Személyazonosságba

A W3C áttekintése egy munkáltató digitális rendszerét használja, amely egy egyetemi fokozatot ellenőriz, mint ellenőrzői példát. Ez emlékeztet minket arra, hogy a munkáltatói ellenőrzés már elismert minta a hitelesítő okmány ökoszisztémákban.

Egy munkáltató vagy flottaüzemeltető jogszerűen tudnia kell:

• Hogy egy munkavállaló jelenleg jogosult-e bizonyos járműkategóriák vezetésére
• Hogy vannak-e kulcsfontosságú korlátozások
• Hogy a jogosultság érvényes-e

Ez valódi üzleti igény. De nem igazolja automatikusan a teljes gépjárművezetői hitelesítő okmányhoz, a teljes személyazonossági adatokhoz vagy az ismételt bemutatások folyamatos sorozatához való állandó hozzáférést.

Az NIST figyelmeztet, hogy egy újrafelhasználható azonosító rendszeres továbbítása és a felhasználók arra szoktatása, hogy személyazonosságot hordozó hitelesítő okmányukat folyamatosan bemutassák, nemkívánatos, és azt mondja, hogy a mindennapi hitelesítésnek hitelesítésre tervezett technológiákra kell támaszkodnia, például jelszókulcsokra. Az NIST a helyi eszközalapú hitelesítést részesíti előnyben a szerveralapú biometrikus egyeztetéssel szemben, mert az jobban megőrzi az adatvédelmet.

A jövőbeli NGE nem válhat munkahelyi belépőkártyává.

Munkáltatói és flottahasználat esetén a megfelelő minta általában a következő:

• Munkával kapcsolatos jogosultság ellenőrzése
• Esetleg időszakos megfelelőségi igazolás
• Esetleg egy állítás arról, hogy a tulajdonos érvényes marad a meghatározott kategóriákra
• De nem az összes engedélyadat alapértelmezett továbbítása minden alkalommal, amikor a munkavállaló bejelentkezik egy rendszerbe vagy elkezd egy műszakot

A flottamegfelelőség egy külön megbízófél-kategória, külön tervezett felhasználással és külön közzétételi profillal.

4. Biztosítók: A Kártérítési Igény Nem Jelent Engedélyt a Folyamatos Láthatóságra

A biztosítási eset gyakran valódi. Az EU mDL felhasználási eseteket tartalmazó anyagban a biztosítók közvetett módon jelennek meg a bérlési forgatókönyvben: a biztosítótársaságok megkövetelik az autókölcsönzőktől, hogy ellenőrizzék, van-e az autót bérlő személynek jogosultsága a vezetésre. A biztosítás már befolyásolja a vezetésigazolás-ellenőrzési folyamatot.

Ez azonban nem jelenti azt, hogy egy biztosítónak ugyanazokat az adatokat kell kapnia, mint a rendőrségnek, vagy állandó hozzáférési joggal kell rendelkeznie a hitelesítő okmányhoz.

A jövőbeli NGE-nek a biztosítókat külön ellenőrzői kategóriaként kell kezelnie, külön tervezett felhasználásokkal:

• Kockázatbiztosítás
• Bérlési kockázat ellenőrzése
• Kárrendezés utáni kezelés
• Csalásvizsgálat

Ezek nem ugyanolyan célok. Az EU adatvédelmi elvei szerint a személyes adatokat meghatározott célokra kell gyűjteni, és azokra a célokra szükséges és arányos mértékre kell korlátozni. A W3C VC útmutatása technikai szempontból ugyanerre a következtetésre jut: az ellenőrzőknek csak a feltétlenül szükséges adatokat kell kérniük.

Jogszerű, eseményspecifikus példák:

• Igazolás, hogy az engedély érvényes volt a releváns pillanatban
• Igazolás a releváns jármű-jogosultságról
• Személyazonossági kapcsolat igazolása, ahol szükséges egy kártérítési igényhez
• Kártérítési igény-specifikus közzététel

Alapértelmezés szerint nem engedélyezett:

• Állandó hozzáférés az alapul szolgáló hitelesítő okmányhoz
• Ismételt általános ellenőrzés minden alkalommal, amikor az ügyfél kapcsolatba lép a biztosítóval
• A gépjárművezetői hitelesítő okmány bejelentkezési tokenként való használata
• Nem kapcsolódó attribútumok gyűjtése

A gépjárművezetői hitelesítő okmány nem megfigyelési előfizetés. És nem szabad csendben azzá válnia.

Miért Kell Láthatónak Lennie a Közvetítőknek

A valódi piacok közvetítőket foglalnak magukban. A bérlési platformok, flottaszállítók, munkáltatói HR-rendszerek és biztosítási kárrendező feldolgozók gyakran harmadik feleken keresztül járnak el.

Az EUDI architektúra ezt a következőképpen kezeli:

• A közvetítőket megbízó felekként kezeli
• Megköveteli tőlük a regisztrációt
• Megköveteli, hogy a közvetített megbízó fél számára kért attribútumok regisztrálva legyenek
• Megmutatja a felhasználónak mind a közvetítőt, mind a végső megbízó felet
• Megtiltja a közvetítőknek, hogy adatokat tároljanak a tranzakció tartalmáról

A jövőbeli NGE-nek soha nem szabad lehetővé tennie azt a mintát, ahol a felhasználó úgy hiszi, hogy az autókölcsönzőnek ad ki adatokat, valójában azonban egy láthatatlan ellenőrzési közvetítőnek, elemzési feldolgozónak és kárrendezési szállítói láncnak teszi közzé azokat.

Az ETSI ebben segít. A tárca-megbízófél tanúsítványmodellje tartalmaz támogatási URI-kat, tervezett felhasználást, regisztrációs URI-kat és felügyeleti hatóság metaadatait. Ez az a fajta géppel olvasható infrastruktúra, amelyre a felhasználóknak szükségük van ahhoz, hogy megértsék, ki van valójában a kérés másik végén, és hová forduljanak, ha törlést vagy helyesbítést szeretnének kérni.

A Megőrzés az Hozzáférés-vezérlés Része

A szelektív közzétételről szóló legtöbb vita túl korán ér véget. Arra összpontosít, mi kerül közzétételre. Nem összpontosít eléggé arra, mennyi ideig marad meg utána.

A jelenlegi iránymutatás már közeledik egymáshoz:

• AAMVA: a tárcának egyértelműen tájékoztatnia kell a tulajdonost arról, milyen adatokat kértek, és hogy az ellenőrző szándékozik-e megőrizni azokat; az érdekelteknek nem szabad nyomon követniük a tulajdonosokat vagy az mDL-használatot, kivéve, ha a jog előírja
• W3C: a tulajdonos szoftvernek naplókat kell biztosítania az ellenőrzőkkel megosztott információkról, hogy azonosítani lehessen a túlzott kéréseket
• EUDI: a felhasználóknak hozzá kell tudniuk férni a tranzakciós naplókhoz, jelenteniük kell a gyanús kéréseket, és kérniük kell a törlést

A megőrzési osztálynak magának a közzétételi szabályzatnak kell részét képeznie:

• Rendőrségi útszéli ellenőrzés: alapértelmezés szerint nincs megőrzés a jogszerű műveleti nyilvántartáson túl
• Bérlési előzetes ellenőrzés: a tranzakciós rekord a foglaláshoz kötve, nem újrafelhasználható személyazonosság-másolat
• Munkáltatói flottamegfelelőség: megfelelőségi rekord vagy igazolás eredménye, nem nyers hitelesítő okmány adatok
• Biztosítói kártérítési igény: az igényhez korlátozott igényrekord, nem állandó hozzáférés

Egy jövőbeli NGE, amely figyelmen kívül hagyja a megőrzést, csak részben védi az adatvédelmet.

Mit Kell Valójában Eldöntenie a Tárcának

Ha ezt az egész cikket egyetlen megvalósítási szabályra kellene redukálnom, az ez lenne:

A tárcának nem azt kell megválaszolnia: „Bemutathatom-e ezt a hitelesítő okmányt?” Hanem ezt: „Bemutathatom-e ezt az állításkészletet ennek a hitelesített ellenőrzőnek, erre a tervezett felhasználásra, ebben a kontextusban, e megőrzési osztály keretein belül?”

Ezt a döntést legalább a következő inputoknak kell vezérelniük:

• Ellenőrző személyazonossága
• Ellenőrző kategóriája
• Tervezett felhasználás
• Regisztrált attribútum-hatókör
• A kibocsátó közzétételi szabályzata, ha van ilyen
• Környezet (út széle, átvétel, távoli, flotta, kártérítési igény)
• Tulajdonos jóváhagyása
• Alkalmazandó megőrzési szabályzat

A szabványok már tartalmazzák ennek nagy részét: szelektív közzététel, megbízó fél hitelesítése, regisztrált tervezett felhasználás, hozzáférési tanúsítványok, közzétételi szabályzat értékelése és célalapú kérések. Ami még hiányzik, az a fegyelem, hogy ezeket az elemeket egyetlen koherens közzétételi architektúraként kezeljük.

Az Alapérv

A jövőbeli NGE-nek nem azt kell kérdeznie, hogy az adatok közzétehetők-e. Azt kell kérdeznie:

• Ki kérdez?
• Milyen célból?
• Milyen hatáskör alapján?
• Milyen kontextusban?
• Milyen megőrzési következményekkel?

A rendőrség, az autókölcsönzők, a munkaadók és a biztosítók nem négy logó egy kérés másik végén. Ez négy különböző kockázati modell, négy különböző jogi kontextus, négy különböző ok a kérdezésre – és négy különböző közzétételi készletet kell eredményezniük.

Ez nem szükségtelen bonyolultság. Így néz ki egy modern gépjárművezetői hitelesítő okmány, amikor abbahagyja, hogy minden ellenőrzőt ugyanolyannak kezeljen.