[Openid-specs-fapi] BG/Embedded SCA - Clinically free from OAuth

Anders Rundgren anders.rundgren.net at gmail.com
Sun Jul 26 12:10:31 UTC 2020

On 2020-07-26 13:10, Torsten Lodderstedt wrote:
>> Am 26.07.2020 um 06:11 schrieb Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:
>> OAuth was designed for three parties: Client (TPP), User, and AS/SP.
>> Commerce introduces a forth, semi-trusted party: the Merchant.
> I don’t understand the distinction. Why couldn’t the merchant be a client?

This is technically possible but requires the Merchant to be a regulated entity which only fits very large Merchants.

>> Although working, the unwanted side effects of this "overloading" are plenty and well documented.
>> The BG Embedded SCA proposal does therefore not build on OAuth.
> BG originally didn’t support OAuth at all, in my perception due to non technical reasons. That’s the reason why OAuth was added later on as separat SCA method instead of using it as underlying framework for all SCA modes (like in UK OB).
>> The client is assumed to have a static and (per scheme) standardized payment credential, like in Apple Pay.
> What is the client then in this approach?

There is no client in OAuth terms, the TPP is effectively a traditional backend processor:
  Merchant->User/Device // Request payment
  User/Device->Merchant // Authorize request
  Merchant->TPP // Commit payment order
  TPP->Bank // Initiate payment using a single authenticated & authorized request

Saturn takes this [since decades back established] concept one step further by replacing the TPP with a trivial identity service ran by the Merchant's Bank.  That is, reusing the four corner model.  I thought I was alone with this crazy/genial idea but I have recently found other folks pushing the very same concept!

Target market: https://www.linkedin.com/posts/andersrundgren_is-this-worrying-visa-mastercard-amex-activity-6692882302978035712-koGA


>> In fact, you could actually use Apple Pay.  This takes Open Banking to the PoS terminal.
>> Now you may think that I'm advocating the adoption of this scheme by FAPI/OBIE?  Actually I'm not because the BG proposal have pretty serious downsides from a Standardization, Implementation, and Innovation point of view.
>> Anders
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

More information about the Openid-specs-fapi mailing list