- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Thu, 21 Apr 2016 19:50:56 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, Dave Longley <dlongley@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>
- CC: Web Payments Working Group <public-payments-wg@w3.org>
On Thursday, April 21, 2016 10:44 AM, Manu Sporny wrote: > 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? 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. Cheers, Adrian.
Received on Thursday, 21 April 2016 19:51:47 UTC