- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 3 May 2016 09:23:54 -0400
- To: Tommy Thorsen <tommyt@opera.com>, Manu Sporny <msporny@digitalbazaar.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>
On 05/03/2016 03:37 AM, Tommy Thorsen wrote: > > I'm a bit concerned about your "Accept: text/html;application/json" use > case because it makes a number of assumptions that are not clearly > spelled out in #128. > > For example, the HTTP API could most likely depend on standard > authentication mechanisms like Digest, HTTP Signatures, Negotiate, > OAuth, etc. This is what this demo will do in time: > > http://http-mediator-demo.web-payments.io/ > > > I guess you're right, but does that mean it's not really feasible to > unify the two payment app types? HTTP Payments and Web Payments already > use different user-agents. And the payee will need bespoke > implementations for each of the two payment types. If the payment apps > can't be shared either, what is common between the two systems? Just because we may need two separate interfaces to communicate with/authenticate with a Payment App doesn't mean we aren't sharing Payment Apps. There is often more than one way to communicate with an application. > Only the format of the request and response messages? That's not a whole lot... I disagree, I think that's a big deal. I think being able to take a payment request message that you received in one way and pass it seamlessly to a Payment App using the API of your choice is powerful and important. It also opens the door to all kinds of new experiences on the Web -- in a similar way that search engine result pages have gone from a list of blue links to information rich, interactive displays. -- Dave Longley CTO Digital Bazaar, Inc.
Received on Tuesday, 3 May 2016 13:24:19 UTC