1037662 - Grant Firefox Accounts (FxA) access to web payment providers

Status: VERIFIED FIXED

(Core :: DOM: Device Interfaces, defect, P1)

Description

[Kumar McMillan [:kumar]]

A web payment provider (https://wiki.mozilla.org/WebAPI/WebPaymentProvider) is a website that runs inside a chrome window that is controlled by navigator.mozPay().

The JavaScript running on a payment provider must be able to access FxA, probably with code like this:

navigator.mozId.watch(
  wantIssuer: 'firefox-accounts',
  ...
);

Payment provider websites do not have permissions the same way packaged apps do. Typically, we expose privileged APIs to payment providers as properties of window.mozPaymentProvider (https://wiki.mozilla.org/WebAPI/WebPaymentProvider#API) but that may or may not make sense here.

Comment 1

[Chris Karlof [:ckarlof]]

Sam, this was identified as a FxA/Marketplace 2.0 blocker.

Comment 2

[Sam Penrose]

Given that currently we restrict to certified and privileged apps, I would say that yes we are blocked here.

Comment 3

[Ian Bicking (:ianbicking)]

It would seem hard to confirm that FxA fully satisfied this use case without a full integration test (even if manual).  While there are identified and known problems around permission, I can imagine other problems with the nested containers and windows.

Is there a workaround for 2.0?  Staying with Persona?  Using OAuth?

Comment 4

[Allen Short [:ashort]]

We can use the OAuth flow until this is available. However, this will mean requiring login every time a payment is done, which obviously is a regression from the Persona behaviour.

Comment 5

[Kumar McMillan [:kumar]]

Some people were confused about what this bug is asking for. Here's another summary:

- An app accesses FxA like this https://github.com/mozilla-b2g/gaia/blob/3a6bc02d3218185240847e433683ccef285188ad/apps/settings/js/findmydevice.js#L25
- The app needs to have this permission: https://github.com/mozilla-b2g/gaia/blob/3a6bc02d3218185240847e433683ccef285188ad/apps/settings/manifest.webapp#L36
- A payment provider is a webpage that runs inside a custom window (the Trusted UI)
- In the Trusted UI there is no concept of an app or its permissions. For example, any app can take in-app payments by working with the navigator.mozPay() API.
- How can a payment provider webpage within the Trusted UI access FxA? We need a platform change for this, maybe by explicitly granting a permission around here? http://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/payment.js#470

Comment 6

[Sam Penrose]

Kumar, thanks for the clarification and my apologies for being slow on the uptake that you expected to see a patch for this (I am "some people" :-)). It will be quite a challenge to get something like this landed for 2.0, even if it is The Right Thing To Do, which is not clear to me yet. The security review for 2.0 is based on the assumption that we have whitelisted apps which access FxA, and that they are at least privileged. Even enabling privileged apps required a late fire drill to fix a security issue, with a patch that was written quickly by the lead for one of the two privileged apps we envisioned supporting in 2.0, and the purpose of which is to force a password challenge when encountering a new RP (such as a new payment provider). We are also generally concerned about the stability of the Trusted UI, though perhaps issues there are orthogonal to how we solve this problem. Given the timeframe and the need for what feels like non-trivial security review, and the long-passed 2.0 string freeze, how should we best move forward? How do we weigh that against the Oauth repeated-challenge regression, noting that MP is starting with Oauth and that our team is going to explore (no promises!) switching to Oauth in the 2.2 time frame?

Comment 7

[Wil Clouser [:clouserw]]

Sam: Why do apps need to specifically request permission to use FxA?

Regarding our next steps - it sounds like we should talk about the best way to fix this and make a patch that we land/test on trunk, and then have the conversation about uplifting to 2.0.

There is some skepticism whether oauth will work here, but even so it would mean logging in every time.

Do you want to talk on video?

Comment 8

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Wil Clouser [:clouserw] from comment #7)
> Sam: Why do apps need to specifically request permission to use FxA?

We needed to add the permission because without this permission, any web page could silently read the users email address. See https://bugzilla.mozilla.org/show_bug.cgi?id=1028398

Fernando proposed an alternative to the permission in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1028398#c3

Perhaps this (or some combination or permissions for privileged apps, and prompting for web pages) might be a solution here? (especially if we can somehow restrict it to trusted UI?)

Comment 9

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Otherwise, another option maybe to whitelist URLs list as payment provider URLs based on the whitelist contained in the preference (dom.payment.provider.*). I think this would be OK if we could somehow guarantee that the URL was opened in trusted UI (but I am not sure how to do that).

Comment 10

[Sam Penrose]

(In reply to Paul Theriault [:pauljt] from comment #8)
> (In reply to Wil Clouser [:clouserw] from comment #7)
> > Sam: Why do apps need to specifically request permission to use FxA?
> 
> We needed to add the permission because without this permission, any web
> page could silently read the users email address. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1028398
> 
> Fernando proposed an alternative to the permission in this comment:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1028398#c3
> 
> Perhaps this (or some combination or permissions for privileged apps, and
> prompting for web pages) might be a solution here? (especially if we can
> somehow restrict it to trusted UI?)

The patch that was implemented throws up the password challenge the first time a given origin accesses FxA with privileged perms. I don't think there is a significantly different mozId()-based option for payments on the table, but if I am missing something please clarify.

Comment 11

[Sam Penrose]

(In reply to Paul Theriault [:pauljt] from comment #9)
> Otherwise, another option maybe to whitelist URLs list as payment provider
> URLs based on the whitelist contained in the preference
> (dom.payment.provider.*). I think this would be OK if we could somehow
> guarantee that the URL was opened in trusted UI (but I am not sure how to do
> that).

Do we know what attributes might hang off the trusted UI's window object indicating it as such? If we can get that far, we would know. I would suggest having a payments engineer start hacking ASAP, with me helping Gecko-side. It would be awesome if they could build from patches I sling at them. Meanwhile we need security to look at whatever we might be considering.

Comment 12

[Chris Karlof [:ckarlof]]

I'm assuming that what the payment provider does in the trusted UI is up to it?

Do payment providers other than mozilla/webpay rely on access to Persona/FxA for authentication?

Does mozilla/webpay trust marketplace? Would it be sufficient for marketplace to trigger authentication before it triggers the mozPay API and smuggle the user information in the signed mozpay JWT, perhaps in productData? Then webpay could rely on that (it's signed by marketplace presumably), rather than from the assertion?

Comment 13

[Kumar McMillan [:kumar]]

(In reply to Sam Penrose from comment #11)
> Do we know what attributes might hang off the trusted UI's window object
> indicating it as such? 

Yes, web pages within the trusted UI (only) get window.mozPaymentProvider. http://dxr.mozilla.org/mozilla-central/search?q=mozPaymentProvider&case=true&redirect=true

Comment 14

[Kumar McMillan [:kumar]]

(In reply to Chris Karlof [:ckarlof] from comment #12)
> Do payment providers other than mozilla/webpay rely on access to Persona/FxA
> for authentication?

No. Only Mozilla domains need FxA.

> 
> Does mozilla/webpay trust marketplace? Would it be sufficient for
> marketplace to trigger authentication before it triggers the mozPay API and
> smuggle the user information in the signed mozpay JWT, perhaps in
> productData? Then webpay could rely on that (it's signed by marketplace
> presumably), rather than from the assertion?

This wouldn't work because we also allow in-app payments from non-Marketplace apps. For example, Angry Birds could call navigator.mozPay() to open a payment flow in the Trusted UI without Marketplace having any direct involvement.

Comment 15

[Andy McKay]

(In reply to Kumar McMillan [:kumar] (needinfo for quickness) from comment #5)
> - How can a payment provider webpage within the Trusted UI access FxA? We
> need a platform change for this, maybe by explicitly granting a permission
> around here?
> http://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/payment.
> js#470

Just to be clear here, can we check its not the payment provider webpage (eg Bango) that has to access FxA. Rather its the mozilla hosted pages at the URL defined in the prefs (for example http://dxr.mozilla.org/mozilla-central/source/webapprt/prefs.js#72) that has to access FxA. Once the Mozilla hosted pages have access to the FxA information, it passes limited identity information onto the payment provider (eg Bango).

Comment 16

[[:fabrice] Fabrice Desré]

Attachment: untested wip

Untested, but the idea is to grant the firefox-accounts permission to payment providers when they are loaded in the trusted UI.

If someone could help conduct testing that would be great!

Comment 17

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I have a build with this patch applied, but I don't know how to actually get payments flow loaded. Can someone explain how to test this? 

Oddly, the persona flow in the marketplace app seems to load in the marketplace app, not in the system app, which was a little unexpected (i thought this used trusted UI as well, but I guess not).

Comment 18

[Kumar McMillan [:kumar]]

Oops. I meant to comment that I emailed Paul instructions on how to set up payments for local testing. If anyone else needs that, let me know.

Comment 19

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So testing this using the information provided by Kumar:

- On custom build with the WIP patch:  I get to enter pin code part, this works, but the payment fails after entering PIN code (seems to timeout while trying to retrieve transaction)
- On  the regular build, I get a payment cancelled error without leaving the pay alt app.

So from what I can tell the payment flow is getting my id with Fabrice’s patch (note: it gets my persona id, NOT Firefox Accounts id though…I assume that is expected.) Hard to tell without working end to end though.

Comment 20

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Attachment: Timeout error on patched device

Comment 21

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I attached logcat for the timeout on the patched device above.

Comment 22

[Fernando Jiménez Moreno [:ferjm]]

Sorry, I just saw this bug.

(In reply to Paul Theriault [:pauljt] from comment #19)
> 
> So from what I can tell the payment flow is getting my id with Fabrice’s
> patch (note: it gets my persona id, NOT Firefox Accounts id though…I assume
> that is expected.) Hard to tell without working end to end though.

How did you triggered the FxA flow? Did you specify the "wantIssuer": "firefox-accounts" parameter in the mozId.watch() call? Check [1]


(In reply to Paul Theriault [:pauljt] from comment #17)
> I have a build with this patch applied, but I don't know how to actually get
> payments flow loaded. Can someone explain how to test this? 
>

I know Kumar already emailed some instructions, but I'll write them also here just in case anyone else wants to try.

I guess the easiest way to test this is by writing a mock payment provider that can be a simple static HTML that makes the appropriate mozId calls. Once you have it, you'll need to tell mozPay to use this payment provider for a specific JWT type. To do that, you need to add an entry to your preferences like in [2] with the details of your mock payment provider. After that, you will need to create a JWT with the "typ" parameter set to the one that you specified for your mock payment provider in the preferences and call navigator.mozPay with this JWT from a test app. That should open the trusted UI embedding your mock payment provider.

> Oddly, the persona flow in the marketplace app seems to load in the
> marketplace app, not in the system app, which was a little unexpected (i
> thought this used trusted UI as well, but I guess not).

I don't understand this. The Persona flow is supposed to use the trusted UI.

[1] https://developer.mozilla.org/en-US/docs/Firefox-Accounts-on-FirefoxOS
[2] https://wiki.mozilla.org/WebAPI/WebPayment#Testing

Comment 23

[Fernando Jiménez Moreno [:ferjm]]

What is supposed to be the audience for the assertions requested by the payment provider via FxA? Are we specifying any audience or we just defer to the mozId implementation to set the origin of the payment provider as the audience?

Note that we only allow certified apps to specify an audience different than its origin [1].

[1] https://mxr.mozilla.org/mozilla-central/source/dom/identity/nsDOMIdentity.js#651

Comment 24

[Kumar McMillan [:kumar]]

Hey all, I put together a fake provider (as ferjm suggests) which will make it easier to test this patch. With this fake provider I can see ERROR_NOT_AUTHORIZED_FOR_FIREFOX_ACCOUNTS within Trusted UI which is what we want to solve so it can be used to test Fabrice's patch.

Instructions:

- Add these prefs to your device or Gaia build (put them in build/config/custom-prefs.js and rebuild the profile):

pref("dom.payment.provider.6.name", "fakepay");
pref("dom.payment.provider.6.description", "fakepay");
pref("dom.payment.provider.6.uri", "http://people.mozilla.org/~kmcmillan/fakepay/pay.html?req=");
pref("dom.payment.provider.6.type", "fakepay/payments/pay/v1");
pref("dom.payment.provider.6.requestMethod", "GET");

- Open this in a B2G browser: http://people.mozilla.org/~kmcmillan/fakepay/start.html (http://mzl.la/1rthClN)
- tap 'Start fake payment'
- Check the console

Fernando's point about the audience is a good one though. After we solve the permission error, how do we solve the audience error? What should the audience be set to?

Comment 25

[Kumar McMillan [:kumar]]

I think we figured out the audience question. We want to leave audience blank so that it will be derived from window.location in our case (which is our payment provider that gets the assertion).

Comment 26

[Kumar McMillan [:kumar]]

I forgot to mention that you may need this pref to see mozId errors:

pref("toolkit.identity.debug", true);

Comment 27

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Screenshot

Thanks Kumar and Fabrice!

I managed to test this patch and there are two main issues.

The first one is that we are requesting a silent assertion, which means that the fxa dialog won't be triggered even if we don't have a valid account. I didn't have time to debug it properly, but it should be easy to fix.

The other issue is that system dialogs are supposed to be shown on top the trusted UI, but they currently don't do that. See the attached screenshot.

Comment 28

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #27)
> The first one is that we are requesting a silent assertion, which means that
> the fxa dialog won't be triggered even if we don't have a valid account. I
> didn't have time to debug it properly, but it should be easy to fix.
> 

This is just because the fake provider is only doing .watch(). Doing .request() should solve it.

Comment 29

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/22084

This patch fixes the system dialog vs trusted UI issue for me.

Comment 30

[Chris Karlof [:ckarlof]]

> I think we figured out the audience question. We want to leave audience blank so that it will be derived from window.location in our case (which is our payment provider that gets the assertion).

Yeah. :) Overriding the audience is only available to certified apps, and even then it's an anti-pattern. It should always get the audience from the origin of the requester.

Comment 31

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8461007 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/22084

Not reading the whole comments but the patch looks sane.

Comment 32

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8461007 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/22084

Thanks Alive! I should have actually asked for r? instead of feedback.

Comment 33

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8460014 [details] [diff] [review]
untested wip

Review of attachment 8460014 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/payment/Payment.jsm
@@ +58,5 @@
>      } catch(e) {
>        this._debug = false;
>      }
> +
> +    this._debug = true;

This needs to go away in the final patch :)

@@ +64,5 @@
> +    let self = this;
> +    Services.obs.addObserver(function(aSubject, aTopic, aData) {
> +      self.registeredProviders = {};
> +      self.registerPaymentProviders();
> +    }, "webapps-registry-ready", /* ownsWeak */ false);

Not a big deal, but we are already lazy loading the payment providers at https://mxr.mozilla.org/mozilla-central/source/dom/payment/Payment.jsm#76

In any case, if there is a good reason for moving the registration step here:
* we should remove the "webapps-registry-ready" observer
* you can use a fat arrow function and get rid of "self".

@@ +205,5 @@
>          nums.push(match[1]);
>        }
>      }
>  
> +    let appsService = Cc["@mozilla.org/AppsService;1"]

This block should probably be b2g only code.

@@ +235,5 @@
>            description: branch.getCharPref("description"),
>            requestMethod: branch.getCharPref("requestMethod")
>          };
> +
> +        // Let this payment provider access the firefox-accounts API when

Also B2G only

Comment 34

[[:fabrice] Fabrice Desré]

Attachment: gecko patch v2

Addressing comments. I don't remember any good reason for doing the registration in the webapps-ready observer, so I just removed that part. Doing a bit of testing with this patch would be good though.

Comment 35

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8462678 [details] [diff] [review]
gecko patch v2

Thanks Fabrice!

Comment 36

[Fernando Jiménez Moreno [:ferjm]]

https://github.com/mozilla-b2g/gaia/commit/3357c45e793bfca7648d215f378eb47e4e97aa23

Comment 37

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/b2g-inbound/rev/a04107c24084

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Backed out for Windows B2G bustage.
https://hg.mozilla.org/integration/b2g-inbound/rev/0698e2cbadf9

https://tbpl.mozilla.org/php/getParsedLog.php?id=44729640&full=1&branch=b2g-inbound

Comment 39

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/b2g-inbound/rev/f8306fd76d3f

Comment 40

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f8306fd76d3f

Comment 41

[Kumar McMillan [:kumar]]

Hey Fernando, I tried out your patch using desktop B2G with the latest m-c and gaia. I did not try flashing a device. Everything seems to work ok but when I log out of Firefox Accounts and retry the flow, the buttons on the bottom are cut off. Is this also happening on device or only on desktop B2G?

Example of starting an FxA flow from the Trusted UI:
http://cl.ly/image/3j3l1U3M0V0R
http://cl.ly/image/3l2V1U2w0c2G

Comment 42

[Sam Penrose]

Kumar the button cut-off is not related to this patch; see:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1038980

and various others.

Comment 44

[Kumar McMillan [:kumar]]

ok. The layout is slightly different in the Trusted UI so I commented on that bug to make sure our scenario is accounted for.

As for FxA within the Trusted UI, I can verify that it is working now. Thanks ferjm!