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 16:48:41 UTC