Agenda
Antitrust Policy
Commonalities Adapt to ICM Security and Interoperability Profile
Adapt info.description to Security and Interoperability Profile
Management of opt-out with Implicit consent (legitimate Interest)
Minutes
Topic Create ICM Release Plan
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. → Jesús Peña García-Oliva I added comment's as well below for clarity 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 Jesús Peña García-Oliva I'm not going to complete this part, 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.
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 metadata describes which flows are supported in general but not per-API.
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)
Next meeting: https://lists.camaraproject.org/g/sp-icm/viewevent?repeatid=57069&eventid=2345744&calstart=2024-06-19