2024-12-19 TSC Minutes

DRAFT MINUTES

Attendees & Representation

LF Staff: @Casey Cain @Evan Harrison

Agenda

• Review and approval of previous meeting minutes

• Action Items Review

• 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:

  • Proposed by TIM and supported by DT. Original Issue #141 . Template available.

  • Decision: Approved

• 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)

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

• DPoP Support (#125, #225):

  • 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-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-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.

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

Action items