数字凭证 API (2025)：Chrome 与 Safari (WWDC25)

最后更新：2025 年 7 月 15 日 (WWDC25 之后)

各大主流浏览器对数字凭证 API 的支持情况快速概览：

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

数字凭证是当前身份领域的热门话题。随着我们的生活与数字世界的联系日益紧密，以安全、以用户为中心且保护隐私的方式在线声明我们的身份和资格，变得前所未有的重要。传统方法已显老态，市场对更强大解决方案的需求也变得非常迫切。

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

多年来，可靠且安全地证明身份一直是网络架构中的一个持续挑战 (链接)。虽然互联网促进了前所未有的连接和信息交换，但它也为虚假陈述和欺诈开辟了新途径。

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

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

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

Want to try digital credentials yourself in a demo?

Try Digital Credentials

要理解数字凭证的运作方式，需要了解其中涉及的关键参与者以及实现其功能的不同技术层面。

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

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

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

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

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

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

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

核心术语：

• 数字凭证： 任何机器可读的凭证（带条形码的 PDF、ISO mDL、W3C VC、SD-JWT 等）。“数字”一词并未说明其是否具有加密可验证性。
• 可验证凭证： 一种数字凭证，由 W3C VC 数据模型定义。它增加了防篡改和加密证明，并且总是存在于一个三方世界中：颁发者 → 持有者 → 验证者。
• 可验证凭证 API： 一个用于后端系统（颁发者、钱包、验证者）之间颁发、存储、出示和验证 VC 的 REST/HTTP 服务接口。
• 数字凭证 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 底层使用正确的格式（高保证 ID 使用 ISO mDoc；一般声明使用 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 年，该 API 仍被描述为正在经历重大变化。这凸显了它正处于积极开发阶段。尽管如此，其潜力巨大。Chrome 是第一个发布公开成果的浏览器，其源试用允许开发者试验其功能。Chrome 还在 Android 上通过其凭证管理器系统原生支持此功能，并且最近还发布了对桌面端跨设备数字凭证 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() {
    // 检查是否支持数字凭证 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();
 
            // 使用来自后端的出示请求调用数字凭证 API
            let dcResponse = await navigator.credentials.get({
                signal: controller.signal,
                mediation: "required",
                digital: {
                    requests: [oid4vp],
                },
            });
 
            // 将加密响应发送到后端进行解密和验证
            // 为简洁起见，此处省略
        } catch (error) {
            console.error("Error:", error);
        }
    } else {
        // 后备方案，仅作说明
        alert("此浏览器不支持数字凭证 API。");
    }
}

此示例取自此处。

数字凭证 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、蓝牙或 QR 码等技术进行现场（近距离）出示的协议。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 可验证凭证 (VC)、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 颁发 mDoc 和 SD-JWT-VC 格式的 PID 和 mDL。这样一个大规模项目对两种协议家族的双重支持，凸显了它们的重要性。然而，这一方向并非没有批评，一些观察家指出，深受“美国科技巨头”公司影响的数字凭证 API，可能会被深度整合到最终的 EUDI 钱包规范中。有人担心非欧盟实体可能对欧盟关键基础设施产生影响，正如在此 GitHub 讨论等社区论坛中所讨论的那样。

数字凭证 API 的浏览器格局仍在形成中，其方法和支持水平存在显著差异。

Google Chrome，尤其是在 Android 上，是数字凭证 API 的早期采用者和实现者。他们已经运行了源试用，并将其与 Android 的原生凭证管理器集成。Chrome 的实现主要利用 OpenID4VP 作为通过 navigator.credentials.get() API 调用请求凭证的协议。虽然 OpenID4VP 本身是格式无关的，可以携带 org.iso.mdoc 或 W3C 可验证凭证作为载荷，但 Google 的实际重点似乎是将 OpenID4VP 流程作为传输机制。Android 的凭证管理器也原生支持 OpenID4VP 用于出示和 OpenID4VCI 用于颁发。这使得 Android 应用可以使用这些标准充当凭证持有者和验证者。

在本文的先前版本中，我们预测 Apple 的方法将与 Google 不同，会专注于 org.iso.mdoc 协议。为了历史背景，我们的推理如下：

正如我们正确预测的那样，WWDC25 证实了这一策略。在大会上，Apple 正式宣布在 Safari 26（将于 2025 年秋季随 iOS 26 和其他操作系统更新一起发布）中支持该 API，并确认其实现仅支持 org.iso.mdoc 协议进行出示。

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

Apple 实现的关键要点：

• 仅支持 MDOC：该 API 仅使用基于 ISO/IEC 18013-7 附件 C 标准的协议字符串 "org-iso-mdoc"。Safari 的数字凭证 API 实现不支持 OpenID4VP。
• 仅限出示：该 API 用于现有凭证的出示（验证）。颁发到 Apple 钱包或其他应用中仍然是一个独立的、非浏览器的过程。
• 以用户为中心且安全：流程由用户手势启动，并利用“部分请求”机制，即操作系统首先在沙箱中解析和验证请求，然后再将其传递给钱包应用程序，从而增强安全性。
• 可扩展至应用：除了 Apple 钱包，第三方应用可以通过实现新的 IdentityDocumentServices 框架和应用扩展来充当文档提供商。

Apple 提供了一个清晰的代码示例，说明信赖方如何使用该 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 已正式对当前的数字凭证 API 提案表达了**“负面”立场**。他们的担忧是全面的，根植于其保护用户隐私、自主权以及确保一个开放、公平的网络的使命。

Mozilla 提出的主要担忧包括：

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

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

表 1：浏览器对数字凭证 API 和协议的支持

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

鉴于拥有显著市场份额的 Safari 可能会优先通过数字凭证 API 进行直接的 org.iso.mdoc 交互，而 Chrome/Android 则强调 OpenID4VP（可以携带 mdocs 或其他可验证凭证格式），旨在实现最广泛覆盖的 RP 应准备支持基于这两种方法的交互。

这意味着构建能够实现以下功能的系统：

1. 通过 navigator.credentials.get() API 发起凭证请求，可能根据浏览器检测或用户代理能力指定不同的协议参数（“org.iso.mdoc”或“openid4vp”）。
2. 处理可能直接以 mdoc 格式或通过 OpenID4VP 以 vp_token 形式返回的响应，然后需要解析该响应以提取底层凭证（其本身可能是 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 指定他们需要的凭证类型和单个声明。然后，钱包会构建一个仅包含所请求信息的可验证出示，前提是凭证格式和钱包支持。

RP 需要将其特定的数据需求映射到这些不同的协议结构中。至关重要的是要理解在每种协议中选择性披露是如何实现和请求的细微差别，以确保只请求和处理最少必要的数据，从而遵守隐私最佳实践和数据最小化原则。钱包返回的已披露数据的格式和结构也可能不同，需要在 RP 的后端进行不同的解析和验证逻辑。

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

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

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

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

Apple 的“围墙花园”方法是众所周知的，其数字凭证的实现也不例外。然而，WWDC25 阐明了第三方参与的路径。

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

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

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

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

数字凭证 API 代表了数字身份领域的重大进步，为身份验证和凭证出示提供了一种更安全、以用户为中心且保护隐私的方法。随着生态系统的发展，信赖方和钱包颁发者都必须适应并拥抱这项新技术的潜力。随着形势的变化，我们将不断更新本文。

然而，挑战依然存在。在不同凭证格式、协议和钱包实现之间实现真正的全球互操作性是一项重大任务。解决像 Mozilla 这样的组织就隐私、排斥和用户自主权提出的合理担忧，对于确保这些技术服务于人类至关重要。当前浏览器支持和协议重点的碎片化意味着，信赖方和钱包颁发者在短期内必须在一个复杂的环境中前行。