An EMV® 3-D Secure view of EMVCo, FIDO, and W3C activities

In September 2020 the Web Payment Security Interest Group published “How EMVCo, FIDO, and W3C Technologies Relate” to describe the relationship between technologies such as EMV® 3-D Secure (hereafter “3DS”), Payment Request API, and FIDO / Web Authentication. In this post I describe some of the current thinking about how to use those technologies together to improve the user experience and security of Web payments.

3DS Background

3DS seeks to reduce remote commerce fraud by authenticating the cardholder. Merchants that leverage 3DS may be eligible to receive a “liability shift” benefit. Because 3DS makes it possible for issuing banks to perform multifactor authentication, it can also be used to satisfy the Strong Customer Authentication (SCA) requirements of the European regulation Payment Services Directive (PSD2).

The industry has devoted a lot of energy to reducing friction during cardholder authentication. To that end, 3DS defines two flows. The “frictionless” flow involves risk assessment by the issuing bank (or its Access Control Server partner) without requiring a user gesture. On the Web, this is generally accomplished by collecting device information (via JavaScript) during checkout and looking for stability in the device information across transactions. According to my colleagues, this first flow suffices for a large majority of cases, and is thus a valuable tool in fraud reduction. However, in some cases (e.g., high value transactions, changes to the device information, compliance with local regulations such as PSD2, etc.) the issuing bank may seek additional data through the second flow, called the “challenge” flow. The bank may use a variety of authentication methods during this flow. For example, the bank can display a form during checkout where the user enters a one-time password they receive on their mobile phone. In Europe, as of 1 January 2021, the one-time password approach cannot be used as a knowledge factor under the strong customer authentication requirement of PSD2.

In both situations, after the flows complete successfully, the bank returns an “authenticationValue” (AV) to the merchant as confirmation that the bank has authenticated the cardholder.

In addition to this sort of regulatory requirement, two changes to the Web ecosystem have motivated members of EMVCo, FIDO Alliance, and W3C to explore new ways to reduce user friction during 3DS:

• Web Authentication is now ubiquitously supported in all major browsers and billions of devices now offer FIDO-compliant authenticators.
• Browser vendors are changing browser behavior to foster greater user privacy, and this will have an impact on the traditional device information techniques of the 3DS frictionless flow.

Below is my summary of approaches we are discussing to enhance 3DS flows with FIDO authentication and Payment Request API.

Protocol Observations

These observations drive some of our design choices and constraints:

• In situations where the issuing bank authenticates the cardholder through 3DS, the issuing bank by default will be the Relying Party. However, the issuing bank may delegate that role to other parties, as we discuss in one scenario below. (We do not discuss here all possible delegation scenarios.)
• FIDO authentication depends on randomized challenges to avoid replay attacks. These challenges are generated by Relying Parties, in our case the issuing bank.

FIDO in the Frictionless Flow

One way to reduce authentication friction during checkout is to try to make use of previous authentications.

Suppose a merchant site supports login through Web Authentication rather than username/password. If the user logs in and begins to shop, is there a way to reuse the FIDO authentication during a 3DS checkout?

If the merchant is the Relying Party, the merchant provides the randomized bits used in the Web Authentication challenge. This means that even if the merchant passes the resulting assertion to the issuing bank, the bank may not have the same level of cryptographic confidence. (The bank and merchant might have an out-of-band agreement, but that would be beyond the scope of the standard and not scale easily.)

However, there are other ways to take advantage of prior authentication to a merchant within the 3DS frictionless flow. In essence, the merchant can send some FIDO information to the issuing bank (e.g., credential id, authentication date), and the bank risk engine can review it for consistency across transactions. A FIDO Technical Note and related EMVCo white paper describe in detail what FIDO-related data to provide on the 3DS rails.

FIDO in the Challenge Flow

To leverage Web Authentication during the challenge flow, the Relying Party —the issuing bank— would ordinarily need to be the origin that (1) challenges the user and (2) validates the resulting assertion. Traditionally this has meant redirecting the user to a first-party context (the issuing bank origin), which is not a great user experience. Web Authentication Level 2 provides a new capability: the Relying Party can challenge the user from a third-party context in an iframe. However, this requires embedding code from issuing bank origins, and some payment service providers have indicated that this is suboptimal since not all issuing banks are known in advance to those payment service providers.

Colleagues from Stripe, Google, and Coil have proposed a new way to streamline authentication during a payment: if the browser is confident that the user has knowingly embarked on a transaction, the browser can relax a Web Authentication constraint and allow a third party to challenge the user. The bank would still need to validate the resulting assertion in a 3DS context, but origins other than the Relying Party could challenge the user as long as the user is in a “payments context.”

How does the browser recognize that the user is in a “payments context?” One answer is: if the user is engaged in a Payment Request API user experience. In other words: browsers have implemented Payment Request API to make clear to users “you are starting a transaction” and to protect users by requiring gestures, etc.

This proposal to couple Payment Request and Web Authentication is called Secure Payment Confirmation (SPC). SPC gives special powers to developers they would not have using Web Authentication “out of the box” in a non-payment context. In addition to enabling very low friction checkout with strong authentication, SPC will enhance payment security by including reliable transaction data in the authentication results; more on this below.

Here’s how we imagine it will work:

• Enrollment. During a transaction or at some other time, the user enrolls their authenticator with the Relying Party. The browser augments the usual authentication credential with extra displayable payment instrument information. Specifically: a short string (e.g., a masked account number) and an icon (e.g., of a credit card company or bank).
• Transaction. The party using SPC provides the browser with one or more Web Authentication credential ids and says “Please authenticate the user with any of the corresponding authenticators (e.g., first match wins). The browser then asks the user if they want to authenticate to pay using the corresponding authenticator.

Starting in December 2020, Stripe began an experiment with SPC in a Chrome origin trial (limited to MacOS). We would like to know whether users prefer a “light” challenge using biometric authentication in a window presented by the browser, or the traditional 3DS challenges presented by the issuing bank (traditionally based on one-time codes). If users like the experience —and if conversions go up and fraud goes down— this will bolster the case for using SPC as a way to satisfy PSD2 SCA requirements. We will also want to compare the SPC experience (and outcomes) to out-of-band authentication via a native app.

Where does the calling origin get the credential ids? We expect different approaches in different payment methods. For the 3DS case, here is the expectation:

• The user will select a card for payment (e.g., by completing a form on the merchant site, or by selecting a previously used card).
• The merchant (or payment service provider) will initiate a 3DS transaction and ask the issuing bank “Do you have any credential ids associated with this card?”
• The issuing bank will return a list that is then used as input to SPC.

EMVCo is helping to explore how best to integrate SPC with their 3DS protocol.

One more note: PSD2 also includes some requirements related to “dynamic linking“: evidence that the user was made aware of and agreed to the payment instrument, amount, and beneficiary of a transaction. We think that SPC will be able to help with compliance. The browser has this information when Payment Request and Web Authentication are used together in SPC. Chrome’s new UI displays the information to the user, signs it using the authenticator, and returns it so that the Relying Party can verify cryptographically what the browser displayed to the user.

To recap: EMVCo, FIDO, and W3C are working together on ways to use FIDO authentication and Payment Request API in both 3DS frictionless and challenge flows. We intend for SPC to be useful in the fulfillment of PSD2’s SCA and dynamic linking requirements.

After Stripe publishes its results, I hope and expect that the Web Payments Working Group will devote a lot of its time in 2021 to SPC. To ensure it can be used with a variety of payment methods, we would reach out to our open banking colleagues, to participants from NACHA and TCH, to our colleagues working on EMV® Secure Remote Commerce (SRC), and others to ensure that the design supports a variety of use cases.

Acknowledgments

Thanks to Benjamin Tidor, Danyao Wang, Adrian Hope-Bailie, Rouslan Solomakhin, and others working on SPC. Thanks to Jonathan Grossar, Benjamin Tidor, Sameer Tare, Christian Aabye, Doug Fisher, and Richard Ledain for input on this post.

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.