Re: [paymentrequest] Should the Payment Request API only be available in a top-level browsing context? (#30)

Hi, Adrian.  I think whether or not an API should be available in an iframe
boils down to the security properties of that API.  Do users need to be
able to definitively know what context it's being called in to use it
safely, and is the URL bar the only way to know this with certainty?  It
certainly seems there are valuable use cases for payments inside an iframe,
so perhaps it should be a design goal that it is safe to use without this
context, e.g. by providing some notification in other browser-controlled
UI.  (We knew there was value in working in an iframe for FIDO, so we aimed
to make the API safe to use by constraining it to be fairly strictly
origin-bound, but that approach may not be suitable for payments.)

There are also some other nuances here.  It should probably be "foreground
only" (in the active tab vs. a background tab) regardless of whether it is
in the top vs a nested browsing context, and it probably should at be OK to
activate it in an iframe that is part of a unit of related similar origin
browsing contexts (
https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts)
with the top-level context, even if you do decide a top-level restriction
is necessary.

On Fri, Dec 11, 2015 at 5:09 AM Adrian Hope-Bailie <notifications@github.com>
wrote:

> There is a prominent use case that would require third-parties to be able
> to call the API (with explicit permission from the top-level context). That
> is the case of merchants (the top-level context) who offload their
> processing to third-party PSPs (sub-context) without doing a complete
> redirect of the user's browser to the PSP's website. @mattsaxon
> <https://github.com/mattsaxon> and @mountainhippo
> <https://github.com/mountainhippo> can provide some more detail I'm sure.
>
> i.e. We DO need a mechanism for the top-level website to provide explicit
> permission to 3rd parties to call the API.
>
> I would recommend that we get some thoughts from WebAppSec on this. cc
> @hillbrad <https://github.com/hillbrad>
>
> In fact, even the top-level context should not be able to learn what
> payment instruments the user supports before the user selects the
> appropriate one, which requires a secure context that cannot contact the
> merchant, but maybe that discussion belongs in anther issue.
>
> [image: :+1:] the calling website learns nothing about the status of the
> request until the user has selected a payment app and the app has returned
> a response. It's even possible that the website never knows what app was
> used if the payment method response is standardized and that is all that's
> returned.
>
> This is all with one caveat. It will be very valuable for a website to
> check if its *own* payment app is installed. This would be enforced by
> the UA which knows the origin of the app publisher and only supports the
> use of this API function if the origin of the current browsing context is
> the same. Merchants and PSPs that publish apps to facilitate custom payment
> methods that incorporate features such as loyalty programs or coupons will
> need a way to tailor the user experience prior to issuing the payment
> request so they can encourage customers to login (so they can customize the
> payment request) or install the merchant's payment app.
>
> @burdges <https://github.com/burdges> - This is related to your comment
> here too: w3c/webpayments#28 (comment)
> <https://github.com/w3c/webpayments/issues/28#issuecomment-163893044>
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/WICG/paymentrequest/issues/30#issuecomment-163933084>.
>


---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/30#issuecomment-164005357