Интеграция EUDI Wallet: как выбрать подход (руководство 2026)
Интеграция EUDI Wallet: сравнение четырёх подходов, что посредник может и не может делать по статье 5b(10), модель сертификатов после 2026/1730, вопросы поставщику и что остаётся за вами.
Кратко
Интеграция с EUDI Wallet начинается с одного решения, а не с технического проекта: кто выступает перед кошельком как доверяющая сторона, вы или посредник, действующий от вашего имени.[1][6]
- Вы всегда регистрируетесь в своем государстве-члене и никогда не вправе запрашивать больше, чем зарегистрировали.[1]
- Посредник считается доверяющей стороной и не вправе хранить данные о содержании транзакции. Это ограничивает то, что поставщик в этой роли может хранить для вас.[1]
- Частные компании, обязанные применять строгую аутентификацию, принимают кошелёк до 24 декабря 2027 года (наш расчет). Микропредприятия и малые предприятия освобождены.[1]
Для European Digital Identity (EUDI) Wallet этой зимой наступает реальный срок: каждое государство-член обязано предоставить кошелек до 24 декабря 2026 года, и в тот же день начинают применяться правила реестра для компаний, которые его принимают.[1][2] Для большинства команд вопрос сместился с «что это такое» на «как к нему подключиться».
В этом руководстве сравниваются четыре пути интеграции с EUDI Wallet, разделяется то, что можно делегировать, и то, что остается за вами, и каждая функция сопоставляется с нормой, на которой она основана. Анализ опирается на действующее право и версию 3.0.0 Architecture and Reference Framework (ARF), технической схемы, включая изменения июля 2026 года в отношении посредников.[3][6]
Если сначала нужны основы, прочитайте Доверяющая сторона EUDI Wallet: регистрация, сертификаты и обязанности и руководство Верификатор OpenID4VP; о праве: eIDAS 2: разъяснение.
Продолжайте верифицировать пользователей, пока принимаете решение
Didit уже сегодня проводит проверки через национальные eID и по документам в одном процессе, а прием EUDI Wallet появится в ближайшее время. Начните бесплатно или свяжитесь с нами, чтобы обсудить вашу европейскую аудиторию.
Что на самом деле должна делать интеграция с EUDI Wallet
Задач пять. Кто-то регистрирует сервис. Кто-то хранит ключи, подтверждающие, кто направляет запрос. Кто-то отправляет подписанный запрос. Кто-то проверяет полученный ответ. Кто-то ведет учет. Каждый путь распределяет эти задачи по-своему.
ARF называет систему, которая взаимодействует с кошельками, экземпляром доверяющей стороны (Relying Party Instance). В ARF она проходит аутентификацию с помощью сертификата доступа, закрытый ключ которого «надежно хранится в аппаратных средствах экземпляра доверяющей стороны».[6] Второй объект, регистрационный сертификат, указывает одно предполагаемое использование и зарегистрированные для него атрибуты.[1][6] Доверяющая сторона включает такой сертификат в каждый запрос на предъявление, по значению.[7]
Место доверяющей стороны в экосистеме. Источник: EUDI Wallet Architecture and Reference Framework, Европейская комиссия, CC BY 4.0.
Два изменения 2026 года меняют решение о закупке. Имплементационный регламент (ЕС) 2026/1730 от 15 июля 2026 года изменил правила регистрации. Теперь государства-члены должны уполномочить как минимум один удостоверяющий центр выдавать регистрационные сертификаты, а выдача должна быть автоматизирована.[3] Он также добавил пункт 16 Приложения I, связь с доверяющей стороной, которую обслуживает посредник. Согласно Приложению II, эту связь должен содержать сертификат доступа.[3]
Даты, определяющие ваш план
- 11 августа 2026Правила изменены2026/1730 вступает в силу, наш расчет: через 20 дней после публикации 22 июля.
- 24 декабря 2026Срок для кошельковНачинают применяться правила регистрации 2025/848.
- 10 июля 2027Применение AMLRПравила об аутсорсинге и хранении записей применяются к большинству обязанных субъектов.
- 24 декабря 2027ПриемСт. 5f(2), частные доверяющие стороны (наш расчет).
- 11 августа 2028Проверка сертификатовКошельки должны аутентифицировать и проверять регистрационные сертификаты.
Даты взяты из Регламента (ЕС) № 910/2014, 2025/848, 2026/1730, 2026/1731 и AMLR. Дату 24 декабря 2027 года мы рассчитали сами: 36 месяцев после вступления в силу имплементационных актов (опубликованы 4 декабря 2024 года, вступили в силу через 20 дней).[1][2][3][4][5][9]
Правовое основание содержится в статье 5f(2). Она охватывает частные доверяющие стороны, которые по закону или договору обязаны применять строгую аутентификацию пользователя для онлайн-идентификации, в сферах, включая банковское дело, энергетику и здравоохранение, и применяется «только по добровольному запросу пользователя».[1] На очень крупные онлайн-платформы распространяется отдельная обязанность по статье 5f(3), без отдельной даты в тексте.[1] Полный календарь: все сроки EUDI Wallet.
Четыре пути интеграции с EUDI Wallet
В таблице пути распределены по тому, кто взаимодействует с кошельком и в какой правовой роли. Трудозатраты и уровень контроля указаны по нашей оценке и не являются правовым критерием.
| Маршрут | Кто взаимодействует с кошельком | Сертификаты | Контроль | Трудозатраты | Обычно подходит |
|---|---|---|---|---|---|
| Создать собственный верификатор | Вы, как доверяющая сторона | Сертификаты доступа и регистрационные сертификаты у вас | Наивысший | Наивысшие: ключи, доверенные списки, тестирование кошельков | Банки и крупные платформы с собственной командой по безопасности |
| Посредник доверяющей стороны | Посредник, от вашего имени | Сертификаты доступа у него, регистрационные сертификаты оформляются на вас | Средний: определяется договором | Низкие по протоколу, но добавляется надзор за новым поставщиком | Компании, которым нужен только кошелёк |
| Платформа идентификации или оркестрации | Зависит от продукта: уточните, какая роль применяется | Обычно как у посредника на участке кошелька | Средние, по нескольким методам | Самый быстрый запуск, самая глубокая зависимость | Компании, которым нужны кошелёк, eID и проверка документов в одном потоке |
| Инструменты для провайдеров кошельков или доверительных услуг | Зависит: инструменты являются продуктом, а не ролью | Различается | Зависит от применения | Зависит от сценария использования | Подписи, выпуск аттестаций, отдельная потребность наряду с верификацией |
Путь 1: создать собственный верификатор
Вы управляете экземпляром доверяющей стороны (Relying Party Instance). Европейская комиссия публикует эталонную реализацию с руководствами по созданию удалённого верификатора и верификатора для проверки вблизи, а её верификационный endpoint распространяется по лицензии Apache 2.0.[14][15] На вас по-прежнему остаются ключи в аппаратном хранилище, сертификат для каждого экземпляра и сервиса, загрузка доверенных списков и обновления при изменении спецификаций.[6][7]
Подходит при больших объёмах проверок через кошелёк или если служба управления рисками не допускает, чтобы третья сторона видела предъявленные атрибуты.
Путь 2: посредник доверяющей стороны
Статья 5b(10) задаёт этой модели правовую форму, остальное раскрывает ARF. Посредник является «особым классом доверяющей стороны», который выполняет задачи доверяющей стороны от её имени, а клиенту «не потребуется сертификат доступа».[6] Регистрироваться вам всё равно нужно: посредник обязан обеспечить, чтобы каждый клиент был зарегистрирован в государстве-члене, где этот клиент учреждён.[7]
Путь 3: платформа идентификации или оркестрации
«Платформа», коммерческий термин, в статье 5b(10) его нет. В части работы с кошельком платформа либо является посредником со всеми вытекающими ограничениями, либо размещает ваш собственный экземпляр. Её ценность в том, что несколько методов подключаются через одну интеграцию. Риск состоит в допущении, что всё, что платформа делает для документов, например хранение доказательств в течение многих лет, распространяется и на кошельки. Это может быть не так.
Открытый вопрос
Является ли посредником поставщик, который лишь размещает ваш экземпляр под вашим собственным сертификатом доступа? Определение в ARF, лицо, «взаимодействующее с Wallet Units от их имени», допускает широкое толкование, и мы не нашли текста, который решал бы этот вопрос.[6] Задайте этот вопрос своему юристу и регистратору до подписания договора.
Путь 4: инструменты поставщиков кошельков или доверительных услуг
Поставщики кошельков и поставщики доверительных услуг тоже продают программное обеспечение. Оно полезно, если вам нужны квалифицированные подписи или вы хотите выпускать аттестации. Правила регистрации указывают эти виды деятельности как отдельные права, например QEAA_Provider и QCert_for_ESig_Provider, наряду с Service_Provider для обычного бизнеса.[2] Если инструмент взаимодействует с кошельками от вашего имени, проверьте его на соответствие правилам для посредников.
Что остаётся за вами и что можно передать
Статья 5b(10)Регламент (ЕС) № 910/2014
«Посредники, действующие от имени доверяющих сторон, считаются доверяющими сторонами и не хранят данные о содержании транзакции».
Источник: EUR-Lex, консолидированный текст[1]
То, что посредник «считается» доверяющей стороной, не снимает с вас ваших собственных обязанностей. Статья 5b(9) возлагает на доверяющие стороны ответственность за проведение процедуры аутентификации и проверки данных идентификации личности и аттестаций, которые они запрашивают.[1] ARF оставляет распределение обязанностей договору: «посредник и любая доверяющая сторона, пользующаяся его услугами, должны согласовать, какие проверки будет проводить посредник».[6] Регистратор может запросить подтверждение отношений, например подписанный договор или поручение.[6]
| Задача | Может ли это сделать поставщик | Норма |
|---|---|---|
| Определить цель использования и данные | Нет: это ваше решение | Ст. 5b(2)(c), 5b(3)[1] |
| Быть зарегистрированным в своём государстве-члене | Оформление документов да, если регистратор это допускает; запись в реестре остаётся вашей | Ст. 5b(1)[1], RPI_03[7] |
| Поддерживать точность записи в реестре | Может помочь; обязанность остаётся вашей | Ст. 5b(6)[1] |
| Держать сертификаты доступа и отправлять запросы | Да, в качестве посредника | ARF §6.6.5[6] |
| Проверять подлинность, отзыв, привязку к устройству и пользователю | Да, если это согласовано | RPI_09[7] |
| Выберите регистрационный сертификат для каждого запроса | Его указываете вы | RPI_05[7] |
| Отвечать на запросы пользователей об удалении данных | Только поддержка; ваши контактные данные указаны в вашем регистрационном сертификате, и кошельки направляют запросы на удаление вам | RPRC_11[7], 2024/2982 статья 6[4] |
| Определять профиль риска и деловые отношения | Нет для обязанных субъектов по AMLR, за исключением одного отступления для фондов | AMLR статья 18(3), 18(7)[9] |
У регулируемых компаний есть еще три уровня требований. Регламент о противодействии отмыванию денег (AMLR) позволяет обязанным субъектам передавать задачи на аутсорсинг, но они должны заранее уведомить надзорный орган и остаются «в полной мере ответственными».[9] Digital Operational Resilience Act оставляет финансовые организации «полностью ответственными» по договорам в сфере ИКТ.[11] Общий регламент по защите данных (GDPR) требует привлекать обработчиков, предоставляющих достаточные гарантии.[10] Ни в одном изученном нами тексте не сказано, является ли посредник обработчиком или контролером, поэтому зафиксируйте свой анализ в договоре.
Как работает посредник и почему важно количество сертификатов
Сравнивает оба идентификатора
Показывает пользователю ваше название
Выполняет согласованные проверки
Удаляет предъявление
Предъявление через посредника, упрощенная схема по ARF §6.6.5 и Topic 52.[6][7]
Во-первых, пользователь видит ваше торговое наименование, а не название поставщика, однако кошелёк регистрирует посредника в журнале, так что пользователь может найти его позже.[6] Во-вторых, кошелёк сравнивает идентификаторы в регистрационном сертификате с идентификаторами в сертификате доступа, и при несовпадении транзакция может быть остановлена.[6] В-третьих, интерфейс между вами и посредником не входит в сферу действия ARF, и ARF не требует сквозного шифрования атрибутов, поэтому поставщик вполне может видеть каждый атрибут.[6]
Главное здесь арифметика ARF. Имплементационный регламент 2026/1730 добавляет в регистрационные данные связь с обслуживаемой доверяющей стороной, а в ARF v3.0.0 эту привязку к обслуживаемой доверяющей стороне несет сертификат доступа, поэтому посредник «получает отдельный набор сертификатов доступа для каждой из доверяющих сторон, которые он обслуживает».[3][6] Поставщик, который до июля 2026 года описывал модель с общим сертификатом, должен показать вам свою новую архитектуру. Масштаб концентрирует риск: если удостоверяющий центр сертификатов доступа вашего посредника приостановлен, его сертификаты отзываются, и вы не можете запрашивать атрибуты, «даже если его регистрация по-прежнему действительна».[7] Вам придется перейти к другому посреднику или ждать, поэтому план выхода является операционным контролем.
Аутентификация доверяющей стороны, шаг, который должен выполняться на любом пути. Источник: EUDI Wallet Architecture and Reference Framework, European Commission, CC BY 4.0.
Проблема доказательств: удалять или хранить
Нормы, требующие удаления
Посредник и верификатор
- Никаких хранимых данных о содержании транзакции (статья 5b(10))
- Удалить «полностью и немедленно» после пересылки (RPI_10)
- Удалить значения подписей, соли, хеши и временные метки, когда они больше не нужны (OIA_16)
Регламент и приложение 2 к ARF[1][7]
Нормы, которые требуют хранить
Обязанный субъект
- Хранить информацию, полученную с помощью средств электронной идентификации (статья 77(1)(a))
- Хранить её 5 лет
- Показать надзорному органу, что переданная на аутсорсинг работа снижает ваши риски (статья 18(2))
AMLR, с 10 июля 2027[9]
OIA_16 предписывает экземпляру доверяющей стороны удалять все уникальные элементы, в том числе подпись поставщика аттестации, и не передавать их «доверяющей стороне или любой другой стороне».[7] Поэтому обещание хранить подписанный ответ кошелька как журнал аудита нужно проверять, кто бы из поставщиков его ни давал. ARF является рамочным документом, а не правовым актом, и не определяет «больше не нужны» применительно к обязанности хранить данные 5 лет. Обратитесь к своему юристу и, если вы поднадзорны, к своему надзорному органу.
Ниже приведена предлагаемая нами схема. Её нужно проверить, это не норма.
| Запись | Кто хранит | Основание |
|---|---|---|
| Атрибуты, необходимые для надлежащей проверки клиента | Вы, в своей системе | AMLR, статья 77[9] |
| Журнал проверки: время, способ, выполненные проверки, результат, использованный сертификат | Вы, без уникальных элементов | AMLR, статья 18(2), наше предложение[9] |
| Фотография, если она вообще запрашивается | Не хранится, за исключением случаев, когда это необходимо или предусмотрено законом | Приложение 2 к ARF[7] |
| Подпись, соли, хеши | Ваш открытый правовой вопрос | OIA_16[7] |
| Содержание транзакции у посредника | Никто: удаляется сразу | Статья 5b(10)[1], RPI_10[7] |
Какие возможности должен продемонстрировать поставщик и на какой норме основана каждая из них
Используйте эту таблицу как техническое приложение к запросу предложений или для собственной разработки.
| Этап | Возможность | Норма или стандарт |
|---|---|---|
| Настройка | Регистрационные данные, включая связь с посредником | 2025/848, Приложение I, пункты 14–16[2][3]; TS5 usesIntermediaries[8] |
| Настройка | Сертификаты доступа для каждого экземпляра, сервиса и клиента, ключи хранятся в аппаратном модуле | ARF §3.11.3[6]; ETSI TS 119 411-8 через 2026/1730[3] |
| Настройка | Якоря доверия из доверенных списков и списков доверенных субъектов с регулярным обновлением | OIA_12, OIA_15a[7] |
| Запрос | Жёсткая блокировка любого атрибута за пределами зарегистрированного использования | Статья 5b(3)[1]; 2025/848, статья 9(2)(c)[2] |
| Запрос | Регистрационный сертификат для текущего использования, передаваемый по значению в каждом запросе | RPRC_19[7] |
| Запрос | Рекомендуется: оба профиля протокола, OpenID4VC-HAIP и ISO/IEC mdoc | Приложение 2026/1731 к 2024/2982[5] |
| Проверка | Подпись эмитента, по типу аттестации | OIA_12 – OIA_15[7] |
| Проверка | Проверка отзыва, а также письменная политика на случай неизвестного статуса | VCR_13, VCR_14[7] |
| Проверка | Привязка к устройству и выбранный метод привязки к пользователю | OIA_17, ARF §6.6.3.9[6][7] |
| После | Удаление уникальных элементов | OIA_16[7] |
| После | Запросы на удаление и контакты вашего органа по защите данных | RPRC_11, RPRC_12[7]; 2024/2982 ст. 6, 7[4] |
| Подтверждение | Опубликованные результаты тестов | Самосертификация OpenID Foundation[12] |
7 августа 2026 OpenID Foundation открыла свои тесты на соответствие OpenID for Verifiable Presentations (OpenID4VP) для самосертификации, и верификаторы могут проходить их бесплатно. Публикация самосертификации платная.[12] Functional Conformance Assessment Framework Комиссии всё ещё находится «в активной разработке», и первой тестируемой в ней системой является Wallet Solution, поэтому пока не стоит ждать от неё отметки для доверяющей стороны.[13] Что касается форматов, учётные данные с данными идентификации личности (PID) должны выдаваться и в mdoc, и в SD-JWT VC, но другие аттестации проверяйте по одной. Наше сравнение форматов объясняет разницу.[7]
Иллюстративные экраны из руководства по дизайну, а не национальный кошелёк: что пользователь проверяет перед передачей данных. Адаптировано (обрезано) из EUDI Wallet Architecture and Reference Framework, приложение 5, Европейская комиссия, CC BY 4.0.[16]
Маршрутизация через кошелёк и без него
Статья 5a(15) гласит, что использование кошелька «является добровольным» и что «должна сохраняться возможность доступа к государственным и частным услугам с помощью других существующих средств идентификации и аутентификации».[1] Поэтому кошелёк никогда не может быть вашим единственным входом. Статья 22(6) AMLR также допускает документы, удостоверяющие личность, или электронную идентификацию существенного или высокого уровня.[9]
1Предложите методы для этой страны
Выбор делает пользователь. Запрос к кошельку запускается только по запросу пользователя.
Предъявление из кошелька успешно и проходит ваши проверки
Продолжить
Добавьте то, чего кошелёк не даёт.
Примените свою политику
Письменный анализ рисков определяет, принять или отказать.
Направить дальше
Национальная eID, затем документ с проверкой живости.
2Проверка по спискам, оценка риска, решение
Одна и та же запись, каким бы методом она ни была получена.
Схема маршрутизации, которая оставляет открытым каждый вход. Путь со статусом «неизвестен» регулируется VCR_14.[1][7]
Портрет может стать обязательным элементом данных PID только с 11 августа 2028 года, и государства-члены могут разрешить пользователям отказаться от него, поэтому схема, основанная на сверке лица с данными из кошелька, будет работать не всегда.[5] В нашей статье о привязке к владельцу разобрано, когда достаточно одного кошелька, а когда нужно добавить проверку живости. Национальные различия в полях и идентификаторах описаны в статье о приёме 27+ национальных кошельков, а статус внедрения приведён в трекере по странам. Для онбординга в регулируемых секторах читайте статью AMLR и EUDI Wallet.
Спроектируйте маршрутизатор до появления кошелька
Этот маршрут можно построить уже сейчас на существующих методах. Верификация личности с Didit включает съёмку документа, чтение NFC-чипа, проверку живости и сверку лица, с ветвлением по стране и результату.[18][19]
Выбор пути по типу компании
Ст. 5f(2): вы обязаны применять строгую аутентификацию пользователей и не относитесь к микро- или малым предприятиям
Обязанность принимать
Планируйте запуск к 24 декабря 2027 года.
По желанию
Если только к вам как к очень крупной онлайн-платформе не применяется ст. 5f(3). При приёме кошельков требуется регистрация.
Вы можете сами обеспечивать хранение ключей, работу с доверенными списками и тестирование кошельков
Собственная разработка
Или сохраните собственную разработку как запасной выход при уходе от поставщика.
Используйте поставщика
Только посредник или платформа, если вам нужны и другие методы.
Это отправная точка: решение принимают ваши юристы с учётом ваших объёмов.[1]
| Вы | Исходный вариант | На что обратить внимание |
|---|---|---|
| Банк или платёжная организация | Собственная разработка или посредник с возможностью собственной разработки | Статья 18 AMLR и Digital Operational Resilience Act[9][11] |
| Финтех- или криптокомпания | Платформа или посредник | Проверьте, применяется ли ст. 5f(2); сроки хранения[1][9] |
| Очень крупная онлайн-платформа | Собственная разработка или посредник | Статья 5f(3), минимальный объём данных[1] |
| Сервис с возрастными ограничениями или небольшая компания | Поставщик, если вы решите принимать кошелёк | Запрашивайте только то, что нужно; не отказывайте в использовании псевдонима, если идентификация не требуется[1] |
| Группа в нескольких государствах-членах | Одна архитектура, несколько регистраций | Каждое юридическое лицо регистрируется там, где оно учреждено[1] |
| Компания без учреждения в ЕС | Сначала получите консультацию | В изученных нами текстах такой путь не описан; Статья 5b(1) привязана к месту учреждения[1] |
Что запросить у поставщика в письменной форме
Правила о реестре применяются с 24 декабря 2026, поэтому запрашивайте запись в реестре, стоящую за любым заявлением о зарегистрированном сервисе.[2]
| Тема | Что получить в письменной форме | Тревожный сигнал |
|---|---|---|
| Правовая роль | Его роль в части взаимодействия с кошельком, у какого регистратора он регистрируется и когда | «Мы платформа, к нам это не относится» |
| Ваша регистрация | Кто подаёт заявку, с каким мандатом и кто её обновляет | Запись была бы оформлена на имя поставщика |
| Сертификаты | Модель для каждого клиента начиная с 2026/1730 | Один общий сертификат для всех клиентов |
| Удостоверяющий центр | Какие центры он использует и каков план на случай приостановки деятельности одного из них | Нет второго источника, нет плана выхода |
| Выполняемые проверки | Перечень: подлинность, отзыв, привязка к устройству и пользователю | «Мы проверяем кошелёк» |
| Видимость данных | Видит ли он атрибуты в открытом виде | Нет ответа |
| Удаление | Как выполняется и подтверждается удаление после пересылки | Предъявления хранятся «для вашего аудита» |
| Ваши записи | Что попадает в вашу систему и в каком виде | Доказательства есть только внутри его портала |
| Ограничения объема | Техническая блокировка незарегистрированных атрибутов | Обещание аккуратно все настроить |
| Тестирование | Опубликованные результаты и кошельки, протестированные с указанием названия и версии | «Работает со всеми кошельками» |
| Выход | Переход к другому посреднику без новых последствий для пользователей | Регистрация, привязанная к поставщику |
Что сделать в этом месяце
- Письменно подтвердите для каждого юридического лица, применяется ли к нему статья 5f(2) или 5f(3).[1]
- Перечислите все сценарии использования и минимальный набор атрибутов для каждого.
- Определите своего регистратора и его национальную политику регистрации.[2]
- Обсудите с юристом OIA_16 в сопоставлении с вашими обязанностями по хранению данных.[7][9]
- Пропишите политику на случай неизвестного статуса отзыва.[7]
- Подготовьте уведомление надзорному органу, если обязанный субъект будет передавать функции на аутсорсинг.[9]
- Постройте резервный сценарий на основе методов, которые есть у вас сегодня.
В нашей сопутствующей статье о политиках и мерах контроля для EUDI Wallet эти шаги сведены в матрицу контролей с ответственными лицами и доказательствами.
Как Didit помогает с интеграцией EUDI Wallet
Прием EUDI Wallet появится в ближайшее время, дата и цена пока не объявлены.[17] Наш подход описан на странице решения EUDI Wallet, где он сформулирован так: «Интегрируйте сегодня и сохраните интеграцию, когда появится кошелек».
Остальная часть процесса, описанного в этом руководстве, доступна уже сегодня. Didit поддерживает MitID, BankID Sweden, Finnish Trust Network, Smart-ID и Mobile-ID наряду со съемкой документов, а в качестве резервного варианта настраивается проверка по документу.[18] См. верификацию eID. Сценарии ветвятся по стране и результату, вебхуки подписываются, а срок хранения настраивается от 1 месяца до 10 лет.[19][20][21] Didit выступает обработчиком данных, а вы остаетесь контролером.[22] У Didit есть отчеты SOC 2 Type 1 и Type 2, сертификация ISO/IEC 27001:2022 и тестирование iBeta Level 1 на обнаружение атак предъявления.[23] Цены см. на странице тарифов.
Что предоставляет Didit
- Национальные eID и проверка документов в одном workflow
- Ветви маршрутизации и резервная проверка по документу
- Подписанные вебхуки и настраиваемый срок хранения
Остается за вами
- Ваша регистрация в качестве доверяющей стороны и заявленные цели использования
- Оценка рисков, политики и решение по клиенту
- Ваши решения о сроках хранения и правовой анализ
Выстройте маршрутизацию до появления кошелька
Начните с национальных eID и документов в одном workflow.
Главное
- Реальный выбор состоит в том, кто выступает перед кошельком доверяющей стороной: вы или посредник.
- Согласно статье 5b(10), посредник считается доверяющей стороной и не вправе хранить данные о содержании транзакции.
- 2026/1730 указывает обслуживаемого клиента в сертификате доступа. ARF v3.0.0 предоставляет посреднику отдельный набор для каждого клиента.
- Правила удаления противоречат обязанностям по хранению: урегулируйте вопрос OIA_16 и статьи 77 AMLR с юристом.
- Статья 5a(15) сохраняет доступность других средств, поэтому сначала спроектируйте маршрутизацию.
Часто задаваемые вопросы
Что такое платформа интеграции EUDI Wallet?
Это сервис, который подключает ваше приложение к EUDI Wallet, часто наряду с другими методами идентификации. Юридического значения этот термин не имеет. На участке взаимодействия с кошельком поставщик является либо посредником, либо хостингом вашего собственного экземпляра, поэтому уточните, какая роль применяется.[1][6]
Как интегрировать EUDI Wallet в мой сервис?
Зарегистрируйтесь в своем государстве-члене, определите каждую заявленную цель использования и ее атрибуты, затем выберите путь: собственный верификатор, посредник, платформа или специализированный инструментарий. Запросы подписываются сертификатом доступа и содержат регистрационный сертификат.[2][7]
Что такое посредник доверяющей стороны?
Это физическое лицо или компания, которые взаимодействуют с кошельками от имени доверяющих сторон. Статья 5b(10) признает его доверяющей стороной и запрещает ему хранить данные о содержании транзакции.[1][6]
Нужно ли мне регистрироваться, если я пользуюсь посредником?
Да. ARF обязывает посредника обеспечить регистрацию каждого клиента в государстве-члене, где этот клиент учрежден. Порядок определяет регистратор, и он может разрешить посреднику подать заявку при наличии подтверждения отношений.[6][7]
Может ли мой поставщик хранить подписанный ответ кошелька в качестве доказательства?
Считайте это открытым вопросом. Посредник не вправе хранить содержание транзакции, а требование ARF OIA_16 предписывает верификаторам удалять значения подписи, как только они больше не нужны. Регулируемым компаниям следует урегулировать этот вопрос с учетом статьи 77 AMLR вместе с юристом.[1][7][9]
Когда частные компании обязаны принимать EUDI Wallet?
К 24 декабря 2027 года по нашему подсчету 36 месяцев, если закон или договор обязывает их использовать строгую аутентификацию пользователя для онлайн-идентификации. Микро- и малые предприятия освобождены, а принятие осуществляется только по добровольному запросу пользователя.[1]
Может ли EUDI Wallet заменить проверку документов?
Для конкретного клиента подходящий кошелёк может заменить проверку документа, но не как единственный путь: использование кошелька добровольно, и в соответствии со статьёй 5a(15) другие средства должны оставаться доступными. AMLR допускает удостоверения личности наряду с электронной идентификацией, поэтому предусмотрите оба варианта.[1][9]
Принимает ли Didit EUDI Wallet уже сейчас?
Нет. Приём EUDI Wallet появится в ближайшее время, дата и цена пока не определены. Сегодня Didit использует национальные eID и проверку документов в одном рабочем процессе.[17][18]
Источники
- Регламент (ЕС) № 910/2014, консолидированный текст от 18 октября 2024 года, EUR-Lex.
- Имплементационный регламент Комиссии (ЕС) 2025/848, регистрация доверяющих сторон кошельков, EUR-Lex.
- Имплементационный регламент Комиссии (ЕС) 2026/1730 от 15 июля 2026 года, EUR-Lex.
- Имплементационный регламент Комиссии (ЕС) 2024/2982, протоколы и интерфейсы, EUR-Lex.
- Имплементационный регламент Комиссии (ЕС) 2026/1731 от 15 июля 2026 года, EUR-Lex.
- Architecture and Reference Framework v3.0.0, Европейская комиссия, июль 2026 года.
- ARF v3.0.0, Приложение 2, высокоуровневые требования по темам, Европейская комиссия.
- Техническая спецификация 5, форматы и API для регистрации доверяющих сторон, Европейская комиссия.
- Регламент (ЕС) 2024/1624 (AMLR), EUR-Lex.
- Регламент (ЕС) 2016/679 (GDPR), EUR-Lex.
- Регламент (ЕС) 2022/2554 (Digital Operational Resilience Act), EUR-Lex.
- Тесты на соответствие OpenID4VP и OpenID4VCI завершены и открыты для самосертификации, OpenID Foundation, 7 августа 2026 года.
- Functional Conformance Assessment Framework, проект EUDI Wallet.
- Документация эталонной реализации EUDI Wallet, Европейская комиссия.
- Репозиторий EUDI verifier endpoint, Apache License 2.0.
- ARF v3.0.0, Приложение 5, руководство по проектированию сценариев обмена данными, Европейская комиссия.
- EUDI Wallet, страница решения Didit.
- Цифровые ID-кошельки, документация Didit.
- Конструктор рабочих процессов, документация Didit.
- Вебхуки, документация Didit.
- Хранение данных, документация Didit.
- Безопасность и комплаенс, документация Didit.
- Сертификаты, документация Didit.
Путь, который вы выбираете сегодня, должен пережить смену поставщика, запоздавший национальный кошелёк и проверку соблюдения сроков хранения. Следите за внедрением и за тем, как Didit подходит к приёму кошельков, на странице решения EUDI Wallet.
Подготовьте процесс идентификации к любому пути
Проверяйте пользователей по национальным eID и документам уже сегодня, в одном рабочем процессе.
Похожие статьи
- Трансграничный приём EUDI Wallet: одна интеграция для всего ЕС
- Готовность к EUDI Wallet: политики и меры контроля для регулируемых организаций
- Привязка к держателю в EUDI Wallet: что на самом деле доказывает предъявление
- Интеграция EUDI Wallet: как выбрать подход (руководство 2026)
- Проверка личности по FINTRAC в 2026 году: методы, правила, C-12
- Закон 25 Квебека и биометрия: руководство по верификации личности (2026)