Re: Review of Payment Apps Proposal

On 04/21/2016 11:51 AM, Manu Sporny wrote:
> On 04/21/2016 11:36 AM, Dave Longley wrote:
>> On 04/21/2016 07:54 AM, Adrian Hope-Bailie wrote:
>>> There is a concern from the browser API spec editors that we
>>> should keep registration in a separate spec so that the payment
>>> and registration specs can evolve independently. I think there is
>>> a case to be made that these should be in the same spec as they
>>> relate to the same component (the browser) and the sections of
>>> the spec that relate to each function can still evolve
>>> independently.
>>
>> I agree that for Payment App registration with the browser -- it
>> should be in a browser API spec. There may be other ways to
>> register Payment Apps (non-browsers) and those should be in their
>> own respective specs. However, if it makes more sense to break up
>> the browser API into a number of "Browser API Specs" I think that's
>> ok as well.
>
> 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.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Thursday, 21 April 2016 17:29:31 UTC