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-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
