W3C home > Mailing lists > Public > public-payments-wg@w3.org > April 2016

Re: Review of Payment Apps Proposal

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 21 Apr 2016 13:44:19 -0400
Message-ID: <57191173.30301@digitalbazaar.com>
To: Dave Longley <dlongley@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>
CC: Web Payments Working Group <public-payments-wg@w3.org>
On 04/21/2016 01:29 PM, Dave Longley wrote:
> On 04/21/2016 11:51 AM, Manu Sporny wrote:
>> I disagree strongly. I don't think it's okay for the registration
>> API to be separate from the browser API. Registration ensures that
>> we have a level playing field, and without it only the browser
>> vendors provide the mechanism for registering payment apps. To put
>> this another way, I don't think any API (either browser or HTTP)
>> should go to REC w/o registration also going to REC at the same
>> time.
> 
> To be clear, if the browser API specs are split into registration
> and payment request, my assumption is that the payment request spec
> would have a normative dependency on registration. It seems like the
> details of how you pass payment request data to a Web-based payment
> app are inextricably linked with registration of said payment app.

Agree w/ this general approach.

If there is a normative requirement for the Registration API spec on the
Browser API spec, then I'd be okay with that because that would create a
level playing field as long as the browser manufacturers are willing to
have that requirement.

What I'm wondering is if Microsoft or Google are okay with that
normative dependency structure?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
http://manu.sporny.org/2016/browser-api-incubation-antipattern/
Received on Thursday, 21 April 2016 17:44:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:16 UTC