Re: Call for reviews of HTTP API and Core Messages proposals

>
>
> 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? Only the format of the request and
response messages? That's not a whole lot... If HTTP Payments and Web
Payments do not share anything meaningful, then we are creating two
entirely separate ecosystems, rather than a single ecosystem which is
accessible via both Web and HTTP.

Katie Haritos-Shea spoke earlier about how important the HTTP Payment
specification is to accessibility. Now, increased accessibility is
something I am very much in favor of, but I wonder: if HTTP Payments is not
a method that lets users with disabilities interact with the grand
ecosystem used by everyone to make payments -- but instead is a method that
lets users with disabilities interact with a completely separate ecosystem
from what everyone else is using -- does it still have value? And who will
create this separate ecosystem?



>
> 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?


All the details aren't clear here, but I think it will load it as a regular
web page with a url and everything. However, the payment app will be loaded
in a separate context (much like a webview overlaid on top of the regular
browser).



> 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?
>
>
I don't know how the native apps will work. I think for mobile platforms,
it is completely up to those that own the platform to decide how this
should work, and we couldn't dictate this to them even if we wanted to.



>
> 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
>
>
These are pretty good, thanks!