Привязка к держателю в EUDI Wallet: что на самом деле доказывает предъявление
Проблема владения по первоисточникам: что доказывает предъявление из кошелька, что ARF v3.0.0 говорит о привязке к пользователю и портрете, таблица угроз и усиленная проверка по риску для регулируемых команд.
Коротко
Привязка к держателю в EUDI Wallet связывает человека, который предъявляет кошелек, с человеком, которому были выданы идентификационные данные. Architecture and Reference Framework (ARF) называет это User binding, и при большинстве предъявлений доверяющая сторона полагается на эту привязку, а не проверяет ее.[2]
- Проверенное предъявление с привязкой к устройству доказывает, что данные подлинные и не изменены и что кошелек хранит привязанный ключ.[2]
- Оно не доказывает, кто держит телефон при вашем следующем входе, выплате или сбросе пароля.
- Высокий уровень даёт реальную гарантию. Оставьте кошелек способом по умолчанию и добавляйте проверку лица только там, где это оправдано риском.
Это проблема владения. Подпись кошелька показывает, что ключ был использован. Чтобы перейти от этого ключа к человеку, нужна цепочка доверия, и последнее звено находится на телефоне, который вы не контролируете.
Ничто из этого не делает кошелек слабым. Он выдается в рамках схемы с высоким уровнем гарантии, и команда, которая относится к нему с подозрением, теряет его ценность. В этом руководстве разобрано, на что он отвечает, что оставляет открытым и как закрыть этот пробел.
О регистрации и сертификатах читайте наше руководство для доверяющих сторон. О выборе способа интеграции читайте статью как выбрать платформу для интеграции EUDI Wallet.
Что на самом деле доказывает предъявление из кошелька
При удалённом предъявлении последовательно выполняется несколько проверок. Часть из них выполняете вы, а часть проходит внутри кошелька, где вы их не видите.
Шаг 3 вы никогда не видите
Проверка подписи и статуса
Проверка привязки к устройству
Упрощённая схема удалённого предъявления по ARF v3.0.0, раздел 6.6.3. Шаги 1, 2 и 4 видны вам или человеку. Шаг 3 не виден.[2]
| Уровень | Что устанавливает | Кто проверяет | Статус для вас | Ограничение |
|---|---|---|---|---|
| Подпись эмитента | Данные получены от подлинного поставщика и не были изменены[2] | Вы | Статья 5b(9) возлагает это на доверяющие стороны, для PID и аттестаций[1] | Ничего не говорит о том, кто предъявляет |
| Статус отзыва | Данные не были отозваны их поставщиком[2] | Вы | Рекомендуется, но не обязательно[3] | Актуальность не выше, чем у источника статуса |
| Привязка к устройству | Данные находятся в том экземпляре кошелька, которому они были выданы, а не в копии[2] | Вы | Рекомендуется, но обязательно, если вы полагаетесь на собственную аутентификацию кошелька[2] | Подтверждает ключ, а не человека |
| Целостность кошелька | Экземпляр кошелька и его защищённое оборудование были действительны на момент выдачи[2] | Поставщик данных, при выдаче[2] | Вы доверяете этому опосредованно[2] | У вас нет способа проверить это напрямую[2] |
| Аутентификация пользователя | Кошелёк аутентифицировал своего пользователя перед передачей данных[2][6] | Кошелёк | Вы доверяете этому опосредованно[2] | Результат до вас не доходит |
ARF v3.0.0 разделяет предусмотренную регламентом аттестацию экземпляра кошелька на Wallet Instance Attestation, которая касается целостности приложения и его статуса отзыва, и Key Attestation, которая касается защищённого хранилища ключей.[2] О вашем положении сказано так: «Экземпляр полагающейся стороны не имеет возможности напрямую проверить подлинность единицы кошелька и поставщика кошелька».[2]
Рисунок 12 из ARF: пользователь взаимодействует с экземпляром кошелька через канал аутентификации, который доверяющая сторона никогда не видит. Источник: EUDI Wallet Architecture and Reference Framework, Европейская комиссия, CC BY 4.0. Без изменений.
Закройте пробел, который оставляет кошелёк
Проводите проверку живости и сравнение лиц для действий с реальным риском, в том процессе верификации, который вы используете сегодня. Начните бесплатно или свяжитесь с нами.
Привязка к устройству, привязка к держателю и пробел после них
Под понятием «привязка к держателю» смешивают три разные связи. Первые две относятся к понятиям ARF. Третья связь названа нами.
Ключ к кошельку
Привязка к устройству
- Данные привязаны к ключу в защищённом оборудовании[2]
- Также называется подтверждением владения (proof of possession)[2]
- Защищает от копирования и повторного воспроизведения[2]
Проверяется вами
Кошелек к человеку
Привязка к пользователю
- Предъявитель является тем лицом, которому выданы данные[2]
- Зависит от привязки к устройству[2]
- Обычно принимается на доверии, а не проверяется[2]
Выполняется кошельком
Человек к действию
Привязка к действию
- Это лицо совершило это последующее действие
- Находится за пределами предъявления
- Обеспечивается вашей сессией и вашими средствами контроля
Только ваша задача (наш термин)
Привязка к устройству (Device binding) и привязка к пользователю (User binding) являются терминами ARF. Привязка к действию (Action binding) является обозначением Didit, а не термином какого-либо стандарта.
В дискуссионном документе ARF об аттестациях, привязанных к устройству, это различие сформулировано одной фразой: «Аттестация может быть привязана к устройству, но не к пользователю».[11] Важно именно следующее определение.
Раздел 6.6.3.9ARF v3.0.0
«Привязка к пользователю (иногда также называемая „привязкой к держателю“) означает, что лицо, предъявляющее PID или аттестацию полагающейся стороне, действительно является пользователем, которому был выдан PID или аттестация».
Источник: ARF v3.0.0, глава 6[2]
На уровне протокола вы управляете этим свойством через параметр require_cryptographic_holder_binding в OpenID4VP. По умолчанию он равен true. Значение false сообщает кошельку, что вы принимаете учетные данные без такого доказательства.[12] Там, где в ARF говорится о привязке к устройству, протокол говорит о привязке к держателю.[12][2] Не отключайте его. Проверки описаны в нашем руководстве по верификатору OpenID4VP.
Что говорят закон и ARF, их собственными словами
Эти положения регулируют выдачу кошелька и его предъявление, а не последующие действия в вашем аккаунте.
| Норма | Текст | Что это значит для вас |
|---|---|---|
| Ст. 5a(4)(a), Регламент 910/2014 | Кошельки должны позволять пользователям предъявлять данные «под единоличным контролем пользователя»[1] | Наше толкование: это требование к устройству кошельков, а не вывод о какой-либо сессии |
| Ст. 5a(5)(d) и 5a(11) | Кошельки соответствуют требованиям высокого уровня и предоставляются в рамках схемы высокого уровня[1] | Надёжная основа, дополнительное подтверждение этого утверждения не требуется |
| Ст. 5b(9) | Доверяющие стороны отвечают за «аутентификацию и проверку достоверности» данных[1] | Проверка подписи и действительности лежит на вас |
| Ст. 3(5), Регламент 2024/2977 | Поставщики PID «должны обеспечивать», чтобы выдаваемые ими PID были «криптографически привязаны к экземпляру кошелька, которому они выданы»[4] | Поставщики PID обязаны привязать PID к экземпляру кошелька, а вы проверяете результат |
| Ст. 3(1), Регламент 2024/2979 | Никаких основных функций, «пока экземпляр кошелька не аутентифицировал пользователя кошелька»[6] | Кошелёк аутентифицирует пользователя до любых действий |
| Приложение, пункт 2.2.1, Имплементационный регламент 2015/1502 | Для высокого уровня: «Средство электронной идентификации спроектировано так, что лицо, которому оно принадлежит, может надёжно защитить его от использования другими лицами».[7] | Защита от других лиц, доступная владельцу |
| WIAM_14, ARF, Приложение 2 | Защищённое оборудование для PID аутентифицирует пользователя на высоком уровне до криптографических операций с его критическими активами[3] | Второй уровень аутентификации внутри кошелька |
Раздел 6.5.3.3.1 ARF гласит: «При активации экземпляра кошелька экземпляр кошелька обеспечивает, чтобы пользователь настроил два механизма аутентификации пользователя». Один работает на уровне операционной системы, другой в защищённом криптографическом оборудовании, которое используется при выдаче, предъявлении или удалении PID.[2] Чтобы предъявить PID, пользователь должен пройти оба.[2]
Раздел 6.6.3.9 о доверии к этой аутентификации: «Это доверие не основано на результате какой-либо проверки, проведённой самой полагающейся стороной», а на «априорном доверии к сертифицированному экземпляру кошелька и (для PID и аттестаций с уровнем безопасности „высокий“) к сертифицированным WSCA/WSCD».[2] (WSCA и WSCD: защищённое криптографическое приложение и устройство кошелька.) ARF добавляет, что опора на этот метод «подразумевает, что полагающиеся стороны должны проверять привязку к устройству».[2]
Таким образом, ARF предусматривает три способа привязки к пользователю. Довериться аутентификации кошелька, которая выполняется всегда. Сравнить портрет в PID с живым лицом. Или сравнить атрибуты PID с документом, удостоверяющим личность, который, как вы можете проверить, действительно принадлежит этому человеку.[2]
Почему высокий уровень даёт реальную гарантию
Высокий уровень требует защиты «от злоумышленников с высоким потенциалом атаки».[7] Сертификация проверяет эту устойчивость.[8] Поддельный PID, клонированный кошелёк или повторно воспроизведённый ответ не должны пройти. Наша трактовка: высокий уровень описывает средство и ничего не говорит о реальном держателе, который решил дать другому лицу пользоваться им или продать такое право.
Рабочий документ ARF по Topic R от 14 октября 2025 фиксирует, что «на сегодняшний день мобильные устройства не имеют средств или оснований подтверждать полагающимся сторонам кошелька, что аутентификация пользователя выполнена», а также что, по мнению ряда экспертов, биометрия устройств «не полностью надёжна».[10] Это протокол обсуждения, а не требование.
- 11 августа 2026Правила подтверждения портретаРегламент 2026/1731 в силе: предупреждения и явное подтверждение.
- 24 декабря 2026Срок для кошельковРасчёт: 24 месяца с даты актов.
- 10 июля 2027Начало применения AMLRСтатья 22(6) становится обязательной для обязанных субъектов.
- 24 декабря 2027ПринятиеРасчёт: Статья 5f(2). Частные стороны, обязанные по закону или договору применять строгую аутентификацию пользователя, по запросу пользователя; микро- и малые предприятия освобождены.
- 11 августа 2028Портрет в PIDОбязательный атрибут PID с этой даты, с учётом возможностей отказа.
Декабрьские даты рассчитаны нами по Статьям 5a(1) и 5f(2), считая от вступления в силу имплементационных актов, указанных в Статьях 5a(23) и 5c(6) (Регламенты 2024/2977–2024/2982, вступили в силу 24 декабря 2024).[1][4][5][13] См. наше руководство по срокам EUDI Wallet.
Портрет: полезен, необязателен и строго регулируется
Портрет, очевидный способ проверить человека. Имплементационный регламент (ЕС) 2026/1731, принятый 15 июля 2026 и опубликованный в Официальном журнале 22 июля 2026, изменил правила для портрета.
- Сроки. «портрет пользователя кошелька может входить в обязательные данные идентификации физического лица только с 11 августа 2028 года».[5] Согласно действующей таблице PID, портрет включается «за исключением случаев, когда пользователь явно отказывается, если применимо».[5]
- Отказ сохраняется. Государства-члены «могут предусмотреть, что у пользователя есть возможность отказаться от включения портрета», и тогда значение оставляется пустым.[5]
- Предупреждение кошелька. Кошелек предупреждает, что запрос касается биометрических данных, и пользователь должен «явно и конкретно подтвердить предъявление портрета».[4] ARF RPA_07c добавляет: «Молчания или заранее отмеченного поля НЕДОСТАТОЧНО».[3]
- Не правовое основание. В пункте 2 преамбулы Регламента 2026/1731 сказано: «Явное подтверждение пользователя кошелька должно быть техническим средством защиты и само по себе не должно служить правовым основанием для обработки».[5] Для правового основания преамбула отсылает к статьям 6 и 9 GDPR.[5]
- Хранение. Портрет «не должен храниться доверяющими сторонами, кроме случаев, когда его обработка необходима для целей идентификации и аутентификации» в соответствии с законодательством о защите данных, либо когда это предусмотрено правом Союза или национальным правом.[4][5]
- Регистрация. Согласно статье 5b(3) вы не можете запрашивать данные сверх зарегистрированных, поэтому портрет должен входить в ваш зарегистрированный сценарий использования.[1]
Для удалённого сравнения ARF требует хорошего освещения, понятных инструкций и «утверждённого механизма проверки живости (liveness), поддерживающего обнаружение атак предъявления (Presentation Attacks Detection)», «а также механизмов обнаружения атак внедрения, в частности обнаружения дипфейков».[2] ENISA подробно описывает атаки предъявления на лицо.[21] ETSI TS 119 461 определяет атаку внедрения как «атаку, заключающуюся во внедрении контролируемого злоумышленником контента в процесс сбора данных».[23]
Проверка лица на телефоне: этап съемки и есть поверхность атаки. Иллюстрация: mikemacmarketing, Wikimedia Commons, CC BY 2.0. Без изменений.
Верификация «один к одному», единственная цель которой состоит в подтверждении заявленной личности, исключена из пункта Приложения III AI Act об удаленной биометрической идентификации.[16] Биометрические данные, используемые для однозначной идентификации человека, остаются данными особой категории по статье 9 GDPR, поэтому заранее определите законное основание и предусмотрите оценку воздействия.[15]
Угроза за угрозой: что останавливает кошелек и что остается за вами
Регламент о сертификации содержит реестр рисков для кошельков. Приведенные ниже идентификаторы угроз являются официальными. Последние два столбца содержат нашу оценку.[8]
| Угроза | Реестр | Эффект кошелька | Что остается | Ваш контроль |
|---|---|---|---|---|
| Скопированные или дублированные данные кошелька | TR60 | Сильный: привязка к устройству[2] | Немного, если вы это проверяете | Не отключайте доказательство привязки |
| Повторно воспроизведенное предъявление | Тип 5.3 | Сильный: свежая подпись над вашими данными[2] | Немного | Уникальный nonce для каждого запроса |
| Украденный телефон, заблокированный | TR98 | Сильный: два уровня аутентификации[2] | Кража фактора знания (TR35) | Проверить статус отзыва |
| Общее устройство в семье | TR35, TR98 | Частично | Человек, который знает PIN или код[22] | Усиленная проверка при действиях с высоким риском |
| Пользователь под принуждением или манипуляцией | TR28, TR99 | Слабая: подтверждает настоящий пользователь | Почти всё | Мониторинг транзакций, период ожидания, усиленная проверка с учетом контекста |
| Ретрансляция между устройствами | TR103 | Частично: проверка близости[24] | Фишинг сессии браузера | По возможности на том же устройстве, называйте действие |
| Обход локальной аутентификации | TR113 | Зависит от сертификации[8] | Риск скомпрометированного устройства | Проверка отзыва, сигналы устройства |
| Захват аккаунта после онбординга | Вне кошелька | Нет, если не предъявлено повторно | Пароли, сессии, процедуры восстановления | Усиленная проверка при чувствительных изменениях |
| Дроп с настоящим кошельком | Вне кошелька | Нет: все проверки пройдены | Всё | Мониторинг поведения, связи в сети |
Настоящий пользователь, который подтверждает
TR99 гласит: «Злоумышленник может убедить пользователя пройти аутентификацию и подтвердить транзакции со злоумышленником или неуполномоченной третьей стороной».[8] Все факторы проходят проверку. По данным ECB, строгая аутентификация клиента «остается эффективной против тех видов мошенничества, для противодействия которым она создавалась». Общий объем зарегистрированного мошенничества в Европейской экономической зоне в 2024 году составил €4.2 млрд.[19][20] По кредитовым переводам доля мошенничества с манипулированием плательщиком выросла «с 65% до 74% в стоимостном выражении и с 55% до 71% в количественном выражении с 2023 по 2024 год».[19]
Два человека, два устройства
TR103: «Пользователь за соединением полагающейся стороны с браузером может отличаться от пользователя за соединением полагающейся стороны с кошельком».[8] В разделе 4.4.3.2 ARF отмечается, что «межустройственные сценарии уязвимы для фишинга и ретрансляционных атак», а раздел 4.4.3 делает для них обязательной проверку близости.[24] При этом ваша веб-сессия по-прежнему остается отделенной от подтверждения в кошельке.
Рисунок 5 ARF: в межустройственном сценарии ваш сервис взаимодействует с браузером, а кошелек находится на втором устройстве. Источник: EUDI Wallet Architecture and Reference Framework, Европейская комиссия, CC BY 4.0. Без изменений.
Дроп с настоящим кошельком
Человек, который продает доступ к счету или открывает счет для другого лица, честно проходит все проверки кошелька, потому что он и есть держатель. Мера контроля здесь та, которую уже устанавливает Регламент о противодействии отмыванию денег (AMLR): «постоянный мониторинг деловых отношений».[13] Сети выявляют такие сигналы, как связи между счетами, общие устройства и повторяющиеся лица.
Схема усиленной проверки, при которой кошелек остается вариантом по умолчанию
Ни один изученный нами текст не требует проверки живости в дополнение к кошельку. Статья 22(6)(b) AMLR называет в качестве одного из вариантов «использование средств электронной идентификации, отвечающих требованиям Регламента (ЕС) № 910/2014 в отношении уровней обеспечения „существенный“ или „высокий“».[13] В окончательном проекте стандартов Управления по противодействию отмыванию денег (AMLA) указано, что это «включает европейские кошельки цифровой идентичности». Эти стандарты пока остаются проектом, а не правом.[14] См. наше руководство по AMLR о приеме кошельков.
Статья 20(2) AMLR ставит объем мер в зависимость от «индивидуального анализа рисков».[13] На наш взгляд, селфи при каждом предъявлении трудно обосновать с учетом принципа минимизации данных GDPR.[15] Эти уровни являются нашим предложением, а не правовыми категориями.
1Классифицируйте событие
Онбординг, вход или конкретное действие, с его уровнем риска.
Какой вред может причинить не тот человек
Только кошелек
Полные криптографические проверки. Без биометрии.
Добавьте проверку живости и сравнение лиц
С портретом или с изображением лица, которое вы храните на законных основаниях.
Повторная верификация при действии
Новая проверка, привязанная к этому действию, затем рассмотрение.
2Зафиксируйте доказательства
Что было проверено, результат, дата. Портрет по умолчанию не сохраняется.
Пример схемы принятия решений. Установите собственные пороги в своей оценке рисков.
| Уровень | Типичные события | Меры контроля | Почему |
|---|---|---|---|
| Только кошелёк | Проверка возраста или атрибутов, стандартное открытие счёта, вход с низким риском | Подпись, привязка к устройству, статус, nonce | Основную работу делает высокий уровень; чем меньше данных, тем лучше |
| Кошелёк плюс лицо | Клиент повышенного риска, необычное устройство или местоположение, первое использование после долгого перерыва | Всё перечисленное выше, плюс проверка живости и сравнение лиц | Напрямую решает задачу привязки к пользователю (User binding), как описано в ARF[2] |
| Повторная верификация действия | Новый получатель, крупная выплата, изменённые банковские реквизиты, восстановление доступа, добавление устройства | Новая проверка лица или подтверждение, привязанное к операции, плюс проверка | Связывает человека с этим действием |
| Нет кошелька или нет портрета | Клиент без кошелька, страна с поздним запуском, отказ от портрета | Документ, чтение чипа, проверка живости, сравнение лиц | Использование кошелька добровольно[1] |
PID не может подтвердить действие за вас: «Экземпляры кошелька НЕ ДОЛЖНЫ использовать закрытый ключ PID для подписи данных транзакции, полученных от полагающейся стороны в запросе на предъявление».[9] Подтверждение операций относится к аттестациям строгой аутентификации пользователя (SUA). Они содержат данные транзакции и относятся к теме ARF об электронных платежах.[3] Платёжное право устроено так же: код должен быть «привязан к сумме платёжной операции и получателю платежа».[18] Формулировка PSD2 «любое действие через удалённый канал, которое может повлечь риск платёжного мошенничества или иных злоупотреблений» служит удобной моделью триггера.[17]
Вариант
Повторно кошелёк
- Новое предъявление PID
- Повторно подтверждает кошелёк
- Нет связи с действием
Подходит для входа
Вариант
Проверка лица
- Проверка живости и сравнение лиц
- Проверяет присутствующего человека
- Нужен законно полученный эталон
Подходит для рискованных изменений
Вариант
Подтверждение транзакции
- Подписывает данные операции
- Показывает пользователю, что именно он подтверждает
- Зависит от поддержки эмитента
Подходит для платежей
Обратите внимание
Не используйте ключ PID как идентификатор устройства. Провайдеры могут выдавать аттестации, которые предъявляются только один раз, чтобы «снизить риск связывания полагающейся стороной».[2] Сопоставляйте повторных клиентов по атрибутам, как описано в нашем руководстве по трансграничному приему.
Чек-лист: что сделать в этом месяце
Внутренняя политика, на которой основаны эти шаги, описана в нашем руководстве по политикам и мерам контроля для EUDI Wallet, а выбор способа интеграции разобран в руководстве по платформе интеграции.
Комплаенс и риски
- Зафиксируйте, какие из ваших событий опираются только на кошелек.
- Определите триггеры усиленной проверки для выплат, смены получателя и восстановления доступа.
- Определите правовое основание для любого сравнения лиц.[5][15]
- Обновите оценку воздействия на защиту данных с учетом использования портрета.[15]
Разработка
- Сохраняйте обязательное доказательство привязки к держателю в каждом запросе.[12]
- Проверяйте подпись привязки к устройству в каждом ответе.[2]
- Проверяйте статус отзыва, даже если это необязательно.[3]
- Привязывайте каждое предъявление к одной сессии с помощью нового nonce.
- Стройте сценарий с портретом так, чтобы он обрабатывал пустое значение.[5]
Продукт и поддержка
- Запрашивайте портрет только там, где это предусмотрено вашими зарегистрированными целями.[1]
- Сохраните путь с документом для людей без кошелька.[1]
- Сформулируйте текст для каждой усиленной проверки так, чтобы в нем было названо действие.
- Сообщите клиентам, что они могут попросить поставщика кошелька отозвать украденный кошелек.[6]
Как Didit помогает решить проблему владения
В документации Didit прием EUDI Wallet указан со статусом «Скоро появится».[28] На нашей странице EUDI Wallet сказано: «Специального API Didit для EUDI пока нет» и «Интегрируйтесь сегодня и сохраните интеграцию, когда появится кошелек». В этом разделе описано то, что работает уже сейчас. Biometric Authentication выполняет усиленные проверки живости и сравнения лиц.
- Повторная верификация. Biometric Authentication проверяет повторных пользователей только с помощью проверки живости или с помощью проверки живости и сравнения лиц с сохраненным портретом, как сессию в рамках процесса.[25][27]
- Присутствие. Liveness проверяет, что перед камерой находится реальный человек, пассивным методом, методом 3D-действия или методом вспышек.[26]
- Усиленная проверка. В документации Authentication от Didit описан вызов, который применяет ваши правила усиленной проверки перед чувствительным действием и возвращает ответ, требуется ли верификация. Эта функция новая и включается для каждого приложения отдельно.[31]
- Networks. Face Search находит дублирующиеся аккаунты, а Networks группирует заявителей, у которых совпадают сигналы устройства, IP, биометрии, документа или контактных данных.[29][30]
- Мониторинг. Transaction Monitoring проверяет транзакции в реальном времени по настраиваемому движку правил, с управлением кейсами.[32]
- Резервный путь. ID Verification и действующие национальные eID обслуживают клиентов без кошелька.[28]
Didit обеспечивает
- Проверку живости и сравнение лиц по запросу
- Пути через документы и национальные eID
- Сигналы дубликатов и сетей
- Запись о каждой проверке
Остается за вами
- Оценка рисков и политика усиленной проверки
- Ваше правовое основание и оценка воздействия
- Регистрация доверяющей стороны
- Каждое решение об онбординге и по транзакции
Тарифы и цены указаны на нашей странице цен. Хранимые данные подчиняются настроенному вами сроку хранения, а Didit выступает вашим обработчиком.[33]
Спроектируйте усиленную проверку вместе с нами
Расскажите, какие действия несут наибольший риск, и начните с проверки живости и сравнения лиц в вашем процессе.
Ключевые выводы
- Привязка к устройству подтверждает ключ. Привязка к пользователю связывает этот ключ с человеком, и обычно вы ей доверяете, а не проверяете ее.
- Высокий уровень дает сильную гарантию в отношении кошелька, но не покрывает добровольного дропа или пользователя, которым манипулируют.
- Портрет входит в обязательные данные PID с 11 августа 2028, с учетом возможности отказа, а подтверждение пользователя не является правовым основанием.
- PID не может подписывать данные транзакции, поэтому для действий с высоким риском нужно отдельное подтверждение.
Часто задаваемые вопросы
Что такое привязка к держателю в EUDI Wallet?
Привязка к держателю означает, что лицо, предъявляющее данные, является тем лицом, которому они были выданы. ARF называет ее User binding и указывает, что ее иногда также называют holder binding.[2]
Чем привязка к устройству отличается от привязки к держателю?
Привязка к устройству связывает данные с ключом в защищенном оборудовании кошелька и предотвращает копирование и повторное воспроизведение. Привязка к держателю связывает данные с человеком. ARF рассматривает привязку к устройству как предварительное условие привязки к пользователю.[2]
Обязательна ли привязка к устройству для PID?
Да, для поставщиков. Имплементационный регламент 2024/2977 обязывает поставщиков PID обеспечивать криптографическую привязку выдаваемых ими PID к экземпляру кошелька.[4] Проверка подписи рекомендуется доверяющим сторонам и обязательна, если вы полагаетесь на собственную аутентификацию кошелька.[2]
Можно ли сравнить лицо с портретом в кошельке?
Только если в PID он есть, вы зарегистрировали такое использование, пользователь подтверждает его и у вас есть правовое основание. С 11 августа 2028 года портрет входит в обязательные данные PID, и государства-члены могут разрешить пользователям отказаться.[5]
Можно ли сохранить портрет, полученный при предъявлении из кошелька?
По умолчанию нет. Его можно хранить, только если обработка необходима для идентификации и аутентификации в соответствии с правом Союза о защите данных или если это предусмотрено правом Союза или национальным правом.[4][5]
Требует ли AMLR проверку живости (liveness) в дополнение к EUDI Wallet?
Ни один прочитанный нами текст этого не требует. Статья 22(6)(b) в качестве одного из вариантов называет средства электронной идентификации, отвечающие требованиям Регламента 910/2014 на уровне «существенный» или «высокий», а объем мер определяется вашим индивидуальным анализом рисков.[13] В окончательном проекте стандартов AMLA сказано, что сюда относятся и кошельки, но эти стандарты пока не имеют силы закона.[14]
Можно ли подтвердить платеж предъявлением из кошелька?
С помощью PID нельзя. PID Rulebook запрещает использовать закрытый ключ PID для подписи данных транзакции.[9] ARF предполагает, что подтверждение конкретной транзакции опирается на аттестации строгой аутентификации пользователя, которые содержат данные транзакции.[3]
Защищает ли уровень «высокий» от захвата учетной записи?
Он защищает кошелек, а не вашу учетную запись. После онбординга ваши пароли, сессии и процессы восстановления доступа находятся вне кошелька, если только вы не запрашиваете новое предъявление или другую проверку в чувствительные моменты.
Может ли дроп пройти проверки EUDI Wallet?
Да. Реальный держатель с реальным кошельком проходит все проверки, потому что результаты проверок верны. Мерой контроля служит постоянный мониторинг по статье 26 AMLR, а также выявление связей между счетами.[13]
Принимает ли Didit EUDI Wallet?
В документации Didit прием EUDI Wallet указан со статусом «Скоро появится», а на странице решений сказано, что отдельного API Didit для EUDI пока нет.[28] Национальные eID, проверка документов, проверка живости и сравнение лиц работают уже сейчас, а на странице решений описан план.
Источники
- Регламент (ЕС) № 910/2014 с изменениями, внесенными Регламентом (ЕС) 2024/1183, консолидированный текст от 18 октября 2024, EUR-Lex.
- Architecture and Reference Framework v3.0.0, глава 6, Trust model, Европейская комиссия, 23 июля 2026.
- Architecture and Reference Framework v3.0.0, Приложение 2, High-Level Requirements, Европейская комиссия.
- Имплементационный регламент (ЕС) 2024/2977, консолидированный текст от 11 августа 2026, EUR-Lex.
- Имплементационный регламент (ЕС) 2026/1731, EUR-Lex, Официальный журнал от 22 июля 2026.
- Имплементационный регламент (ЕС) 2024/2979, консолидированный текст от 11 августа 2026, EUR-Lex.
- Имплементационный регламент (ЕС) 2015/1502 об уровнях гарантии, EUR-Lex.
- Имплементационный регламент (ЕС) 2024/2981 о сертификации кошельков, Приложение I, реестр рисков, EUR-Lex.
- PID Rulebook v1.7, Европейская комиссия, 17 июля 2026.
- Тема R, Authentication of the User to the device, v1.0, дискуссионный документ ARF, 14 октября 2025.
- Тема Z, Device-bound Attestations, v1.0, дискуссионный документ ARF, 29 сентября 2025.
- OpenID for Verifiable Presentations 1.0, OpenID Foundation.
- Регламент (ЕС) 2024/1624 (AMLR), EUR-Lex, Официальный журнал от 19 июня 2024.
- Окончательный отчет, проект RTS по статье 28(1) AMLR, AMLA, 30 сентября 2026 (окончательный проект, не имеет силы закона).
- Регламент (ЕС) 2016/679 (GDPR), EUR-Lex.
- Регламент (ЕС) 2024/1689 (AI Act), EUR-Lex.
- Директива (ЕС) 2015/2366 (PSD2), EUR-Lex.
- Делегированный регламент (ЕС) 2018/389, EUR-Lex.
- Отчет о мошенничестве с платежами за 2025 год, EBA и ECB, декабрь 2025.
- Совместный отчет EBA и ECB о мошенничестве с платежами, пресс-релиз, ECB, 15 декабря 2025.
- Remote Identity Proofing: Attacks and Countermeasures (удаленное подтверждение личности: атаки и меры противодействия), ENISA.
- TechDispatch о кошельках цифровой идентичности, Европейский инспектор по защите данных, декабрь 2025.
- ETSI TS 119 461 v2.1.1, подтверждение личности субъектов доверительных услуг, ETSI.
- Architecture and Reference Framework v3.0.0, глава 4, высокоуровневая архитектура, Европейская комиссия.
- Биометрическая аутентификация, документация Didit.
- Проверка живости (liveness), документация Didit.
- Сравнение лиц 1:1 (Face Match), документация Didit.
- Цифровые ID-кошельки, документация Didit.
- Поиск по лицу (Face Search), документация Didit.
- Сети (Networks), документация Didit.
- Создание усиленной проверки, документация Didit.
- Мониторинг транзакций, документация Didit.
- Хранение данных, документация Didit.
Кошелек отвечает на вопрос, кому принадлежат учетные данные, и ваша работа с рисками начинается с этого ответа. Для ситуаций, где нужен сам человек, см. Биометрическая аутентификация. О готовности к кошелькам см. нашу страницу EUDI Wallet и Проверка eID.
Проверяйте человека, а не только ключ
Добавьте проверку живости и сравнение лиц там, где этого требует ваша оценка рисков.
Похожие статьи
- Трансграничный приём EUDI Wallet: одна интеграция для всего ЕС
- Готовность к EUDI Wallet: политики и меры контроля для регулируемых организаций
- Привязка к держателю в EUDI Wallet: что на самом деле доказывает предъявление
- Интеграция EUDI Wallet: как выбрать подход (руководство 2026)
- Проверка личности по FINTRAC в 2026 году: методы, правила, C-12
- Закон 25 Квебека и биометрия: руководство по верификации личности (2026)