- From: Rouslan Solomakhin <rouslan@google.com>
- Date: Sun, 18 Aug 2019 08:39:39 -0400
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>
- Message-ID: <CAMMzaWGj+50P80nzb3kacfFiJpfxiRsSemT2LueGyk55nv42Cw@mail.gmail.com>
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 <https://developers.google.com/web/fundamentals/payments/payment-apps-developer-guide/android-payment-apps>. 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