FW: [Web Payments] Call for reviews of HTTP API and Core Messages proposals

FYI.....Manu's response and rationale for the use of HTTP API - non-browser initiated payments.

​​​​​



* katie *
 
Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545


-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: Monday, May 2, 2016 12:48 PM
To: public-payments-wg@w3.org
Subject: Re: Call for reviews of HTTP API and Core Messages proposals

On 05/02/2016 04:19 AM, Tommy Thorsen wrote:
> Here are my thoughts regarding the HTTP API specification:

Hi Tommy, thanks for reviewing, responses to your feedback below.

> 1. Email any review comments you have back to the mailing list.
> 
> I don't have any detailed review comments -- only high-level ones: 
> Although the spec looks fine, I am opposed to having two different 
> definitions of the payment app. As I mentioned in #128 I think the 
> payment app should be fully specified in a single document, which 
> should cover both the Web case and the HTTP case with a single 
> implementation. Ideally, the cases should be identical, except that in 
> the HTTP case, the user agent will send "Accept:
> application/json", whereas in the Web case, the accept header will be 
> "text/html;application/json".

I agree on the following:

* We should have a Payment App spec (or something to that effect)
* The communication mechanisms that the Payment Apps use in the Browser
  API and the HTTP API should be as aligned as possible
* Any content that should belong in a payment app spec that is
  currently in the HTTP API spec should be moved to the payment app
  spec in time.

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/

Interactive Payment Apps may want to do additional things like two-factor authentication or some other type of interactive authentication. That means that we might need a mechanism other than just the Accept header to know whether or not a Payment App can be purely used via the HTTP API (what happens if your Payment App requires interaction?).

Also, does the browser load the text/html page into a secure context without a URL (the user is not redirected to the payment app website) or does it redirect the user to the payment app website? How do native payment apps work? How does the browser send the payment request to the native payment app? Via native OS messaging, or are we requiring native payment apps to open HTTP ports on localhost? And if we do that, what are the security implications?

Those are just some of the questions that your proposal raises. I'm not saying it's impossible to do or not worth pursuing as it would be nice if a payment app is very easy to write for interactive (Browser API) and non-interactive (HTTP API) use cases... but we haven't been able to find solutions to the problems above that would likely be implemented by browser vendors. That said, you work for a browser vendor, so I'd be very interested in hearing answers to the questions above from you.

> I would very much like to see some real use-cases for this spec.

Here's the primary use case domain: non-browser initiated payments

These payments may be interactive (native app that is not a browser) or non-interactive (automated payments/billing).

We have a number of use cases in our published Web Payments Use Cases
1.0 document that would benefit (or need) an HTTP API:

https://www.w3.org/TR/web-payments-use-cases/#uc-freemium
https://www.w3.org/TR/web-payments-use-cases/#uc-email
https://www.w3.org/TR/web-payments-use-cases/#uc-preauth
https://www.w3.org/TR/web-payments-use-cases/#uc-machine-readability
https://www.w3.org/TR/web-payments-use-cases/#uc-live-prices
https://www.w3.org/TR/web-payments-use-cases/#uc-trialware
https://www.w3.org/TR/web-payments-use-cases/#uc-vehicle
https://www.w3.org/TR/web-payments-use-cases/#uc-subscription
https://www.w3.org/TR/web-payments-use-cases/#uc-discovery
https://www.w3.org/TR/web-payments-use-cases/#uc-automatic-selection
https://www.w3.org/TR/web-payments-use-cases/#uc-
https://www.w3.org/TR/web-payments-use-cases/#uc-payer-initiated
https://www.w3.org/TR/web-payments-use-cases/#uc-electronic-receipts
https://www.w3.org/TR/web-payments-use-cases/#uc-refund

While it's arguable that some of those use cases could be achieved via a browser interface, the fact remains that they could also be achieved via a native app (no browser) or an embedded device.

> The IoT-case with a thing in the car that connects to the parking 
> meter and pays for parking, seems a bit of a stretch to me. This is 
> something that would be much more likely implemented using physical 
> web <https://google.github.io/physical-web/> and a smart phone, in 
> which case regular web payment would work just fine.

One of the uses of the HTTP API is if the user doesn't want to interact at all with the payee and instead wants their software agent to make a payment on behalf of them. For example, if I take a toll road every single day, I don't want to authorize the payment every single day. I want to grant my car the ability to pay the toll, but on demand and with a pre-set limit (not a subscription).

> Other scenarios I saw mentioned are auto payment of utility bills and 
> business-to-business payments -- do we have someone who would be the 
> actual users/implementors of this?

We're implementing this in product, so yes to that question. I hope other implementers in the group come forward and let us know their needs for non-browser Web Payments.

Users would be small governments, large governments, banks, utility companies, and businesses (to name a few). Those comments are going to be harder to get. That said, you're right, we should get some organizations on the record saying that an HTTP API is important to them and they'd deploy something that looks like this. I'd imagine that our customers are reluctant to say that at this point in time since the work hasn't even been adopted by the WG yet, but I'll check with them.

The Web Payments WG doesn't have a large number of retailers or banks, either, which highlights another problem with your question. We're going to have a hard time finding the right people at those organizations because many of the decision makers that care about "using open standards" and "the Web" and "automated payments" don't know enough about the technology to have a strong opinion other than "it should work and reduce costs for my organization"... which doesn't really help us.

Again, I agree with you that we should ask these questions and get this input, but getting feedback from users this early in the process might be difficult if we don't ask the right questions.

> I would have liked to see their opinion on how useful this 
> specification is, and to what extent it covers their needs. Links to 
> relevant discussions with relevant people in the interest group or 
> community group would be appreciated.

The Web Payments Use Cases were derived from many of these discussions, so I hope that helped answer some of your questions (though I don't expect they answered all of them).

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern http://manu.sporny.org/2016/browser-api-incubation-antipattern/

Received on Monday, 2 May 2016 17:34:19 UTC