Dlaczego Blockchain Jest Opcjonalny dla Przyszłego Międzynarodowego Prawa Jazdy (MPJ)

Przyszłe Międzynarodowe Prawo Jazdy (MPJ) potrzebuje przejrzystości, kotwic zaufania i publicznej rozliczalności. Czego z założenia nie potrzebuje — to umieszczania samych kierowców w rozproszonym rejestrze.

Każda poważna rozmowa o cyfrowym, transgranicznym MPJ prędzej czy później przyciąga tę samą propozycję: „Po prostu umieść to na blockchainie.” Atrakcyjność tego pomysłu jest zrozumiała. Blockchainy oferują odporność na manipulacje, wspólną widoczność i historię tylko do dopisywania. To są realne właściwości. Jednak w kontekście transgranicznej tożsamości kierowcy bardzo często są one stosowane do niewłaściwej warstwy.

Ten artykuł wyjaśnia dlaczego, omawia, co naprawdę mówią standardy, i przedstawia lepszy wzorzec architektoniczny.

Co Naprawdę Mówią Standardy o Blockchainie

Model danych weryfikowalnych poświadczeń W3C wyraźnie stwierdza, że weryfikowalny rejestr danych może przybierać wiele form, w tym:

• Zaufane bazy danych
• Zdecentralizowane bazy danych
• Rządowe bazy danych tożsamości
• Rozproszone rejestry

DID Core jest równie jasny: wiele metod DID używa technologii rozproszonego rejestru, ale nie wszystkie. Innymi słowy, standardy już odrzucają pogląd, że blockchain jest obowiązkową podstawą dla cyfrowych poświadczeń.

To jest właściwy punkt wyjścia dla przyszłego MPJ. Użyteczne pytanie brzmi nie „blockchain czy nie blockchain?”, lecz:

Która warstwa rzeczywiście wymaga przejrzystości, a która absolutnie nie powinna domyślnie stawać się publiczną infrastrukturą?

Blockchain to Zbiór Właściwości, Nie Wymóg

Pierwszym błędem jest traktowanie „blockchainu” jako pojedynczego wymogu. Tak nie jest. To zbiór możliwych właściwości, w tym:

• Wspólna publikacja
• Historia tylko do dopisywania
• Zdecentralizowane działanie
• Generowanie potwierdzeń
• Odporność na jednostronne zmiany

Niektóre z tych właściwości są przydatne dla przyszłego MPJ. Niektóre są nieistotne. A niektóre są wręcz niebezpieczne, gdy są stosowane do podmiotów poświadczeń będących ludźmi. Model rejestru W3C celowo dopuszcza wiele implementacji, ponieważ różne ekosystemy wymagają różnych kompromisów.

Trzy Problemy, Których Nie Należy Łączyć

Drugim błędem jest łączenie trzech różnych problemów w jeden system. Dla przyszłego MPJ muszą one pozostać oddzielne:

1. Gdzie mieszka prawda prawna. Prawo do prowadzenia pojazdów należy do autorytatywnych krajowych rejestrów praw jazdy.
2. Jak dystrybuowane są materiały zaufania. Klucze wystawców i certyfikaty weryfikatorów należą do kontrolowanych rejestrów zaufania.
3. Jak ekosystem audytuje zmiany. To należy do warstwy przejrzystości.

Rzeczywiste ekosystemy już tak działają. Usługa Digital Trust Service stowarzyszenia AAMVA dystrybuuje publiczne klucze wystawców w postaci listy do pobrania, zanim weryfikator wejdzie w interakcję z mDL. Podręcznik mobilnego prawa jazdy UE określa, że Państwa Członkowskie powiadamiają Komisję o autoryzowanych wystawcach mDL, a Komisja publikuje listę weryfikacyjną tych organów. To jest dystrybucja zaufania bez blockchainu.

Czego Uczy Nas Transparentność Certyfikatów

Najskuteczniejszy model przejrzystości w publicznym internecie to nie konsumencki blockchain. To Transparentność Certyfikatów (CT).

RFC 9162 opisuje CT jako protokół do publicznego rejestrowania certyfikatów serwerów TLS, dzięki któremu każdy może:

• Audytować działalność urzędów certyfikacji
• Wykrywać problematyczne lub nieprawidłowo wydane certyfikaty
• Audytować same dzienniki

Kluczowa lekcja projektowa z CT: przejrzystość jest najcenniejsza, gdy rejestruje zachowanie wystawców i materiały zaufania — nie aktywność użytkowników końcowych.

W zastosowaniu do przyszłego MPJ oznacza to rejestrowanie takich rzeczy jak:

• Wydawanie i rotacja kluczy wystawców
• Publikacja kotwic zaufania
• Rejestracja kategorii weryfikatorów
• Zmiany polityki
• Oświadczenia o zgodności
• Zdarzenia istotne dla bezpieczeństwa

Czego nie oznacza, to tworzenie publicznego lub półpublicznego rejestru posiadaczy, identyfikatorów poświadczeń lub zdarzeń prezentacji. To nie jest przejrzystość. To nadmierne zbieranie danych.

SCITT: Dlaczego Przejrzystość Nie Jest Tym Samym co Prawda

Projekt architektury SCITT IETF rozszerza to myślenie. SCITT definiuje Usługę Przejrzystości, która utrzymuje weryfikowalną strukturę danych i wydaje kryptograficzne potwierdzenia dowodzące włączenia podpisanych oświadczeń. Tożsamość Usługi Przejrzystości jest uchwycona przez klucz publiczny znany stronom ufającym, a kotwice zaufania i polityki rejestracji są same w sobie upubliczniane.

To jest potężny model dla infrastruktury MPJ, ponieważ przekształca przejrzystość w audytowalną usługę wokół materiałów zaufania i polityki — nie wokół osobistych zdarzeń podróży.

SCITT jest również jasny co do granic przejrzystości:

• Zarejestrowane oświadczenie dowodzi jedynie, że wystawca je wyprodukował i zarejestrował — nie że oświadczenie jest na zawsze poprawne.
• Późniejsze podpisane oświadczenie może zastąpić wcześniejsze.
• Przejrzystość nie zapobiega nieuczciwym lub skompromitowanym wystawcom; sprawia, że ponoszą odpowiedzialność.

W kontekście tożsamości kierowcy to rozróżnienie ma ogromne znaczenie: dziennik przejrzystości jest dowodem i historią audytu, a nie autorytatywnym stanem prawnym prawa do jazdy danej osoby.

SCITT zauważa również, że usługa przejrzystości może chronić swoją sekwencję tylko do dopisywania za pomocą kombinacji zaufanego sprzętu, protokołów konsensusu i dowodów kryptograficznych. Nawet warstwa przejrzystości nie wymaga jednego konkretnego projektu blockchainowego. Konsensus jest jedną z opcji, nie jedyną.

Prawidłowe Oddzielenie Architektoniczne dla Przyszłego MPJ

Przyszłe MPJ powinno rozdzielić zagadnienia na cztery odrębne warstwy:

1. Autorytatywne rejestry dotyczące tego, kto może prowadzić pojazd (krajowe organy ds. prawa jazdy)
2. Rejestry zaufania dla kluczy wystawców i weryfikatorów
3. Infrastruktura statusu zapewniająca aktualność i unieważnianie
4. Opcjonalna warstwa przejrzystości do publicznego audytu polityk, kotwic zaufania, potwierdzeń i oświadczeń o zgodności

Po rozdzieleniu tych warstw pytanie o blockchain staje się znacznie bardziej precyzyjne. Nie brzmi już „czy przyszłe MPJ powinno być na blockchainie?”, lecz:

Która warstwa, jeśli w ogóle, rzeczywiście korzysta z publicznego audytu tylko do dopisywania?

Pięć Powodów, dla Których Tożsamość Kierowcy On-Chain Jest Złym Domyślnym Rozwiązaniem

1. Tworzy Trwałe Sygnały Śledzenia

Prace EUDI dotyczące prywatności wyjaśniają, że prezentacje atestacji mogą zawierać unikalne wartości, takie jak:

• Sole (salts)
• Wartości skrótów
• Identyfikatory unieważnienia
• Publiczne klucze wiążące urządzenie
• Podpisy
• Znaczniki czasu

Ponieważ te wartości są stałe dla tej samej atestacji, pozwalają stronom ufającym łączyć różne transakcje i budować profil behawioralny użytkownika. EUDI wyraźnie ostrzega, że narusza to uzasadnione oczekiwanie, iż oddzielne działania portfela nie zostaną połączone.

Jeśli publikujesz stabilne identyfikatory posiadaczy, stabilne identyfikatory poświadczeń, wielokrotnie używane skróty lub indywidualnie identyfikowalne zdarzenia unieważnienia w publicznym rejestrze, nie rozwiązujesz problemu śledzenia — utrwalasz go na zawsze.

2. Ujawnia Zdarzenia Unieważnienia i Aktualności

Rekomendacja W3C Bitstring Status List jasno opisuje ten problem: jeśli istnieje odwzorowanie jeden do jednego między poświadczeniem a adresem URL, pod którym jego status jest publikowany, wydawca może powiązać posiadacza, weryfikatora i czas sprawdzenia. Specyfikacja używa przykładu prawa jazdy, aby zilustrować, dlaczego bycie śledzonym przez wystawcę przy wejściu do lokalu narusza powszechne oczekiwanie dotyczące prywatności.

Lepsze domyślne rozwiązanie, które proponuje Bitstring Status List:

• Duże, kompresowalne listy statusów, w których wiele poświadczeń współdzieli jeden zasób statusu
• Domyślna długość listy wynosząca 131 072 wpisy
• Strony ufające pobierające nowe wersje oddzielnie, bez uwierzytelniania się
• Losowe indeksy i gwarancje prywatności grupowej

To jest przeciwieństwo zindywidualizowanych, on-chainowych śladów unieważnienia.

3. Myli Status Poświadczenia ze Statusem Prawnym Kierowcy

Cyfrowe poświadczenie może zostać unieważnione, ponieważ jego mechanizm podpisywania został skompromitowany — nawet gdy rzeczywiste prawo do jazdy pozostaje ważne. Publiczny rejestr zdarzeń poświadczeń nie jest czystym substytutem autorytatywnego stanu krajowego rejestru prawa jazdy.

SCITT wzmacnia ten punkt: zarejestrowane oświadczenie może później zostać zastąpione nowym, a strony ufające decydują, czemu ufać, na podstawie polityki i historii. Dziennik nie jest stałą prawdą. Jest dowodem na to, kto co powiedział, kiedy i w ramach jakiej polityki. Krajowy organ ds. prawa jazdy pozostaje korzeniem prawnej prawdy.

4. Celuje w Niewłaściwy Problem Zarządzania

Transgraniczna tożsamość kierowcy nie jest przede wszystkim problemem konsensusu. To problem zarządzania:

• Kto może wydawać?
• Które klucze publiczne są aktualne?
• Którzy weryfikatorzy są autoryzowani?
• Które żądania danych odpowiadają zadeklarowanemu celowi?
• Która wersja polityki obowiązywała w danym czasie?

Rzeczywiste ekosystemy już odpowiadają na te pytania poprzez zarządzaną infrastrukturę zaufania, a nie zdecentralizowany konsensus:

• Usługa Digital Trust Service stowarzyszenia AAMVA publikuje publiczne klucze organów wydających w postaci listy do pobrania.
• Podręcznik mobilnego prawa jazdy UE stanowi, że Komisja Europejska publikuje listę autoryzowanych wystawców mDL.
• Prace ETSI dotyczące certyfikatów stron ufających portfela zapewniają maszynowo czytelne uwierzytelnianie weryfikatorów z zamierzonym zastosowaniem i zarejestrowanymi żądanymi atrybutami.

To jest jawna publiczna administracja zaufania — nie zdecentralizowane zarządzanie.

5. Nie Rozwiązuje Rzeczywistości Przydrożnej

Wiele propozycji blockchainowych po cichu zakłada, że dostęp do sieci na żywo jest zaletą. W przypadku poświadczeń kierowcy — szczególnie przy drodze lub podczas podróży — często tak nie jest.

Wytyczne implementacyjne AAMVA określają, że:

• Pobieranie z urządzenia działa bez zewnętrznej łączności zarówno dla posiadacza, jak i czytnika w czasie transakcji.
• ISO/IEC 18013-5 wymaga obsługi pobierania z urządzenia.
• Dostęp weryfikatora do publicznych kluczy wystawcy nie musi następować w czasie transakcji. Klucze mogą być pobierane z wyprzedzeniem.

Jeśli weryfikator może już walidować lokalnie przy użyciu zapisanych w pamięci podręcznej materiałów zaufania, żywa zależność od blockchainu nie jest niezbędna. W najlepszym razie jest to wybór implementacyjny dla niektórych funkcji audytu backendowego.

Co Powinno Być Przejrzyste w Przyszłym MPJ

Przyszłe MPJ absolutnie potrzebuje przejrzystości — we właściwym miejscu.

Domyślnie upublicznij następujące elementy:

• Publiczne klucze wystawców i zdarzenia rotacji kluczy
• Kotwice zaufania i listy autoryzowanych wystawców
• Certyfikaty dostępu weryfikatorów i metadane zarejestrowanego celu
• Wersje polityk i zasady rejestracji
• Oświadczenia o zgodności i twierdzenia dotyczące wydań oprogramowania istotnych dla bezpieczeństwa
• Audytowalne potwierdzenia dowodzące, że te oświadczenia zostały zarejestrowane

Domyślnie nie upubliczniaj następujących elementów:

• Identyfikatory posiadaczy w publicznym rejestrze
• Stabilne identyfikatory poświadczeń wielokrotnie używane w różnych weryfikatorach
• Zdarzenia per prezentacja
• Surowe wpisy unieważnienia izolujące jedną osobę
• Pełne podpisane oświadczenia zawierające dane osobowe, gdy wystarczyłyby skróty lub metadane

SCITT wyraźnie ostrzega wystawców, aby przed przesłaniem oświadczeń do usługi przejrzystości przejrzeli włączenie prywatnych, poufnych lub danych umożliwiających identyfikację osób. Zauważa również, że usługi przejrzystości mogą przechowywać jedynie kryptograficzne metadane, takie jak skróty — a nie kompletne podpisane oświadczenia.

Lepszy Wzorzec: Przejrzystość Wokół Ekosystemu, Nie Przez Osobę

Czysta architektura przyszłego MPJ wygląda następująco:

• Autorytatywny rejestr krajowy — pozostaje prawnym źródłem prawdy o prawie do prowadzenia pojazdów.
• Warstwa poświadczeń — przenosi maszynowo weryfikowalne uprawnienia do prowadzenia pojazdów do portfela posiadacza.
• Warstwa rejestru zaufania — dystrybuuje klucze wystawców, certyfikaty weryfikatorów i listy autoryzowanych wystawców.
• Warstwa statusu — używa krótkotrwałych atestacji lub list statusów chroniących prywatność, odświeżanych oddzielnie.
• Warstwa przejrzystości — może, ale nie musi, wewnętrznie używać konsensusu, i rejestruje kotwice zaufania, zmiany kluczy, aktualizacje polityk, potwierdzenia i oświadczenia ekosystemowe korzystające z publicznego audytu tylko do dopisywania.

Ta architektura przejmuje użyteczne elementy myślenia blockchainowego — audytowalność tylko do dopisywania, publiczna kontrola, odporność na manipulacje, potwierdzenia — bez uczynienia kierowcy publicznym podmiotem systemu. Odpowiada również temu, co już opisują standardy: rejestry mogą przybierać różne formy, DID nie wymagają rozproszonych rejestrów, rejestry zaufania już istnieją, a mechanizmy statusu chroniące prywatność są już zestandaryzowane.

Główny Argument

Przyszłe MPJ powinno przyjąć najlepszy pomysł z blockchainu — publiczna rozliczalność infrastruktury — bez przyjmowania jego najgorszego domyślnego rozwiązania dla ludzi: trwałego, globalnie widocznego śledzenia.

W praktyce oznacza to:

• Przejrzystość dla wystawców, nie ujawnianie posiadaczy
• Audytowalne kotwice zaufania, nie publiczne rejestry podróży
• Potwierdzenia dla polityk i rejestracji, nie trwałe harmonogramy użycia poświadczeń
• Dowody tylko do dopisywania dla zarządzania ekosystemem, nie tożsamość kierowcy on-chain jako domyślne rozwiązanie

To nie jest argument przeciwko blockchainowi. To argument przeciwko stosowaniu blockchainu do niewłaściwej warstwy.

Przyszłe MPJ może z powodzeniem używać usług przejrzystości opartych na konsensusie gdzieś w ekosystemie. Jednak jeśli projekt zaczyna od umieszczania kierowcy, poświadczenia lub śladu prezentacji w rejestrze, to już z założenia wybrał złe domyślne rozwiązanie.