RE: SEPA Credit Transfer + W3C PamentRequest

Hi Anders,



Thank you!

A small note maybe on your wording re. ISO 20022 that it was not designed for 
the frontend; actually it was designed to be used in any financial 
environment. It is indeed predominantly used in the backend because that (used 
to ;) be dominated by banks.

Now that the pre-settlement space been commoditised and has opened up to other 
types of players, it would be a good strategy to use 20022 in that space as 
well (where applicable) at least for the information flows, to reduce 
friction.



Kind regards





From: Rouslan Solomakhin [mailto:rouslan@google.com]
Sent: Sunday, August 18, 2019 2:40 PM
To: Anders Rundgren
Cc: Web Payments Working Group
Subject: Re: SEPA Credit Transfer + W3C PamentRequest



Mail originates from outside SWIFT !
Be vigilant before you click on a link, open attachments or reply !
------------------------------------------------------------------------- 

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