...
Adapt API Guidelines to ICM Security and Interoperability Profile - https://github.com/camaraproject/Commonalities/pull/208
- Agreed in ICM: https://github.com/camaraproject/IdentityAndConsentManagement/issues/160
- Mark raised the point about diversity of using either authorization code flow and/or CIBA but we need to be careful. Straightforward question: Is it one of the either or both? do we mandate something?
- Axel Nennker opened a discussion in ICM but with no real result of a global direction because it'is up to API implementation.
Sub-project can indicate if & how they are supported CIBA. I, Axel, do not know how they can indicate CIBA support in their YAML files. Also, openid discovery does not help because the metadata allows to express support for flows on a AZ global level through grant_types_supported not on an API level and not on an API endpoint level. Maybe subprojects can "indicate" support or requirement for CIBA somewhere - to be acted upon at onboarding time - but not on a technical level e.g. in the yaml file. So, telcos do not know which flow must be supported by an API and API consumers do not know which flow is supported or needed by an API by looking at the API's yaml file.
- Diego González Martínez raised that we need to decouple the "how the developer get auth flow accepted" from "how we manage several possible auth flow for one API". Also said that from his point of view, discussion mentioned by Axel was about security schemas but not for the topic raised by Mark.
- We can have a 'decision' at sub project level to 'device' which authorization flow will be supported. Need anyway to see how this 'information' will be communicated.
- Move this discussion in ICM.
- Axel Nennker opened a discussion in ICM but with no real result of a global direction because it'is up to API implementation.
- Alignment with Release Management and ICM for Release Candidate
...