[以下内容译自 W3C Web 支付标准活动负责人 Ian Jacobs 的博客文章，参见英文原文]

3月18日，Stripe 向 W3C Web 支付工作组（会议记录）提交了他们为期三个月的SPC（Secure Payment Confirmation，安全支付确认）实验结果。结果非常令人兴奋：转化率提高了8%，认证速度明显加快。接下来我会分享更多细节，大家可以在 Stripe 的演示中获取更多信息。

SPC 的目的是在 Web 支付过程中优化 SCA（strong customer authentication，客户身份强认证）流程。这将改善 Web 端电商体验，增强安全性，并帮助支付行业符合监管的要求（如欧洲的 PSD2）。SPC 尚还没有作为一个 API 或一组完整定义的浏览器行为存在。Stripe 实验尝试实现了 SPC 的一些设想。谷歌工程师通过修改 MacOS Chrome 中的 Web 认证和支付请求 API，使实验成为可能。Web 支付工作组准备开始更系统地阐述 SPC 的特性和范围。

Stripe 实验试图了解用户对认证的偏好，是偏好单次输入密码进行强认证，还是 FIDO 认证。为什么实验选择FIDO？我们通常讲的 FIDO2, 是 FIDO 联盟的 CTAP 协议与 W3C WebAuthn 规范的结合，是 SCA 解决方案的完美基础。所有主流浏览器（桌面和移动端）上都支持 FIDO2,目前几十亿的手机和笔记本电脑都已经预先内置了认证程序。FIDO2 提供了比密码比起来更具安全性和可行性，并切实寻求符合法规的要求（请参阅关于满足 PSD2 SCA 需求的 FIDO 白皮书）。

简单地讲，SPC 实验重点关注使用 EMV® 3DS（3-D Secure，3-D 安全标准）进行初始登记的银行卡支付。正如我在前一篇博客文章中提到的，EMVCo、FIDO 和 W3C 正在讨论可以将 FIDO 与 3DS 结合使用的方法。该实验集中在 3DS 挑战模式(3DS challenge flow)期间使用 FIDO。这个实验将带给我们很多有用的信息，但我们正在进行的一部分工作是确保SPC能够支付过程和系统中被广泛使用。 

为了了解SPC的动机，需要了解3DS在Web上的使用方法。我的解释是一个简化的版本：

* 3DS的一个重要设计目标是使得发行信用卡的银行能够决定将要使用信用卡进行电子商务支付的人是否有权限。然而，当用户购物时，用户是在与商家交互，而不是与他们的银行交互。

* 一种方法是“让用户访问银行”，通过HTTP重定向到银行的网站（在第一方内容中）进行身份验证。考虑到各种便利性，人们会不喜欢这个解决方案。商家也不希望顾客离开他们的网站。

* 另一个解决方案是在商户网站上嵌入来自发卡银行的代码（在第三方内容中）。支付服务提供商（向商户）通常使用采用iframe，但没有Web认证。

我们来分析原因。在 WebAuthn 第一版规范中：

* 依赖方（relying party）必须在第一方（first party）环境中注册验证器。、

* 只有依赖方（relying party）可以对用户进行身份验证。

* 依赖方（relying party）只能在第一方（first party）的环境下这样做。

换言之，在 WebAuthn 第一版规范中，发卡银行（假设它和商户不同源）无法对用户在第三方购买中页使用Web 身份验证。为了克服这一限制，Web 支付工作组要求WebAuthn工作组改进方案。因此，在 WebAuthn 第二版规范中：

* 依赖方（relying party）必须在第一方环境中注册验证器。

* 只有依赖方（relying party）可以对用户进行身份验证。

* 依赖方（relying party）可以在第一方或第三方环境中这样做。 

现在，发卡银行可以在商户页面中使用 WebAuthn 对用户进行身份验证。这已经是一个巨大的成功。但 Stripe寻求进一步的改进。他们指出，在页面中嵌入发卡银行的代码会涉及很多网络请求，可能会出现安全问题。相反，他们希望自己能够触发 Web 身份验证，收集执行的结果，并通过后台渠道将其传达给发卡银行。作为信赖方，发卡银行仍将作为依赖方（relying party）验证该结果。 

首个“超能力”的SPC就是这样产生的。使用SPC：

* 依赖方（relying party）必须在第一方环境中注册验证器。

* 任何一方都可以对用户进行身份验证。

* 任何一方都可以在第一方或第三方环境中这样做。 

这是明显违背 WebAuthn 的行为，因此它仅在“支付情况下”可用。“支付情况下”目前（实验阶段）定义为“在付款请求 API 期间”。

实验阶段的 SPC 融合了支付请求 API 和 WebAuthn。独立使用 API 相比，开发人员通过 SPC 拥有更多超级功能。

SPC 的第二个超级功能是浏览器的“交易确认对话框”，其目标是使用内置浏览器功能，在网站和平台上创建一致的身份验证体验。

这是 SPC 和 WebAuthn 另外一个不同之处。WebAuthn 是在网站新开窗口内执行的。Stripe 询问 Chrome 团队使用当前窗口，而不是新建窗口。权衡结果是使用内置浏览器对话框，效果截图见文章插图。SPC 将身份验证交互操作委托给浏览器。下面描述 SPC 触发交易对话框的流程：

* 注册时（这里我不会详述），用户在第一方环境中向发卡银行注册验证器。发卡银行将用户的卡与该 FIDO 凭证关联。

* 在交易过程中，在任何商户网站上，用户都会选择同一张卡进行支付。Stripe（或任何支付服务提供商）请求发卡银行（通过修改后的 3DS 协议）并询问：这张卡是否存在关联的 FIDO 凭证？发卡银行返回凭证的公钥，以及一个随机数（用于身份验证）。Stripe 调用 SPC，浏览器打开“交易确认”对话框，询问用户：“是否要授权使用此卡向以下商户支付 N 美元？”如果用户继续，平台（以 MacOS 为例）会提示用户授权（本次实验使用 TouchID）。 

Stripe 还希望利用 SPC 来满足 PSD2 的另一个要求：“动态链接”。该要求涉及用户同意交易金额和受益人的加密证据。浏览器的新交易弹框显示 PSD2 所需信息，当用户点击确认时，FIDO 验证器用于确认金额、受益人和卡信息。因此，SPC 的第三个超级功能是内置的对签名交易确认数据的支持。 

总而言之，SPC的初步实验包含了这三种新的浏览器功能：

* 在支付请求API期间对于FIDO凭证，放宽了用户进行身份验证的限制

* 浏览器内置的交易确认对话框

* 签名交易数据

我们已经正在列举这三种功能为 SPC 带来的好处。我想这三个最初的功能未来会在 SPC 中保留，但是人们已经我们添加更多功能，比如标准化注册流程、零摩擦流（zero-friction flows）、作为 FIDO 认证输入的随机性来源，以及在支付 APP 中调用 SPC 的能力。我们将在 Web 支付工作组的远程会议上讨论 SPC 的潜在功能。 

回到实验上来，SPC 与一次性密码相比如何？Stripe 表示，使用 SPC：

* 转换（交易完成）增加了8%。

* 用户验证时间缩短为原来的1/3。

* 欺诈数量低到可以忽略不计。

我预计工作组将把 SPC 作为一项正式提案，这意味着我们将有很多工作要做：

* 更多的实验（包括与银行共同实验）

* 技术规范的初始工作。

* 谷歌将实现扩展到其他平台。

* 与更多浏览器供应商合作。

* 讨论各种支付系统和流程中的业务诉求。如 EMV® SRC（Secure Remote Commerce，安全远程商务）、The Clearing House 的实时支付、欧洲的 Open Banking 等。

* 与 WebAuthn 工作组和 FIDO 联盟沟通，确保 SPC 工作内容的对齐。

* 与 EMVCo 3DS 工作组协调改进 3DS 或 SRC 功能，以支持 SPC。

* 了解SPC与其他认证委托用例的联系；例如，请参阅新的白皮书用于商家和钱包服务的 FIDO SCA 代理。Web 支付安全兴趣小组为 EMVCo、FIDO 和 W3C 提供了讨论使用场景的平台，以及如何确保各种技术能够灵活地互操作。 

我要感谢所有迄今为止为讨论、编码和实验做出贡献的人，特别是 Stripe、Google 和 Coil 的同行们。