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

[Ralph Bragg]

Hi,

Glad to see that CIBA might solve the use case, having a flow where the UI/UX isn’t interrupted for a TPP was a significant driver for the inclusion of this in the OBIE specs. Authorization becomes optional / configurable and identity is what ever is agreed as part of the market initiative specification for login_hint or id_token.

I personally think of CIBA as more as a decoupled authorization rather than authentication protocol and using the standard id_token_hint or login_token_hint will allow TPP’s to persist and assert an identity of a PSU that a bank can rely on. Technically there’s nothing stopping a TPP asking for the same experience with a redirect.  The format of login_hint as defined in OIDC Core could be a signed object which in turn could be wrapped in a signed request. A TPP can already indicate that an ASPSP should not perform any additional authentication or authorization by including the prompt=none on a redirect https://openid.net/specs/openid-connect-core-1_0.html

An ecosystem specification could require that ASPSPs ensure that the authentication mechanisms available to a PSU are conveyed in an id_token to a TPP for the purposes signalling if a PSU supports a CIBA flow. This would be quite useful but personally something I see that a market initiative will need to specify as the non-technical requirements for the delay and ux that different mechanisms of asynchronous AuthZ/AuthN have will be acceptable or not-acceptable to different markets and indeed different TPPs!


  *   If there is a need to ‘discover’ the authentication mechanisms a customer supports
  *   A market initiative deems this to be critical
  *   And it needs to be done before a TPP initiates a transaction that may require additional authorization
  *   And a TPP has a means of asserting the identity of the calling PSU

I’d suggest a market initiative could require Banks accept either a redirect. { prompt=none, response_type= id_token, scope=openid, claim=available_authn_mechanisms?, login_hint={signed id} or CIBA equivalent to be given an id_token without any user interaction.

This would then allow a TPP to make a choice based on the mechanisms available to a PSU
All of this can be done with the existing standards using FAPI profiles.

Another market initiative extension might be useful is to include as part of the CIBA request_context an indication that the TPP takes full responsibility for AuthN and AuthZ capturing. An ASPSP can then either reject the request because it can’t fulfil those requirements (say as a result of TRA or a PSU opting into Bank only AuthZ reconfirmation) or ignore them.

If you could provide a list of the use cases and scenarios I’d be happy to confirm if they’ve been considered in any of the jurisdictions that FAPI is being considered and what options for the specs were suggested.

Cheers,
Ralph

From: Francis Pouatcha <fpo at adorsys.de>
Date: Friday, 5 June 2020 at 03:15
To: Ralph Bragg <ralph.bragg at raidiam.com>
Cc: Openid-specs Fapi <openid-specs-fapi at lists.openid.net>, Dave Tonge <dave.tonge at momentumft.co.uk>, Anders Rundgren <anders.rundgren.net at gmail.com>
Subject: Re: Issue #295: Possible support for "embedded" SCA mode (openid/fapi)

Hello Ralph,

On Thu, Jun 4, 2020 at 2:49 PM Ralph Bragg <ralph.bragg at raidiam.com<mailto:ralph.bragg at raidiam.com>> wrote:
Hi,

Sure – could you perhaps assist with this and call out where you feel the current standards are lacking with a comparision specifically to the clauses in FAPI Redirect (1 or 2) and FAPI CIBA that would not facilitate either of the approaches that you’re suggesting?
I am not talking about FAPI or NextGen, but about the PSD2 RTS. It uses the word SCA (Strong Customer Authentication) to cover Authentication of the PSU and Authorization of the transaction. This is where the confusion starts. Authentication shall only be a consequence of the authorization. Both of them handled separately would have kept overall framework simpler and less ambiguous.

I’m particulary interested in what’s missing from OAuth and OIDC discovery that advertises what mechanisms an ASPSP supports for use by TPPs (CIBA or Redirect (and every flavour) off?
-> I appreciate the way oAuth and OIDC deal with AS/OP metadata.
-> In the context of Open Banking, passing Client/RP metadate to the AS through dynamic client registration is sort of static, as an authorization process depends not only on AS/OP and Client/RP capabilities, but also on many situational elements accounting the RO/PSU device, the nature of the transaction (amount to pay, permissions requests) and some dynamic risk factor like the location or the moment at which the transaction is taking place.

I’m also really interested in where the current standards would preclude the use cases that are trying to be achieved in particular the profile of CIBA as we crafted at the OBIE would allow Banks to choose to opt out of SCA RTS or even allow customers to choose to opt out of SCA (or even any authentication) if they chose too. The id_token_hint instead of the login_token_hint would allow a Bank to essentially delegate this flow a TPP. Essentially using the token as a credential however this credential was issued to the TPP not given by a PSU to a TPP.
Just read. through ciba. Looks actually designed for asynchronous authorization. In my first look  overloaded for embedded, as. some ASPSP might offer embedded without having to offer decoupled SCA.

This is really pertinent given the Australians are looking at ‘What next’ for their decoupled flows and it would be good to cover all basis.
Yes...


Cheers,
Ralph

From: Francis Pouatcha <fpo at adorsys.de<mailto:fpo at adorsys.de>>
Date: Thursday, 4 June 2020 at 19:03
To: Openid-specs Fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>>
Cc: Ralph Bragg <ralph.bragg at raidiam.com<mailto:ralph.bragg at raidiam.com>>, Dave Tonge <dave.tonge at momentumft.co.uk<mailto:dave.tonge at momentumft.co.uk>>, Anders Rundgren <anders.rundgren.net at gmail.com<mailto:anders.rundgren.net at gmail.com>>
Subject: Re: Issue #295: Possible support for "embedded" SCA mode (openid/fapi)

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<mailto:ralph.bragg at raidiam.com>>
To: Francis Pouatcha <fpo at adorsys.de<mailto:fpo at adorsys.de>>, Dave Tonge
        <dave.tonge at momentumft.co.uk<mailto:dave.tonge at momentumft.co.uk>>
Cc: Financial API Working Group List
        <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>>, Anders Rundgren
        <anders.rundgren.net at gmail.com<mailto: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<mailto: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<mailto:fpo at adorsys.de>>
Date: Thursday, 4 June 2020 at 15:36
To: Dave Tonge <dave.tonge at momentumft.co.uk<mailto:dave.tonge at momentumft.co.uk>>
Cc: Financial API Working Group List <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>>, Anders Rundgren <anders.rundgren.net at gmail.com<mailto:anders.rundgren.net at gmail.com>>, Ralph Bragg <ralph.bragg at raidiam.com<mailto: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<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><mailto: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/


--
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/20200605/1eccdc6a/attachment-0001.html>