Should the Payment Request API only be available in a top-level browsing context?

[adrianba]

This issue comes from WICG/paymentrequest#30 and was discussed at the F2F.

[mattsaxon]

The proposals made at the f2f would significantly impact the user experience for merchants. Many small or even large merchant use iframe in their payment processing to delegate to a 3rd party.

Today is is possible for iframe to request payments, so a move to the user agent mediated approach is a massive step in the right direction for security.

The user-agent can do lots to call out who the payment request is being made and we could even do things such as allow a merchant's website to nominate which iframes should be allowed to request payments.

[adrianhopebailie]

In TAG review @triblondon said:

[This issue discusses] whether iframes should be able to request payment. It seems like a severe limitation to me to prohibit that mode of use.

[adrianhopebailie]

We require a comprehensive proposal to address this use case that considers how a merchant may put an iframe into their site that is able to call the payments API but only with the explicit permission of the merchant.

We should also consider what user permissions should be required for this and consult with @w3c/webappsec-admin for guidance.

[adrianhopebailie]

A proposal is required for how the API may be safely exposed in lower level contexts (like iframes)

[dlongley]

Reminder that a future-looking use of this API is to be able to call it on, for example, search results. Merchants could publish digitally-signed payment requests where they don't care how someone happens to find it. A search engine could make these available to be clicked on for immediate purchases via search results.

Search results used to just be a list of blue links on a page and they have since become filled with very rich structured data, images, and interactive displays. They could be further augmented with the ability to make purchases much more quickly and seamlessly.

There may also be cases where IoT devices (w/o "merchant websites") publish digitally-signed payment requests w/push based payment that would require this API to be called in different contexts.

[webpayments-specs]

On Thu, Jun 9, 2016 at 12:09 PM, Dave Longley notifications@github.com
wrote:

There may also be cases where IoT devices (w/o "merchant websites")
publish digitally-signed payment requests w/push based payment that would
require this API to be called in different contexts.

Think soda vending machine. This is a really interesting use case,
actually.

Shane McCarron
Projects Manager, Spec-Ops

[adamroach]

I finally cornered one of our security people on this. He points out that the kind of thing we're trying to do is congruent with the delegated permissions work currently underway.

I propose we adopt this approach, which allows both declarative and imperative delegation of extra permissions to iframes.

Declaratively:

<iframe src="..." permissions="payment">

Imperatively:

var iframe = document.getElementById('payment_frame');
navigator.permissions.delegate({embedee: iframe, name: 'payment'}).then(
  function() {
    // Delegation succeeded.
  }).catch(function() {
    // Delegation failed.
  });

In particular, we beleive that using the sandbox attribute for this purpose, as was discussed last month, is the wrong tool for this job, as it removes capabilities, rather than adding them.

[adrianhopebailie]

+1 @adamroach

@zkoch - you proposed the sandbox attribute. What are your thoughts?

[zkoch]

I think this is great. We should find out what the timetable for this is. Since both authors are from Google, I'll reach out. :)

[sideshowbarker]

from @zkoch:

I think this is great. We should find out what the timetable for this is. Since both authors are from Google, I'll reach out. :)

To be clear on what that comment is referring to (there’s no comment threading in github issue trackers, so the context gets lost easily…), it seems clear it’s in reply to @adamroach’s comment at #2 (comment):

the kind of thing we're trying to do is congruent with the delegated permissions work currently underway.

I propose we adopt this approach, which allows both declarative and imperative delegation of extra permissions to iframes.

…which refers to the draft spec at https://noncombatant.github.io/permission-delegation-api/ (from the WebAppSec WG) authored by @raymeskhoury and @noncombatant (Chris Palmer).

[zkoch]

Wanted to update this. I've reached out and talked to a few people on our security team. It sounds as though delegated permissions is being merged into Feature Policy. I think Feature Policy still has what we need. According to one of the editors, they expect to support cascading permissions, so this would work for our needs.

Issue #18 on the Feature Policy repo has been added to track support for web payments.

[adrianhopebailie]

Awesome stuff! Thanks @zkoch

[sideshowbarker]

FYI we’re adding a payment-request-in-iframe test to web-platforms-tests, which is just a copy of the test from Chromium third_party/WebKit/LayoutTests/payments/payment-request-in-iframe.html and can currently be run here:

https://w3c-test.org/submissions/3440/payment-request/payment-request-in-iframe.html

So, if the resolution for this issue results in a change to the expected result for that test, then we need to remember to update the test at that time.

cc @halindrome

[adamroach]

Note: We need to re-evaluate question 3.13 of the Security and Privacy Checklist once this issue is closed. See https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?usp=sharing for additional detail