W3C pushes browser pay security for banks and card networks
The World Wide Web Consortium (W3C) is sending a message to the payments industry that it might not be wise to wait on the card networks to solve the growing problem of mobile and online payments fraud.
W3C, a consortium that counts several banks and card networks among its members, is wrapping up about three years of work to build its Payment Request API, which uses browser-based payments to strengthen security for making and accepting e-commerce transactions. W3C joins the Faster Identity Online Alliance (FIDO) and EMVCo's Secure Remote Commerce framework in advancing payments security on the web.
"In some ways, there is an analogy with W3C and FIDO because they are trying to solve the same problem — that the card payment programs have not secured mobile or e-commerce effectively," said Steve Mott, principal of BetterBuyDesign, a Stamford, Conn.-based consulting firm.
Two years ago, W3C and its director Tim Berners-Lee were pushing hard to replace passwords with cryptographic operations, viewing it as essential to rid consumers of an authentication method that was too easily forgotten or considered weak by security standards.
And a year ago, FIDO and W3C worked together to create Web Authentication, a new standard that allowed FIDO authentication methods to operate through browsers. With that protocol, browsers are able to accept biometric authentication from a user's device when the user is shopping or making payments while visiting websites.
FIDO also has been in discussions with EMVCo for the past two years to determine how its developing authentication methods could support EMV payments.
In the meantime, W3C focuses on the browser as a way to move payments when a Payment Handler API and Payment Request API work together to pass payments requests received from websites to a digital wallet for processing. Its goal is for every consumer or business, no matter what device or browser they are using, to move through a checkout process quickly without numerous authentication steps and card data input. The "digital wallet" destination could be an app or a bank account.
"I think it is safe to say that the W3C Payments Working Group is developing the capability to enable payments in the browser, which could simplify the payment process for both merchants and their customers," said Thad Peterson, senior analyst with Aite Group.
Even though browser payments are not in place yet, Peterson acknowledges the payments industry will stand up and notice soon. "It would appear to have the potential to change the digital payments landscape," he said.
As such, W3C has long contended that the browser-based payment APIs would not be limited to card payments and would work with any type of unique or domestic payment method, including cryptocurrency and loyalty rewards networks.
In its first iterations, the Payment Request API would be implemented in Chrome, Edge, Firefox, Facebook, Webkit and Samsung Internet Browser.
But W3C has been putting the idea of browser-based payment security in front of banks and card networks for many years, Mott said. And the payments security community has essentially frowned on those ideas, he added.
"Those in security fear that if someone is able to compromise the browser, they would be able to compromise all of the payments streams using that browser," Mott said. "They would prefer that the browser continue to operate independently, and that the security protocols would be separate sessions with an online or mobile transaction."
To offset those fears, W3C has been working on authentication protocols and specifications that would utilize off-browser security and support off-browser payment screens, Mott added. "Their view is that the big nuance, to get global acceptance of widespread improvements in online and mobile security, would take place with a browser-based solution as the fastest way to achieve that."
But it's a complex method when handling payments identified by a URL or a payment button.
In the past few weeks, Google has added support for the Payment Handler API on the Chrome browser. In the W3C payment request ecosystem, users pay through the "payment handlers" — web pages, native digital wallets, or even the browser if payment card information is stored there. A browser-opened window, or "sheet," displays relevant payment handlers based on payment methods accepted by the merchant.
The browser "knows" what payment handler the user is deploying through the user's manual installation of a payment choice or through a button on a web site to register a web-based payment handler.
Some of the processes are adjusted and some steps skipped, if the user is purchasing digital goods and the merchant has no need to check a shipping address or obtain contact information.
At the same time W3C is advancing browser-based payments, and FIDO is pushing biometric authentications to eliminate static passwords, the card networks are also advancing security methods through brand-operated standards body EMVCo and its 3-D Secure 2.0 upgrade.
The upgrade promises faster transactions and more relevant data moving to issuers to make better authentication decisions, but 3-D Secure 1.0 left a sour taste in the mouths of many e-commerce merchants because of its long authentication process, and there is no guarantee the new version will have widespread support.
About four months ago, EMVCo's Secure Remote Commerce framework also was behind Mastercard and Visa's efforts to establish a single payment button on websites for e-commerce. The pay button represents the SRC standard's goal to push similar processes and security measures for card-not-present payments.
Because the three security bodies are working on the same problem, the payments ecosystem is "in a bit of a mess" in trying to determine what works best to improve e-commerce and what has the best chance of widespread use and acceptance, Mott said.
"There is no synthesizing mechanism," he added. "FIDO has put a lot of thought into what will work in terms of stepped-up authentication, and the W3C's browser option is the path of least resistance for most consumers, and it also offers additional authentication."
But the SRC framework from EMVCo puts all of the payments "in a funnel for EMVCo to make all of the decisions on a network-centric basis," Mott added. "That didn't work with other initiatives and would be more of the same of minimizing the hassle and expense for the issuers at the expense of the rest of the payments ecosystem."