On Sep 18, 2013, at 11:22 AM, Ehsan Akhgari <[email protected]> wrote:
> On 2013-09-05 12:21 PM, Kumar McMillan wrote: >> >> On Sep 4, 2013, at 6:04 PM, Ehsan Akhgari <[email protected]> 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? 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. > >>> 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 _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
