Стек, що стоїть за майбутнім МВП: чому для заміни паперового дозволу потрібна багаторівнева архітектура стандартів

Жоден окремий стандарт не замінить паперовий Міжнародний водійський дозвіл (МВП). Справжній наступник — це стек стандартів, що працюють разом, і розуміння цього стеку є ключем до розуміння того, куди насправді рухаються цифрові водійські посвідчення для перетину кордонів.

Чому жоден окремий стандарт не замінить паперовий МВП

Більшість дискусій про майбутній МВП починаються з неправильного запитання: який стандарт замінить паперовий дозвіл? Таке формулювання передбачає, що одна специфікація може виконати всю роботу. Це не так.

Дослідження mDL (мобільного водійського посвідчення) NIST прямо зазначає, що нові стандарти цифрових облікових даних розробляються в окремих проблемних сферах. Сама родина ISO 18013 вже поділена на кілька частин, що охоплюють фізичний дизайн, безпеку, мобільне пред’явлення та інтернет-розширення. Майбутнє водійське посвідчення для перетину кордонів — це тому не одна специфікація, а скоординований стек специфікацій, кожна з яких вирішує окрему задачу.

Стек майбутнього МВП — короткий огляд

Ось вісім рівнів, які разом визначають, як виглядатиме майбутній МВП:

Рівень 0 — Фізична та інформаційна основа: ISO/IEC 18013-1
Рівень 1 — Безпека облікових даних: ISO/IEC 18013-3
Рівень 2 — Пред’явлення в безпосередній близькості (особисто): ISO/IEC 18013-5
Рівень 3 — Дистанційне / інтернет-пред’явлення: ISO/IEC 18013-7
Рівень 4 — Семантика облікових даних: W3C Verifiable Credentials Data Model 2.0
Рівень 5 — Протокол видачі: OpenID4VCI
Рівень 6 — Протокол запиту та пред’явлення: OpenID4VP
Рівень 7 — Розповсюдження довіри та авторизація верифікаторів: Реєстри довіри (модель VICAL від AAMVA, модель довірених сторін на основі сертифікатів EUDI)

Кожен рівень ґрунтується на чинних стандартах або активній документації екосистеми. Наведені нижче розділи пояснюють, що робить кожен рівень — і, не менш важливо, чого він не робить.

Рівень 0 — ISO/IEC 18013-1: фізична та семантична основа

Частина 1 має більше значення, ніж більшість людей усвідомлює, адже вона стосується не лише дизайну картки.

ISO/IEC 18013-1 визначає фізичні характеристики та базовий набір даних водійського посвідчення, що відповідає ISO, створюючи спільну основу для міжнародного використання та взаємного визнання. Вона побудована навколо захищеної картки формату ID-1 у поєднанні з буклетом для міжнародного використання, замінюючи стару паперову модель МВП. ISO також зазначає, що в багатьох випадках одна картка може замінити потребу у двох окремих документах.

Практичний висновок простий: майбутній МВП не може починатися з рівня гаманця. Якщо спочатку не стандартизовано базову структуру документа, модель даних і компонування, кожен цифровий рівень вище стає латкою сумісності поверх роздрібнених національних форматів. Частина 1 — це фундамент, від якого залежить решта стеку.

Рівень 1 — ISO/IEC 18013-3: безпека облікових даних

Частина 3 — це місце, де облікові дані переходять від статусу даних на документі до статусу об’єкта безпеки. ISO описує 18013-3 як частину, що визначає механізми для:

Контролю доступу до машиночитаних даних
Автентифікації документа
Перевірки цілісності

Проте ISO прямо зазначає, що Частина 3 не вирішує питання конфіденційності, пов’язані з подальшим використанням даних, — і ця межа є важливою.

Коротко кажучи, 18013-3 забезпечує безпеку облікових даних, а не повне управління екосистемою. Вона допомагає відповісти на такі запитання: Чи були ці облікові дані видані заявленим органом? Чи були дані змінені? Вона не дає повної відповіді на: Чи взагалі має право цей верифікатор запитувати це поле? Чи дозволений цей запит у даному контексті?

Це також активний рівень, а не завершений продукт. ISO включає поправку 2022 року щодо протоколу PACE, поправку 2023 року щодо оновлень пасивної автентифікації та новий проект 18013-3, що наразі перебуває в розробці.

Рівень 2 — ISO/IEC 18013-5: мобільне пред’явлення особисто

Якщо Частина 1 визначає документ, а Частина 3 захищає його, Частина 5 перетворює посвідчення на мобільний обліковий запис.

ISO зазначає, що 18013-5 охоплює інтерфейс між mDL і зчитувачем, а також між зчитувачем та інфраструктурою органу-емітента. Вона також надає третім сторонам — включаючи органи влади та верифікаторів в інших країнах — можливість:

Отримувати дані mDL машиною
Пов’язувати ці дані з власником
Автентифікувати їх походження
Перевіряти їх цілісність

Не менш важливо те, що не охоплює 18013-5. ISO прямо перераховує питання поза сферою дії стандарту, зокрема: як отримується згода власника на передачу даних та вимоги до зберігання даних mDL і приватних ключів. Частина 5 — це не повний продукт гаманця, не повна модель згоди користувача і не повна система управління. Це рівень транспортування та верифікації для мобільного пред’явлення.

Настанови AAMVA щодо впровадження уточнюють це, розрізняючи дві моделі отримання даних:

Отримання з пристрою, де дані зчитуються безпосередньо з пристрою власника.
Отримання з сервера, що може дозволити органу-емітенту спостерігати за тим, коли використовується mDL, які дані передаються, і навіть оцінювати фізичне місцезнаходження через аналіз IP-адрес.

Другий пункт — це не привід відхиляти стандарт, а привід точно визначити, яку модель отримання даних майбутній МВП має використовувати за замовчуванням. AAMVA також вимагає, щоб гаманець надавав власнику повний контроль над тим, які елементи даних передаються, що значно краще відповідає майбутньому МВП, ніж стара модель «показати весь документ».

Рівень 3 — ISO/IEC 18013-7: інтернет-пред’явлення

Частина 5 вирішує проблему особистого пред’явлення. Частина 7 розширює цю модель на дистанційне використання.

ISO описує 18013-7:2025 як розширення 18013-5 для інтернет-пред’явлення mDL зчитувачу. Інтернет — це не другорядна деталь цієї архітектури; він є явною частиною стандарту.

Посібник ЄС з мобільного водійського посвідчення вже розглядає інтернет-пред’явлення як практичне, а не теоретичне, описуючи такі сценарії:

Реєстрація при оренді автомобіля, де користувачі надають своє mDL особисто або дистанційно заздалегідь
Перевірки на узбіччі дороги поліцією
Загальний профіль використання mDL, побудований на ISO/IEC 18013-5 та 18013-7

При цьому поточні настанови AAMVA чесно визнають обмеження: використання mDL через інтернет є вкрай бажаним, але деякі допоміжні стандарти ще дозрівають. Існують реальні прогалини в поточній інтеграції гаманця з браузером, і без переліку довірених зчитувачів сторона mdoc може не мати надійного способу підтвердити певні властивості безпеки. Дистанційне пред’явлення — це реальність, яка ще розвивається.

Навіть з урахуванням цих застережень, 18013-7 є першою серйозною відповіддю на проблему, яку паперовий МВП навіть не намагався вирішити: дистанційне пред’явлення прав на керування транспортним засобом до того, як особа дістанеться стійки або контрольно-пропускного пункту.

Рівень 4 — W3C VC Data Model 2.0: семантичний рівень

Модель даних верифікованих облікових даних W3C 2.0 — це не стандарт водійського посвідчення, і саме тому вона важлива.

Рекомендація визначає розширювану модель даних для верифікованих облікових даних, пояснює, як їх можна захистити від змін, і описує екосистему в термінах трьох основних ролей: емітентів, власників та верифікаторів. Водійське посвідчення наводиться як один із основних прикладів.

Для майбутнього МВП VC 2.0 надає загальний словник для тверджень, презентацій та верифікованих реєстрів даних. W3C прямо зазначає, що такі реєстри можуть мати кілька форм, зокрема:

Довірені бази даних
Державні бази ідентифікаційних даних
Децентралізовані бази даних
Розподілені реєстри

Це руйнує хибну дихотомію між підходом виключно на основі блокчейну і повністю власницьким. Модель даних ширша за обидва варіанти.

VC 2.0 також чітко говорить про вибіркове розкриття даних. W3C зазначає, що водійське посвідчення може містити більше даних, ніж потрібно для конкретного випадку використання, і рекомендує або розбивати інформацію на менші частини, або використовувати механізми вибіркового розкриття. Для майбутнього МВП це не необов’язкова конфіденційна деталь — це різниця між сучасним обліковим записом і цифровою ксерокопією пластикової картки.

Однак VC 2.0 не є повноцінною заміною ISO 18013. W3C вказує, що модель даних не вимагає традиційної моделі ланцюга довіри на основі центру сертифікації. На практиці VC 2.0 є потужним семантичним рівнем, але поверх нього все одно потрібні явні рівні розповсюдження довіри та управління верифікаторами.

Рівень 5 — OpenID4VCI: протокол видачі

Майбутньому МВП потрібен стандартний спосіб передачі облікових даних від емітента до гаманця. Це роль OpenID для видачі верифікованих облікових даних (OpenID4VCI) 1.0.

Специфікація визначає захищений OAuth API для видачі верифікованих облікових даних і навмисно не прив’язана до жодного формату. Серед підтримуваних форматів облікових даних:

ISO mdoc
SD-JWT VC
W3C VCDM credentials

Вона також підтримує прив’язку власника та подальші пред’явлення без додаткової участі емітента. OpenID4VCI 1.0 було затверджено як Остаточну специфікацію у вересні 2025 року.

Це робить OpenID4VCI стратегічно важливим для майбутньої екосистеми МВП. Замість побудови власних конвеєрів від емітента до гаманця для кожної юрисдикції або провайдера гаманця, екосистема може визначити керований профіль видачі поверх стандартного фреймворку видачі — при цьому зберігаючи вибір між кодуванням результуючого облікового запису як mdoc, VC або іншого підтримуваного формату. Ця гнучкість є одним із найвагоміших аргументів на користь модульного стеку майбутнього МВП.

Рівень 6 — OpenID4VP: протокол запиту та пред’явлення

Якщо OpenID4VCI переміщує облікові дані до гаманця, OpenID для верифікованих презентацій (OpenID4VP) повертає їх назад у контрольований спосіб.

Специфікація визначає механізм запиту та пред’явлення облікових даних. Її базовий варіант використовує HTTPS-повідомлення та перенаправлення, але також підтримує використання через W3C Digital Credentials API замість потоків перенаправлення. OpenID4VP 1.0 досяг статусу Остаточної специфікації у липні 2025 року.

Це важливо, оскільки надає стеку майбутнього МВП вебнативний рівень пред’явлення, який веб-сайти, застосунки та онлайн-верифікатори можуть впроваджувати безпосередньо. Кілька нещодавніх подій підтверджують це:

У серпні 2025 року OpenID Foundation оголосив про офіційний аналіз безпеки OpenID4VP, що використовується через Digital Credentials API, — нових вразливостей у перевіреній моделі протоколу виявлено не було.
Поточний проект mDL від NIST будує свою модель загроз навколо запиту та пред’явлення mDL через OpenID4VP поверх W3C Digital Credentials API, з використанням FIDO CTAP для забезпечення близькості та захисту від фішингу у відповідних потоках.

Вебсторона стеку і сторона mDL зближуються. OpenID4VP не слід сприймати як конкурента ISO 18013-7 — це вебпротокольний рівень, який робить інтернет-пред’явлення практичним у реальних середовищах браузерів, гаманців і верифікаторів.

Рівень 7 — Реєстри довіри: де стек стає екосистемою

Цей рівень багато обговорень пропускають — і саме він визначає, чи працює вся система насправді.

Верифікатор не може зробити багато з підписаним обліковим записом, якщо не знає трьох речей:

Які емітенти є легітимними
Які відкриті ключі є актуальними
Чи авторизована сама запитувальна сторона

З боку емітента, Служба цифрової довіри AAMVA пропонує конкретну відповідь. Вона надає єдиний, безпечний і надійний спосіб для довірених сторін отримувати відкриті ключі органів-емітентів, що розповсюджуються через Список сертифікатів верифікованих емітентів (VICAL). Настанови AAMVA описують роль провайдера VICAL у практичних термінах: збирати відкриті ключі від легітимних органів-емітентів, перевіряти, що ці органи надійно управляють своїми ключами, об’єднувати ключі в єдиний VICAL і надавати його верифікаторам.

З боку верифікатора, Європа підходить до проблеми довіри з іншого боку. В Архітектурі та довідковому фреймворку EUDI довірені сторони реєструються, отримують сертифікати доступу та використовують ці сертифікати для автентифікації перед застосунками гаманця при запиті атрибутів. Гаманець потім перевіряє ланцюг сертифікатів, перевіряє статус відкликання, представляє запит користувачу та передає лише затверджені атрибути.

Модель VC від W3C також робить свій внесок тут, розглядаючи верифіковані реєстри даних як окрему роль в екосистемі. Як зазначалося раніше, ці реєстри можуть бути довіреними базами даних, державними базами ідентифікаційних даних, децентралізованими базами даних або розподіленими реєстрами. Реєстр довіри майбутнього МВП не обов’язково має бути побудований на блокчейні. Він має бути керованим, підлягати аудиту та бути машиночитаним.

Якщо ISO 18013 визначає, як виглядає і передається обліковий запис, реєстри довіри вирішують, чи варто йому вірити.

Майбутній МВП — це стек, а не одна специфікація

Як працює майбутня транзакція МВП від початку до кінця

Ось стек у дії, розбитий на чотири ключові моменти життєвого циклу облікового запису.

1. Видача. Національний орган — або строго керований авторизований емітент — перевіряє базовий запис про посвідчення та видає обліковий запис до гаманця власника. OpenID4VCI є найбільш практичним рівнем видачі, доступним сьогодні, оскільки він вже підтримує формати ISO mdoc, SD-JWT VC і W3C VCDM. Сам ISO 18013-5 виключає зі сфери дії збір згоди та зберігання приватних ключів, що є саме тому, чому видача та управління гаманцем мають функціонувати вище базового транспортного рівня ISO.

2. Пред’явлення особисто. На узбіччі дороги або за стійкою оренди гаманець пред’являє обліковий запис за допомогою потоку близькості на основі 18013-5. Зчитувач перевіряє походження та цілісність за допомогою ключів емітента, отриманих із реєстру довіри, — а не приймає рішення про довіру самостійно. Власник підтверджує лише поля, необхідні для конкретної ситуації.

3. Дистанційне пред’явлення. Для перевірок перед орендою або інших онлайн-процесів верифікатор запитує мінімальний набір атрибутів через потік з підтримкою інтернету за допомогою 18013-7 та/або OpenID4VP. Гаманець показує, які атрибути запитуються, власник підтверджує, і верифікатор отримує структуровану презентацію, а не скан або завантаження PDF. Поточна архітектура NIST, побудована навколо OpenID4VP плюс Digital Credentials API, демонструє, що це вже є практичним інженерним шляхом.

4. Довіра та авторизація верифікатора. Гаманець не довіряє сліпо кожному запитувачу. Зріла екосистема автентифікує довірену сторону, перевіряє ланцюги сертифікатів, перевіряє статус відкликання та надає користувачу видимість щодо того, хто і які дані запитує. Модель EUDI особливо сильна тут, розглядаючи реєстрацію верифікаторів і сертифікати доступу як невід’ємні частини системи, а не необов’язкові доповнення.

Цей повний потік є саме тому, чому майбутній МВП має бути стеком. Жоден окремий рівень не може його забезпечити. Ні лише ISO. Ні лише VC. Ні лише OpenID. І вже точно не PDF, прикріплений до форми.

Чого ще бракує в стеку майбутнього МВП

Найскладніша задача, що залишилася, — це вже не створення нової криптографії, а досягнення керованої сумісності.

Розгляньмо поточний стан екосистеми:

NIST описав поточний ландшафт стандартів як такий, що розвивається в окремих сферах.
AAMVA побудувала регіональну службу довіри для Північної Америки.
Європа впроваджує довіру до довірених сторін на основі сертифікатів у свою архітектуру гаманця.
OpenID фіналізував специфікації видачі та пред’явлення і розширює інфраструктуру відповідності.

Це поки що відповіді, специфічні для окремих екосистем. Ще не існує єдиного глобального транскордонного рівня довіри для водійських посвідчень. Залишається визначити:

Які частини стеку є обов’язковими
Які формати облікових даних є прийнятними
Як розповсюджується довіра до емітентів і верифікаторів
Як тестується відповідність
Як транскордонне визнання управляється без шкоди для конфіденційності

Висновок: майбутній МВП — це стек, а не документ

Майбутній МВП не з’явиться тому, що одна організація зі стандартизації напише один документ. Він виникне тоді, коли цілісний стек буде визначено, керовано та прийнято в різних юрисдикціях. Цей стек вже має ідентифіковані рівні: