Putting some info from camaraproject/IdentityAndConsentManagement#157 here.
Also from camaraproject/IdentityAndConsentManagement#57
And some TSC discussion
And my interpretation of what TSC might or might not have decided on
camaraproject/IdentityAndConsentManagement#157 (comment)

My understanding is that

  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration

is the default security scheme Camara APIs should use. Especially if personal information is involved in the API.

OIDC is a profile of OAuth2 and OIDC does not forbid OAuth2 client credentials.

But, I find that always just specifying openIdConnectsecurity scheme as a security mechanism for an endpoint does not help API consumers e.g. if the endpoint is CIBA or client credentials protected.
Deferring to discovery does not help because the authorization server might support all kinds of flows and does not provide any info which flow is expected at specific endpoints.

There might be endpoints that use CIBA and then an SMS is sent to the authentication device. But a client might reject CIBA because of the user experience. There might be one endpoint that is OIDC protected and a different one that is protected by CIBA.
A Camara API should be able to express that, and an API client should be able to choose the endpoint that fits its expectations on user experience.

If an API or some of its endpoints do not involve user information than OAuth2 client credentials is totally fine and the API should be able to express that.
E.g. this API seems to be client credentials only
https://github.com/camaraproject/QualityOnDemand/blob/main/code/API_definitions/qos-profiles.yaml
And they define an security scheme for OAuth2 client credentials named oAuth2ClientCredentials.
https://github.com/camaraproject/QualityOnDemand/blob/main/code/API_definitions/qos-profiles.yaml#L131

Which I think is much more meaningful than using the ICM openid defined security scheme.

I think TSC did not forbid the possibility of defining other security schemes. I think that TSC decided that for now discovery is the way to go for OIDC.

I want to state that I fully support the decision to use the openid security in all APIs and endpoints that involve personal information.
BUT if an API endpoint is CIBA protected then the API yaml should express that, and if an endpoint is client credentials protect (hopefully not involving personal data) then the API yaml should express that. And most importantly be transparent to the API consumer.

Discussion on API access mechanism #24

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions