Status update on proposed payment handler changes from Mar 30

Dear Web Payments Working Group,

At the Mar 30 WPWG virtual meeting, my colleague Justin Toupin and I
presented some proposed changes to the Payment Handler API (slides
<https://docs.google.com/presentation/d/1hWUKPWYhNFO7UuQ59ETHdSvU5dOz06GGXt_AubQZ_P4/edit#slide=id.p>)
to improve upon its privacy and security properties. Thank you for all the
feedback. I’d like to give you an update on these proposals.

===

Of the self-contained mitigations proposed:

1A) Require user gestures
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#mandatory-user-interaction-with-payment-handler-window>

This contains two parts: (i) require user gestures to trigger
`request.show()` and (ii) require a user interaction with the payment
handler before releasing the `PaymentResponse` to the caller.

For (i), we heard a use case from Stripe where `request.show()` must be
called in a separate iframe from the one that captures the user gesture. We
propose these next steps:

   -

   For the short term, Chrome will whitelist known affected origins such as
   Stripe, but start to enforce the user gesture requirement on all other
   origins.
   -

   For the long term, explore the viability of the Activation through
   postMessage <https://mustaqahmed.github.io/user-activation-delegation/>
   solution with other browser vendors. If this fails, we will work with
   affected origins to find workarounds.


Ask: please let us know if your origin also needs to be exempted from the
user gesture enforcement.

For (ii), we heard some concern about user friction if an additional click
is required, but we didn’t hear any objection against ensuring the user is
aware that a payment handler is invoked. So we’re moving ahead with these
steps:

   -

   Added a note to the Privacy & Security section of the Payment Handler
   API to highlight user agent’s responsibility to ensure this awareness:
   https://github.com/w3c/payment-handler/pull/365
   -

   Go back to the drawing board to identify solutions that both provide a
   meaningful signal of user interaction while taking into consideration the
   friction concerns raised. This work will be tracked in
   https://github.com/w3c/payment-handler/issues/369


1B) Stronger UX indication for cross-origin switch
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#13-ux-indication-for-explicit-cross-origin-context-switch>

This proposal is a pure UX change in Chrome so will not impact the spec. We
heard feedback supportive of clearer user awareness, provided it doesn’t
introduce additional friction. So we have taken the following steps:

   -

   Added a note to the Privacy & Security section of the Payment Handler
   API: https://github.com/w3c/payment-handler/pull/366
   -

   Provided the feedback from the WG to the Chrome designers to incorporate
   into the final design.


1C) Make payment handler a 3P context by default
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#payment-handler-browser-context-3p-by-default>

We heard that having the payment handler being considered a 1P context is
important for login persistence and APIs such as WebAuthn that can only be
used in a top-level browsing context. We also  didn’t reach an agreement on
the mechanism to get user’s consent to grant 1P access.

We propose these next steps:

   -

   One of the original threats that motivated this proposal was zero-click
   tracking attack
   <https://w3c.github.io/webpayments/proposals/privacy-threat-model.html#zero-click-track-web>.
   We plan to prioritize shipping 1A) above to close this gap.
   -

   Deprecate the wildcard for `supported_origins`
   <https://w3c.github.io/payment-method-manifest/#format> from the Payment
   Method Manifest spec. This will increase the bar for pulling off an attack.
   This is tracked in
   https://github.com/w3c/payment-method-manifest/issues/42.
   -

   Explore best patterns for login persistence with less reliance on
   storage usage patterns that are also exploited by trackers today.
   -

   Prioritize the evaluation of vetting and low-friction installation flows.


Ask: please flag any additional use cases that depend on the payment
handler being 1P in https://github.com/w3c/payment-handler/issues/370. This
will help constrain our search for a solution.

===

Of the mitigations with more complicated implications:

2A) Explicit user install
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#11-explicit-installation--consent-flow-for-payment-handlers>

We heard general reservations about explicit user install due to friction.
Since this is a Chrome-only UX feature, there is no impact on the spec. We
will update this group when we have a new design.

2B) Payment handler vetting

We heard supportive feedback from the group on vetting. Offline
conversation with other browser vendors flagged concerns about the
governance of a registry. We continue to explore options but don’t have any
updated plan to report at the moment.

2C) Threat vector removal

This contained two parts: (i) read-only access to local storage before
`request.show()`
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#22-read-only-storage-access-before-show>,
and (ii) remove `hasEnrolledInstrument()`.

After more investigation, (i) seems technically too complex to implement.
So we’ll drop this proposal.

For (ii), we heard feedback that this API is useful. We are brainstorming
some alternatives and will reach out for more feedback.

===

Of the other proposals:

3A) Separate events for canmakepayment and hasenrolledinstrument
<https://github.com/w3c/payment-handler/wiki/2020-Mar-proposed-changes#canmakepayment-and-hasenrolledinstrument>

We heard some support and no objection to this proposal so we’ll move
ahead. This will be tracked in
https://github.com/w3c/payment-handler/issues/364.

3B) Change skip-the-sheet behavior
<https://docs.google.com/document/d/1JH-IWDyvrSx70TDtmhvP-0F4Aob9Wz_oLh91U9kwTx0/edit#heading=h.dukxss20appt>

We didn't hear clear objections to the current behavior of skip-the-sheet
as of M80, so we plan to keep it.

===

Thanks,

Danyao