Re: Web Payments - 21 years ago

On 12 November 2015 at 15:12, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

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

Why do you need to?

If the messages provide an envelope for each payment scheme to insert their
own data then the scheme can define whatever mechanism it chooses to
provide end-to-end security.

Imagine payment scheme X decides to leverage the standard and publishes
their specification for how payer and payee PSP's must construct the
request and response messages.


Once the payer app (mobile app, web based app, it's not material) receives
the payee's request it will contain an indication that the payee supports
payment scheme X and the payment scheme X data that the apyer requires (per
payment scheme X's specification). Since the payer app also supports
payment scheme X it knows how to interpet the scheme specific data in the
request and construct the response to the PSP.

The process for doing this may include a call-out to a third party token
provider, an authorization flow that involves hardware security, some
entirely proprietary process that only certified payment scheme X payer app
developers have access to The point is that once the request has been
received by the payer app anything can happen before the app construct a
response (with appropriate scheme specific data) and sends it back.

Very simple example:
The scheme may give each payee PSP a unique certificate that they must link
to in their payment request (and store under the same origin as the
requesting site maybe?) and the payer app must encrypt response data using
the keys from that certificate.

Open scheme example:
The Bitcoin community decide on a format for exchanging payee wallet
address (and signing the message to prevent tampering). Payer apps that
support the community defined scheme must make a payment to the supplied
address and provide a response (per the community defined format) that
helps the payee trace the payment.


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