[Openid-specs-fapi] Issue #295: Possible support for "embedded" SCA mode (openid/fapi)

Thu Jun 4 18:03:37 UTC 2020

It makes sense to have the oAuth2 protocol revisited and cleanly extended
to support the embedded approach.

For compliance with PSD2's RTS, the design of the SCA flow shall
- give the final decision of selecting the authentication/authorization
flow to the ASPSP (AS/RS)
- allow the TPP (Client) to provide flow preferences like the NextGenPSD2's
"TPP-Redirect- Preferred" flag.
- PSD2's RTS will even allow ASPSP's to exempt transactions from SCA.

As for the conversion on this list earlier today, some sort of
pre-authorization
request (like PAR, CIBA, ...) shall allow the ASPSP (AS/RS) to decide on
how to proceed with the authentication/authorization flow.

I also mentioned mixed flows in my earlier response below, there is still a
big misconception between authentication and authorization. Authorization
barely involves permanent credentials. PSD2's RTS requires iherence between
transaction data and the second factor used for authorizing that
transaction.

@Ralph
Embedded is not about disclosing the password of the user to parties. There
is enough technology out there to mitigate this.

/Francis

>
> Message: 4
> Date: Thu, 4 Jun 2020 14:53:34 +0000
> From: Ralph Bragg <ralph.bragg at raidiam.com>
> To: Francis Pouatcha <fpo at adorsys.de>, Dave Tonge
>         <dave.tonge at momentumft.co.uk>
> Cc: Financial API Working Group List
>         <openid-specs-fapi at lists.openid.net>, Anders Rundgren
>         <anders.rundgren.net at gmail.com>
> Subject: Re: [Openid-specs-fapi] Issue #295: Possible support for
>         "embedded" SCA mode (openid/fapi)
> Message-ID: <8548BEAA-44AD-40B0-AB8C-77A47A1A7EEE at raidiam.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the commentary Francois. Apart from the security issues and the
> existential challenge that having a body that?s concerned with identity and
> good security practices implement a mechanism to facilitate user
> impersonation, the primary technical challenge I have around imbedded is
> the practicality of biometrics as called out by the EBA Opinion.
>
> The last time that this body and the OBIE considered how to facilitate a
> request to convey credentials as a ?hint?, the prevailing recommendation
> was to standardize a login_token_hint as part of a CIBA flow. Either a CIBA
> or Device Flow can be used to facilitate POS journeys and they have been
> documented and published by the OBIE.
>
> We stopped short of publishing the formats for login_token_hint because of
> the variability however recommendations are made to ensure that the ID
> isn?t guessable or it includes input binding. There is nothing stopping a
> CIBA flow being initiated with a token of  {userId: rbragg, password:
> this_is_a_sub_optimal_suggestion } a bank can choose to ignore the ?hint?
> of a password or take it on face value. I personally would prefer to
> describe conceptually via unofficial communications how this can be done
> rather than condone or encourage the practice of users surrendering
> passwords to parties to whom they are not intended and that have completely
> reasonable technical alternatives that offer far greater security and
> privacy benefits.
>
> My 2c ? be interested in others views.
>
> From: Francis Pouatcha <fpo at adorsys.de>
> Date: Thursday, 4 June 2020 at 15:36
> To: Dave Tonge <dave.tonge at momentumft.co.uk>
> Cc: Financial API Working Group List <openid-specs-fapi at lists.openid.net>,
> Anders Rundgren <anders.rundgren.net at gmail.com>, Ralph Bragg <
> ralph.bragg at raidiam.com>
> Subject: Re: [Openid-specs-fapi] Issue #295: Possible support for
> "embedded" SCA mode (openid/fapi)
>
> Thanks for sharing Ralph,
>
> - From a legal perspective, many ASPSP still provided AIS and PIS to their
> customers through embedded interfaces. As long as this occurs, TPP will
> keep fighting to obtain the same privileges, as the embedded approach
> provides the smoothest user experience.
>
> - From a technical perspective, there is a huge misunderstanding around
> authentication and authorization in the open banking space. Many frictions
> caused by multiple SCA, multiple redirections are due to the fact that
> initial open banking market initiatives did not draw clear lines between
> "authentication" and "authorization" of the PSU.
> --> Authenticating a PSU with the purpose of establishing a session
> between the PSU -> TPP -> ASPSP can occur once, can be well done using
> redirection and can be durable.
> --> Authorizing a payment or additional account access is very tight to
> banking business logic and should be embedded inside the PSU -> TPP
> interface,
> ----> as there is a dynamic linking between transaction data and the
> second factor (TAN, signature, ...)
> ----> as this will take away all hazard associated with involving unwanted
> third parties in this interaction, including the leakage of transaction
> data embedded into unencrypted jwt token in browser caches, ...
> ----> as this will allow TPP to provide frictionless banking interfaces to
> PSU
>
> - We also witness the EBA here mentioning the PoS use case that does not
> work with mandatory redirection.
>
> From this EBA opinion paper, you can see the embedded approach is still a
> battleground between TPPs and ASPSP in the EEA open banking space. This
> battle will continue till we have well implemented reference practices that
> are secure and smooth on the market.
>
> IMHO the final solution will move toward having hybrid solutions with
> redirected authentication and embedded authorizations.
>
> This I reraised the point of reconsidering the embedded approach.
>
> @Dave Tonge<mailto:dave.tonge at momentumft.co.uk> Where do I find the
> previous discussion or FAPI change request related to the embedded approach?
>
> Best regards.
> /Francis
>
> On Thu, Jun 4, 2020 at 8:10 AM Dave Tonge <dave.tonge at momentumft.co.uk
> <mailto:dave.tonge at momentumft.co.uk>> wrote:
> Thanks for sharing Ralph - its an interesting document.
>
> We had a discussion with Francis Pouatcha who brought the issue up again -
> as a way of helping harmoisation efforts with the Berlin Group and banks
> that have implemented their standards.
>
> --
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200604/82f32764/attachment-0001.html>