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

Последнее обновление: 26 марта 2026 г.

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

• Сдвиг в управлении протоколами: Рабочая группа W3C FedID упразднила открытый реестр протоколов на TPAC (ноябрь 2025) и теперь жестко прописывает поддерживаемые протоколы прямо в спецификации: OpenID4VP, OpenID4VCI и ISO 18013-7 Annex C. API больше не является «простой трубой» (dumb pipe).
• Появление функции выпуска (Issuance): Chrome 143 запустил Origin Trial для выпуска удостоверений через navigator.credentials.create(), расширяя возможности API за рамки только презентации.
• Реализация в Firefox: Несмотря на неизменную отрицательную позицию по стандартизации, Mozilla добавила базовый код DC API в Firefox 149, и работа над UX продолжается.
• Условный мандат ЕС: EUDI Architecture Reference Framework (Topic F) теперь условно требует поддержки DC API для всех кошельков государств-членов.
• Реальное внедрение: DMV Калифорнии добавило поддержку DC API в свою платформу OpenCred (февраль 2026).

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

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

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

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

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

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

Want to experience digital credentials in action?

Try Digital Credentials

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

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

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

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

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

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

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

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

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

• Цифровое удостоверение (Digital credential): Любое машиночитаемое удостоверение (PDF со штрих-кодом, ISO mDL, W3C VC, SD-JWT и т.д.). Слово «цифровое» ничего не говорит о криптографической проверяемости.
• Проверяемое удостоверение (Verifiable Credential): Тип цифрового удостоверения, определенный моделью данных 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 (слой модели данных), не зависит от формата; все, что ниже, зависит от формата удостоверения.

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

Следующая диаграмма иллюстрирует, как эти слои работают вместе в реальном сценарии.

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

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

• Интероперабельная модель данных (криптографические доказательства, выборочное раскрытие): Решается с помощью VC Data Model (и других форматов).
• Стандартные конечные точки REST для бэкенд-систем: Решается с помощью VC API.
• Рукопожатие Кошелек ↔ Веб-сайт с сохранением конфиденциальности: Решается с помощью DC API.
• Разные уровни доверия / типы документов (гос. ID против сертификата курсов): Решается использованием правильного формата (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 Working Group (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 Annex C, в то время как Safari поддерживает исключительно протокол org-iso-mdoc.

Важное обновление (Март 2026): Отношение API к протоколам фундаментально изменилось. На TPAC в ноябре 2025 года W3C FedID WG достигла консенсуса об устранении открытого реестра протоколов и вместо этого жестком кодировании конечного списка поддерживаемых протоколов непосредственно в спецификации: openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc (для презентации) и openid4vci-v1 (для выпуска). Ожидается, что user agent-ы (браузеры) будут отклонять протоколы, не входящие в список. Это делает Рабочую группу фактическим привратником для будущих добавлений протоколов — сознательный компромисс для обеспечения целостного обзора безопасности и конфиденциальности всего, что проходит через API (см. текущий рабочий проект).

Спецификация теперь также охватывает выпуск удостоверений через navigator.credentials.create(). Chrome 143 запустил Origin Trial для этого, позволяя веб-сайтам инициировать потоки наполнения кошелька с использованием OpenID4VCI. Однако уязвимость привязки выбора кошелька — когда вредоносное приложение-кошелек может перехватить коды предварительной авторизации выпуска — остается открытой проблемой. Государственные эмитенты заявили, что не будут внедрять выпуск через браузер, пока это не будет решено.

Chrome поддерживает презентацию нативно на Android через свою систему Credential Manager, а также поддерживает Cross-Device Digital Credentials API на десктопе через канал CTAP/BLE с передачей через QR-код.

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

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

async function requestCredential() {
    // Проверка поддержки Digital Credentials API
    if (typeof window.DigitalCredential !== "undefined") {
        try {
            // Эти параметры обычно получаются с бэкенда.
            // Здесь определены статически для иллюстрации расширяемости протокола.
            const oid4vp = {
                protocol: "oid4vp", // Пример запроса OpenID4VP к кошелькам. // Основано на https://github.com/openid/OpenID4VP/issues/125
                data: {
                    nonce: "n-0S6_WzA2Mj",
                    presentation_definition: {
                        //Запрос Presentation Exchange, опущен для краткости
                    },
                },
            };
 
            // создание Abort Controller
            const controller = new AbortController();
 
            // Вызов Digital Credentials API с использованием запроса презентации от бэкенда
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // Отправка зашифрованного ответа на бэкенд для расшифровки и проверки
            // Опущено для краткости
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // сценарий фоллбэка, только для иллюстрации
        alert("Digital Credentials API не поддерживается в этом браузере.");
    }
}

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

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

Digital Credentials API изначально разрабатывался как полностью протоколо-независимый, действующий как «глупая труба» с открытым реестром для регистрации любого протокола. Однако по состоянию на январь 2026 года спецификация теперь явно именует поддерживаемые протоколы — ожидается, что браузеры будут отклонять те, что не указаны в списке. Двумя основными семействами протоколов, жестко прописанными в спецификации, являются: org.iso.mdoc (производный от ISO 18013-5 и его расширения ISO 18013-7 «Annex 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 (Annex C) для использования с такими API, как Digital Credentials API.

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

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

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

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

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

Обновление от марта 2026 года: Приверженность ЕС к Digital Credentials API стала более конкретной. Архитектура EUDI (ARF) Topic F теперь условно требует, чтобы модули кошелька EUDI (Wallet Units) и Relying Party поддерживали DC API для потоков удаленной презентации и выпуска аттестаций. Условия включают достижение DC API статуса Рекомендации W3C и соответствие ожиданиям в отношении функциональности, нейтральности браузера/ОС, конфиденциальности и защиты от отказа в обслуживании. Консорциум European Wallet Consortium (EWC) включил тестовые случаи DC API в свою программу тестирования соответствия, а консорциум NOBID завершил пилоты платежей с использованием OpenID4VP — того же протокола, который теперь переносит DC API.

Однако это направление не лишено критики, так как некоторые наблюдатели отмечают, что Digital Credentials API, находящийся под сильным влиянием «американского бигтеха», может глубоко интегрироваться в финальные спецификации EUDI Wallet. Поднимались вопросы о потенциальном влиянии субъектов не из ЕС на критически важную часть инфраструктуры ЕС, что обсуждалось на форумах сообщества, таких как это обсуждение на GitHub. Отдельно решение жестко закодировать ссылку на ISO 18013-7 в спецификации вызвало возражение от Ping Identity, аргументирующее, что нормативная ссылка на спецификацию с платным доступом противоречит принципам открытого веба — проблема, которая может вылиться в официальное возражение при переходе спецификации к статусу Candidate Recommendation.

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

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

Определение функции:

if (typeof DigitalCredential !== "undefined") {
    // Digital Credentials API поддерживается
}

Android Credential Manager нативно поддерживает 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 Annex C. В реализации Digital Credentials API в Safari нет поддержки OpenID4VP.
• Только презентация: API предназначен для презентации (верификации) существующих удостоверений. Выпуск в Apple Wallet или другие приложения остается отдельным процессом, не связанным с браузером.
• Ориентированность на пользователя и безопасность: Поток инициируется жестом пользователя и использует механизм «частичного запроса», когда ОС сначала разбирает и проверяет запрос в песочнице перед передачей его в приложение-кошелек, повышая безопасность.
• Расширяемость для приложений: Помимо Apple Wallet, сторонние приложения могут выступать в качестве провайдеров документов, реализуя новый фреймворк IdentityDocumentServices и расширение приложения.
• Кросс-девайс поддержка: Кросс-девайс презентация с платформ не-Apple использует CTAP для близости после передачи QR-кода; JS-ответ остается зашифрованным/непрозрачным для браузера.

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

async function verifyIdentity() {
    try {
        // Сервер генерирует и криптографически подписывает данные запроса.
        const response = await fetch("drivers/license/data");
        const data = await response.json();
 
        // Запрос указывает протокол 'org-iso-mdoc'.
        const request = {
            protocol: "org-iso-mdoc",
            // data содержит криптографически подписанный запрос mdoc.
            data,
        };
 
        // API должен вызываться внутри жеста пользователя.
        const credential = await navigator.credentials.get({
            mediation: "required",
            digital: {
                requests: [request],
            },
        });
 
        // Отправка зашифрованного ответа от кошелька на сервер для расшифровки и валидации.
        const verificationResponse = await fetch("/decrypt", {
            method: "POST",
            body: JSON.stringify(credential.data),
            headers: {
                "Content-Type": "application/json",
            },
        });
 
        // Отображение проверенных данных...
        const json = await verificationResponse.json();
        presentDetails(json);
    } catch (err) {
        // Обработка ошибок, например, отмены пользователем.
    }
}

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

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

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

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

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

Обновление от марта 2026 года — Реализация идет полным ходом: Несмотря на то, что официальная отрицательная позиция остается технически неизменной, Mozilla начала активно реализовывать Digital Credentials API. В 1 квартале 2026 года базовая поддержка DC API появилась в Firefox 149 (за флагом настроек), отслеживаемая под мета-багом 2004828. Исходный код находится в mozilla-central, включая DigitalCredential.cpp, привязки WebIDL и IPC-обвязку. Работа над запросами разрешений для десктопа и Android (баг 2010091, баг 2010093) продолжается.

Три инженера Mozilla — John Schanck, Martin Thomson и Benjamin VanderSloot — являются активными участниками рабочей группы W3C FedID Working Group, а Schanck предоставляет существенную обратную связь, основанную на реализации, по ключевым PR спецификации, включая алгоритм презентации удостоверения и алгоритм подготовки запроса.

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

Таблица 1: Поддержка Digital Credentials API и протоколов браузерами (Март 2026)