W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2013

Re: proposed navigator.mozPay() changes

From: Kumar McMillan <kmcmillan@mozilla.com>
Date: Wed, 11 Sep 2013 13:49:53 -0500
Cc: "public-webpayments@w3.org Payments" <public-webpayments@w3.org>
Message-Id: <CBA2A31F-C3F1-4F7D-860F-042FEB026075@mozilla.com>
To: Manu Sporny <msporny@digitalbazaar.com>

On Sep 10, 2013, at 10:30 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> I'm collecting my thoughts wrt. Web Commerce API for the discussion
> tomorrow, so just mostly thinking out loud and offering potential
> answers to your questions.
> On 09/05/2013 06:07 PM, Kumar McMillan wrote:
>> 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.
> Where is the work happening separately? Is it in a form that is ready
> for public consumption yet? Got a link?

It would happen on https://lists.mozilla.org/listinfo/dev-b2g or https://lists.mozilla.org/listinfo/dev-webapps and in meetings but I don't know if anyone is working on it yet. Some security/UX folks were maybe going to hold another meeting about it (which would be public). I don't think it's scheduled yet.

>> Eventually when we have a working trusted UI I think it would be
>> essential to open it up for others to use.
> +1
>> My proposal to deprecate mozPay means that no one would need to be
>> whitelisted to do get mobile payment features.
> Ok, that would be great. I don't understand the high-level of how that
> would work. We should go over that on the call.

I'm not sure if we covered this actually. What I meant was things like observeSilentSms() could be called by anyone on the web, no need to whitelist who can use that function. There are security details to work out but my proposal was to perhaps only allow whitelisted *phone numbers*, those that we knew would not incur a charge to the user. In the current mozPay you have to be a whitelisted payment provider to get access to silent SMS auth which doesn't make a whole lot of sense.

>> What incentive is there for large companies to adopt mozPay as a buy
>> flow? 
> Maybe not mozPay itself, but mozPay + PaySwarm could be compelling if
> certain things fall into place. If (big IF) PaySwarm were to gain
> adoption as a major Web payments standard online, and it could be
> triggered by navigator.pay(), then large companies might want want to
> use it because it makes integrating their payment system with a website
> much easier.

I think we covered this on the call: actually I think using navigator.pay() might make it harder for websites to integrate payswarm because everyone would be at the mercy of the platform (the browser) to get API updates. If payswarm is already possible on the web then it makes more sense to me to let it innovate with a JavaScript shim (which is easier to update). For problems that the shim can't solve, like client side storage, there might be ways to address this via other APIs.

It might be helpful to spend some time now to identify the web APIs that are missing in order for payswarm (and bitcoin, etc) to do the client side logic it wants to do.

> A merchant currently has to pick a merchant processor and shopping cart
> software. The software tends to be very difficult to setup and use, even
> in the case of Stripe. It would be nice if you just had a Stripe-like
> API that worked the same for any payment processor. So, switching
> payment processors was quite literally a one line code change, and not
> the gigantic multi-week hassle that it is today.
> This shift will be driven by the developers rather than the large
> companies. That said, this can happen w/o mozPay.

Agreed. Also, I think this is a good use case for building an open source payments.js library or something like that. It could be an abstraction on top of whoever wants to be a part of it -- say, PayPal, if they send a pull request for support :) Once a stable API emerges that addresses many needs, something might feed back into the platform. In the example of jQuery, the library iterated rapidly as a standalone lib and now we have document.querySelector(). I'd like to see the same iteration happen for payments before we try to push something into the platform. Anyway, querySelector() is a primitive that was missing from the web whereas navigator.mozPay() is not, it's an end-to-end strategy.

>>> 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.
> Agreed. I still don't understand which special API privileges we're
> talking about, though. I'm sure you'll explain on the call.

I meant that Mozilla is currently the only one whitelisted to use navigator.mozPay(). No one else has access to the mozPaymentProvider API: https://wiki.mozilla.org/WebAPI/WebPaymentProvider#API

>> 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?
> With respect to the PaySwarm work, we've always been interested in the
> browser having the ability to complete a transaction initiated by an API
> call in the background. This is useful for pay-as-you-go scenarios or
> in-app payments where you don't want a UI popping up every time you need
> to do a $0.05 purchase. It's true that you can do this with some
> server-side trickery today, but one of the goals of PaySwarm was to make
> payments easier to process. Ideally, a developer would just:
> 1. Create a product and put it on the page for sale.
> 2. Call navigator.pay(productUrl).
> 3. The browser would lift the product info from the page, submit the
> signed purchase request to the payment processor, the payment processor
> would complete the purchase, the digital receipt would be handed
> back to the browser, and it would appear in the client-side code, which
> the website could then do with as it pleased.
> All of this is implementable w/o the navigator.pay() API, but it
> requires more code outlay on the server side.

I don't see how requiring more code is a bad thing here. The developer already has to write code (e.g. to call navigator.mozPay()) so why not include a distributed javascript library in their web page that did more work?

> Generally speaking, we wanted the purchase processing to be between the
> browser and the payment processor, not the browser->merchant->payment
> processor.

The part that trips me up here is that we (Mozilla) need the merchant to be in control of the transaction. Each merchant has an explicit agreement that guarantees how they will get paid. If the merchant is not in control then they could get ripped off. I definitely see how payswarm can solve this problem but I still don't see why you'd need a browser API to accomplish that. The JavaScript code has to execute somewhere. It could execute from a browser API (in chrome) or from a web page, no difference.

> We wanted this so that the browser could be smarter about
> things when doing a purchase... if the item has already been purchased,
> the browser could just return the digital receipt w/o needing to contact
> the payment processor.
> In a restricted intranet (military facility - yes
> we have a use case for this), the browser could still provide
> proof-of-purchase w/o contact w/ the outside world.
> I do admit that this is a heavier set of requirements than mozPay, but
> we always viewed navigator.pay() as the start of a storage mechanism for
> digital receipts.

Mozilla is indeed heading toward decentralized receipts but there isn't really a use case for storing digital receipts on device. Our main use case: a web app sells its in-app products through Mozilla *or* through any other web payment provider. If we specify a .well-known path for merchants to put their products in and a JSON-LD (or whatever) format then that would address the problem. 

The problem with storing things on device is devices can get lost or stolen. Additionally, Mozilla is very interested in syncing data across devices for user convenience; this will inevitably require a server but I think we can do it without compromising privacy/security. As for the federation aspect, I envision that we will push more logic into each web app server, not into mobile devices. To federate user content we will probably use Persona for that -- PICL (https://wiki.mozilla.org/Identity/PiCL) aims to attach profile data to identities.

>> 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?
> It can continue w/o deeper browser integration, yes. It was designed to
> not depend on browser implementations to work (same design principles as
> Mozilla Persona). That said, there are some really compelling use cases
> that can be accomplished with minimal browser additions. I should really
> document all of those somewhere. Here is the high-level:
> 1. The ability for the browser to provide a proof-of-purchase.

The more I think about this, I wonder if Request Autocomplete is a good fit for storing data like digital receipts. Google has a similar use case where they want to store and auto-transmit oauth tokens. The best example I could find is using a hidden form: http://www.chromium.org/developers/using-requestautocomplete#id.lozox1wy6l41


> 2. The ability for a browser to be offline and provide a proof-
>   of-purchase.
> 3. Greater anonymity when using a proof-of-purchase to access other
>   website content.
> 4. The ability to perform purchases where the target device is not
>   connected to the Internet (vending machines).
>>> 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.
> I certainly agree with the goals. I don't understand the details, but
> those are easy enough to cover on the phone call.
> -- 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 Wednesday, 11 September 2013 18:50:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:24 UTC