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

Re: Review of Payment Apps Proposal

From: David Illsley <david.illsley@digital.cabinet-office.gov.uk>
Date: Fri, 22 Apr 2016 17:16:20 +0100
Message-ID: <CAOEMzaJgrnP8vZ+Z0Yf0w8rjBUHw=_8pDiFDq7dd_BiVumpx_g@mail.gmail.com>
To: Adam Roach <abr@mozilla.com>
Cc: Shane McCarron <shane@spec-ops.io>, Adrian Bateman <adrianba@microsoft.com>, Manu Sporny <msporny@digitalbazaar.com>, Dave Longley <dlongley@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments Working Group <public-payments-wg@w3.org>
I don't think I understand how browsers can be prevented from allowing
payment without supporting registration?

On 22 April 2016 at 01:42, Adam Roach <abr@mozilla.com> wrote:

> On 4/21/16 15:14, Shane McCarron wrote:
> On Thu, Apr 21, 2016 at 2:50 PM, Adrian Bateman < <adrianba@microsoft.com>
> adrianba@microsoft.com> wrote:
>> No, in fact I've argued for the opposite. It's entirely reasonable for us
>> to develop v2 of a registration API without having to go back and change
>> a dependency in the Payment Request API. They should be independent so
>> that they can proceed independently.
> Huh?  I really don't understand.  Payment App registration is a
> fundamental requirement of this ecosystem.  The browser payment request API
> would have nothing to communicate with if there are no payment apps
> registered.  Certainly the test environment (as I am designing it)
> registers a payment app with the implementation under test so that we can
> process messages from and to the user agent just as we will model those
> messages from the "payee".  A normative reference in a W3C spec says "this
> spec requires that this other spec be in the environment too, as it DEPENDS
> upon this other spec".  Surely you are not proposing that we push out a
> version of the browser payment api that does not require support for
> payment app registration?
> I'm still coming up to speed on the specifics of the existing proposals;
> however, with the high-level understanding of the basic purpose of the
> payment functions and the registration functions that I do have, I find
> proposals not to make the payment functions strictly dependent on the
> registration functions troublesome.
> I'll reiterate the point that Manu has made: the only way unlinking these
> makes sense is in a world where we envision some implementations that do
> one without the other. Allowing registration without payment is clearly
> nonsense; and allowing payment without registration implies that we're
> going out of our way to accommodate browsers with non-extensible, baked-in
> payment providers.
> And that would be very bad for users.
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO, Mozilla
Received on Friday, 22 April 2016 16:17:08 UTC

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