Майбутній Міжнародний водійський дозвіл (МВД) потребує прозорості, якорів довіри та публічної підзвітності. Те, чого він не потребує за замовчуванням — це розміщення самих водіїв у розподіленому реєстрі.
Кожна серйозна розмова про цифровий транскордонний МВД врешті-решт призводить до однієї й тієї самої пропозиції: «Просто помістіть це в блокчейн». Привабливість зрозуміла. Блокчейни пропонують захист від фальсифікацій, спільну видимість та незмінну журнальну історію. Це реальні властивості. Але в контексті транскордонної ідентичності водія вони дуже часто застосовуються до неправильного рівня.
Ця стаття пояснює чому, розглядає, що насправді говорять стандарти, та пропонує кращий архітектурний шаблон.
Що стандарти насправді говорять про блокчейн
Модель даних верифікованих облікових даних W3C прямо зазначає, що реєстр верифікованих даних може мати різні форми, зокрема:
- Довірені бази даних
- Децентралізовані бази даних
- Державні бази даних ідентичності
- Розподілені реєстри
DID Core настільки ж однозначний: багато методів DID використовують технологію розподіленого реєстру, але не всі. Іншими словами, стандарти вже відкидають ідею про те, що блокчейн є обов’язковою основою для цифрових облікових даних.
Це правильна відправна точка для майбутнього МВД. Корисне питання — не «блокчейн чи ні?» Воно полягає в наступному:
Який рівень насправді потребує прозорості, а який абсолютно не повинен ставати публічною інфраструктурою за замовчуванням?
Блокчейн — це набір властивостей, а не вимога
Перша помилка — розглядати «блокчейн» як єдину вимогу. Це не так. Це пакет можливих властивостей, зокрема:
- Спільна публікація
- Незмінна журнальна історія
- Розподілена робота
- Генерація квитанцій
- Стійкість до односторонніх змін
Деякі з них корисні для майбутнього МВД. Деякі — нерелевантні. А деякі є відверто небезпечними при застосуванні до суб’єктів облікових даних. Модель реєстру W3C навмисно допускає різні реалізації, оскільки різні екосистеми потребують різних компромісів.
Три проблеми, які не слід об’єднувати
Друга помилка — зведення трьох різних проблем до однієї системи. Для майбутнього МВД їх необхідно тримати окремо:
- Де зберігається юридична істина. Право на керування транспортним засобом належить до авторитетних національних записів водійських посвідчень.
- Як розподіляються матеріали довіри. Ключі видавців та сертифікати верифікаторів належать до контрольованих реєстрів довіри.
- Як екосистема перевіряє зміни. Це належить до рівня прозорості.
Реальні екосистеми вже працюють саме так. Сервіс цифрової довіри AAMVA розподіляє публічні ключі видавців у вигляді завантажуваного списку ще до того, як верифікатор взаємодіє з mDL. Посібник ЄС з мобільного водійського посвідчення зазначає, що Держави-члени повідомляють Комісію про авторизованих видавців mDL, а Комісія публікує перевірочний список цих органів. Це розподіл довіри без блокчейну.
Що вчить нас прозорість сертифікатів
Найефективніша модель прозорості в публічному інтернеті — це не споживчий блокчейн. Це Прозорість сертифікатів (CT).
RFC 9162 описує CT як протокол публічного журналювання TLS-сертифікатів серверів, що дозволяє будь-кому:
- Перевіряти діяльність центрів сертифікації
- Виявляти проблемні або неправильно видані сертифікати
- Перевіряти самі журнали
Ключовий урок дизайну від CT: прозорість найцінніша, коли вона фіксує поведінку видавців та матеріали довіри — а не активність кінцевих користувачів.
Стосовно майбутнього МВД це означає журналювання таких речей, як:
- Видача та ротація ключів видавців
- Публікація якорів довіри
- Реєстрація категорій верифікаторів
- Зміни політики
- Заяви про відповідність
- Події, що мають значення для безпеки
Це не означає створення публічного або напівпублічного реєстру власників, ідентифікаторів облікових даних або подій презентації. Це не прозорість. Це надмірний збір даних.
SCITT: чому прозорість — це не те саме, що істина
Чернетка архітектури IETF SCITT розвиває цю думку далі. SCITT визначає Сервіс прозорості, який підтримує верифіковану структуру даних та видає криптографічні квитанції, що підтверджують включення підписаних тверджень. Ідентичність Сервісу прозорості фіксується публічним ключем, відомим довіреним сторонам, а самі якорі довіри та політики реєстрації також стають прозорими.
Це потужна модель для інфраструктури МВД, оскільки вона перетворює прозорість на підзвітну службу навколо матеріалів довіри та політики — а не навколо особистих подій подорожей.
SCITT також чітко окреслює межі прозорості:
- Зареєстроване твердження лише доводить, що видавець його створив та зареєстрував — але не те, що твердження залишається правильним безстроково.
- Пізніше підписане твердження може замінити попереднє.
- Прозорість не запобігає нечесним або скомпрометованим видавцям; вона робить їх підзвітними.
Для ідентичності водія це розрізнення має величезне значення: журнал прозорості — це доказова база та журнал аудиту, а не авторитетний юридичний стан права на керування транспортним засобом.
SCITT також зазначає, що сервіс прозорості може захистити свою незмінну послідовність за допомогою комбінації довіреного апаратного забезпечення, протоколів консенсусу та криптографічних доказів. Навіть рівень прозорості не вимагає одного конкретного дизайну блокчейну. Консенсус — це один з варіантів, а не єдиний.
Правильне архітектурне розділення для майбутнього МВД
Майбутній МВД повинен розділити завдання на чотири окремі рівні:
- Авторитетні записи про тих, хто має право керувати транспортним засобом (національні органи ліцензування)
- Реєстри довіри для ключів видавців та верифікаторів
- Інфраструктура статусу для актуальності та відкликання
- Необов’язковий рівень прозорості для публічного аудиту політик, якорів довіри, квитанцій та заяв про відповідність
Після розділення цих рівнів питання блокчейну стає значно конкретнішим. Воно більше не звучить як «чи повинен майбутній МВД бути в блокчейні?» Воно стає:
Який рівень, якщо такий є, насправді виграє від незмінного публічного аудиту?
П’ять причин, чому on-chain ідентичність водія є хибним підходом за замовчуванням
1. Це створює тривалі сигнали відстеження
Матеріали EUDI щодо конфіденційності пояснюють, що презентації атестації можуть містити унікальні значення, зокрема:
- Солі
- Хеш-значення
- Ідентифікатори відкликання
- Публічні ключі прив’язки пристрою
- Підписи
- Мітки часу
Оскільки ці значення є фіксованими для однієї й тієї самої атестації, вони дозволяють довіреним сторонам пов’язувати різні транзакції та будувати поведінковий профіль користувача. EUDI прямо застерігає, що це порушує розумне очікування того, що окремі дії гаманця не будуть об’єднані.
Якщо ви публікуєте стабільні ідентифікатори власників, стабільні ідентифікатори облікових даних, повторно використовувані хеші або індивідуально відстежувані події відкликання у публічному реєстрі, ви не вирішуєте проблему відстеження — ви робите її постійною.
2. Це розкриває події відкликання та актуальності
Рекомендація W3C щодо списку статусів бітових рядків чітко описує проблему: якщо існує відображення «один до одного» між обліковими даними та URL-адресою публікації їхнього статусу, видавець може пов’язати власника, верифікатора та час перевірки. Специфікація використовує приклад водійського посвідчення, щоб пояснити, чому відстеження видавцем при вході до закладу порушує загальне очікування конфіденційності.
Кращий підхід за замовчуванням, запропонований списком статусів бітових рядків:
- Великі стисненні списки статусів, де багато облікових даних спільно використовують один ресурс статусу
- Типова довжина списку — 131 072 записи
- Довірені сторони завантажують нові версії окремо, без власної автентифікації
- Рандомізовані індекси та групові гарантії конфіденційності
Це повна протилежність індивідуалізованих on-chain слідів відкликання.
3. Це плутає статус облікових даних із юридичним статусом водіння
Цифровий обліковий запис може бути відкликаний через компрометацію його механізму підпису — навіть якщо реальне право на керування транспортним засобом залишається дійсним. Публічний реєстр подій облікових даних не є чистою заміною авторитетного стану національного запису водія.
SCITT підсилює цю думку: зареєстроване твердження може пізніше бути замінене новим, а довірені сторони вирішують, чому довіряти, виходячи з політики та історії. Журнал — це не постійна істина. Це докази про те, хто що сказав, коли та згідно з якою політикою. Національний орган ліцензування залишається коренем юридичної істини.
4. Це спрямоване на вирішення неправильної проблеми управління
Транскордонна ідентичність водія — це насамперед не проблема консенсусу. Це проблема управління:
- Хто має право видавати?
- Які публічні ключі є актуальними?
- Які верифікатори авторизовані?
- Які запити даних відповідають задекларованій меті?
- Яка версія політики діяла на той момент?
Реальні екосистеми вже вирішують ці питання через керовану інфраструктуру довіри, а не через децентралізований консенсус:
- Сервіс цифрової довіри AAMVA публікує публічні ключі видавничих органів у вигляді завантажуваного списку.
- Посібник ЄС з мобільного водійського посвідчення зазначає, що Комісія публікує список авторизованих видавців mDL.
- Робота ETSI з сертифікатами довіреної сторони гаманця забезпечує машиночитану автентифікацію верифікаторів із зазначенням призначення та зареєстрованих запитуваних атрибутів.
Це явне публічне управління довірою — а не децентралізоване управління.
5. Це не вирішує реалій дорожньої перевірки
Багато пропозицій щодо блокчейну мовчки припускають, що живий мережевий доступ є перевагою. Для водійських посвідчень — особливо при дорожній перевірці або під час подорожей — це часто не так.
Настанови щодо впровадження AAMVA вказують, що:
- Отримання даних із пристрою працює без зовнішнього підключення як для власника, так і для пристрою зчитування під час транзакції.
- ISO/IEC 18013-5 вимагає підтримки отримання даних із пристрою.
- Доступ верифікатора до публічних ключів видавця не потребує здійснення в момент транзакції. Ключі можна завантажити заздалегідь.
Якщо верифікатор вже може виконати локальну валідацію з використанням кешованих матеріалів довіри, залежність від живого блокчейну не є необхідною. У найкращому випадку це реалізаційний вибір для певної функції внутрішнього аудиту.
Що має бути прозорим у майбутньому МВД
Майбутній МВД абсолютно потребує прозорості — у правильному місці.
Зробіть це прозорим за замовчуванням:
- Публічні ключі видавців та події ротації ключів
- Якорі довіри та списки авторизованих видавців
- Сертифікати доступу верифікаторів та метадані зареєстрованих цілей
- Версії політик та правила реєстрації
- Заяви про відповідність та вимоги щодо безпечно значущих випусків програмного забезпечення
- Перевіряємі квитанції, що підтверджують реєстрацію цих тверджень
Не робіть це публічним за замовчуванням:
- Ідентифікатори власників у публічному реєстрі
- Стабільні ідентифікатори облікових даних, повторно використовувані у різних верифікаторів
- Події на рівні кожної презентації
- Сирі записи відкликання, що ідентифікують одну особу
- Повні підписані твердження, що містять персональні дані, якщо достатньо хешів або метаданих
SCITT прямо застерігає видавців перевіряти включення приватної, конфіденційної або особистоідентифікованої інформації перед поданням тверджень до сервісу прозорості. Він також зазначає, що сервіси прозорості можуть зберігати лише криптографічні метадані, такі як хеші, — а не повні підписані твердження.
Кращий шаблон: прозорість навколо екосистеми, а не через особу
Чиста архітектура для майбутнього МВД виглядає так:
- Авторитетний національний реєстр — залишається юридичним джерелом істини щодо права на керування транспортним засобом.
- Рівень облікових даних — доставляє машиноверифіковані права на керування транспортним засобом до гаманця власника.
- Рівень реєстру довіри — розподіляє ключі видавців, сертифікати верифікаторів та списки авторизованих видавців.
- Рівень статусу — використовує короткочасні атестації або списки статусів, що зберігають конфіденційність, та оновлюються окремо.
- Рівень прозорості — може або не може використовувати консенсус внутрішньо, та журналює якорі довіри, зміни ключів, оновлення політик, квитанції та заяви екосистеми, які виграють від незмінного публічного аудиту.
Ця архітектура захоплює корисні частини блокчейн-мислення — незмінна перевіряємість, публічний контроль, захист від фальсифікацій, квитанції — не перетворюючи водія на публічний суб’єкт системи. Вона також відповідає тому, що вже описують стандарти: реєстри можуть мати різні форми, DID не вимагають розподілених реєстрів, реєстри довіри вже існують, а механізми статусу, що зберігають конфіденційність, вже стандартизовані.
Основний аргумент
Майбутній МВД повинен перейняти найкращу ідею блокчейну — публічну підзвітність для інфраструктури — не переймаючи його найгірший підхід за замовчуванням щодо людей: тривале, глобально видиме відстеження.
На практиці це означає:
- Прозорість для видавців, а не розкриття власників
- Перевіряємі якорі довіри, а не публічні записи подорожей
- Квитанції для політик та реєстрацій, а не постійні хронології використання облікових даних
- Незмінні докази для управління екосистемою, а не on-chain ідентичність водія за замовчуванням
Це не аргумент проти блокчейну. Це аргумент проти застосування блокчейну до неправильного рівня.
Майбутній МВД цілком може використовувати сервіси прозорості на основі консенсусу десь в екосистемі. Але якщо дизайн починається з розміщення водія, облікового запису або сліду презентації в реєстрі, він вже обрав хибний підхід за замовчуванням.
Опубліковано Травень 19, 2026 • 10хв на читання
