数字凭证 API (2025)：Chrome 和 Safari 现已正式支持

最后更新于：2025 年 10 月 30 日

以下是主流浏览器对数字凭证 API 支持情况的简要概述：

数字凭证领域正在飞速发展。以下是关键进展和预测的快照：

Want to experience digital credentials in action?

Try Digital Credentials

自 2025 年 7 月以来有哪些变化？

• 已发布：Chrome 141（2025 年 9 月 30 日）和 Safari 26（2025 年 9 月 15 日）。
• Chrome：协议无关（同时支持 OpenID4VP 和 ISO 18013-7 附录 C），通过 CTAP 实现桌面跨设备功能。
• Safari：仅支持 mdoc (org-iso-mdoc)，通过 CTAP 实现跨设备流程。
• API 形态：navigator.credentials.get()；requests/data 命名；DigitalCredential 功能检测。

数字凭证是当前身份领域的热门话题。随着我们的生活与数字世界日益紧密地联系在一起，对安全、以用户为中心且保护隐私的方式来在线声明我们的身份和资格的需求从未如此迫切。传统方法已经显得过时，市场对更强大解决方案的需求显而易见。

在本文中，我们将讨论数字凭证 API 的现状，这是一项重要的发展，有望重塑我们在 Web 上与身份信息交互的方式。我们将探讨其底层机制、支持的协议、当前的浏览器采用情况，并为正在这个快速发展的领域中探索的信赖方和钱包颁发者提供建议。

多年来，如何在 Web 架构中可靠、安全地证明身份一直是一个持续的挑战。虽然互联网促进了前所未有的连接和信息交换，但它也为身份冒用和欺诈开辟了新途径。

在一些国家，解决方案应运而生，主要由早期的银行联盟推动，他们开发了利用现有信任关系进行在线身份识别的服务。政府也介入其中，强制推行或提供国家数字身份钱包和服务。然而，这些解决方案通常是孤立的、有地域限制，并且不具备普遍的互操作性。

在许多地区，身份验证的传统备用方案涉及高摩擦流程。例如，在邮局进行物理验证会带来严重的延迟和不便。视频通话结合文件上传成为一种更数字化的替代方案，随后是近期兴起的自动文档扫描和活体检测。尽管这些方法有所进步，但它们有明显的缺点。它们可能耗时、容易出现人为错误或偏见，并且经常被曝出容易受到复杂伪造的攻击。

随着深度伪造、先进的 AI 驱动的冒充技术以及日益复杂的网络钓鱼攻击的出现，这一挑战正在急剧升级。这些技术可以创建高度逼真但完全伪造的视频、音频和文件证据，使得传统系统甚至 AI 驱动的验证工具极难区分真实用户和欺诈者。创建合成身份或操纵生物特征数据以绕过检查的潜力是一个严重威胁，特别是对于金融机构和任何需要强大“了解你的客户”（KYC）流程的服务而言。这种不断升级的威胁形势凸显了对更安全、可通过密码学验证的在线身份和验证机制的迫切需求。

Want to experience digital credentials in action?

Try Digital Credentials

要理解数字凭证如何运作，我们需要审视其中的关键参与者以及实现其功能的不同技术层面。

从核心上讲，数字凭证的概念，特别是在新的 Web API 背景下，围绕着一个三方模型展开：

1. 颁发者：一个实体（例如，政府、大学、雇主），对某个主体的特定信息具有权威性，并能颁发数字凭证来证明该信息。
2. 持有者：信息的主体（即用户），他从颁发者那里接收凭证并将其存储在数字钱包中。持有者控制何时以及分享凭证中的哪些信息。
3. 验证者（或信赖方）：一个实体（例如，网站、在线服务），需要验证持有者的某些信息以授予对服务或资源的访问权限。验证者向持有者请求必要的信息。

这个三方模型之所以重要，是因为它旨在将用户（持有者）置于其自身数据的控制中心。与传统身份系统中数据可能被集中存储或在各方之间共享而没有用户直接干预不同，该模型强调用户同意和选择性披露。持有者决定在特定交易中分享凭证的哪些信息，而不是泄露整个凭证。

这些系统的一个基本方面是密码学密钥对的参与。颁发者对凭证进行数字签名，确保其真实性和完整性。持有者则使用他们的私钥（通常安全地存放在受设备硬件保护的数字钱包中）来证明对凭证的控制权，并授权将其出示给验证者。这通常涉及验证者出示一个挑战（一个随机数据片段），持有者的钱包使用与凭证关联的私钥对其进行签名。验证者随后可以使用相应的公钥来确认签名，从而验证出示行为的真实性。

这个解释是协议中立的，因为颁发、持有和通过密码学挑战进行验证的核心原则在不同的底层技术中是共通的。

本文重点关注数字凭证的验证和选择性披露原则，使用户能够证明特定属性（例如，“我已满 18 岁”、“我持有有效驾照”）而无需透露整个源文件。虽然数字凭证的底层系统可能支持合格电子签名（QES）和远程签名功能（如欧盟数字身份钱包等综合解决方案中所见，用于具有法律约束力的签名），但本文的重点，特别是对于数字凭证 API 而言，是在线交互中的身份断言和属性验证，而非这些更广泛的签名功能。

为了理解数字凭证如何运作，将它想象成一个分层模型会很有帮助。每一层都处理生态系统的不同方面，从数据格式本身到它如何在 Web 浏览器中呈现给用户。本文主要关注数字凭证 API，它在表示层运行。

核心术语：

• **数字凭证：**任何机器可读的凭证（带条形码的 PDF、ISO mDL、W3C VC、SD-JWT 等）。“数字”一词并未说明其是否具有密码学可验证性。
• **可验证凭证：**一种数字凭证，由 W3C VC 数据模型定义。它增加了防篡改和密码学证明，并且总是存在于一个三方世界中：颁发者 → 持有者 → 验证者。
• **可验证凭证 API：**一个 REST/HTTP 服务接口，用于在后端系统（颁发者、钱包、验证者）之间颁发、存储、出示和验证 VC。
• **数字凭证 API (DC API)：**一个浏览器/操作系统 API（JavaScript + 原生底层实现），允许网站以保护隐私的方式请求用户设备侧的钱包出示任何支持的数字凭证（VC、ISO mDoc、SD-JWT…）。

可以将 VC 视为数据模型，VC API 视为后端规范，而 DC API 则是将凭证呈现给 Web 的前端实现。第 1 层（数据模型层）以上的所有内容都与格式无关；以下的所有内容都取决于凭证格式。

端到端流程（示例：在线年龄验证）：

1. **颁发（VC API - 颁发者 ↔ 钱包）：**州车管局颁发一份可验证凭证，声明“持有者已满 18 岁”。
2. **存储（钱包应用 - 操作系统）：**凭证及其加密证明存储在用户的钱包中。
3. **请求（通过 DC API 的 navigator.credentials.get() - 网站 → 浏览器）：**啤酒商店网站请求：“请出示用户年满 18 岁的证明。”
4. **出示（DC API 分派给钱包 → OpenID4VP (协议) → VC 载荷）：**钱包显示一个同意界面，用户批准后，钱包发回一个可验证出示。
5. **验证（VC API - 啤酒商店后端）：**网站后端验证签名和颁发者的 DID/公钥；授予访问权限。

请注意数据是 VC，Web 上的传输是 DC API，底层的交换协议是 OpenID4VP，而服务器端的检查则使用 VC API。

为什么存在这种划分：

• **可互操作的数据模型（密码学证明、选择性披露）：**由 VC 数据模型（及其他格式）解决。
• **用于后端系统的标准 REST 端点：**由 VC API 解决。
• **保护隐私的钱包 ↔ 网站握手：**由 DC API 解决。
• **不同的信任级别/文件类型（政府 ID vs. 课程证书）：**通过在 DC API 底层使用正确的格式（ISO mDoc 用于高保障 ID；W3C VC 用于一般声明）来解决。

关键要点：

1. “数字凭证”是一个总称。
2. 可验证凭证是一种内置密码学可验证性的数字凭证。
3. VC API 是用于 VC 生命周期操作的服务器到服务器的底层实现。
4. 数字凭证 API 是浏览器到钱包的桥梁，最终让这些凭证能够顺利流入 Web 应用，无论它们具体是什么格式。
5. 这三个部分是互补的，而不是竞争的——它们位于同一技术栈的不同层次，共同在开放的 Web 上实现安全、以用户为中心的身份验证。

在探讨了数字凭证的参与者和整体分层架构之后，本文现在将更深入地探讨表示层，特别关注数字凭证 API 及其当前状态。

作为表示层的关键组件，数字凭证 API 是一项正在开发的 Web 标准，旨在为网站提供一种安全、标准化的方式来请求和接收来自用户数字钱包的数字身份信息。这项工作主要由 W3C 的联合身份工作组（FedID WG）负责，于 2025 年 4 月从 FedID 社区组迁移而来。官方规范草案可在此处找到：https://w3c-fedid.github.io/digital-credentials/。

截至 2025 年 10 月，该 API 已在 Chrome 141（2025 年 9 月 30 日）和 Safari 26（2025 年 9 月 15 日）的稳定版本中发布。Chrome 的实现是协议无关的，同时支持 OpenID4VP 和 ISO 18013-7 附录 C，而 Safari 仅支持 org-iso-mdoc 协议。Chrome 通过其 Credential Manager 系统在 Android 上原生支持此功能，并且还通过 CTAP/BLE 支持的 QR 码切换在桌面上支持跨设备数字凭证 API。

该 API 通过 navigator.credentials.get() 启用对数字凭证的请求，从而扩展了现有的凭证管理 API。根据 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.");
    }
}

此示例摘自此处。

数字凭证 API 实质上充当了一个安全的包装器或中介。它允许浏览器协调身份信息的请求，利用底层操作系统的能力来发现符合请求的可用钱包和凭证。然后，浏览器和操作系统可以呈现一致的用户界面，供用户选择凭证并授权其发布，通过确保用户同意并防止网站静默访问敏感数据来增强安全性和隐私。响应中的实际凭证数据旨在对浏览器本身保持不透明（加密），解密和解释由信赖方和钱包/持有者处理。

数字凭证 API 被设计为协议无关的，这意味着它可以支持各种用于凭证交换的底层协议。然而，有两个主要的协议家族是当前实现和讨论的核心：org.iso.mdoc（源自 ISO 18013-5 及其扩展 ISO 18013-7 “附录 C”）以及 OpenID 基金会的 OpenID for Verifiable Presentations (OpenID4VP) 和 OpenID for Verifiable Credential Issuance (OpenID4VCI) 规范。

• 起源与标准化：org.iso.mdoc 指的是移动文档的数据格式和交互模型，主要用于移动驾驶执照 (mDL)，由国际标准化组织 (ISO) 和国际电工委员会 (IEC) 进行标准化。基础标准是 ISO/IEC 18013-5，它定义了 mDL 应用、数据结构以及使用 NFC、蓝牙或二维码等技术进行现场（近距离）出示的协议。ISO/IEC 18013-7 将此扩展到支持在线/远程出示 mDL。协议字符串 "org.iso.mdoc" 在 ISO/IEC TS 18013-7（附录 C）中被特别定义，用于与数字凭证 API 等 API 配合使用。

• 数据模型：mdocs 具有基于 CBOR（简洁二进制对象表示法）的严格定义的数据结构，以实现紧凑性和效率。它为常见的驾驶执照属性指定了命名空间和数据元素，并支持强大的加密安全功能，包括颁发者认证、设备绑定、持有者认证（通过肖像）、会话加密和选择性披露。

• 典型用例：主要是政府颁发的身份文件，如驾驶执照和国民身份证。它专为高保障场景设计，包括现场（例如，交通检查、受限商品的年龄验证）和在线（例如，访问政府服务、银行开户的远程身份验证）。

• 起源与标准化：OpenID4VP（用于出示）和 OpenID4VCI（用于颁发）是由 OpenID 基金会制定的规范。它们扩展了 OAuth 2.0 以支持可验证凭证的交换。这些是开放标准，旨在为各种凭证类型（不仅仅是政府凭证）实现广泛的互操作性。截至 2025 年初，OpenID4VP 处于高级草案阶段（例如，截至 4 月的第 28 版草案）。OpenID4VCI 也日趋成熟。
• 数据模型：OpenID4VP/VCI 被设计为凭证格式无关的。它们可以携带 JSON/JSON-LD 或 JWT 格式的 W3C 可验证凭证 (VCs)、mdocs、SD-JWTs 和其他格式。交互模型涉及来自验证者 (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 颁发 mDoc 和 SD-JWT-VC 格式的 PID 和 mDL。这样一个大规模项目对两种协议家族的双重支持，凸显了它们的重要性。然而，这一方向并非没有批评，一些观察家指出，受“美国科技巨头”公司严重影响的数字凭证 API 可能会被深度整合到最终的 EUDI 钱包规范中。有人担心非欧盟实体可能对欧盟关键基础设施产生影响，这在诸如此 GitHub 讨论等社区论坛中有所讨论。

数字凭证 API 的浏览器格局现已形成，Chrome 141 和 Safari 26 已于 2025 年 9 月发布了稳定版支持。不同浏览器在方法和支持水平上存在显著差异。

Chrome 已在 Chrome 141（2025 年 9 月 30 日）中发布了数字凭证 API。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
}

Android 的 Credential Manager 原生支持 OpenID4VP 进行出示和 OpenID4VCI 进行颁发，允许 Android 应用作为凭证持有者和验证者使用这些标准。Google 指出钱包支持正在增长；Google Wallet 是早期采用者，已宣布支持的还有 Samsung Wallet 和 1Password。

在本文的早期版本中，我们曾预测 Apple 的方法将与 Google 的不同，它会专注于 org.iso.mdoc 协议。为提供历史背景，我们的理由如下：

正如我们正确预测的那样，WWDC25 证实了这一策略。Safari 26 (iOS/iPadOS/macOS) 于 2025 年 9 月 15 日发布，带来了对数字凭证 API 的支持，并确认其实现仅支持 org-iso-mdoc 协议（带连字符）用于出示。

这在 WWDC25 的会议 在 Web 上验证身份文件 中有详细说明。该 API 允许网站从存储在 Apple Wallet 或第三方文档提供商应用中的身份文件（如驾驶执照）请求可验证信息。

Apple 实现的关键要点：

• 仅支持 MDOC：该 API 仅使用协议字符串 "org-iso-mdoc"，基于 ISO/IEC 18013-7 附录 C 标准。Safari 实现的数字凭证 API 不支持 OpenID4VP。
• 仅用于出示：该 API 用于现有凭证的出示（验证）。颁发到 Apple Wallet 或其他应用中仍然是一个独立的、非浏览器的过程。
• 以用户为中心且安全：流程由用户手势发起，并利用“部分请求”机制，即操作系统首先在沙盒中解析和验证请求，然后再将其传递给钱包应用，从而增强安全性。
• 可扩展至应用：除了 Apple Wallet，第三方应用可以通过实现新的 IdentityDocumentServices 框架和应用扩展来充当文档提供商。
• 跨设备支持：从非 Apple 平台进行跨设备出示时，在 QR 码切换后使用 CTAP 进行近距离通信；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 已正式对当前形式的数字凭证 API 表示负面标准立场。他们的担忧是全面的，根植于其保护用户隐私、自主权以及确保一个开放、公平的 Web 的使命。

Mozilla 提出的主要担忧包括：

• 隐私风险：如果对数字凭证的请求在琐碎的交互中变得普遍，可能会导致个人数据共享增加，在线匿名性降低。
• 用户排斥：不能或选择不使用数字凭证的个人可能会被排除在在线服务和社区之外的风险。政府颁发的凭证作为主要用例，可能与个人的身份呈现选择不符。
• 互操作性问题：担心凭证格式的激增会导致生态系统碎片化，而不是一个普遍可互操作的生态系统。
• 选择性披露：担心如果没有强大的不可链接性保证，或者如果用户不完全理解正在共享的内容，选择性披露的隐私优势可能会被削弱。
• 信任和用户自主权的集中化：担心该 API 可能导致信任的进一步集中化和用户自主权的减少，从而延续现有的社会权力不平衡。

Mozilla 承认，这样的 API 可能比现有的临时凭证出示方法提供更多实用性，但强调新的 Web 平台功能必须证明能够从整体上改善 Web，并优先考虑用户的利益。尽管 W3C 理事会否决了一项与这些担忧相关的正式反对意见（以允许工作在 W3C 内部进行，而不是在可能不那么透明的场所），但理事会确实建议工作组积极努力减轻这些潜在危害。

表 1：浏览器对数字凭证 API 和协议的支持情况（2025 年 10 月）

对于打算请求和验证用户数字凭证的组织（信赖方或 RP），当前的形势需要仔细的战略规划。

鉴于 Safari（2025 年 9 月 15 日发布）通过数字凭证 API 仅支持直接的 org-iso-mdoc 交互（ISO 18013-7 附录 C），而 Chrome（2025 年 9 月 30 日发布）是协议无关的，同时支持 OpenID4VP 和 ISO 18013-7 附录 C (mdoc)，旨在覆盖最广泛用户群的 RP 应准备好支持基于这两种方法的交互。

这意味着构建能够执行以下操作的系统：

1. 通过 navigator.credentials.get() API 发起凭证请求，并根据浏览器检测或用户代理能力指定不同的协议参数（"org-iso-mdoc" 用于 Safari 或 "openid4vp" 用于 Chrome/OID4VP 流程）。
2. 处理可能直接以 mdoc 格式（ISO 18013-7 附录 C）或通过 OpenID4VP 以 vp_token 形式返回的响应，然后需要解析该响应以提取底层凭证（其本身可能是 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 的后端进行不同的解析和验证逻辑。

对于希望颁发数字凭证并为持有者提供钱包应用的实体来说，操作系统环境起着至关重要的作用。

在钱包创建、系统集成以及与数字凭证 API 的交互方面，钱包颁发者在 iOS 和 Android 上面临着截然不同的环境。

• Android：通常提供一个更开放的生态系统。Android Credential Manager 包含一个 Holder API，允许第三方原生应用注册为凭证持有者。这些已注册的持有者应用随后可以参与由系统协调的凭证出示流程，响应来自数字凭证 API（通过 Chrome）或原生应用验证者的请求。Android 还明确支持 OpenID4VCI 进行凭证颁发，允许用户选择兼容的第三方钱包来接收新颁发的凭证。虽然原生应用是实现完整凭证持有者功能的主要焦点，但该系统旨在实现更广泛的参与。

• iOS：Apple 对其生态系统保持着更严格的控制。虽然第三方钱包应用可以存在于 App Store 上，但它们作为系统级凭证持有者进行深度集成以处理高保障凭证（如用于 Apple Wallet 的 mDL）的能力通常受制于 Apple 的特定流程和授权。例如，向 Apple Wallet 添加身份证是一个受控流程，涉及州颁发机构和 Apple 的验证。对于 Safari 中的数字凭证 API，交互很可能会受到严密管理，主要关注从授权来源（即 Apple Wallet 本身和已注册的第三方文档提供商应用）出示的 org.iso.mdoc。

Apple 的“围墙花园”方法早已确立，其数字凭证的实现也不例外。然而，WWDC25 明确了第三方参与的路径。

虽然 Apple Wallet 是州 mDLs 等凭证的主要内置提供商，但 Apple 为原生 iOS 应用引入了 IdentityDocumentServices 框架。这允许第三方开发者构建可以提供和出示其自身身份文件的应用。

要参与 Web 流程，原生应用必须：

1. 注册文档：使用 IdentityDocumentProviderRegistrationStore 向操作系统注册应用管理的 mdocs。此注册包括文档类型和用于请求签名的受信任证书颁发机构。
2. 实现应用扩展：向项目添加一个“身份文档提供商” UI 应用扩展。当应用在基于 Web 的验证流程中被选中时，此扩展负责向用户显示授权 UI。

这意味着，虽然在 iOS 上创建一个完全集成的钱包需要构建一个原生应用并使用 Apple 的特定框架——而不是像 PWA 这样的 Web 技术——但对于第三方应用来说，有一个明确但严格控制的机制，可以与 Apple Wallet 一起充当文档提供商。这证实了与 Safari 中数字凭证 API 的交互由操作系统管理，然后操作系统将请求分派给 Apple Wallet 或任何其他已注册并获得授权的文档提供商应用。

数字凭证 API 代表了数字身份领域的重大进步，为身份验证和凭证出示提供了一种更安全、以用户为中心且保护隐私的方法。随着 Chrome 141（2025 年 9 月 30 日）和 Safari 26（2025 年 9 月 15 日）现已发布稳定版支持，该 API 已从实验阶段进入生产就绪阶段。随着生态系统的不断发展，信赖方和钱包颁发者都必须适应并拥抱这项新技术的潜力。随着形势的变化，我们将不断更新本文。

然而，挑战依然存在。在不同凭证格式、协议和钱包实现之间实现真正的全球互操作性是一项艰巨的任务。解决像 Mozilla 这样的组织提出的关于隐私、排斥和用户自主权的合理担忧，对于确保这些技术服务于人类至关重要。不同的方法——Chrome 的协议无关实现与 Safari 的仅支持 mdoc 的焦点——意味着信赖方和钱包颁发者在可预见的未来必须在一个双协议的环境中导航。