DRAFT
AGENDAMINUTES
Attendees & Representation
| |||||
---|---|---|---|---|---|
Representatives | Organization | Role | |||
Deutsche Telekom AG | Maintainer | x | |||
Deutsche Telekom AG | Maintainer | x | |||
Ericsson | Maintainer | x | |||
KDDI | Maintainer | x | |||
Orange | Maintainer | x | |||
Nokia | Maintainer, Release Manager | x | |||
Telefonica | Maintainer | x | |||
Telefónica | Maintainer | x | |||
Vodafone | Maintainer | x | |||
Verizon | Maintainer | x | |||
EUC Representative | x | ||||
Massimiliano Troiani | Verizon | EUC Representative | |||
Summit Tech | EUC Representative | x | |||
George Glass | TM Forum | TM Form Representative | |||
GSMA | GSMA Representative |
Tip |
---|
Community members may use @name tag to mark their attendance |
Community: Kevin Smith Rafal Artych Artur Krukowski
LF Staff: Casey Cain Evan Harrison
Agenda
The project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF. |
Review and approval of previous meeting minutes
General Topics
Governance & project management issues
API Backlog
Commonalities
Identity & Consent Management
Release Management
Specific Topics
...
Any Other Topics
Minutes
Review and approval of previous meeting minutes
Minutes of previous TSC meeting: 2024-12-05 TSC Minutes
...Previous meeting minutes were approved at 7:06am (PT) on 12/19/24
Action Item Review
See home page Technical Steering Committee for current list of open action items
Action Tanja on API categories: TM Forum will adopt the latest API portfolio categories as defined by GSMA Product Stream for use in the TMF936 Catalog API. A longer list of categories discussed between TM Forum and OGW Business stream concerned the application categories for use in the TMF931 onboarding API.
Action Rafal see below in Commonalities.
Governance & Project Management issues
…
Proposal for execution of Sandbox / Incubated / Graduated approach:
Step 1 (can be started immediately)
Declare all API Repositories which had a release within Fall24 meta-release as “Incubation Candidates”
Keep all Sub Projects which have an “Incubation Candidate” API Repository for now under “Sub Projects”, that are:
CallForwardingSignal
CarrierBillingCheckout
ConnectivityInsights
DeviceLocation
DeviceStatus
EdgeCloud (SimpleEdgeDiscovery)
HomeDeviceQoD
KnowYourCustomer
NumberVerification
OTPValidation
PopulationDensityData
QualityOnDemand
SimSwap
Move all other “Sub Projects” as is to “Sandbox API Repositories”
Create additional wiki pages for Sandbox API Repositories of above remaining Sub Projects (e.g. DeviceDataVolume of Device Status Sub Project)
Step 2:
Evaluate the “Incubation Candidates” according to proposed (and than agreed) criteria until mid of February (3 TSC meetings from now)
Create a new wiki page for each incubated API Repository under “Incubated API Repositories”
Potentially split or (re-)combine Sub Projects (e.g. NumberVerification / OTPValidation)
Change the structure of Sub Project wiki pages structure towards an entry page for the Sub Project and a list of API Repositories belonging to the Sub Project
Discussion:
Differentiating marking within GitHub: use of badges on the README.md and “topics”.
API versioning as initial vs stable decisions are independent of sandbox/incubated, and are done according to rules of Release Management
To be check the requirement for graduation regarding the first stable APIs in term of maturity & market adoption. Probably too early for our APIs.
Decision: Step 1 can be executed.
API Backlog (Jorge Garcia Hospital )
https://github.com/camaraproject/APIBacklog/blob/main/documentation/APIbacklog.md
One new API proposals brought to TSC (1) and one new API enhancement proposal.
New API: Energy Footprint Notification:
API enhancement: Facial Recognition:
Proposed by China Mobile as part of existing ModelAsAService API repository. Original Issue #126. Template available.
The ModelAsAService Sandbox team should consider if they want to develop the API within the ModelAsAService repository or in a separate repository (e.g. to allow participation of contributors who want get only involved into the original ModelAsAService scope)
Decision: enhancement approved - target repository of this API to be decided later.
API Backlog proposal for API management/marketing…:
As in APIBacklog/issues/123 , companies see a suitable feature to have a spot in each repository where participants can be reported, stating the interest of those participant companies for this API.
Current options:
CodeOwner/maintainer list: Includes companies actively leading the API definition, but not companies which participate in a more passive way.
Github contributors tool (e.g./APIBacklog/graphs/contributors ) reports the companies which have participated actively in the API, with e.g. providing code. But does not report companies who passively track the API evolution, e.g. participating in the discussion meetings.
Proposal to create a place where companies can provide their support or willingness to participate in an API, not official as maintainer/codeowner and not providing proper code as in
contributors
.Companies to provide support (or concerns) about this proposal. E.g. wiki page of each repository could host a file where companies can include their support to the API(s)
Decision: Provide a proposal to backlog group about what to be added in the confluence page to track companies supporting the API (without necessarily be code owner and/or maintainer).
Commonalities (Rafal Artych )
Initial Analysis of Commonalities 0.5.0-alpha.1 changes - prepared
based on comments https://github.com/camaraproject/Commonalities/issues/363 opened
can be the starting point to check Commonalities changes needed for Spring25 meta-release
Discussion
APIs should strictly apply semantic versioning regarding breaking changes. Any change that may break an implementation (e.g. changes in error response codes) should be considered as a breaking change
May need to consider the concept of a “marketing version” for APIs when increments in the major version are not associated with any new functionality
https://github.com/camaraproject/Commonalities/issues/352
proposed string pattern:
^[a-zA-Z0-9-]{1,36}$
- possibly breaking change - should it be applied in Spring25?possible enhancement of security requirements for string parameters
Future: explore use of Open Telemetry in relation with x-correlator - W3C Trace Context as a long-term replacement for
x-correlator
?Current implementations of Trace Context here.
Discussion should be continued within the issue (#352)
Corrections to alpha.1 are coming and are implemented
Identity & Consent Management (diego.gonzalezmartinez on behalf of Axel Nennker )
(WG) reviewed and prioritized open issues and pull requests (PRs) critical for the Spring25 meta-release. The deadline proposed for closing these scope-related topics was set for the end of this week to avoid delays into January.
Clarity on
login_hint
(#191, #242):WG consensus: “Optional” status for
login_hint
in the authorization code flow, ensuring implementations can ignore it if not applicable. A PR will be created to update the documentation accordingly, emphasizing interoperability.
Error Scenarios Appendix (#211, #220):
Action: Add comments clarifying WG alignment and seek to unblock PR #220.
Several approvals already, need DT to review their block
CIBA Flow Examples (#236, #237):
Pending: Address minor comments and Eric’s suggestion regarding clarification on signed vs. unsigned examples.
Signed Request Object for
/authorize
(#205, #226):Pending topics:
OIDC vs. RFC 9101 as a reference.
aud value.
sub claim requirement (not include it in request object assertion) to avoid cross-JWT confusion.
Additional clarification on not including the “sub” claim to avoid JWT confusion was requested. A final review will validate this approach.
JWT Token Lifetime (#208, #216):
Consensus on token lifetime computation:
If the
iat
(issued at) claim is present, use it as the baseline.If absent, use the token’s arrival time at the authorization server.
Need DT to review their block
Action: Approval needed from key contributors to finalize the PR.
Release Management (Tanja de Groot )
Currently 32 API candidates in the Spring25 meta-release
All Fall24 APIs need to be re-release released with updates to align with new Commonalities and ICM releases (25 APIs). 5 APIs are currently missing from Spring25
Stable version API like OTP must be updated with commonalities 0.5
12 new APIs for Spring25
Decision needed from TSC to shift M3 to 2025-01-15 17 (final cut-off date for API release PRs).
Decision agreed !
Sub Projects are requested to propose their release PR for review for M3 as soon as available.
Specific Topic 1 (...)
...
Any Other Business
...
Next Meeting
Next TSC Meeting will be on …
To be agreed: have a TSC on January 2nd or skip it?
Next TSC will be Jan 16th
Specific agenda topics backlog (for 2025):
…none yet