W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2014

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

From: David Ezell <David_E3@VERIFONE.com>
Date: Mon, 17 Nov 2014 17:26:08 +0000
To: Anders Rundgren <anders.rundgren.net@gmail.com>
CC: Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>, "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>
Message-ID: <54C00E24834FCE47B11EC129A84E7F78A4685410@VF2WDEXMB1.verifone.com>
In response:
>If the WebIDL interface is a part of the browser it requires quite difficult browser integration work.  
That remains to be seen from the work of the WG.  "Difficult" is very relative.  

>If OTOH the WebIDL interface lives somewhere outside of the browser, we are not on the web anymore.
All I'm saying is that it's quite a useful abstraction, and if it works in the browser or outside the browser that a good thing.  The underlying implementation might use a web service client, so I don't see the "in the browser" distinction as useful.


-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] 
Sent: Monday, November 17, 2014 12:15 PM
To: David Ezell
Cc: Manu Sporny; Web Payments CG; public-webpayments-comments@w3.org
Subject: Re: Discussion - Payment APIs: others are thinking about this problem space, too

On 2014-11-17 17:15, David Ezell wrote:
> Hi Manu:
> 1) WebIDL
>       I understand the "handover" issue, but it is an essential work product, and not one that we can or should
>       ignore.  I understand the point, but consider the following possibility:
>       Based on WPAY work (some WG) that produces a WebIDL interface, Android developers create a Dalvik VM
>       Interface (Java Classes) that are >isomorphic< to the WebIDL interface.  Then, any browser port becomes
>       trivial, but the semantics of the interface are available for people working in native, hybrid, or pure HTML5
>       environments.  I could conjecture similarly about iOS or Tizen or any other platform, but who knows.

David, I don't understand what you are saying here.  If the WebIDL interface is a part of the browser it requires quite difficult browser integration work.  If OTOH the WebIDL interface lives somewhere outside of the browser, we are not on the web anymore.

Anders

>
> 2) RESTful WS
>       I agree this one is important, but it tends to address only the "off-platform" use cases.
>
>
> Best regards,
> David
>
> -----Original Message-----
> From: Manu Sporny [mailto:msporny@digitalbazaar.com]
> Sent: Friday, November 14, 2014 2:35 PM
> To: David Ezell
> Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
> Subject: Re: Discussion - Payment APIs: others are thinking about this 
> problem space, too
>
> 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/
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.
> blog: High-Stakes Credentials and Web Login 
> http://manu.sporny.org/2014/identity-credentials/
> ________________________________
> 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 Monday, 17 November 2014 17:26:47 UTC

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