DRAFT AGENDA
...
Representative | Organization | Role | |
---|---|---|---|
Deutsche Telekom AG | TSC Chair, Active Maintainer | ||
Deutsche Telekom AG | Active Maintainer | ||
Ericsson | Active Maintainer | ||
KDDI | Active Maintainer | ||
Orange | TSC Deputy Chair, Active Maintainer | ||
Radisys | EUC Representative | ||
Summit Tech | EUC Representative | ||
Telefonica | Active Maintainer | ||
Telefónica | Active Maintainer | ||
Verizon | EUC Representative | ||
Vodafone | TSC Deputy Chair | ||
Vodafone | Active Maintainer | ||
Vonage | Active Maintainer | ||
George Glass | TM Forum | TM Forum Representative | |
TM Forum | TM Forum Representative | ||
GSMA | GSMA Representative | ||
GSMA | GSMA Representative |
...
- New proposal how to manage "API Families" as Sub Projects with one lead repository and multiple API "family member" repositories (#142)
- Herbert Damker Proposal changed based on the feedback within the comments: no "lead repository" for a Sub Project, but a Sub Project / API Family will be a set of 1 to n equal repositories to describe, develop, document and test the APIs (family members). The link between the repositories is the home page of the Sub Project within the wiki
- Pull request to be reviewed: https://github.com/camaraproject/Governance/pull/146
...
- Create ICM Release Plan - #146:
- The team agreed to proceed with a release candidate directly, bypassing the alpha release, given the stability and closed scope of the current state.
- Proposal to protect the /authorize endpoint for the Authorization Code Flow (Auth Code Flow) - RFC9101 - #128
- Issue 128 will be excluded from the current release, and the scope is now fully defined, allowing the team to proceed with generating the release candidate.
- Is the service API meant to validate the content of the access token and compare this against the API parameters ? - #174
- There is a recognition of the need for validation of access tokens but differing views on the feasibility and scope of standardization. Some participants suggested documenting standard claims in access tokens, while others emphasized the need to leave implementation details to individual operators.
- OIDC authorization code flow and/or CIBA - #176
- GSMA highlighted the need for clarity on which authorization flow operators should implement when onboarded in Open Gateway.
- ICM feedback: The decision on which authorization flow to implement is more of a business decision than a technical one. Operators should support the flows defined by CAMARA and be compliant with ICM Security & Interoperability profile, but specific implementation can be decided based on business needs and regulatory requirements. For instance, an operator using only one API that requires a specific flow can choose to implement just that flow if it's allowed by the business decision of Open Gateway. For specific APIs with unique requirements, the auth flow to implement may be dictated by the API's functionality (such as Number Verification API) and be documented by the API subproject.
...