Web Payments Working Group: Recent Episodes
None
More than 500 people from the W3C community came to Anaheim, California (23-27 September) for the 2024 Edition of TPAC, W3C’s big annual meeting. This is my personal summary of key topics and discussions that took place in different group meetings and breakouts; see in particular the Web Payments WG TPAC agenda, which includes links to minutes.
Secure Payment Confirmation (SPC)Secure Payment Confirmation (SPC) is designed to make strong authentication during checkout flows easier and more secure. During the week:
- We heard encouraging feedback on the usefulness of the technology from pilots, including a report from Visa and a report from Mastercard.
- MercadoLibre also presented the use case for SPC in PIX, Brazil’s fastest growing payment system. This is the second year in a row that we’ve heard strong demand for support for PIX.
- Through a presentation on regulatory trends, Fime made clear some of the strong authentication requirements common to several regions of the world. This presentation underlined the importance of “possession factors” to strong authentication solutions, including SPC.
- Passkeys have gained significant traction as the future of Web login, but synced passkeys “sacrifice” a strong possession factor in the name of usability because they can be shared between devices. That makes good sense for login use cases, but makes it harder to use passkeys on their own for payments use cases.
- For that reason we spent a good amount of time discussing a proposal to enhance SPC with what we started calling a “browser-based key.” At a high level, when a user authenticates through SPC, the API would return both a Web Authentication assertion with a signature over the transaction detail and a second signature using an additional private key local and specific to the device and secured by the browser. During Thursday’s meeting we walked through a draft list of requirements for this new feature and I anticipate that we will add those requirements to the discussion about the feature over the next week or so. The requirements should help use ensure the feature fulfills regulatory expectations in Europe and beyond.
- On Tuesday, the Web Payments Working Group met jointly with the Web Authentication Working Group to discuss the proposal. The Web Authentication Working Group had developed two proposals that would have added a possession factor back to passkeys: the devicePublicKey extension and subsequent supplementalPubKeys extension. However, the Web Authentication Working Group has dropped those proposals for the general passkeys-for-login use cases. For that reason, the Web Payments Working Group pitched the idea of adding a similar feature to SPC. We made the case that since SPC has a built-in “transaction confirmation” user experience, the browser has confidence the user is choosing to authenticate to make a payment. Therefore, the browser can more comfortably provide more information about the device after a successful authentication. We heard some support for adding such a possession factor to SPC and no objections.
- Finally, the Chrome Team also showed some UX mock-ups of the new user experience features of their implementation of SPC. The UX has been evolving based on pilot feedback and we heard at the meeting appreciation for these improvements.
My hope is that between now and the end of the year, the Working Group will (1) publish a set of requirements for a new “browser-based key” feature of SPC and (2) the Chrome team will implement the feature (and update the specification) to enable experimentation.
Digital CredentialsThe Digital Credentials API explainer usefully frames the current hot topic of digital credentials and wallets on the Web:
“Government-recognized documents play a big and constructive role in society (e.g., drivers licenses, passports, etc.). Increasingly, with the movement of government and financial services online, and regulation (e.g. eIDAS and various age verification regulations), these paper-based documents are gaining digital counterparts.”
What W3C technologies might play a role in a digital credentials ecosystem where digital credentials are issued, stored in wallets, presented during interactions on the Web and subsequently verified? The following list is just a starting point:
- Digital Credentials
- Credential Management
- Verifiable Credentials
- WebAuthn / Passkeys
- Payment Request / Payment Handlers
- Secure Payment Confirmation (SPC)
- FedCM
- Device Bound Session Credentials
During the Web Payments Working Group meeting we held a session on digital credentials and payments to socialize ideas for an architecture for digital credentials for e-commerce transactions. My main take-away (other than this is a hot topic) is that the payments community at W3C needs to become more involved in the broader digital credentials work. It also struck me during the conversation that some of the current momentum for non-payments use cases may lead to new approaches for credential exchange that look like the Payment Request and Payment Handler APIs. We will want to share our experience with those APIs in ongoing discussions and also track whether a broader digital credential exchange approach might gain more traction than the Payment Handler API has had to date.
There were many other sessions about digital credentials at TPAC in various group meetings. In addition, Tim Cappalli led a breakout discussion titled “Real World Identity and the Web… Continued”; I found the slides from that presentation quite interesting.
All the other topics!Our discussions covered many other topics during week, which I greatly appreciated and know we will continue to work on:
- Fraud trends (led by Entersekt)
- Regulatory trends (led by Fime and Worldline)
- Merchant perspectives (led by MAG)
- Improving address autofill (led by Shopify)
- Ideas for using Device Bound Session Credentials and CHIPS with EMV® 3-D Secure (led by Fime)
- Ideas for using Web Authentication and GNAP with EMV® Secure Remote Commerce (led by Fime)
- Web technology and experiences with PCI v4 (led by Shopfiy)
- Updates from the FIDO Alliance (trust signals, credential exchange)
- Joint discussions with the Anti-Fraud Community Group about the use of IP Addresses in fraud mitigation for payments
W3C @ 30I’ll close by mentioning the W3C @ 30 Gala where the community celebrated 30 years of W3C’s activities to build a Web for everyone. I encourage you to check out the W3C @ 30 video (which even mentions Web payments!). Speakers at the Gala shared moving stories about how the Web transformed their lives. Their stories (and TPAC generally) reminded me how important it is to pause our technical discussions from time to time and acknowledge our positive impact on so many people’s lives, at the scale of the planet. TPAC remains my favorite work week of the year.
Photo of the Web Payments Working Group Meeting
The Working Group met remotely 27-29 March (agenda and minutes). After a successful in-person meeting at TPAC 2022 we had wanted to meet in-person again, but fell back to remote due to scheduling challenges.
Co-Chair Nick Telford-Reed opened the meeting with an overview of the group:
Working Group Charter renewed in November 2022 for 2 years Secure Payment Confirmation (SPC) Specification status: we are nearly ready to go to Candidate Rec * Implementation status: shipping in Chrome and Edge; still working on other browsers * Integration status: referenced from both EMV® 3-D Secure and EMV® Secure Remote Commerce; looking at other payment systems * Pilot status: Adyen/Airbnb pilot ongoing; Stripe (second) pilot imminent; expect data at TPAC 2023 * Next use cases and features: see the issues list Payment Request and Payment Handlers* Payment Request advanced to Recommendation in September 2022 and is shipping in Chrome, Edge, and Safari. Feature requests are several years old; we did not spend time on these at this meeting but may do so soon. * Payment Handler is a Working Draft, shipping in Chrome and Edge; not actively working on it but the Chrome team makes changes periodically to align with other privacy-related changes. With that framing in mind, here’s how our agenda played out.
Working Group: Request to Restore some TextColleagues from Apple requested (262) the restoration of some text to the Working Group charter. While the Working Group of course wants to increase participation, we also discussed the disadvantages of rechartering, such as the time and effort required, and the risk of W3C Member objections to other parts of the charter (however unlikely). More discussion with Apple is needed to better understand the request and how to proceed.
SPC UX when no matching credentialsWe revisited issue 98 regarding the SPC user experience when there are no matching credentials. As a reminder, there is a “fallback UX” today in order to avoid leaking information about whether the user has any Web Authentication credentials on the current device. We looked at some proposed UX improvements. I took away that there is support for a user experience that offers a clearer distinction between “the user wishes to authenticate another way” and “the user wishes to cancel”, provided that the UX does not leak the fact that the user does not have matching credentials. We are now seeking entities who would like to experiment with an SPC deployment, and would be interested in testing different fallback experiences.
SPC Integration: EMV® 3-D SecureSPC is referenced from EMV® 3-D Secure 2.3, and there are ways to use SPC with earlier versions as well. With members of the EMVCo 3-D Secure Working Group we reviewed both (1) basic UX enhancements for the “single transaction” use case (the current implementation of SPC), and (2) enhancements to support other use cases.
In particular, we looked closely at a range of recurring payments and installments use cases to get a better understanding of what data it could be interesting to display in the transaction dialog (and have signed upon authentication). We acknowledged the complexities of recurring payments use cases, but also the value of both cryptographic evidence of consent, and consistent UX across payment systems. Furthermore, there is a sense that some regulators (e.g., in Europe) may be looking for stronger consumer protection in the area of recurring payments, and, if so, it would be great for SPC to be well-positioned as a relevant technology.
In general, the Web Payments Working Group is interested in both streamlining strong authentication (with SPC) and frictionless payments, where no user interaction is required. The following topics thus arose during our discussion of recurring payments:
- We don’t want to prevent frictionless recurring payments (e.g., very low-value, recognized payment)
- It would be great to reduce the need for strong customer authentication for subsequent payments. For example, could SPC be used to gather consent for an initial payment of $100 and also future payments of $10 monthly, and could the evidence of this consent lead to frictionless flows for the future payments? Another example: could the consent to pay $10 monthly for an initial subscription to a service, and agree at the same time to pay up to $15 for extra services so that they do not need to re-authenticate later?
As with the fallback UX, I think experimentation will play a key role in encouraging browser support for recurring payment and other use cases.
SPC Integration: Grant Negotiation and Authorization Protocol (GNAP)Although we frequently discuss SPC with card payment flows, SPC is not just for cards. On Tuesday we discussed other integrations, both GNAP and PIX.
We first learned about GNAP and SPC at our 2 February meeting when Adrian Hope-Bailie (Fynbos) presented a demo showing GNAP as the protocol used to carry out a payment from a digital wallet, with SPC as the authentication UX. We continued the discussion at this week’s meeting, with an introduction to GNAP by one of the authors (Justin Richer) and more detail from Adrian Hope-Bailie about a related IETF draft: “GNAP Secure Payment Confirmation Extension.” Given our previous discussion about recurring payments, we had discussion about whether and how to use access tokens to represent consent for future payments. And since we had been discussing frictionless payments, we discussed how, with GNAP, an Access Server (AS) could return a token based on context and other information, without requiring additional user interaction. It was pointed out out that there are overlaps in functionality between GNAP, EMV® 3-D Secure, and EMV® Secure Remote Commerce, and so I anticipate we’ll continue to have discussions about protocol interoperability.
SPC Integration: PIXAlthough the WPWG had discussed the Brazilian Boleto system previously, I think this is the first time we discussed PIX, the Brazilian instant payments system. Through a very informative (and witty) presentation, we learned about rapid rise of PIX (driven in part by concerns about inflation) and the evolution of fraud mitigation approaches grounded in the relationships managed through the Central Bank of Brazil: trusted actors and a surrounding ring of indirect partners. Our colleagues from Netflix and Itaú pointed out that the user experience and security mechanisms currently available on the Web are lacking, and thus they are interested in how SPC might help. We learned about the current PIX UX where users copy codes from a merchant page and paste into a bank app and discussed whether we could improve on that (e.g., via specific URL schemes). I anticipate we will continue to discuss PIX and SPC and I hope see some experimentation as well.
SPC Integration: EMV® Secure Remote CommerceEMV® Secure Remote Commerce (SRC) version 1.3 integrates SPC as one of the authentication method types known to the protocol. During the meeting this week we considered two related concepts from the SRC protocol: user recognition and cardholder authentication. For the first, we discussed how FedCM (designed primarily for federated login use cases in a world without 3p cookies) might prove useful in SRC flows (see the presentation from the EMVCo SRC Working Group). We also discussed different ways that FedCM and SPC might be used together, including with and without a “common entity” that could help coordinate data exchange across different SRC systems.
Low Friction AuthenticationWe wrapped up the meeting with more discussion about “frictionless” and “low-friction” payment experiences. Industry stakeholders have made clear that friction can lead to cart abandonment, and the Web should support flows with minimal friction, for example, in regulatory contexts where multi-factor authentication is not required. It is not clear to me what role, if any, SPC will play in “frictionless” flows because it involves a user experience, but even if it does not, I expect the Working Group will continue to brainstorm about how to use emerging technology to minimize checkout friction.
After a three-year hiatus, W3C held TPAC 2022 in person in Vancouver. It was really great to be back in person, and I heard that sentiment from just about everyone. More than 360 people registered to attend TPAC in person … Continue reading →
TPAC 2022 will be a hybrid event: in-person in Vancouver, with remote participation. I believe more than 600 people have registered, and it looks like more than 350 people will attend in person. This will be my first in-person meeting … Continue reading →
In early May the Web Payments Working Group held an energetic remote meeting; see the agenda and minutes. While we were meeting, the FIDO Alliance released a press release with headline Apple, Google and Microsoft Commit to Expanded Support for … Continue reading →
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, … Continue reading →
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 … Continue reading →
Today W3C published Proposed Recommendations for Payment Request API and Payment Method Identifiers. Congratulations to the Working Group! I want to extend heartfelt thanks to all the editors over the years whose contributions have brought us to this point.
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, … Continue reading →
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 … Continue reading →
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 … Continue reading →
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 … Continue reading →
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 … Continue reading →
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; … Continue reading →
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 … Continue reading →