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

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

[1] https://mustaqahmed.github.io/user-activation-v2/

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