- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 22 Apr 2016 12:40:29 -0400
- To: David Illsley <david.illsley@digital.cabinet-office.gov.uk>, Adam Roach <abr@mozilla.com>
- Cc: Shane McCarron <shane@spec-ops.io>, Adrian Bateman <adrianba@microsoft.com>, Manu Sporny <msporny@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments Working Group <public-payments-wg@w3.org>
On 04/22/2016 12:16 PM, David Illsley wrote: > I don't think I understand how browsers can be prevented from allowing > payment without supporting registration? They can't be prevented from doing anything (unless we're talking by force of law) -- they just won't be compliant with the spec. The spec should reflect what is best for users. > > On 22 April 2016 at 01:42, Adam Roach <abr@mozilla.com > <mailto:abr@mozilla.com>> wrote: > > On 4/21/16 15:14, Shane McCarron wrote: >> >> >> On Thu, Apr 21, 2016 at 2:50 PM, Adrian Bateman >> <<mailto:adrianba@microsoft.com>adrianba@microsoft.com >> <mailto: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 > > -- Dave Longley CTO Digital Bazaar, Inc.
Received on Friday, 22 April 2016 16:40:55 UTC