Полиция, прокатные стойки, работодатели, страховщики: почему они не должны видеть одни и те же данные

Главная ошибка при проектировании будущего Международного водительского удостоверения (МВУ) — рассматривать каждого верификатора как одного и того же. Сотрудник полиции, стойка проката автомобилей, работодатель и страховщик задают разные вопросы — а значит, должны получать разные ответы.

Один водитель. Одно основное право на управление транспортным средством. Один кошелёк. Но четыре совершенно разных верификатора:

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

Если будущее МВУ показывает одни и те же данные всем четырём — система уже потерпела неудачу. Не потому, что учётные данные ненадёжны, а потому, что модель раскрытия информации слишком проста.

Сообщество разработчиков стандартов уже отходит от этой упрощённой модели. Работа 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 по верифицируемым учётным данным приходит к тому же техническому выводу: верификаторы должны запрашивать только строго необходимое.

Законные, событийно-обусловленные примеры:

• Подтверждение того, что удостоверение было действительно в соответствующий момент
• Подтверждение соответствующей категории транспортного средства
• Подтверждение привязки к личности там, где это необходимо для урегулирования претензии
• Раскрытие, привязанное к конкретному страховому случаю

По умолчанию не разрешено:

• Постоянный доступ к базовому документу
• Повторная общая верификация при каждом взаимодействии клиента со страховщиком
• Использование водительского документа в качестве токена для входа
• Сбор не связанных атрибутов

Водительский документ — не подписка на мониторинг. И не должен тихо ею становиться.

Почему посредники должны быть видимы

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

Архитектура EUDI решает эту проблему следующим образом:

• Рассматривая посредников как доверяющие стороны
• Обязывая их регистрироваться
• Требуя регистрации атрибутов, запрашиваемых в интересах конечной доверяющей стороны
• Показывая пользователю как посредника, так и конечную доверяющую сторону
• Запрещая посредникам хранить данные о содержании транзакции

Будущее МВУ не должно допускать ситуации, когда пользователь считает, что раскрывает данные прокатной компании, а в действительности — невидимой цепочке из брокера верификации, аналитического процессора и поставщика услуг по претензиям.

Здесь помогает ETSI. Его модель сертификатов доверяющих сторон кошелька включает URI поддержки, предполагаемое использование, URI реестров и метаданные надзорных органов. Именно такая машиночитаемая инфраструктура нужна пользователям, чтобы понять, кто на самом деле стоит за запросом и куда обращаться для удаления или исправления данных.

Хранение данных — часть управления доступом

Большинство дискуссий об избирательном раскрытии заканчиваются слишком рано. Они сосредоточены на том, что раскрывается. Но недостаточно внимания уделяется тому, как долго данные хранятся после этого.

Современные руководящие принципы уже сближаются:

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

Класс хранения должен быть частью самой политики раскрытия:

• Дорожная проверка полицией: хранение по умолчанию не осуществляется, за исключением законных оперативных записей
• Предварительная проверка при прокате: запись о транзакции привязана к бронированию, а не является многократно используемой копией удостоверения личности
• Соответствие требованиям работодателя / автопарка: запись о соответствии или результат аттестации, а не необработанные данные удостоверения
• Страховая претензия: запись о претензии, ограниченная конкретным случаем, без постоянного доступа

Будущее МВУ, игнорирующее хранение данных, обеспечивает конфиденциальность лишь частично.

Что на самом деле должен решать кошелёк

Если свести всю эту статью к одному правилу реализации, оно будет таким:

Кошелёк не должен отвечать на вопрос «Могу ли я предъявить этот документ?» Он должен отвечать на вопрос «Могу ли я передать этот набор данных данному аутентифицированному верификатору, для данного предполагаемого использования, в данном контексте, при данном классе хранения?»

Это решение должно основываться как минимум на следующих входных данных:

• Идентификация верификатора
• Категория верификатора
• Предполагаемое использование
• Зарегистрированная область атрибутов
• Политика раскрытия от эмитента, если она задана
• Среда (дорога, выдача, удалённо, автопарк, претензия)
• Одобрение держателя
• Применимая политика хранения

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

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

Будущее МВУ не должно спрашивать, можно ли раскрыть данные. Оно должно спрашивать:

• Кто запрашивает?
• С какой целью?
• На каком основании?
• В каком контексте?
• С какими последствиями для хранения данных?

Полиция, прокатные стойки, работодатели и страховщики — это не четыре логотипа на другом конце запроса. Это четыре разные модели риска, четыре разных правовых контекста, четыре разные причины для обращения — и они должны порождать четыре разных набора раскрываемых данных.

Это не излишняя сложность. Именно так выглядит современное водительское удостоверение, когда оно перестаёт относиться ко всем верификаторам одинаково.