RE: Discussion - Payment APIs: others are thinking about this problem space, too

Hi Anders:

I certainly think an open source implementation would be a good target, especially if WGs in the Web Payments umbrella produce implementable things (like APIs).  So in general I agree with the open source idea though limiting it to Android doesn't seem wise.

I am curious about one comment below:
>Running this as standard W3C project is a surefire recipe for failure unless it
>(in reality) becomes a single big-company affair.

I'm wondering if you can give an example of a standard W3C project that has produced a failure of the kind that seems so obvious; we'd like to avoid that if possible.  I'm not sure I know what a standard W3C project is.

Best regards,
David Ezell

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: Saturday, November 15, 2014 7:47 AM
To: Joseph Potvin
Cc: public-webpayments-comments@w3.org; Web Payments CG
Subject: Re: Discussion - Payment APIs: others are thinking about this problem space, too

On 2014-11-15 11:44, Joseph Potvin wrote:
> What you're saying Anders is that the W3C WP effort is about herding cats:
> http://www.blinkx.com/ce/saQTySG9pg5QQ_bOz5lULrZwc2FRVHlTRzlwZzVRUV9iT

> 3o1bFVMclp3c2FRVHlTRzlwZzVRUV9?id=1604418093

Great video!

>
> May I suggest it's about identifying the sort of cat food that will entice them into a common area.

A possible ingredient could be an open source client running on Android.

Since the costs and difficulties for doing this are extremely high I also think that a successful project (beyond producing a REC) must be open for any willing participant.

Running this as standard W3C project is a surefire recipe for failure unless it (in reality) becomes a single big-company affair.

Anders

>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983
>
>
> On Sat, Nov 15, 2014 at 2:18 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Manu,
>     I think this discussion highlightes what I have tried to say which
>     is that standardization of payments probably is the most difficult
>     target you can possible find!
>
>     Anyway, standardization has never been a level playing field, nor a
>     democratic process or even a quest for the best possible solution.
>
>     With SuperProviders like Apple and Google (and Alibaba on the horizon)
>     it just got worse.
>
>     The limited information available around the Google Wallet and Apple Pay,
>     also shows that the W3C members aren't mentally ready for standardization,
>     i.e. whatever we do it will be a "rebel" effort or even more likely a no-go.
>     Gemalto is participating in the IG because they have a wallet but they
>     haven't submitted the specs...very useful indeed.
>
>     I would personally consider schemes that *compete* with established
>     payment industry but that is something W3C can't do so therefore it
>     seems that the whole W3C payment standardization thing is toast.
>
>     Regarding polyfilling as a solution, I think this is a hard sell when
>     the SuperProviders can add whatever feature they need using an army of
>     developers and then get it distributed as an automatic update.
>     You can't replace security elements with polyfilling and for payments
>     that's a show-stopper.
>
>     Apple Pay is the new yardstick for the payment industry.
>
>     Anders
>
>     On 2014-11-14 20:35, Manu Sporny wrote:
>
>         On 11/13/2014 02:54 PM, David Ezell wrote:
>
>             As I see it, there are two levels of API with which we are
>             concerned:
>             1) Interfaces for the "payment agent"[2] - probably WebIDL defined
>             interfaces.
>
>
>         I'm always concerned when this comes up because it has fantastic
>         potential for vendor lock-in. For example, if we create the WebIDL
>         interfaces in such a way that only the browser manufacturers can
>         implement them, then we will fail for at least two reasons:
>
>         1. We will fail because the browser vendors may drag their feet to
>              implement it, and more importantly
>         2. We will fail because it won't create a level playing field, it'll
>              make it so that the browser vendors determine the payment landscape
>              on the Web.
>
>         WebIDL is a great way to hand an enormous amount of power over to the
>         browser vendors.
>
>         So, when we talk about WebIDL interfaces, we should build them in such a
>         way as to avoid vendor lock-in. That is, any WebIDL we provide must be
>         implementable in pure JavaScript w/o waiting on the browsers to implement.
>
>         Just pointing out what should be a show-stopper for every payment
>         company that isn't a browser vendor.
>
>             2) RESTful web services for other as yet TBD goals.
>
>
>         I think this is a better approach. RESTful web services coupled with
>         WebIDL APIs that can be implemented in pure JavaScript. That removes
>         many technical barriers to adoption and doesn't put this group in the
>         position of waiting for any particular organization or industry to get
>         off their keister and open themselves up to competition.
>
>             We need to generate some concrete ideas and get the ball rolling.
>
>
>         Some concrete ideas:
>
>         https://web-payments.org/__specs/source/roadmap/

> <https://web-payments.org/specs/source/roadmap/>
>
>         -- manu
>
>
>
>
>
>
>


________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Sunday, 16 November 2014 20:47:52 UTC