Digital Credentials API (2025): поддержка в Chrome и Safari уже доступна

Последнее обновление: 30 октября 2025 г.

Краткий обзор поддержки Digital Credentials API в основных браузерах:

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

Want to experience digital credentials in action?

Try Digital Credentials

Что изменилось с июля 2025 года?

• Выпущено: Chrome 141 (30 сентября 2025 г.) и Safari 26 (15 сентября 2025 г.).
• Chrome: Независимость от протокола (OpenID4VP и ISO 18013-7, Приложение C), кросс-девайс на десктопе через CTAP.
• Safari: Только mdoc (org-iso-mdoc), кросс-девайс через CTAP.
• Структура API: navigator.credentials.get(); именование requests/data; определение поддержки через DigitalCredential.

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

В этой статье мы обсудим текущее состояние Digital Credentials API — важной разработки, которая обещает изменить наше взаимодействие с идентификационной информацией в вебе. Мы рассмотрим его основные механизмы, поддерживаемые протоколы, текущее внедрение в браузерах и дадим рекомендации как для доверяющих сторон, так и для эмитентов кошельков, ориентирующихся в этом быстро меняющемся ландшафте.

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

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

Резервным вариантом для проверки личности во многих регионах традиционно были трудоемкие процессы. Например, физическая проверка в почтовом отделении создает значительные задержки и неудобства. Видеозвонки в сочетании с загрузкой документов стали более цифровой альтернативой, за которой последовало недавнее распространение автоматического сканирования документов и проверок на реальность (liveness checks). Несмотря на их преимущества, эти методы имеют существенные недостатки. Они могут быть трудоемкими, подверженными человеческим ошибкам или предвзятости, и часто оказывались уязвимыми для изощренных подделок.

Проблема резко обостряется с появлением дипфейков, продвинутых техник имитации на основе ИИ и все более изощренных фишинговых атак. Эти технологии могут создавать очень реалистичные, но полностью сфабрикованные видео, аудио и документы, что делает чрезвычайно трудным для традиционных систем и даже для инструментов верификации на основе ИИ отличать настоящих пользователей от мошенников. Возможность создания синтетических личностей или манипулирования биометрическими данными для обхода проверок представляет серьезную угрозу, особенно для финансовых учреждений и любых сервисов, требующих надежных процессов "Знай своего клиента" (KYC). Этот растущий ландшафт угроз подчеркивает острую необходимость в более безопасных, криптографически проверяемых механизмах онлайн-идентификации и верификации.

Want to experience digital credentials in action?

Try Digital Credentials

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

В своей основе концепция цифровых удостоверений, особенно в контексте новых веб-API, вращается вокруг трехсторонней модели:

1. Эмитент: организация (например, правительство, университет, работодатель), которая является авторитетным источником определенной информации о субъекте и может выпустить цифровое удостоверение, подтверждающее эту информацию.
2. Держатель: субъект информации (т. е. пользователь), который получает удостоверение от эмитента и хранит его в цифровом кошельке. Держатель контролирует, когда и какая информация из удостоверения передается.
3. Верификатор (или доверяющая сторона): организация (например, веб-сайт, онлайн-сервис), которой необходимо проверить определенную информацию о держателе для предоставления доступа к услуге или ресурсу. Верификатор запрашивает необходимую информацию у держателя.

Эта трехсторонняя модель важна, поскольку она направлена на то, чтобы предоставить пользователю (держателю) контроль над своими данными. В отличие от традиционных систем идентификации, где данные могут храниться централизованно или передаваться между сторонами без прямого посредничества пользователя, эта модель подчеркивает согласие пользователя и избирательное раскрытие. Держатель решает, какие фрагменты информации передать из удостоверения для конкретной транзакции, вместо того чтобы раскрывать все удостоверение целиком.

Фундаментальным аспектом этих систем является использование криптографических пар ключей. Эмитент цифровым образом подписывает удостоверение, обеспечивая его подлинность и целостность. Держатель, в свою очередь, использует свой приватный ключ, часто защищенный внутри его цифрового кошелька (который защищен аппаратным обеспечением устройства), чтобы доказать контроль над удостоверением и авторизовать его предъявление верификатору. Обычно это включает в себя предъявление верификатором вызова (случайного набора данных), который кошелек держателя подписывает с использованием приватного ключа, связанного с удостоверением. Затем верификатор может использовать соответствующий публичный ключ для подтверждения подписи, таким образом аутентифицируя предъявление.

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

Эта статья концентрируется на верификации цифровых удостоверений и принципе избирательного раскрытия, позволяя пользователям доказывать конкретные атрибуты (например, «мне больше 18 лет», «у меня есть действительные водительские права»), не раскрывая весь исходный документ. Хотя базовые системы для цифровых удостоверений могут поддерживать такие функции, как квалифицированные электронные подписи (QES) и возможности удаленного подписания (как в комплексных решениях, таких как EU Digital Identity Wallet для юридически обязывающих подписей), здесь основной фокус, особенно для Digital Credentials API, делается на подтверждении личности и верификации атрибутов для онлайн-взаимодействий, а не на этих более широких функциях подписания.

Чтобы понять, как функционируют цифровые удостоверения, полезно представить себе многоуровневую модель. Каждый уровень отвечает за свой аспект экосистемы, от самого формата данных до того, как они представляются пользователю в веб-браузере. Эта статья в основном фокусируется на Digital Credentials API, который работает на уровне представления.

Основная терминология:

• Цифровое удостоверение: любое машиночитаемое удостоверение (PDF со штрих-кодом, ISO mDL, W3C VC, SD-JWT и т. д.). «Цифровой» ничего не говорит о криптографической проверяемости.
• Проверяемое удостоверение: вид цифрового удостоверения, определенный в W3C VC Data Model. Он добавляет защиту от подделки и криптографическое доказательство и всегда существует в трехстороннем мире: эмитент → держатель → верификатор.
• Verifiable Credential API: интерфейс сервиса REST/HTTP для выпуска, хранения, предъявления и проверки VC между бэкэнд-системами (эмитентами, кошельками, верификаторами).
• Digital Credentials API (DC API): API браузера/операционной системы (JavaScript + нативная часть), который позволяет веб-сайту запрашивать у кошелька на устройстве пользователя предъявление любого поддерживаемого цифрового удостоверения (VC, ISO mDoc, SD-JWT…) с соблюдением конфиденциальности.

Думайте о VC как о модели данных, о VC API — как о спецификации для бэкэнда, а о DC API — как о фронтенд-реализации, которая представляет удостоверения вебу. Все, что выше 1-го уровня (уровень модели данных), не зависит от формата; все, что ниже, зависит от формата удостоверения.

Сквозной процесс (пример: онлайн-проверка возраста):

1. Выпуск (VC API - эмитент ↔ кошелек): Государственное управление автотранспорта выпускает проверяемое удостоверение, в котором говорится: «Держатель старше 18 лет».
2. Хранение (Приложение-кошелек - ОС): Удостоверение хранится в кошельке пользователя вместе с его криптографическим доказательством.
3. Запрос (navigator.credentials.get() через DC API - веб-сайт → браузер): Сайт магазина пива запрашивает: «Покажите мне доказательство, что пользователю ≥18 лет».
4. Предъявление (DC API передает запрос кошельку → OpenID4VP (протокол) → данные VC): Кошелек показывает интерфейс согласия, пользователь одобряет, кошелек отправляет обратно проверяемое представление.
5. Проверка (VC API - бэкэнд магазина пива): Бэкэнд сайта проверяет подпись и DID/публичный ключ эмитента; предоставляет доступ.

Обратите внимание, как данные представлены в виде VC, транспорт в вебе — DC API, протокол обмена под ним — OpenID4VP, а проверка на стороне сервера использует VC API.

Почему существует такое разделение:

• Совместимая модель данных (криптографические доказательства, избирательное раскрытие): решается с помощью VC Data Model (и других форматов).
• Стандартные REST-эндпоинты для бэкэнд-систем: решается с помощью VC API.
• Взаимодействие кошелька и веб-сайта с сохранением конфиденциальности: решается с помощью DC API.
• Различные уровни доверия / типы документов (государственное удостоверение личности против сертификата о прохождении курса): решается использованием правильного формата (ISO mDoc для удостоверений с высоким уровнем доверия; W3C VC для общих утверждений) под DC API.

Ключевые выводы:

1. «Цифровое удостоверение» — это общий термин.
2. Проверяемое удостоверение — это вид цифрового удостоверения со встроенной криптографической проверяемостью.
3. VC API — это серверная инфраструктура для операций жизненного цикла VC.
4. Digital Credentials API — это мост между браузером и кошельком, который наконец-то позволяет этим удостоверениям плавно передаваться в веб-приложения, независимо от их конкретного формата.
5. Эти три части дополняют друг друга, а не конкурируют — они находятся на разных уровнях одного стека и вместе обеспечивают безопасную, ориентированную на пользователя идентификацию в открытом вебе.

Изучив участников и общую многоуровневую архитектуру цифровых удостоверений, эта статья теперь углубится в уровень представления, сосредоточившись конкретно на Digital Credentials API и его текущем состоянии.

Являясь ключевым компонентом на уровне представления, Digital Credentials API — это веб-стандарт, который в настоящее время разрабатывается для предоставления безопасного и стандартизированного способа для веб-сайтов запрашивать и получать информацию о цифровой личности из цифровых кошельков пользователей. Эта работа в основном ведется в рамках Рабочей группы W3C по федеративной идентичности (FedID WG), куда она перешла из FedID Community Group в апреле 2025 года. Официальный проект спецификации можно найти здесь: https://w3c-fedid.github.io/digital-credentials/.

По состоянию на октябрь 2025 года API выпущен в стабильных версиях как Chrome 141 (30 сентября 2025 г.), так и Safari 26 (15 сентября 2025 г.). Реализация в Chrome не зависит от протокола, поддерживая как OpenID4VP, так и ISO 18013-7, Приложение C, в то время как Safari эксклюзивно поддерживает протокол org-iso-mdoc. Chrome поддерживает это нативно на Android через свою систему Credential Manager, а также поддерживает кросс-девайсный Digital Credentials API на десктопе через передачу QR-кода с использованием CTAP/BLE.

API расширяет существующий Credential Management API, позволяя запрашивать цифровые удостоверения через navigator.credentials.get(). Согласно пояснению к Digital Credentials от W3C FedID WG (https://github.com/w3c-fedid/digital-credentials/blob/main/explainer.md), API вернулся к использованию этого устоявшегося интерфейса вместо ранее предложенного navigator.identity. Веб-сайт запрашивает цифровое удостоверение, вызывая navigator.credentials.get() с определенными параметрами для цифровых удостоверений.

Вот наглядный пример того, как веб-сайт может вызвать API для запроса удостоверения с использованием OpenID4VP:

async function requestCredential() {
    // Check for Digital Credentials API support
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // These parameters are typically fetched from the backend.
            // Statically defined here for protocol extensibility illustration purposes.
            const oid4vp = {
                protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Presentation Exchange request, omitted for brevity
                    },
                },
            };
 
            // create an Abort Controller
            const controller = new AbortController();
 
            // Call the Digital Credentials API using the presentation request from the backend
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Send the encrypted response to the backend for decryption and verification
            // Ommitted for brevity
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // fallback scenario, illustrative only
        alert("The Digital Credentials API is not supported in this browser.");
    }
}

Этот пример взят отсюда.

Digital Credentials API по сути действует как безопасная обертка или посредник. Он позволяет браузеру управлять запросом на получение идентификационной информации, используя возможности базовой операционной системы для обнаружения доступных кошельков и удостоверений, соответствующих запросу. Затем браузер и ОС могут представить единый пользовательский интерфейс для выбора удостоверения и авторизации его передачи, повышая безопасность и конфиденциальность за счет обеспечения согласия пользователя и предотвращения скрытого доступа веб-сайтов к конфиденциальным данным. Фактические данные удостоверения в ответе должны быть непрозрачными (зашифрованными) для самого браузера, а их расшифровка и интерпретация выполняются доверяющей стороной и кошельком/держателем.

Digital Credentials API разработан таким образом, чтобы не зависеть от протокола, что означает, что он может поддерживать различные базовые протоколы для обмена удостоверениями. Однако два основных семейства протоколов являются центральными для текущих реализаций и обсуждений: org.iso.mdoc (производный от ISO 18013-5 и его расширения ISO 18013-7 «Приложение C») и спецификации OpenID Foundation — OpenID for Verifiable Presentations (OpenID4VP) и OpenID for Verifiable Credential Issuance (OpenID4VCI).

• Происхождение и стандартизация: org.iso.mdoc относится к формату данных и модели взаимодействия для мобильных документов, в первую очередь мобильных водительских удостоверений (mDL), стандартизированных Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC). Основополагающим стандартом является ISO/IEC 18013-5, который определяет приложение mDL, структуру данных и протоколы для личного (бесконтактного) предъявления с использованием таких технологий, как NFC, Bluetooth или QR-коды. ISO/IEC 18013-7 расширяет это, чтобы обеспечить онлайн/удаленное предъявление mDL. Строка протокола «org.iso.mdoc» специально определена в ISO/IEC TS 18013-7 (Приложение C) для использования с такими API, как Digital Credentials API.

• Модель данных: mdocs имеют строго определенную структуру данных на основе CBOR (Concise Binary Object Representation) для компактности и эффективности. Она определяет пространства имен и элементы данных для общих атрибутов водительских прав и поддерживает надежные функции криптографической безопасности, включая аутентификацию эмитента, привязку к устройству, аутентификацию держателя (через портрет), шифрование сеанса и избирательное раскрытие.

• Типичные сценарии использования: в основном, документы, удостоверяющие личность, выданные правительством, такие как водительские права и национальные ID. Он предназначен для сценариев с высоким уровнем доверия, как при личном присутствии (например, проверка на дороге, проверка возраста для товаров с ограничениями), так и онлайн (например, доступ к правительственным услугам, удаленная проверка личности для открытия банковского счета).

• Происхождение и стандартизация: OpenID4VP (для предъявления) и OpenID4VCI (для выпуска) — это спецификации, разработанные OpenID Foundation. Они расширяют OAuth 2.0 для поддержки обмена проверяемыми удостоверениями. Это открытые стандарты, нацеленные на широкую совместимость для различных типов удостоверений, а не только государственных. На начало 2025 года OpenID4VP находится на продвинутых стадиях разработки (например, черновик 28 по состоянию на апрель). OpenID4VCI также находится в стадии созревания.
• Модель данных: OpenID4VP/VCI разработаны так, чтобы не зависеть от формата удостоверений. Они могут переносить проверяемые удостоверения W3C (VC) в форматах JSON/JSON-LD или JWT, mdocs, SD-JWT и других. Модель взаимодействия включает в себя запрос авторизации от верификатора (RP) и ответ от кошелька держателя, содержащий vp_token (токен проверяемого представления). Избирательное раскрытие обычно управляется с помощью языков запросов, таких как Presentation Exchange (DIF PE) или более нового Digital Credentials Query Language (DCQL).
• Типичные сценарии использования: широкий спектр приложений, включая проверку личности, предоставление подтверждения квалификации (например, дипломы об образовании, профессиональные сертификаты), подтверждения членства и многое другое. Они хорошо подходят для онлайн-взаимодействий, где доверяющей стороне необходимо проверить утверждения от различных эмитентов.

Важно понимать, что они не всегда являются взаимоисключающими. OpenID4VP, например, может использоваться для запроса и транспортировки [org.iso.mdoc]. Выбор часто зависит от конкретного сценария использования, типа удостоверения и участников экосистемы.

Цифровой кошелек Европейского Союза (EUDI) — это крупная инициатива, направленная на предоставление всем гражданам и резидентам ЕС безопасного цифрового кошелька для документов, удостоверяющих личность, и подтверждений. Архитектура и референтная структура кошелька EUDI явно планируют поддерживать как mdoc (особенно для мобильных водительских прав), так и проверяемые удостоверения W3C, используя OpenID4VP и OpenID4VCI для процессов предъявления и выпуска. Референтная реализация включает поддержку OpenID4VP для передачи mDocs и OpenID4VCI для выпуска PID и mDL в форматах mDoc и SD-JWT-VC форматах. Эта двойная поддержка со стороны такого крупномасштабного проекта подчеркивает важность обоих семейств протоколов. Однако это направление не лишено критики, поскольку некоторые наблюдатели отмечают, что Digital Credentials API, на который сильно повлияли компании «американского Bigtech», может стать глубоко интегрированным в окончательные спецификации кошелька EUDI. Были высказаны опасения по поводу потенциального влияния неевропейских организаций на критически важную часть инфраструктуры ЕС, как обсуждалось на форумах сообщества, таких как это обсуждение на GitHub.

Ландшафт поддержки Digital Credentials API в браузерах теперь сформировался: Chrome 141 и Safari 26 выпустили стабильную поддержку в сентябре 2025 года. Существуют заметные различия в подходе и уровне поддержки между браузерами.

Chrome выпустил Digital Credentials API в Chrome 141 (30 сентября 2025 г.). Реализация в Chrome не зависит от протокола: она совместима с OpenID4VP и ISO 18013-7, Приложение C (mdoc онлайн). Десктопная версия поддерживает кросс-девайсное предъявление с мобильных кошельков через канал на базе CTAP/BLE (передача через QR-код), при этом ответ непрозрачен для браузера. Структура API перешла на navigator.credentials.get(); параметры переименованы: providers → requests, request → data.

Определение поддержки:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API supported
}

Credential Manager в Android нативно поддерживает OpenID4VP для предъявления и OpenID4VCI для выпуска, позволяя приложениям на Android выступать в качестве держателей и верификаторов удостоверений, используя эти стандарты. Google отмечает растущую поддержку со стороны кошельков; Google Wallet является одним из первых последователей, также анонсированы Samsung Wallet и 1Password.

В предыдущих версиях этой статьи мы предсказывали, что подход Apple будет отличаться от подхода Google, сосредоточившись на протоколе org.iso.mdoc. Для исторического контекста, наши рассуждения были следующими:

Как мы правильно и ожидали, WWDC25 подтвердила эту стратегию. Safari 26 (iOS/iPadOS/macOS) вышел 15 сентября 2025 года с поддержкой Digital Credentials API, подтвердив, что их реализация эксклюзивно поддерживает протокол org-iso-mdoc (через дефис) для предъявления.

Это было подробно описано в сессии WWDC25 Verify identity documents on the web. API позволяет веб-сайтам запрашивать проверяемую информацию из документов, удостоверяющих личность, таких как водительские права, хранящиеся в Apple Wallet или в сторонних приложениях-поставщиках документов.

Ключевые выводы из реализации Apple:

• Только MDOC: API эксклюзивно использует строку протокола "org-iso-mdoc", основанную на стандарте ISO/IEC 18013-7, Приложение C. В реализации Digital Credentials API в Safari нет поддержки OpenID4VP.
• Только предъявление: API предназначен для предъявления (верификации) существующих удостоверений. Выпуск в Apple Wallet или другие приложения остается отдельным процессом, не связанным с браузером.
• Ориентированность на пользователя и безопасность: Процесс инициируется жестом пользователя и использует механизм «частичного запроса», где ОС сначала анализирует и проверяет запрос в песочнице, прежде чем передать его приложению-кошельку, что повышает безопасность.
• Расширяемость для приложений: Помимо Apple Wallet, сторонние приложения могут выступать в качестве поставщиков документов, реализовав новый фреймворк IdentityDocumentServices и расширение приложения.
• Кросс-девайсная поддержка: Кросс-девайсное предъявление с платформ, отличных от Apple, использует CTAP для бесконтактного взаимодействия после передачи QR-кода; ответ в JS остается зашифрованным/непрозрачным для браузера.

Apple предоставила ясный пример кода, как доверяющая сторона будет использовать API:

async function verifyIdentity() {
    try {
        // Server generates and cryptographically signs the request data.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // The request specifies the 'org-iso-mdoc' protocol.
        const request = {
            protocol: "org-iso-mdoc",
            // data contains the cryptographically signed mdoc request.
            data,
        };
 
        // The API must be called from within a user gesture.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Send the encrypted response from the wallet to the server for decryption and validation.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Display the verified details...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Handle errors, e.g., user cancellation.
    }
}

Это подтверждение закрепляет расходящиеся стратегии на рынке браузеров. В то время как Chrome строит свою реализацию на гибком транспортном уровне OpenID4VP, Apple использует свои глубокие инвестиции в экосистему ISO mdoc для предоставления высокоинтегрированного и безопасного, хотя и менее гибкого, решения, адаптированного для официальных документов, удостоверяющих личность.

Mozilla официально выразила негативную позицию по стандарту Digital Credentials API в его текущем виде. Их опасения всеобъемлющи и основаны на их миссии по защите конфиденциальности пользователей, их свободы выбора и обеспечению открытого, справедливого веба.

Ключевые опасения, высказанные Mozilla, включают:

• Риски для конфиденциальности: Потенциал для увеличения обмена личными данными и снижения онлайн-анонимности, если запросы на цифровые удостоверения станут обыденностью для тривиальных взаимодействий.
• Исключение пользователей: Риск того, что люди, которые не могут или не хотят использовать цифровые удостоверения, могут быть исключены из онлайн-сервисов и сообществ. Государственные удостоверения, основной сценарий использования, могут не соответствовать выбору человека в представлении своей личности.
• Проблемы совместимости: Опасения по поводу распространения форматов удостоверений, что приведет к фрагментированной экосистеме, а не к универсально совместимой.
• Избирательное раскрытие: Беспокойство, что преимущества конфиденциальности от избирательного раскрытия могут быть подорваны, если оно не будет реализовано с сильными гарантиями невозможности связывания данных, или если пользователи не будут полностью понимать, что именно передается.
• Централизация доверия и свободы выбора пользователя: Опасения, что API может привести к увеличению централизации доверия и снижению свободы выбора пользователя, увековечивая существующие социальные дисбалансы власти.

Mozilla признает, что такой API мог бы быть полезнее существующих спонтанных методов предъявления удостоверений, но подчеркивает, что новые функции веб-платформы должны очевидно делать веб лучше в целом и ставить интересы пользователей на первое место. Хотя Совет W3C отклонил официальное возражение, связанное с этими опасениями (чтобы позволить работе продолжаться в рамках W3C, а не в потенциально менее прозрачных местах), Совет рекомендовал Рабочей группе активно работать над смягчением этих потенциальных рисков.

Таблица 1: Поддержка Digital Credentials API и протоколов в браузерах (октябрь 2025 г.)

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

Учитывая, что Safari (выпущен 15 сентября 2025 г.) эксклюзивно поддерживает прямые взаимодействия org-iso-mdoc (ISO 18013-7, Приложение C) через Digital Credentials API, а Chrome (выпущен 30 сентября 2025 г.) не зависит от протокола, поддерживая как OpenID4VP, так и ISO 18013-7, Приложение C (mdoc), RP, стремящимся к максимально широкому охвату, следует подготовиться к поддержке взаимодействий на основе обоих подходов.

Это означает проектирование систем, которые могут:

1. Инициировать запросы на удостоверения через API navigator.credentials.get(), указывая различные параметры протокола ("org-iso-mdoc" для Safari или "openid4vp" для Chrome/OID4VP) на основе определения браузера или возможностей user agent.
2. Обрабатывать ответы, которые могут приходить непосредственно в формате mdoc (ISO 18013-7, Приложение C) или как vp_token через OpenID4VP, который затем необходимо разобрать для извлечения базового удостоверения (которое само может быть mdoc или другим форматом VC).

Хотя это добавляет сложности, попытка заставить всех пользователей использовать один протокол, скорее всего, исключит значительную часть пользовательской базы, либо тех, кто на iOS, либо тех, кто на Chrome/Android, в зависимости от выбранного пути. Прагматичный, хотя и более трудоемкий в разработке, подход заключается в создании гибкости для обработки обоих вариантов.

Доверяющие стороны должны четко осознавать, что даже при запросе одной и той же логической информации (например, «пользователю больше 21 года?»), то, как это определяется в запросе и как возвращается в ответе, может значительно отличаться между прямым запросом mdoc и запросом OpenID4VP (который может использовать Presentation Exchange или DCQL).

• Избирательное раскрытие в mdoc: org.iso.mdoc имеет свои собственные механизмы для избирательного раскрытия, обычно включающие создание эмитентом соленых хэшей отдельных элементов данных. Кошелек держателя затем раскрывает только запрошенные элементы вместе с их солями, позволяя верификатору сверить их с хэшами, не видя других данных. Запрос конкретных элементов привязан к предопределенным пространствам имен и идентификаторам элементов данных в стандарте mdoc.
• Избирательное раскрытие в OpenID4VP: OpenID4VP обычно использует язык запросов, такой как Presentation Exchange (DIF PE) или более новый Digital Credentials Query Language (DCQL), встроенный в presentation_definition запроса. Это позволяет RP указывать типы удостоверений и отдельные утверждения, которые им нужны. Затем кошелек конструирует проверяемое представление, содержащее только запрошенную информацию, если это поддерживается форматом удостоверения и кошельком.

RP необходимо сопоставить свои конкретные требования к данным с этими различными структурами протоколов. Крайне важно понимать нюансы того, как избирательное раскрытие реализуется и запрашивается в каждом протоколе, чтобы гарантировать, что запрашиваются и обрабатываются только минимально необходимые данные, тем самым соблюдая лучшие практики конфиденциальности и принципы минимизации данных. Формат и структура раскрытых данных, возвращаемых кошельком, также могут отличаться, требуя отдельной логики разбора и валидации на бэкэнде RP.

Для организаций, желающих выпускать цифровые удостоверения и предоставлять приложения-кошельки для держателей, среда операционной системы играет решающую роль.

Эмитенты кошельков сталкиваются с совершенно разными условиями на iOS и Android в отношении создания кошельков, системной интеграции и взаимодействия с Digital Credentials API.

• Android: В целом предлагает более открытую экосистему. Android Credential Manager включает Holder API, который позволяет сторонним нативным приложениям регистрироваться в качестве держателей удостоверений. Эти зарегистрированные приложения-держатели затем могут участвовать в процессах предъявления удостоверений, управляемых системой, отвечая на запросы от Digital Credentials API (через Chrome) или верификаторов из нативных приложений. Android также явно поддерживает OpenID4VCI для выпуска удостоверений, позволяя пользователям выбирать совместимый сторонний кошелек для получения новых удостоверений. Хотя нативные приложения являются основным фокусом для полных возможностей держателя удостоверений, система разработана для более широкого участия.

• iOS: Apple поддерживает более жесткий контроль над своей экосистемой. Хотя сторонние приложения-кошельки могут существовать в App Store, их способность глубоко интегрироваться в качестве системных держателей удостоверений высокого уровня доверия (таких как mDL, предназначенных для Apple Wallet) часто зависит от специфических процессов и разрешений Apple. Например, добавление ID в Apple Wallet — это контролируемый процесс, включающий государственные органы-эмитенты и проверку Apple. Для Digital Credentials API в Safari взаимодействия, скорее всего, будут строго управляться, с основным фокусом на org.iso.mdoc, предъявляемых из авторизованных источников, а именно из самого Apple Wallet и зарегистрированных сторонних приложений-поставщиков документов.

Подход Apple «закрытой экосистемы» хорошо известен, и их реализация цифровых удостоверений не является исключением. Однако WWDC25 прояснила путь для участия сторонних разработчиков.

Хотя Apple Wallet является основным встроенным поставщиком для удостоверений, таких как государственные mDL, Apple представила фреймворк IdentityDocumentServices для нативных приложений на iOS. Это позволяет сторонним разработчикам создавать приложения, которые могут предоставлять и предъявлять свои собственные документы, удостоверяющие личность.

Чтобы участвовать в веб-процессе, нативное приложение должно:

1. Регистрировать документы: Использовать IdentityDocumentProviderRegistrationStore для регистрации mdocs, которыми управляет приложение, в операционной системе. Эта регистрация включает тип документа и доверенные центры сертификации для подписи запросов.
2. Реализовать расширение приложения: Добавить в проект UI App Extension типа «Identity Document Provider». Это расширение отвечает за отображение интерфейса авторизации пользователю, когда приложение выбрано во время процесса верификации через веб.

Это означает, что хотя создание полностью интегрированного кошелька на iOS требует создания нативного приложения и использования специфических фреймворков Apple, а не веб-технологий, таких как PWA, существует ясный, хотя и строго контролируемый, механизм для сторонних приложений, чтобы они могли выступать в качестве поставщиков документов наряду с Apple Wallet. Это подтверждает, что взаимодействие с Digital Credentials API в Safari управляется ОС, которая затем направляет запросы в Apple Wallet или любое другое зарегистрированное и авторизованное приложение-поставщик документов.

Digital Credentials API представляет собой значительный шаг вперед в области цифровой идентификации, предлагая более безопасный, ориентированный на пользователя и сохраняющий конфиденциальность подход к верификации личности и предъявлению удостоверений. С выходом стабильной поддержки в Chrome 141 (30 сентября 2025 г.) и Safari 26 (15 сентября 2025 г.) API перешел из экспериментальной стадии в готовую к использованию в продакшене. Поскольку экосистема продолжает развиваться, для доверяющих сторон и эмитентов кошельков крайне важно адаптироваться и использовать потенциал этой новой технологии. Мы будем поддерживать эту статью в актуальном состоянии по мере изменения ландшафта.

Однако проблемы остаются. Достижение истинной глобальной совместимости между различными форматами удостоверений, протоколами и реализациями кошельков — это серьезная задача. Учет обоснованных опасений, высказанных такими организациями, как Mozilla, в отношении конфиденциальности, исключения и свободы выбора пользователя, имеет первостепенное значение для обеспечения того, чтобы эти технологии служили человечеству. Расходящиеся подходы — независимая от протокола реализация Chrome против фокуса Safari только на mdoc — означают, что доверяющие стороны и эмитенты кошельков должны будут ориентироваться в ландшафте двух протоколов в обозримом будущем.