RE: Web Payments - 21 years ago

Anders,
My apologies for the remedial nature of my comments / questions here. 19 years ago I worked on the implementation of SET (as did many of us) which did, in fact, rely on a central authority for security credentialing. In this discussion, I do not follow why you say that the W3C work here is reliant on a "super provider". The work seems very well targeted at the processing, flow, and participants without defining a super provider for any processing step (again, unless I am missing something).

On another topic, (not certain where it arose) -- I also do not see the "betting-on" a browser wallet. I see the interest for improving the payments process within the browser environment which is truly not standardized and varies widely today. Having a browser which reaches out to a mobile app (unless I misunderstood) seems that it would limit the work of this group to those who have both browser and mobile app. That seems contrary to the work effort.

-- 
David Jackson | Senior Director Financial Services
Mobile: +16145601237 | VOIP: +16144656654 
Oracle Global Industry Solutions Group
New York City | Columbus


-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com] 
Sent: Thursday, November 12, 2015 8:13 AM
To: Adrian Hope-Bailie
Cc: Web Payments IG; Web Payments CG
Subject: Re: Web Payments - 21 years ago

On 2015-11-12 11:54, Adrian Hope-Bailie wrote:
> By "you", I assume you mean the WG (or at least the IG who chartered the WG)?

Right.


> I think you have misunderstood the way the WG specifications will play out.
>
> Let's look at what is being standardised (ignoring for a moment the pre-payment stuff like registration):
>
> 1. A very high level flow (request from payee -> response from payer) 
> all other
 > comms are out of scope and hanlded by the payer (or their wallet/app/agent) and  > payee (or their PSP/bank etc)

I think I've got that.


> 2. The messages that form part of this flow. Although clearly these
 > messages will be "envelopes" for payment method specific data as required by implementors.

Here you immediately run into a problem:
How can you interpret/decipher currently unknown/undocumented payment method specific data?
Answer: You cannot.

In addition, if you (for the sake of the discussion) applied this thinking to my PoC it wouldn't work since it already defines a specific, and for the rest of this end-2-end-secured payment system carefully matched request/response pair.

Well, you can of course hope that the rest of the payment parties won't insist on end-2-end-security and similar stuff which is in direct conflict with the IG/WG vision.

Anders


>
> 3. A WebIDL API that allows a UA to mediate the flow of messages between payer and payee.
>
> In the "app" world (mostly only on mobile platforms) nothing is stopping implementors from simply passing the request received by the browser on to the mobile platform so that the standard app selection pattern can be used to allow the payer to select the payment app they want to use.
>
> On the desktop (where this pattern is less well defined) I expect that these will be "Web apps" (i.e. hosted by a PSP and served via HTTP to the browser that will render the UI defined by the PSP in HTML).
>
> Browser vendors may choose to allow hosting payment apps "in-the-browser" but that is not guaranteed and need not be offered at the expense of other options.
>
> My feeling is that this architecture accommodates such a wide variety of deployment scenarios that it will be able to leverage the platform neutrality of the Web but also the various benefits of "native" where appropriate.
>
> On 12 November 2015 at 10:59, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2015-11-12 09:09, Adrian Hope-Bailie wrote:
>
>         A New York Times article from 1994 describes the first online payment:
>         
> http://www.nytimes.com/1994/08/12/business/attention-shoppers-internet
> -is-open.html
>
>
>     For on-line payments (and reservations) using credit-cards and not relying on a
>     super-provider, nothing has really changed during these 21 years.  Considering its
>     importance these days, I'm inclined to say that things have rather 
> gone backward :-)
>
>     The only noticeable action is on the "App" side which makes me wonder why you
>     didn't consider hooking into this force instead of betting on a "Browser Wallet"
>     which will be difficult to standardize [1] and keep up-to-date with the market,
>     while the "App" folks can do updates whenever there is a need.
>
>     Cheers,
>     Anders
>
>     1] with respect to
>     - Payment UI ownership/branding
>     - Deployment model
>     - Possibly different flows of information
>     - Possibly encrypted data
>     - Enrollment
>     - Security solutions
>     - The desire among payment providers keeping their code secret
>
>

Received on Thursday, 12 November 2015 14:06:43 UTC