2025-12-18 TSC Minutes

Attendees & Representation

LF Staff: @Casey Cain

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

  • none

• Any Other Topics

Minutes

Review and approval of previous meeting minutes

• Minutes of previous TSC meeting: 2025-12-04 TSC MinutesPreview

  • no comments, approved

Action Item Review

• See home page Technical Steering Committee for current list of open action items

  • No open action items

Governance & Project Management issues

• Update from TSC Chair nomination/election (@Casey Cain)

  • See https://lists.camaraproject.org/g/tsc/message/360: @Herbert Damker from Deutsche Telekom will continue to serve as the CAMARA Technical Steering Committee Chair

• Migration from Slack to Zulip (@Casey Cain)

  • Deadline January 29th, migration will start after the holiday period (notification will be send out tomorrow)

• Open issues in Governance:

  • https://github.com/camaraproject/Governance/issues/205

    • Request from Arpit Joshipura (CAMARA Executive Director) to move the technical overview from the Project Charter into a separate document - waits for proposal from LF team.

    • Draft is in legal review by LF.

  • MCP (Model Context Protocol) White paper

    • Whitepaper is done, PDF version available, last editings ongoing. According to Marketing WG minutes it is planned to publish it as PR and LinkedIn post in 1st week of 2026 together with AAIF marketing team (@Jill Lovato) and to promote it on the Unthinkable lab event (@Markus Kümmerle)

    • Next steps of work to be discussed in https://github.com/camaraproject/Governance/issues/203 (needs rework based on latest whitepaper content)

  • https://github.com/camaraproject/Governance/issues/200

    • The initial vote was procedurally valid but not representative of all key stakeholders. The Marketing WG was asked to broaden the proposal space before making a final decision. The marketing team has taken the task and started a discussion.

  • https://github.com/camaraproject/Governance/issues/197

    • Decision to migrate taken in previous TSC meeting - see above. Issue will be closed.

  • https://github.com/camaraproject/Governance/issues/194

    • Adoption of the concept has been decided and already done to a large extent by the Release Management WG. Issue still open to check for further document updates across the project (Draft File Modifications: Adopt a Dual-Phase Meta-Release Cadence for CAMARA APIPreview ) - seperate issues to be created, than the issue can be closed.

  • Further issues are stale (February 2025 or earlier), to be reviewed begin of 2026 @Herbert Damker

API Backlog (@Jorge Garcia Hospital@Alberto Ramos Monaga )

Two new APIs are proposed from the CAMARA Backlog WG for inclusion as Sandbox APIs:

• In-Home Device Management API: #250

  • Taxonomy (proposed): Service Management

  • API family owner: Infosys – @Ravi Shekhar

  • API family supporters: Infosys

  • Scope / description: This API allows applications to manage in-home device connectivity by controlling network access (blocking or unblocking devices connected to the home network) and by monitoring network health, checking each device’s connectivity status and providing recommendations to improve overall network performance.

  • Create as a Sandbox repository: InHomeDeviceManagement (aligned with existing Sandbox repositories)

    • Decision: approved

• Radio Signal Strength API: #267

  • Taxonomy (proposed): Communication Quality

  • API family owner: Ericsson – Kamran Keykhosravi

  • API family supporters: Ericsson

  • Scope / description: This API provides access to microwave links in the operator’s network (their endpoints, carrier frequencies, and current attenuation) and uses these radio links as virtual rain sensors. By observing how rain attenuates the microwave signal in a predictable way for each frequency, the API delivers near real-time rainfall information for a defined geographical area. API consumers can then translate attenuation (in dB) into rain intensity (mm/h) and feed this data into their own rainfall and geospatial models.

  • Create as a Sandbox repository: RadioSignalStrength (aligned with existing Sandbox repositories) (Rainfall Intensity and signal API - proposed new name)

    • Decision: approved, final name to be determined in Onboarding tracker issue

Unified Clean-up Process for Inactive Onboarding Trackers and Repositories #201 . For already evaluated once we’ve created issues in APIBacklog:

• #283 - [Repository Transition → Archived]: HomeDevicesQoD, confirmed by involved maintainers.

• #284 - [Repository Transition → Archived]: SiteToCloudVPN,

• #285 - [Repository Transition → Archived]: ShortMessageService,

• #286 - [Repository Transition → Archived]: VoiceVerificationCode: China Unicom has expressed its intention to proceed with both proposals.

• #287 - [Repository Transition → Archived]: VoiceNotification: same as VocieVerificationCode.

Commonalities (@Rafal Artych )

• https://github.com/camaraproject/Commonalities/issues/543 - the scope is frozen

  • https://github.com/camaraproject/Commonalities/issues/302

    • ConnectedNetworkType, DeviceIdentifier, DeviceLocation, DeviceReachabilityStatus, DeviceRoamingStatus, QoSBooking, QualityOnDemand - proposed own (similarly expressed) guidelines

    • @Herbert Damker think (in general) about short notes within API descriptions, pointing for full explanation to a central document (avoiding that traversal topics are dominated the API descriptions section)

• https://github.com/camaraproject/Commonalities/issues/461

  • Breakout session series extended

    • It was decided to continue with sequence diagrams for both the simple and advanced variants and make a PR

• https://github.com/camaraproject/Commonalities/issues/568

  • Several sub-projects (e.g., CQM-family, Device Status, IoT Connectivity) are encountering similar requirements and addressing them independently.

  • Come more investigations what the different APIs need and would use such functionality (in Commonalities) → consolidation in one of the next meetings.

  • Related issue in APIBacklog: https://github.com/camaraproject/APIBacklog/issues/288, but discussion mainly first in Commonalities

Identity & Consent Management (@Jesús Peña García-Oliva on behalf of@Axel Nennker )

• ICM Spring26 meta-release status. The Working Group has officially closed the scope for the Spring26 release. Current progress stands at 63% completion. The WG is aligned on the M2 milestone, targeting a release candidate by January 31, but timely ownership of the remaining in-scope items (Rich Authorization Requests (RAR) and Profile alignment with OAuth 2.1) is critical.

  • Security profile update: DPoP additional recommendations for implementers. Proposal to strengthen DPoP support (Issue #318 / PR #325) is in its final review phase and close to approval.

  • JWT-Bearer flow using Operator Token. The proposed flow (Issue #326 / PR #334) has been successfully merged, maintaining an implementation-agnostic approach for internal temporary token validation.

• A new proposal to introduce OAuth 2.0 Token Exchange (RFC 8693) is currently under technical debate. While potential benefits were identified, concerns remain around overlap with existing CAMARA flows and the risk of additional optional features impacting interoperability. No decision has been taken yet.

• Consent Info API evolution / Controlled Consent Capture Delegation.

  • The callbackURL feature is merged and a new release (v0.2.0) of Consent Info API is expected in the coming weeks.

  • Telefónica provided a proposal that suggests managing Consent Capture Delegation via two distinct APIs rather than overloading the existing Consent Info API.

    • The group agreed to separate the APIs. No objections raised.

    • ICM will request a new repository (ConsentManagement) for the new Consent Management API.

    • The group also agreed (no objection raised) moving the existing PR #43 content to this new repository as an initial contribution.

      • https://github.com/camaraproject/ConsentInfo/pull/43

• Further details of the above items can be found at 2025-12-17 ICM MinutesPreview

Release Management (@Tanja de Groot)

• Spring26 meta-release (Spring26 meta-releasePreview )

  • M1 Commonalities & ICM (Nov 30)

    • Commonalities Spring26 scope issue: Scope of the Spring release #543 is frozen.

    • ICM Spring26 scope issue: ICM scope for the Spring26 meta-release #311 is frozen.

  • M1 APIs (Dec 15 - Spring26 is not recommended for APIs)

    • The following Spring26 API participation requests have been received in Release Management.

      • Spring 26 participation: SessionInsights #350

      • Spring26 participation: HighThroughputElasticNetworks #349

      • Spring26 participation: IoTSIMFraudPrevention #348 

      • Spring26 participation: NetworkInsights #344

      • Spring26 participation: ClickToDial #343 

      • Spring26 participation: Network Slice Booking #341

    • Release Management proposes, as the number is limited, that all candidates are accepted to participate in Spring26 - the final decision will be the M3 milestone review (Jan 31, 2026) for which solid API definition(s) are expected.

    • TSC is requested to endorse the proposal: yes

• M2 (Jan 31, 2026)

  • The release-candidates of Commonalities & ICM.

• M3 (Jan 31, 2026)

  • Spring26 APIs that have been granted participation to provide their release-candidate based on the release-candidates of Commonalities and ICM of Spring26.

• Automation (cudos to Herbert)

  • Automated generation of interactive meta-release tables for Fall24, Spring25 and Fall25 meta-release has been achieved and is now available from the meta-release pages, e.g. see Fall25 meta-releasePreview . This process collects GitHub metadata and repository content, enriches it with config data, and ensures that, when patch releases are done, the table is updated automatically instead of manually sofar.

  • There is also a table with all releases across Fall24, Spring25 and Fall25 available: https://camaraproject.github.io/releases/portfolio.html If you need specific reports and/or views for certain purposes please open an issue in camaraproject/project-administration and describe your needs. The goal is to replace step by step all manual reports and API overviews with generated, authoritative ones.

  • This is the first step in replacing the manual API release trackers in the wiki by metadata (release-plan.yaml, release-metadata.yaml) in GitHub. The rollout of the release-plans to all repositories is then next step.

    • The release-plan.yaml replaces the API release-tracker wiki pages.

    • The release-metadata.yaml will be generated for each release.

Specific Topics

• none

Any Other Business

• An action item for everyone: What should CAMARA focus on in 2026? We'd love to hear your ideas on topics, initiatives, or activities that could help grow our community, strengthen the ecosystem, and make life easier for everyone working with CAMARA APIs.

  Share your thoughts however works best for you:

  • Drop a comment here in the meeting notes

  • Send an email to the TSC mailing list

  • Open an issue in Governance (or the relevant working group)

  • Or just grab one of the TSC Members directly

Next Meeting

• Next TSC Meeting will be on the third Thursday in January, 2025-01-15, at 15:00 UTC (16:00 UTC)

  • Skipping the TSC on January 1st - Happy New Year 🎇

• Specific agenda topics backlog:

  • ...

Action items