Align securitySchemes and security of QOD API spec with IdentityAndConsentManagement

[hdamker]

Problem description
QoD API need to be aligned with the upcoming released version of documents in https://github.com/camaraproject/IdentityAndConsentManagement

Possible evolution
Adapt securitySchemes as defined in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md when it is released (dependent on at least issue camaraproject/IdentityAndConsentManagement/issues/57 and related PR camaraproject/IdentityAndConsentManagement/pull/93).

Alternative solution

Additional context
For all or some QoD API endpoints client_credentials might be an allowed grant type if certain prerequisites are given.

[jlurien]

Hi @hdamker, PR camaraproject/IdentityAndConsentManagement#93 is already merged and issue closed in I&CM. We should proceed adapting QoD to it. Do you think we should align v0.10 or wait for a next one?

[hdamker]

v0.10.0 is already in rc2 and therefore out of the door. We marked this issue as "enhancement" for the next release.
For applying scopes which allow the "wildcard" scope we might need also to think about splitting sessions and profiles in two APIs.

[jlurien]

v0.10.0 is already in rc2 and therefore out of the door. We marked this issue as "enhancement" for the next release. For applying scopes which allow the "wildcard" scope we might need also to think about splitting sessions and profiles in two APIs.

Splitting the API may have all sense. BTW, we are facing some new use cases where QoS profiles may be used by other APIs as well, so that would ease reusing this functionality.

[hdamker]

Agreement within QoD Call Feb 9th: the split of QosSessions and QosProfiles to be done first (#265).