Align FAPI-CIBA to FAPI2-baseline/advanced

[Joseph Heenan]

Should we somehow align FAPI-CIBA to FAPI2?

Currently FAPI-CIBA requires signed request objects in the backchannel; if it was being used in a FAPI2-baseline ecosystem it would make sense to use unsigned requests.

[Joseph Heenan]

This was discussed on today's working group call, but I'm not sure we came to a clear conclusion. (If someone thinks we did, please do add an update!)

The discussion was yes, FAPI-CIBA probably should align to FAPI2-base/adv in terms of signed request object vs passing request as url parameters to the CIBA endpoint. There was further discussion about how FAPI-CIBA is duplicated many of the requirements in FAPI2-base and it would be nicer for everyone if it didn't do that.

I mentioned that the clean way to do that would be to separate FAPI2-baseline into two separate topics - generic things that apply to all interactions with the AS (like TLS 1.2, ciphers, client auth, sender constraining access tokens, jws algs, etc) vs the things that are specific to the authorization code grant / front channel redirects (like use of the PAR endpoint).

[Torsten Lodderstedt]

I support the alignment of FAPI-CIBA with the FAPI 2 baseline profile. The modularization also seems reasonable to me. However, modularization of specs also leads to a more complex document structure, which might be an obstacle for developers. Alternatively, CIBA-FAPI could replace the duplication with references to the respective clauses in FAPI 2 baseline.

[Dave Tonge]

We discussed this on the call today.

@Dima Postnikov and @Dave Tonge will look into it

[Nat Sakimura]

Dima will look into it after the CIBA PR is merged.