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

inline

Thanks,
Bryan Sullivan 
-----Original Message-----
From: David Ezell [mailto:David_E3@verifone.com] 
Sent: Monday, November 17, 2014 9:22 AM
To: SULLIVAN, BRYAN L; Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: RE: Discussion - Payment APIs: others are thinking about this problem space, too

Hi Bryan:
Many payment applications (like the payment agent) may run on the terminal, but many components may run someplace else (off-platform).  An existing example is how some people do EMV processing on an external server using the ISO7816 messaging[1].

So all I meant was we could create a JSON or XML RESTful API to do payment agent functions, but it's a little convoluted to try to make those calls locally on the terminal.  Not impossible (I've done it myself in the past) but I'm not sure it's the most direct solution.

[bryan] OK, I understand (perhaps). I think the design approach of API exposure by a local RPC/REST service is becoming more straightforward, especially with smartphones, tablets, etc that can run local services and even entire web application server frameworks. Having back-end native APIs (e.g. to SE-based wallets) is a further requirement if the payment agent doesn't do it all itself, but I think such an approach should be on the table. The instances of projects that create such "bridges" to native or off-device functionality (e.g. LAN/PAN-connected devices) are increasing. Credentials, payment, preferences/profile management, etc are all reasonable use cases for this approach as well. So I would hope that the Payments IG could consider locally-exposed RPC/REST web APIs as in-scope technical approaches, when it discusses use cases and high-level requirements.

Best regards,
David

[1] I'm not necessarily suggesting we do this, BTW.

-----Original Message-----
From: SULLIVAN, BRYAN L [mailto:bs3131@att.com] 
Sent: Monday, November 17, 2014 11:52 AM
To: David Ezell; Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: RE: Discussion - Payment APIs: others are thinking about this problem space, too

inline

-----Original Message-----
From: David Ezell [mailto:David_E3@VERIFONE.com]
Sent: Monday, November 17, 2014 8:15 AM
To: Manu Sporny
Cc: public-webpayments-ig@w3.org; public-webpayments-comments@w3.org
Subject: 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.

[bryan] David, what do you mean by "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:43:58 UTC