2018年8月， EMVCo发布了EMV® 3DS测试平台，并开始正式发放认证证书。众多3DS方案提供方陆续启动测试申请。中国银联同步向成员机构发布了银联3DS全球推广计划，各大卡组织也根据EMVCo进度发布或更新了系统改造升级计划。这一系列动作使3DS这个熟悉又陌生的词汇再一次走进了大众视野中。究竟什么是3DS?3DS对商户和银行会带来什么样的影响呢?接下来笔者将带各位走近这个神秘又新鲜的新一代标准。

　　什么是3DS?

　　3DS，即3-Domain Secure，是一种针对在线交易场景的身份验证协议，使发卡行可以率先验证持卡人的身份信息，通过基于数据的风险评估决定最终授权，是在线交易的一层额外安全保障。顾名思义，它涉及到三个不同“域(Domain)”的信息联动, 三个域分别指收单域、发卡域以及交互域。通过这三个域之间的信息交换与确认，持卡人的身份得到验证，防止了银行卡在未经授权的情况下被盗用，提高了在线交易的安全性。

　　3DS从一代到二代的重大变化

　　Visa于2003年提出3DS第一代版本(3DS 1.0)，之后由EMVCo于2016年发布第二代版本(EMV® 3DS)。此次3DS升级带来的变化重点如下表所示：

　　表1 3DS第一代与第二代的主要区别

　　EMV® 3DS的应用场景是什么?

　　在笔者看来，3DS的应用场景可以由三个维度进行组合，这三个维度分别为：验证入口(浏览器/App)，交易类型(payment authentication/ non-payment authentication，即支付验证/非支付验证)，以及持卡人体验(平滑模式(frictionless)/挑战模式(challenge))，即无需持卡人反馈/需要持卡人反馈)。三个维度的组合极大提高了3DS协议的灵活性以应对更多的应用场景。

　　举个例子，某持卡人正在使用线上购物服务。持卡人可以通过浏览器或是移动端App来进行后续的验证与交易授权流程，这便是不同的验证入口;在持卡人结算购物车或是将银行卡绑定至电子钱包时的身份验证，分别对应了支付验证与非支付验证的需求。在身份验证过程中，发卡方可通过3DS协议中要求上送的信息对验证风险进行评估, 持卡人若是处在低风险的场景中(如在常用的设备上进行小额交易)，便不用提供额外的验证信息，即平滑模式的验证流程;反之，发卡方可要求持卡人提供额外信息来验证身份，即挑战模式的验证流程。

　　EMV® 3DS的优势

　　首先，EMV® 3DS支持了更多样的验证方式，意味着提供了更高的安全性。如与发卡行app的结合、调用持卡人的生物信息等，使得持卡人可以规避单一验证方式被技术手段攻破所带来的风险。

　　其次， EMV® 3DS可以为持卡人提供更加平滑的用户体验。通过机器学习、大数据、与第三方验证机构合作等方式的结合应用，3DS可以使持卡人更准确地以平滑模式进行支付，令在线交易体验更放心、更舒心。

　　第三，标准统一也是值得一提的改进点。在第一代时，各卡组织应用的都是自家定制的“3DS协议”，例如Visa的Verified by Visa，万事达的MasterCard SecureCode，以及美国运通的American Express SafeKey。这种各卡组织“自扫门前雪”的做法，显然会给持卡人造成不一致的、困惑的用户体验，在协议技术上的升级也无法保证做到同步的及时跟进，不利于3DS的推广普及与更新迭代;而EMV® 3DS由EMVCo进行统一发布、管理，具有更强的普适性和灵活性，有助于3DS在用户心中形成更统一更鲜明的品牌印象，也有助于对出现的问题和新鲜的技术进行快速响应。

　　最后，不仅持卡人会从3DS中获益，商户也可以因应用3DS进行验证而享受到风险责任转移(liability shift)的福利。这是指通过3DS验证成功的交易，风险责任从商户转移至发卡行，即商户不用承担支付退款的责任。这对于商户来说是实打实的益处。

　　综上所述，EMV ® 3DS对移动支付场景的支持更加灵活，标准的制定和修订更加规范，可以有效推动线上交易安全体系的形成。

　　EMV® 3DS的技术流程

　　说了这么多3DS的宏观概念，接下来让我们探索3DS的技术流程。以挑战模式为例，下图便是一次完整的3DS验证报文传递流程：

　　图1  EMV® 3DS的挑战模式信息传递流程

　　不要被繁杂的箭头和英文所吓倒，我们来逐步揭开3DS的神秘面纱。首先要强调的是，3DS是一个只处理身份验证报文的协议，而上图中虚线箭头连接的流程都是授权相关的，所以这些其实是3DS验证通过后为完成整个交易流程而执行的后续步骤，不包含在3DS标准中。所以，3DS的相关验证报文只在3DS Client、3DS Server、Directory Server(DS)、Access Control Server(ACS)四个组件中进行转发。

　　3DS Client：

　　集成在商户侧、运行在持卡人设备上的、具备3DS功能的客户端。根据设备的不同，可以是集成在浏览器上的一段脚本，也可以是集成在商户app上的sdk，负责收集设备信息和提供发卡行验证界面。

　　3DS Server：

　　发起3DS验证流程的后台服务器， 负责3DS验证报文的信息收集，以及与3DS Client，Directory Server的通信 。

　　Directory Server：

　　在交易流程中交互域的用于处理并路由3DS报文的服务器, 是整个3DS流程的信息枢纽，通常由卡组织承担。负责在3DS Server与ACS之间转发3DS报文，同时负责定义3DS流程中交互域相关规则。

　　Access Control Server：

　　发卡域的用于处理3DS报文的服务器。负责判断验证信息是否有效，及判断是否需要持卡人进一步提供相关信息进行后续验证(即是否进入挑战模式)。

　　了解了各组件承担的职责后，理解整个挑战模式的流程便容易得多。按照“目的”维度分类，报文可分为验证(Authentication)、挑战(Challenge)、结果(Result)三类。这三类报文，从由3DS Server经过DS向ACS发出的验证请求(Authentication Request)报文开始，按照“先求验证、再定挑战、后谈结果”的顺序处理，而每一个步骤都要由最终接收到请求报文的组件返回一个相应的回复报文。若验证为平滑模式，则不存在挑战报文，故ACS与3DS Client间不进行互相通信。由此可见，3DS是一个简明又严谨的，充满着工程美学的协议。

=============================================================================================

声明：本文为转载，该文观点仅代表作者本人。奥航智讯转发的内容如侵犯个人及公司合法权益，请及时联系，我们将及时处理。

微信公众号搜索" 奥航智讯 "加关注

【微信扫描下图可直接关注】