Web Payments Meeting (March 2023 Edition)

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 Text

Colleagues 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 credentials

We 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 Secure

SPC 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: PIX

Although 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 Commerce

EMV® 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 Authentication

We 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.

Posted in Events | Comments Off on Web Payments Meeting (March 2023 Edition)

TPAC Recap (2022 Edition)

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 and another 250 joined remotely.

Below I summarize discussions of the meetings I attended: the Web Payments Working Group, the Web Payment Security Interest Group, and joint meetings with the Web Authentication Working Group and the Antifraud Community Group.

Web Payments Working Group

The Web Payments Working Group agenda opened with a focus on Secure Payment Confirmation (12 September minutes):

  • Adyen and Airbnb shared some information about their SPC pilot. The discussion led us to topics such as the importance of user education (for the new user experience), some ideas for the timing of user registration (post-transaction), and the potential value of sharing a FIDO attestation when using SPC in a delegated authentication flow.
  • Google presented their current work to bring SPC to Chrome on Android. That led to discussion about (and strong interest in) SPC availability beyond browsers in native Android apps.
  • FIS shared thoughts on three topics of interest: shops making the transition from brick and mortar to digital-first, online stores looking to create a seamless shopping experience, and merchants that prefer strong control over the user experience. Across these topics there were three main themes:
    • Merchants want to know who their customers are prior to authorization. On this point we discussed the impact of tokenization and potential benefits of ensuring that the Payment Account Reference (PAR) can be communicated during an EMV® 3-D Secure transaction that involves SPC.
    • Data is not always available based on payment types or implementations.
    • Cart abandonment is a problem due to extra friction and payment problems.
  • Microsoft shared some perspectives as a merchant that adopted strong customer authentication in Europe. They emphasized the important of frictionless authentication and indicated (as FIS also indicated) that stronger authentication can lead to cart abandonment; see the Microsoft slides for details. Key takeaways were thus that a great SCA user experience is very important (hence our emphasis on SPC) but that frictionless risk assessment is still very important. Microsoft reiterated during the talk that merchants do not like to hand over the authentication experience to banks, which, to me, reinforced the value proposition of SPC where merchant controls the authentication ceremony, and the bank can still validate the results.
  • We then revisited some EMVCo observations about SPC and some changes that the EMVCo 3-D Secure Working Group has requested, including support for non-payments use cases, recurring payments, and more alignment with user experience requirements defined in the EMV® 3-D Secure specification.

We opened the second day of the WPWG meeting (13 September minutes) with discussion about the Payment Request API, which advanced to Recommendation just before the start of TPAC. Both Apple and Google expressed interest in restoring some capabilities related to address collection that are implemented in their respective browsers, but that were removed from version 1 of the specification for privacy-related reasons. I expect the features will be re-introduced so that interoperable implementations are documented, even if not recommended in their current form. The Working Group is likely to try to evolve the feature to address the previously registered privacy concerns.

After that:

  • Apple then described some changes to ApplePay.js over the past couple of years that could be integrated into Payment Request. This was useful for helping the group develop a potential roadmap for new work on the API.
  • We then discussed some upcoming changes to browsers related to “Bounce Tracking Mitigations.” Bounce tracking refers to very quick redirects from one site to another and back, usually without the user knowing that the redirect has happened. As with previous discussions about privacy-related changes to browsers (e.g., IP address masking, user agent string masking, removal of third party cookies) we discussed the likely impact on user recognition and fraud prevention.
  • In the same vein, we then heard about changes that the Chrome team plans to make to their Payment Handler implementation based on other changes on the Web related to privacy. The theme of data collection and risk mitigation continued into the Thursday joint meeting (below).

Tuesday Joint Meeting

On Tuesday afternoon, four groups met: the Web Payments WG, the Web Payment Security IG, the Web Authentication WG, and the Antifraud CG (13 September joint meeting minutes):

  • The Antifraud CG, launched in early 2022, has developed as set of use cases; these include both payments and advertising use cases. Proposals to address these use cases are emerging, and we heard about several of them during the joint meeting, in particular about device integrity attestations. We also discussed trust tokens, currently in development in the Web Incubator CG.
  • The Web Authentication Working Group summarized the state of specification and deployment of passkeys (cross-device FIDO credentials) and device public keys. I have the impression that device public keys —not yet implemented— could play an important role in payments use cases so that a Relying Party make make risk decisions based on previously seen devices. Those decisions may also rely on attestation availability, and it was pointed out that attestations are optional with Device Public Keys and may not always be available. We then discussed technology developments around a user experience question that we’ve heard before: if, for privacy reasons, a party cannot query the browser to determine whether the user has already enrolled credentials, how does that party know when to offer the user a registration experience?
  • In the final session of the joint meeting, we discussed the status of SPC and broached several topics of ongoing coordination with the Web Authentication WG. We heard that our proposed “cross-origin bit” is now part of FIDO CTAP (and will be made public soon). The Web Payments Working Group next needs to register the extension with IANA. The WPWG re-raised the topic of cross-origin credential creation, which is permitted in SPC but not in Web Authentication. While there is some support within the Web Authentication WG to reconsider this capability in Web Authentication Level 3, there is not yet consensus.

Antifraud discussion, in particular about Device Public Keys used for fraud prevention, continued during a Wednesday breakout on Antifraud.

Thursday Joint Meeting

On Thursday, both the Web Payment Security Interest Group and the Antifraud Community Group held individual meetings as well as a 90-minute joint session on patterns of payment fraud (15 September WPSIG/Antifraud minutes):

  • Entersekt presented some payment fraud patterns (e.g., account takeover through phishing, SIM swap, or social engineering; chargeback fraud, and card skimming attacks). We discussed current mitigation techniques (e.g., IP address monitoring) with attention to how those might be affected by privacy-related changes to browsers. As it was put in the meeting, “Browser fingerprinting is not good enough anymore.” Our colleagues from Entersekt evaluated some of the Antifraud CG Proposals in development to see which might help with payments fraud use cases. I anticipate we will soon discuss a proposed new risk signal based on the joint discussion.
  • Our colleague from the University of Illinois Chicago presented findings from research Phish in Sheep’s Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting. One interpretation of the research is that it illustrates the limits of current approaches data collection used for payment fraud mitigation.

We made good progress at TPAC in understanding use cases, formulating the value proposition of SPC, and emphasizing the need for more fraud prevention tools (with some useful whiteboarding in the mix). I anticipate the groups will want to meet again in person well before TPAC 2023.

Posted in Events | Comments Off on TPAC Recap (2022 Edition)

Preparing for TPAC 2022

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 in about 3 years.

I have been working with multiple groups on a coordinated agenda about payments, authentication, and fraud prevention:

I’m looking forward to discussion about Secure Payment Confirmation (SPC). We expect to hear about a pilot from Airbnb/Adyen, emerging support for SPC on Android, and other industry perspectives about the current version as well as next use cases.

I’ll summarize the meetings in a few weeks!

Posted in Events | Comments Off on Preparing for TPAC 2022

Web Payments Meeting (May 2022 Edition)

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 FIDO Standard to Accelerate Availability of Passwordless Sign-Ins. This type of strong industry support for Web Authentication/FIDO is very exciting because Secure Payment Confirmation (SPC) builds on those technologies and benefits from the momentum.

In preparation for advancing SPC to Candidate Recommendation we have been working through our issues list and stabilizing the version 1 feature set. We closed 7 issues in the past month including through joint discussion with the Privacy Interest Group and the Web Authentication Working Group. We have also labeled some issues as “after version 1.” See below for details about how we plan to manage the remaining 10 issues.

At the meeting we heard a bit about recent changes to the Chrome implementation of SPC and upcoming plans. Modirum colleagues provided a demonstration of their EMV® 3-D Secure implementation (version 2.3) that integrates SPC. Airbnb and Adyen shared a brief update on their SPC pilot. We will continue to look for support in more browser engines and refine the specification based on feedback from pilots.

We also discussed Web Authentication more broadly. Best Buy has deployed Web Authentication for login and shared some of their experiences with the group. We also heard about some PSD2 use cases from (French bank) BPCE. In addition to SCA and dynamic linking for payments —the use case for SPC— they have similar requirements for authentication and signatures over transactions involving sensitive data. General browser support for signing transaction data with authenticators has been discussed previously in the Web Authentication Working Group; our recent joint discussion with them may re-energize the topic.

Remaining Issues

Here is a quick summary of our remaining 10 issues and how we plan to address them on the road to Candidate Recommendation.

Web Authentication Topics

The bulk of our remaining issues relate to the SPC dependency on FIDO. In some cases, we think the proper long-term solution will involve enhancements to WebAuthn and/or CTAP:

  • Issue 12: support for roaming authenticators. This issue involves both UX challenges and the need for support in CTAP for silently querying roaming authenticators for available credentials.
  • Issue 124: determining when to enroll the user (in a way that protects user privacy)
  • Issue 157: support for a “cross-origin” bit and CTAP; issue 154 relates to this and is about user consent to allow cross-origin reuse of a credential>.
  • Issue 175: impact of multi-device credentials on SPC.
  • Issue 187: improving understanding of who is authenticating for whom

I expect the Working Group will try to (1) balance the desire to advance SPC to Candidate Recommendation in a timely fashion with (2) remaining in sync with FIDO advances. It may be that SPC implementations support short-term solutions to some of these issues (e.g., involving caching information) and then evolve as underlying specifications support new capabilities.

Privacy Topics

Stripe asked in issue 172 how to enable a user to opt-out of stored payment credentials for compliance with regulation such as GDPR. In scenarios where the user authenticates in a first-party context, it is straightforward to offer an opt-out feature. With SPC, authentication may happen in a third-party context where it is less obvious how best to offer an opt-out solution. We have been discussing when it would be most appropriate to provide the user with information about how to opt-out:

  • At registration time.
  • At transaction time, before authentication starts
  • At transaction time, during authentication. Overall I’ve not heard much support for opt-out during authentication.
  • At other times.

These discussions are ongoing; Stripe plans to conduct a deeper analysis of their requirements.

I raised issue 77 with the hope that we would find a technology solution to preserve privacy as SPC credentials are shared across origins. We have not found a practical technology solution. Our current plan (see pull request) is to provide guidance to relying parties and others on how to manage identifiers.

Internationalization

Our issue 93 on the localization of displayed strings is shared with other groups (including Web Authentication) whose specifications involve data outside of markup. I believe the Internationalization Working Group will seek support at the JavaScript level in the long run. In the short run, I would like to see W3C publish a standalone specification that describes how to support localizable strings, and that can be “imported” into SPC and other specifications.

UX Topics

In order to better align with EMV® 3-D Secure requirements we’ve received a request that the Chrome implementation of SPC display larger icons (issue 184). EMVCo colleagues have also suggested additional UX enhancements such as the display of additional icons.

I look forward to our next extended meeting —TPAC 2022 in Vancouver— by which time I hope that we will have reached Candidate Recommendation (or come very close).

Posted in Events | Comments Off on Web Payments Meeting (May 2022 Edition)

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!

Posted in Events | Comments Off on TPAC Recap (2021 Edition)

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.

Posted in Uncategorized | Comments Off on SPC Design Choices for Flexibility and Scale

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.

Posted in Events | Comments Off on Remote Meeting Agenda in Development

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.

Posted in Uncategorized | Comments Off on SPC is a First Public WD

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.

Posted in Events | Comments Off on Updates on Payment Request V1 and SPC