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

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.

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 16:15:42 UTC