Representation of Client-Initiated Backchannel Authentication (CIBA)

I'd like to raise a concern with including CIBA in the OAuth Flow Object in 3.2.0.

I understand that CIBA can, feasibly, be implemented using bare OAuth 2.0 but realistically it's an OpenID Connect profile. A user is correlated by the Authorization Server using login_hint, id_token_hint, etc - these are OpenID Connect features.

I think there needs to be a separation-of-concerns between OAuth 2.0 and OpenID Connect in OpenAPI. The semantics of OpenID Connect provides proofs-of-authentication, with support for request objects, ID tokens, et al. OpenID Connect obviously builds on top of OAuth, but if we go down the road of starting to bundle OpenID Connect profiles into the OAuth Flow it has the potential to get pretty messy .

I propose an alternative approach:

• OAuth Flow object stays as is. This is well known, and medalling with it might be a step backwards.
• New OpenID Connect object, building on the existing pointer to discovery metadata through openIdConnect property. Implement with a description of how to process that metadata for various profiles such as:
  • Bare OpenID Connect
  • FAPI 1.0 Advanced and FAPI 2.0
  • CIBA

I think that if we did it this way we can avoid duplicating OpenID Connect Discovery metadata in OpenAPI, and instead allow that to live where it needs to i.e. in the discovery endpoint. Implementing OpenID Discovery is a common practice, so I think we are in a good place to leverage an existing, external metadata source.

The descriptions - and maybe a nice JSON Schema as an addendum that we provide to be helpful - will then help tooling makers make sense of the discovery metadata from the lens of OpenAPI.

Happy to get involved if this approach is perceived as a good idea. I know OpenID in enough to detail to be vaguely useful.

Start by reviewing the OAuth Flow Object in the OpenAPI 3.2.0 context and the existing openIdConnect property. The issue does not mention repository files or tests, so first map where these specification objects are defined and how CIBA is represented. Done would require an agreed approach for separating OpenID Connect profiles from the OAuth Flow object.