Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

proposal: replace navigator.mozPay() with primitives

135 views
Skip to first unread message

Kumar McMillan

unread,
Sep 4, 2013, 5:03:40 PM9/4/13
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, Andreas Gal, Mounir Lamouri, Jonas Sicking, Fernando Jiménez Moreno
Hi all,

After gaining much experience using navigator.mozPay() (https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments it feels like the API may not be useful as a generic API for the broader web. I'd like to propose deprecating navigator.mozPay() and replacing it with lower-level primitives that payment providers can use directly. Thoughts and feedback on this?

The problem: mozPay() adds some features for carrier billing but does so by imposing a rigid end to end transaction flow. Not all payment providers need to adopt this end to end flow and many providers already have their own end to end flow. Awkwardly, mozPay also has a whitelist of who can use it which means Mozilla (or whoever builds B2G) has to grant access to each provider.

mozPay comes in two parts:

* Developers use navigator.mozPay() to conduct a transaction and disperse digital goods within their app. This is roughly the equivalent of doing window.open() and using postMessage to communicate with the new window.
* Whitelisted payment providers (such as Firefox Marketplace) host their custom payment flow in an iframe controlled by the chrome layer of mozPay. That iframe has a special global called window.mozPaymentProvider which is defined here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider

I'd like to propose deprecating mozPay and instead figuring out a way to securely expose mozPaymentProvider since it exposes primitives that websites can use to implement mobile payments themselves. This would be a big win for Firefox OS: anyone on the web could process payments just the same as Mozilla does.

What are the exact primitives we need to expose?

1. To optimize carrier billing authentication mozPaymentProvider provides an observeSilentSms method. This allows the payment provider to exchange a challenge/response via SMS to get an unspoofable link to the user's phone bill. We could expose this to all web content but we couldn't allow arbitrary numbers if it were publicly accessible. We would have to whitelist the short codes that can be used in this function (a short code incurs no cost to the user; it is paid for by the payment authority). We might also need to prevent DOS'ing a short code? There won't be too many of these to whitelist. Mozilla could also host a web service for the whitelist which would make it easy to maintain.

This covers the use case we have for Mozilla's carrier billing and it is a somewhat typical pattern. FaceTime registration works via silent SMS: http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration

(Note that some operators support HTTP header injection to link to a user's phone bill. In that case, the web doesn't need a new API; you can use HTTP redirects.)

2. Payment providers need to know the user's network. Use cases: the provider may need to enable/disable certain regions (e.g. when in pre-production) and the provider needs to know which whitelisted short code to use for silent SMS. This is currently available as MCC/MNC on mozPaymentProvider. What is the danger of exposing this to all web content? Do we need to prompt the user like geolocation?

3. Since carrier billing is tied to SIMs the payment provider must know when a SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed. Multiple SIMs should be supported too. Mozilla's payment provider persists carrier billing identity in a cookie (to avoid repeat authentication) so we need to know when to delete / recreate that cookie. Currently mozPaymentProvider exposes an array of ICCs that can be used for this so we'd want to expose this to all web content. A provider doesn't need to know the *exact* ICCs, it could use obfuscated values. Can we safely expose these data/events separately to web content?


That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().


Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.

I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.

Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).

As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.

On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.

Thanks for reading. Thoughts?

-Kumar

Kumar McMillan

unread,
Sep 4, 2013, 5:23:11 PM9/4/13
to Andy McKay, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal

On Sep 4, 2013, at 4:18 PM, Andy McKay <amc...@mozilla.com> wrote:

>
> On 2013-09-04, at 2:03 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:
>> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona
>
> If we think the TrustedUI is useful, would it make sense to make that be an API call as well, navigator.trustedUI, that starts the trusted UI. It would have to be a whitelist of add domains that can start that flow off, similar to how it is now.

That is what I proposed as a special flag to window.open(). Why make a new navigator.trustedUI method? Anyway, I think the Trusted UI is still evolving will probably take a new shape once some work has gone into making it more trustworthy.

Ehsan Akhgari

unread,
Sep 4, 2013, 7:04:50 PM9/4/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal
On 2013-09-04 5:03 PM, Kumar McMillan wrote:
> Hi all,
>
> After gaining much experience using navigator.mozPay() (https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments it feels like the API may not be useful as a generic API for the broader web. I'd like to propose deprecating navigator.mozPay() and replacing it with lower-level primitives that payment providers can use directly. Thoughts and feedback on this?
>
> The problem: mozPay() adds some features for carrier billing but does so by imposing a rigid end to end transaction flow. Not all payment providers need to adopt this end to end flow and many providers already have their own end to end flow. Awkwardly, mozPay also has a whitelist of who can use it which means Mozilla (or whoever builds B2G) has to grant access to each provider.
>
> mozPay comes in two parts:
>
> * Developers use navigator.mozPay() to conduct a transaction and disperse digital goods within their app. This is roughly the equivalent of doing window.open() and using postMessage to communicate with the new window.
> * Whitelisted payment providers (such as Firefox Marketplace) host their custom payment flow in an iframe controlled by the chrome layer of mozPay. That iframe has a special global called window.mozPaymentProvider which is defined here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider
>
> I'd like to propose deprecating mozPay and instead figuring out a way to securely expose mozPaymentProvider since it exposes primitives that websites can use to implement mobile payments themselves. This would be a big win for Firefox OS: anyone on the web could process payments just the same as Mozilla does.
>
> What are the exact primitives we need to expose?
>
> 1. To optimize carrier billing authentication mozPaymentProvider provides an observeSilentSms method. This allows the payment provider to exchange a challenge/response via SMS to get an unspoofable link to the user's phone bill. We could expose this to all web content but we couldn't allow arbitrary numbers if it were publicly accessible. We would have to whitelist the short codes that can be used in this function (a short code incurs no cost to the user; it is paid for by the payment authority). We might also need to prevent DOS'ing a short code? There won't be too many of these to whitelist. Mozilla could also host a web service for the whitelist which would make it easy to maintain.
>
> This covers the use case we have for Mozilla's carrier billing and it is a somewhat typical pattern. FaceTime registration works via silent SMS: http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration
>
> (Note that some operators support HTTP header injection to link to a user's phone bill. In that case, the web doesn't need a new API; you can use HTTP redirects.)

Would that not tie us down to the payment providers who use one of the
white-listed numbers?

> 2. Payment providers need to know the user's network. Use cases: the provider may need to enable/disable certain regions (e.g. when in pre-production) and the provider needs to know which whitelisted short code to use for silent SMS. This is currently available as MCC/MNC on mozPaymentProvider. What is the danger of exposing this to all web content? Do we need to prompt the user like geolocation?

Can't they just use the client's IP address to obtain that information?

> 3. Since carrier billing is tied to SIMs the payment provider must know when a SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed. Multiple SIMs should be supported too. Mozilla's payment provider persists carrier billing identity in a cookie (to avoid repeat authentication) so we need to know when to delete / recreate that cookie. Currently mozPaymentProvider exposes an array of ICCs that can be used for this so we'd want to expose this to all web content. A provider doesn't need to know the *exact* ICCs, it could use obfuscated values. Can we safely expose these data/events separately to web content?

Wouldn't that raise fingerprinting concerns? I guess that depends on
what kind of obfuscation you had in mind though.

> That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().
>
>
> Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.
>
> I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.
>
> Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).
>
> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.

Why is mozTrusted needed?

> On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.

I never understood what the point of requestAutocomplete was. It seems
to me like Google is pushing this so that they can integrate Google
Wallet in Chrome's UI, but if that is not a requirement for us, then why
wouldn't we just let the UA provide the autocomplete service as it does
today?

Cheers,
Ehsan

Kumar McMillan

unread,
Sep 5, 2013, 12:21:08 PM9/5/13
to Ehsan Akhgari, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal

On Sep 4, 2013, at 6:04 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> On 2013-09-04 5:03 PM, Kumar McMillan wrote:
>> Hi all,
>>
>> After gaining much experience using navigator.mozPay() (https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments it feels like the API may not be useful as a generic API for the broader web. I'd like to propose deprecating navigator.mozPay() and replacing it with lower-level primitives that payment providers can use directly. Thoughts and feedback on this?
>>
>> The problem: mozPay() adds some features for carrier billing but does so by imposing a rigid end to end transaction flow. Not all payment providers need to adopt this end to end flow and many providers already have their own end to end flow. Awkwardly, mozPay also has a whitelist of who can use it which means Mozilla (or whoever builds B2G) has to grant access to each provider.
>>
>> mozPay comes in two parts:
>>
>> * Developers use navigator.mozPay() to conduct a transaction and disperse digital goods within their app. This is roughly the equivalent of doing window.open() and using postMessage to communicate with the new window.
>> * Whitelisted payment providers (such as Firefox Marketplace) host their custom payment flow in an iframe controlled by the chrome layer of mozPay. That iframe has a special global called window.mozPaymentProvider which is defined here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider
>>
>> I'd like to propose deprecating mozPay and instead figuring out a way to securely expose mozPaymentProvider since it exposes primitives that websites can use to implement mobile payments themselves. This would be a big win for Firefox OS: anyone on the web could process payments just the same as Mozilla does.
>>
>> What are the exact primitives we need to expose?
>>
>> 1. To optimize carrier billing authentication mozPaymentProvider provides an observeSilentSms method. This allows the payment provider to exchange a challenge/response via SMS to get an unspoofable link to the user's phone bill. We could expose this to all web content but we couldn't allow arbitrary numbers if it were publicly accessible. We would have to whitelist the short codes that can be used in this function (a short code incurs no cost to the user; it is paid for by the payment authority). We might also need to prevent DOS'ing a short code? There won't be too many of these to whitelist. Mozilla could also host a web service for the whitelist which would make it easy to maintain.
>>
>> This covers the use case we have for Mozilla's carrier billing and it is a somewhat typical pattern. FaceTime registration works via silent SMS: http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration
>>
>> (Note that some operators support HTTP header injection to link to a user's phone bill. In that case, the web doesn't need a new API; you can use HTTP redirects.)
>
> Would that not tie us down to the payment providers who use one of the white-listed numbers?

I suppose it would, yes. However, the current mozPay already ties us down to white-listed payment providers, only more brutally. If we expose observeSilentSms to all web content, we need to protect it from abuse somehow. It could be abused by web content entering a number that charges the user money repeatedly in the background without anyone knowing it. Maybe someone has another idea for protecting it?

>
>> 2. Payment providers need to know the user's network. Use cases: the provider may need to enable/disable certain regions (e.g. when in pre-production) and the provider needs to know which whitelisted short code to use for silent SMS. This is currently available as MCC/MNC on mozPaymentProvider. What is the danger of exposing this to all web content? Do we need to prompt the user like geolocation?
>
> Can't they just use the client's IP address to obtain that information?

I've been told that IP address is not reliable enough to detect region and network. There seems to be proxying scenarios that create a lot of edge cases. Anyway, the fact that IP addresses are already exposed on the web makes me think that exposing MCC/MNC is not such a big deal.

>
>> 3. Since carrier billing is tied to SIMs the payment provider must know when a SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed. Multiple SIMs should be supported too. Mozilla's payment provider persists carrier billing identity in a cookie (to avoid repeat authentication) so we need to know when to delete / recreate that cookie. Currently mozPaymentProvider exposes an array of ICCs that can be used for this so we'd want to expose this to all web content. A provider doesn't need to know the *exact* ICCs, it could use obfuscated values. Can we safely expose these data/events separately to web content?
>
> Wouldn't that raise fingerprinting concerns? I guess that depends on what kind of obfuscation you had in mind though.

The main use case here is detecting when one SIM is removed and another one inserted. That's all we need to solve for payments -- there are probably a couple different ways to do it safely without enabling fingerprinting. I also thought of window.addEventListener('moz-sim-changed', ...) or something.

>
>> That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().
>>
>>
>> Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.
>>
>> I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.
>>
>> Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).
>>
>> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.
>
> Why is mozTrusted needed?

When a developer calls navigator.mozPay(), the chrome layer opens a Trusted UI which is a special window that makes it more secure to enter sensitive payment details. You can see Gaia's interface for it here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/trusted_ui.js If we were to deprecate mozPay, web content would need a way to retain this functionality. The Trusted UI is not very well understood (yet) so the easiest way to retain this functionality would be to continue whitelisting Marketplace and Persona as the only domains who are allowed to open a Trusted UI. My idea was to let web content do window.open(url, {mozTrusted: true}) to open a Trusted UI which decouples it from mozPay. Only whitelisted domains would be allowed to do that; any other URLs would trigger an error. In the future, the Trusted UI might evolve into something that all web content can use if we can figure out how to trust content :)

>
>> On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.
>
> I never understood what the point of requestAutocomplete was.

The point of it is to enable users to autocomplete forms that they are asked to fill out regularly. Imagine that you are using your mobile phone for the first time and you want to pay for something on a web app. The app might ask you to enter your credit card number, expiration, and CVV. This is cumbersome to type on a mobile device. Now, imagine that another unrelated app asks you to pay for something the next day. You have to enter you credit card number again! This would repeat infinitely for all unique payment providers on the web that you encounter. With request autocomplete, you would only need to enter your credit card number once -- you could auto-complete it the next time. Everyone on the web wins :)

> It seems to me like Google is pushing this so that they can integrate Google Wallet in Chrome's UI, but if that is not a requirement for us, then why wouldn't we just let the UA provide the autocomplete service as it does today?

In the context of Firefox OS, request autocomplete has nothing to do with Google Wallet. It would improve the user experience around payments and other cumbersome form entry.

-Kumar

>
> Cheers,
> Ehsan
>

Gervase Markham

unread,
Sep 6, 2013, 12:06:43 PM9/6/13
to Kumar McMillan
On 04/09/13 22:03, Kumar McMillan wrote:
> 1. To optimize carrier billing authentication mozPaymentProvider
> provides an observeSilentSms method. This allows the payment provider
> to exchange a challenge/response via SMS to get an unspoofable link
> to the user's phone bill.

At what point did they decide SMS was unspoofable? :-|

> 2. Payment providers need to know the user's network. Use cases: the
> provider may need to enable/disable certain regions (e.g. when in
> pre-production) and the provider needs to know which whitelisted
> short code to use for silent SMS. This is currently available as
> MCC/MNC on mozPaymentProvider. What is the danger of exposing this to
> all web content? Do we need to prompt the user like geolocation?

MCC/MNC locates the user, so we would need to prompt. Which would both
be confusing ("why do they need to know where I am to sell me
something?") and mean that you'd lose the "silent" aspect of it.

> 3. Since carrier billing is tied to SIMs the payment provider must
> know when a SIM is/isn't present, when a new SIM is inserted, and
> when a SIM is removed. Multiple SIMs should be supported too.
> Mozilla's payment provider persists carrier billing identity in a
> cookie (to avoid repeat authentication) so we need to know when to
> delete / recreate that cookie. Currently mozPaymentProvider exposes
> an array of ICCs that can be used for this so we'd want to expose
> this to all web content.

I'm not a privacy expert, and you'd need to ask one, but this sounds
problematic as well. :-(

Can we find an API "level" between "one function call" and "expose all
this info" which enables more use cases?

Gerv

Kumar McMillan

unread,
Sep 6, 2013, 1:02:22 PM9/6/13
to Gervase Markham, mozilla-d...@lists.mozilla.org

On Sep 6, 2013, at 11:06 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 04/09/13 22:03, Kumar McMillan wrote:
>> 1. To optimize carrier billing authentication mozPaymentProvider
>> provides an observeSilentSms method. This allows the payment provider
>> to exchange a challenge/response via SMS to get an unspoofable link
>> to the user's phone bill.
>
> At what point did they decide SMS was unspoofable? :-|

It's unspoofable because there are two SMS's, one going from the device to the short code service and one returning from the service to the device. The payment provider initiates this on a web server so it can use a secret code (scraped from returning SMS) to authenticate the two-way communication.

>
>> 2. Payment providers need to know the user's network. Use cases: the
>> provider may need to enable/disable certain regions (e.g. when in
>> pre-production) and the provider needs to know which whitelisted
>> short code to use for silent SMS. This is currently available as
>> MCC/MNC on mozPaymentProvider. What is the danger of exposing this to
>> all web content? Do we need to prompt the user like geolocation?
>
> MCC/MNC locates the user, so we would need to prompt. Which would both
> be confusing ("why do they need to know where I am to sell me
> something?") and mean that you'd lose the "silent" aspect of it.

If we must prompt for MCC/MNC access to do silent SMS then it would still be better than a manual SMS authentication which looks like this:

* the web page asks the user to type in their mobile number
* the web server sends that user an SMS with a secret code
* user navigates to SMS inbox, memorizes secret code
* user navigates back to the payment screen, types in secret code

>
>> 3. Since carrier billing is tied to SIMs the payment provider must
>> know when a SIM is/isn't present, when a new SIM is inserted, and
>> when a SIM is removed. Multiple SIMs should be supported too.
>> Mozilla's payment provider persists carrier billing identity in a
>> cookie (to avoid repeat authentication) so we need to know when to
>> delete / recreate that cookie. Currently mozPaymentProvider exposes
>> an array of ICCs that can be used for this so we'd want to expose
>> this to all web content.
>
> I'm not a privacy expert, and you'd need to ask one, but this sounds
> problematic as well. :-(
>
> Can we find an API "level" between "one function call" and "expose all
> this info" which enables more use cases?

I hope so!

>
> Gerv

Robert Kaiser

unread,
Sep 7, 2013, 3:40:06 PM9/7/13
to mozilla-d...@lists.mozilla.org
Kumar McMillan schrieb:
> * user navigates to SMS inbox, memorizes secret code

Memorizing pone-time secret codes sounds awful to me. :(

Robert Kaiser

Kumar McMillan

unread,
Sep 17, 2013, 4:05:11 PM9/17/13
to dev-w...@lists.mozilla.org, dev-w...@lists.mozilla.org, Andreas Gal, Mounir Lamouri, Jonas Sicking, Fernando Jiménez Moreno
TLDR; navigator.mozPay() is too prescriptive, how about we introduce lower level API primitives for mobile payments? Any feedback on this proposed change of direction?

I've received feedback only about the new API ideas (thank you) but they were just sketches; the API details need more thought. If others agree that the direction is good, let's dive in and pivot toward a payment API that the web will benefit from.

-Kumar

On Sep 4, 2013, at 4:03 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:

> Hi all,
>
> After gaining much experience using navigator.mozPay() (https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments it feels like the API may not be useful as a generic API for the broader web. I'd like to propose deprecating navigator.mozPay() and replacing it with lower-level primitives that payment providers can use directly. Thoughts and feedback on this?
>
> The problem: mozPay() adds some features for carrier billing but does so by imposing a rigid end to end transaction flow. Not all payment providers need to adopt this end to end flow and many providers already have their own end to end flow. Awkwardly, mozPay also has a whitelist of who can use it which means Mozilla (or whoever builds B2G) has to grant access to each provider.
>
> mozPay comes in two parts:
>
> * Developers use navigator.mozPay() to conduct a transaction and disperse digital goods within their app. This is roughly the equivalent of doing window.open() and using postMessage to communicate with the new window.
> * Whitelisted payment providers (such as Firefox Marketplace) host their custom payment flow in an iframe controlled by the chrome layer of mozPay. That iframe has a special global called window.mozPaymentProvider which is defined here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider
>
> I'd like to propose deprecating mozPay and instead figuring out a way to securely expose mozPaymentProvider since it exposes primitives that websites can use to implement mobile payments themselves. This would be a big win for Firefox OS: anyone on the web could process payments just the same as Mozilla does.
>
> What are the exact primitives we need to expose?
>
> 1. To optimize carrier billing authentication mozPaymentProvider provides an observeSilentSms method. This allows the payment provider to exchange a challenge/response via SMS to get an unspoofable link to the user's phone bill. We could expose this to all web content but we couldn't allow arbitrary numbers if it were publicly accessible. We would have to whitelist the short codes that can be used in this function (a short code incurs no cost to the user; it is paid for by the payment authority). We might also need to prevent DOS'ing a short code? There won't be too many of these to whitelist. Mozilla could also host a web service for the whitelist which would make it easy to maintain.
>
> This covers the use case we have for Mozilla's carrier billing and it is a somewhat typical pattern. FaceTime registration works via silent SMS: http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration
>
> (Note that some operators support HTTP header injection to link to a user's phone bill. In that case, the web doesn't need a new API; you can use HTTP redirects.)
>
> 2. Payment providers need to know the user's network. Use cases: the provider may need to enable/disable certain regions (e.g. when in pre-production) and the provider needs to know which whitelisted short code to use for silent SMS. This is currently available as MCC/MNC on mozPaymentProvider. What is the danger of exposing this to all web content? Do we need to prompt the user like geolocation?
>
> 3. Since carrier billing is tied to SIMs the payment provider must know when a SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed. Multiple SIMs should be supported too. Mozilla's payment provider persists carrier billing identity in a cookie (to avoid repeat authentication) so we need to know when to delete / recreate that cookie. Currently mozPaymentProvider exposes an array of ICCs that can be used for this so we'd want to expose this to all web content. A provider doesn't need to know the *exact* ICCs, it could use obfuscated values. Can we safely expose these data/events separately to web content?
>
>
> That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().
>
>
> Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.
>
> I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.
>
> Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).
>
> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.
>
> On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.
>
> Thanks for reading. Thoughts?
>
> -Kumar
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

Gervase Markham

unread,
Sep 18, 2013, 6:09:32 AM9/18/13
to Kumar McMillan, Andreas Gal, Mounir Lamouri, Jonas Sicking, Fernando Jiménez Moreno
On 17/09/13 21:05, Kumar McMillan wrote:
> I've received feedback only about the new API ideas (thank you) but
> they were just sketches; the API details need more thought. If others
> agree that the direction is good, let's dive in and pivot toward a
> payment API that the web will benefit from.

I strongly think that any changes here need to be done from the very
beginning in consultation with the Privacy team; I fear that your plans
to expose certain location, SIM info and other values to be web-facing
will be showstoppers. So check that out before doing a ton of work.

Gerv

Kumar McMillan

unread,
Sep 18, 2013, 11:57:51 AM9/18/13
to Gervase Markham, Jonas Sicking, Andreas Gal, Mounir Lamouri, mozilla-d...@lists.mozilla.org, Fernando Jiménez Moreno

On Sep 18, 2013, at 5:09 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 17/09/13 21:05, Kumar McMillan wrote:
>> I've received feedback only about the new API ideas (thank you) but
>> they were just sketches; the API details need more thought. If others
>> agree that the direction is good, let's dive in and pivot toward a
>> payment API that the web will benefit from.
>
> I strongly think that any changes here need to be done from the very
> beginning in consultation with the Privacy team; I fear that your plans
> to expose certain location, SIM info and other values to be web-facing
> will be showstoppers. So check that out before doing a ton of work.

I understand that there are some security and privacy issues to work out but letting users grant permission to this data seems fine to me; that's how geolocation works. With some effort, I think we can design the right API.

What is the alternative? Restrict all the payment features for Mozilla's use only? That's how it works in the current mozPay API -- Mozilla is the only one whitelisted to use it. Historically, locking other players out of platform features has never worked on the web (e.g. Microsoft, etc). It's an open web and anyone should be able to do carrier billing in Firefox OS, not just Mozilla.

Kumar

Ehsan Akhgari

unread,
Sep 18, 2013, 12:22:46 PM9/18/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal
On 2013-09-05 12:21 PM, Kumar McMillan wrote:
>
> On Sep 4, 2013, at 6:04 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>
>> On 2013-09-04 5:03 PM, Kumar McMillan wrote:
>>> Hi all,
>>>
>>> After gaining much experience using navigator.mozPay() (https://wiki.mozilla.org/WebAPI/WebPayment) to implement Firefox OS payments it feels like the API may not be useful as a generic API for the broader web. I'd like to propose deprecating navigator.mozPay() and replacing it with lower-level primitives that payment providers can use directly. Thoughts and feedback on this?
>>>
>>> The problem: mozPay() adds some features for carrier billing but does so by imposing a rigid end to end transaction flow. Not all payment providers need to adopt this end to end flow and many providers already have their own end to end flow. Awkwardly, mozPay also has a whitelist of who can use it which means Mozilla (or whoever builds B2G) has to grant access to each provider.
>>>
>>> mozPay comes in two parts:
>>>
>>> * Developers use navigator.mozPay() to conduct a transaction and disperse digital goods within their app. This is roughly the equivalent of doing window.open() and using postMessage to communicate with the new window.
>>> * Whitelisted payment providers (such as Firefox Marketplace) host their custom payment flow in an iframe controlled by the chrome layer of mozPay. That iframe has a special global called window.mozPaymentProvider which is defined here: https://wiki.mozilla.org/WebAPI/WebPaymentProvider
>>>
>>> I'd like to propose deprecating mozPay and instead figuring out a way to securely expose mozPaymentProvider since it exposes primitives that websites can use to implement mobile payments themselves. This would be a big win for Firefox OS: anyone on the web could process payments just the same as Mozilla does.
>>>
>>> What are the exact primitives we need to expose?
>>>
>>> 1. To optimize carrier billing authentication mozPaymentProvider provides an observeSilentSms method. This allows the payment provider to exchange a challenge/response via SMS to get an unspoofable link to the user's phone bill. We could expose this to all web content but we couldn't allow arbitrary numbers if it were publicly accessible. We would have to whitelist the short codes that can be used in this function (a short code incurs no cost to the user; it is paid for by the payment authority). We might also need to prevent DOS'ing a short code? There won't be too many of these to whitelist. Mozilla could also host a web service for the whitelist which would make it easy to maintain.
>>>
>>> This covers the use case we have for Mozilla's carrier billing and it is a somewhat typical pattern. FaceTime registration works via silent SMS: http://theiphonewiki.com/wiki/FaceTime#FaceTime_Activation_.2F_Registration
>>>
>>> (Note that some operators support HTTP header injection to link to a user's phone bill. In that case, the web doesn't need a new API; you can use HTTP redirects.)
>>
>> Would that not tie us down to the payment providers who use one of the white-listed numbers?
>
> I suppose it would, yes. However, the current mozPay already ties us down to white-listed payment providers, only more brutally. If we expose observeSilentSms to all web content, we need to protect it from abuse somehow. It could be abused by web content entering a number that charges the user money repeatedly in the background without anyone knowing it. Maybe someone has another idea for protecting it?

Fair enough. Perhaps a white-list of this kind is not very bad after all.

>>> 2. Payment providers need to know the user's network. Use cases: the provider may need to enable/disable certain regions (e.g. when in pre-production) and the provider needs to know which whitelisted short code to use for silent SMS. This is currently available as MCC/MNC on mozPaymentProvider. What is the danger of exposing this to all web content? Do we need to prompt the user like geolocation?
>>
>> Can't they just use the client's IP address to obtain that information?
>
> I've been told that IP address is not reliable enough to detect region and network. There seems to be proxying scenarios that create a lot of edge cases. Anyway, the fact that IP addresses are already exposed on the web makes me think that exposing MCC/MNC is not such a big deal.

Yeah, in addition to that the IP address is not useful if you're
roaming, or are connected to wifi, etc.

>>> 3. Since carrier billing is tied to SIMs the payment provider must know when a SIM is/isn't present, when a new SIM is inserted, and when a SIM is removed. Multiple SIMs should be supported too. Mozilla's payment provider persists carrier billing identity in a cookie (to avoid repeat authentication) so we need to know when to delete / recreate that cookie. Currently mozPaymentProvider exposes an array of ICCs that can be used for this so we'd want to expose this to all web content. A provider doesn't need to know the *exact* ICCs, it could use obfuscated values. Can we safely expose these data/events separately to web content?
>>
>> Wouldn't that raise fingerprinting concerns? I guess that depends on what kind of obfuscation you had in mind though.
>
> The main use case here is detecting when one SIM is removed and another one inserted. That's all we need to solve for payments -- there are probably a couple different ways to do it safely without enabling fingerprinting. I also thought of window.addEventListener('moz-sim-changed', ...) or something.

Can we just expose this information to content loaded in the trusted UI?

>>> That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().
>>>
>>>
>>> Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.
>>>
>>> I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.
>>>
>>> Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).
>>>
>>> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.
>>
>> Why is mozTrusted needed?
>
> When a developer calls navigator.mozPay(), the chrome layer opens a Trusted UI which is a special window that makes it more secure to enter sensitive payment details. You can see Gaia's interface for it here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/trusted_ui.js If we were to deprecate mozPay, web content would need a way to retain this functionality. The Trusted UI is not very well understood (yet) so the easiest way to retain this functionality would be to continue whitelisting Marketplace and Persona as the only domains who are allowed to open a Trusted UI. My idea was to let web content do window.open(url, {mozTrusted: true}) to open a Trusted UI which decouples it from mozPay. Only whitelisted domains would be allowed to do that; any other URLs would trigger an error. In the future, the Trusted UI might evolve into something that all web content can use if we can figure out how to trust content :)

I see, thanks! FWIW window.open already has a features parameter which
we can extend for this purpose.

>>> On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.
>>
>> I never understood what the point of requestAutocomplete was.
>
> The point of it is to enable users to autocomplete forms that they are asked to fill out regularly. Imagine that you are using your mobile phone for the first time and you want to pay for something on a web app. The app might ask you to enter your credit card number, expiration, and CVV. This is cumbersome to type on a mobile device. Now, imagine that another unrelated app asks you to pay for something the next day. You have to enter you credit card number again! This would repeat infinitely for all unique payment providers on the web that you encounter. With request autocomplete, you would only need to enter your credit card number once -- you could auto-complete it the next time. Everyone on the web wins :)

Actually, the auto-complete part can still be done by the UA using the
autocomplete content attribute. When talking to Jonas about this last
week, he mentioned that the use case for requestAutocomplete is for the
browser to do smart things such as generate one-time CC numbers, etc.
It also allows the UA to prompt for a PIN code for instance which is
used to encrypt the stored CC number. These use cases are not evident
from the proposed spec at all, but I guess it makes sense.

>> It seems to me like Google is pushing this so that they can integrate Google Wallet in Chrome's UI, but if that is not a requirement for us, then why wouldn't we just let the UA provide the autocomplete service as it does today?
>
> In the context of Firefox OS, request autocomplete has nothing to do with Google Wallet. It would improve the user experience around payments and other cumbersome form entry.

I think if we decide to adopt the one-time CC number generation, that
part is done through Google Wallet (or perhaps other similar services).
But we don't necessarily need to figure out that part for now.

Cheers,
Ehsan

Kumar McMillan

unread,
Sep 18, 2013, 12:37:42 PM9/18/13
to Ehsan Akhgari, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal
It is currently exposed *only* in the trusted UI. My proposal is to allow other non-whitelisted parties on the web to access payment features outside of the trusted UI. I'm not proposing to un-whitelist the trusted UI because that's a separate issue that is harder to solve IMO. Baby steps + iteration.

>
>>>> That's it! These are the only primitives in mozPaymentProvider that we need to expose to web content if we want to deprecate mozPay().
>>>>
>>>>
>>>> Also, we've heard from partners that they want to access the Secure Element present on UICC SIMs. This primitive will enable them to set up carrier billing easier -- an API is in the works for NFC related needs.
>>>>
>>>> I mentioned that mozPay is roughly the equivalent of window.open() and postMessage. The way I envision apps doing payments is by including a JavaScript file in their app built by the payment provider. For example, an app would include a JS file to do Stripe payments (like they do already). If Stripe were to support carrier billing in addition to credit cards, it would benefit from access to the mozPaymentProvider data above.
>>>>
>>>> Exposing low level payment functionality to the app (or any web content) is a paradigm shift from mozPay. The *app* would be managing a new payment window instead of how mozPay's innards currently manage the new window. However, this is pretty standard practice on today's web (PayPal, Google Wallet, Stripe, etc, all work by injecting javascript into web pages).
>>>>
>>>> As a consequence of deprecating mozPay() Firefox Marketplace will need something like window.open(url, {mozTrusted: true}). This flag could be restricted to whitelisted domains; it would open the current trusted UI which is used by Firefox Marketplace and Persona. This would *not* be meant as a fix or evolution to the current trusted UI but as a way for Mozilla to transition out of mozPay(). Making the trusted UI more flexible is a separate ongoing discussion.
>>>
>>> Why is mozTrusted needed?
>>
>> When a developer calls navigator.mozPay(), the chrome layer opens a Trusted UI which is a special window that makes it more secure to enter sensitive payment details. You can see Gaia's interface for it here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/trusted_ui.js If we were to deprecate mozPay, web content would need a way to retain this functionality. The Trusted UI is not very well understood (yet) so the easiest way to retain this functionality would be to continue whitelisting Marketplace and Persona as the only domains who are allowed to open a Trusted UI. My idea was to let web content do window.open(url, {mozTrusted: true}) to open a Trusted UI which decouples it from mozPay. Only whitelisted domains would be allowed to do that; any other URLs would trigger an error. In the future, the Trusted UI might evolve into something that all web content can use if we can figure out how to trust content :)
>
> I see, thanks! FWIW window.open already has a features parameter which we can extend for this purpose.
>
>>>> On a separate but related note, Request Autocomplete (http://www.chromium.org/developers/using-requestautocomplete) would add additional benefit to users who make payments on mobile. For example, typing a credit card on mobile is painful.
>>>
>>> I never understood what the point of requestAutocomplete was.
>>
>> The point of it is to enable users to autocomplete forms that they are asked to fill out regularly. Imagine that you are using your mobile phone for the first time and you want to pay for something on a web app. The app might ask you to enter your credit card number, expiration, and CVV. This is cumbersome to type on a mobile device. Now, imagine that another unrelated app asks you to pay for something the next day. You have to enter you credit card number again! This would repeat infinitely for all unique payment providers on the web that you encounter. With request autocomplete, you would only need to enter your credit card number once -- you could auto-complete it the next time. Everyone on the web wins :)
>
> Actually, the auto-complete part can still be done by the UA using the autocomplete content attribute. When talking to Jonas about this last week, he mentioned that the use case for requestAutocomplete is for the browser to do smart things such as generate one-time CC numbers, etc. It also allows the UA to prompt for a PIN code for instance which is used to encrypt the stored CC number. These use cases are not evident from the proposed spec at all, but I guess it makes sense.

ohh, I didn't know about auto-completing CC numbers only after PIN entry. That's a nice feature.

Ehsan Akhgari

unread,
Sep 18, 2013, 1:39:14 PM9/18/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal
I think I was not clear on this. So, AFAIU it is only the silent SMS
API which requires to be notified of SIM changes, and that API would
only be accessible from the pages loaded in the trusted UI. Assuming
that my understanding is correct, we should be able to only expose the
SIM change event to content running in the trusted UI. Is that correct?

Ehsan

Kumar McMillan

unread,
Sep 18, 2013, 7:48:26 PM9/18/13
to Ehsan Akhgari, dev-w...@lists.mozilla.org, Fernando Jiménez Moreno, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Andreas Gal
Correction: all web content would need access to SIM changes. The use case applies to payment providers that do carrier billing. This type of payment provider would need to persist user IDs (derived from phone numbers) to enable purchases over wifi. When the user swaps SIMs, the provider needs to un-persist the user ID -- thus, they need a notification event. I'm talking about all web content, not content within a Trusted UI.

Imagine that PayPal wants to be better at carrier billing on Firefox OS -- this use case applies to them. In fact, all use cases apply to them. They should be able to use the same web APIs that Mozilla uses for carrier billing.

-Kumar

>
> Ehsan
>

Gervase Markham

unread,
Sep 23, 2013, 10:49:43 AM9/23/13
to Kumar McMillan, mozilla-d...@lists.mozilla.org, Andreas Gal, Mounir Lamouri, Jonas Sicking, Fernando Jiménez Moreno
On 18/09/13 16:57, Kumar McMillan wrote:
> I understand that there are some security and privacy issues to work
> out but letting users grant permission to this data seems fine to me;
> that's how geolocation works.

Right - but there's some connection between "give the site my GPS
coordinates" and the service the site provides, which will be
location-related. There is no necessary connection in the mind of a user
that tells them that every time they pay for something, they have to
reveal where they are.

> What is the alternative? Restrict all the payment features for
> Mozilla's use only?

I didn't say I had all the answers; but the privacy team might.

> That's how it works in the current mozPay API --
> Mozilla is the only one whitelisted to use it. Historically, locking
> other players out of platform features has never worked on the web
> (e.g. Microsoft, etc). It's an open web and anyone should be able to
> do carrier billing in Firefox OS, not just Mozilla.

I'm all for openness, as I hope you know.

Gerv

Gervase Markham

unread,
Sep 23, 2013, 10:49:43 AM9/23/13
to Kumar McMillan, mozilla-d...@lists.mozilla.org, Andreas Gal, Mounir Lamouri, Jonas Sicking, Fernando Jiménez Moreno
On 18/09/13 16:57, Kumar McMillan wrote:
> I understand that there are some security and privacy issues to work
> out but letting users grant permission to this data seems fine to me;
> that's how geolocation works.

Right - but there's some connection between "give the site my GPS
coordinates" and the service the site provides, which will be
location-related. There is no necessary connection in the mind of a user
that tells them that every time they pay for something, they have to
reveal where they are.

> What is the alternative? Restrict all the payment features for
> Mozilla's use only?

I didn't say I had all the answers; but the privacy team might.

> That's how it works in the current mozPay API --
> Mozilla is the only one whitelisted to use it. Historically, locking
> other players out of platform features has never worked on the web
> (e.g. Microsoft, etc). It's an open web and anyone should be able to
> do carrier billing in Firefox OS, not just Mozilla.

0 new messages