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

Torsten Lodderstedt torsten at lodderstedt.net
Sun Jul 26 12:31:33 UTC 2020

> Am 26.07.2020 um 14:10 schrieb Anders Rundgren <anders.rundgren.net at gmail.com>:
> 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.

Understood. The need to be regulated entity in order to get access to the bank‘s API is a fundamental limitation/obstacle built into PSD2.

Architecture wize, open banking could be much simpler since it removes the need for a forth corner. The need for regulation in PSD2 kind of re-intrudes it since a merchant needs to work with a TPP (instead of its Bank or acquirer).

>>> 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!

But TPP and Akquirer act more or less similar, why do you consider the four corner model superior?

> Target market: https://www.linkedin.com/posts/andersrundgren_is-this-worrying-visa-mastercard-amex-activity-6692882302978035712-koGA
> Anders
>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2275 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200726/68173725/attachment.p7s>

More information about the Openid-specs-fapi mailing list