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

Francis Pouatcha fpo at adorsys.de
Mon Jun 8 14:01:50 UTC 2020

On Fri, Jun 5, 2020 at 2:59 AM Ralph Bragg <ralph.bragg at raidiam.com> wrote:

> 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.
> I documented a sample open banking workflow in the ticket:
. This can serve as a basic input for the specification of the embedded

Francis Pouatcha
Co-Founder and Technical Lead at adorys
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200608/db051e28/attachment-0001.html>

More information about the Openid-specs-fapi mailing list