--- url: 'https://www.corbado.com/zh/blog/passkeys-dongtai-lianjie-spc' title: '使用 Passkeys 实现动态链接：安全支付确认 (SPC)' description: '了解动态链接、Passkeys 和安全支付确认 (SPC) 如何增强数字支付。学习如何使用 Passkeys 实现动态链接。' lang: 'zh' author: 'Vincent Delitz' date: '2025-07-15T13:23:10.997Z' lastModified: '2026-03-25T10:04:15.692Z' keywords: '动态链接, 安全支付确认, spc' category: 'Passkeys Strategy' --- # 使用 Passkeys 实现动态链接：安全支付确认 (SPC) ## 1. 引言 在我们关于 [PSD2](https://www.corbado.com/blog/psd2-passkeys) 的四篇系列文章（第一部分、第二部分、第三部分和第四部分）中，我们探讨了 Passkeys 如何与 [PSD2](https://www.corbado.com/blog/psd2-passkeys) 引入的**强客户认证 (SCA)** 措施相结合。我们特别关注了 SCA 对访问银行应用程序所需的认证要素。SCA 的要求不仅适用于访问应用程序，也适用于远程发起和签署电子支付交易。此外，这些要求还需要使用一种称为**动态链接**的机制。在本文中，我们将解释什么是动态链接，并探讨如何有效利用 Passkeys 在当前和未来实现这一机制。 ## 2. PSD2 中的动态链接是什么？ **动态链接**是 [PSD2](https://www.corbado.com/blog/psd2-passkeys) 指令及其执行附录《监管技术标准》(RTS) 下的一项安全要求。引入这一概念是为了增强电子支付的安全性，通过认证码确保每笔交易都与特定金额和特定收款人唯一关联。这种链接可以防止付款人认证后交易详情被修改，从而降低欺诈风险。电子支付包括网上[银行](https://www.corbado.com/passkeys-for-banking)软件中的银行转账，也包括在商户网站上的信用卡支付。 ### 2.1 PSD2 中的定义和重要性 根据 PSD2 指令和附带的 RTS，动态链接被定义为一个过程，确保“生成的认证码特定于付款人在发起电子支付交易时同意的金额和收款人”（PSD2 第 97(2) 条）。这意味着支付详情的任何变更都会使认证码失效，需要重新认证。 动态链接在 PSD2 中至关重要，因为它直接解决了与远程电子交易相关的安全风险，这类交易特别容易受到中间人攻击等不同类型的欺诈。 通过这种方式保护交易，动态链接显著降低了未经授权交易的可能性。 ### 2.2 金融交易中动态链接的要求 RTS 第 5 条详细说明了动态链接中认证码的要求。这些要求包括： - **付款人知情**：付款人被告知支付交易的金额和收款人。 - **认证码唯一**：为每笔交易生成的认证码必须是唯一的，且不能用于任何其他交易。 - **认证码具有特定性**：生成和接受的认证码必须特定于付款人确认的交易金额和收款人身份。金额或收款人的任何变更都会导致认证码失效。 - **安全传输**：在认证的所有阶段，包括认证码的生成、传输和使用，都必须保持交易金额和收款人的机密性、真实性和完整性。 在阐明了动态链接的这些技术要求后，下一节我们将探讨 Passkeys 作为一项新技术如何提供帮助。我们将探索它们在简化和保护支付认证流程方面的潜力，使动态链接不仅更强大，也更方便用户使用。 ## 3. 如何使用 Passkeys 实现动态链接？ 我们首先来分析一下在动态链接中使用 Passkeys 的不同方案。 ### 3.1 方案一：在动态链接中标准使用 Passkeys 在这种方法中，Passkey 本身充当一个加密**断言**，直接用作认证码。交易过程中发出的质询是专门为反映特定交易详情（如金额和收款人）而生成的，并与这些信息一同存储。当用户使用其 Passkey 授权交易时，会生成一个唯一的、加密安全的签名，该签名可以被验证并与交易一同存储。这个响应不仅作为一个强大的认证因素，还直接将批准与特定的交易详情绑定，严格遵守 PSD2 对动态链接的要求。 ### 3.2 方案二：通过 WebAuthn 质询增强加密证明 一种更高级的集成方式是将额外的交易详情编码到 WebAuthn 质询本身（技术上 PSD2/RTS 并未要求）。这种方法建议将收款人和金额的加密哈希值以及其他随机数据一同纳入质询中。通过这样做，认证过程不仅通过 Passkey 验证了用户的身份，还以加密方式断言了交易详情的完整性。这种方法提供了一个额外的安全层，确保在最终支付时可以检测到任何对金额或收款人详情的篡改。加密证明成为认证码不可变的一部分，从而增强了高风险交易环境中的信任和安全性（更多信息请见[此处](https://www.w3.org/2024/Talks/Fime_W3C_6feb24.pdf)）。 ### 3.3 标准 Passkey 方案的局限与挑战 我们来分析一下这两种方案的局限和挑战。 #### 3.3.1 无法保证付款人知情 在动态链接（特别是支付认证）的背景下使用 Passkeys 的一个局限性是，缺乏具体文档或保证来确保付款人已准确获知收款人信息。 虽然 Passkeys 提供了一种安全的用户认证方法，但它们本身并不能验证所有交易详情（尤其是关于收款人的详情）是否已正确显示给付款人。 这个问题并非 Passkeys 独有；它是各种在线支付系统面临的共同挑战。确保付款人在发起支付前充分了解并同意所有交易详情，对于维持信任和安全至关重要。 #### 3.3.2 用例：第一方与第三方支付情境 将 Passkeys 集成到动态链接中的最显著局限性在于第一方和第三方注册的区别。 **什么是第一方支付情境？** ✔️ 在第一方支付情境中，用户直接在**发行方**或银行自己的互联网服务和域名上进行交互。Passkeys 可以无缝注册和认证。例如，一家银行可以在自己的网站上注册一个 Passkey，并用它来授权从其网上[银行](https://www.corbado.com/passkeys-for-banking)软件发起的支付。在这里，Passkeys 可以无缝工作。银行可以确保 Passkey 在其域内使用，从而保持对支付环境和交易安全的控制。 请参阅我们关于万事达卡 Passkey 实现的博文，了解第一方支付情境的案例。 **什么是第三方支付情境？** 在第三方支付情境中，用户在不同域名（例如 amazon.com）的**商户**页面上进行结账，并希望发起一笔信用卡交易： - ✔️ **情况 1 – 用户已拥有其发行方/银行的 Passkey：** **商户**会显示一个 [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)，用户可以在其中使用 Passkey 进行认证。这个 [IFRAME](https://www.corbado.com/blog/iframe-passkeys-webauthn) 由底层的 [3-D Secure](https://www.corbado.com/glossary/3d-secure) 2 (3DSS/EMV 3DS) 流程显示，该流程已用于需要支持 SCA 和动态链接的信用卡交易。 - ❌ **情况 2 – 用户没有其发行方/银行的 Passkey：** 同样，商户会显示 [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)。由于尚无可用 Passkey，用户通过现有的认证因素（例如短信一次性密码或智能手机上的原生[银行](https://www.corbado.com/passkeys-for-banking)应用）进行认证。此时，在成功认证后，本应是为用户注册 Passkey 的理想时机，但**由于 WebAuthn 标准的限制，这是不允许的**。在跨域 iframe 中注册 Passkeys 是不被允许的（主页面和 iframe 的域名需要相同）。像下面截图中那样的逐步注册将无法实现： ![dynamic-linking-passkeys-check-out-faster.png](https://www.corbado.com/website-assets/dynamic_linking_passkeys_check_out_faster_edb79b9e22.png) **未来是否会支持在跨域 iframe 中注册 Passkey？** 虽然 Passkeys 在单一域内的第一方支付情境中为动态链接提供了很好的解决方案，但在第三方支付情境中，WebAuthn Level 2 目前尚不支持。然而，好消息是跨域 iframe 支持已经纳入正在进行的 [WebAuthn Level 3](https://www.corbado.com/blog/passkeys-prf-webauthn) 规范中（预计将于 2024 年底普遍可用）。不过，浏览器仍需跟上规范的步伐： | **浏览器/标准** | **第一方情境** | **第三方情境** | | --------------------------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------------------- | | **在跨域 iframe 中注册 Passkeys：** | | | | WebAuthn Level 2 要求 | ✔️ [详情](https://issues.chromium.org/issues/40258856) | ❌ | | WebAuthn Level 3 要求 | ✔️ [详情](https://issues.chromium.org/issues/40258856) | ✔️ [详情](https://issues.chromium.org/issues/40258856) | | Chrome 中已实现 | ✔️ [详情](https://issues.chromium.org/issues/40258856) | ✔️ [详情](https://issues.chromium.org/issues/40258856) | | Firefox 中已实现 | ✔️ [详情](https://issues.chromium.org/issues/40258856) | [积极信号](https://github.com/mozilla/standards-positions/issues/964) 表示将实现 | | [Safari](https://github.com/WebKit/standards-positions/issues/304) 中已实现 | ✔️ [详情](https://issues.chromium.org/issues/40258856) | 等待实现信号 | | **在跨域 iframe 中使用 Passkeys 认证：** | | | | WebAuthn Level 2 要求 | ✔️ | ✔️ | | WebAuthn Level 3 要求 | ✔️ | ✔️ | | Chrome 中已实现 | ✔️ | ✔️ | | Firefox 中已实现 | ✔️ | ✔️ | | Safari 中已实现 | ✔️ | ✔️ | 截至目前，到 2024 年，主流浏览器对跨域注册 Passkeys 的覆盖似乎有望成为现实，这将解除在支付中使用 Passkeys 的最重要技术限制。 ## 4. 未来方案：安全支付确认 (SPC) 由 Google 发起的 W3C 工作组曾多次尝试（例如 BasicCard、PaymentHandler 或 PaymentManifest）改善网络支付体验。但到目前为止，没有一个方案获得显著的市场覆盖和使用。随着反欺诈法规的日益增多，[电子商务](https://www.corbado.com/passkeys-for-e-commerce)交易中的支付流程摩擦仍然是一个巨大挑战。由 Google 和 Stripe 发起的**安全支付确认**标准是目前最有前途的、基于 WebAuthn 标准的方案。 ### 4.1 SPC 标准的目标是什么？ 安全支付确认 (SPC) 解决了 PSD2 SCA 的所有重要元素，包括动态链接要求，同时试图改善用户体验。 - **提供浏览器原生用户体验**：[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) 利用浏览器在不同商户网站和依赖方之间提供一致且简化的认证体验。这种方法旨在通过一致的外观和保证付款人知情，来增强交易安全性，超越通常通过 iframe 中渲染内容所能达到的水平： ![Dynamic Linking Passkeys SPC Merchant](https://www.corbado.com/website-assets/dynamic_linking_passkeys_spc_merchant_8009b1ef5a.png)_示例来自 [https://www.w3.org/press-releases/2023/spc-cr/](https://www.w3.org/press-releases/2023/spc-cr/)_ - **提供加密证据**：该标准确保用户确认支付详情的加密证明被生成并包含在 WebAuthn **断言**中，而无需将信息编码到 WebAuthn 质询中。 - **允许第三方注册**：与 WebAuthn Level 2 标准不同（其中**认证器**的注册必须在第一方情境中进行），[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) 允许直接从跨域 iframe 注册 Passkeys。此功能解决了支付生态系统中的常见用例，并为商户和支付处理商提供了更简便的集成。正如我们上面讨论的，此功能已经是底层标准下一版本的一部分，因此将来可能会从 [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) 中移除。 - **跨域支付认证**：SPC 扩展了 WebAuthn 的功能，允许任何源为交易生成**断言**，即使它利用了来自另一个依赖方的凭证（无需离开页面）。在这种情况下，甚至不需要来自商户/发行方的 iframe。此功能在涉及多方（商户 + 发行方/银行）的认证过程中特别有用，**断言**随后可以传输到原始依赖方（账户提供商，例如银行）进行验证。 ![Cross Origin Authentication Payments](https://www.corbado.com/website-assets/cross_origin_authentication_payments_1fe18ec791.png) 上图示例取自 SPC Explainer，展示了跨域支付认证的概念：在使用 SPC 的支付流程中，用户在整个交易过程中都停留在**商户**网站上（蓝色高亮部分）。Web 浏览器（绿色部分）保持显示**商户**的源，并呈现一个预定义的、不可自定义的对话框，其中包含动态链接所需的所有重要信息（金额 + 收款人）以确认交易。用户确认后，操作系统（橙色部分）处理验证交易所需的生物识别认证。 这些目标说明了 SPC 致力于改善在线支付的安全性和用户体验，旨在简化认证流程，同时在整个数字支付领域保持高安全标准。 ### 4.2 SPC Passkey 流程会是怎样的？ 我们来逐一了解 SPC 将允许的所有可能流程，并与标准 Passkeys 进行比较，以便我们理解其优势。 | | **SPC Passkeys** | **Passkeys** | | ---------------------------- | ---------------- | ------------ | | **发行方网站认证/注册** | ✔️ | ✔️ | | **商户网站在 iframe 中注册** | ✔️ | ❌/✔️ | | **商户网站在 iframe 中认证** | ✔️ | ✔️ | | **商户网站跨域认证** | ✔️ | ❌ | 从这里我们可以看到，最重要的区别是在商户网站的 iframe 内进行注册（目前 Passkeys 尚不支持，见上文讨论），以及全新的跨域认证可能性。我们来逐一分析。 #### 4.2.1 SPC Passkeys：直接在发行方/银行网站上注册/认证 这是一个直接在万事达卡页面上注册 SPC Passkey 的模拟示例。如您所见，Passkey 创建是在通过短信一次性密码完成认证后立即提供的。 ![SPC Passkeys Issuer Bank](https://www.corbado.com/website-assets/spc_passkeys_issuer_bank_3d68dd2043.png) 在这种情况下，通信过程看起来像一个标准的 Passkeys 注册流程，因为这完全发生在第一方情境中。 ![SPC Passkeys Flow](https://www.corbado.com/website-assets/spc_passkeys_flow_1324c4d2d7.png)_取自 [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ 这个 SPC Passkey 现在可以在商户网站上用于认证，在商户网站的 iframe 中使用，以及用于跨域认证（见下文）。 #### 4.2.2 SPC Passkeys：在支付过程中于商户网站上注册/认证 正如我们之前讨论的，在商户网站上注册 SPC Passkey 的过程通常发生在支付交易期间，在 3-D Secure (3DS) 流程的背景下。该流程旨在通过增加一个验证持卡人身份的额外认证步骤，来增强在线信用卡和借记卡交易的安全性。 在支付交易期间，当 3DS 流程启动时，认证过程通过托管在**商户**网站（例如 amazon.com）上但由支付服务提供商或发卡银行（例如 [mastercard](https://www.corbado.com/blog/mastercard-passkeys).com）控制的 iframe 来进行。这个 iframe 为客户提供了一个安全的环境，以使用现有的认证因素来验证其身份。 一旦客户使用这些传统因素（例如短信一次性密码或银行应用）成功认证自己，就有机会为未来的交易注册一个 SPC Passkey。**由于 SPC 标准允许从 iframe 内进行跨域 Passkey 创建，这将是可行的。** 在 iframe 中注册此 Passkey 通常需要客户执行一个操作，生成并将 Passkey 绑定到其信用卡，例如在兼容设备上验证其指纹或面部识别。请记住，iframe 由支付服务提供商（例如 [PayPal](https://www.corbado.com/blog/paypal-passkeys)）或发卡银行（例如[mastercard](https://www.corbado.com/blog/mastercard-passkeys).com）控制。因此，SPC Passkey 是直接与发行方/银行而不是商户创建的。简化的流程如下： ![SPC Passkeys Merchant Flow](https://www.corbado.com/website-assets/spc_passkeys_merchant_flow_267ffda65a.png)_取自 [https://developer.chrome.com/docs/payments/register-secure-payment-confirmation](https://developer.chrome.com/docs/payments/register-secure-payment-confirmation)_ 在 [https://spc-merchant.glitch.me/](https://spc-merchant.glitch.me/)，Google 建立了一个演示应用程序，可以通过 Chrome 在 Windows 和 Mac 上访问，它展示了如何从 iframe 内部实现这一功能： ![SPC Passkey Demo App](https://www.corbado.com/website-assets/spc_passkey_demo_app_4458eb6295.png) 它还允许直接体验银行的网站，该网站托管在：[https://spc-rp.glitch.me/reauth](https://spc-rp.glitch.me/reauth)。在这个例子中，商户和发行方/银行之间不需要带外 API 通信——一切都由浏览器处理。使用现有 Passkey 进行认证的方式与在 iframe 内相同。 #### 4.2.3 SPC Passkeys：跨域认证 在下面的例子中，我们看到了跨域认证，用户已经向万事达卡注册了一个 SPC Passkey。示例商户网站 (decorshop.com) 可以触发跨域认证。**主要且重要的区别在于，在认证过程中，商户/发行方页面始终不可见**。浏览器与操作系统结合，呈现预定义的支付用户体验（由 SPC 标准的浏览器实现提供）和认证模态框（WebAuthn 标准）。商户和发行方/银行之间的通信在后台处理。 ![SPC Passkeys Cross-Origin Authentication](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_3cc4d40619.png)_原始来源（部分调整）：[https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf](https://www.w3.org/2023/Talks/mc-passkeys-20230911.pdf) (Mastercard)_ ![SPC Passkeys Cross-Origin Authentication Flow](https://www.corbado.com/website-assets/spc_passkeys_cross_origin_authentication_flow_d6d05cdf6b.png)_原始来源（部分调整）：[https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams](https://github.com/w3c/secure-payment-confirmation/tree/main/sequence-diagrams)_ 使用跨域认证时，商户通过某种形式的 API 与发行方/银行通信，以交换有关现有凭证的信息（上图序列图中的 #2）。如果凭证存在且用户浏览器支持 SPC，则认证开始。最后，**断言**通过现有的协议（如 EMV 3DS）一路返回给发行方/银行，最终在发行方/银行处进行加密验证（#16）。 由于断言还包括有关浏览器显示的信息，因此满足了动态链接的所有要求。这在用户体验和客户支付体验改进方面将是一个重大进步。 ### 4.3 安全支付确认标准的状态如何？ 安全支付确认 (SPC) 标准是在线支付认证领域一个有趣的发展，旨在增强安全性的同时简化用户体验。截至目前，Google Chrome 是唯一支持某种形式 SPC 的主流浏览器。然而，这并不奇怪，因为该标准部分是由 Google 发起的。其他主流浏览器，如苹果的 Safari 和 Mozilla Firefox，则明显缺乏承诺，没有明确的信号表明他们计划支持 SPC。特别是苹果正在推广其自有的专有标准 **Apple Pay**，似乎对其他支付标准不感兴趣。 SPC 与 WebAuthn 的关联使得开发过程更加困难。这是因为 SPC 标准中的任何增强或修改都需要仔细评估，以防止冗余并确保它们提供优于现有功能的真正改进。目标是完善 SPC，以满足支付流程中 WebAuthn 未能完全覆盖的特定需求，例如直接集成到结账流程中，并提供更用户友好的认证体验，可以在不同商户网站之间无缝操作。 随着 SPC 的不断发展，其在不同浏览器中的采用对于广泛实施至关重要。像 Google 这样的主要参与者的参与表明了一个积极的方向，但更广泛的支持对于将 SPC 确立为在线支付行业的标准是必要的。 ## 5. 未来方案二：确认扩展 上述挑战，特别是围绕**付款人知情**的问题，促使 [WebAuthn 工作组](https://github.com/w3c/webauthn/pull/2020)正在进行一项名为**确认扩展**（以前称为“txAuthSimple”）的工作，该扩展属于 WebAuthN 标准。其目标是允许**认证器**或浏览器/操作系统（在特权 UI 中）向用户显示交易详情，并确保**依赖方**收到用户确实确认了这些详情的加密证明。这直接解决了[第 3.3.1 节](#331-payer-awareness-cannot-be-assured)中描述的“无法保证用户知情”的问题。 ### 5.1 确认扩展的目标是什么？ 与安全支付确认 (SPC) 提供专用的、由浏览器驱动的对话框类似，确认扩展解决了“所见即所签”(WYSIWYS) 的问题。其主要目标是： - **可信的交易详情显示**：该扩展不是让网页内容来显示金额和收款人，而是利用设备的安全屏幕或操作系统控制下的浏览器 UI 对话框。 - **加密证据**：**认证器**（或客户端平台）对所显示的确切文本记录进行签名。通过验证此签名，**依赖方**可以确认用户看到了正确的详情。 - **认证器不支持显示时的后备方案**：在硬件认证器无法显示文本的情况下，浏览器可以显示文本并将其包含在 \[=client data=] 中。这是一个较弱的保证，但允许更广泛的兼容性。 ### 5.2 确认扩展如何工作？ 该扩展向现有的 WebAuthn 扩展结构添加了一个新字段。依赖方提供一个名为 `confirmation` 的简单文本字符串（可带可选的基本格式）： ```webidl partial dictionary AuthenticationExtensionsClientInputs { USVString confirmation; }; ``` 当客户端（浏览器）收到此信息时，它会： 1. 通过一个特殊的确认对话框**提示**用户（让他们知道这不仅仅是一次基本登录）。 2. 如果认证器支持该扩展，则将相同的字符串作为 [CBOR](https://www.corbado.com/glossary/cbor) 数据**传递**给认证器。 3. 将任何认证器输出**返回**给依赖方。 如果认证器支持显示文本，它**必须**在完成用户验证之前显示该文本（例如，在其自己的屏幕或可信 UI 上）。然后，它在其签名输出中包含相同的字符串。 在依赖方一侧，验证步骤确保返回的 `confirmation` 文本与发送的文本**匹配**。如果缺少认证器扩展输出，但依赖方策略允许后备方案，则依赖方可以依赖来自客户端数据的 `confirmation` 值——这表明是浏览器而不是认证器显示了文本。 ### 5.3 它对动态链接为何重要？ 通过将**收款人**和**金额**嵌入此扩展中，用户可以在可信的显示界面上精确地看到他们正在授权的内容。用户的签名现在不仅反映了一个哈希质询，还反映了**确切的交易文本**。这对于 PSD2 的动态链接要求尤其有价值，因为： - 显示后对交易详情的任何不匹配或修改都会使签名无效。 - 依赖方可以证明在签名时向用户提供了正确的交易详情，从而比仅仅在质询中哈希数据更稳健地满足了 PSD2 的“付款人知情”要求。 ### 5.4 确认扩展的当前状态 虽然**确认扩展**仍在讨论中，但它代表了朝着更安全、更用户友好的交易流程迈出的关键一步。通过将其直接构建到 WebAuthn 规范中，它提供了： - **互操作性**：任何实现该扩展的认证器或客户端都将遵循相同的标准化格式。 - **灵活性**：依赖方可以强制执行更强的策略（要求认证器级别的显示），或者在需要时接受浏览器级别的后备方案。 - **更广泛的生态系统对齐**：它与 PSD2 等监管要求非常吻合，特别是在稳健的动态链接方面。 有关更多技术细节，您可以查看正在进行的讨论：[GitHub pull request #2020](https://github.com/w3c/webauthn/pull/2020)。总而言之，确认扩展也可以弥补标准 Passkey 流程中最后一个主要差距：提供用户同意时所见内容的**加密证明**，尽管其结构化程度不如安全支付确认。如果它能在浏览器和认证器供应商中获得支持，它可能成为提供 PSD2 动态链接及其他场景下所需的 WYSIWYS 安全保证的高度标准化方法。 ### 5.5 比较：SPC 和确认扩展有何不同 尽管 **SPC** 和**确认扩展**有着共同的目标，即在 WebAuthn 中加强动态链接，但它们在范围和方法上有所不同。下表突出了一些差异： | **比较标准** | **SPC** | **确认扩展** | | ------------------------------------------------------------------------- | ------------------------------------- | -------------------------------------------------------------------------------- | | **集成支付流程**
_（处理完整的结账、金额、收款人、UI 等）_ | ✔️ 包括一个标准化的浏览器支付对话框 | ❌ 仅专注于显示和签署一个文本字符串 | | **可信交易显示**
_（确保用户看到正确的收款人/金额）_ | ✔️ 基于浏览器的流程确保一致的用户体验 | ✔️ 认证器显示或浏览器显示 | | **后备处理**
_（如果认证器显示能力有限或没有）_ | ❌ 未专门为后备路径设计 | ✔️ 如果需要，依赖方可以接受客户端级别的显示 | | **动态链接之外的范围**
_（更广泛的目标，例如一键式流程、跨域认证）_ | ✔️ 旨在简化整个结账流程 | ❌ 严格来说是标准 WebAuthn 质询/响应的扩展 | | **当前成熟度与采用情况**
_（跨浏览器准备情况）_ | 除 Chrome 外采用率低；时间表不确定 | 在 [WebAuthn WG](https://github.com/w3c/webauthn/pull/2020) 中讨论中，但前景看好 | 本质上，SPC 试图提供一个全面的支付解决方案，并将其流程的一部分包含了动态链接。而确认扩展则在标准 WebAuthn 消息中解决了“所见即所签”的要求，而无需强加一个完整的支付流程。任何一种方法都可以促进 PSD2 合规，但每种方法都依赖于**浏览器**和**认证器**的支持才能带来实际的好处。 ## 6. 对发行方/银行的建议 因此，我们对发行方、银行和金融机构的建议是，仔细评估需要覆盖的用例，并监控生态系统的发展，因为 Passkeys 的便捷性将对现有的 SCA 和动态链接解决方案施加巨大压力，迫使其改善用户体验。客户将要求在 Web 上使用生物识别解决方案。目前，我们的操作建议是： - ✔️ **[在发行方/银行网站上发起的支付使用 Passkeys](https://issues.chromium.org/issues/40258856)：** Passkeys 是发行方/银行为其网站和应用直接实现动态链接的一个非常好的解决方案。它们可以与其他认证选项（如推送通知、电子邮件/短信一次性密码或 TOTP）相结合，以进一步增强高风险支付的安全性。当然，关于 SCA 合规性的考虑应始终是讨论的一部分（另请参阅我们关于 Passkeys 和 SCA 的四篇系列文章）。 发行方/银行可以自行实施一个建议的解决方案，因为 Passkeys 基于开放的 WebAuthn 标准。然而，这需要大量的专业知识，处理边缘情况，并持续跟上所有新的法规和技术发展。另一种选择是使用第三方认证提供商。例如，Corbado Connect 支持通过交易签名实现动态链接，利用调整后的 WebAuthn 质询。所有信息都记录在审计日志中。这不仅对金融机构有用，还可以用于各种签名（例如文件签名、高风险用户操作）。可选地，可以使用额外的短信或电子邮件一次性密码来进一步提高安全性。 - ❌ **在商户页面上的支付使用 Passkeys：** 目前还无法在商户页面上推广使用 Passkeys 进行支付。跨域用例仍在开发中，但可能在 2024 年底成为一个可行的选择。不过，在商户页面上使用 Passkeys 进行认证在今天已经是一个好主意，也可以用来开始收集 Passkeys，这些 Passkeys 将来也可以用于支付。 - ❌ **使用 SPC Passkeys 或确认扩展实现动态链接**：SPC 标准尚未达到成熟和支持的状态，无法在生产环境中使用。 总的来说，我们很高兴看到商户和银行已经开始参与该标准，并将其要求和支持添加到生态系统中。展望未来，金融机构和[电子商务](https://www.corbado.com/passkeys-for-e-commerce)平台应密切关注这些技术进步，并考虑如何将 Passkeys 集成到其系统中。随着法规的不断演变，保持领先地位至关重要，确保支付认证流程符合最新的安全标准，并为消费者提供安全、高效的用户体验，从而提高转化率并减少摩擦。 ## 6. 结论 当我们审视使用 Passkeys 实现动态链接时，很明显，虽然 Passkeys 有助于遵守 SCA 和动态链接要求，但与第三方服务的技术集成（WebAuthn 标准最初是为第一方情境设计的）带来了一些挑战。这些标准正在逐步演变，以更好地支持第三方场景，显示出其应用灵活性增强的趋势。安全支付确认 (SPC) 旨在进一步推动这种适应，目标是通过在各种商户网站上整合更用户友好和无缝的交互来增强支付认证流程。 然而，SPC 标准或确认扩展的进步和更广泛的接受度在很大程度上依赖于主流浏览器的采用——这一过程一直很缓慢，目前只有 Google Chrome 是唯一的支持者。这种缓慢的采用率可能会阻碍特别是 SPC 超越其当前状态，除非更多浏览器开始集成它。Passkeys 的持续发展和日益增长的吸引力预示着一个充满希望的方向，即依赖硬件安全模块 (HSM) 的系统（如安全飞地、TEE 和 TPM）也将在支付应用中发挥重要作用，因为这些技术提供了增强的安全性，可以使支付的动态链接不仅在银行网站发起的交易中，而且在第三方商户平台上也变得更加实用和舒适。 Passkeys 将其功能扩展到在线支付流程的潜力，凸显了在保护基于网络的交易和使互联网总体上成为一个更安全的地方方面的一个重要方面。