Руководство для верификатора OpenID4VP: приём EUDI Wallet

Последняя проверка: 5 октября 2026 г. · Не является юридической консультацией

OpenID4VP позволяет сайту или приложению попросить кошелёк подтвердить сведения о человеке, например имя или дату рождения. Верификатор указывает, какие учётные данные и утверждения ему нужны. Пользователь даёт согласие в кошельке. Кошелёк возвращает предъявление, которое верификатор проверяет криптографически. Согласно самой спецификации, она «определяет протокол запроса и предъявления учётных данных (Credentials)».^[1]

Это руководство для разработчиков, которые создают верификатор OpenID4VP для EUDI Wallet. В нём разобраны объект запроса, DCQL, режимы ответа, сценарии работы с устройствами, проверки SD-JWT VC и mdoc, правила HAIP в праве ЕС, типичные ошибки и среды для тестирования.

OpenID4VP простыми словами

OpenID4VP повторяет структуру запроса авторизации OAuth 2.0. Верификатор запрашивает тип ответа vp_token. Успешный ответ должен содержать параметр vp_token с предъявлениями.^[1] Обменивать код или токен доступа не нужно: данные приходят в самом ответе.

Кошелёк аутентифицирует доверяющую сторону и проверяет, что она запрашивает не больше, чем зарегистрировала. Затем он получает согласие пользователя и подписывает предъявление. После этого доверяющая сторона проверяет подпись эмитента, статус отзыва и привязку к устройству.^[3] Идентификационные данные лица (PID) выдаются в двух форматах: SD-JWT VC и ISO/IEC mdoc. Оба формата используют хеши с солью, поэтому пользователь может раскрыть одни атрибуты и скрыть остальные.^[5][3]

1. 10 июля 2025Окончательная спецификацияOpenID4VP 1.0 утверждён.
2. 22 июля 2026ПубликацияCIR 2026/1731 (принят 15 июля 2026 года) опубликован в Официальном журнале.
3. 23 июля 2026ARF v3.0.0Текущая версия архитектуры.
4. 24 декабря 2026КошелькиНе менее одного в каждом государстве-члене.
5. 24 декабря 2027ПриёмРегулируемые частные доверяющие стороны.

От окончательной спецификации до даты приёма частным сектором.^[2][3][4][5]

Как проходит обмен с верификатором OpenID4VP

OpenID4VP приводит эталонную схему для режима ответа direct_post. В этом режиме кошелёк отправляет ответ POST-запросом на серверную конечную точку, а не через браузер.^[1]

Эталонная схема direct_post из OpenID4VP 1.0, раздел 13.3, в упрощённом виде.^[1]

• Для каждого запроса генерируйте nonce длиной «не менее 16 свежих криптографически случайных байтов».
• Передайте request-id от response endpoint в кошелёк как state.
• После того как кошелёк отправит ответ, верните redirect URI с новым response_code.
• Получите VP Token по transaction-id и этому коду, затем проверьте nonce.

response_code защищает от фиксации сессии, когда злоумышленник перенаправляет ваш запрос в кошелёк жертвы. В спецификации отмечено, что при работе между разными устройствами он не помогает, и для таких случаев рекомендованы дополнительные механизмы.^[1]

Объект запроса OpenID4VP и идентификаторы клиента

client_id начинается с Client Identifier Prefix, который сообщает кошельку, как аутентифицировать проверяющую сторону.^[1] Крупные запросы передаются по ссылке: кошелёк загружает подписанный объект запроса по request_uri. Для QR-кодов спецификация рекомендует direct_post с request_uri, поскольку запрос «может не поместиться в QR-код».^[1]

Префиксы идентификатора клиента (Client Identifier Prefixes), OpenID4VP 1.0, раздел 5.9.^[1]

Для верификаторов EUDI префикс определяет право ЕС: конечный сертификат «для использования с префиксом идентификатора клиента x509_hash должен быть сертификатом доступа RP, как указано в ETSI TS 119 475», а один элемент verifier_info «должен включать регистрационный сертификат».^[5]

Запросы DCQL: запрашивайте то, что зарегистрировали

Digital Credentials Query Language (DCQL) это JSON-запрос, в котором указываются нужные вам учетные данные и атрибуты. Он содержит обязательный массив credentials и необязательный массив credential_sets. Каждому запросу учетных данных нужны id, format и объект meta.^[1] Пример SD-JWT VC из спецификации:^[1]

{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }

Для mdoc используется формат mso_mdoc, а meta содержит doctype_value.^[1] Для PID подставьте его тип и названия атрибутов. Обязательные атрибуты PID: фамилия, имя, дата рождения, место рождения и гражданство.^[7]

• require_cryptographic_holder_binding по умолчанию имеет значение true. Оставьте его: с ним кошелек возвращает доказательство привязки ключа.^[1]
• trusted_authorities лишь фильтрует то, что предлагает кошелек. Верификаторы «должны самостоятельно проверять, что эмитент полученной презентации является доверенным».^[1]
• Полагающиеся стороны «не должны запрашивать у пользователей никаких данных, кроме» тех, что они зарегистрировали, и кошелек это проверяет.^[4][3]

Режимы ответа OpenID4VP

Режим ответа определяет, как VP Token возвращается обратно. По умолчанию для vp_token используется fragment: токен передается во фрагменте URI перенаправления.^[1]

Режимы ответа в OpenID4VP 1.0.^[1]

При direct_post параметр response_uri обязателен, а redirect_uri должен отсутствовать, иначе кошелек возвращает invalid_request.^[1] Например, в документации EVO Wallet Молдовы описаны OpenID4VP 1.0 с direct_post.jwt в сценарии на одном устройстве, mdoc по ISO/IEC 18013-5 с профилем согласно OpenID4VC HAIP 1.0 и IETF Token Status List для отзыва.^[11]

Одно устройство, разные устройства и Digital Credentials API

В ARF перечислены поддерживаемые удаленные комбинации: OpenID4VP в сочетании с механизмом передачи на основе перенаправлений и пользовательских схем URI; OpenID4VP или ISO/IEC 18013-7 в сочетании с W3C Digital Credentials API; и, опционально, ISO/IEC 18013-7 с перенаправлениями и пользовательскими схемами URI.^[3]

Три способа, которыми кошелек получает запрос OpenID4VP.^[3][1][10]

В ARF указано, что пользовательские схемы URI «не рекомендуются для сценариев с разными устройствами», а в качестве альтернативы назван Digital Credentials API.^[3] Через API кошелек получает источник (origin) верификатора, аутентифицированный браузером, «что важно для устойчивости к фишингу».^[1] Спецификация W3C пока остается черновиком.^[9] Что пользователь видит на телефоне:

Пошаговая проверка представления SD-JWT VC

Представление SD-JWT VC содержит JWT, подписанный эмитентом, раскрытия, которые открыл пользователь, и Key Binding JWT. Проверяющая сторона «ОБЯЗАНА проверить каждое отдельное верифицируемое представление (Verifiable Presentation)» и отклонить любое представление с неверным nonce.^[1]

Проверки, которые проверяющая сторона выполняет для одного представления SD-JWT VC.^[1][3]

Подпись эмитента. ARF называет её первой среди проверок доверяющей стороны. Якоря доверия берутся из доверенных списков (Trusted Lists, ETSI TS 119 612) и списков доверенных субъектов (Lists of Trusted Entities, ETSI TS 119 602).^[3]

Раскрытия. Подписанные данные содержат массив дайджестов _sd; каждое раскрытие состоит из соли, имени утверждения и значения, например ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].^[1] Вычислите хеш каждого раскрытия и найдите его дайджест. Если совпадения нет, значит эмитент его не подписывал.

Key Binding JWT. Если требуется привязка к владельцу, кошелёк «ОБЯЗАН вернуть SD-JWT с Key Binding JWT». Его nonce должен совпадать с nonce вашего запроса, а aud с вашим Client Identifier или, при работе через Digital Credentials API, с вашим origin с префиксом origin:.^[1] Пример из спецификации:

{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }

Отзыв. Доверяющая сторона проверяет, что поставщик «не отозвал PID или аттестат».^[3] Например, молдавский EVO Wallet описывает для этого IETF Token Status List.^[11]

Кратко о предъявлении mdoc по ISO/IEC 18013-7

Для mdoc VP Token содержит закодированный в base64url DeviceResponse по ISO/IEC 18013-5, который «содержит подпись или MAC над SessionTranscript», включая структуру передачи (handover) OpenID4VP.^[1] Эта структура привязывает mdoc к вашему запросу так же, как nonce и audience привязывают SD-JWT VC.

В нашем сравнении SD-JWT VC и mdoc разобрано, когда подходит каждый формат.

Что профиль HAIP добавляет для верификаторов EUDI

High Assurance Interoperability Profile (HAIP) сужает набор вариантов OpenID4VP. ARF уже требует его для выпуска и указывает, что его использование «необходимо для обеспечения совместимости».^[3] Для предъявления CIR 2026/1731 устанавливает «профиль OpenID4VC-HAIP» и «профиль ISO/IEC-mdoc».^[5]

Сертификат регистрации «описывает предполагаемое использование доверяющей стороной и указывает атрибуты», которые она зарегистрировала. Регламент о регистрации применяется с 24 декабря 2026 года.^[6] Дата 11 августа 2028 года касается только проверки этого сертификата на стороне кошелька, а не регистрации.^[5] Германия формулирует это так: организация «получает сертификат доступа и сертификат регистрации для организации и сценария использования».^[12] Регистрация подробно описана в нашем руководстве для доверяющих сторон EUDI Wallet.

Типичные ошибки при создании верификатора OpenID4VP

Использование кошелька также добровольное: доступ «никоим образом не должен ограничиваться или ставиться в невыгодные условия» для тех, кто им не пользуется. Поэтому ваш верификатор работает наряду с другим способом.^[4]

Ресурсы для тестирования

Прежде чем тестировать с национальными кошельками, начните с эталонного ПО и тестов на соответствие.

• Запустите тесты на соответствие на conformance.eudi.dev.^[3]
• Изучите документацию эталонной реализации на docs.eudi.dev. Это документация, а не тесты.^[3]
• Изучите демонстрационный верификатор Национального банка Молдовы и его исходный код.^[13]
• Прежде чем полагаться на браузерный способ, ознакомьтесь с черновиком Digital Credentials API.^[9]

Даты для вашего плана тестирования см. в статье Сроки для кошелька EUDI в 2026 и 2027 годах.

Как Didit помогает с верификацией через кошелек EUDI

Прием кошелька EUDI скоро появится в Didit. Он есть в нашей дорожной карте, согласован с графиком внедрения кошелька EUDI и будет работать в том же процессе, который вы используете сегодня. А пока вы уже сейчас можете проверять людей удаленно.

• Сегодня в Didit работают пять национальных eID через цифровые ID-кошельки: MitID, BankID Sweden, Finnish Trust Network, Smart-ID и Mobile-ID. Подробнее: верификация eID.
• Если у человека нет eID, процесс переключается на проверку документов со считыванием NFC-чипа, проверкой liveness и сравнением лица. Настройка выполняется по каждой стране. Полная проверка KYC стоит $0.33.
• AML-скрининг выполняется в том же процессе и стоит $0.20.

Обязанности доверяющей стороны остаются за вами. В документации по кошелькам показано, как eID включаются для каждой страны.

Часто задаваемые вопросы

Источники

1. OpenID for Verifiable Presentations 1.0, OpenID Foundation, окончательная спецификация.
2. Окончательная спецификация OpenID for Verifiable Presentations 1.0 утверждена, OpenID Foundation, 10 июля 2025 г.
3. Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet на GitHub, релиз от 23 июля 2026 г.
4. Регламент (ЕС) 2024/1183 (eIDAS 2), EUR-Lex, Официальный журнал от 30 апреля 2024 г.
5. Имплементационный регламент Комиссии (ЕС) 2026/1731, EUR-Lex, Официальный журнал от 22 июля 2026 г.
6. Имплементационный регламент Комиссии (ЕС) 2025/848 о регистрации полагающихся сторон кошельков, EUR-Lex, Официальный журнал от 7 мая 2025 г.
7. Имплементационный регламент Комиссии (ЕС) 2024/2977 о данных идентификации лица, EUR-Lex, Официальный журнал от 4 декабря 2024 г.
8. ISO/IEC 18013-7, страница стандарта на сайте ISO.
9. Digital Credentials, черновик W3C.
10. Digital Credentials API выпущен, Chrome for Developers.
11. Руководство разработчика EVO Wallet, Правительство Молдовы, egov4dev.
12. Частые вопросы о кошельке EUDI, eudi-wallet.gov.de.
13. Демо-верификатор BNM, Правительство Молдовы, egov4dev.

OpenID4VP является той частью кошелька EUDI, с которой разработчики работают чаще всего, и она достаточно стабильна, чтобы строить на ее основе. Подход Didit к приему кошельков описан на странице решения для кошелька EUDI, а общая картина представлена в нашем обзоре eIDAS 2.