SD-JWT VC или mdoc (ISO/IEC 18013-5): сравнение форматов кошелька EUDI

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

SD-JWT VC представляет собой проверяемые учётные данные в виде подписанного JSON Web Token, утверждения которого можно раскрывать по одному. mdoc представляет собой мобильный документ в формате ISO/IEC 18013-5. Этот стандарт изначально написан для мобильных водительских удостоверений. Архитектура и эталонная структура (ARF) EUDI Wallet называет оба формата обязательными для кошельков. Третий формат, W3C Verifiable Credentials Data Model 2.0, указан как необязательный и «предназначен только для неквалифицированных EAA».^[1]

В этом руководстве оба формата сравниваются для разработчиков, которые создают проверяющую сторону. Источники: ARF v3.0.0, текст OpenID for Verifiable Presentations (OpenID4VP) 1.0 и Официальный журнал. PID означает данные идентификации личности (person identification data).

Что такое SD-JWT VC

ARF описывает «SD-JWT-based Verifiable Credentials» как формат данных и правила обработки для представления проверяемых учётных данных. Здесь SD-JWT «означает "Selectively Disclosable JSON Web Token"».^[1] Формат охватывает кодирование в JSON, механизм доказательства с выборочным раскрытием и необязательную привязку к устройству.^[1]

В OpenID4VP используется идентификатор формата dc+sd-jwt, а запрос указывает тип учётных данных через vct_values.^[4] Пример выданной полезной нагрузки из спецификации, сокращённый до двух из восьми дайджестов:^[4]

{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }

Что такое mdoc (ISO/IEC 18013-5)

ISO/IEC 18013-5 определяет атрибуты удостоверения, их кодирование в Concise Binary Object Representation (CBOR) и пространства имён, которые не дают идентификаторам пересекаться. Он также определяет механизм доказательства с выборочным раскрытием, обязательную привязку к устройству и обмен данными при очном предъявлении.^[1]

Специфична для вождения только модель данных удостоверения. ARF отмечает, что все остальные аспекты «являются общими и могут использоваться для любого другого типа аттестаций, включая PID».^[1]

OpenID4VP описывает такие учётные данные как «закодированные в CBOR и защищённые с помощью COSE_Sign1» и присваивает им идентификатор формата mso_mdoc. Запрос указывает тип документа через doctype_value.^[4]

Как работает выборочное раскрытие в каждом формате

Выборочное раскрытие позволяет пользователю передать одни атрибуты и скрыть остальные. При этом проверяющий всё равно проверяет подпись эмитента. eIDAS 2 требует, чтобы кошельки обеспечивали такую возможность.^[6] ARF называет механизм SD-JWT «хешами с солью» и указывает, что он «концептуально идентичен механизму, используемому для той же цели в [ISO/IEC 18013-5]».^[1]

Один механизм, две кодировки.^[1][4]

В примере выше массив _sd содержит дайджесты SHA-256. Каждое раскрытие представляет собой массив из случайного значения, имени утверждения и значения утверждения. Для имени это ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"], и его хеш стоит первым в списке дайджестов. Проверяющая сторона хеширует каждое полученное раскрытие и ищет этот дайджест в подписанных данных.^[4]

Утверждения адресуются по-разному. Для учётных данных в JSON путь к утверждению представляет собой список ключей, например ["address", "street_address"]. Для mdoc путь «содержит два элемента строкового типа»: пространство имён и идентификатор элемента данных, например ["org.iso.18013.5.1", "first_name"].^[4]

Привязка ключа и device engagement

Привязка к устройству связывает учётные данные с ключами в кошельке пользователя, поэтому их нельзя клонировать. Проверяющая сторона проверяет привязку: она просит кошелёк подписать свежие случайные данные закрытым ключом, который соответствует открытому ключу в учётных данных.^[1] Названия различаются: «В [ISO/IEC 18013-5] это называется „mdoc authentication“. В [SD-JWT VC] это называется „key binding“».^[1]

Привязка к устройству обязательна для PID в обоих форматах.^[1][4]

Для SD-JWT VC правило в OpenID4VP строгое. Если require_cryptographic_holder_binding имеет значение true (это значение по умолчанию), кошелёк «ДОЛЖЕН вернуть SD-JWT» вместе с Key Binding JWT. Утверждение nonce должно совпадать с nonce вашего запроса, а aud должно совпадать с вашим Client Identifier. Исключение составляет Digital Credentials API: там оно должно совпадать с вашим origin с префиксом origin:.^[4]

Device engagement есть только в mdoc. В сценарии очного предъявления пользователь показывает QR-код или предъявляет NFC-метку. Она содержит то, что нужно считывателю, чтобы открыть соединение NFC, Bluetooth Low Energy или Wi-Fi Aware и построить поверх него аутентифицированный зашифрованный канал. Интернет-соединение между устройствами при этом не нужно.^[1]

Очное предъявление с mdoc (ISO/IEC 18013-5), упрощённая схема.^[1]

Что видит пользователь:

Протоколы предъявления: OpenID4VP, ISO/IEC 18013-7 и очное предъявление

В ARF перечислено, с чем работает кошелёк: ISO/IEC 18013-5 при очном предъявлении, а также OpenID4VP или ISO/IEC 18013-7 при удалённом предъявлении.^[1]

Какой протокол передаёт какой формат, согласно ARF.^[1]

Аттестации SD-JWT VC «не могут использоваться при предъявлении вблизи». ISO/IEC 18013-7 «может использоваться только для запроса и предъявления аттестаций в формате, соответствующем [ISO/IEC 18013-5]». OpenID4VP «подходит только для потоков транзакций удалённого предъявления» и передаёт оба формата.^[1] OpenID4VP 1.0 получила статус Final Specification 10 июля 2025 года.^[5]

ARF не рекомендует использовать собственные URI-схемы между устройствами, поскольку такие потоки «уязвимы для фишинга и атак ретрансляции», и называет альтернативой Digital Credentials API.^[1] Этот API пока остаётся черновиком W3C, а Chrome 141 включает его по умолчанию.^[9][10] ISO указывает техническую спецификацию 18013-7 2024 года как отозванную и заменённую, а третья редакция находится в разработке. Поэтому проверьте, на какую редакцию ориентирован ваш код.^[7][8] Детали запроса приведены в руководстве для верификатора OpenID4VP.

Что Имплементационный регламент (ЕС) 2026/1731 требует в отношении PID

Первое правило о форматах PID, Имплементационный регламент (ЕС) 2024/2977, устанавливало, что PID «выдаются в двух форматах»: ISO/IEC 18013-5:2021 и Verifiable Credentials Data Model 1.1.^[2][3] Изменяющий акт июля 2026 года заменил это предложение. Теперь PID «выдаются в соответствии со стандартами, установленными в Приложении II к Имплементационному регламенту (ЕС) 2024/2979, пункты 5 (формат SD-JWT VC) и 6 (формат ISO/IEC-mdoc)».^[2]

1. 4 декабря 2024Первое правило2024/2977: 18013-5 и VCDM 1.1.
2. 22 июля 2026Внесены изменения2026/1731: SD-JWT VC и mdoc.
3. 23 июля 2026ARF v3.0.0Приведена в соответствие с изменяющими актами.
4. 24 декабря 2026Срок для кошельковОдин кошелёк на каждое государство-член.
5. 11 августа 2028ПортретТребование о портрете применяется, если пользователь явно не отказался от него, где это применимо.

Как менялось законодательство о форматах PID.^[1][2][3][6]

Тот же акт устанавливает два профиля предъявления в приложении к Имплементационному регламенту (ЕС) 2024/2982: «профиль ISO/IEC-mdoc» и «профиль OpenID4VC-HAIP».^[2]

• Передавайте свой сертификат регистрации: один из элементов verifier_info «должен включать сертификат регистрации».^[2]
• Используйте свой сертификат доступа как конечный (leaf) сертификат с префиксом идентификатора клиента x509_hash.^[2]
• Для mdoc через Digital Credentials API следуйте «Приложению C к ISO/IEC 18013-7:2025».^[2]

Регистрация описана в руководстве по EUDI Wallet для доверяющих сторон, а календарь в статье Сроки EUDI Wallet на 2026 и 2027 годы.

SD-JWT VC и mdoc (ISO/IEC 18013-5): сравнительная таблица

По данным ARF, кроме строки PID (Имплементационный регламент 2026/1731) и двух последних строк (OpenID4VP 1.0).^[1][2][4]

Мобильные водительские удостоверения в США основаны на ISO/IEC 18013-5 для очного предъявления.^[7][8] Решение ЕС для проверки возраста называет доказательство с нулевым разглашением обязательным механизмом предъявления, «с простым предъявлением mDoc в качестве резервного варианта».^[13] В документации молдавского EVO Wallet описан OpenID4VP 1.0 с mdoc по ISO/IEC 18013-5 в профиле HAIP 1.0.^[11]

Какой формат должна поддерживать доверяющая сторона

Экземпляры кошелька работают с обоими форматами, и PID выдаётся в обоих.^[1][2] В текстах, изученных для этого руководства, нет положения, обязывающего доверяющую сторону запрашивать оба. На практике это означает следующее: удалённый верификатор может запросить любой из них, а считывателю без подключения к интернету нужен mdoc, единственный формат, работающий при очном предъявлении (proximity).^[1]

Язык запросов цифровых удостоверений (DCQL) в OpenID4VP позволяет передать в одном запросе запрос dc+sd-jwt и запрос mso_mdoc одновременно. Пример такого запроса приведён в спецификации.^[4] Согласно ARF, доверяющая сторона проверяет подпись издателя по якорю доверия из доверенного списка (Trusted List) или списка доверенных субъектов (List of Trusted Entities), проверяет отзыв по списку статусов или списку отзыва и проверяет привязку к устройству.^[1]

Согласно eIDAS 2, Регламенту (ЕС) 2024/1183, каждое государство-член должно предоставить как минимум один кошелёк до 24 декабря 2026 года, а частные доверяющие стороны, обязанные применять строгую аутентификацию пользователя, должны принимать его по запросу пользователя до 24 декабря 2027 года. Микро- и малые предприятия освобождены от этого требования.^[6] Статус по странам приведён в трекере запуска EUDI Wallet.

Библиотеки и инструменты тестирования

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

• Запустите тесты на соответствие на conformance.eudi.dev. Они указаны в примечаниях к выпуску ARF v3.0.0.^[1]
• Изучите документацию эталонной реализации на docs.eudi.dev.^[1]
• Изучите опубликованный верификатор: Национальный банк Молдовы выпустил для финансовых организаций демонстрационный верификатор с исходным кодом.^[12]
• Убедитесь, что библиотека следует HAIP, а не только базовым спецификациям.^[1]
• Уточните, какую редакцию ISO/IEC 18013-7 она реализует.^[2][8]

Как Didit помогает с проверкой через EUDI Wallet

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

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

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

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

Источники

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

SD-JWT VC и mdoc (ISO/IEC 18013-5) представляют собой две кодировки одного и того же обещания: подписанные атрибуты, которые контролирует пользователь. О том, как Didit подходит к приему кошельков, читайте на странице решения для кошелька EUDI, а все национальные схемы описаны в обзоре «Схемы eID по странам».