数字凭证与 Passkey：两者的异同与结合

• 🔑 Passkey：用于安全登录。 它们能证明“你是谁”（身份验证），并有效对抗网络钓鱼。
• 📄 数字凭证：用于提供可验证的证明。 它们能证明“关于你的事实”（证明，例如你的身份、技能），并且你可以控制分享哪些内容。
• 🤝 两者的结合点： 两者都使用强加密技术，相比密码，提供了更好的安全性和更流畅的用户体验。
• 🎯 两者的区别： Passkey 主要用于“访问”服务。数字凭证则用于“提供关于你自己的已验证信息”。

数字世界正在飞速变化。这种变化不仅是因为传统的密码和共享密钥屡屡失效，还因为网络钓鱼和 AI 驱动的深度伪造等攻击手段变得越来越高明，难以察觉。这些高级威胁甚至能骗过谨慎的用户，让旧的身份验证方式变得不可靠。这清楚地表明，数字加密证明是确认某人身份的唯一真正安全的方式。在这种严峻形势下，我们迫切需要更安全、更方便用户且“可通过加密验证”的在线交互方式。这一需求催生了两项关键技术：已被广泛使用的 Passkey，以及刚刚起步的数字凭证。这些技术不依赖于越来越容易伪造的人工核对声明，而是利用机器可验证的加密证明来建立真正的信任。

得益于苹果、谷歌、微软等大公司以及 FIDO 联盟的大力支持，Passkey 在 2023-2025 年间的使用率大幅跃升。基于可靠的 W3C WebAuthn 标准，Passkey 是对脆弱的共享密钥的一次根本性变革。它们不使用密码，而是采用公钥加密技术。在这种技术中，安全存储在用户设备上的私钥会对来自信赖方 (Relying Party, RP) 的挑战进行签名。这既能证明用户拥有该密钥，又不会暴露密钥本身。

这种加密技术使得 Passkey 极难被网络钓鱼攻击——这是一个巨大的优势，因为网络钓鱼攻击变得越来越狡猾，有时甚至使用深度伪造技术来使其看起来更真实。由于 Passkey 与其创建时所针对的特定网站或应用绑定，用户不会意外地在虚假网站上使用它。这是旧式登录方法的一个常见问题，这些方法很容易受到此类高级伎俩的攻击。Passkey 还阻止了密码重用以及数据泄露后凭证填充攻击的危险。除了安全性，Passkey 还极大地改善了登录体验：它更快，通常只需一次生物识别扫描（如面容 ID 或指纹），用户无需记住或输入长密码。这种安全性与易用性的结合使其迅速普及。

与此同时，通常保存在数字身份钱包中的数字凭证也变得越来越受关注。欧盟数字身份钱包 (EUDI Wallet) 就是这一趋势的一个很好的例子。

与主要用于“身份验证”（通过证明你控制一个私钥来证明“你是谁”）的 Passkey 不同，数字凭证（基于 W3C 可验证凭证 (VCs) 或 ISO mdocs 等标准）关注的是“密码学可验证的证明”（通过数字签名的声明来证明“关于你的事实”）。能够强力验证这些声明非常重要，尤其是在深度伪造技术可以制作出以假乱真的传统证据的今天。没有加密检查，即使是专家也很难分辨真伪。它们让人们能够以一种密码学安全、尊重隐私（通过让用户只分享必要信息）且可由机器核查的方式，数字携带和展示已验证的信息——如姓名、出生日期、驾照、学历或职业证书。

这两种技术的兴起并非巧合。它表明了行业正在从中心化的、基于密码的身份系统，向更去中心化、以用户为中心、建立在加密信任之上的模式转变。密码是网络安全中一个众所周知的薄弱环节。旧的共享身份信息的方式通常笨拙、不安全，或者共享过多数据，损害了用户隐私。Passkey 直接修复了身份验证的弱点。数字凭证则处理了在用户控制下安全共享属性的问题。两者都使用类似的加密技术，并越来越依赖于平台集成和安全硬件，这表明业界正在共同努力，以大幅改进我们的数字身份系统。

虽然 Passkey 处理“登录”，数字凭证处理“证明属性”，但它们使用相似的加密基础，并在建立可信的数字交互中扮演互补的角色。这一点我们非常需要，因为当前像狡猾的网络钓鱼和深度伪造等威胁，使得旧的、非加密的身份验证方式变得不安全。这就引出了一个主要问题：Passkey 和数字凭证是如何连接的，它们如何在日常用户场景中协同工作？

本文将探讨这种协同作用。我们将审视它们的异同、支持它们的技术协议、它们对安全硬件的共同依赖，以及它们如何在用户注册、带升级认证的登录和设备迁移等场景中相互衔接。我们还将探讨像数字凭证 API 这样的新兴浏览器标准是如何旨在连接这两个世界的。本文特别关注这两种技术之间的“相互作用”，作为对已有的数字凭证 API 更深入技术探讨的补充。

要理解 Passkey 和数字凭证如何协同工作，首先必须掌握它们各自的特点以及支撑它们的技术层次。

下表提供了一个高层次的比较：

这个比较突显出，虽然两者都利用加密技术来建立信任，但它们的主要功能和典型使用模式有显著不同。Passkey 专为频繁、安全的身份验证而优化，而数字凭证则擅长在用户同意的情况下提供可验证的属性。

Passkey 是通过几个关键标准的交互而实现的：

• WebAuthn (Web Authentication): 这个 W3C 标准定义了 Web 应用程序用于与验证器交互以注册 (navigator.credentials.create()) 和验证 (navigator.credentials.get()) Passkey 的 JavaScript API。它充当了信赖方 (RP) 的 Web 应用程序与用户浏览器或操作系统之间的桥梁。WebAuthn 扩展了 W3C 的通用凭证管理 API。

• CTAP (Client to Authenticator Protocol): 由 FIDO 联盟定义，CTAP 规定了客户端（浏览器或操作系统）如何与验证器设备通信。这可以是一个内置于设备中的平台验证器（使用像 TPM 或 Secure Enclave 这样的安全硬件），也可以是一个漫游验证器，如 USB 安全密钥，甚至是一部手机作为另一台设备的验证器。CTAP2 是与 FIDO2 和 Passkey 对齐的版本，支持 USB、NFC 和低功耗蓝牙 (BLE) 等多种传输方式。

• 高级信任信号和设备绑定（同步 Passkey 的考量）： 随着 Passkey 发展为可在设备间同步（“多设备凭证”），信赖方 (RP) 有时需要识别在身份验证期间使用的具体物理设备以进行风险评估。早期的想法，如 devicePubKey 和 supplementalPubKeys 扩展，试图解决这个问题，但后来被放弃了。FIDO 联盟的信任信号工作组现在正在开发替代方案。这里的主要思想是，一个带有同步 Passkey 的验证器“也”可以创建和使用与设备绑定的第二对密钥。在身份验证期间，验证器可以同时提供来自主同步密钥和这个第二设备绑定密钥的签名。这将让 RP 能够识别一个特定的受信任设备。这意味着即使主 Passkey 在多个设备间同步，也可以减少摩擦（例如，跳过额外的挑战），而不会失去同步 Passkey 的主要好处：跨设备可用性。虽然目前还没有最终的标准，但这样的功能将满足需要高保证级别的 RP 的关键需求，让他们能更好地发现新设备的使用或满足内部的强客户认证 (SCA) 规定。

同样，数字凭证生态系统依赖于一套协议和新兴的 API 来运作：

• 数字凭证 API: 这是一个新兴的 W3C 规范工作，旨在扩展 navigator.credentials.get() API，以允许 Web 应用程序以标准化的方式从用户的数字钱包中请求可验证凭证。它的作用类似于 WebAuthn，但专注于 VC 而不是 Passkey。
• OpenID for Verifiable Presentations (OpenID4VP): 这定义了一个基于 OAuth 2.0 的协议，规定了验证方（请求凭证的 RP）如何从持有者的钱包中请求 VC。关键元素包括 presentation_definition（指定所需的凭证和声明）、作为授权服务器的钱包，以及将可验证呈现返回给验证方的 vp_token。
• OpenID for Verifiable Credential Issuance (OpenID4VCI): 作为 OpenID4VP 的补充，该标准规范了发行方如何将 VC 交付给持有者的钱包，同样使用 OAuth 2.0 机制。它涉及凭证提议、预授权或授权码流程以及专用的凭证端点等概念。
• ISO 标准（例如 ISO/IEC 18013-7, ISO/IEC 23220）： 这些国际标准对于移动驾照 (mDL) 和其他类型的移动文档 (mdoc) 尤其重要。ISO 18013-5 定义了核心的 mDL 数据结构和离线呈现（NFC, BLE），而 ISO 18013-7 和 23220 则规定了在线呈现机制，包括 REST API 和与 OpenID4VP 的集成配置文件（18013-7 的附录 B）。像 Google Wallet 和 Apple Wallet 这样的平台都利用了这些 ISO 标准。

尽管用途和协议不同，Passkey 和数字凭证共享着一些基础的构建模块：

• 非对称加密： 两者都严重依赖公私钥对。Passkey 使用私钥在身份验证期间证明所有权。数字凭证使用发行方的私钥对凭证进行签名，确保其真实性和完整性，而持有者可能会使用自己的私钥对包含该凭证的呈现进行签名。
• 安全硬件： 保护私钥至关重要。这两种技术都极大地受益于集成到现代设备中的安全硬件组件：
  • TPM (Trusted Platform Module): 一种常用于笔记本电脑和台式机的专用芯片，提供安全的密钥生成、存储和加密操作。它通常被像 Windows Hello 这样的平台验证器使用。
  • Secure Enclave: 苹果公司基于硬件的密钥管理器，与 iPhone、iPad 和 Mac 上的主处理器隔离，用于保护包括 Passkey 私钥在内的敏感数据。
  • Android Keystore System / StrongBox Keymaster: Android 提供了一个硬件支持的 Keystore，通常使用专用的安全处理器 (StrongBox Keymaster) 实现，为 Android 设备上的加密密钥提供强有力的保护。虽然一些密码管理器使用“Strongbox”这个名字，但操作系统提供的底层安全硬件元件才是这里的关键推动者。

使用“相同”的安全硬件元件（TPM、Secure Enclave、Android 的硬件支持 Keystore）来进行 Passkey 操作和潜在地保护数字钱包内的私钥，创造了显著的协同效应。平台不需要为每个功能配备单独的安全芯片。相反，它们可以使用单一、强大的硬件基础和相关的操作系统 API（如用于 Android Keystore 或苹果 Secure Enclave 的 API）来强力保护身份验证凭证 (Passkey) 和证明凭证 (VC)。这使得开发更容易，提高了安全性的一致性，并充分利用了现有的平台投资。

此外，浏览器的凭证管理 API (navigator.credentials) 是一个关键的组织层。它首先由 WebAuthn 为 Passkey 进行了扩展，现在又被数字凭证 API 为 VC 进一步扩展。这指向一个明确的计划：为 RP 提供一个请求不同凭证的主要方式，并为用户提供一个熟悉的选择方式（比如通过 Android 的凭证管理器或内置的浏览器密码管理器）。这将隐藏像 CTAP、OID4VP 和 ISO 等协议的复杂技术细节，为开发者和用户简化了操作。

从信赖方 (RP) 的角度来看，理解如何有效地集成和利用 Passkey 与数字凭证，对于增强安全性、改善用户体验和满足监管要求至关重要。本节分析 RP 如何在不同的常见场景和生态系统中部署这些技术。

Passkey 和数字凭证的最佳集成策略因具体用例及其相关的风险状况和要求而有很大差异。下表提供了常见场景的高层次比较：

生态系统场景比较

图例：

• VC 角色 🆔： 描述在“主要交互”中的角色，承认 VC 在各种场景中常用于初始注册/KYC。
• 需要设备绑定？🔗： 指的是除了标准的 Passkey 源绑定之外，是否需要明确的设备绑定，这对于同步 Passkey 尤其重要。
• 欧盟 EUDI 钱包强制要求*：此场景反映了即将实施的 eIDAS 2 法规下的要求，预计在最终实施法案生效后约 36 个月适用（可能在 2020 年代末）。

这个比较提供了一个快速概览；以下各节将从 RP 的集成角度深入探讨每个场景的具体细节。

• 目标： 快速、低摩擦的访问，具有良好的基线安全性。
• 可能的流程：
  • 主要身份验证： Passkey 将占主导地位。它们的抗网络钓鱼能力和无缝的用户体验（通常只是生物识别/PIN）使其成为在频繁登录场景中替代密码的理想选择。
  • 数字凭证的角色： 在核心登录中作用极小。VC 可能会在登录后“选择性地”用于特定操作，如年龄验证（例如，购买限制商品）、基于已验证属性的个性化（例如，会员状态），或在初次注册时加快个人资料填写。
• 相互作用： Passkey 处理核心登录；VC 则保留用于可选的、基于属性的交互。

• 目标： 高保证级别的登录，以及在必要时提供已验证的身份断言。
• 可能的流程：
  • Passkey 作为独立的 2FA/MFA： 当在登录仪式中进行用户验证（PIN/生物识别）时，Passkey 内在地满足了双因素认证的要求。它们结合了：
    • 拥有物： 对私钥控制权的证明。
    • 所知物/固有物： 通过 PIN 或生物识别进行的用户验证。这使得 Passkey 登录本身就是一种强大的、抗网络钓鱼的 MFA 方法，足以满足许多高保证场景的需求，而无需为实现 2FA 而增加一个单独的第二步。
  • 身份验证的升级（一次性）： 当服务必须“明确验证身份”，而不仅仅是验证一个回头客时，就需要一个额外的步骤，这时数字凭证就派上用场了。当深度伪造技术可以令人信服地伪造视觉或文件形式的身份证明时，这种强大的加密检查至关重要。只有来自可信来源的数字加密证明才能可靠地确认一个属性。这可能在以下情况中需要：
    • 初始注册期间。
    • 对于需要确认身份属性的特定高风险操作。在这些情况下，RP 在 Passkey 登录后，会从用户的钱包中请求一个特定的可验证凭证（例如，PID、国家身份凭证）的呈现。
  • 用于恢复的身份： 一旦用户的身份得到强力验证（例如，通过 VC 呈现升级），这个已验证的身份信息就有可能被用于安全的账户恢复流程。例如，如果用户丢失了他们所有的 Passkey 验证器，呈现一个高保证级别的身份凭证可以作为重新获得访问权限和注册新 Passkey 过程的一部分。
• 相互作用： Passkey 为身份验证提供了强大的、独立的 2FA/MFA。VC 在需要时被战略性地用于明确的身份验证，并且这个已验证的身份也可以支持安全的账户恢复机制。

• 目标： 简化、安全的结账或支付发起，最大限度地减少用户摩擦。
• 可能的流程：
  • 支付认证： Passkey 非常适合用于向用户的支付服务提供商 (PSP) 账户（例如，PayPal）进行身份验证，或直接在商家的结账流程中进行验证。这取代了密码，并为发起支付提供了一个快速、安全的确认。
  • 注册/KYC： 在与 PSP 或商家进行“注册”或账户设置阶段，VC 仍然至关重要，它提供了启用支付功能所必需的已验证身份信息（KYC/AML 检查）。
  • 交易摩擦问题： 在核心支付授权流程中引入一个单独的可验证凭证呈现步骤（需要与数字身份钱包交互）会比无缝的 Passkey 确认步骤增加显著的摩擦。这种对用户体验的干扰可能会损害转化率，因此不适合典型的低摩擦支付场景。
• 相互作用： Passkey 保护支付行为本身的身份验证。VC 处理建立支付账户所需的、通常是一次性的身份证明/KYC，但被排除在关键的、对摩擦敏感的支付确认步骤之外。（关于直接使用数字凭证“作为支付工具”的复杂主题，包括不同钱包类型和新兴浏览器 API 如何启用或与此类支付专用 VC 交互，将在我们即将发布的补充文章中详细探讨：数字凭证与支付。）

• 目标： 通过从传统的身份验证方法升级，实现安全的银行访问，并显著减少欺诈，特别是与网络钓鱼相关的欺诈。
• 可能的流程：
  • 替代传统 MFA： 许多金融机构目前依赖密码加上易受网络钓鱼攻击的第二因素，如短信 OTP。Passkey 提供了一个优越得多的替代方案，它通过单一的用户手势提供了本质上抗网络钓鱼的强身份验证。
  • 使用 Passkey 进行主要登录： 采用 Passkey 进行主要登录，由于其抗网络钓鱼的特性，能立即增强安全性。Passkey 的加密性质减轻了困扰传统凭证的最常见攻击向量。
  • 基于风险的升级 - 谨慎考虑设备信号： 对于更高风险的操作（例如，大额转账、更改联系方式），金融机构可能会考虑升级验证。虽然与 Passkey 相关的设备绑定信号是一个选项，但其必要性应仔细评估。主要 Passkey 身份验证本身的抗网络钓鱼能力已经大大减轻了许多风险。
  • 基于结果的安全与欺诈减少： Passkey 实现的网络钓鱼风险显著降低是一个关键因素。一种基于结果的安全方法，专注于身份验证方法的强度和抗网络钓鱼能力，可以带来可观的欺诈减少。像 Passkey 这样的抗网络钓鱼因素的权重远高于增加更多易受网络钓鱼攻击的因素。这必须是金融机构从旧方法迁移时的核心战略。
  • 用于注册/身份证明的 VC： 与其他场景一样，VC 对于稳健的初始 KYC/AML 以及使用已验证信息安全地更新客户身份属性至关重要，为银行关系建立了可信的基础。
• 相互作用： Passkey 作为一种强大的、抗网络钓鱼的主要身份验证方法，极大地降低了来自传统系统的欺诈风险。设备信号用于升级是一个战术选项。Passkey 的内在强度应为基于风险的安全态势提供信息，可能减少对额外的、抗网络钓鱼能力较弱的因素的过度依赖。VC 提供基础的身份保证。

• 目标： 遵守 eIDAS 2 法规（第 5f 条）的要求，即特定信赖方（公共机构、受监管行业的大型私营实体、VLOPs）必须接受欧盟数字身份钱包，从而在法律要求时，既能实现保护隐私的假名登录，又能进行高保证的身份/属性验证。
• 可能的流程：
  • 假名登录（默认）： 用户发起登录。RP 请求通过 EUDI 钱包进行身份验证。钱包使用其内置的“假名密钥”——一个存储在设备认证安全元件 (WSCD) 中的、与硬件绑定、RP 范围的 WebAuthn 常驻密钥——来验证用户。这提供了强大的、符合 SCA 的身份验证（拥有物 + 用户验证），同时默认情况下保持用户的公民身份为假名。
  • 身份/属性升级（法律要求时）： 当且仅当 RP 根据欧盟或国家法律有特定的法律依据（例如，PSD2、AML、电信注册）要求身份验证或特定属性时，它才会启动第二步。RP 从钱包请求呈现（通过 OpenID4VP）必要的个人身份数据 (PID) 或合格属性证明 (QAA)。用户必须明确同意分享这些已识别的数据。
  • 钱包与 RP 认证： 该流程涉及相互认证。RP 向钱包验证自己的身份（基于其官方注册），钱包则向 RP 证明其真实性和凭证的有效性，这都利用了安全硬件 (WSCD) 和相关的认证基础设施。
• 相互作用： EUDI 钱包作为一个统一的验证器。其集成的 WebAuthn Passkey（假名密钥）处理标准登录，提供强大的、保护隐私的身份验证。钱包的 VC 功能则被选择性地调用，用于明确的、法律强制的身份或属性披露，确保默认情况下的数据最小化。

在这个不断发展的领域中航行需要战略规划。以下是给信赖方 (RP) 的一些关键考量。

对于 RP 来说，今天的主要行动应该是启用并鼓励用户使用 Passkey 进行身份验证。Passkey 已经标准化，得到平台的广泛支持，并在安全性（抗网络钓鱼）和用户体验（更快、更简单的登录）方面提供了立竿见影的巨大好处。这意味着可以减少对密码和不安全的 MFA 方法（如短信 OTP）的依赖。它还可以降低因密码重置和账户恢复而产生的支持成本。争取广泛使用 Passkey，为用户身份验证建立一个现代、安全的基础。虽然初期采用率可能较慢，但事先向用户宣传其好处并简化注册流程，可以帮助他们开始使用。

虽然 Passkey 本身在实现稳健认证方面迈出了重要一步，并且可以满足强客户认证 (SCA) 的要求，但一些组织可能有更严格的内部合规框架或特定担忧，尤其是在同步 Passkey 方面。对于面临此类情况、合规部门寻求进一步保证的信赖方 (RP) 来说，了解可以采取额外措施来补充 Passkey 部署是很有用的。这些措施可以帮助弥合感知的 SCA 差距或满足那些更高的内部要求。一种常见的策略是利用设备信任信号，像 PayPal 这样的服务就采取了这种方法。

例如，PayPal 允许用户将设备标记为“已记住”，正如其帮助页面所述：

这意味着，如果用户从一个已记住的设备（他们拥有的东西）用密码（他们知道的东西）登录，PayPal 在许多情况下可能会认为这足以满足 SCA。然而，他们也声明，“在某些情况下，我们可能仍会要求您进行另一次验证，以确保您的账户安全。” 这可能包括通过短信发送一次性密码或提示通过 PayPal 应用进行确认。

这种方法允许在受信任的设备上提供更流畅的用户体验，同时在风险较高或法规要求时仍提供升级认证的机制。RP 可以考虑类似的模式，其中主要认证（如 Passkey）和设备信任（如果需要，可以在 WebAuthn 的直接机制之外管理）的结合可以帮助弥合 SCA 合规差距。然而，要在 WebAuthn 框架内实现一种更集成、更标准化的设备特定信任信号方法，注意力转向了该领域的持续发展。

关于这种用于更强设备信任的 WebAuthn 集成方法，高安全环境中的 RP 应了解其历史和未来方向。过去的 WebAuthn 扩展提案，如 devicePubKey 和 supplementalPubKeys，旨在提供这些设备特定的信任信号。这些尝试是为了解决同步 Passkey 的安全考量，同步 Passkey 虽然为大规模采用提供了至关重要的可用性，但引入了不同的风险状况（例如，依赖云账户恢复），与设备绑定密钥相比。这类扩展背后的想法是让 RP 能够通过检查来自特定绑定到所用物理设备的密钥的签名，来获得额外的保证层，“即使主 Passkey 本身是同步的”。

尽管这些特定的扩展（devicePubKey 和 supplementalPubKeys）已被停用，但为同步 Passkey 获取更强设备绑定信号的挑战依然存在。因此，RP 应关注该领域“后续解决方案”的开发和标准化。这样的解决方案可以帮助 RP 更好地判断风险（例如，区分来自已知、受信任设备的登录和来自新同步设备的登录），而无需强迫所有用户使用不太方便的设备绑定 Passkey。这为 RP 提供了一个比仅仅“同步 vs. 设备绑定”更复杂的选择。同步 Passkey（通常符合 AAL2）提供了最大的便利性和最佳的采用机会，对消费者应用至关重要。设备绑定 Passkey（可能符合 AAL3）提供了最高的保证级别，但使用起来可能更困难。已停用扩展的目标是找到一种折中方案——通过增加一个设备特定的信任信号来提高同步密钥的安全性。这有助于在云同步被攻破时减少一些风险，而不会失去同步的所有便利性。因此，RP 应寻找旨在实现这一目标的“后续解决方案”。最佳策略将取决于 RP 的具体风险承受能力、用户群以及任何新标准的成熟度。

除了 WebAuthn 内部用于设备信任的具体机制外，一些信赖方 (RP)——特别是银行、保险和支付服务等行业的 RP——正开始评估数字凭证（可验证凭证，或 VC）作为其身份和安全策略中的一个补充，甚至是下一步的组成部分。

推动这一兴趣的一个重要因素是与数字凭证相关的强大设备绑定，尤其是在安全的数字身份钱包中管理时。这些钱包可以利用硬件支持的安全性（如 Secure Enclave 或 TPM）来保护凭证和用于呈现它们的私钥。发行方和钱包提供商还可以强制执行策略，使某些高价值凭证天生就是设备绑定的，这为高保证场景提供了有吸引力的控制水平。

认识到这一点至关重要：虽然这种增强的设备绑定能力对这些 RP 来说是一个引人注目的特性，但数字凭证的“主要目的”（证明属性和声明）与 Passkey（用户身份验证）是不同的。Passkey 确认“用户是谁”，而数字凭证确认“关于用户的事实是什么”。尽管在目的上有这个根本区别，但钱包中持有的 VC 的强大安全特性使其成为寻求增加额外保证的 RP 积极考虑的领域。这自然而然地将讨论引向了这些数字身份钱包的提供商以及支持此类凭证发行、存储和呈现的生态系统。

虽然 Passkey 提供直接的身份验证，但数字凭证 (VC) 是通过数字身份钱包来管理并呈现给信赖方的。这些钱包，无论是原生平台解决方案（如 Apple Wallet、Google Wallet）还是第三方应用程序（如 EUDI 钱包），都在不断发展，以使用像数字凭证 API 这样的新兴浏览器标准，来实现更流畅的在线身份验证（例如，年龄检查、共享数字身份属性）。

不同钱包类型的详细机制、特定平台对 VC 集成的策略（包括苹果对浏览器交互的 mDoc 重点与安卓通过其凭证管理器对 OpenID4VP 的更广泛支持）、这些钱包如何促进属性证明，以及任何支付功能的完全独立的考量，都是复杂的话题。这些将在我们即将发布的补充文章中深入探讨：数字凭证与支付。

本文将继续专注于 Passkey 用于身份验证和数字凭证用于证明属性的一般作用之间的基础性相互作用。

Passkey 和数字凭证，虽然主要目的不同，但它们代表了现代、更安全、以用户为中心的数字身份未来的两大支柱。理解它们如何关联并相互支持，是构建下一代在线服务的关键。

根据这些技术的当前状态和发展轨迹，信赖方有两个关键的行动项目脱颖而出：

• 立即在各处部署 Passkey： 标准已经成熟，平台支持广泛，其相对于密码的优势清晰而巨大。将 Passkey 作为用户身份验证的默认目标，以立即增强安全性和可用性。
• 在涉及 AML/KYC 的地方添加钱包升级： 对于需要更高保证或特定已验证属性的流程——例如满足反洗钱 (AML) / 了解你的客户 (KYC) 法规、进行可靠的年龄验证或确认专业资格——集成可验证凭证的呈现流程，以获取可通过加密验证的属性。在一个充满复杂数字伪造和深度伪造的时代，这对于信任身份和声明是不可或缺的。在可行的情况下使用数字凭证 API，但要实施稳健的二维码/深层链接回退方案，以确保在 API 稳定之前实现跨平台覆盖。这可以在不给每次登录增加负担的情况下提供有针对性的高保证。

展望未来，我们可以期待更多的融合和改进：

• 改进的凭证可移植性： 设备间的转移方法可能会变得更好。这可能超越用于 Passkey 的 CTAP 2.2 跨设备认证，包括更顺畅地在钱包之间转移 VC 的方法，尽管这方面的标准化还远未成熟。
• 统一的浏览器 API： 数字凭证 API 可能会成熟并在各浏览器中得到更一致的支持。这将为 RP 提供一个更标准的方式，通过 navigator.credentials 请求 Passkey 和 VC。
• 统一的用户体验： 最终，用户应该会看到使用 Passkey 进行身份验证和使用 VC 呈现属性之间的技术差异越来越小。平台凭证管理器和钱包可能会在幕后平滑地管理这些交互。它们将使用共享的加密工具和安全硬件，让用户只需通过熟悉的生物识别或 PIN 提示来批准请求，无论使用的是 Passkey 还是 VC。此外，像持续被动认证 (CPA) 这样的概念，它通过行为生物识别和其他信号在后台持续验证用户，可以进一步增强这种无缝的安全性，并可能与像 Passkey 这样的主动验证器协同工作。

要实现这个集成的未来，需要在标准、平台支持以及应用使用方面做更多的工作。通过现在使用 Passkey 并深思熟虑地添加数字凭证，组织可以为向一个无密码且让用户对自己的数据有更多控制权的数字世界转变做好准备。