Будущее международное водительское удостоверение (МВУ) нуждается в прозрачности, якорях доверия и публичной подотчётности. Однако по умолчанию оно вовсе не требует размещения данных самих водителей в распределённом реестре.
Любое серьёзное обсуждение цифрового трансграничного МВУ неизменно привлекает одно и то же предложение: «Просто вынесите это в блокчейн.» Привлекательность понятна. Блокчейн обеспечивает защиту от фальсификаций, совместную видимость и историю только для добавления записей. Это реальные свойства. Но в контексте трансграничной идентификации водителей они очень часто применяются не к тому уровню.
В этой статье объясняется почему, рассматривается то, что на самом деле говорят стандарты, и предлагается более правильный архитектурный паттерн.
Что стандарты на самом деле говорят о блокчейне
Модель данных верифицируемых учётных данных W3C прямо указывает, что реестр верифицируемых данных может принимать множество форм, включая:
- Доверенные базы данных
- Децентрализованные базы данных
- Государственные базы данных идентификации
- Распределённые реестры
Спецификация DID Core столь же однозначна: многие методы DID используют технологию распределённого реестра, но не все. Иными словами, стандарты уже отвергают идею о том, что блокчейн является обязательной основой для цифровых учётных данных.
Это правильная отправная точка для будущего МВУ. Полезный вопрос звучит не как «блокчейн или нет?», а иначе:
Какому уровню действительно необходима прозрачность, а какой уровень по умолчанию категорически не должен становиться публичной инфраструктурой?
Блокчейн — это набор свойств, а не требование
Первая ошибка — рассматривать «блокчейн» как единое требование. Это не так. Это совокупность возможных свойств, включая:
- Общедоступная публикация
- История только для добавления записей
- Распределённая работа
- Генерация квитанций
- Устойчивость к односторонним изменениям
Некоторые из них полезны для будущего МВУ. Некоторые не имеют значения. А некоторые откровенно опасны при применении к людям — субъектам учётных данных. Реестровая модель W3C намеренно допускает несколько реализаций, поскольку различные экосистемы требуют разных компромиссов.
Три проблемы, которые не следует объединять
Вторая ошибка — сведение трёх различных проблем в одну систему. Для будущего МВУ их необходимо разделять:
- Где хранится юридическая истина. Право на управление транспортным средством должно находиться в авторитетных национальных записях о водительских правах.
- Как распространяется материал доверия. Ключи эмитентов и сертификаты верификаторов должны находиться в контролируемых реестрах доверия.
- Как экосистема проверяет изменения. Это должно находиться на уровне прозрачности.
Реальные экосистемы уже работают именно так. Служба цифрового доверия AAMVA распространяет открытые ключи эмитентов в виде загружаемого списка ещё до того, как верификатор взаимодействует с мобильным водительским удостоверением (mDL). Руководство ЕС по мобильным водительским удостоверениям предписывает государствам — членам ЕС уведомлять Европейскую комиссию об авторизованных эмитентах mDL, а Комиссия публикует список верификации этих органов. Это распространение доверия без блокчейна.
Чему нас учит прозрачность сертификатов
Наиболее эффективная модель прозрачности в публичном интернете — не потребительский блокчейн. Это Certificate Transparency (CT) — прозрачность сертификатов.
RFC 9162 описывает CT как протокол публичного журналирования TLS-сертификатов серверов, позволяющий любому желающему:
- Проверять деятельность удостоверяющих центров
- Обнаруживать проблемные или ошибочно выданные сертификаты
- Проводить аудит самих журналов
Ключевой урок по проектированию из CT: прозрачность наиболее ценна, когда фиксирует поведение эмитентов и материал доверия, а не активность конечных пользователей.
Применительно к будущему МВУ это означает журналирование таких событий, как:
- Выпуск и ротация ключей эмитентов
- Публикация якорей доверия
- Регистрация категорий верификаторов
- Изменения политик
- Заявления о соответствии требованиям
- События, значимые с точки зрения безопасности
Это не означает создание публичного или полупубличного реестра держателей, идентификаторов учётных данных или событий предъявления. Это не прозрачность. Это избыточный сбор данных.
SCITT: почему прозрачность — это не то же самое, что истина
Архитектурный проект IETF SCITT развивает эту идею. SCITT определяет службу прозрачности, которая поддерживает верифицируемую структуру данных и выдаёт криптографические квитанции, подтверждающие включение подписанных утверждений. Идентичность службы прозрачности закреплена открытым ключом, известным доверяющим сторонам, а якоря доверия и политики регистрации сами по себе делаются прозрачными.
Это мощная модель для инфраструктуры МВУ, поскольку превращает прозрачность в проверяемый сервис вокруг материала доверия и политики — но не вокруг личных событий в поездках.
SCITT также чётко обозначает пределы прозрачности:
- Зарегистрированное утверждение лишь доказывает, что эмитент его создал и зарегистрировал — но не то, что оно верно бессрочно.
- Более позднее подписанное утверждение может заменить более раннее.
- Прозрачность не предотвращает действия нечестных или скомпрометированных эмитентов — она привлекает их к ответственности.
Для идентификации водителей это различие чрезвычайно важно: журнал прозрачности — это доказательства и история аудита, а не авторитетное юридическое состояние права конкретного человека на управление автомобилем.
SCITT также отмечает, что служба прозрачности может защищать свою последовательность только для добавления записей с помощью комбинации доверенного аппаратного обеспечения, протоколов консенсуса и криптографических доказательств. Даже уровень прозрачности не требует какого-то одного конкретного дизайна блокчейна. Консенсус — это один из вариантов, а не единственный.
Правильное архитектурное разделение для будущего МВУ
Будущее МВУ должно разделять задачи на четыре отдельных уровня:
- Авторитетные записи о праве на управление транспортным средством (национальные органы по выдаче водительских прав)
- Реестры доверия для ключей эмитентов и верификаторов
- Инфраструктура статусов для актуальности и отзыва
- Необязательный уровень прозрачности для публичного аудита политик, якорей доверия, квитанций и заявлений о соответствии требованиям
После разделения этих уровней вопрос о блокчейне становится гораздо более конкретным. Он звучит уже не как «должно ли будущее МВУ быть на блокчейне?», а так:
Какой уровень, если вообще какой-либо, действительно выигрывает от публичного аудита с историей только для добавления записей?
Пять причин, по которым идентификация водителя на блокчейне — неверный выбор по умолчанию
1. Создаются устойчивые сигналы отслеживания
Документация по конфиденциальности EUDI объясняет, что презентации аттестаций могут содержать уникальные значения, такие как:
- Соли
- Хеш-значения
- Идентификаторы отзыва
- Открытые ключи привязки к устройству
- Подписи
- Временны́е метки
Поскольку эти значения неизменны для одной и той же аттестации, они позволяют доверяющим сторонам связывать различные транзакции и формировать поведенческий профиль пользователя. EUDI прямо предупреждает, что это нарушает разумное ожидание того, что отдельные действия в кошельке не будут объединяться.
Если вы публикуете стабильные идентификаторы держателей, стабильные идентификаторы учётных данных, повторно используемые хеши или индивидуально отслеживаемые события отзыва в публичном реестре, вы не решаете проблему отслеживания — вы делаете её постоянной.
2. Раскрываются события отзыва и обновления статуса
Рекомендация W3C по Bitstring Status List чётко описывает проблему: если существует взаимно однозначное соответствие между учётной записью и URL-адресом, по которому публикуется её статус, издатель может связать держателя, верификатора и время проверки. Спецификация использует пример водительского удостоверения, чтобы пояснить, почему отслеживание эмитентом факта входа в заведение нарушает общепринятые ожидания конфиденциальности.
Лучший вариант по умолчанию, предлагаемый Bitstring Status List:
- Большие сжимаемые списки статусов, в которых многие учётные данные используют один ресурс статуса
- Длина списка по умолчанию — 131 072 записи
- Доверяющие стороны загружают новые версии отдельно, не аутентифицируя себя
- Рандомизированные индексы и групповые гарантии конфиденциальности
Это полная противоположность индивидуализированным записям об отзыве на блокчейне.
3. Смешиваются статус учётных данных и юридический статус водителя
Цифровая учётная запись может быть отозвана из-за компрометации механизма подписи — даже при сохранении реального права на управление автомобилем. Публичный реестр событий, связанных с учётными данными, не является чистым аналогом авторитетного состояния национальной записи о водителе.
SCITT подкрепляет этот тезис: зарегистрированное утверждение может быть впоследствии заменено новым, а доверяющие стороны принимают решение о доверии на основе политики и истории. Журнал — это не постоянная истина. Это доказательства того, кто, что, когда и в соответствии с какой политикой заявил. Национальный орган по выдаче водительских прав остаётся корнем юридической истины.
4. Решается не та задача управления
Трансграничная идентификация водителей — это в первую очередь не проблема консенсуса. Это проблема управления:
- Кому разрешено выпускать документы?
- Какие открытые ключи актуальны?
- Какие верификаторы авторизованы?
- Какие запросы данных соответствуют заявленной цели?
- Какая версия политики действовала в данный момент?
Реальные экосистемы уже решают эти вопросы через управляемую доверенную инфраструктуру, а не через децентрализованный консенсус:
- Служба цифрового доверия AAMVA публикует открытые ключи выдающих органов в виде загружаемого списка.
- Руководство ЕС по мобильным водительским удостоверениям указывает, что Европейская комиссия публикует список авторизованных эмитентов mDL.
- Работа ETSI по сертификатам доверяющих сторон кошельков обеспечивает машиночитаемую аутентификацию верификаторов с указанием предполагаемого использования и зарегистрированных запрашиваемых атрибутов.
Это явное публичное администрирование доверия, а не децентрализованное управление.
5. Это не решает реальные задачи на дороге
Многие предложения по блокчейну негласно исходят из того, что постоянный сетевой доступ — это преимущество. Для документов водителя — особенно при проверке на дороге или в поездках — это зачастую не так.
Руководство по реализации AAMVA устанавливает следующее:
- Получение данных с устройства работает без внешнего подключения как для держателя, так и для считывателя в момент транзакции.
- ISO/IEC 18013-5 требует поддержки получения данных с устройства.
- Доступ верификатора к открытым ключам эмитента не обязан осуществляться в момент транзакции. Ключи могут быть загружены заранее.
Если верификатор уже может проводить локальную проверку, используя кешированный материал доверия, зависимость от блокчейна в реальном времени не является обязательной. В лучшем случае это выбор реализации для некоторой серверной функции аудита.
Что должно быть прозрачным в будущем МВУ
Будущему МВУ абсолютно необходима прозрачность — но в правильном месте.
Сделайте следующее прозрачным по умолчанию:
- Открытые ключи эмитентов и события ротации ключей
- Якоря доверия и списки авторизованных эмитентов
- Сертификаты доступа верификаторов и метаданные зарегистрированных целей
- Версии политик и правила регистрации
- Заявления о соответствии требованиям и сведения о выпусках программного обеспечения, значимые с точки зрения безопасности
- Проверяемые квитанции, подтверждающие регистрацию этих утверждений
Не делайте следующее публичным по умолчанию:
- Идентификаторы держателей в публичном реестре
- Стабильные идентификаторы учётных данных, повторно используемые у разных верификаторов
- События отдельных предъявлений
- Необработанные записи об отзыве, идентифицирующие одного человека
- Полные подписанные утверждения, содержащие персональные данные, когда достаточно хешей или метаданных
SCITT прямо предупреждает эмитентов о необходимости проверять наличие частной, конфиденциальной или персонально идентифицируемой информации перед отправкой утверждений в службу прозрачности. Также отмечается, что службы прозрачности могут хранить только криптографические метаданные — такие как хеши — а не полные подписанные утверждения.
Лучший паттерн: прозрачность вокруг экосистемы, а не через личность человека
Чистая архитектура для будущего МВУ выглядит следующим образом:
- Авторитетный национальный реестр — остаётся юридическим источником истины о праве на управление транспортным средством.
- Уровень учётных данных — доставляет машиночитаемые права на управление автомобилем в кошелёк держателя.
- Уровень реестра доверия — распространяет ключи эмитентов, сертификаты верификаторов и списки авторизованных эмитентов.
- Уровень статусов — использует краткосрочные аттестации или списки статусов с защитой конфиденциальности, обновляемые отдельно.
- Уровень прозрачности — может использовать или не использовать консенсус внутри, и журналирует якоря доверия, изменения ключей, обновления политик, квитанции и экосистемные утверждения, которые выигрывают от публичного аудита с историей только для добавления записей.
Эта архитектура сохраняет полезные аспекты идей блокчейна — проверяемость только для добавления записей, публичный контроль, защиту от фальсификаций, квитанции — не превращая водителя в публичный объект системы. Она также соответствует тому, что уже описывают стандарты: реестры могут иметь различные формы, DID не требуют распределённых реестров, реестры доверия уже существуют, а механизмы статусов с защитой конфиденциальности уже стандартизированы.
Основной тезис
Будущее МВУ должно принять лучшую идею блокчейна — публичную подотчётность инфраструктуры — не принимая при этом худшего варианта по умолчанию для людей: устойчивого, глобально видимого отслеживания.
На практике это означает:
- Прозрачность для эмитентов, а не раскрытие информации о держателях
- Проверяемые якоря доверия, а не публичные записи о поездках
- Квитанции для политик и регистраций, а не постоянные хронологии использования учётных данных
- Доказательства только для добавления записей для управления экосистемой, а не идентификация водителя на блокчейне по умолчанию
Это не аргумент против блокчейна. Это аргумент против применения блокчейна не к тому уровню.
Будущее МВУ вполне может использовать службы прозрачности на основе консенсуса где-то в экосистеме. Но если проектирование начинается с размещения водителя, учётной записи или следа предъявлений в реестре, значит, уже выбран неверный вариант по умолчанию.
Опубликовано Май 18, 2026 • 11м на чтение
