- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 6 Nov 2019 05:32:23 +0100
- To: Rouslan Solomakhin <rouslan@google.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>, VIGNET cyril <Cyril.VIGNET@bpce.fr>, KUNTZ Vincent <Vincent.KUNTZ@swift.com>, Matt Saxon <matt.saxon@gmail.com>
On 2019-11-04 16:17, Rouslan Solomakhin wrote: > Hi Anders, Hi Rouslan & Co, > > Do you have a video or a GIF of the PoC? That's a very good idea so I will try to create a video ASAP. In the meantime you may take a look at this very short clip produced by Open Banking in the UK: https://www.youtube.com/watch?v=SXiRhCAYRCE Particularly noteworthy is that bank selection is performed in the MERCHANT environment. Using a "Wallet" concept like Google Pay, Apple Pay and Saturn everything needed is in YOUR own local environment. The reason why Open Banking doesn't come with a "Wallet" is because it is based on OAuth2 which is a server-centric and moves the authentication to on-line banks. The additional mode of Open Banking APIs I'm proposing uses a security and interaction model which is closer to EMV which is a user-centric scheme. If somebody wants to the "kick the tires" of the prototype, it is currently available on the public web: https://mobilepki.org/swedbank-psd2-saturn It (of course) uses the PaymentRequest-4-Android API :) The LIS (Local Integration Service) code took < 40 *calendar days* to write. Given the fact that I had ZERO previous experiences with Open Banking, I would say that this is a really simple solution. Kind regards, Anders Rundgren > > Cheers, > Rouslan > > On Sun, Nov 3, 2019 at 1:56 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > Hi List, > > Regardless of the merits of https://w3c.github.io/payment-method-credit-transfer/ the cost for integrating a new scheme in a bank environment is simply put prohibitive. The only realistic way ahead seems to be building on Open Banking APIs which also provides the (currently missing) security solution. This would though require a major revision of the draft. > > Having seen a few demos of payment systems using Open Banking APIs, I note that they are behind in user-experience compared to state-of-the-art systems like Apple Pay. This is not due to laziness or incompetence of the developers, but rather stems from the fact that Open Banking APIs such as FAPI [1] primarily targeted third-party "Financial Services" which is quite distinct from Payments in a shop. Analogy: EMV-cards were designed for payments using a specific account and associated key combining security and convenience, while login to a bank for paying an invoice usually requires another authentication solution and UI. > > To neither have to "boil the ocean" nor have to accept second-class user-experiences, I have developed a proposal for "tweaking" Open Banking APIs: > https://github.com/cyberphone/doc/blob/gh-pages/payments/dual-mode-open-banking-api.md#background > > In addition, I have created a working PoC using an Open Banking "sandbox" [2] which verified my initial hunch that this is both simple and efficient. > > WDYT? > > Thanx, > Anders > > > 1] https://openid.net/wg/fapi/ > 2] https://github.com/cyberphone/swedbank-psd2-saturn >
Received on Wednesday, 6 November 2019 04:32:31 UTC