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

Torsten Lodderstedt torsten at lodderstedt.net
Sun Jul 26 11:10:47 UTC 2020



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

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

> 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/4e7a910e/attachment.p7s>


More information about the Openid-specs-fapi mailing list