Re: proposed navigator.mozPay() changes

On Sep 5, 2013, at 12:00 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 09/04/2013 05:44 PM, Kumar McMillan wrote:
>> I just posted a request for feedback on this proposal:
>> https://groups.google.com/forum/#!topic/mozilla.dev.webapi/cyk8Nz4I-f4
>> (https://lists.mozilla.org/listinfo/dev-webapi)
> 
> Let me attempt to summarize in order to see if I really understand the
> proposal:
> 
> You're proposing that we create a new whitelisted feature in modern web
> browsers that allows a "trusted window" to appear when a payment, or any
> potentially risky operation, is initiated.

My mention of the trusted UI in the proposal was only to suggest a path away from mozPay and retain the current pay window. The trusted UI is fraught with peril as is. It was meant to be unspoofable yet there are plenty of ways to spoof it. It was meant to be trustworthy but there is no user research suggesting that it is trustworthy and no solid arguments for how users would know to trust it. 

I think it is possible to evolve a real trusted UI but the one in Firefox OS is not it. Work on this is happening separately so I merely suggested window.open({mozTrusted: true}) as a way to extract that part from mozPay until a better solution is ready.

> 
> This window could be opened by companies like Square, Stripe, Google
> Wallet, PayPal, Telefonica, Verizon, or a number of other companies that
> provide payment services. The code that can run in this window is
> arbitrary, allowing any payment flow to work. The application (like a
> game) could communicate with the payment provider using existing
> features like postMessage().

Eventually when we have a working trusted UI I think it would be essential to open it up for others to use.

> 
> The benefits of this approach are:
> 
> 1. Simplicity of design and composability, which are generally good
> things when attacking a problem with unknown depth.
> 2. Added flexibility, supporting payment flows that we haven't thought
> about.
> 
> The drawbacks of this approach are:
> 
> 1. The existence of a whitelist, which potentially places the browser
> companies in the position of blessing business models. Seeing how Google
> and Apple might have a reason to prevent competitors to their payment
> solutions, that may not be a good idea.

My proposal to deprecate mozPay means that no one would need to be whitelisted to do get mobile payment features.

> 
> 2. There is no payment standard or convergence.

This is a hard problem to solve. I don't really think mozPay had a good solution to this.

> Large companies will
> continue to support their proprietary buy flows with no real incentive
> to settle on a particular buy flow.

What incentive is there for large companies to adopt mozPay as a buy flow? The only incentives I can think of is that the payment provider could gain some carrier billing features. It seems unfair to ask payment providers to implement all the details (like the JWT exchange) if they simply want to improve their carrier billing service on Firefox OS which is why I proposed to expose these primitives separately.

> 
> 3. This may be perceived as Mozilla backing away from doing something
> deeper with payments and app stores on the Web. Is that perception
> correct?

I'd hope that this proposal is perceived as Mozilla making core payment features available to *more* of the web. What I'd like to do is unlock the special API privileges that Mozilla is currently getting from mozPay. If PayPal wants to improve their carrier billing they should be able to do so without implementing all of mozPay.

> Are decentralized product listing and sale still something
> Mozilla is still interested in pursuing?

Mozilla is definitely still interested in this. App receipts were designed to be decentralized with multiple app stores in mind. However, app purchase / installation was a much more concrete problem that needed new web APIs to solve. There was no app install API, now there is. It's less clear why we need a new web API to enable the purchase of any good anywhere on the web. Don't we just need HTTP? How would mozPay help solve this?

If it sounds like I'm playing dumb on some of these questions I'm really not :) I keep coming back to a lot of these questions and I keep failing to think of answers.

> 
> I think we can address issue #1 by keeping the "add a trusted provider"
> mechanism we created in the Web Commerce API.
> 
> #2 and #3 are more concerning to me, do you see the focus being placed
> on PaySwarm to accomplish a standard payment mechanism? Or something
> else?

Yeah, PaySwarm seems like a much better way to accomplish a standard payment system for all of the web to share. However, it's equally unclear to me why PaySwarm would need a new web API. Doesn't the PaySwarm protocol already work on today's web? I think the PaySwarm protocol can excel forward without the need for something like mozPay. Or am I missing something here?

> Would nav.pay() disappear entirely?

My proposal was to stop using nav.pay() for payments, yes. My argument is that we don't need it to do payments on Firefox OS, we just need some lower level primitives to do carrier billing better. Mozilla's mission is to push the web forward -- If we want to empower all of the web to do payments in mobile environments like Firefox OS then mozPay is not a good solution, it is too tightly constrained. 

Kumar



> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
>

Received on Thursday, 5 September 2013 22:07:55 UTC