Re: [w3c/payment-handler] Security consideration: user consent before payment (#365)

@danyao commented on this pull request.



> @@ -2438,10 +2438,19 @@ <h2>
         </h2>
         <ul>
           <li>One goal of this specification is to minimize the user
-          interaction required to make a payment. At the same time, user agents
-          must not permit combinations of configurations that would enable
-          invoking Web sites to invoke payment request and receive payments
-          silently.
+          interaction required to make a payment. However, we also want to
+          ensure that the user has an opportunity to consent to making a
+          payment. Because payment handlers are not required to open windows
+          for user interaction, user agents should take necessary steps to
+          provide for some form of user action before <a data-cite=
+          "payment-request#show-method">PaymentRequest.show()</a> resolves. For
+          example, a user agent might do nothing if a payment handler opens a
+          window and the user has an opportunity to confirm a transaction via a
+          button. But if the payment handler does not open a window, or opens a
+          window without an opportunity for user interaction, the browser might
+          prompt the user to confirm the payment handler's behavior before

Maybe we can add a `finalizeResponse()` method to `PaymentRequestEvent` that the payment handler must call with a user activation. I worry about this being brittle for scenarios like this:
- User interaction happens inside a cross-origin iframe in the PH window, so there's no way to transfer that user activation to the PH origin to trigger `PaymentRequestEvent.finalizeResponse()`. This can be the case if the PH embeds a 3DS flow from a bank or PSP.
- Browser minimal UI flow where the browser shows a native UI for a PH without showing any web content from the PH.

The alternative I had in mind was for the browser to track user interactions within the payment handler's web content as an internal state, e.g. `[[userInteracted]]` of the PaymentRequest. I need to dig more into the code to know how hard this would be. The main downside is that we're leaving the definition of "user interaction" to the browser instead of leveraging the standardized "user activation" definition, so be a source of interop subtleties. The upside is that "user activation" as spec'ed today has very complex rules for how they can be transferred. Opening it up to address the iframe case could actually increase the overall security surface.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/pull/365#discussion_r409824205