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?
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
Nick: Thanks to all. Tomorrow SRC!