...
| 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 | not Active Maintainer | ||
TelefónicaTnot removedelefó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 |
...
API Backlog (Ricardo Serrano Gutierrez )
- Herbert Damker Two new API Proposals are forwarded by the API Backlog working group to the TSC (see https://lists.camaraproject.org/g/tsc/message/195)
- Device Connection Quality Indicator
- Device data Volume
- Both are intended to be part of the DeviceStatus Sub Project (agreed with their Maintainers)
- Herbert Damker There are currently two approaches to define an API which delivers the network type a device is currently connected to
- Within DeviceStatus: https://github.com/camaraproject/DeviceStatus/issues/143 with PR
- Within ConnectivityInsights: https://github.com/camaraproject/ConnectivityInsights/pull/40 (see also https://github.com/camaraproject/ConnectivityInsights/issues/48)
- How to avoid and resolve such situations?
- ...
Commonalities (Rafal Artych )
- Release 0.4.0-rc.1 - in preparation
- All PRs missing in alpha merged, new fixes proposed (PR#229, PR#234, PR#236, PR#238)
- Device object simplification https://github.com/camaraproject/Commonalities/pull/233:
Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios - Annex to API Design Guidelines
networkAccessIdentifier not removed from Device object, but not allowed in Commonalities 0.4.0 (Fall24 release)
- Device object simplification https://github.com/camaraproject/Commonalities/pull/233:
- All PRs missing in alpha merged, new fixes proposed (PR#229, PR#234, PR#236, PR#238)
Identity & Consent Management (Jesús Peña on behalf of Axel Nennker )
- 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 frm 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.
...