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!