- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sat, 17 Aug 2019 16:36:10 +0200
- To: Web Payments Working Group <public-payments-wg@w3.org>
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 Saturday, 17 August 2019 14:36:37 UTC