Поліція, Пункти Оренди, Роботодавці, Страховики: Чому Вони Не Повинні Бачити Однакові Дані

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

Один водій. Одне основне право на керування транспортним засобом. Один гаманець. Але чотири зовсім різних верифікатори:

• Поліцейський на узбіччі дороги
• Пункт прокату автомобілів при отриманні транспортного засобу
• Роботодавець, що перевіряє право на використання корпоративного транспорту
• Страховик, що розглядає страхову вимогу

Якщо майбутнє МПВ показує однакові дані всім чотирьом — система вже зазнала невдачі. Не тому що облікові дані ненадійні, а тому що модель розкриття інформації надто проста.

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

Чому Фізична Картка Навчила Нас Мислити Неправильно

Фізичне посвідчення привчило нас до підходу «показати все». Ви передаєте картку. Інша людина бачить те, що на ній написано. Це вся взаємодія.

Такий підхід прийнятний у паперовому світі, бо немає альтернативи. У цифровому він стає неприйнятним.

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

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

Правильна Модель — Розкриття на Основі Політик

Якщо ви прагнете серйозної архітектури, правильна модель більше схожа на контроль доступу на основі атрибутів, ніж на пред’явлення цифрової картки.

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

• Суб’єкт: водій
• Об’єкт: запитувані поля даних
• Дія: не абстрактне «переглянути посвідчення», а щось конкретне — наприклад, «підтвердити право на керування транспортним засобом категорії B на узбіччі» або «підтвердити право на оренду за бронюванням»
• Середовище: узбіччя дороги, пункт прокату, дистанційна попередня перевірка, оформлення корпоративного парку та розгляд претензії після збитку — різні середовища, які мають призводити до різних рішень

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

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

Верифікатор Повинен Ідентифікувати Себе Перш Ніж Щось Запитувати

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

Архітектура EUDI чітко вказує на це. Сторони, що покладаються на дані, повинні:

• Зареєструвати, які атрибути вони мають намір запитувати і з якою метою
• Отримати сертифікати доступу
• Автентифікуватися у гаманці перед будь-яким розкриттям інформації
• Перевірятися на відповідність зареєстрованій сфері застосування там, де реєстраційна інформація доступна

Користувач може бачити, хто запитує, що саме запитується та чи перебуває запит у межах зареєстрованої сфери.

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

• Торговельне найменування
• URI підтримки
• Передбачене використання
• Повноваження
• URI реєстру
• Інформація про наглядовий орган

Другий принцип майбутнього МПВ: без ідентифікації верифікатора — без розкриття інформації.

Чому Екрани Згоди Недостатні

Тут є ще одна помилка: ототожнення схвалення користувача з юридичною законністю.

Архітектура EUDI прямо зазначає, що схвалення користувачем передачі атрибутів не повинно розглядатися як законна підстава для обробки персональних даних стороною, що покладається. Сторона, що покладається, однак, повинна мати власну законну підставу. EUDI також вимагає схвалення користувача в усіх випадках використання, включаючи випадки, коли сторона, що покладається, може бути частиною правоохоронних органів або іншого державного органу.

Гарний інтерфейс гаманця може допомогти, але сам по собі не може вирішити проблему перевищення повноважень верифікатором. Правило має існувати раніше за інтерфейс.

Тому майбутнє МПВ потребує обох складових:

• Криптографічна автентифікація верифікатора для підтвердження того, хто запитує
• Обмеження на основі політик щодо того, що може запитувати ця категорія верифікаторів

Без обох складових «вибір користувача» перетворюється на спосіб перекласти провал політики на окрему людину.

1. Поліція: Перевірка Права на Керування, а Не Всієї Особи

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

Посібник ЄС з мобільних посвідчень водія описує це безпосередньо: поліція або інші посадові особи перевіряють посвідчення у разі необхідності, включаючи дійсність посвідчення та права на керування транспортним засобом. У сценарії взаємодії офіцер верифікує посвідчення через потік з QR-кодом, Bluetooth, Wi-Fi Aware або NFC. Це зосереджене завдання верифікації:

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

Дозволено за замовчуванням:

• Ім’я та прізвище
• Фотографія
• Статус посвідчення
• Дати видачі та закінчення терміну дії
• Категорії
• Обмеження, пов’язані з керуванням
• Орган видачі та юрисдикція
• Результат актуальності/статусу

Не дозволено за замовчуванням:

• Домашня адреса
• Внутрішні ідентифікатори, непотрібні для використання на узбіччі
• Непов’язані атрибути з інших підтверджень
• Журнали попередніх пред’явлень
• Комерційні метадані

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

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

2. Пункти Прокату: Право на Оренду, Підтвердження Особи — і Нічого Зайвого

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

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

Пункт прокату в першу чергу не займається розслідуванням інцидентів. Йому потрібно вирішити: Чи можу я здати цей автомобіль в оренду цьому клієнту за цим бронюванням і полісом?

Дистанційна попередня перевірка повинна включати:

• Прив’язку ідентифікаційних даних
• Фотографію або еквівалентний елемент прив’язки до особи
• Відповідну категорію транспортного засобу
• Дати видачі та закінчення терміну дії
• Поточну дійсність
• Можливо, порогове значення або діапазон віку

При отриманні слід підтвердити:

• Що власник — та сама особа, яка завершила попередню перевірку
• Поточну дійсність
• Відповідні права

За замовчуванням не потрібно:

• Повна домашня адреса, якщо профіль бронювання вже містить контактні дані
• Повна дата народження, якщо достатньо підтвердження про вік або вікового діапазону
• Непов’язані ідентифікаційні атрибути
• Повторне пред’явлення повного документа, якщо підтвердження бронювання вже існує

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

3. Роботодавці: Категорія Верифікатора, а Не Відкритий Доступ до Повної Ідентичності

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

Роботодавець або оператор корпоративного автопарку може законно потребувати знати:

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

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

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

Майбутнє МПВ не повинно перетворюватися на пропуск для доступу до робочого місця.

Для використання роботодавцями та корпоративними автопарками правильна схема зазвичай така:

• Перевірка прав, пов’язаних із роботою
• Можливо, періодичне підтвердження відповідності вимогам
• Можливо, підтвердження того, що власник зберігає дійсність для визначених категорій
• Але не стандартна передача всіх даних посвідчення щоразу, коли працівник входить у систему або розпочинає зміну

Відповідність вимогам корпоративного автопарку — це окрема категорія сторін, що покладаються, з окремим призначенням та окремим профілем розкриття інформації.

4. Страховики: Страхові Вимоги — Не Дозвіл на Постійний Нагляд

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

Але це не означає, що страховик повинен отримувати ті самі дані, що й поліція, або мати постійне право доступу до документа.

Майбутнє МПВ повинно розглядати страховиків як окрему категорію верифікаторів з окремими призначеннями:

• Андеррайтинг
• Верифікація ризику при оренді
• Обробка претензій після збитку
• Розгляд шахрайства

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

Законні, пов’язані з конкретною подією приклади:

• Підтвердження того, що посвідчення було дійсним у відповідний момент
• Підтвердження відповідного права на керування транспортним засобом
• Підтвердження прив’язки до особи там, де це необхідно для претензії
• Розкриття інформації, обмежене конкретною претензією

За замовчуванням не дозволено:

• Постійний доступ до базового документа
• Повторна загальна верифікація щоразу, коли клієнт взаємодіє зі страховиком
• Використання документа водія як токену для входу в систему
• Збір непов’язаних атрибутів

Документ водія — не підписка на моніторинг. І він не повинен непомітно нею ставати.

Чому Посередники Повинні Бути Видимими

Реальні ринки передбачають посередників. Платформи оренди, постачальники послуг для корпоративних автопарків, HR-системи роботодавців і обробники страхових претензій часто діють через треті сторони.

Архітектура EUDI вирішує це шляхом:

• Розгляду посередників як сторін, що покладаються
• Вимоги до їхньої реєстрації
• Вимоги реєстрації атрибутів, що запитуються для посередницької сторони
• Відображення і посередника, і кінцевої сторони користувачеві
• Заборони для посередників зберігати дані про зміст транзакції

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

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

Зберігання Даних — Частина Контролю Доступу

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

Поточні рекомендації вже сходяться:

• AAMVA: гаманець повинен чітко повідомляти власника, які дані були запитані та чи має намір верифікатор їх зберігати; учасники не повинні відстежувати власників або використання мобільного посвідчення, крім випадків, передбачених законом
• W3C: програмне забезпечення власника повинне вести журнали інформації, переданої верифікаторам, щоб можна було виявити надмірні запити
• EUDI: користувачі повинні мати доступ до журналів транзакцій, можливість повідомляти про підозрілі запити та запитувати видалення даних

Клас зберігання повинен бути частиною самої політики розкриття:

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

Майбутнє МПВ, яке ігнорує питання зберігання, забезпечує лише часткову конфіденційність.

Що Насправді Повинен Вирішувати Гаманець

Якби мені потрібно було звести всю цю статтю до одного правила реалізації, воно звучало б так:

Гаманець не повинен відповідати на запитання «Чи можу я пред’явити цей документ?» Він повинен відповідати на запитання «Чи можу я передати цей набір відомостей цьому автентифікованому верифікатору, для цього призначення, в цьому контексті, за цим класом зберігання?»

Це рішення повинне ґрунтуватися щонайменше на таких вхідних даних:

• Ідентифікація верифікатора
• Категорія верифікатора
• Призначення
• Зареєстрована сфера атрибутів
• Політика розкриття від емітента, якщо є
• Середовище (узбіччя дороги, отримання, дистанційно, корпоративний автопарк, претензія)
• Схвалення власника
• Застосовна політика зберігання

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

Основний Аргумент

Майбутнє МПВ не повинно запитувати, чи можуть дані бути розкриті. Воно повинно запитувати:

• Хто запитує?
• З якою метою?
• На підставі якого повноваження?
• В якому контексті?
• З якими наслідками для зберігання?

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

Це не зайва складність. Саме так виглядає сучасний документ водія, коли він перестає ставитися до кожного верифікатора однаково.