Intent to implement and ship: iframe support for web payments

[Rouslan Solomakhin]

Contact emails

rou...@chromium.org, sanjo...@samsung.com, zk...@chromium.org

Spec

https://w3c.github.io/browser-payment-api/#paymentrequest-and-iframes

Tag review

https://github.com/w3ctag/spec-reviews/issues/147

Summary

The HTMLIFrameElement is extended with an allowpaymentrequest content attribute. allowpaymentrequest is a boolean attribute. When specified, it indicates that scripts in the iframe element's browsing context are allowed to make payment requests (if it's not blocked for other reasons, e.g., there is another ancestor iframe without this attribute set).

Motivation

There are some circumstances where a cross-origin iframe wants to make a payment request. A cross-origin iframe needs explicit permission from the embedding page to invoke the payment request API.

Interoperability risk

Firefox: Public support

Edge: Public support

Safari: No public signals

Web developers: Strongly positive

Compatibility Risk

Low: Other implementers have not shipped PaymentRequest yet. The API surface is small and additive.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

allowpaymentrequest is supported on all platforms where PaymentRequest is supported. This is currently Android and eventually all other platforms, except Android WebView. There's no PaymentRequest support planned for Android WebView.

OWP launch tracking bug

http://crbug.com/652148

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5511036157296640

Requesting approval to ship?

Yes

[Philip Jägenstedt]

What kinds of sites and embedded iframes are most likely to make use of this? I imagine that you'd have to trust the security of the embeddee to a high degree. For example, if the iframe is navigated, whatever it navigates to would also have the permission. With Feature Policy it's possible to limit the delegation to a specific origin, which at the very least seems like a nice-to-have. Could we end up with both allowpaymentrequest and a Feature Policy equivalent?

Nit: allowedToUsePaymentRequest() in PaymentRequest.cpp seems to not handle out-of-process iframes, see allowedToUseFullscreen() in Fullscreen.cpp and WebFrameOwnerProperties with related code for how that state is replicated. The complication with out-of-process iframes is one reason to dislike allow* attributes, and if it all possible I think it'd be good to limit the number of such attributes to 1 (allowfullscreen) forever.

There is discussion ongoing in https://github.com/w3c/browser-payment-api/issues/311. What to do largely depends on other vendors' plans I'd say. If this feature is important to another vendor that doesn't plan to ship Feature Policy any time soon, then some interim solution is necessary. I do think that something that could be trivially mapped onto Feature Policy later might be preferable though, were any such alternatives explored when making the spec or implementation change?

[Rouslan Solomakhin]

Many shopping websites place their checkout experience in iframes to improve compliance and delegate handling of credit cards to 3rd party services like Stripe, PayPal, Shopify, and Worldpay, to name a few.

I agree that FeaturePolicy is the best way to go, if the other browsers also implement it. The iframe allow* attribute was added to the spec when even Chrome was not sure of the timeline for FeaturePolicy implementation. It seems that we might have it in M-57?

[Ian Kilpatrick]

+FeaturePolicy folks

So just to clarify - the intent/plan now is (modulo feedback from other vendors on FeaturePolicy):

 - Disable the allowPaymentRequest attribute that was going to ship in M-56.

 -  Implement a subset of the FeaturePolicy API (just enable="paymentrequest") in M57(?).

 - M57/58 full(er) support of the FeaturePolicy API(?).

rouslan - is above correct (again modulo FP feedback)?

FeaturePolicy folks - is above reasonable? Also who is on point for getting feedback from other vendors at this point?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rouslan Solomakhin]

On Wed, Nov 23, 2016 at 10:28 AM, Ian Kilpatrick <ikilp...@chromium.org> wrote:

 - Disable the allowPaymentRequest attribute that was going to ship in M-56.

 

I'm doing this in http://crrev.com/2525813003

 -  Implement a subset of the FeaturePolicy API (just enable="paymentrequest") in M57(?).

 - M57/58 full(er) support of the FeaturePolicy API(?).

FeaturePolicy folks: What needs to be done to accomplish these two tasks? I can help, if needed.

who is on point for getting feedback from other vendors at this point?

https://github.com/w3c/browser-payment-api/issues/311 has a discussoin where Marcos Cáceres of Mozilla states he's not aware of plans to implement FeaturePolicy in Mozilla. I'm continuing the discussion on github and will bring this up at the next weekly WG conference call.

[Rouslan Solomakhin]

According to Mozilla, they cannot implement FeaturePolicy in time, so we should be using allowpaymentrequest iframe attribute:

https://github.com/w3c/browser-payment-api/issues/311#issuecomment-263170521

Tag review has turned up a few concerns for me to address:

https://github.com/w3ctag/spec-reviews/issues/147#issuecomment-262400109

[Ojan Vafai]

I commented on the github issue. Noone proposed to them the interim solution that we decided to aim for on the platform-ergonomics@chromium thread about this. They should be able to do the same.

[Jochen Eisinger]

I'm a bit surprised that 3rd parties would allow payments when iframed. I was under the impression that the risk of click-jacking or other attacks was too high, so they'll always navigate to their own site first?

How would a third-party make sure that the embedding site is actually a valid customer and not an attacker?

best

-jochen

[Jeff Carpenter]

Hi Jochen, 

Payments in an iframe are necessary for 3rd parties like payment gateways to enable their merchants to meet the easiest level of PCI compliance - SAQ A - which stipulates that payment details must be entered only on the 3rd party payment provider's domain.

In the case of payment gateways, the iframe sends the payment details to the gateway and returns a payment method token to the merchant's website. Transactions are created from the merchant's server, not from the browser. From what I understand, if the merchant has proper CSRF protection, all an attacker can do is create new payment method tokens, not new transactions.

[Ian Kilpatrick]

Cycling back here - see: https://github.com/w3c/browser-payment-api/issues/311#issuecomment-264554355

(TL;DR)

We (Chrome) discussed using FeaturePolicy for this API instead of the new iframe attribute, and think that it's worth going ahead with the attribute for this feature.

For future specs we'll bring up using FeaturePolicy again. 

non-owner lgtm.  

[Jochen Eisinger]

Thanks for the answer. I have to admit that I don't know what PCI compliance nor SAQ A means.

In the intent to ship, strongly positive support from web developers is listed - could you please point out some instances of this support? Do we have supporting statements from payment providers such as Paypal (which was mentioned as a possible user of this API)?

best

-jochen

[Rouslan Solomakhin]

Most of the conversations with merchants happen over private BD talks, but here's one example documented in the public. Matt Saxon of WorldPay stated:

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

WorldPay is a payment processor for merchants. +Zach to see if he can show more evidence of developer support.

[Jochen Eisinger]

thanks!

lgtm1 to ship.

Please make sure that there's a chrome launch review bug filed. I think specifically the UI that explains to the user what origin wants to get payment data should get explicitly reviewed by security and UI 

[Rouslan Solomakhin]

Can http://crbug.com/652148 be used for this? I've raised your concern in http://crbug.com/652148#c18.

[Jochen Eisinger]

no, please file a regular launch bug to trigger the needed reviews (go/newChromeFeature for instructions)

[Chris Harrelson]

LGTM2

[Simon Pieters]

On Wed, 23 Nov 2016 00:52:52 +0100, Rouslan Solomakhin
<rou...@chromium.org> wrote:

> Contact emails
>
> rou...@chromium.org, sanjo...@samsung.com, zk...@chromium.org
>
> Spec
>
> https://w3c.github.io/browser-payment-api/#paymentrequest-and-iframes

Sorry to chime in a bit late here, but I want to point out that as far as
I can tell the implementation does not match the current spec. The spec
changed very recently, and has several open issues, with possible security
holes (in the spec; not sure about the impl).

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/payments/PaymentRequest.cpp?q=allowpaymentrequest&sq=package:chromium&dr=C&l=468

vs

https://w3c.github.io/browser-payment-api/#constructor step 3

Some open spec issues
https://github.com/w3c/browser-payment-api/issues/363
https://github.com/w3c/browser-payment-api/issues/362
https://github.com/w3c/browser-payment-api/issues/361
https://github.com/w3c/browser-payment-api/issues/360

Recently merged pull request that changed things in this area; fixed some
earlier-reported issues but introduced some of the above issues:

https://github.com/w3c/browser-payment-api/pull/359

Open spec issues/PRs on whatwg/html
https://github.com/whatwg/html/issues/2143
https://github.com/whatwg/html/pull/2133


> *Tag review*

> https://github.com/w3ctag/spec-reviews/issues/147
>
>
> Summary
>
> The HTMLIFrameElement is extended with an allowpaymentrequest content
> attribute. allowpaymentrequest is a boolean attribute. When specified, it
> indicates that scripts in the iframe element's browsing context are
> allowed
> to make payment requests (if it's not blocked for other reasons, e.g.,
> there is another ancestor iframe without this attribute set).
>
> Motivation
>
> There are some circumstances where a cross-origin iframe wants to make a
> payment request. A cross-origin iframe needs explicit permission from the
> embedding page to invoke the payment request API.
>

> *Interoperability risk*

> Firefox: Public support
> Edge: Public support
> Safari: No public signals
> Web developers: Strongly positive
>
> Compatibility Risk
>
> Low: Other implementers have not shipped PaymentRequest yet. The API
> surface is small and additive.
>
> Ongoing technical constraints
>
> None
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> allowpaymentrequest is supported on all platforms where PaymentRequest is
> supported. This is currently Android and eventually all other platforms,
> except Android WebView. There's no PaymentRequest support planned for
> Android WebView.
>
> OWP launch tracking bug
>
> http://crbug.com/652148
>

> Link to entry on th*e feature dashboard*

>
> https://www.chromestatus.com/features/5511036157296640
>
> Requesting approval to ship?
>
> Yes
>

--
Simon Pieters
Opera Software

[dgla...@google.com]

LGTM3, please address Simon's feedback.

:DG<

[Dimitri]

LGTM3, please address Simon's and Jochen's feedback.

:DG<

[Rouslan Solomakhin]

+Zach

[Philip Jägenstedt]

Simon also filed https://github.com/whatwg/html/pull/2187 today and I would very much like to strive towards that model for allowfullscreen. For allowpaymentrequest, I think we should have this behavior out of the gate. Given the high profile of this, even a single release with the allowfullscreen-like behavior could ruin the possibility of later defining allowpaymentrequest in terms of Feature Policy. 

[Rouslan Solomakhin]

I would like to ship based on the current spec, with the caveat that the behavior (but not the API shape) may change slightly based on whatever consensus emerges for the two open issues:

• The same-origin behavior, discussed in https://github.com/whatwg/html/issues/2184.
  
• The snapshotting behavior, discussed in https://github.com/whatwg/html/pull/2187.
  

Compat risk is low given the current usage.

[Rick Byers]

I dug into the state of the debate a little.  I agree you should go ahead and flip this to stable for M57 (so still LGTM).

There's still some outstanding discussion and we can expect some spec tweaks.  Hopefully those get resolved sometime in Jan or Feb and you can update our implementation to match.  But if you end up needing to make some breaking changes to the semantics here, I'm confident the compat risk will be managable.  Overall PaymentRequest usage is still below what'd we'd normally worry about in terms of compat risk.

Rick