[Openid-specs-fapi] Strong MERCHANT Authentication

Anders Rundgren anders.rundgren.net at gmail.com
Sun Apr 12 06:21:32 UTC 2020

It might not be evident for everybody but in the depicted scheme counter signatures is a not just "a cool thing"; it is rather a prerequisite for maintaining a highly constrained and granular access model.

The same goes for signed and encrypted User authorizations which enable another flow and UI than SCA.

I'm now in the process adding VRP on top of the resulting User Bank authorization.  This works like SDD where the "mandate" is an intrinsic part of the authorization process while still building on the same inter-banking A2A-rails as direct payments.

The most complex task seems to be figuring out how much data you need to send to the Wallet for the User to react on.  I guess text saying that this is based on a contract that you are supposed to have read is the only workable way ahead?
Current take on a phone subscription authorization request:
   "@context": "https://webpki.github.io/saturn/v3",
   "@qualifier": "PaymentClientRequest",
   "supportedPaymentMethods": [{
     "paymentMethod": "https://bankdirect.net",
     "payeeAuthorityUrl": "https://payments.bigbank.com/payees/86344"
     "paymentMethod": "https://supercard.com",
     "payeeAuthorityUrl": "https://secure.cardprocessor.com/payees/1077342"
   "paymentRequest": {
     "payee": {
       "commonName": "ET Phone Home",
       "homePage": "etphonehome.com"
     "amount": "25.50",
     "currency": "EUR",
     "nonDirectPayment": {
       "type": "RECURRING",
       "interval": "MONTHLY",
       "fixed": false,
       "expires": "2022-04-13T00:00:00Z"
     "referenceId": "754329",
     "timeStamp": "2020-04-12T06:04:12Z",
     "expires": "2020-04-12T06:35:00Z",
     "software": {
       "name": "WebPKI.org - Payee",
       "version": "1.00"

How is FAPI going to handle VRP?


More information about the Openid-specs-fapi mailing list