Page Comparison

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Community Attendees:

Axel Nennker Jesús Peña García-Oliva Sébastien Dewet Jan Friman

Community Attendees:

Ming Hui Surajj Jaggernath

LF Staff:

Agenda

Antitrust Policy

Minutes

Topic Create ICM Release Plan

Jesús Peña García-Oliva says ICM is going to handle that during Axel's vacation.

Topic Commonalities Adapt to ICM Security and Interoperability Profile → CONTEXT: https://github.com/camaraproject/IdentityAndConsentManagement/issues/160

Main question: Should the security schemes created by ICM be in CAMARA APIs access and user consent management or be moved into Commonalities API Guidelines?

Axel's paraphasing of the arguments presented. → Jesus added comment's as well but I think we should remove what is written... Minutes are minutes, the discussions are on github. We should use the minutes for the things mentioned in the call, not to replicate some of the discussions here.

Pro moving arguments:

- API Design guidelines should be in one place and not be scattered into several.
- OpenAPI Definitions should be in one place which is currently the API Design Guidelines document
- There is precedence that release management created guidelines that are now part of Commonalities documents.
- Camara_common.yaml is also a Commonalities document

Contra moving arguments:

- Specifically for this securitytSchemes issue, it is a very polarising issue that took weeks to agree and required a TSC escalation and decision, and it is already happening (with all the overhead and confusion that entails) that there is more than one open issue in Commonalities, API subprojects, slack messages and even multiple issues in ICM just related to security schemes. Having this information in the ICM would allow us to have better control over it, and also guide CAMARA participants to the decisions made by the ICM and TSC, avoiding overhead and confusion.
- The security scheme expertise is in ICM and future changes are easier to do if security schemes and info.description are in an ICM document.
- ICM, as Commonalities WG, also provides guidance to API subprojects and this is well-known.
- These guidelines are the result of work done in the ICM and are documented in a document under the ownership of the ICM
- For a document reader perspective, it is just one click browsing github documentation, which means nothing. There are many other references like that in the API design guidelines or the ICM profile itself and it is not a problem. It's like browsing through Confulence pages...

Options:

- move openapi definitions to API Design guidelines
- keep security scheme and info.description in access and user consent
- ~~create a new document Camara-OpenAPI-defintions.md (at Commonalities or at ICM?) that contains API Design guidelines section 11 and security schemes and info.description~~
- your option here

Topic Provide API Design guidelines for OAuth2 client credentials

Axel's arguements why there should be guidelines on OAuth2 client credentials

There was an TSC agreement in December that we have one security scheme that is openid. In the meantime we now have APIs that are client credentials only and therefor it makes sense to revisit that agreement.

What is currently happening is that APIs, like PopulationDensigity, that had OAuth2 client credentials security schemes in their yaml files have PR removing that.

I think API consumers benefit from knowing which flow is applicable. OpenID discovery does not provide that information because the OP describes which flows are supported in general not per-API.

When it comes to clients credentials then I think there should be different endpoints with or without parameters that identify the user/device. After OIDC or CIBA the access token has an association with the subject, so no parameter is needed.

With client credentials the subject identifier is needed.

Example:

```

/sim-swap

elisabeth.mueller@ericsson.com kindly agreed to propose text in #160

Topic Provide API Design guidelines for OAuth2 client credentials

Topic Adapt info.description to Security and Interoperability Profile

Topic Add text regarding oauth2ClientCredentials

Topic Proposed text on network-based authentication

Topic Management of opt-out with Implicit consent (legitimate Interest)

Topic Is the service API meant to validate the content of the access token and compare this against the API parameters ?

Clarification requesting.