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

[Anders Rundgren]

Hi Torsten,
I very much appreciate your responses below because they add meat to the discussion.

If we stick to the FAPI/OpenID work it seems that this has to date been very focused on security and with OAuth at the center.

There is nothing wrong with that but very little time has been spent on more high-level issues like how payments systems can be architected.
OBIE's adaption of FAPI supports the CMA order but the result is not comparable to proprietary payment solutions.

There is no wallet and there is no defined Merchant interface to the PSU/SCA Device or to the PISP.

Regarding what you say about FIDO and cookies, this is of course correct.  However, for payments you can do things quite differently without necessarily introducing vulnerabilities.  As an example you can encrypt a locally generated payment authorization which thus can be sent through (security-wise) untrusted Merchants:
https://cyberphone.github.io/doc/payments/payment-decentralization-scheme-1a.pdf
Why on earth would you do that???  Well, this is the discussion the FAPI WG never had.

The upgraded Embedded SCA mode would presumably use such methods.

Regards,
Anders


On 2020-07-26 19:08, Torsten Lodderstedt wrote:
> 
> 
>> On 26. Jul 2020, at 18:59, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>
>> On 2020-07-26 18:38, Torsten Lodderstedt wrote:
>>>> On 26. Jul 2020, at 18:21, Anders Rundgren <anders.rundgren.net at gmail.com> wrote:
>>>>
>>>> On 2020-07-26 17:52, Torsten Lodderstedt wrote:
>>>> <snip>
>>>>>>
>>>>>> My turn for a question: do you think FAPI/OBIE should follow BG?
>>>>> Why should we? The whole embedded stuff is contrary to any security best practice.
>>>>
>>>> Essentially you are saying that Apple Pay and EMV doesn't work.
>>> No, I’m saying the BG embedded SCA mode contradicts best security practice.
>>
>> It can be as secure as the targeted payment scheme is.
> 
> Secure and best security practice are two different things. Best security practice refers to a set of practice that most people would accept as reasonable and battle proven. One of those practice is not to share credentials with other parties. This significantly reduces the attack surface. Most modern standards are built on this practice (or better but design principle). Cookies are sent to the originator only, FIDO 2 assumes the party creating the key pair is the party using the key pair. As long as one works within this corridor, things are simple, well understood and easier to secure.
> 
> One can also secure the embedded mode, but it comes at a price, complex liability rules and regulatory obligations and incompatibility with current and emerging web (security) technology.
> 
>>
>>
>>> I’m not an expert in payments, but here is my take:
>>> Apple Pay works differently as the credit card is tokenized and I assume Apple never sees the user’s credentials with the bank.
>>
>> Correct.  This can be achieved with a suitable Embedded SCA scheme which then can offer a payment experience that is comparable to Apple Pay which is the explicit goal.
> 
> Don’t you see the contradiction? Embedded SCA == PSU credentials are handled by 3rd parties (Apple in this case).
> 
>>
>> That's all.
>>
>> Regards,
>> Anders
>>
>>> EMV at the POS is closer to the embedded mode as everything, including the PIN, goes through the terminal. Security is ensured by tight control over the participants - the whole approach is everything but open.
>>> In online use cases, 3DS uses the break out to let the issuer ask the user for her credentials, which is more OAuth alike.
>>> The world is a bit more complicated than black and white.
>>>>
>>>> Regards,
>>>> Anders
>>>>
>>>>
>>>>
>>
>