W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 5 May 2016 10:39:25 -0400
To: public-payments-wg@w3.org
Message-ID: <572B5B1D.1010901@digitalbazaar.com>
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?

It depends on what you mean by "unify". One could argue that the same
payment app can have two interfaces, but share the same messages, and
doing so would make much of the processing back-end of the payment app
identical (and that's a good thing).

That is, the only thing that changes is the protocol used to access the
payment app. The back-end logic remains the same.

> HTTP Payments and Web Payments already use different user-agents.

They don't have to. You can imagine a scenario where a payment mediator
(aka user-agent) can execute both HTTP API-based payments and Browser
API-based payments. I'm not saying that's the norm (I don't know what
will be), but we shouldn't rule some of these scenarios out.

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

The payment apps can be shared. For example, if you use the same login
credentials when registering, you get the same payment app.

> Only the format of the request and response messages? That's not a 
> whole lot...

The request and response messages /and/ the business logic. Those are
pretty significant parts of a payment app. The only thing that is
different is the protocol used to access the payment app (and even that
isn't necessarily true). One could imagine a few scenarios where a
browser /could/ purely use an HTTP API to access a payment app if, for
example, it only requires Digest-based authentication to approve the
transaction and the browser knows the username and password for the
payment app website.

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

I hope were creating the latter, and to modify your language a bit...
we're trying to make the ecosystem accessible via browser protocols and
the HTTP protocol... both of those things are considered by many to be
"the Web". :)

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

It does. Just because you don't use wheelchair ramps and handicap
accessible automatic doors doesn't mean that those things don't have
tremendous value to those that need to use those systems out of necessity.

> And who will create this separate ecosystem?

It's not a separate ecosystem just like a wheelchair ramp access isn't a
separate ecosystem from building access. We're talking about making it
easier to access the single Web Payments ecosystem using any device or
client. It's about choice in how you access the ecosystem.

As for who pays for it, society usually does (and thus government and
private industry) via ensuring that they are compliant with
accessibility regulations.

>> 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).

+1

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

+1

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/
Received on Thursday, 5 May 2016 14:39:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 May 2016 14:39:54 UTC