As you know W3C is a standards body that helps standardize web technologies and I would describe our mission overall as creating a competitive platform for application distribution.
So we'd like the web to be as full-featured, secure and powerful as native platforms and so we have a lot of work going on and a lot of different Working Groups to develop new APIs for the web.
My specific focus is on streamlining checkout experiences and before we get started, I just wanted to say that some of the information in the presentation and the overall direction of the standardization work really, draws on data from U.S and European markets and not as much on Asian markets.
That may change as our work on mini apps progresses and we would love to hear from the W3C membership and other community members about use cases where you think new web technologies would help increase security and usability.
So, to get started, it's well socialized at this point that people spend an increasing amount of time in native applications as this chart shows - it depends a little bit on which site people are visiting whether they spend more time in the native app version of a site or the web app version.
But even if people are spending more time in native apps, in many cases, there are more visitors to mobile websites than to apps themselves.
And people have described the difficulty of getting visibility in app stores and so we would like to make it easier and more secure for those users who are browsing the mobile web to complete their transactions.
In fact, most revenue still comes from desktop - again, this is very Western, U.S- and Europe-oriented, but there's still a place to improve the web not just for mobile but for desktop.
So a big driver behind our work is helping to ensure that people can create modern and secure checkout experiences, and help make the web platform more appealing to developers.
When we look at information about specific priorities that consumers have, there's a whole list, many of which probably can't be improved through web standards, but a few of these can, including notably making checkout processes fast and convenient, improving the overall speed and responsiveness of website, and improving the mobile experience.
And so obviously the payments work that we're doing is not sufficient on its own for some of these - it requires other enhancements to the platform, which is why we have work going on to support Progressive Web Apps, and access to devices, device capabilities, and access to the GPU and so forth.
But we think together, these APIs can help fulfill some of these user expectations.
So the work that we're doing in payments, I would characterize principally these days to streamline checkout - there are many forms of payments, business-to-business and so forth, but our focus is really on the web in an e-Commerce experiences, increasing usability, improving security and reducing fraud, and also enhancing user privacy.
So I should just point out a little bit the scope of these conversations: as I said the focus is e-commerce from websites and web apps, mobile and desktop, but it it's within the scope of our work to allow people to complete transactions not just with web apps but also with native apps.
So as we'll see in a bit, merchants call the APIs from the web-based checkout experience but users may be able to respond with their native apps.
We have pretty good participation in the Working Group - of course we always are looking for more representation for more parts of the world, different pieces of the market.
But right now, we have pretty good representation from payment service providers, card networks, browser vendors, some merchants and technology providers around payments.
When we started this work in 2015, we thought about the work initially as enhancing autofill.
“autofill” requires merchants or their service providers to provide forms, and we thought we could simplify the user experience and reduce the burden on merchants by reusing data that had been previously stored in the browser.
So we characterized this as “one click pay”: the merchant would call our APIs, and with one click, the user would return previously stored data to complete a payment.
We thought that was how we were going to streamline checkout, and there has been some adoption but it hasn't overwhelmed the web.
Another priority was to reduce the total number of buttons on a checkout page, and so we built into the Payment Request API capabilities in the browser to do matchmaking between the payment methods that are accepted by the merchant and those that the user can use to pay.
So the browser, when it displays the Payment Request user experience, can show the intersection and reduce some of the complexity, and do so in a way that's harmonized across websites and we think that improved usability will make it easier for users to complete transactions when they shop on different sites.
And lastly, we thought we could improve browser capabilities in a way that would support innovation in the payment space.
So it can be very challenging to bring secure user experiences and effective user experiences to the web, and so offloading some of that to the browser - we imagined - would make it easier for people to bring new payment methods into the web.
All of these priorities were informed by discussions with people from a variety of payment systems, including credit cards and and debit cards, as well as digital wallets like all the *pay wallets - Google Pay, Apple Pay, Samsung Pay, Alipay and so forth -, ACH in the United States, Open Banking in Europe, and some new payments work around streaming micropayments from Coil which we are calling web monetization.
So our goal, as I said, is not to support any single payment method specifically but to provide generally useful APIs for a broad set of payment flows.
And this is how we imagine the flows generically: the merchant or their payment service provider provides a checkout experience on which there's a button or more than one button, the user clicks the button and, as I said, the browser does the job of matchmaking the payment methods declared by the merchant and those that can be used by the user through different payment apps; the user picks a payment app, interacts with it - which may involve authentication - choosing an instrument like an account number or card number; and then when the user is done, the data is returned back to the merchant.
Sometimes that data is used to complete payment, and sometimes that data might be a receipt or a status message that payment has taken place, for example in the case of a credit transfer or a real-time payment.
But again this flow is our generic flow and the APIs that we've designed sort of support this generic flow.
So we have the principal API, the Payment Request API, where the merchant requests data, and users can respond to that by paying either with native apps, as I said, or web-based apps or in some cases - probably rarer cases - built-in capabilities directly in the browser.
So W3C is focused on the web and therefore we are creating a standard for bringing web-based payment apps to the web, called the Payment Handler API. One thing to note in this image from a demo is the modal window - that you see on top of the checkout experience - is provided by what's called a Payment Handler, and the modal window keeps the user near the merchant site.
And lots of merchants and payment service providers have let us know that that's a superior user experience than redirecting the user to another website and losing the context.
Sometimes the users don't come back from such redirects and so this is a very appealing characteristic and improved usability through the Payment Handler api.
So here is what the architectural view of all of this looks like: we have the merchant requesting to be paid through Payment Request API, the user has one or more payment apps that they can respond with, and how those payment apps communicate with the browser depends on how they're built - so web-based payment apps communicate through the Payment Handler API - and then those apps in turn talk to servers for authenticating the user, providing access to accounts and getting tokens or other data to return to the merchant.
So that's the heart of the standards work that we've been doing.
Now, several years later, Payment Request API is shipping in most major current browsers - there is a Firefox implementation, but because you can't respond to it with any payment apps in Firefox, it's been deactivated but we're hoping it will be reactivated again soon to support some of the newer work that we're doing.
And in addition to browser support, a number of payment service provider libraries - like libraries from Stripe and Braintree - make use of Payment Request API when they can, when it's supported in browsers and when there's available payment apps, so we're also seeing some deployment in the market through these libraries.
Payment Handler API is less mature but it is supported in Chromium-based browsers, and many many companies have been experimenting with Payment Handlers which helps us continue to develop API features.
I should note that both of these APIs are broadly available in China, partly because of the market share of Android on mobile and Windows on desktop, so if you're interested in experimenting, you should be able to reach lots of customers through these APIs.
I mentioned a moment ago that our priorities have changed as we've gained experience in the past few years.
We are planning to finalize version 1 of the Payment Request API which is deployed and used by number of merchants.
Our expectation is that will be finalized as a W3C Recommendation in mid-March of 2021.
I also mentioned a moment ago that the modal window available to Payment Handlers is quite appreciated, and a number of companies have asked if that could be made available outside of Payment Handlers from just Javascript, perhaps still in a Payment Request context, from merchant side code.
So that is a topic that the Working Group will continue to pursue.
But I think the biggest new piece of work, and the one that's generating the most interest, has to do with strong customer authentication, largely motivated by regulatory requirements in Europe for Strong Customer Authentication - or SCA.
Many many companies are interested in improving the user experience of Strong Customer Authentication.
And at the same time we have seen significant deployment now of the Web Authentication standard, which is part of the FIDO2 set of specifications.
Web Authentication is supported in all current browsers, mobile and desktop, and now many many devices - whether they're Android devices or Apple devices or Windows laptops - have built-in authenticators.
And so users have now in their possession ways to respond to Web Authentication prompts to register their authenticators and then to authenticate for example during transactions using those same authenticators.
In addition to the Strong Customer Authentication requirement of PSD2, a piece of that regulation also wishes to improve security by having proof that a user was presented with a certain payment request - an amount and a currency to a specific beneficiary from a particular account, and they call this “dynamic linking” - or we've also heard it called “transaction confirmation”.
And so the work that we're doing takes that into account and seeks to fulfill those requirements as well where there's a cryptographic proof that a user was presented with some information relevant to a transaction.
There is one other topic I'll mention a little bit more later: the payments industry is interested in not just low-friction and Strong Customer Authentication, but also frictionless risk assessment: that's a piece of the EMV 3D Secure protocol today, and we'll talk about that more in a bit and what's changing based on the evolution of browsers.
So I mentioned Secure Payment Confirmation is what we call this new piece of work, or SPC.
I have linked to the proposal from Stripe, Google and Coil from the slide deck, but SPC essentially marries the Payment Request API with the Web Authentication API. And by coupling them it's possible to remove the total number of user gestures to complete an authentication, and by reducing the same origin requirement of Web Authentication, it's possible to allow different parties like payment service providers to authenticate the user without including code in a page, which can help lighten the page and also increase security.
So there are a number of benefits like the addition of biometric authentication during payments, increasing user confidence through a consistent user experience, improving privacy, satisfying these regulatory requirements and so on.
I'll very quickly walk through mockups that have helped and helped inform the current Chrome implementation of SPC which is experimental.
There is first an enrollment phase as there is with authentication generally.
So what you see in the upper left-hand corner is a standard credit card checkout where the user has entered the card the payment service provider - in this case Stripe -, then opens a Payment Handler - that's the modal window -, and starts to execute a 3D Secure authentication.
So generally, 3D Secure enrollment involves a one-time password, - sorry 3D Secure authentication involves a one-time password, so here the user's device receives the one-time password which they enter into the form, and what's new with SPC then is, in the bottom left, Stripe is offering the possibility of enrolling an authenticator to speed up future transactions.
So if the user chooses to enroll the authenticator, then the next image you see in the center bottom is the platform asking the user to touch their TouchID in this case - the experiments being done on a Mac, but of course all of this would be independent of any particular device or operating system once standardized.
And if the user completes that authentication, their authenticator is enrolled with the bank and they're ready for future checkouts.
So the SPC checkout experience looks very similar: the user is on another site, enters a card number and this time the payment service provider reaches out to the back end, gets the previously enrolled authenticator information in communication with the the bank or the 3DS server, and then asks the user if they wish to authenticate to pay.
This is where the “dynamic linking” or “transaction confirmation” information is displayed to the user, and if the user says “yes” then they're prompted using the platform authentication system and if successful, the order is completed.
So that's what SPC will look like: this particular pilot program is being run by Stripe, its focus is on credit card payments and 3D Secure, but Secure Payment Confirmation will not be limited to a specific payment method or authentication protocol, it will be more generically available and will leverage Web Authentication in a variety of systems.
We're expecting to hear back results from stripe in early next year, early January or February, and if all goes well, the Web Payments Working Group will probably spend a good part of 2021 developing standard for SPC.
I mentioned frictionless or “zero-friction” risk assessment is still important to the payments industry, even if we have low friction authentication.
But a number of of systems are likely to break given how this low-friction or zero-friction risk assessment takes place today, namely by fingerprinting the user's browser.
So as browsers make it increasingly hard to use third-party cookies and they impose restrictions on storage, many of the current techniques are going to break.
And so we have created a number of groups in W3C for this type of conversation, and the zero-friction conversation will continue within W3C and its partners.
We have standardization Working Groups, Payments and Authentication, that work closely to make sure for example future versions of Web Authentication support payments use cases; we've created this Web Payment Security Interest Group for EMVCo, FIDO and W3C to work together; we have a new Merchant Business Group to hear requirements from the merchant community and to make sure they are aware of emerging web technologies.
And the Web Payment Security Interest Group - I'll say a word about them - we launched that group in early 2019; and right away a number of industry stakeholders asked us to clarify the relationship between a variety of technologies that we were developing and to make sure that they work well together.
So there had been confusion about the role of FIDO authentication or Web Authentication, and how did that relate to 3D Secure authentication; and there was confusion about Payment Request - which is about streamlining checkout - and EMVCo Secure Remote Commerce - also about streamlining checkout.
So we published in September of this year a document called “how technologies relate”.
That document describes each technology briefly and then explains the different ways that they can be used together, or some of the ways that they can be used together.
And we continue to meet and discuss emerging specifications of these three different standards bodies, with a goal of ensuring interoperability among the different technologies.
So that's an ongoing collaboration that involves lots and lots of players now from the three different organizations.
The Merchant Business Group on the other hand is brand new, does not have a well-established community yet and, as I mentioned, it will focus on merchant use cases and requirements gathering as input to other Working Groups, as well as education of merchants about emerging web technologies.
Thank you very much, I appreciate your time and I hope if you have any questions you won't hesitate to contact me.
Thank you!