动态链接中的生物识别与付款人意识

Corbado 的方法将抗网络钓鱼的 Passkeys (SCA) 与银行控制的显示界面和服务器端动态链接相结合，以满足 PSD2 RTS 第 5 条（“所见即所签”）的要求。

• 核心实现（当前）： 我们在 Passkey 认证之前和期间，在由 Bison 银行控制的用户界面中显示交易金额和收款人。我们的后端会生成一个一次性质询，该质询绑定到一个规范化的交易快照（金额、收款人、交易ID）。只有当响应与该快照匹配时才会被接受；任何更改都会使其失效。

• 监管立场： 即使使用 Passkeys，远程支付仍然需要动态链接（PSD2 第 97(2) 条；RTS 第 5 条）。RTS 并未要求动态链接的“认证码”必须在设备上计算；当显示完整性、特异性和变更时失效得到强制执行时，服务器端生成/验证是可以接受的（另见 EBA 问答 2020_5366 关于认证码可在何处计算的问题）。

• 安全性与可审计性： 将基于硬件、抗网络钓鱼的 Passkey 签名与特定的交易数据绑定，可防止篡改和中继攻击，并产生强大、不可否认的付款人同意证据。在支持的情况下，我们可以选择性地采用安全支付确认 (SPC)，以在不改变后端模型的情况下增加对所显示细节的加密证明。

• SCA：来自不同类别（知识/所有物/内在特征）的两个独立元素，通过适当的缓解措施防止泄露/复制（RTS 第 6-8 条）。要求独立性（第 9 条），包括在多功能设备上执行时的分离（例如，操作系统级别的保护、安全硬件）。
• 动态链接 (RTS 第 5 条)：
  • (i) 在认证过程中让付款人知晓金额和收款人
  • (ii) 认证码对该金额/收款人是唯一的
  • (iii) 任何更改都会使认证码失效
  • (iv) 金额、收款人和认证码的机密性/完整性受到端到端保护。这实现了“所见即所签”的监管意图。
• 启示：仅有强大的用户认证对于支付是不够的。批准必须与特定的交易数据绑定，并提供可审计的绑定证据以及向付款人展示的证据（RTS 第 5(1)(a-d) 条）。

澄清 — 网络钓鱼 vs. 授权： Passkeys 与来源绑定，因此虚假域名无法获取有效签名。然而，PSD2 仍然要求远程支付使用动态链接，以将授权绑定到确切的金额和收款人，从而使任何更改都失效，并保护向付款人显示内容的完整性（RTS 第 5(1)(a-d) 条）。动态链接解决的是授权完整性问题（包括中间人攻击/浏览器中间人攻击/TPP 替换），而不仅仅是网络钓鱼。

EBA 2019 年意见 (EBA-Op-2019-06) 强调，动态链接将认证与金额和收款人绑定，要求各因素独立，并接受设备绑定的加密密钥作为所有物证明，前提是存在唯一的设备绑定。它还强调了在认证期间向付款人显示内容的完整性。 EBA 2019 年意见

在 PSD2 之前，许多银行依赖短信一次性密码 (OTP) 或打印的 TAN 列表，这些通常在批准步骤旁边不显示金额或收款人。这个漏洞使得在凭证被盗后，更容易诱骗客户授权非预期的转账。引入动态链接是为了弥补这一漏洞，确保付款人在认证时能清楚地看到确切的金额和收款人，并使认证码与这些细节特定关联，从而任何更改都会使其失效（RTS 第 5(1)(a-d) 条）。当短信是流程的一部分时，发卡行还必须在认证的所有阶段确保证金额/收款人和认证码的机密性、真实性和完整性（问答 2018_4414；RTS 第 5(2) 条）。如今的应用内批准（例如，“您想通过面容 ID 授权向 John Smith 支付 100 美元吗？”）以一种对客户友好的方式实现了这一“所见即所签”的原则。

如今，在移动设备上，有两种主流模式。第一种是，推送通知可以将客户深度链接到应用中，以审查交易详情并批准。监管机构已澄清，如果采取了第 7 条的控制措施以减轻未经授权的使用和防止复制，并且整个流程符合 RTS，那么推送通知可以作为所有物元素的证据；尽管如此，社交工程风险依然存在，应在用户体验中加以解决（问答 2019_4984；RTS 第 7 条）。

第二种是，使用设备的原生生物识别功能（以 PIN 作为备用方案）进行批准，这会在本地执行用户验证以解锁一个私钥操作。该私钥存在于一个安全硬件环境（Secure Enclave/TEE/TPM）中，并对一个质询进行签名。这与 SCA 的要求完美契合：内在特征（生物识别）加上通过设备绑定和设备绑定的加密密钥证明的所有物（EBA-Op-2019-06，第 25、35-37 段）。对于远程支付，认证码必须与金额和收款人动态链接，并且这些细节必须在用户验证前向付款人显示（RTS 第 5 条）。如果两个因素都在同一设备上，则需实现独立的安全执行环境和完整性检查，以确保一个因素的泄露不会危及另一个（RTS 第 9(2)-(3) 条）。

在底层，本地生物识别并不直接“向银行认证”。相反，生物识别（或 PIN 备用方案）在设备上执行用户验证，并控制对存储在硬件支持的安全模块中的不可导出私钥的访问。当付款人批准时，设备使用该私钥对银行提供的质询生成数字签名。如果银行从交易的规范快照（金额、收款人、标识符）派生或关联该质询，那么生成的签名就充当了特定于这些细节的认证码。任何更改都将使该码失效，因为存储的快照不再匹配，或者在增强设计中，因为质询的派生方式改变了。付款人意识部分仍然是一个用户体验要求：在用户验证前，在银行控制的视图中显示金额和收款人。综合来看，这满足了 RTS 第 5 条关于意识、特异性/唯一性和变更时失效的要求，而第 7 条的控制措施和设备绑定则证明了所有物元素。

• 所有物（设备绑定和同步密钥）：Passkey 私钥存储在安全硬件（TEE/Secure Enclave/TPM）中。设备绑定的 Passkeys 是不可导出的，这与 EBA 对唯一设备绑定的期望一致（EBA-Op-2019-06，第 25、35-37 段）。同步的 Passkeys 也可以在每次认证时证明所有物，前提是设备绑定和防复制控制有效；监管机构强调了元素与设备之间需要有可靠的链接（EBA-Op-2019-06；RTS 第 7 条）。
• 内在特征/知识（用户验证）：通过生物识别（内在特征）或设备 PIN（知识）进行用户验证，在本地激活密钥。结合所有物，这就是真正的双因素认证，且因素独立。一个因素的泄露不会危及另一个。

动态链接的核心是将认证与交易绑定。银行面临的问题是：如果我们让用户通过 Passkey（而不是一次性密码或签名设备）批准支付，我们能保证这个批准是特定于预期的金额和收款人，并且不能被重用或操纵吗？

使用 Passkeys 实现动态链接有两种选择：

• 服务器端链接（标准）： 生成一个一次性的 WebAuthn 质询，后端将其与确切的金额和收款人关联起来。用户在银行控制的视图中看到“向 Y 支付 X 欧元”，然后用 Passkey 批准。该响应仅对该笔交易有效。任何更改都会使其失效。
• 加密包含（增强）： 将金额/收款人的哈希值嵌入到质询中，这样签名就承诺了交易数据。RTS 并未要求这样做，但这增加了额外的保证，即使后端被替换，验证也会失败。

明确的合规说明： RTS 并未要求动态链接的“认证码”必须在付款人的设备上计算。只要金额/收款人受到保护且任何更改都会使认证码失效，支付服务提供商可以在服务器上生成和验证它（参见 EBA 问答 2020_5366 关于认证码的位置/时间）。这就是我们的**服务器端动态链接（标准）**方法。

这两种方法都产生了一个唯一的、不可重用的、特定于交易的“认证码”。主要的注意事项是付款人意识：WebAuthn 本身并不能证明显示了什么内容。显示的完整性必须来自银行控制的用户界面。

RTS 第 5 条要求付款人在认证期间看到金额和收款人。WebAuthn 并不证明显示了什么。理论上，如果应用或操作系统被攻破，用户可能会被误导，而认证器仍然会签名。我们将在下面详细分析这种风险在现实中如何发生，以及为什么它不是真正的安全风险，而更多是法规解释的问题。

我们强制执行的显示完整性控制：

• 银行控制的视图呈现金额+收款人：如果该视图被遮挡或失焦，我们阻止 Passkey 的调用
• 应用/Web 中的覆盖/篡改检测：不允许来自隐藏 iframes 的 Passkey 提示
• 设备完整性/证明门控：对已 root/越狱/被攻破的设备信号，拒绝或提升验证等级
• 针对服务器持有的金额/收款人快照的原子性批准：任何参数更改都需要一个新的质询

关于加密包含： WebAuthn 的“交易显示”扩展（SPC）如今并未得到广泛支持。我们的可移植基线是服务器端绑定，通过从交易快照派生质询（例如，H(金额 || 收款人 || 交易ID || 随机数)）来加强，从而使签名承诺了这些值。

这两种模式都使用公钥加密技术和不可导出的设备密钥，并且都依赖本地用户验证来解锁签名操作。在这两种模式中，银行通过在用户验证前立即在银行控制的视图中显示金额和收款人来确保付款人意识，并通过将认证码与这些细节绑定来确保特异性——任何更改都会使其失效（RTS 第 5(1)(a-d) 条）。RTS 是技术中立的，并不要求金额/收款人必须在操作系统生物识别模态框内呈现；它要求向付款人显示并绑定认证码（RTS 第 5 条）。当两个 SCA 元素都在一个设备上执行时，第 9 条的完整性和分离要求同样适用（RTS 第 9(2)-(3) 条）。最后，动态链接计算的位置是灵活的：如果完整性得以保持且任何更改都会使认证码失效，它可以在服务器端执行（问答 2020_5366）。这些是监管机构已经接受本地生物识别与 PKI 的相同条件——因此，使用相同的付款人意识和绑定控制措施实现的 Passkeys，也应该在同等基础上被接受。

那么，根据 WebAuthn 标准的普通 Passkeys 是否实现了动态链接的意图？部分实现：

• 中间人攻击/网络攻击： 是的。来源绑定和每次质询的签名可以防止篡改和重放。
• 交易完整性： 是的。服务器关联或质询哈希确保只有原始的金额/收款人才能通过验证。
• 付款人同意： 较难。Passkeys 缺乏认证器级别的显示。在被攻破的设备上可能存在 UI 欺骗。必须在其之上构建一些东西来保证付款人的同意。

为什么使用 Passkeys 仍然需要动态链接

• 法律要求： PSD2 第 97(2) 条和 RTS 第 5 条规定，所有远程支付发起都必须使用动态链接。没有针对抗网络钓鱼方法的豁免。
• 安全性： Passkeys 消除了跨域网络钓鱼，但它们本身并不能证明向付款人显示了什么。动态链接 + 显示完整性控制确保银行执行的是用户看到的特定金额/收款人，并且任何更改都会使批准失效。

**总而言之，当 Passkeys 与交易数据严格绑定并与可信的显示机制配对时，可以满足动态链接的要求。**剩下的挑战是证明用户实际看到了什么。

Corbado 提供了一个符合动态链接要求的解决方案，明确解决了上述付款人同意的考量。

流程：

• 银行控制的显示界面向付款人展示确切的金额和收款人。除非此视图可见，否则不会显示 Passkey 提示。
• 认证： 客户端使用一个一次性的、与规范化交易绑定的质询调用 WebAuthn。 认证器执行用户验证（生物识别或设备 PIN）并对质询和来源进行签名。
• 服务器验证： 后端验证 RP ID 哈希和来源，将质询与存储的交易匹配，检查 UV/标志，强制执行一次性使用和过期时间，并比较存储的金额/收款人快照。
• 批准和审计： 只有在此之后，交易才被原子性地批准。任何不匹配/更改都会被拒绝，并需要重新认证。一个不可变的审计记录被持久化（凭证 ID、authenticatorData、clientDataJSON、签名、质询以及规范化的金额/收款人），可选择使用哈希链以防篡改。
• 设备完整性门控： 评估设备完整性和证明信号：如果设备被 root/越狱/攻破，则拒绝或提升验证等级。
• 收款人规范化： 显示一个友好的标签（例如，“ACME GmbH”），但根据规范的收款人标识符（例如，IBAN/BIC 或其他唯一方案）进行绑定和验证。

技术细节：

• 后端： 创建一个包含规范化数据的交易对象（例如，标准化的货币/小数位；规范化的 IBAN/受益人）。生成一个承诺这些值的短期质询（例如，H(金额||收款人||交易ID||随机数)）；存储待处理状态；仅向客户端暴露不透明的 ID。
• 客户端/认证器： 在银行控制的视图中呈现付款人详情；仅在可见时调用 WebAuthn（RP ID = Bison 域名）；要求用户验证；认证器根据 WebAuthn 签署质询 + 来源。
• 验证/最终确定： 验证签名、RP ID 哈希、来源/类型、UV 标志；防重放/过期；比较不可变的金额/收款人快照；原子性批准；持久化审计记录。
• 从快照派生质询：： 质询 = H(金额 ‖ 规范收款人 ‖ 交易ID ‖ 随机数)

用户体验策略：

• 明确强调金额/收款人；提供易于访问的确认/取消控件；设置短超时；优雅的重试始终使用新的质询；即时收据（例如，“您已批准向 Y 支付 X 欧元”）。如果显示被遮挡，则阻止 Passkey 提示；如果参数在签名之前发生变化，则发出警告。
• 检测覆盖/遮挡内容：如果交易视图不可见，绝不显示 Passkey 提示。如果参数在流程中发生变化，则拒绝并使用新的质询重新开始。

合规说明： 这个端到端的设计满足 RTS 第 5 条：付款人意识（银行控制的显示）、特异性和唯一性（与金额/收款人绑定的一次性代码）、变更时失效（严格的服务器检查），以及在所有阶段的金额/收款人和代码的机密性/完整性（RTS 第 5(1)(a-d), 5(2) 条；另见问答 2018_4414 关于短信完整性）。通过设备绑定的所有物和在具有适当保护的多功能设备上的本地用户验证，保留了因素的独立性（第 7-9 条），符合 RTS 第 9(2)-(3) 条的规定。

注意： 对于 Web 流程，如果/当苹果提供广泛支持时，Corbado 将选择性地采用安全支付确认（https://www.w3.org/TR/payment-request-secure-payment-confirmation/），增加一个受信任的、由浏览器中介的显示，从而以加密方式证明金额和收款人。

顾虑：网络钓鱼攻击 应对： Passkeys 的设计本身就具有抗网络钓鱼能力：它们与合法来源绑定，不涉及共享秘密，因此凭证不会像一次性密码那样在虚假网站上被窃取。一个将流量代理到相似域名的攻击者无法获得银行来源的有效签名。动态链接在这方面贡献较小，但仍然是强制性的，以确保任何批准对于预期的金额和收款人都是唯一的。补充措施（网络钓鱼教育、明确区分登录和支付批准、对异常支付情景进行异常/风险评分）进一步降低了风险。

顾虑：社交工程 / 授权推送支付 (APP) 欺诈 应对： 没有任何认证器可以完全阻止用户在虚假借口下（例如，“安全账户”骗局）授权支付。动态链接确保用户明确看到收款人和金额，并提供强有力的同意证据，但它无法改变一个深信不疑的付款人的决定。补偿措施包括情景警告（新收款人、首次大额转账）、对高风险收款人设置冷静期或延迟执行、更强的收款人验证以及在出现风险信号时进行升级检查（额外确认）。支付后通知和快速争议渠道有助于发现和控制损害。我们增加了实时的情景警告（例如，新收款人、首次大额转账）、对高风险收款人设置冷静期、更强的收款人验证和支付后通知（“您已批准向 Y 支付 X 欧元”），以加快检测和响应。

顾虑：恶意软件或设备被攻破 应对： 私钥是不可导出的，并且每次签名都需要本地用户验证，因此恶意软件无法简单地窃取凭证。现实的风险是在一个完全被攻破的操作系统上进行UI 欺骗。可以通过安全/经过验证的 UI（例如，受保护的确认）、设备完整性检查/证明和阻止高风险设备，以及在可用时使用如 SPC 或确认扩展等可信确认来缓解。如果出现设备被攻破的迹象（覆盖检测、root/越狱），则使用带外重新验证或拒绝执行。在完全被控制的设备上，没有一种消费者方法是完美的，但这些控制措施极大地缩小了攻击窗口。

顾虑：浏览器中间人攻击 / 会话劫持 应对： 恶意扩展或注入的脚本可以在合法来源上发起操作。与来源绑定的 Passkeys 可以阻止跨站网络钓鱼。动态链接确保对金额/收款人的幕后编辑会失败。我们通过 CSP/防篡改控制以及要求每次确认都使用一个全新的、一次性的质询来加固通道。

顾虑：内部威胁或服务器端篡改 应对： 认证响应与原始金额/收款人唯一绑定，因此任何服务器端的替换都会验证失败。为审计/不可否认性，维护防篡改、不可变的链接记录（质询、凭证、签名和规范化的金额/收款人）。在关键支付处理路径上应用职责分离和四眼原则控制，以降低内部风险。

顾虑：设备被盗 / 凭证被盗 应对： 仅仅拥有设备是不够的：每次签名都需要用户验证（生物识别/PIN），并有操作系统级别的速率限制和锁定。每次支付都需要一个全新的、特定于交易的质询；通用的会话令牌不能授权任意支付。增加远程设备撤销、新设备使用时升级验证、地理速度检查和通知（“您已授权向 Y 支付 X 欧元”）等措施进一步限制了滥用。

总体而言：Passkeys 显著降低了网络钓鱼和重放风险；动态链接对于保证交易完整性、将批准与金额/收款人绑定，并在其余威胁情景中提供强有力的知情同意证据仍然至关重要。

问题 1： 使用 Passkey 时，我们如何证明用户确实看到并同意了金额和收款人？ 应对： 我们在银行控制的视图中强制执行付款人显示，并将批准与金额/收款人的服务器端快照绑定。Passkey 断言（authenticatorData、clientDataJSON、签名）仅对从该快照派生的质询有效；任何更改都需要一个新的质询。我们的防篡改审计将断言链接到“向收款人ID Y 支付 X 欧元”，并记录我们的系统在细节不符时不会继续。在支持的情况下，SPC 增加了用户确认所显示细节的加密证据。

问题 1： 使用 Passkey 时，我们如何证明用户确实看到并同意了金额和收款人？ 应对： 这本质上是不可否认性的问题。根据 PSD2，动态链接旨在确保用户了解他们正在批准什么。使用 Passkey，我们保留的证据是加密签名（认证码）和相关数据（它在我们服务器上与哪个金额/收款人绑定）。根据政策，我们在用户认证前在应用或网页中向用户显示交易详情。我们记录该屏幕/视图以及随后针对该特定交易的成功 Passkey 认证。如果发生争议，我们可以证明用户的设备为与（例如）“向 ACME Corp. 支付 100 欧元”相关联的质询生成了有效签名，并且如果任何细节不同，我们的系统都不会继续。我们的合规性依赖于安全的日志记录：我们确保我们的系统在将 Passkey 响应与交易数据链接方面是防篡改的。

问题 2： 如果设备或操作系统被攻破怎么办？恶意软件能操纵交易或 Passkey 过程吗？ 应对： 在任何数字银行场景中，设备被攻破都是一个关键威胁。如果操作系统是恶意的，它可能会试图误导用户或劫持进程。然而，即使在这种最坏的情况下，Passkeys 仍然保持一些关键保护。私钥不能被恶意软件提取。恶意软件也无法冒充用户向银行进行认证，因为它无法在没有用户的生物识别/PIN 的情况下生成 Passkey 签名。它最多能做的就是诱骗用户在虚假借口下认证某些东西。动态链接在这里有所帮助，因为它要求进行完整性检查：恶意软件无法在事后悄悄更改交易详情——如果它这样做，签名将无法验证。最薄弱的一环是显示/UI：一个复杂的木马可能会改变用户看到的内容（例如，显示“ACME Corp”，而底层交易实际上是给另一个收款人）。这并非易事，特别是如果银行应用使用安全 UI 框架，但这是可以想象的。话虽如此，如果我们检测到设备被攻破的迹象（异常行为、已知的恶意软件签名等），我们会回退到带外验证或拒绝交易。总结一下： 如果用户的设备完全被攻击者控制，没有解决方案是 100% 安全的。Passkeys + 动态链接极大地减少了攻击面（攻击者不能仅仅代理凭证或更改网络数据；他们必须实时对用户进行欺骗）。如果操作系统被攻破，动态链接至少能确保我们后端能捕捉到应有内容与实际批准内容之间的任何不匹配。

问题 3： 如果使用生物识别来解锁 Passkey，这算是一个因素还是两个？我们是否遵守了双因素规则？ 应对： 单独的生物识别不足以构成 SCA——它只是一个内在特征因素。然而，在 Passkey 实现中，生物识别并非单独存在：拥有设备是另一个因素。用户的生物识别解锁了存储在设备上的私钥。所有物和内在特征是两个不同的类别。这类似于许多银行应用已经满足 SCA 的方式：你拥有手机（所有物）并且你使用指纹或面部来解锁应用（内在特征）。EBA 已明确承认设备绑定加生物识别的组合是符合 SCA 的。Passkey 场景正是这种组合。如果用户选择使用 PIN 而不是生物识别来解锁 Passkey，那么它就是所有物 + 知识，也符合要求。我们对所有 Passkey 操作强制执行用户验证（意味着用户每次都必须提供生物识别/PIN），所以不存在仅拥有设备就足够的情况。因此，根据 PSD2 的定义，每次通过 Passkey 进行的支付授权都是一个双因素事件。

问题 4： 攻击者能否重用 Passkey 认证或通过操纵传输中的数据以某种方式绕过动态链接？ 应对： 不行。这正是 Passkeys 和动态链接协同作用的强大之处。每次 WebAuthn 认证都会产生一个唯一的签名，该签名与质询（我们为每笔交易生成）绑定，并限定在我们的域内。攻击者无法为不同的交易重放该签名。签名本身包含了质询随机数，并且只对它最初签发的内容有效。如果攻击者截获了网络通信，他们无法在不使签名失效的情况下更改金额或收款人（因为质询或交易上下文将不再匹配）。这实际上就是我们讨论过的中间人攻击保护。此外，Passkey 签名包含来源数据——如果不是发送到我们确切的网站/应用来源，它们将无法验证，所以网络钓鱼或重定向是行不通的。简而言之，根据动态链接规则，任何操纵尝试都会使认证码失效。这实际上比一些当前基于 OTP 的流程更安全，在那些流程中，用户有时会批准一个通用代码，存在请求被篡改的风险。使用 Passkeys，我们将用户认证与特定的会话/交易进行了加密绑定。

问题 5： 是否有关于 WebAuthn/Passkeys 用于 SCA 的已知监管意见？我们确定监管机构会接受 Passkeys 为合规吗？ 应对： 截至目前，EBA 尚未在其问答或指南中明确发布关于 WebAuthn 或“Passkeys”一词的意见。然而，根据他们制定的原则，Passkeys 显然符合可接受的方法。EBA 的 2019 年意见基本上预见了类似 FIDO2 的方法：对于所有物，他们明确提到**“公/私钥交换”与适当的设备绑定作为所有物证据**。一个 WebAuthn Passkey 正是如此——一个公/私钥对，其中私钥部分安全地绑定到设备。他们还认可“由设备生成的签名”作为有效的持有证明。所以虽然他们没有使用 Passkey 这个词，但这种方法已被他们的例子所涵盖。我们也观察到欧洲主要的支付公司正在推进 Passkey 的实施（例如 PayPal），这表明他们有信心这符合 PSD2。这个例子表明，只要满足动态链接和总体要求，Passkeys 正在被接受为合规 SCA 流程的一部分。

问题 6： 如果 Passkeys 具有抗网络钓鱼能力，我们还需要动态链接吗？ 应对： 是的。Passkeys 消除了跨域网络钓鱼，但 PSD2 仍然强制要求远程支付发起使用动态链接。动态链接将特定的金额和收款人与 SCA 结果绑定，并使任何更改都失效，从而解决了网络钓鱼之外的授权完整性问题（例如，中间人攻击/浏览器中间人攻击/TPP 替换）。

Corbado 的解决方案符合动态链接和 PSD2 的要求。认证前的付款人显示、与金额和收款人绑定的一次性质询、严格的服务器验证以及不可变的审计共同满足了 RTS 第 5 条关于付款人意识、唯一性/特异性、变更时失效以及完整性/机密性的要求。通过设备绑定的所有物和用户验证（生物识别或 PIN），保留了因素的独立性，这与 EBA 的指导意见一致。

与当今的 OTP/SMS 方法相比，Corbado 提供了显著更好的安全性和用户体验：抗网络钓鱼和重放攻击、防止静默参数篡改、更强的不可否认证据，以及通过设备上的用户验证减少了操作摩擦。剩余风险（例如，社交工程、设备被攻破）通过具体的控制措施得到缓解，并且比传统方法风险范围更窄。对于 Web，当平台（特别是苹果）提供广泛支持时，Corbado 可以采用 SPC，在不改变核心合规态势的情况下增加显示的加密证明。

简而言之，Corbado 基于 Passkey 的交易授权符合 PSD2 动态链接的文字和精神，与传统方法相比，提高了欺诈抵御能力和可审计性，同时为随着生态系统的成熟，未来的增强功能（SPC）保留了清晰的路径。

在实践中，当我们做到三件事时，Passkeys 就满足了动态链接的要求：我们在用户验证前向付款人显示金额和收款人；我们生成一个特定于这些确切细节的认证码；我们在任何更改时都使该认证码失效（RTS 第 5(1)(a-d) 条）。这反映了监管机构已经接受的本地生物识别的原则，并增加了 Passkeys 是操作系统原生且无需额外应用即可跨 Web 和应用渠道工作的便利性。结合来源绑定，它们不会显示欺骗性请求——只有来自原始网站或应用的合法提示才会出现在用户面前。