Payments and Authentication: Driving toward a Whole Greater than Parts

Many forces are driving rapid changes in the payments industry, including the ubiquity of mobile devices, regulatory requirements (e.g., PSD2 in Europe), and real-time payments initiatives. COVID-19 is also changing the landscape as more companies move their activities onto the Web and face new fraud risks.

W3C groups and other organizations are developing new Web capabilities to rise to these challenges. To enable secure end-to-end payment experiences, all of these capabilities need to work well together, taking into account the full user journey. I am involved in a number of coordination activities to help raise awareness and foster interoperability, including:

• The Web Payment Security Interest Group, a forum to pursue interoperability of technologies from EMVCo, the FIDO Alliance, and W3C. This group also liaises with other groups such as the W3C Privacy Interest Group (e.g., about browser privacy trends) and the OpenID Foundation.
• A joint task force between the Web Payments Working Group and the Web Authentication Working Group. The primary mission of this task force is to inform Web Authentication capability discussions based on payments use cases. We seek to create education materials to help the payment industry adopt FIDO2.

Conversations have been very productive, and people are beginning to bring forth concrete proposals for using independently developed technologies in creative ways. In some cases, the proposals appear to improve security, usability, and privacy all at the same time. Since that is rare, these are exciting discussions.

Here are a few of the conversations that are taking place.

Authentication

A variety of forces are driving discussions about authentication, notably European regulatory requirements in PSD2 for strong customer authentication (SCA). Here are a few of the topics that we have discussed in this area:

• How can FIDO be used to address SCA under PSD2? See the FIDO White Paper on this topic.
• EMV® 3-D Secure 2 is also positioned to fulfill PSD2 SCA requirements. However, it relies on browser fingerprinting and third-party cookies. Browser vendors are changing behaviors in this space (e.g., changes to SameSite behaviors in Chrome, for example), and this is having an impact on 3-D Secure implementations. We've been discussing new strategies (e.g., Storage Access) to meet industry requirements with superior privacy protection.
• We have also been discussing how FIDO authentication might be used as input to 3-D Secure processes. EMVCo and FIDO in particular are discussing their connection (see this 2018 press release).

Several recent discussions have also looked at how to streamline authentication during payment flows by leveraging both Web Authentication and Payment Request API in innovative ways:

• Dirk Balfanz (Google) gave a presentation on an idea where a relying party could create Web Authentication credentials usable by itself and another origin. This could allow, for example, a user to enroll with their issuing bank, and for the bank to mint a credential shareable with the user's payment handler. This would enable the payment handler to control the user experience of authentication, and to pass on the authentication assertion to the issuing bank for validation (e.g., as part of a 3-D Secure flow).
• In March the Web Authentication Working Group reached a decision that could also improve the user experience of authentication within a payment handler. The decision allows for cross-origin iframes to call Web Authentication get(). This could be useful during a 3-D Secure flow, where the issuing bank wants to perform FIDO authentication, but without a full top-level redirection from the payment handler's origin.
• Adrian Hope-Bailie (Coil) has proposed streamlining authentication by leveraging the same user gesture to initiate authentication and launch a payment handler.
• The same Adrian Hope-Bailie has been discussing a "minimal UI" experience in Chrome (mentioned during TPAC 2019 last fall ) where the user simply authenticates to confirm a payment. I am looking forward to upcoming working demos of this streamlined experience.

Privacy / Storage

Above I referred to browser trends to limit third-party cookie behaviors. In addition to SameSite changes in Chrome, see also Apple blog posts, Mozilla Enhanced Tracking Protection, and Google's plans to make third-party cookies obsolete. These changes have an impact on a variety of Web activities, including advertising, session management, and payment industry risk engines. Discussions about the evolution of Web capabilities are taking place in various fora, including W3C's Improving Web Advertising Business Group.

The Web Payments Working Group has been discussing a proposal that payment handlers open in a third-party context by default. However, payment handlers by their nature involve sharing data across origins, so we want them to be able to easily request first-party storage access. Current conversations with browser vendors involve optimizing how to make payment handlers readily available to users, how to ensure users are aware of them and consent to using them, and how to manage "powerful features" (such as first-party storage access) that might be granted to trusted parties in a known payments context. One idea is that an explicit but streamlined registration ceremony would enable payment handlers to perform better than other out-of-the-Web-box solutions for some use cases.

Changing storage behavior will also affect session management. In our discussions about how to carry out Secure Remote Commerce (SRC) transactions through Payment Request API, we have been evaluating ideas to reduce the friction of user recognition across transactions, in a way that aligns with evolving browser behavior and user expectations. One question I have: is the right approach to make it "easier to get in" than "harder to get out?" That is: can we make it very easy for users to be logged back into a payment handler (or otherwise recognized by some relying party) via something like the Credential Management API? I noticed some developer documentation on using that API for one-tap sign-in, and even automatic sign-in under some conditions.

Transaction Confirmation

Another topic from PSD2 is dynamic linking, which I have heard summarized as "what you see is what you sign." As I understand it, the goal is to have a trustworthy record that a user agreed to pay some amount to a particular beneficiary.

The Web Authentication Working Group formulated a "transaction confirmation" extension to Web Authentication Level 1 for this use case. However, the group recently removed the feature from Web Authentication Level 2 due to lack of implementation. The use case is still of interest, and so we are discussing alternative approaches in the joint task force between the Web Payments Working Group and the Web Authentication Working Group, as well as in the WPSIG. We have started discussion of an early proposal from Adrian Hope-Bailie that leverages trust enabled by the combination of Payment Request API and Web Authentication.

One note on the Transaction Confirmation Extension in Web Authentication Level 1: it remains in that specification in case anyone wants to take a crack at implementing it.

Open Banking

In a recent meeting, the Web Payments Working Group heard updates from multiple European open banking initiatives, including Open Banking UK, STET, the Berlin Group, and SWIFT. We continue to look for opportunities to leverage Payment Request API and FIDO Authentication in open banking flows.

Also in the context of open banking several people have drawn our attention to the Financial-grade API (FAPI); we are just starting to learn more.

Help us Drive Adoption

First I want to thank all the engineers from the many organizations working on these technologies and proposals to improve Web security, usability, and privacy (in payments and other areas). Please contact me if are interested in getting involved in the efforts I've mentioned above.

I also want to mention a new opportunity. FIDO2 is particularly exciting now that Web Authentication is widely deployed in mobile and desktop browsers and support for built-in authenticators continues to grow. If you'd like to help support the adoption of FIDO2, please consider joining the WebAuthN Adoption Community Group.

We are also finalizing our plans for a new group devoted to the use cases and requirements of merchants. Although we already benefit from the participation of some merchants, the Merchant Advisory Group, and some stakeholders such as integrators that enable checkout experiences, we recognize that we need more direct input from merchants about their priorities, such as payment method choice, protection against fraud (as I mentioned at the top of the post), and user journeys. I look forward to sharing more details in the very near future about this new Merchant Business Group.