Web Payments Working Group

30 Mar 2020



Clinton Allen (American Express / EMVCo), Giulio Andreoli (Apple), Dirk Balfanz (Google), Andrey Bannikov (Facebook), David Benoit, Tomasz Blachowicz (Mastercard), Sofiane Boumedine (Canton), John Bradley (Yubico), Erhard Brand (Entersekt), Donovan Changfoot, Jalpesh Chitalia (Visa), Chris Dee (FIS Global), Matt de Haast (Coil), Una Dillon (Merchant Risk Council), John Fontana (Yubico), Dave Fortney (TCH), Jean-Michel Girard (Worldline), Jonathan Grossar (Mastercard), Liquan (Max) Gu (Google), Puneet Gupta (Squarespace), Lauren Helt (American Express), Frank Hoffmann (Klarna), Mathieu Hofman (Stripe), Adrian Hope-Bailie (Coil), Ian Jacobs (W3C), Manoj Kannembath (Visa), Joshua Karoly (Netflix), Mahesh Kulkarni (Samsung), Vincent Kuntz (ISO 20022 / SWIFT), Marek Kurylko (Mastercard), Duy-Tung Luu (Canton), Florent Lambert (Lyra Network), Mercia le Roux (Entersekt), Bryan Luo (Amazon), Olivier Maas (Worldline), Ajay Maddukuri (American Express), Takashi Minamii (JCB), Fawad Nisar (Discover), Cairin Michie (Coil), Gerhard Oosthuizen (Entersekt), Kacie Paine (MAG), Jay Patel (American Express), Brian Piel (Mastercard), Anne Pouillard (Worldline), Jean-Yves Rossi (Canton), Sophie Rainford (American Express), Hervé Robache (STET), Peter Saint-Andre (Mozilla), Sahel Sharify (Google), Rouslan Solomakhin (Google), Sameer Tare (Mastercard), Nick Telford-Reed, Benjamin Tidor (Stripe), Justin Toupin (Google), Laura Townsend (MAG), Arno van der Merwe (Entersekt), Jonathan Vokes (FIS Global), Luke Walker (Yubico), Danyao Wang (Google), Clément Warnier de Wailly (Canton), Wanli Yang (Airbnb)
Marcos Caceres (Mozilla), Michel Weksler (Airbnb), Yun Cho (Airbnb)
Nick Telford-Reed
Ian Jacobs


  1. Welcome (attendance, video, timekeeping, antitrust guidance)
  2. Payment handler privacy assessment and proposals
  3. Combining gestures to launch WebAuthn and payment handlers
  4. Wrap-up for today

Welcome (attendance, video, timekeeping, antitrust guidance)

Payment handler privacy assessment and proposals

See the 30 March agenda for links to materials.

[Presentation from Justin Toupin and Danyao Wang]

Justin: Thanks for joining today's meeting in light of challenging times. We are looking forward to your questions

[Danyao Wang on the threat analysis behind many of these proposals.]

Danyao: I work on Chrome at Google
... one of the superpowers of payment handlers is the ability to share information cross-origins
... so we did a pro-active threat assessment for privacy (and also partly security; more to come on that front)
... we wanted to do this analysis before payment handler usage scales

Danyao: We've identified four main groups of threats:

(1) Cross-origin tracking without user interaction

(2) Cross-origin tracking without sufficiently clear user intent to interact

(3) Phishing

(4) Fingerprinting

[The slides summarize these groups.]

Danyao: When show() triggers a payment handler the payment handler might choose to not show any user interface, which is one of the issues.
... a user may not realize that a payment handler was activated.
... Note that one of the phishing concerns is no different than pop-ups today, but we wanted to include it for completeness
... Our assessment today is that the fingerprinting risk associated with payment handlers is low today for two reasons (1) browser throttling of calls to hasEnrolledInstrument and (2) small number of payment handlers, but the latter could change over time as number grows

Gerhard: This is really useful. There are two times a payment handler can be installed: manual and just-in-time (JIT).
... does the threat assessment differ depending on which installation path was used?

Danyao: Short answer: today, no. Today the threat is not significantly different because installation is silent. So it's easy for any party to install a PH as the user "drives by" a site. No click is required; just visiting a 1p web site suffices today
... one of the proposals is to make the installation ceremony more intentional, and we think that will help

Justin: Based on these groups of threats, our proposed mitigations fell into two main categories:

(1) those that are straightforward and self-contained.

(2) those with more complicated implications

Justin: We hope for the former to achieve consensus quickly on what we believe are robuts proposals. For the second we are really seeking more input

[Three Straightforward mitigations]

(1) require user gestures

(2) Strong ux of cross-origin switch

(3) Open payment handler in 3p context by default, but with user consent can have 1p access

Justin: for "require user gestures":

* require user gesture to trigger show(). (Note that this is already required by PR API.)

* require user gesture in a payment handler window before show() promise is allowed to resolve

Justin: How does requiring user gesture to trigger show() affect implementations that make use of cross-origin iframes where the user gesture is not propagated along postMessage()?

Danyao: We are looking for any merchants or payment handler providers to let us know
... we heard from Google Pay, for example, that in the case of Stripe payment requests are initiated from an iframe. This iframe origin is different from the calling context. The user gesture is not created in the frame, and there's no way to attach the user gesture to the show(). (Editor: See more below from Mathieu Hofman on this.)

<Zakim> AdrianHB, you wanted to ask about use cases where PH passes request over other channel (e.g. to mobile)

AdrianHB: Use case - you invoke a payment handler that does not display UI
... the server pushes a message to a mobile phone
... the user consents to pay from the phone
... the user data is sent back to the payment handler code, which can package up the payment method response, without ever having to show UI
... can your proposal accommodate that use case?

Danyao: I think the use case here primarily applies to native handlers.

AdrianHB: Not necessarily. A Web-based payment handler could forward information to a service that communicates with the user over another channel (e.g., mobile push, or some other Web API like WebAuthn)

<benoit> imagine a PH that simply renders a QR code and all the interaction is in the phone ... there's no gesture, is there?

Danyao: I think the principle we are proposing here is that the user be aware that a PH has been invoked after show()
... so there might be a browser-created spinner (for example) even if there is no window created by the ph
... e.g., the browser spinner might display "Foo.com is awaiting your response."
... the browser could paint that UI (or the payment handler could)

AdrianHB: Suppose browser paints the spinner. The spinner can go away before the ph closes
... maybe we can add a sort of time out. Like "the window must be open for N seconds without a user gesture."

Danyao: I agree that we would want to support this use cases. Time-based approach may be reasonable.
... so a combo of user gesture or time on the page is probably useful.
... so part of next step could be to document flows that would be "broken" by this proposal (to require user gesture) and to document workarounds or solutions

Gerhard: We are using exactly the flow that Adrian describes (some form of out-of-band notice to the user, eg. over GSM)
... so I agree with something like a "minimum amount of time" or "minimum amount of space on the screen"
... there are two scenarios potentially:

1) User gesture before show()

2) Or payment can indicate to the user agent "I will do a gesture once I run, so don't ask for one in advance"

Danyao: I am hearing the requirement for a gesture either before show() or after, and finding a way to get a single gesture.
... How would we trust that a ph would require the user gesture?
... we can, for example, ensure that the ph cannot close without the gesture
... but we cannot guarantee, for example, that the ph has already has not yet persisted some user information

Gerhard: Maybe there's a permission thing: I cannot do X until I've gotten consent (e.g., can't get to indexDB until something has happened).
... I want to show some information, and upon user "continue" gesture, I want to be able to access userDb (for example)

Danyao: We will discuss similar proposals later on: restricting write access prior to some other event.

Justin: I agree that some proposals here are likely to cover multiple use cases

tomasz: For SRC (tomorrow's agenda) we would like to propose to use an iframe in the payment handler window, where the payment handler does not display any interaction, but all the interaction is managed through the iframe.
... that's a case where the user gesture needs to be propagated to the embedded iframe.

Danyao: In that case, the interactive UI (from iframe)...we can probably treat any user gesture in the frame tree as sufficient.

Frank: I am happy to discuss more about use cases offline

danyao: Thanks, Frank.

Mathieu: Here's more description of what Danyao was referring to earlier: Our (Stripe) users can call payment request; processing happens within an iframe.
... for security reasons
... we need the propagation of user gesture ... where the gesture is done in the merchant page, but the call happens within a iframe.
... for PCI compliance the basic card data can't go through the merchant

Danyao: Could the call for action button be rendered in the iframe?

Mathieu: We'd need to allow merchants to determine what shows up in our iframe, which becomes tricky

<AdrianHB> @mathieu: would this go away if you didn't use PR for basic-card?

<mhofman> I suppose, but that's the main use case for us today

Justin: Next is UX indication of cross-origin switch
... this one is mostly an implementation detail. To alert the user more clearly that they are interacting on a different origin
... we are thinking about two use cases:

(1) How to alert them during loading

(2) Within the payment handler window, more emphasis on the origin of the payment handler

Justin: We need to do more UX research to validate the efficacy. I think this is otherwise straightforward.

[The proposal to move payment handlers to 3p context by default]

Justin: Browsers are moving in a particular direction around storage mechanisms and we want payment handlers to be consistent with that direciton. The proposal is that, by default, a payment handler opens in 3p context (double-keyed with merchant origin) but the browser will grant 1p access when there is some form of (one-time) user consent.
... Question is how to sandbox the ph service worker to 3p access when sw typically have 1p storage

Danyao: The entire proposal around "Storage Access API" is still under discussion in Google; so don't have a timeline for moving forward to this implementation
... we won't roll out this change until we have a good solution for use cases
... the main challenge here is that the service worker acts an access point for persistent storage of user's payment credentials.
... but the sw can also be used in the normal sw sense (e.g., intercept fetch requests).
... question is how to differentiate when sw is operating as part of payment flow v. other flows
... while payment flow we want to restrict storage access, but we don't want to break other use cases.
... so one proposal is that a sw cannot serve both roles: payment handler AND another role
... what we are looking for here is more on your use cases that require storage?

<Matt> Or is the limit only for certain events and not the actual payment event?

ChrisD: What would the user experience be like to get user consent? Would it be meaningful?
... Would it be specific like "You are going to make a payment with X. Is that ok?"

Justin: Are you asking about consent for first party storage access?

ChrisD: Yes

Justin: We'll walk through some example flows to show that.
... I agree that getting the language right for the user will definitely be a challenge; I don't think we are there yet.
... the other approach might be to simply follow the browser's general UX approach for requesting consent from the user for storage access.

ChrisD: From reading the proposals, it seems a lot are mitigated through consent, which is a tough UX issue

Justin: Agreed

AdrianHB: I like the mobile solution. Have you done any UX testing for desktop?

Justin: Yes, we are researching for both desktop and mobile

AdrianHB: Danyao commented about being able to understand when to impose (or not impose) restrictions. Are we talking about read-only access to indexDB here?

Danyao: In the 3p storage proposal we don't refer to the "no write access to indexDB" proposal.

AdrianHB: What I'm trying to address in my question - how do we partition functions of a service worker?

Danyao: Yes, we need to look more into event handling
... a service worker could communicate with open tasks in that origin and post messages, so the operation could break out of the event handler itself
... that would require that the user also have a tab open with the malicious payment handler.

Bryan: On the 3p proposal, I'm wearing my Amazon Pay hat.

<Matt> You can skip me on the queue. I think the discussion vaguely answered my question. Will dive more offline.

Bryan: 1p access is important to us and we see it as one of the major benefits of the payment handler approach
... To clarify the concern of payment handlers having access to 1p storage - is that primarily about user checking or reading of 1p data?

Danyao: mostly about writing of 1p data by a tracker using the payment handler api

(For more details about the origin of the 3p proposal, see: https://github.com/w3c/payment-handler/issues/351)

<Matt> Also remember that there are cases where the PH and Tracker are the same entity.... Its very difficult to protect against that

Danyao: Today its very easy to install a SW (silently) and persist user state

Bryan: +1 to the write access limitation proposal
... Regarding "one-time user consent", what are you pinning the user to?

Danyao: Browser instance.

Mathieu: Is there a difference between this and storage access API?
... For the flows where we need to onboard the user, how would it work if we are in a payment handler and create local storage.

Danyao: Regarding "Storage Access API", yes, the intention was for this to be the same (that is: we would leverage that emerging specification.)
have been ... we want to align with it
... also note that Storage Access API is partially deployed (Webkit, Firefox) but not yet in Chrome (experimentation happening)
... as far as we are thinking for Chrome around payments, once 1p access is granted, then both read and write would be allowed -- you would be able to set up state on enrollment.

Mathieu: One use case for service workers generally is to intercept some requests. A proposal: if the PH was not installed from 1P ahead of time (or through whatever user consent mechanism), allow it to run but not permanently installed, and only allow it to communicate / act on behalf (including fetch handling) of frames within the page that made the PR invocation (PH sheet and iframes of origin in main document). Would not need 1P storage until storage access granted through PH sheet.

ChrisD: If you present a PH from having 1p access, will that prevent it from storing shipping, etc.
... would you potentially provide read access without consent?

Danyao: I need to think through more that question
... it seems to me that "read only before consent" may be ok

<Zakim> Chris_D, you wanted to ask if the PH only has access to 1st party access, will it prevent it from auto populating payment instrument and billing details into the payment flow - one

Justin: Back to proposals that have more complex issues. The next proposals fall basically under three main strategies:

(1) explicit user install

(2) payment handler vetting

(3) threat vector removal

Justin: these are not entirely mutually exclusive.
... and also there are probably still edge cases with each
... and the questions about user consent and how good it is are still important here

[Explicit user consent for install]

Justin: PHs need explicit user consent to access local storage and hasEnrolledINstrument(). Consent could happen at install or first use

(We see some flows and UX)

Justin: We think that both of these flows (we've shown) may be required for different use cases

AdrianHB: Point of clarification on your first flow example - is that JIT?

Justin: Yes

AdrianHB: how would this work if you also had to show the sheet?

Justin: The reason that we need the second flow is where JIT is not possible (e.g., standardized payment method)
... I don't have any UI here for how it would look with the sheet, but it would look very similar

Danyao: If we were to have a payment sheet, it would probably show prior to the user consent prompt.

Justin: Also when a payment handler selector is required (the sheet or other mechanism), that is another option to provide information about whether a payment handler has been used previously.
... A pro of the explicit install proposal: transparent to the user and probably improves user awareness

Justin: But con New consent step might create drop-off. Key open questions: could an extra consent step harm viability of ph? What happens when consent is declined? What does that flow look like?

jalpesh: on the experience that AdrianHB was referring to, is the second screen shown by the browser?

Justin: Yes

Jalpesh: That makes sense.

Justin: We don't know yet what forms of customization (if any) might be possible by the payment handler

nicktr: I think that consent is really important.
... the consent is likely to be one-time, so the friction may be lessened in that way
... I think explicitly install is strongly the way to go.

<AdrianHB> +1 to NickTR

Ian: The proposal refers to two options for consent: at install or on first use. Based on discussion there might be a third option: during the payment handler's execution. The idea is that the payment handler may have a way to integrate consent smoothly into that particular payment method flow. The browser could prevent the payment handler from doing some things until such time as the payment handler has triggered the request for consent.

Gerhard: Explicit install brings with it some benefits
... to nick's point, if I install it on Chrome instance #1, do I need to consent to Chrome instant #2?

Justin: My intuition is that it would be nice to propagate across instances of a browser, but a lot of investigation would be necessary. And we'd also want to align with similar browser use cases.
... so as a guiding principle is that if the browser knows the user across instances, it should work that way

Gerhard: There are two phases to using a payment handler (e.g., guest checkout scenario): (1) Enrollment of credentials and (2) Transaction time. It may make sense to allow for two different consent journeys --- when I am doing things at the payment handler 1p context, or when I am shopping on a different merchant site (JIT install)
... so JIT install and "explicit install" may involve 2 consent flows

AdrianHB: I agree maybe in the 1p instance we don't need the same level of user gesture
... e.g, ordinary service worker install
... but the user still would need to do things when the user wants to use this handler on other sites

mhofman: Would there be any way for the merchant to see if the payment handler has already been installed?
... and to install the onboarding "penalty" if they don't want to opt into that.

Danyao: hasEnrolledInstrument could answer that

mhofman: But what if hasEnrolledInstrument ("hEI") usage is restricted?

Danyao: For now the restrictions we have in mind for hEI are (1) if not installed, hEI returns false(). (2) but after install can return true (but read only access to storage)

btidor: Does this really plug the privacy hole? Will users forget having installed payment handlers? And will they understand their ongoing consent?
... I suggest perhaps moving the consent into the payment flow itself

Danyao: We did explore expiration of consent. E.g., if the user has not used the ph after some period of time, then the user is reprompted
... ...I agree that "permanent approval" poses issues
... expiry is on the table

<AdrianHB> @btidor: I think there are a number of mitigations that can be introduced to handle long lived PHs potentially tracking users. For example, if the hasEnrolledInstrument is called a lot but the Ph is never invoked the browser might expire the consent

rouslan: the user may not understand that installing a ph on one site might be used on other sites
... would it be crazy to install payment handlers from a web site
... that means that each web site would have to go through the onboarding flow
... the advantage would be that the user understands more that the ph interacts with different web sites

<AdrianHB> I would expect that there will soon be an ability within browsers to review the Payment Apps you have installed etc

<danyao> +1 yes to give user ability to review installed payment handlers

Justin: Next topic is 'payment handler vetting'
... One proposal is that only "vetted" payment handlers could have access to 1p local storage and hasEnrolledInstrument.
... vetting could be per-browser or a global registry
... pros include low incremental user friction and minimal change for current payment handlers
... cons include payment handler onboarding friction and cost of maintaining a gatekeeper registry

Gerhard_: There are a number of organizations that do some vetting
... so may wish to distribute the vetting process to other organizations

<AdrianHB> Propose that we make "vetting payment handlers" a last resort

Ian: I have concerns about any entity being a centralised gatekeeper. Tthe payment method manifest is an implementation of a delegated approach. I wondered if the FIDO folk can offer insight from their certification experiences...

<AdrianHB> "Certification" to use a Web Platform API would be unprecedented

John_Bradley: Complicated beasts. I would lean on existing programs, especially in Europe
... where people have to register and get a qualified digital certificate
... running a certification program is expensive and potentially legally fraught.

JohnFontana: +1 to JohnB's comments. Once you wander away from simplicity it can be very challenging.

stpeter: Agree in general with challenge of registry. We and the other browsers have had challenging experiences with Web extensions that have malicious behavior. I think we need to take action on this front in some form or another.

stpeter: Increasing onboarding friction for those who are already doing the right thing is not a major problem

ChrisD: +1 to Peter

<AdrianHB> +1 to stpeter

<Zakim> Chris_D, you wanted to comment that payment handlers get to solicit sensitive PFI from consumers; WebPayments gives a payment handler a level of credibility and therefore should it

ChrisD: Payment handlers need to be trusted by users...so I think we need to take steps to ensure that rogue payment handlers are not unleashed, and it would not be a major hurdle for legitimate market actors

Justin: Third option at a high level is to attempt to remove threat vectors.
... for example, do we need hasEnrolledInstrument?
... we have heard that some in the ecosystem consider this very important.
... are there alternatives that would still be useful?

Danyao: Two additional proposals related to querying user environment.
... there has been some confusion about canMakePayment and hasEnrolledInstrument.
... we've linked to a proposal to clarify that there are 2 events available
... but having 2 APIs doesn't change the threat surface
... but it would have some impact on payment handler distributors (since there would be a second event to handle)

<benoit> no idea what happened to my connection; my concerns about a certification process were likely already mentioned by now by others ... that up-starts will have a Goliath to face, and using existing programs like those in the EU for PISP or even PCI impose a burden that a) may not be necessary for early stage companies, or b) may not exist from a regulatory is the startup's country/region

<AdrianHB> +1 benoit

Danyao: While waiting, I have greater clarity and understanding of concerns. Justin and I will update the proposals and schedule offline converations

<mhofman> What was the @chromium list that was mentioned?

Combining gestures to launch WebAuthn and payment handlers

Adrian Hope-Bailie Slides

AdrianHB: Proposal inspired by payment handlers that want to use WebAuthn for strong authentication
... goal is to combine 2 gestures: launch webauthn and launch payment handler. The proposal involves a modification to payment handler registration -- the ph registers credentials. Gist of idea is to have the browser trigger webauthn for registered credentials and update the UX to say "Authenticate" and to enable single gesture to launch WebAuthn or payment handler
... Some questions in the deck.
...including: scenarios where this would not work (e.g., JIT installation)? Would this work equally well with other forms of credential than WebAuthn?

Gerhard_: We've seen demos of a minimal flow. Could you achieve the same with a payment handler specifically done for authentication?

AdrianHB: The minimum UI flow is similar to what I'm talking about. The difference at the moment is the signal from the browser that the user has agreed to the payment.
... it's not a full signed assertion (with WebAuthn challenge)

Danyao: +1 to Adrian's distinction
... the original minimal flow was just a demo. Seeing AHB's proposal, I think that's a direction to go in.

<Zakim> Chris_D, you wanted to ask whether WebAuthN data could be exposed to a rouge payment handler by providing the assertion proactively? Could a rouge PH act as a man-in-the middle if

Nick: Let's take up Chris's question at call on Weds on authentication

Wrap-up for today

Nick: Thanks to all. Tomorrow SRC!

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/10/16 14:09:14 $