Digital Credentials API (2025): Поддержка в Chrome и Safari (WWDC25)

Последнее обновление: 15 июля 2025 г. (после WWDC25)

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

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

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

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

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

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

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

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

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

1. Издатель (Issuer): Организация (например, правительство, университет, работодатель), которая является авторитетным источником определенной информации о субъекте и может выдать цифровое удостоверение, подтверждающее эту информацию.
2. Держатель (Holder): Субъект информации (т.е. пользователь), который получает удостоверение от издателя и хранит его в цифровом кошельке. Держатель контролирует, когда и какая информация из удостоверения передается.
3. Проверяющая сторона (Verifier) (или Доверяющая сторона (Relying Party)): Организация (например, веб-сайт, онлайн-сервис), которой необходимо проверить определенную информацию о держателе для предоставления доступа к услуге или ресурсу. Проверяющая сторона запрашивает необходимую информацию у держателя.

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

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

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

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

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

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

• Цифровое удостоверение (Digital credential): Любое машиночитаемое удостоверение (PDF со штрих-кодом, ISO mDL, W3C VC, SD-JWT и т.д.). Слово «цифровое» ничего не говорит о криптографической верифицируемости.
• Верифицируемое удостоверение (Verifiable Credential): Разновидность цифрового удостоверения, определенная моделью данных W3C VC. Оно добавляет защиту от подделки и криптографическое доказательство, и всегда существует в трехстороннем мире: издатель → держатель → проверяющая сторона.
• 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 - издатель ↔ кошелек): Государственное автотранспортное управление (DMV) выдает Верифицируемое удостоверение (Verifiable Credential), в котором говорится: «Держателю больше 18 лет».
2. Хранение (Приложение-кошелек - ОС): Удостоверение хранится в кошельке пользователя вместе с его криптографическим доказательством.
3. Запрос (navigator.credentials.get() через DC API - веб-сайт → браузер): Веб-сайт пивного магазина запрашивает: «Покажите мне доказательство, что пользователю ≥18 лет».
4. Предъявление (DC API передает запрос кошельку → OpenID4VP (протокол) → полезная нагрузка VC): Кошелек показывает интерфейс для получения согласия, пользователь одобряет, кошелек отправляет обратно верифицируемое представление (verifiable presentation).
5. Верификация (VC API - бэкенд пивного магазина): Бэкенд сайта проверяет подпись и DID/публичный ключ издателя; предоставляет доступ.

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

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

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

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

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

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

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

По состоянию на 2025 год, API все еще описывается как находящийся в стадии значительных изменений. Это подчеркивает его активную фазу разработки. Несмотря на это, его потенциал огромен. Chrome первым выпустил что-то публичное в виде Origin Trial, позволяя разработчикам экспериментировать с его возможностями. Chrome также поддерживает это нативно на Android через свою систему Credential Manager и недавно также опубликовал поддержку использования Cross-Device Digital Credentials API на десктопе.

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 (Verifiable Presentation Token). Выборочное раскрытие обычно управляется с помощью языков запросов, таких как Presentation Exchange (DIF PE) или более нового Digital Credentials Query Language (DCQL).
• Типичные сценарии использования: Широкий спектр приложений, включая верификацию личности, предоставление доказательств квалификации (например, дипломы об образовании, профессиональные сертификаты), подтверждение членства (attestations) и многое другое. Они хорошо подходят для онлайн-взаимодействий, где доверяющей стороне необходимо проверить утверждения от различных издателей.

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

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

Ландшафт браузеров для Digital Credentials API все еще формируется, с заметными различиями в подходе и уровнях поддержки.

Google Chrome, особенно на Android, был одним из первых, кто внедрил и реализовал Digital Credentials API. Они проводили Origin Trials и интегрировали его с нативным Credential Manager в Android. Реализация Chrome в основном использует OpenID4VP в качестве протокола для запроса удостоверений через вызов API navigator.credentials.get(). Хотя сам OpenID4VP не зависит от формата и может переносить org.iso.mdoc или верифицируемые удостоверения W3C в качестве полезной нагрузки, практический акцент со стороны Google, похоже, делается на потоке OpenID4VP как на транспортном механизме. Credential Manager в Android также нативно поддерживает OpenID4VP для предъявления и OpenID4VCI для выдачи. Это позволяет приложениям на Android выступать в качестве держателей и проверяющих удостоверений, используя эти стандарты.

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

Как мы и предсказывали, WWDC25 подтвердила эту стратегию. На конференции Apple официально объявила о поддержке API в Safari 26 (который выйдет с iOS 26 и другими обновлениями ОС осенью 2025 года), подтвердив, что их реализация эксклюзивно поддерживает протокол org.iso.mdoc для предъявления.

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

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

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

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 и протоколов в браузерах

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

Учитывая, что Safari, с его значительной долей рынка, скорее всего, будет отдавать приоритет прямому взаимодействию с org.iso.mdoc через Digital Credentials API, а Chrome/Android делают акцент на OpenID4VP (который может переносить mdocs или другие форматы верифицируемых удостоверений), RP, стремящиеся к максимально широкому охвату, должны быть готовы поддерживать взаимодействия на основе обоих подходов.

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

1. Инициировать запросы удостоверений через API navigator.credentials.get(), потенциально указывая различные параметры протокола («org.iso.mdoc» или «openid4vp») на основе определения браузера или возможностей user agent.
2. Обрабатывать ответы, которые могут приходить непосредственно в формате mdoc или в виде vp_token через OpenID4VP, который затем необходимо разобрать для извлечения базового удостоверения (которое само может быть mdoc или другим форматом VC).

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

Доверяющие стороны должны четко осознавать, что даже при запросе одной и той же логической информации (например, «пользователю больше 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 указывать типы удостоверений и отдельные утверждения, которые им нужны. Затем кошелек конструирует верифицируемое представление (Verifiable Presentation), содержащее только запрошенную информацию, если это поддерживается форматом удостоверения и кошельком.

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 «огороженный сад» (walled garden) хорошо известен, и их реализация цифровых удостоверений не является исключением. Однако WWDC25 прояснила путь для участия третьих сторон.

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

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

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

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

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

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