EMV 3DS 访问控制服务器：Passkeys、FIDO 和 SPC

在线支付认证领域正在经历重大变革，其驱动力来自于两方面的需求：一是增强安全性以抵御日益复杂的欺诈行为，二是改善用户体验以减少操作阻力和购物车放弃率。EMV® 3-D Secure (3DS) 协议，特别是其后续版本 (EMV 3DS 2.x)，已成为全球范围内验证无卡交易 (CNP) 的基础技术。该协议由 EMVCo 管理，旨在促进商户、发卡行（通过其访问控制服务器 - ACS）以及互操作域（由支付方案运营的目录服务器）之间的数据交换，以验证持卡人身份。

在此框架内，与 FIDO（线上快速身份验证）联盟标准相关的两项关键技术进步正在兴起：

1. 利用在先前用户交互（例如商户登录）期间生成的 FIDO 认证数据，来丰富 EMV 3DS 无感流程的风险评估。
2. 集成安全支付确认 (SPC)，这是一项基于 FIDO/WebAuthn 构建的 W3C Web 标准，作为 EMV 3DS 流程中一种简化的、抗钓鱼的“挑战”方法。

本文概述了全球范围内为发卡银行提供的 EMV 3DS 访问控制服务器 (ACS) 解决方案市场。文章识别了主要供应商，并试图评估他们当前对非 SPC 的 FIDO 数据结构和用于挑战流程的安全支付确认 (SPC) 的支持情况。此外，本文还阐明了发卡行如何通过 SPC 在 3DS 挑战流程中利用自己的 FIDO Passkeys 进行加密验证的机制，并讨论了该标准的全球适用性。

EMV 3DS 主要通过两种不同的认证路径运作：

• 无感流程 (Frictionless Flow)： 这是首选路径，旨在提供无缝的用户体验。发卡行的 ACS 会根据交易发起时交换的丰富数据集（通过认证请求，即 AReq 消息）进行风险评估。这些数据包括交易详情、商户信息、设备特征、浏览器数据（可能通过 3DSMethod JavaScript 收集）以及可能的先前认证信息。如果风险被评为低，交易将在不需要持卡人任何直接互动或“挑战”的情况下得到认证。这种流程占了 3DS 交易的大部分，尤其是在风险引擎经过良好优化的情况下。
• 挑战流程 (Challenge Flow)： 如果 ACS 确定交易风险较高，或者根据法规（如欧洲的 PSD2 SCA）或发卡行政策的要求，持卡人将被主动要求验证其身份。传统的挑战方法包括通过短信发送的一次性密码 (OTP)、基于知识的问题或通过银行应用进行的带外 (OOB) 认证。较新版本的 3DS 和像 SPC 这样的相关技术的目标是使这种挑战流程比传统方法更安全、更便捷。

EMVCo 和 FIDO 联盟已合作定义了一种标准化方式，让商户可以在标准的 3DS AReq 消息中，将先前 FIDO 认证（其中_商户_作为信赖方，例如在用户登录期间）的信息传递给发卡行的 ACS。这一机制最早在 EMV 3DS v2.1 中得到支持，它利用了 AReq 内的特定字段，主要是 threeDSRequestorAuthenticationInfo 结构，该结构包含诸如 threeDSRequestorAuthenticationData 等子字段。

FIDO 联盟技术说明和相关的 EMVCo 白皮书为这个 threeDSRequestorAuthenticationData 字段在传递先前 FIDO 认证详情时指定了一个 JSON 结构。这个 JSON 对象包括认证时间 (authTime)、FIDO 信赖方 ID (rpId 或 appId)，以及关于所用认证器的信息，包括公钥、AAGUID/AAID，以及用户在场 (UP) 和用户验证 (UV) 的指示符。

其基本原理是，如果一个商户最近为发起购买的用户会话执行了一次强 FIDO 认证（例如，使用生物识别或 Passkey），这些信息可以作为发卡行 ACS 的一个有价值的额外风险信号。通过接收和处理这些标准化的 FIDO 数据，ACS 可以更有信心地判断交易的合法性，从而增加无感批准的可能性，并减少进行单独挑战的需要。值得注意的是，在这种情况下，商户是 FIDO RP，而发卡行将此数据作为其风险引擎的输入；发卡行在这个无感流程中并不对 FIDO 断言本身进行加密验证。如果 ACS 未配置处理此数据，它也可以选择忽略。

安全支付确认 (SPC) 代表了 FIDO 标准在 EMV 3DS 挑战流程中的一种独特集成。SPC 是 W3C 的一项 Web 标准，由 W3C 与 FIDO 和 EMVCo 合作开发，并基于 WebAuthn 构建。从 2.3 版本开始，它在 EMV 3DS 中得到正式支持。

当 SPC 被用作挑战方法时：

1. 发卡行（或由发卡行明确授权的一方，如支付方案）充当 FIDO 信赖方 (RP)。这与前面描述的非 SPC FIDO 数据流有根本不同，在后者中，商户通常是为其自身登录/认证目的而充当 RP。
2. 在 3DS 挑战期间，ACS 发出需要 SPC 的信号，并向商户/3DS 服务器提供必要的 FIDO 凭证标识符和加密挑战。
3. 商户的系统调用浏览器的 SPC API，在一个由浏览器控制的安全对话框中向用户显示交易详情（金额、货币、收款人、支付工具）。
4. 用户使用他们的 FIDO 认证器（例如，设备生物识别、PIN、安全密钥）进行认证，该认证器使用与发卡行注册的 Passkey 关联的私钥对交易详情和挑战进行签名。
5. 生成的 FIDO 断言（认证和同意的加密证明）通过 3DS 协议（通常通过第二条 AReq 消息）传回给发卡行的 ACS。
6. ACS 作为 RP，使用相应的公钥对断言进行加密验证，从而确认持卡人的身份以及对特定交易详情的同意。

与传统方法相比，SPC 旨在提供一种既更安全（抗钓鱼、将认证与交易数据进行动态链接）又可能摩擦更小（通常比输入 OTP 更快）的挑战体验。

FIDO 集成的双重路径——一种利用先前的商户认证数据进行无感风险评估，另一种通过 SPC 使用发卡行管理的凭证进行直接的基于 FIDO 的挑战——为在 EMV 3DS 框架内增强安全性和用户体验提供了不同的方法。对于正在规划其认证策略的发卡行和 PSP 来说，了解供应商对每种路径的支持情况至关重要。

本节分析了全球 EMV 3DS ACS 解决方案提供商的能力，重点关注其市场地位以及对 FIDO 数据（非 SPC）和安全支付确认 (SPC) 的支持情况。精确的市场份额数据是专有信息，难以公开获取；因此，市场地位的评估基于供应商声明、认证、合作伙伴关系、地理覆盖范围和市场报告。

• 市场地位： Entersekt，尤其是在 2023 年 12 月收购 Modirum 的 3DS 软件业务后，将自己定位为全球领先的 EMV 3DS 解决方案提供商，旨在进入市场前五的地位。Modirum 在 3DS 领域拥有超过 20 年的经验。Entersekt 强调其创纪录的增长得益于新客户（尤其是在北美）和战略合作伙伴关系，包括与 Mastercard 的深化合作。他们声称每年保障超过 25 亿笔交易（截至 24 财年），并在 Liminal 的银行账户盗用 (ATO) 防护排名中位列第一。其 ACS 可托管（由 Entersekt 或客户托管）或本地部署。他们为全球的发卡行和处理机构提供服务。
• 非 SPC FIDO 数据支持（无感流程）： Entersekt 强调其 Context Aware™ 认证、用于风险信号的设备和行为分析，以及与各种风险评分服务的集成。其 ACS 已通过 FIDO EMVCo 2.2 认证。虽然他们强调利用风险和行为智能数据进行 RBA，但在其在线材料中并未明确说明是否支持处理来自先前商户认证的、位于 threeDSRequestorAuthenticationInfo 字段中的标准化 FIDO 认证数据以增强无感流程。
• SPC 支持（挑战流程）： 有强烈迹象表明 Entersekt 支持 SPC。Entersekt 收购的 Modirum 曾为 Visa 的 SPC 试点项目提供了使用 3DS 2.2 及扩展的组件。Entersekt 明确将其对 SPC 合规性的支持列为其监管合规能力的一部分。其 ACS 支持生物识别认证，已通过 EMV 3DS 2.2 认证，并可能整合了 Modirum 在试点项目中的能力。收购 Modirum、明确提及 SPC 合规性以及 FIDO 认证的结合，强烈表明其当前产品支持 SPC。

• 市场地位： Broadcom 的 Arcot 是 3DS 市场的奠基者之一，曾与 Visa 共同发明了最初的协议。他们将自己定位为公认的全球领导者，为全球超过 5000 家金融机构服务，并处理来自 229 个国家的交易。其 Arcot Network 强调一种庞大的联盟数据方法（声称拥有超过 6 亿个设备签名，150 万亿个数据点），以支持其欺诈评分和风险引擎。他们在欧洲、澳大利亚和北美拥有强大的市场地位。
• 非 SPC FIDO 数据支持（无感流程）： Broadcom 重点强调其数据网络的丰富性以及使用 AI/神经网络进行欺诈检测和基于风险的评估，这超出了标准的 EMV 3DS 数据元素。他们明确表示，其解决方案利用了流经多个发卡行的数据，并整合了设备和地理位置等数字数据。虽然没有明确提及处理来自 threeDSRequestorAuthenticationData 的_特定_ FIDO JSON 结构，但他们专注于吸纳多样化数据点进行 RBA 的做法强烈暗示，如果提供此类数据，他们_可以_消费，这与 EMVCo/FIDO 指南的意图一致。其平台旨在通过卓越的风险评估最大化无感批准率。
• SPC 支持（挑战流程）： Broadcom 的文档确认在其更广泛的 VIP Authentication Hub / Identity Security 套件中支持 FIDO 认证器（安全密钥、生物识别、Passkey）。其 3DS ACS 支持包括 OTP 和推送通知在内的多种挑战方法，并提到支持生物识别。他们还提供委托认证 能力并引入了挑战后风险评估功能。然而，在所提供的文档中，并未明确确认其 _EMV 3DS ACS 产品_当前支持 SPC 作为一种特定的挑战方法（这需要 EMV 3DS v2.3+ 的能力和双 AReq 流程）。虽然他们作为主要参与者很可能能够实现它，但目前公开的材料更侧重于其 RBA 引擎和传统/OOB 挑战方法。

• 市场地位： Netcetera 将自己定位为重要的国际支付参与者，尤其在欧洲和中东地区实力雄厚。他们声称其 ACS 被超过 800 家银行/发卡行使用，为全球超过 5000 万张卡提供安全保障。他们强调已获得所有主要卡组织（Visa、Mastercard、Amex、Discover、JCB、UnionPay 等）的认证，并符合 PCI 合规性。值得注意的是，他们是全球首家获得 EMV 3DS 2.3.1 认证的 ACS 供应商。
• 非 SPC FIDO 数据支持（无感流程）： Netcetera 的文档强调了通过 3DSMethod 收集的数据对于 ACS 风险评估以增加无感认证的重要性。他们提供与风险工具的集成。然而，在所审阅的材料中，并未明确提及处理先前商户 FIDO 认证数据（来自 threeDSRequestorAuthenticationInfo）以进行风险评估。
• SPC 支持（挑战流程）： Netcetera 对 SPC 表现出强有力的支持。他们是全球首家通过 EMV 3DS 2.3.1 认证的供应商，该版本整合了 SPC。他们参与了 Visa 的 SPC 试点项目，提供了 v2.3.1 的组件。其产品文档明确定义了 SPC。他们举办了讨论 FIDO 和 SPC 集成的网络研讨会，并发表了强调 SPC 优势的文章。这种认证、试点参与和明确文档的结合，证实了他们对 SPC 挑战的支持。

• 市场地位： Worldline 将自己定位为欧洲支付和交易服务的领导者，以及全球主要参与者（声称是全球第四大支付玩家）。他们每年处理数十亿笔交易，并强调保证合规性、使用 AI/ML 进行欺诈控制以及可扩展性。其 ACS 据称已通过 EMV 3DS 认证，并符合主要方案（Visa Secure、Mastercard Identity Check）和 PSD2 的要求。他们报告称每年为超过 100 家发卡行处理超过 24 亿笔 3DS 交易。
• 非 SPC FIDO 数据支持（无感流程）： Worldline 的 ACS 产品包括一个 RBA 规则引擎，允许发卡行根据风险配置无感或挑战流程。其更广泛的“可信认证”解决方案利用了设备智能和行为分析。虽然他们普遍支持 FIDO，但在所提供的摘要中，并未详细说明在 ACS 内处理先前商户 FIDO 数据（非 SPC）以进行风险评估。
• SPC 支持（挑战流程）： Worldline 明确表示支持 SPC。他们的文档承认 EMV 3DS 2.3 的演进包含了 SPC/FIDO。他们明确推广其“WL 可信认证”解决方案，称其支持 FIDO 认证，并提供一个适用于“3DS 用例，支持 emvCO2.3 和 SPC”的“WL FIDO 服务器”。

• 市场地位： GPayments 将 ActiveAccess 定位为一个“强大的市场领先的访问控制服务器 (ACS) 平台”，在 3D Secure 领域拥有超过 20 年的经验。他们已通过主要卡组织（Visa Secure、Mastercard Identity Check、JCB J/Secure）的 3DS1 和 EMV 3DS 认证。其解决方案可以在本地部署或云端托管。市场报告将 GPayments 确定为提供 ACS 解决方案的重要参与者。
• 非 SPC FIDO 数据支持（无感流程）： ActiveAccess 支持与第三方 RBA 解决方案集成，并利用各种参数进行自身的风险评估。然而，所提供的文档并未明确提及支持吸纳或使用先前商户 FIDO 认证数据（非 SPC）进行无感风险评估。
• SPC 支持（挑战流程）： 所审阅的 ActiveAccess 文档并未明确提及支持安全支付确认 (SPC)、WebAuthn 挑战或 FIDO 挑战作为其挑战流程能力的一部分。虽然他们支持包括 OOB（可以包含生物识别）在内的多种认证方法，但从现有信息来看，对 SPC 的具体支持情况尚不清楚。

• 市场地位： Visa 作为全球主要的支付网络，定义了基于 EMV 3DS 标准的 Visa Secure 计划。他们开创了最初的 3DS 协议。Visa 主要不是像 Entersekt 或 Broadcom 这样的技术公司那样直接作为 ACS 供应商，而是运营该计划，并依赖一份经批准的 3DS 供应商名单（包括 ACS 提供商），这些供应商的产品已通过 EMV 3DS 和 Visa Secure 规则的认证。发卡行通常从这些认证供应商处采购 ACS 解决方案。Visa 自身则专注于网络（目录服务器）、定义计划规则、促进采用以及推动像 SPC 试点这样的创新。
• 非 SPC FIDO 数据支持（无感流程）： 基于 EMV 3DS 的 Visa Secure 本身就支持交换丰富数据以进行风险评估，从而实现无感流程。如果所选的 ACS 供应商支持处理它，那么用于传递先前 FIDO 数据的 EMVCo/FIDO 框架就可以在 Visa Secure 生态系统内运作。
• SPC 支持（挑战流程）： Visa 积极参与 SPC 的试点和推广。他们正与合作伙伴（如试点项目中的 Netcetera 和 Modirum/Entersekt）合作，在 3DS 协议内测试和完善 SPC 流程。这种强有力的参与表明，在 Visa Secure 计划中，他们对 SPC 作为一种挑战方法给予了战略性支持，但这取决于生态系统的准备情况（ACS、商户、浏览器支持）。

• 市场地位： 与 Visa 类似，Mastercard 运营着基于 EMV 3DS 的 Mastercard Identity Check 计划。他们为发卡行和商户提供多种选择，包括代理处理以及可能利用像 NuData 这样的合作伙伴或子公司。Mastercard 于 2017 年收购了行为生物识别公司 NuData Security，从而增强了其风险评估能力。他们还强调在生物识别、RBA 和 AI 方面的持续创新。与 Visa 一样，他们依赖认证供应商提供核心 ACS 组件，但也可能提供捆绑服务或利用收购的技术。
• 非 SPC FIDO 数据支持（无感流程）： Mastercard Identity Check 利用 EMV 3DS 2.x 的丰富数据交换来改进风险决策和无感流程。他们对 NuData 的收购表明，他们非常重视将行为分析作为风险评估的一部分。对处理先前商户 FIDO 数据的支持将取决于发卡行在 Identity Check 计划中使用的具体 ACS 实现。
• SPC 支持（挑战流程）： Mastercard 是 EMVCo 的关键成员，并参与了 EMV 3DS 标准的制定，包括支持 SPC 的 v2.3。他们也在更广泛地推广Passkey 的采用。更多详情可在此处找到：https://developer.mastercard.com/product/identity-check/。他们是 SPC 的坚定支持者，并推动采用现代认证方法。

EMV 3DS ACS 市场还有许多除上述详述之外的供应商。诸如 /n software、RSA、2C2P、3dsecure.io、Adyen、ACI Worldwide、Computop 等供应商也提供认证解决方案，或在特定地区或细分市场中扮演重要角色。本分析旨在覆盖全球主要参与者，但由于市场的动态性，并非详尽无遗。供应商的能力，特别是关于像 SPC 这样的新兴标准，正在迅速发展。如果您发现任何不准确之处或有关于供应商对 FIDO 数据或安全支付确认支持的更新信息，请联系我们，以确保本概述保持最新和准确。

在 EMV 3DS 挑战流程中使用安全支付确认 (SPC) 的一个核心原则是，发卡行（或由发卡行明确授权的一方，如支付方案）充当 FIDO 信赖方 (RP)。这与前面描述的非 SPC FIDO 数据流有根本不同，在后者中，商户通常是为其自身登录/认证目的而充当 RP。

为了让 SPC 在 3DS 挑战中发挥作用，需要以下步骤：

1. 注册 (Enrollment)： 持卡人必须首先向其发卡行注册一个 FIDO 认证器（例如，设备生物识别如指纹/面部 ID、设备 PIN 或漫游安全密钥）。这个过程会创建一个 Passkey，其中公钥和唯一的凭证标识符由发卡行存储，并与持卡人的账户或特定支付卡关联。注册可能会在银行的移动应用、网上银行门户中进行，或者可能在一次成功的传统 3DS 挑战后提供。至关重要的是，为了让像商户网站这样的第三方能够调用 SPC，凭证通常必须在用户明确同意其在此类上下文中使用的情况下创建，这通常涉及在注册期间使用特定的 WebAuthn 扩展。
2. 认证（在 3DS 挑战期间）：
   • 当一笔 3DS 交易触发挑战，且发卡行/ACS 支持并选择 SPC 时，ACS 会识别与持卡人和设备关联的相关 FIDO 凭证 ID。
   • ACS 将这些凭证 ID、一个唯一的加密挑战以及交易详情（金额、货币、收款人名称/来源、支付工具图标/显示名称）包含在发送回 3DS 服务器/请求方的认证响应 (ARes) 中。
   • 商户的 3DS 请求方组件使用来自 ARes 的这些信息来调用浏览器的 SPC API。
   • 浏览器会呈现一个标准化的安全对话框，显示由 ACS 提供的交易详情。
   • 用户确认交易并使用其注册的 FIDO 认证器进行认证（例如，触摸指纹传感器、面部识别、输入设备 PIN、轻触安全密钥）。此操作会解锁安全存储在设备/认证器上的私钥。
   • 认证器对呈现的交易详情和从 ACS 收到的加密挑战进行签名。
   • 浏览器将生成的 FIDO 断言（签过名的数据负载）返回给商户的 3DS 请求方。
   • 3DS 请求方将此断言传回给发卡行 ACS，通常封装在第二条 AReq 消息中。
   • 发卡行/ACS 作为权威的信赖方，使用持卡人先前存储的公钥对断言上的签名进行加密验证。验证成功即确认合法的持卡人使用其注册的认证器批准了所呈现的特定交易详情。

将 SPC 集成到 EMV 3DS 挑战流程中，需要对标准消息序列进行修改，通常涉及两次 AReq/ARes 交换：

1. 初始认证请求 (AReq #1)： 商户/3DS 服务器通过发送包含交易和设备数据的 AReq 来启动 3DS 流程。为了表明支持 SPC，请求中可能包含一个类似 threeDSRequestorSpcSupport 设置为 'Y' 的指示符（或类似值，取决于 ACS 供应商的实现）。
2. 初始认证响应 (ARes #1)： 如果 ACS 确定需要挑战并选择 SPC，它会以一个 ARes 响应来表明这一点。transStatus 可能被设置为 'S'（表示需要 SPC）或其他特定值。此 ARes 包含 SPC API 调用所需的数据负载。
3. SPC API 调用和 FIDO 认证： 商户的 3DS 请求方组件接收 ARes #1 并使用其负载来调用浏览器的 SPC API。用户通过浏览器的安全 UI 与其认证器进行交互。
4. FIDO 断言返回： 用户成功认证后，浏览器将 FIDO 断言数据返回给 3DS 请求方。
5. 第二次认证请求 (AReq #2)： 3DS 请求方构建并向 ACS 发送_第二条_ AReq 消息。此消息的主要目的是传输 FIDO 断言数据。它通常包括：
   • ReqAuthData：包含 FIDO 断言。
   • ReqAuthMethod：设置为 '09'（或为 SPC/FIDO 断言指定的值）。
   • 可能包含来自 ARes #1 的 AuthenticationInformation 值以关联请求。
   • 可选地，如果 SPC API 调用失败或超时，则包含 SPCIncompletionIndicator。
6. 最终认证响应 (ARes #2)： ACS 接收 AReq #2，使用持卡人的公钥验证 FIDO 断言，并确定最终的认证结果。它发回包含最终交易状态的 ARes #2（例如，transStatus = 'Y' 表示认证成功，'N' 表示失败）。

这种双 AReq 流程与传统的 3DS 挑战方法（如通过 CReq/CRes 或 RReq/RRes 消息处理的 OTP 或 OOB）有所不同，后者通常在收到 transStatus = 'C' 后在初始的 AReq/ARes 周期内完成。虽然 SPC 的用户交互部分（生物识别扫描、PIN 输入）通常比输入 OTP 快得多，但引入第二次完整的 AReq/ARes 往返会增加 3DS 服务器、目录服务器和 ACS 之间的网络延迟。实施者和供应商必须仔细优化此流程并处理潜在的超时，以确保整体端到端交易时间保持竞争力并满足用户期望。

由于其双重标准化，安全支付确认有望在全球范围内得到采用。它被万维网联盟 (W3C) 正式定义为一项 Web 标准，已于 2023 年中期达到候选推荐状态，并正在努力成为一项完整的推荐标准。同时，SPC 已被整合到由全球支付标准技术机构 EMVCo 管理的 EMV® 3-D Secure 规范中，从 2.3 版本开始。这种整合确保了 SPC 在已建立的全球 CNP 交易认证框架内运作。W3C、FIDO 联盟和 EMVCo 之间的合作凸显了全行业为创建可互操作、安全且用户友好的在线支付标准所做的努力。

虽然 SPC 的设计，特别是其将用户认证与特定交易详情进行加密链接（“动态链接”）的能力，有助于满足欧洲支付服务指令 (PSD2) 等法规下的强客户认证 (SCA) 要求，但其用途并不仅限于这些强制性地区。SPC 是一项全球技术标准，适用于任何市场，包括美国和加拿大，只要必要的生态系统组件已经就位。

在没有对每笔交易都有明确 SCA 强制要求的市场中，采用 SPC 的主要驱动力是：

• 改善用户体验： 与传统的 OTP 或基于知识的问题相比，提供一种可能更快、更便捷的挑战方法（例如，使用设备生物识别），从而可能减少购物车放弃率。试点项目显示，与传统挑战相比，认证时间显著减少。
• 增强安全性： SPC 内在的基于 FIDO 的认证能够抵抗钓鱼攻击、凭证填充以及其他针对密码和 OTP 的常见威胁。

因此，即使没有对所有交易都进行强制要求的法规，北美等地区的发卡行和商户也可能选择战略性地实施 SPC，以增强安全性并提供更好的客户体验。

安全支付确认 (SPC) 的成功部署和广泛采用在很大程度上依赖于支付生态系统中多个组件的协同准备。虽然底层的 FIDO 标准和 Passkey 技术正在迅速成熟，但浏览器层面对于 SPC API 的具体支持以及整个支付链的全面集成仍然是关键障碍。其他生态系统参与者的进展普遍良好。

生态系统准备情况摘要（截至 2025 年 5 月）

这在实践中意味着什么（2025 年 5 月）

SPC 采用的主要限制因素是用户代理（浏览器）层：

• Safari (macOS & iOS)： ❌ WebKit 仍然缺少 secure-payment-confirmation 支付请求方法。任何在 Safari 中访问的网站都必须回退到其他认证方法（OTP、OOB，可能还有非 SPC 的 WebAuthn 体验）。苹果尚未表示有兴趣实现该扩展。
• Chrome / Edge (Chromium)： ⚠️ 基线 SPC（凭证创建+认证）是稳定的，但密钥尚未存储在硬件认证器中，并且仅在试点中使用。实施者应预期可能出现破坏性变更，并准备根据 API 可用性检查（例如 canMakePayment()）或功能标志来控制功能。
• Firefox： ❌ 团队已表示有兴趣，但没有承诺的实施时间表；商户必须为平稳的回退路径做好计划。

因为发卡行基础设施（ACS、FIDO 服务器）和卡组织目录服务器已基本就绪或正在迅速推进，并且商户/PSP 工具也已可用，所以**广泛使用 SPC 的主要障碍是浏览器支持。**一旦浏览器覆盖率提高，剩下的任务主要涉及商户/PSP 集成（升级到 EMV 3DS v2.3+，添加 SPC 调用逻辑，处理双 AReq 流程）以及扩大发卡行专门为支付场景注册 Passkeys 的规模。

目前，预计 SPC 只会出现在有限的一部分交易中。在 Safari（以及因此整个 iOS 生态系统）提供支持之前，SPC 无法获得市场支持。

分析显示，截至 2025 年 5 月，EMV 3DS 中的两种主要 FIDO 集成方式在准备程度上存在明显差异。尽管作为挑战方法的安全支付确认 (SPC) 的基础要素正在推进——特别是发卡行/ACS 的能力和卡组织的准备情况——但其广泛采用受到了浏览器支持这一关键瓶颈的严重阻碍，最突出的是苹果 Safari（阻碍了所有 iOS/iPadOS 设备）和 Firefox 尚未实现，以及当前 Chromium 实现中的局限性。SPC 仍然是一个充满希望的未来状态，但它在今天还不是一个实用、普遍的解决方案。

根据当前的生态系统状况，我们提出以下建议：

• 商户：
  • 优先采用 Passkeys： 为用户登录和认证实施 Passkeys。除了改善您自身的安全性和用户体验（此处未详述的因素）外，这还为 3DS 无感流程创建了所需的数据。
  • 传递 FIDO 数据： 确保您的 3DS 集成在结账会话期间，能用成功的先前 Passkey 认证详情正确填充 threeDSRequestorAuthenticationInfo 字段。与您的 PSP/3DS 服务器提供商合作以启用此功能。
• 发卡行：
  • 为用户注册 Passkeys： 开始提供并鼓励持卡人直接向您注册 Passkeys（用于银行应用访问、未来的 SPC 等）。构建必要的 FIDO 信赖方基础设施。
  • 立即利用商户 Passkey 数据： 指示您的 ACS 供应商吸纳并利用商户传递的 FIDO 数据 (threeDSRequestorAuthenticationInfo)，作为您 RBA 引擎中的一个强有力的积极信号。在可能的情况下，维护与用户关联的可信商户 Passkeys 记录。目标是显著提高那些有强商户 Passkey 认证在先的交易的无感批准率。
  • 为 SPC 做准备，积极监控： 确保您的 ACS 路线图包括完整的 EMV 3DS v2.3.1+ SPC 支持，但将其视为未来的增强功能。持续监控浏览器发展（尤其是 Safari），以判断 SPC 何时可能大规模可行。
• ACS 供应商：
  • 通过 Passkey 智能增强 RBA： 大力投入研发，提升您的 RBA 引擎处理和信任商户提供的 FIDO/Passkey 数据的能力。开发逻辑以跟踪特定用户/设备在不同商户购物时的 Passkey 使用情况。存储公钥（来自发卡行直接注册）以验证商户认证数据的加密完整性（如果提供）。将成功的 Passkey 使用直接与更高的无感批准率挂钩。
  • 构建稳健的 SPC 能力： 继续开发和认证完整的 SPC 挑战流程支持（EMV 3DS v2.3.1+），为未来的市场采用做好准备。
• 支付方案/网络：
  • 倡导无感 FIDO 数据： 积极推广并可能激励在 3DS 流程中传递和利用商户 FIDO 认证数据 (threeDSRequestorAuthenticationInfo)。为发卡行和 ACS 供应商提供明确的指导和支持，帮助他们有效地利用这些数据进行 RBA。
  • 继续倡导 SPC 并与浏览器互动： 保持努力，标准化和推广 SPC，并与浏览器供应商（苹果、Mozilla、谷歌）进行关键性接触，以鼓励他们全面、可互操作地实现 SPC API 标准。

当前最直接、最切实的机会在于通过利用商户层面日益增长的 Passkeys 采用率来增强无感流程。所有生态系统参与者都应优先考虑在现有 EMV 3DS 框架内实现这种先前认证数据的创建、传输和智能消费。这条路径能够在短期内带来减少摩擦和潜在欺诈的好处，而无需等待普遍的 SPC 浏览器支持。与此同时，为 SPC 奠定基础——特别是发卡行的Passkey 注册和 ACS 的准备工作——确保一旦浏览器瓶颈得到解决，生态系统就能迅速采用这种更优越的挑战方法。