W3C home > Mailing lists > Public > public-payments-wg@w3.org > August 2019

Re: SEPA Credit Transfer + W3C PamentRequest

From: Rouslan Solomakhin <rouslan@google.com>
Date: Sun, 18 Aug 2019 08:39:39 -0400
Message-ID: <CAMMzaWGj+50P80nzb3kacfFiJpfxiRsSemT2LueGyk55nv42Cw@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Web Payments Working Group <public-payments-wg@w3.org>
Thank you for the kind words, Anders.I'm happy that you were able to get
you Android payment app working with Chrome. For the curious, here's some
documentation on it: Android payment apps developer guide
Anders gave us excellent feedback on the docs that we are planning to
incorporate into the docs.

On Sat, Aug 17, 2019 at 10:37 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Hi Payment Aficionados,
> F.Y.I. I'm putting the finishing touches on a Payment Authorization
> solution for account-2-account based transactions like SEPA Credit
> Transfer.  It builds on a native Android application invoked by Google's
> Android implementation of W3C's PaymentRequest. Aided by excellent help
> from Rouslan it wasn't too difficult to get PaymentRequest going.
> This implementation uses massive amounts of cryptography to enable an
> end-2-end secured and scalable trust model which I believe is new for the
> banking industry:
> https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf
> Yes, authenticating Merchants is (in this scenario NB) a prerequisite.
> AML considerations also speak for this.
> The client also needed some pretty advanced security features to cope with
> the rather demanding push payment model:
> https://cyberphone.github.io/doc/saturn/saturn-payment-credentials.pdf
> Signed and encrypted JSON data is based on
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06
> which I hope to get published as an "Informational" RFC.
> It was a pleasure replacing the awkward (and security broken) URL handler
> scheme with PaymentRequest!  Suddenly the App became an integral part of
> the browser experience.
> If anybody wonder where ISO 20022 is in this scheme the answer is simple:
> ISO 20022 was designed for the "backend" while this system targets the
> "frontend".  Of course the information need to perform the backend
> operations must be available, but that is not the same thing as running the
> entire system on ISO 20022.  The security constructs as well as the message
> in step #4 has no counterpart in any backend protocol.
> Thanx,
> Anders Rundgren
Received on Sunday, 18 August 2019 12:40:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:33 UTC