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

@danyao commented on this pull request.

> If it is up to the payment handler to call PaymentRequestEvent.finalizeResponse(),
> that seems to leave open the possibility that the payment handler could lie.

Payment handler can't lie if the browser rejects the show promise if `PaymentRequestEvent.finalizeResponse()` is called without a user activation.

Thinking about it a bit more, the iframe use case I described can fit in today's user activation model [1] because click events are allowed to propagate upwards to parent frames, even cross-origin ones. This is good.

For the minimal UI case, we can still ask payment handler to call `finalizeResponse()`, but browser can override the user activation requirement based on user's interaction with the native UI.

The other question is backward compatibility: how should a browser handle legacy payment handlers that don't yet call `finalizeResponse()` explicitly? Maybe we can take a two-step approach:

1. Bridge solution: browser tracks user activation inside PH window and implicitly call `finalizeResponse()` when the window closes.
2. End state: PH has to explicitly call `finalizeResponse()`.

We would also need an extra state to `PaymentRequest` to track if an implementation specific window is ever opened. If not, the show promise should reject when the PH attempts to resolve the promise.

> @@ -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

> 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

This seems too prescriptive. Would it be sufficient to say something like this?

"...At the same time, user agents should take necessary steps to make sure the user is made aware when a payment request is invoked, and has an opportunity to interact with the payment handler before the merchant is allowed to receive the payment response from the payment handler."

-- 
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#pullrequestreview-394972103