ciba-grant-3.2.0.md

[shilpa-padgaonkar]

Below are details of the proposed changes in this PR to add CIBA grant flow:

• The supported OAuth flows list has been extended with the CIBA flow

• The OAuth flow object is extended with 3 new fields for CIBA
• The authorizationUrl and tokenUrl fields are updated to specify that they are also applicable for the CIBA flow

• The OAuth flow object example is extended with a CIBA flow example

This PR:
Fixes #3587

Branch and file used:

• 3.2.0 spec: v3.2.0-dev branch, versions/3.2.0.md

[LasneF]

@shilpa-padgaonkar :

we should upgrade as well the schema
https://github.com/OAI/OpenAPI-Specification/blob/v3.2.0-dev/schemas/v3.1/schema.yaml

@handrews this raise the point that the 3.2 should have its own schema version (compatible but still its own version)

to me the delivery mode should be an enum following the acceptable values
"backchannel_token_delivery_mode: REQUIRED. One of the following values: poll, ping, or push."

about user code , we may need to include it as part of the sample
not sure if as well it should not be a boolean , not clear why a string array

another point should it be called ciba , or should it be called backchannel as the OIDC spec mentionned those name as of parameter (ie it s just a legitimate question , to me ciba is fine as pointing the precise concept, not aware if there are other back channel technology leveraging those concept)

[darrelmiller]

Could you help me understand why there is a need for a new OAuth2Flow when this information could be communicated via an OpenIDConnect configuration document considering it is an OIDC specific flow?

[AxelNennker]

Could you help me understand why there is a need for a new OAuth2Flow when this information could be communicated via an OpenIDConnect configuration document considering it is an OIDC specific flow?

Hi @darrelmiller although it sounds like "OpenID Connect Client-Initiated Backchannel Authentication Flow" is the same as OpenId Connect is is not.
Also an OpenId Provider can offer CIBA and Authorization Code flow and then the API consumer would not know if the API only allows CIBA (or is intended to be used with CIBA).

This idea of introducing ciba to OAI comes out of the Camara project where we discovered the need to specify this flow.
Many Camara APIs use CIBA. Many APIs from MobileConnect also use CIBA but the flow was communicated offline and not documented in the e.g. openapi.yaml. We found that the flow should be part of the Camara API specification, and here we are.
Hope this explains why we need this and why openIdConnectUrl is not enough.

[shilpa-padgaonkar]

@LasneF : Thanks for your feedback.

• I have updated the schema files.
• fixed the type of ciba_user_code to boolean
• for ciba_delivery_modes, it is also possible that not just one, but rather 2 or all 3 of the delivery modes are selected.

[lornajane]

Sorry, I know we've had some back-and-forth on the schemas, but since this change won't go into 3.1, it would be better to omit the schema updates from this pull request (the 3.2 schemas haven't been created yet), we can't merge this pull request with these schema changes in.

[darrelmiller]

OpenAPI uses camelCasing for parameter values. So although the CIBA specification uses snake case, for consistency we should require tooling to do the translation and maintain consistency in the OpenAPI description.

[darrelmiller]

Remove OPTIONAL keywords and change casing of parameters

[handrews]

@darrelmiller

Remove OPTIONAL keywords and change casing of parameters

I presume you meant "Remove OPTIONAL from keywords..." rather than removing the keywords marked OPTIONAL

[shilpa-padgaonkar]

Sorry, I know we've had some back-and-forth on the schemas, but since this change won't go into 3.1, it would be better to omit the schema updates from this pull request (the 3.2 schemas haven't been created yet), we can't merge this pull request with these schema changes in.

@lornajane Reverted schema changes

[shilpa-padgaonkar]

@darrelmiller Done changes for camelCase. Kindly check.

[lornajane]

Thank you for being patient with us and working through the amendments.

changes were made