Antitrust Policy

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 LinusFoundation.   Antitrust Policy

Open

New Procedures in API Backlog WG meetings

A number of improvements are under discussion with leadership team of OGW project (Henry), CAMARA Project (Markus), Product Definition WS (Helene) and TSC (Herbert). As of today, the WG adopted agreements are three:

1. To close the agenda SEVEN DAYS BEFORE the conf. call.

   • In case a WG participant wants to include a point in the agenda (e.g., present a new API proposal), this participant shall ensure the corresponding issue is opened in Github by then.

   • Exceptional situations will be treated separately.

2. New schedule of conf. calls **The meetings are to be held by Linux Foundation (Links available at GitHub and Confluence Backlog front pages)

   • 2nd Thursday of the month (9-10:30 UTC)

   • 4th Thursday of the month (15-16:30 UTC)

3.  Send agenda to TSC mail list, to encourage more TSC member companies to join the call and provide comments when they identify APIs which are of interest for them. 

4. New API proposals are included in backlog table when template PR is created, linking to the pending PR

5. PR will be merged as soon as ready for TSC, and should be merged before TSC review

6. API enhancements requires existing group’s validation. TSC is informed accordingly to validate

7. Link and status in backlog table will be updated accordingly

8. Issue to track API onboarding will be opened once new API is confirmed in TSC.

9. New proposal Lifecycle for frozen APIs.

Recent Updates & Recap

Last TSC meeting 2026-01-15:

Governance & Project Management:

• EUC: Doug is back as the 3rd EUC representative (no objections from TSC).

• Zulip: Move discussions from Slack to Zulip; use existing WG channels and open “topics” as needed (subprojects via support@camaraproject.org).

• MCP: Whitepaper announced and well received.

• TSC discussion (Issue #210): Start with Phase 0 using 3–4 pilot APIs; Security/Consent to be handled by ICM; decide pilots/scope/sponsors and consolidate work (close #203, continue in #210).

Commonalities:

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

  • https://github.com/camaraproject/Commonalities/issues/461: PR with sequence diagrams for both the simple and advanced flow variants under preparation

• https://github.com/camaraproject/Commonalities/issues/568: this is a medium/longer term activity (not for Spring26). It is to be discussed if a specific API is created or if to use a template approach and dedicated API updates. The latter could provide more flexibility.

  NEWhttps://github.com/camaraproject/Commonalities/issues/572 - new related issue proposing developing guidelines for:

  • Collections used for listing/pagination (representation concern, not a consistency boundary)

  • Invariant-bearing Resource Groups (true consistency boundaries where cross-resource invariants must hold)

  • Batch/bulk request patterns (single request to operate on many independent resources without persistent group semantics)

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

• ICM Spring26 meta-release status. Current progress stands at 75% completion after adding the new issue #338 to the scope as per WG decision. Significant milestones include the closure of the DPoP support strengthening issue (https://github.com/camaraproject/IdentityAndConsentManagement/issues/318) and the upcoming January 31 deadline for the release candidate. Remaining work focuses on Rich Authorization Requests (RAR) and Profile alignment with OAuth 2.1.

• OAuth 2.0 Token Exchange (Issue #337): This remains an open and debated topic. Although potential benefits have been identified, concerns remain about overlap with existing CAMARA flows, the risk that additional optional features will impact interoperability, and whether there is a real business need for it.

• Consent Info API evolution / Controlled Consent Capture Delegation.

  • Consent Management API: A new independent repository has been successfully established for the Consent Management API to handle Controlled Consent Capture Delegation.

  • ConsentInfo API: The callback URL feature has been merged into the main branch, and the repository is preparing for the v0.2.0 release.

Release Management:

• Spring26 meta-release (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/268500993 )

  • M2 (Jan 31): Target date is Jan 31, 2026 for the release-candidates of Commonalities & ICM. Both are well on track (81 and 75% respectively) to deliver their planned release-candidate for the M2 milestone.

  • M3 (Jan 31)

    • Target date is Jan 31, 2026 for Spring APIs that have been granted participation:

      • 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

  • These Spring26 APIs will be the first candidates for the roll-out of the automated release process

• Fall26 meta-release  (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/268533761 ) 

  • M0 (Jan 15): kick-off to be done on today’s TSC: All API Sub Projects can start to prepare their scope issue for Fall26. They shall start using the Commonalities and ICM Spring26 release-candidate once available (M2).

  • M1 (Apr 30): API alpha versions for Fall26: Fall26 will be fully supported by the automated release process based on the release metadata.

Other topics

(Reminder) CAMARA APIs - Functional Differences (Use-Case & Data Semantics Edition): A white paper has been produced for publication on the CAMARA website to explain in detail what problem each API solves, what data it delivers, how to interpret it, and how to combine them in risk and error-prevention policies (Audience: Non-telco experts) APIs covered: SIM Swap · Device Swap · Tenure · Number Recycling - (link)

(Information) Unified Clean-up Process for Inactive Onboarding Trackers and Repositories: For already evaluated once we’ve created issues in APIBacklog:

• #283 - [Repository Transition → Archived]: HomeDevicesQoD,

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

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

  • Decision: TSC supports the proposed archiving. The issues are to be closed after the archiving is done.

(Review PR) Update the backlog table with the changes as of December #280

(Scope enhancement) Enhancement of Dedicated Networks API #295: Dedicated Networks proposes an optional “Areas API” (Issue #86 / PR #87) to help consumers find/select eligible areas. Early signals suggest the same concept may also be needed in QoS Booking, so we risk duplicating / diverging semantics across CQM APIs. The group needs guidance on whether this should be treated as:

• DN-only optional API enhancement (new API within the Dedicated Networks family), or

• a shared CQM cross-API building block that can be reused by multiple CQM APIs (at minimum DN + QoS Booking), to prevent duplication.

  • Expected outcome / DoD: The decision must be agreed upon by the group before being added to the backlog.

Discussion

Current Issues 

Out Of Agenda

Closing Issues