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

最后更新：2026 年 3 月 26 日

以下是主要浏览器对数字凭证 API (Digital Credentials API) 支持情况的快速概览：

数字凭证领域正如火如荼地发展。以下是关键进展和预测的快照：

Want to experience digital credentials in action?

Try Digital Credentials

自 2025 年 10 月以来有什么变化？

• 协议治理转变：W3C FedID WG 在 TPAC (2025 年 11 月) 取消了开放协议注册表，现在直接在规范中 硬编码支持的协议：OpenID4VP、OpenID4VCI 和 ISO 18013-7 Annex C。该 API 不再只是一个“单纯的传输通道 (dumb pipe)”。
• 发行功能到来：Chrome 143 启动了通过 navigator.credentials.create() 进行凭证发行的 Origin Trial，将 API 的功能扩展到了仅展示之外。
• Firefox 正在实施：尽管反对标准立场未变，Mozilla 还是在 Firefox 149 中合入了基础 DC API 代码，用户体验 (UX) 工作正在进行中。
• 欧盟有条件强制要求：EUDI 架构参考框架 (Topic F) 现在有条件地要求所有成员国钱包支持 DC API。
• 现实世界采用：加州 DMV 在其 OpenCred 平台 (2026 年 2 月) 中添加了 DC API 支持。

数字凭证 (Digital Credentials) 目前是身份认证领域的热门话题。随着我们的生活与数字领域的联系日益紧密，对安全、以用户为中心且保护隐私的在线身份和资格认证方式的需求从未如此迫切。传统方法已显老态，对更强大解决方案的需求显而易见。

在本文中，我们将探讨数字凭证 API 的现状，这一重要进展有望重塑我们在网络上交互身份信息的方式。我们将深入了解其底层机制、支持的协议、当前的浏览器采用情况，并为在这个快速发展的领域中摸索的依赖方 (Relying Parties) 和 钱包 发行方 (Issuers) 提供建议。

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

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

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

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

Want to experience digital credentials in action?

Try Digital Credentials

理解数字凭证的运作方式需要关注参与的关键角色以及启用其功能的不同技术层。

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

1. 发行方 (Issuer)：拥有关于主体的某些权威信息，并能发行证明该信息的数字凭证的实体 (例如：政府、大学、雇主)。
2. 持有者 (Holder)：信息的主体 (即用户)，从 发行方 接收凭证并将其存储在 数字钱包 中。持有者控制何时以及分享什么信息。
3. 验证方 (Verifier) (或 依赖方 Relying Party)：需要验证关于持有者的某些信息以授予服务或资源访问权限的实体 (例如：网站、在线服务)。验证方从持有者处请求必要的信息。

这个三方模型之所以重要，是因为它旨在让用户 (持有者) 控制自己的数据。与数据可能集中存储或在没有用户直接中介的情况下在各方之间共享的传统身份系统不同，该模型强调用户同意和选择性披露 (selective disclosure)。持有者决定在特定交易中分享凭证中的哪些信息片段，而不是通过出示整个凭证来泄露所有信息。

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

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

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

为了理解数字凭证的功能，将其可视化为一个分层模型很有帮助。每一层解决生态系统的不同方面，从数据格式本身到如何在 Web 浏览器中呈现给用户。本文主要关注 数字凭证 API (Digital Credentials API)，它在展示层 (Presentation Layer) 运行。

核心术语：

• 数字凭证 (Digital credential)：任何机器可读的凭证 (带条形码的 PDF、ISO mDL、W3C VC、SD-JWT 等)。“数字”一词并不代表具备加密可验证性。
• 可验证凭证 (Verifiable Credential)：一种数字凭证，由 W3C VC 数据模型定义。它增加了防篡改和加密证明，并且始终存在于三方世界中：发行方 → 持有者 → 验证方。
• 可验证凭证 API (VC API)：一种 REST/HTTP 服务接口，用于在后端系统 (发行方、钱包、验证方) 之间发行、存储、展示和验证 VC。
• 数字凭证 API (DC API)：一种浏览器 / 操作系统 API (JavaScript + 原生管道)，允许网站以尊重隐私的方式请求用户的设备端钱包展示任何支持的数字凭证 (VC、ISO mDoc、SD-JWT 等)。

可以将 VC 视为数据模型，VC API 视为后端规范，而 DC API 则是将凭证展示给 Web 的前端实现。第 1 层 (数据模型层) 以上的一切都是格式无关的；以下的一切都取决于凭证格式。

端到端流程 (示例：在线年龄验证)：

下图说明了这些层在现实场景中如何协同工作。

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

为什么存在这种划分：

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

关键要点：

1. “数字凭证”是总称。
2. 可验证凭证 是一种内置加密可验证性的数字凭证。
3. VC API 是用于 VC 生命周期操作的服务器到服务器管道。
4. 数字凭证 API (DC 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 Annex C，而 Safari 仅支持 org-iso-mdoc 协议。

重要更新 (2026 年 3 月)： 该 API 与协议的关系发生了根本性变化。在 2025 年 11 月的 TPAC 会议上，W3C FedID WG 达成共识 取消开放协议注册表，转而直接在规范中 硬编码一份有限的支持协议列表：openid4vp-v1-unsigned、openid4vp-v1-signed、openid4vp-v1-multisigned、org-iso-mdoc (用于展示) 以及 openid4vci-v1 (用于发行)。用户代理 (浏览器) 预计将拒绝未列出的协议。这使得工作组实际上成为了未来协议添加的守门人——这是一种深思熟虑的权衡，旨在对通过 API 流动的所有内容进行整体安全和隐私审查 (参见 当前工作草案)。

该规范现在还涵盖了通过 navigator.credentials.create() 进行的 凭证发行。Chrome 143 为此启动了一项 Origin Trial，允许网站使用 OpenID4VCI 触发钱包配置流程。然而，一个 钱包选择绑定漏洞 —— 恶意钱包应用可以拦截发行预授权码 —— 仍然是一个悬而未决的问题。政府发行方已表示，在该问题解决之前，他们不会采用浏览器中介的发行方式。

Chrome 通过其 凭证管理器系统 在 Android 上原生支持展示，并通过 CTAP/BLE 支持的二维码交接在桌面端支持 跨设备数字凭证 API。

该 API 扩展了现有的 凭证管理 API，启用了通过 navigator.credentials.get() 请求数字凭证的功能。根据 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() {
    // 检查是否支持 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。");
    }
}

此示例摘自 此处。

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

数字凭证 API 最初被设计为完全协议无关的，充当一个具有开放注册表的“单纯传输通道 (dumb pipe)”，任何协议都可以在此注册。然而，截至 2026 年 1 月，该规范 现在明确命名 了其支持的协议 —— 用户代理预计将拒绝未列出的协议。目前规范中硬编码的两大主要协议家族是：org.iso.mdoc (源自 ISO 18013-5 及其扩展 ISO 18013-7 "Annex 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 (Annex C) 中专门定义的，用于数字凭证 API 等接口。

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

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

• 起源与标准化：OpenID4VP (用于展示) 和 OpenID4VCI (用于发行) 是由 OpenID 基金会开发的规范。它们扩展了 OAuth 2.0 以支持 可验证凭证 的交换。这些是旨在实现各种凭证类型 (不仅仅是政府凭证) 广泛互操作性的开放标准。截至 2025 年初，OpenID4VP 处于高级草案阶段 (例如 4 月发布的 draft 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 进行展示和发行流程。参考实现包括支持传输 mDocs 的 OpenID4VP 和以 mDoc 和 SD-JWT-VC 格式 发行 PID 和 mDLs 的 OpenID4VCI。这样一个 大规模 项目的双重支持突显了这两个协议家族的重要性。

2026 年 3 月更新： 欧盟对数字凭证 API 的承诺变得更加具体。EUDI 架构参考框架 (ARF) Topic F 现在 有条件地要求 EUDI 钱包单元和依赖方支持 DC API 进行远程展示和证明发行流程。条件包括 DC API 达到 W3C 推荐标准状态，并满足有关功能、浏览器/操作系统中立性、隐私和拒绝服务保护的期望。欧洲钱包联盟 (EWC) 已将 DC API 测试用例纳入其一致性测试计划，NOBID 联盟 完成了使用 OpenID4VP 的支付试点 —— DC API 现在承载的正是同一协议。

然而，这一方向并非没有批评，一些观察家指出，深受“美国科技巨头”影响的数字凭证 API 可能会被深度整合到最终的 EUDI 钱包规范中。正如在社区论坛 (如 这个 GitHub 讨论) 中所讨论的，人们担心非欧盟实体对欧盟关键基础设施的潜在影响。另外，在规范中 硬编码 ISO 18013-7 引用 的决定招致了 Ping Identity 的反对，他们认为规范性地引用付费规范与开放网络原则相冲突 —— 当规范过渡到候选推荐标准时，这种担忧可能会演变成正式反对意见。

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

Chrome 在 Chrome 141 (2025 年 9 月 30 日) 中 发布 了数字凭证 API。Chrome 的实现是 协议无关 的：兼容 OpenID4VP 和 ISO 18013-7 Annex C (mdoc 在线)。桌面端通过 CTAP/BLE 支持 的通道 (二维码交接) 支持来自移动钱包的 跨设备 展示，响应对浏览器是不透明的。API 形态变为 navigator.credentials.get()；参数重命名：providers → requests，request → data。

特性检测：

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

Android 的凭证管理器原生支持 OpenID4VP 用于展示和 OpenID4VCI 用于 发行，允许 Android 应用充当凭证持有者和验证者，使用这些 标准。Google 指出钱包支持正在增长；Google 钱包 是早期采用者，Samsung Wallet 和 1Password 也已宣布支持。

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

正如我们正确预期的那样，WWDC25 证实了这一策略。Safari 26 (iOS/iPadOS/macOS) 于 2025 年 9 月 15 日 发布，支持数字凭证 API，确认其实陈 仅支持 org-iso-mdoc 协议 (带连字符) 进行展示。

这在 WWDC25 会议 Verify identity documents on the web 中有详细说明。该 API 允许网站请求存储在 Apple 钱包或第三方文档提供程序应用中的身份文档 (如驾驶执照) 的可验证信息。

Apple 实现的关键要点：

• 仅支持 MDOC：该 API 专门使用基于 ISO/IEC 18013-7 Annex C 标准的协议字符串 "org-iso-mdoc"。Safari 的数字凭证 API 实现中 不支持 OpenID4VP。
• 仅展示：该 API 用于现有凭证的展示 (验证)。发行到 Apple 钱包或其他应用仍然是一个独立的、非浏览器的流程。
• 以用户为中心且安全：流程由用户手势发起，并利用“部分请求”机制，即操作系统在将请求传递给钱包应用程序之前，首先在沙箱中解析和验证请求，从而增强安全性。
• 可扩展至 App：除了 Apple 钱包，第三方 App 还可以通过实现新的 IdentityDocumentServices 框架和 App 扩展来充当文档提供者。
• 跨设备支持：来自非 Apple 平台的 跨设备 展示在 二维码 交接后使用 CTAP 进行近场通信；JS 响应对浏览器保持加密/不透明。

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 可能导致信任更加集中化，用户自主权降低，从而延续现有的社会权力不平衡。

虽然 W3C 理事会否决了一项正式反对意见，该反对意见与这些担忧有关 (为了允许工作在 W3C 内部进行，而不是在可能不太透明的场所进行)，但理事会确实建议工作组积极努力减轻这些潜在危害。

2026 年 3 月更新 — 正在实施： 尽管正式的反对立场在 技术上保持不变，但 Mozilla 已开始 积极实施 数字凭证 API。2026 年第一季度，基础 DC API 支持 已合入 Firefox 149 (在偏好设置标志后)，在 meta bug 2004828 下跟踪。源代码 位于 mozilla-central 中，包括 DigitalCredential.cpp、WebIDL 绑定和 IPC 管道。桌面和 Android 权限提示的工作 (bug 2010091, bug 2010093) 正在进行中。

三位 Mozilla 工程师 —— John Schanck、Martin Thomson 和 Benjamin VanderSloot —— 是 W3C FedID 工作组的 活跃成员，Schanck 一直在为关键规范 PR 提供基于实施的实质性反馈，包括 凭证展示算法 和 请求准备算法。

这是一个重大进展：虽然 Mozilla 对该 API 潜在的滥用保持担忧，但显然它选择通过规范工作和实施从内部塑造该 API，而不是将设计权拱手让给其他浏览器供应商。这表明数字凭证 API 可能正朝着三大浏览器支持的方向发展，尽管 Mozilla 正在推动更强的隐私护栏 (包括提议的用于凭证请求的 透明度日志)。

表 1：数字凭证 API 和协议的浏览器支持 (2026 年 3 月)