[Openid-specs-fapi] Issue #295: Possible support for "embedded" SCA mode (openid/fapi)
joseph at authlete.com
Thu Jun 4 08:40:03 UTC 2020
> On 4 Jun 2020, at 09:30, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> Hi Joseph,
>> I think there’s definitely an argument for this new endpoint allowing, somehow, for multiple alternative flows (including CIBA or a redirect) to result based on AS/RP capabilities & the situation of which methods the user has available + various risk indicators.
>> Fully appreciate your points about OAuth2 and I’m not sure how cleanly it’s possible to do the above within the constraints of OAuth2.
> What constraints do you have in mind?
I’m not sure, but across the existing RFC/IETF drafts/OIDF specs there are multiple ways of initiating an oauth2 flow, each of which returns it’s own kind of what is essentially a handle for the request, and I’m not sure there’s a neat way for a new endpoint to send the client down alternative paths.
For example, a pushed authentication request might/could contain all the information necessary info for the AS to give an idea of which flows to return. It would be a bit unnatural perhaps to start a flow by sending a request to the new endpoint we’ve invented in this thread, only for the AS to then say “based on that I want you to do a redirect flow, start by resending what you just send me to the pushed authentication request endpoint”. Similarly the CIBA endpoint currently receives roughly the same set of info.
More information about the Openid-specs-fapi