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

On 2014-11-17 18:26, David Ezell wrote:
> 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.

All I'm saying is that every interface that is exposed through the browser (to usually arbitrary web code),
stir up a lot of discussions around Security, Privacy, Trust and User interactions.  There are seldom any
easy answers here.  I'm working with this right now so I know :-(

http://lists.w3.org/Archives/Public/public-web-security/2014Nov/0048.html

Cheers,
Anders

>    
>
>> 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:47:31 UTC