TPAC Recap (2021 Edition)

The Web Payments Working Group held a remote meeting 25-28 October (agenda, minutes) as part of TPAC 2021.

The meeting took place one week after TPAC breakouts, which included sessions I think were of particular interest to the payments industry, including: Anti-Fraud for the Web, The State of Web Monetization, Cross-Device Security (caBLE), The state of browser storage partitioning, and The intersection of Web Monetization, the Creative Economy and Diversity. Some of these topics infused the Working Group agenda.

The main themes of our agenda were: strong authentication, user recognition and privacy, and Payment Request reviews. In addition, we heard updates on two incubation topics: Google on Digital Goods API and Coil on Web Monetization.

Strong Authentication

On Monday we jumped into discussion about Secure Payment Confirmation (SPC), our primary deliverable related to strong customer authentication (SCA). The Chrome team reported on implementation status, including the fact that SPC support now ships in Chrome 95 stable. We also made progress on some key SPC issues.

On the second day Adyen described the SPC pilot they are currently running with Airbnb. I recommend checking out the user experience featured in Adyen’s registration video and Authentication video; descriptions are available.

We met with the Web Authentication Working Group on the third day to discuss care and feeding of the relationship between SPC and Web Authentication. For example, in the current draft specification SPC credentials are FIDO credentials with subtype “payment.” SPC credentials can be used for login use cases, but (at least in the current implementation) vanilla Web Authentication credentials cannot be used with SPC. In the current model, it is not possible to alter the nature of existing credentials (from vanilla-to-SPC or vice versa). This led to conversations about whether the ecosystem might find itself creating SPC credentials “by default” to make them useful for both login and payments. We also discussed ways to help FIDO server operators avoid accidentally allowing an SPC credential to be used for login use cases.

The Web Authentication Working Group also shared their vision for new features in WebAuthn Level 3, including:

  • Delegation (of authentication rights to others).
  • User experience improvements. Relying parties may at time hesitate to use Web Authentication because they don’t know whether there is a credential on the current device. The label “non-modal UI” was used to refer to mechanisms that would help create an acceptable user experience without revealing device information to the relying party.
  • Support for relying parties signaling a desire for re-authentication.
  • Backups and recovery, including potentially synchronizing keys across boundaries (that is, not requiring all keys be hardware-bound).

In the current implementation of SPC, any SPC credential may be used by any origin to initiate an authentication ceremony. During the meeting it was suggested that some relying parties might want to benefit from the transaction confirmation dialog, but might not want other origins to be able to initiate the authentication ceremony. (Following the meeting we logged this as Issue 157: Consider separating the SPC powers of Third Party invocation and Payment display.)

That topic in turn suggested that the current implementation of the SPC credential as a “payment” subtype may not suffice. And the current implementation prevents credential behavior from changing over time: a credential cannot start life as a login credential, be changed with user consent into a login+payment credential, have the login power revoked, etc. I anticipate ongoing productive discussions with the Web Authentication Working Group about which functionalities migrate from SPC to Web Authentication and keeping everything in sync.

User Recognition and Privacy

SPC is gaining traction as our mechanism for strong customer authentication for Web payments. However other user recognition use cases also remain of high interest. At least for now there seem to be two important user recognition use cases:

  • Risk calculations. For example, the EMV® 3-D Secure Protocol “frictionless flow” relies on data collection for risk assessment, and some aspects of that data collection may become more difficult as browser behaviors change around cookies. (We had already begun to document some requirements related to EMV® 3-D Secure.)
  • Stored user profile information available cross-origin. Some applications want to know who the user is in order, for example, to display that user’s available payment instruments.

For the risk calculation use case, our colleague from Entersekt described the pertinent question this way: Have I seen this user on this device with this instrument, and has the user consented to be identified with this device to make this payment experience better? We heard that billions of transactions fail due to inadequate risk assessment, and so this is a serious problem that requires attention.

Can we devise a browser capability to help minimize friction in the user payment experience (e.g., no additional challenge to the user after pushing the “pay” button, no redirects to a first party context) while protecting the user’s privacy (e.g., by not sharing strongly identifying information silently across origins)? We acknowledged that there are other anti-fraud use cases that might (or might not) overlap in scope so we should join those discussions. We also recognized the need to be attentive to the potential for abuse of any strongly identifying capability.

We lightly discussed several ideas during the meeting (please refer to the minutes) and it is clear that there is strong interest in more discussion of these use cases.

For conversations about both SPC and user recognition, we were fortunate to meet with representatives from both the W3C Privacy Interest Group and the Privacy Community Group.

Payment Request Reviews

The W3C Membership recently reviewed Proposed Recommendations for Payment Request API and Payment Method Identifiers; I hope that we will soon wrap up our work on those specifications.

We met with the Internationalization Working Group during our meeting to discuss approaches to support the internationalization of human-readable strings in specifications (both Payment Request (pull request 971) and SPC (issue 93)). The Internationalization Working Group seeks to define a Web-wide approach for specifications to define human-readable strings and so the Web Payments Working Group will likely adopt it as the proposal advances.

Next Steps

I think these are the main next steps for the Working Group:

  • Publish version 1 Recommendations of Payment Request and Payment Method Identifiers.
  • For SPC:
    • Address SPC issues
    • Make improvements based on pilots from Adyen/Airbnb and Stripe
    • Seek implementation in other browsers, and flesh out the test suite to encourage interoperability.
    • Continue to coordinate with the Web Authentication Working Group, Web Payment Security Interest Group, and horizontal review groups.
  • Refine use cases and requirements around user recognition use cases. (Following the meeting an Anti-Fraud Community Group was launched.)
  • Recharter. I hope to send our draft charter for W3C Member review within the next month.

A Moment of Gratitude

At the meeting, Adrian Hope-Bailie announced to the Working Group that he plans to step down as co-Chair (but remain involved). The Working Group shared their appreciation of Adrian’s commitment. I would like here to emphasize how important Adrian has been to this project and to the Web. And we’ve had great fun. Thank you, Adrian!

SPC Design Choices for Flexibility and Scale

SPC authentication dialog allowing user to consent to payment through Web Authentication.

An important goal of Secure Payment Confirmation (SPC) is to streamline strong customer authentication (SCA). One way to reduce friction is to allow many authentications for a given registration. In other words, ideally the user registers once and can then authenticate “everywhere” (consistent with the policies of the relying party; they have to opt-in).

Several recent API design and implementation choices have expanded our vision of “everywhere.”

During an SPC authentication the browser displays a prompt to the user: do you wish to pay this amount to this merchant using this instrument? In the original SPC implementation the relying party (for example the bank or card issuer) provided the instrument information (a label describing the instrument and a icon) at registration time. This turned out to overconstrain the API, so now the instrument information is provided at authentication time. How does this expand “everywhere”? The user may have multiple instruments with a relying party (e.g., multiple cards or accounts with a bank). The new SPC approach allows the user to register once with the relying party and use that registration with multiple instruments. The relying party decides, at authentication time, which instrument information the browser should display.

In the original SPC implementation credentials were stored in the browser, which meant that as soon as the user moved to a new browser, a new registration would be required to use SPC. A second recent change has been making SPC work with (FIDO) discoverable credentials. This allows the browser to determine at authentication time if there is an authenticator that matches the credentials provided as input to SPC. Although discoverable credentials are not yet interoperable on all platforms, we are headed in that direction. How will this expand “everywhere”? First, the user can use SPC in a new browser on their device without a new registration; the existing registration is discovered on the fly at authentication time. Second, we hope to see wider adoption of technologies that let people use their mobile devices as authenticators during desktop authentication (e.g., caBLE). This should increase the range of authenticators with discoverable credentials.

The choice of relying party also has a direct impact on the scope of “everywhere.” If the relying party is, for example, an issuing bank, as long as other parties in the ecosystem (notably payment service providers) can query the bank for SPC credentials, the user should be able to authenticate on any merchant using any PSP for the same registration. That is the most expansive vision of “everywhere.” However, different stakeholders will move at different speeds for a variety of security and practical reasons. In the meantime, other parties may choose to play the relying party role. For example a payment service provider might act as the relying party. In this case (a form of delegated authentication), the user could reuse a registration across all merchants served by that payment service provider. The user would likely have to register anew with each new payment service provider. As a Working Group, our goal is to design the API to support a variety of flavors of relying parties: banks, companies that provide services to banks, companies that provide payment services to merchants, and so on.

Another axis of flexibility involves the integration of SPC into an underlying protocol. Payment service providers need to be able to ask relying parties (e.g., banks) for SPC credentials, and to return assertions to relying parties for validation. I am excited that the first SPC integration will be in EMV® 3-D Secure version 2.3. Likewise, as FIDO authentication becomes more commonplace for bank login experiences, I expect users will want the same type of experience for payments directly from their bank accounts. I hope that these integrations drive interest in the API and get us closer to “everywhere.”

We’ll talk about all of this in more detail soon at the Working Group’s October meeting.

Remote Meeting Agenda in Development

We are building the agenda of the Web Payments Working Group’s next virtual meeting, 25-28 October. The meeting is part of TPAC 2021, and so are planning several joint discussions with other W3C groups, notably on topics of Web Authentication, Internationalization, and Privacy. In addition to those conversations, our main focus will be Secure Payment Confirmation (SPC). I anticipate we will discuss SPC experiments (Adyen/Airbnb and Stripe), the integration of SPC into EMV® 3-D Secure version 2.3, other potential integrations, and deployment status in Chrome.

We typically organize some future looking sessions. This time around Coil is leading a discussion on “Unlocking the Potential of the Internet of Value”. A session like this is particularly timely because we are in the process of rechartering the group and want to be sure that we can accommodate emerging participant interests.

I expect our agenda to solidify over the next couple of weeks, so check back soon.

SPC is a First Public WD

My congratulations to the Web Payments Working Group for the publication today of Secure Payment Confirmation (SPC) as a First Public Working Draft. The specification is taking shape in part thanks to experimentation by Adyen and Airbnb, the results of which I anticipate we will hear about at our October TPAC meeting if not sooner. We also look forward to a second experiment from Stripe, whose first experiment led to a number of changes in the Chrome implementation. Our colleagues at EMVCo have shared publicly that they anticipate integration of SPC into EMV® 3-D Secure version 2.3, and I look forward to seeing that specification soon. We also continue to pursue our conversations about integration into other underlying protocols, such as EMV® Secure Remote Commerce and Open Banking.

In other Working Group news:

* We have stopped work on the Basic Card specification. Some participants have expressed interest in exploring a replacement, so we will begin use case discussions this week.
* We have started group review of a draft charter; our current charter expires at the end of 2021.
* We are building our agenda for the October TPAC meeting.

I look forward to a busy next few months.

Updates on Payment Request V1 and SPC

I want to share two updates from the Web Payments Working Group.

The first is that we are preparing a slimmed down version of Payment Request API version 1 to advance to Recommendation by early August. Privacy and internationalization reviews led us to look closely at features related to requests for shipping/billing addresses and contact information. To satisfy some of those concerns and because the features are not widely used in the wild, our plan is to remove them. Doing so should also make it easier for browser vendors to maintain their implementations of the API, and for the Working Group to add new features. Once we’ve adopted these changes (following a Call for Consensus to the Working Group), we will return to Candidate Recommendation for a brief period, then proceed mid-July to Proposed Recommendation.

The second topic is Secure Payment Confirmation (SPC). (For an introduction, see the previous blog post on SPC and the Stripe Experiment.) The Web Payments Working Group held a 4-day remote meeting in early April to discuss SPC, including:

To focus our SPC deliberations, a few weeks ago we created an SPC task force within the Web Payments Working Group. One of the first goals was to craft a clear answer to the question “What is SPC?” Here is our current draft (subject to change; feedback welcome):

Secure Payment Confirmation is a Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.

The task force has also taken a stab at answering the question “What is unique about SPC?” and capturing some consumer-to-business user stories. After our work on SPC scope we will progress to gathering requirements and prioritizing feature requests.

In parallel, the Chrome team has launched a second origin trial for SPC and updated developer documentation for those who wish to experiment.

Our work on use cases and requirements, as well as feedback from the growing number of pilots (Stripe version 2, Airbnb + Adyen) will inform the shape and initial capabilities of the API.

Now is a great time to experiment; please contact me or the Chrome Team for more information about participating in the second origin trial.

Secure Payment Confirmation, Stripe Experiment, and Next Steps

Mockup of transaction dialog for SPC

On 18 March Stripe presented the results of their 3-month experiment with Secure Payment Confirmation (SPC) to the Web Payments Working Group (minutes). The results were quite exciting: conversions went up by 8% and authentication sped up considerably. I share details below and you can find more in the Stripe presentation.

The vision for SPC is to streamline strong customer authentication (SCA) during a Web payment. This will improve Web commerce experiences, enhance security, and help the payments industry fulfill regulatory requirements (e.g., PSD2 in Europe). SPC does not yet exist as an API or a well-defined set of browser behaviors. The Stripe experiment tested some hypotheses for what SPC could become. Google engineers made the experiment possible through modifications to implementations of Web Authentication and Payment Request API in Chrome on MacOS. The Web Payments Working Group is about to embark on a more systematic elaboration of SPC’s features and scope.

The Stripe experiment sought to understand if users prefer strong authentication through one-time passwords or FIDO authentication. Why FIDO? The combination of CTAP from the FIDO Alliance and Web Authentication from W3C —commonly referred to as FIDO2— is an ideal backbone for an SCA solution. It is supported on all major browsers (desktop and mobile). Billions of deployed phones and laptops include built-in authenticators. FIDO2 provides better security and usability than passwords and explicitly seeks to meet regulatory requirements (see the FIDO white paper on meeting PSD2 SCA requirements).

For simplicity, the SPC experiment focused on card payments where the initial enrollment was performed with EMV® 3-D Secure (“3DS”). As I mentioned in a previous blog post, EMVCo, FIDO, and W3C are discussing multiple ways of using FIDO with 3DS. The experiment focused on using FIDO during the 3DS challenge flow. This proved a very informative starting point, but part of our ongoing work will be to ensure that SPC can be used in a broad range of payment flows and systems.

To understand the motivation for SPC, it is useful to consider how 3DS works on the Web today. My explanation is a simplified version.

  • An important design goal 3DS is to enable the bank that issues a credit card to determine whether the person planning to use the card for an ecommerce payment is authorized to do. However, when a user is shopping, the user is interacting with a merchant, not their bank.
  • One way to “get the user to the bank” is through an HTTP redirect to the bank’s Web site (in a first party context) for authentication. People tend to not like this solution for a variety of usability reasons. Merchants do not like directing their customers away from their site.
  • Another solution is to include code from the issuing bank in the merchant site (in a third party context). Payment services providers (to merchants) typically take this approach using iframes, but without Web Authentication.

Let’s examine why. In Web Authentication Level 1:

  • A relying party must register an authenticator in a first party context.
  • The relying party is the only party that can authenticate the user.
  • The relying party can only do so in a first party context.

In other words, with Web Authentication Level 1, the issuing bank (assuming it operates in a different origin than the merchant) could not use Web Authentication to authenticate the user within the merchant page (in a third party context).

To overcome this limitation, the Web Payments Working Group asked the Web Authentication Working Group for an enhancement. As a result, in Web Authentication Level 2:

  • A relying party must register an authenticator in a first party context.
  • The relying party is the only party that can authenticate the user.
  • The relying party can do so in either a first or third party context.

Now the issuing bank can authenticate the user with Web Authentication from within a merchant page. That’s already a big win. But Stripe sought further improvements. They pointed out that embedding code from an issuing bank in a page involves more network calls and could create security policy issues. Instead, they wanted to be able to trigger Web Authentication themselves, collect the resulting assertion, and pass that on to the issuing bank through back channels. The issuing bank would still validate the assertion as the relying party.

This is how the first “superpower” of SPC came about. With SPC:

  • A relying party must register an authenticator in a first party context.
  • Any party can authenticate the user.
  • Any party can do so in either a first or third party context.

This is an important departure from Web Authentication behavior and so it is only available “in a payments context.” The current (experimental) definition of “in a payments context” is “during Payment Request API.”

SPC, in its pilot manifestation, thus marries Payment Request API and Web Authentication. The idea is that developers will have more superpowers via SPC than when the APIs are used independently.

The second superpower of SPC is the browser’s “transaction confirmation dialog.” The goal is to have a built-in browser capability to create a consistent authentication experience across Web sites and platforms.

This is another departure from Web Authentication. Web Authentication is performed within a window opened by some origin. Stripe asked the Chrome team if the browser could manage the window instead of Stripe having to open one. The result is a built-in browser dialog, shown in the mockup included above. SPC delegates the authentication UX to the browser. Here’s how SPC worked during the experiment, leading up to the transaction confirmation dialog:

  • During an enrollment (which I won’t describe in detail here), the user registers an authenticator with the issuing bank in a first party context. The issuing bank associates the user’s card with that FIDO credential.
  • During a transaction, on any merchant site, the user selects the same card to make a payment. Stripe (or any PSP) reaches out to the issuing bank (via a modified 3DS protocol) and asks: Do you have any FIDO credentials associated with this card? The issuing bank returns the shareable parts of any credentials it has stored, along with a random number (which will be used during authentication). Stripe calls SPC, and the browser opens the transaction confirmation dialog, asking the user: “Do you want to authenticate to pay N dollars to the following merchant using this card?” If the user proceeds, the platform (in this case MacOS) prompts the user to authenticate (in the experiment, using TouchID).

Stripe also wanted to leverage SPC to fulfill another PSD2 requirement: “dynamic linking.” The requirement involves cryptographic evidence that the user agreed to the transaction amount and beneficiary. The browser’s new transaction confirmation dialog displays the information required by PSD2, and when the user proceeds, the FIDO authenticator is used to sign the amount, beneficiary, and card information. Thus, the third superpower of SPC is built-in support for signed transaction confirmation data.

To summarize, the initial experiment with SPC involved these three new browser capabilities:

  • Relaxation of the constraint on who can authenticate the user for a given FIDO credential during Payment Request API
  • Transaction confirmation dialog built into the browser
  • Signed transaction data

We have started work to elaborate a list of SPC benefits that emerge from these three capabilities. I imagine these initial three capabilities will remain part of the SPC vision, but people are already curious whether we can add more, such as standardized enrollment flows, zero-friction flows, sources of randomness as input to FIDO authentication, and the ability to invoke SPC within a Payment App. We will discuss potential SPC features at the remote meeting of the Web Payments Working Group next week.

Back to the experiment. How did SPC compare to one-time passwords? Stripe shared with us that with SPC:

  • Conversions (completed transactions) increased 8%.
  • Users authenticated in less than 1/3 of the time.
  • There was negligible fraud.

I expect the Working Group will want to take up SPC as a formal work item, which means we’ll have a lot to do:

  • More experimentation (including with banks)
  • Initial work on a specification.
  • Expansion of implementation by Google to other platforms.
  • Engagement with more browser vendors.
  • Discussion of requirements from a variety of payment systems and flows (e.g., EMV® Secure Remote Commerce (“SRC”), Real-Time Payments from The Clearing House, Open Banking in Europe, etc.)
  • Coordination with the Web Authentication Working Group and the FIDO Alliance to make sure that SPC aligns with that work.
  • Coordination with the EMVCo 3DS Working Group for any enhancements to 3DS or SRC to support SPC.
  • Understanding how SPC relates to other authentication delegation use cases; see for instance the new white paper FIDO for SCA Delegation to Merchants or Wallet Providers. The Web Payment Security Interest Group provides EMVCo, FIDO, and W3C the forum for discussing these use cases and how to make sure the various technologies can interoperate flexibly.

I want to thank all the people who have contributed to discussions, coding, and experimentation so far, especially colleagues at Stripe, Google, and Coil.

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.

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.

Recap of October 2020 Extended Meeting

The agenda of the recent Web Payments Working Group meeting (19-22 October) spanned three broad topics:

  • Payment Request API, today and tomorrow
  • Streamlining authentication in payments flows
  • QR codes and more payment methods

Meeting minutes are linked from the agenda; below is my summary.

Payment Request API, today and tomorrow

We first discussed a plan to finalize Payment Request 1.0: it has shipped in Chromium and Webkit browsers for several years; can be used with Apple Pay, Google Pay, Samsung Pay; and is supported in several merchant libraries (e.g., Stripe and Braintree). After the meeting (and a Call for Consensus) the Chairs announced the decision to proceed toward Recommendation. Version 1.0 provided us with a lot of insights and now we can build on that experience.

Streamlining authentication in payments flows

We then discussed “next version” Web payment capabilities, some of which are already in development. In particular, we saw demos of Secure Payment Confirmation (SPC), designed to streamline strong authentication during checkout by marrying Payment Request and Web Authentication. Here’s how it works: Web sites call SPC with Web Authentication credentials as input. If the browser is able to authenticate the user using any of the (previously enrolled) credentials, it will prompt the user and return the resulting assertion to the site. In addition, SPC is designed to support “transaction confirmation” use cases, such as those described in European regulation (PSD2’s “dynamic linking”). SPC features a clear and secure display of key transaction details, reduces the total number of user gestures to authenticate, and eliminates the need for the site to open its own window for Web Authentication. Stripe showed a demo that leverages the preliminary implementation of SPC in Chrome 86. The demo is part of a pilot program that Stripe is running to test the hypothesis that users will prefer a low-friction authentication experience using Web Authentication (as part of an EMV® 3-D Secure step-up) to a typical one-time password experience. We look forward to hearing results from the pilot by early 2021.

We then heard from Visa and Mastercard about how SPC could enhance the user experience of EMV® Secure Remote Commerce (SRC) flows. (I apologize for the similarity between “SRC” and “SPC”!). Visa presented slides that show an SRC checkout demo including SPC leveraged by the merchant’s payment service provider. Mastercard shared mockups of an SRC checkout where a Web-based payment app uses SPC to streamline authentication.

My colleague from Mastercard referred to these approaches respectively as “the left side” (code running in the merchant site) and “the right side” (payment app code running on the user’s device). I appreciated that imagery, which I have similarly expressed in a Payment Request ecosystem diagram (shown in this post) where the merchant site (calling Payment Request) is on the left, the browser is in the center, and payment apps (native or Web-based) are on the right.

Block diagram of payment request components, with the merchant site on the left, the browser in the center, and payment apps on the right

We thus heard calls for SPC to be available for both left side and right side solutions. We have heard similar requests related to another user experience enhancement: “in-context display”. Today the Chrome implementation of the Payment Handler API includes a “modal window” in which payment app code runs. Chrome displays the origin of the code running in the window at the top, a security benefit. There is general agreement that this modal window, which appears above the underlying merchant context, provides a better user experience than a redirect. In-context display is thus available today on the right side, but not yet on the left. I anticipate we will turn our attention increasingly in 2021 to left side use cases as we continue to revisit Web payments architecture.

To round out our authentication discussion, the co-Chairs of the Web Authentication Working Group gave us an update on the progress of Web Authentication Level 2.

QR codes and more payment methods

We also discussed the following payment methods and use cases, looking for connections to Payment Request, SPC, and our architectural considerations:

  • QR codes: QR codes are very popular in some parts of the world, and have gained more attention during the COVID-19 pandemic as a way to communicate at a distance. We heard first from EMVCo, who is developing some new standards in this space. We also heard from two entities that are making use of that work: China Union Pay, and the European Payments Council on Mobile Initiated SEPA Credit Transfers. Our colleagues from Entersekt also shared perspectives on QR codes and Web payments, and these may help us structure our conversations moving forward.
  • Open banking: Colleagues from STET and the Berlin Group provided updates on the adoption of their open banking APIs, some challenges they are facing, and some new programs they expect to appear in 2021.
  • Web Monetization: Coil (one of the TPAC sponsors, thank you!) shared updates about Web Monetization deployments and a current strong interest in using it for use cases such as tipping and donations. We also learned more about the Grant for the Web, a Coil-led project to boost innovation around Web monetization.
  • Real-time Payments (RTP) and bill pay: The Clearing House described advances in the Real-Time Payments (RTP) protocol as well as a bill pay use case where the Payment Request architecture could be a good fit for enabling streamlined checkout using the “request for payment” functionality developed alongside RTP. We also connected this discussion to our QR codes and authentication discussions.

Closing thoughts

Although I longed to see colleagues in Vancouver, I found this meeting invigorating and productive (as I found our April 2020 meeting). There is a lot of experimentation happening right now, and I look forward to hearing the results in early 2021, and of course sharing them in this forum.
Thanks to the Web Payments Working Group participants for all they do!

A few days ago we launched a new Merchant Business Group focused on non-technical discussion and advocacy. The group held its first meeting in late October and I hope that soon we’ll connect some of their use cases and requirements to the Web Payments Working Group agenda. Contact Nick Telford-Reed or me if you have any questions.

Preparing to Advance Payment Request API 1.0 to Recommendation

Today we kicked off the process that, ideally, will result in the publication of Payment Request API 1.0 as a W3C Recommendation in Q1 2021.

The Web Payments Working Group and other W3C groups now have an opportunity to respond to a Call for Consensus to publish Payment Request API as a revised Candidate Recommendation. W3C Process requires us to return to “CR” because we removed a small number of features for which we don’t have interoperable implementations.

At the Working Group’s meeting 19-22 October we will discuss the plan to “get to Recommendation.” We will also discuss the evolution the API thereafter, grounded in our discussions with the payments industry.

Don’t hesitate to contact me if you have any questions!