Policja, Wypożyczalnie, Pracodawcy, Ubezpieczyciele: Dlaczego Nie Powinni Widzieć Tych Samych Danych

Największym błędem projektowym przyszłego Międzynarodowego Prawa Jazdy (MPJ) byłoby traktowanie każdego weryfikatora tak samo. Funkcjonariusz policji, pracownik wypożyczalni samochodów, pracodawca i ubezpieczyciel nie zadają tego samego pytania — a zatem nie powinni otrzymywać tej samej odpowiedzi.

Jeden kierowca. Jedno podstawowe prawo do prowadzenia pojazdu. Jeden portfel. Ale czterech zupełnie różnych weryfikatorów:

• Funkcjonariusz policji przy drodze
• Pracownik wypożyczalni podczas odbioru pojazdu
• Pracodawca weryfikujący uprawnienia do obsługi floty
• Ubezpieczyciel rozpatrujący roszczenie

Jeśli przyszłe MPJ będzie pokazywać wszystkim czterem te same dane, system już na wstępie poniesie porażkę. Nie dlatego, że poświadczenie jest niezabezpieczone, lecz dlatego, że model ujawniania danych jest zbyt prosty.

Środowisko normalizacyjne już odchodzi od tego uproszczonego modelu. Prace W3C nad weryfikowalnymi poświadczeniami opisują ekosystem złożony z wystawców, posiadaczy i weryfikatorów, podając jako przykłady weryfikatorów pracodawców i strony internetowe. Prace UE nad mobilnym prawem jazdy (mDL) już traktują kontrole drogowe i wypożyczalnie samochodów jako odrębne scenariusze weryfikacji — obejmują zdalne udostępnianie danych z wyprzedzeniem dla wypożyczalni oraz kontrole osobiste dla policji. Architektura jest już zaprojektowana z myślą o wielu typach weryfikatorów. Błędem byłoby projektowanie doświadczenia użytkownika tak, jakby istniał tylko jeden typ.

Dlaczego Fizyczna Karta Nauczyła Nas Myśleć Błędnie

Fizyczne prawo jazdy przyzwyczaiło nas do podejścia „pokaż wszystko”. Wręczasz kartę. Druga osoba widzi, co jest na karcie. Na tym polega cała interakcja.

Takie podejście jest dopuszczalne w świecie papierowym, bo nie ma alternatywy. W świecie cyfrowym staje się niedopuszczalne.

W3C VC Data Model 2.0 stwierdza wprost: prawo jazdy może zawierać numer identyfikacyjny, wzrost, wagę, datę urodzenia i adres zamieszkania — ale nawet to może być znacznie więcej, niż jest niezbędne do danej transakcji. Kluczowe wnioski z aktualnych standardów:

• Zalecenie W3C: obsługiwać selektywne ujawnianie danych i żądać wyłącznie tego, co jest ściśle niezbędne
• Wytyczne UE w zakresie ochrony danych: przetwarzanie musi być ograniczone do określonych celów, a przetwarzane dane muszą być niezbędne i proporcjonalne
• Pierwsza zasada przyszłego MPJ: to samo poświadczenie nie oznacza tego samego prawa do wglądu

Właściwym Modelem Jest Ujawnianie Oparte na Zasadach

Jeśli zależy nam na poważnej architekturze, właściwym modelem jest coś bliższego kontroli dostępu opartej na atrybutach niż prezentacji cyfrowej karty.

NIST SP 800-205 definiuje decyzje dotyczące kontroli dostępu jako ocenę atrybutów związanych z podmiotem, obiektem, żądaną operacją i warunkami środowiskowymi w odniesieniu do zasad. To jest dokładnie właściwa struktura dla przyszłego MPJ:

• Podmiot: kierowca
• Obiekt: żądane pola danych
• Działanie: nie „wgląd do prawa jazdy” w sensie ogólnym, lecz coś konkretnego, jak „weryfikacja uprawnienia do prowadzenia pojazdów kategorii B przy drodze” lub „weryfikacja uprawnień do wypożyczenia pojazdu w ramach rezerwacji”
• Środowisko: kontrola drogowa, stanowisko wypożyczalni, zdalna weryfikacja wstępna, rejestracja floty i rozpatrywanie roszczeń po szkodzie to różne środowiska — i powinny prowadzić do różnych decyzji

NIST zaznacza również, że systemy atrybutów wymagają szczegółowości, ładu informacyjnego oraz mechanizmów redukcji, grupowania i minimalizacji atrybutów.

A zatem przyszłe MPJ nie powinno zadawać pytania: Czy ten weryfikator może odczytać prawo jazdy? Powinno zadawać pytanie: Które dane ten weryfikator może otrzymać, w jakim zamierzonym celu, w jakim środowisku i z jakimi zasadami dotyczącymi przechowywania danych?

Weryfikator Powinien Się Zidentyfikować, Zanim Czegokolwiek Zażąda

Przyszłe MPJ nie powinno zaczynać się od tego, że portfel ujawnia dane. Powinno zaczynać się od tego, że weryfikator udowadnia swoją tożsamość.

Architektura EUDI jest w tej kwestii jednoznaczna. Strony ufające muszą:

• Zarejestrować, jakich atrybutów zamierzają żądać i w jakim celu
• Otrzymać certyfikaty dostępu
• Uwierzytelnić się w portfelu przed jakimkolwiek ujawnieniem danych
• Być weryfikowane względem zarejestrowanego zakresu, jeśli informacje rejestracyjne są dostępne

Użytkownik może wówczas zobaczyć, kto pyta, o co jest proszony i czy żądanie mieści się w zarejestrowanym zakresie.

Trwające prace ETSI nad certyfikatami stron ufających dla portfeli nadają temu bardziej konkretny kształt. Certyfikat rejestracyjny strony ufającej może opisywać zamierzony cel jej działania oraz atrybuty, które zarejestrowała jako możliwe do żądania. Powiązany certyfikat dostępu służy zapewnieniu, że żądanie pochodzi od uprawnionej strony. ETSI obejmuje również metadane strony ufającej, takie jak:

• Nazwa handlowa
• URI wsparcia
• Zamierzony cel
• Uprawnienia
• URI rejestru
• Informacje o organie nadzorczym

Druga zasada przyszłego MPJ: brak tożsamości weryfikatora oznacza brak ujawnienia danych.

Dlaczego Ekrany Zgody Nie Są Wystarczające

Istnieje tu jeszcze inny błąd: utożsamianie zgody użytkownika z legalnością działania.

Architektura EUDI wyraźnie stwierdza, że zgoda użytkownika na udostępnienie atrybutów nie może być traktowana jako prawna podstawa przetwarzania danych osobowych przez stronę ufającą. Strona ufająca musi posiadać własną, odrębną podstawę prawną przetwarzania. EUDI wymaga również zgody użytkownika we wszystkich przypadkach użycia, w tym w sytuacjach, gdy stroną ufającą może być organ ścigania lub inna agencja rządowa.

Dobry interfejs portfela może pomóc, lecz sam w sobie nie rozwiąże problemu nadużyć ze strony weryfikatorów. Zasady muszą istnieć, zanim powstanie interfejs.

Przyszłe MPJ wymaga zatem obu elementów:

• Kryptograficznego uwierzytelnienia weryfikatora potwierdzającego tożsamość pytającego
• Ograniczeń zasad dotyczących tego, czego dana kategoria weryfikatorów może żądać

Bez obu tych elementów „wybór użytkownika” staje się sposobem na przerzucenie odpowiedzialności za błędy systemowe na jednostkę.

1. Policja: Weryfikacja Prawa do Jazdy, Nie Całej Tożsamości

Scenariusz kontroli drogowej przez policję jest najbardziej precyzyjnie określony.

Podręcznik UE dotyczący mDL opisuje go wprost: policja lub inni uprawnieni funkcjonariusze kontrolują prawo jazdy na żądanie, sprawdzając ważność dokumentu i uprawnienia do prowadzenia określonych pojazdów. W toku kontroli funkcjonariusz weryfikuje prawo jazdy za pomocą przepływu uruchamianego kodem QR, Bluetooth, Wi-Fi Aware lub NFC. Jest to zadanie weryfikacyjne o ściśle określonym zakresie:

• Czy ta osoba jest posiadaczem dokumentu?
• Czy poświadczenie jest ważne?
• Jakie uprawnienia do prowadzenia pojazdów i ograniczenia obowiązują?

Domyślnie dozwolone:

• Imię i nazwisko
• Zdjęcie
• Status prawa jazdy
• Daty wydania i ważności
• Kategorie
• Ograniczenia istotne dla kierowania pojazdem
• Wystawca i właściwa jurysdykcja
• Wynik weryfikacji aktualności/statusu

Domyślnie niedozwolone:

• Adres zamieszkania
• Identyfikatory wewnętrzne niepotrzebne do kontroli drogowej
• Niezwiązane atrybuty z innych poświadczeń
• Historyczne dzienniki prezentacji
• Metadane komercyjne

Wytyczne wdrożeniowe AAMVA potwierdzają znaczenie zdjęcia: jeśli zdjęcie jest żądane i jakikolwiek inny element jest udostępniany, zdjęcie powinno być udostępnione, aby weryfikator mógł powiązać dane z osobą je prezentującą. Te same wytyczne stanowią, że interesariusze nie mogą śledzić posiadaczy mDL ani korzystania z mDL, z wyjątkiem przypadków wymaganych przez prawo.

Przypadek kontroli policyjnej nie polega na tym, że państwo otrzymuje wszystko. Polega na tym, że państwo otrzymuje dane związane z kierowaniem pojazdem, niezbędne do egzekwowania przepisów na drodze. To istotna różnica.

2. Wypożyczalnie: Uprawnienia, Potwierdzenie Tożsamości i Nic Zbędnego

Przypadek wypożyczalni jest bardziej złożony, ponieważ w rzeczywistości obejmuje dwa momenty: zdalne sprawdzenie wstępne przed przyjazdem oraz odbiór pojazdu, kiedy osoba lub kiosk przekazuje kluczyki.

Podręcznik UE dotyczący mDL już modeluje oba przypadki. Wypożyczalnia samochodów może żądać mDL wraz z dowodem tożsamości podczas rezerwacji, zweryfikować poświadczenia, a następnie zidentyfikować klienta osobiście podczas odbioru przed wydaniem pojazdu. Użytkownicy mogą udostępniać swoje mDL wypożyczalniom samochodów zarówno osobiście, jak i zdalnie z wyprzedzeniem.

Wypożyczalnia nie musi przede wszystkim wyjaśniać żadnego incydentu. Musi podjąć decyzję: Czy mogę wynająć ten pojazd temu klientowi w ramach tej rezerwacji i na tych warunkach ubezpieczenia?

Zdalne sprawdzenie wstępne powinno obejmować:

• Powiązanie tożsamości
• Zdjęcie lub równoważny element potwierdzający tożsamość
• Odpowiednią kategorię pojazdu
• Daty wydania i ważności
• Aktualną ważność
• Ewentualnie próg wiekowy lub przedział wiekowy

Odbiór powinien potwierdzać:

• Że posiadacz jest tą samą osobą, która przeszła weryfikację wstępną
• Aktualną ważność dokumentu
• Odpowiednie uprawnienia

Domyślnie niepotrzebne:

• Pełny adres zamieszkania, gdy profil rezerwacji zawiera już dane kontaktowe
• Pełna data urodzenia, gdy wystarczy potwierdzenie przekroczenia progu wiekowego lub przedziału wiekowego
• Niezwiązane atrybuty tożsamości
• Ponowna prezentacja pełnego poświadczenia, jeśli poświadczenie rezerwacji już istnieje

Aktualna architektura mDL opracowana przez NIST pokazuje, że strona ufająca używa DCQL do żądania wyłącznie niezbędnych atrybutów, i wyraźnie stwierdza, że takie podejście wspiera minimalizację danych oraz świadomą zgodę posiadacza poprzez ustrukturyzowanie żądania, zamiast traktowania poświadczenia jako jednej całości. AAMVA dodaje, że aplikacja powinna wyraźnie pokazywać, jakie dane zostały zażądane oraz czy weryfikator zamierza je przechowywać.

3. Pracodawcy: Kategoria Weryfikatora, Nie Wgląd w Pełną Tożsamość

Przegląd W3C podaje jako przykład weryfikatora cyfrowy system pracodawcy sprawdzający dyplom ukończenia uczelni. Przypomina nam to, że weryfikacja przez pracodawcę jest już uznanym wzorcem w ekosystemach poświadczeń.

Pracodawca lub operator floty może zasadnie potrzebować wiedzieć:

• Czy pracownik posiada aktualnie uprawnienia do prowadzenia określonych kategorii pojazdów
• Czy istnieją istotne ograniczenia
• Czy uprawnienie pozostaje ważne

Jest to realna potrzeba biznesowa. Nie uzasadnia jednak automatycznie stałego dostępu do całego poświadczenia prawa jazdy, pełnych danych tożsamości ani ciągłego strumienia powtarzających się prezentacji.

NIST ostrzega, że częste przesyłanie wielokrotnie używanego identyfikatora i przyzwyczajanie użytkowników do regularnego prezentowania poświadczeń zawierających dane tożsamości jest niepożądane, i zaleca, aby uwierzytelnianie w codziennym użyciu opierało się na technologiach przeznaczonych do uwierzytelniania, takich jak klucze dostępu. NIST preferuje lokalne uwierzytelnianie na urządzeniu nad dopasowaniem biometrycznym po stronie serwera, ponieważ lepiej chroni prywatność.

Przyszłe MPJ nie powinno stać się przepustką do miejsca pracy.

W przypadku pracodawców i flot właściwym wzorcem jest zazwyczaj:

• Weryfikacja uprawnień istotnych dla wykonywanej pracy
• Ewentualnie okresowe potwierdzenie zgodności
• Ewentualnie zaświadczenie, że posiadacz zachowuje ważność uprawnień dla określonych kategorii
• Ale nie domyślny transfer wszystkich danych z prawa jazdy przy każdym logowaniu pracownika do systemu lub rozpoczęciu zmiany

Zarządzanie zgodnością floty to odrębna kategoria strony ufającej, z odrębnym zamierzonym celem i odrębnym profilem ujawniania danych.

4. Ubezpieczyciele: Roszczenia Nie Są Przyzwoleniem na Stały Wgląd w Dane

Przypadek ubezpieczeniowy jest często jak najbardziej realny. W materiałach dotyczących przypadków użycia mDL w UE ubezpieczyciele pojawiają się pośrednio w scenariuszu wypożyczalni: firmy ubezpieczeniowe wymagają od wypożyczalni samochodów sprawdzenia, czy osoba wynajmująca pojazd ma prawo do jego prowadzenia. Ubezpieczenia już teraz wpływają na przebieg weryfikacji uprawnień do jazdy.

Nie oznacza to jednak, że ubezpieczyciel powinien otrzymywać te same dane co policja ani mieć stałego dostępu do poświadczenia.

Przyszłe MPJ powinno traktować ubezpieczycieli jako odrębną kategorię weryfikatorów z odrębnymi zamierzonymi celami:

• Underwriting
• Weryfikacja ryzyka przy wynajmie
• Obsługa roszczeń po szkodzie
• Weryfikacja w przypadku podejrzenia oszustwa

To nie są te same cele. Zgodnie z unijnymi zasadami ochrony danych osobowych dane osobowe muszą być zbierane w określonych celach i ograniczone do tego, co jest niezbędne i proporcjonalne do danego celu. Wytyczne W3C dotyczące weryfikowalnych poświadczeń prowadzą technicznie do tego samego wniosku: weryfikatorzy powinni żądać wyłącznie tego, co jest ściśle niezbędne.

Uzasadnione przykłady dotyczące konkretnych zdarzeń:

• Potwierdzenie, że prawo jazdy było ważne w danym momencie
• Potwierdzenie posiadania odpowiednich uprawnień do prowadzenia pojazdu
• Potwierdzenie powiązania tożsamości, jeśli jest to konieczne dla danego roszczenia
• Ujawnienie danych związanych z konkretnym roszczeniem

Domyślnie niedozwolone:

• Stały dostęp do źródłowego poświadczenia
• Powtarzające się ogólne weryfikacje przy każdym kontakcie klienta z ubezpieczycielem
• Wykorzystanie poświadczenia prawa jazdy jako tokenu logowania
• Zbieranie niezwiązanych atrybutów

Poświadczenie prawa jazdy nie jest subskrypcją monitorowania. I nie powinno po cichu się nią stać.

Dlaczego Pośrednicy Muszą Być Widoczni

Rzeczywiste rynki angażują pośredników. Platformy wynajmu, dostawcy systemów flotowych, systemy kadrowe pracodawców oraz procesory roszczeń ubezpieczeniowych często działają za pośrednictwem stron trzecich.

Architektura EUDI rozwiązuje ten problem poprzez:

• Traktowanie pośredników jako stron ufających
• Wymóg ich rejestracji
• Wymóg rejestracji atrybutów żądanych w imieniu pośredniczącej strony ufającej
• Prezentowanie użytkownikowi zarówno pośrednika, jak i końcowej strony ufającej
• Zakaz przechowywania przez pośredników danych dotyczących treści transakcji

Przyszłe MPJ nigdy nie powinno dopuszczać sytuacji, w której użytkownik sądzi, że ujawnia dane wypożyczalni, a w rzeczywistości ujawnia je niewidocznemu brokerowi weryfikacyjnemu, procesorowi analitycznemu i łańcuchowi dostawców obsługi roszczeń.

ETSI jest tu pomocne. Model certyfikatu strony ufającej dla portfela obejmuje URI wsparcia, zamierzony cel, URI rejestru i metadane organu nadzorczego. To właśnie tego rodzaju czytelna maszynowo infrastruktura jest potrzebna użytkownikom, aby mogli zrozumieć, kto faktycznie jest po drugiej stronie żądania oraz gdzie się zwrócić, gdy chcą skorzystać z prawa do usunięcia lub korekty danych.

Zasady Przechowywania Danych Są Częścią Kontroli Dostępu

Większość dyskusji o selektywnym ujawnianiu danych kończy się zbyt wcześnie. Skupiają się na tym, co jest ujawniane. Niewystarczająco skupiają się na tym, jak długo dane pozostają dostępne po ujawnieniu.

Aktualne wytyczne zmierzają już ku spójnym wnioskom:

• AAMVA: portfel musi wyraźnie informować posiadacza, jakie dane zostały zażądane i czy weryfikator zamierza je przechowywać; interesariusze nie mogą śledzić posiadaczy ani korzystania z mDL, z wyjątkiem przypadków wymaganych przez prawo
• W3C: oprogramowanie posiadacza powinno udostępniać dzienniki informacji udostępnianych weryfikatorom, aby możliwe było wykrycie nadmiernych żądań
• EUDI: użytkownicy powinni mieć dostęp do dzienników transakcji, możliwość zgłaszania podejrzanych żądań oraz składania wniosków o usunięcie danych

Klasa przechowywania danych powinna stanowić część samej zasady ujawniania:

• Policja przy drodze: domyślnie brak przechowywania poza zgodnym z prawem operacyjnym wpisem w rejestrze
• Zdalna weryfikacja wstępna w wypożyczalni: zapis transakcji powiązany z rezerwacją, a nie kopia danych tożsamości do wielokrotnego użycia
• Zarządzanie zgodnością floty przez pracodawcę: zapis zgodności lub wynik poświadczenia, a nie surowe dane poświadczenia
• Roszczenie ubezpieczeniowe: zapis roszczenia ograniczony do danej sprawy, bez stałego dostępu

Przyszłe MPJ, które ignoruje zasady przechowywania danych, chroni prywatność jedynie częściowo.

O Czym Powinien Decydować Portfel

Gdybym miał sprowadzić cały ten artykuł do jednej zasady implementacyjnej, brzmiałaby ona następująco:

Portfel nie powinien odpowiadać na pytanie „Czy mogę przedstawić to poświadczenie?” Powinien odpowiadać na pytanie: „Czy mogę przedstawić ten zestaw danych temu uwierzytelnionemu weryfikatorowi, w tym zamierzonym celu, w tym kontekście i w ramach tej klasy przechowywania?”

Decyzja ta powinna być podejmowana na podstawie co najmniej następujących danych wejściowych:

• Tożsamość weryfikatora
• Kategoria weryfikatora
• Zamierzony cel
• Zarejestrowany zakres atrybutów
• Zasady ujawniania danych od wystawcy, jeśli są dostępne
• Środowisko (kontrola drogowa, odbiór pojazdu, weryfikacja zdalna, flota, roszczenie)
• Zgoda posiadacza
• Obowiązująca zasada przechowywania danych

Standardy zawierają już znaczną część mechanizmów niezbędnych do realizacji tego celu: selektywne ujawnianie danych, uwierzytelnianie strony ufającej, zarejestrowany zamierzony cel, certyfikaty dostępu, ocenę zasad ujawniania oraz żądania powiązane z celem. Brakuje jeszcze dyscypliny, aby potraktować te elementy jako jedną spójną architekturę ujawniania danych.

Kluczowy Argument

Przyszłe MPJ nie powinno pytać, czy dane mogą zostać ujawnione. Powinno pytać:

• Kto pyta?
• W jakim celu?
• Na podstawie jakiego uprawnienia?
• W jakim kontekście?
• Z jakimi konsekwencjami w zakresie przechowywania danych?

Policja, wypożyczalnie, pracodawcy i ubezpieczyciele to nie cztery logo po drugiej stronie żądania. To cztery różne modele ryzyka, cztery różne konteksty prawne, cztery różne podstawy do zadawania pytań — i powinny prowadzić do czterech różnych zestawów ujawnianych danych.

To nie jest niepotrzebna złożoność. Tak właśnie wygląda nowoczesne poświadczenie prawa jazdy, gdy przestaje traktować każdego weryfikatora tak samo.