The origin restrictions in the PaymentRequest are not nearly strong enough

[bzbarsky]

Step 3 of the steps in https://w3c.github.io/browser-payment-api/#constructor (I see no way to link to the steps directly) says:

If the browsing context of the script calling the constructor is a nested browsing context whose origin is different from the top-level browsing context's origin and the nested browsing context is not allowed to make payment requests, then throw a SecurityError.

This has at least two problems (not counting the already-filed #324 and #323):

1. Consider the case when our toplevel origin is A, which loads a subframe from origin B, which loads a subframe from origin A. This innermost frame would be allowed to make payment requests, as the spec is currently written, even if the B subframe is not. That seems very odd to me. The secure thing here would be to only allow payment requests in a document if all its ancestor documents can make payment requests, plus whatever other criteria are desired. This is how feature policy would work, for example.
2. It's not clear to me that any of this considers that various of the documents involved may not be active, or may not be fully active. It's hard to tell, exactly, because the other two issues I cite above mean the processing model is really not defined at all here.

[adrianhopebailie]

Consider the case when our toplevel origin is A, which loads a subframe from origin B, which loads a subframe from origin A. This innermost frame would be allowed to make payment requests, as the spec is currently written, even if the B subframe is not. That seems very odd to me.

Why does that seem odd?

On the contrary I would think it's odd if A had to give permission to call payment request to B as a way to let B embed a frame from A that can.

Use case example:

Merchant A embeds frames from B who is a third-party that manages their advertising across all properties. A wishes to give B the ability to show advertisements with "click-to-buy" functionality but doesn't want B to be able to invoke the payment API directly.

[bzbarsky]

Why does that seem odd?

Because it allows B to trigger payment requests from A by when A might not expect it to.

Note that the proposed feature policy API has exactly the semantics I'm talking about: if a document doesn't have permission to do something, neither do any of its descendants. And I believe that having the payment permissions model be describable by feature policy is an explicit goal. So if it can't be, one or the other is wrong and needs to change.

[adrianhopebailie]

Because it allows B to trigger payment requests from A by when A might not expect it to.

I disagree. Both contexts from origin A (the top-level and innermost contexts) can trigger payment requests but the other context (with origin B) cannot.

[bzbarsky]

The point is, it allows B to embed an A iframe and try to manipulate it in various ways (postMessage, URL structure, etc) to try to get it to trigger a payment request. If the inner iframe is written defensively enough this may be ok, but if it's not, you end up with a problem.