Issue #

#259

Heksagon

Voice One Time Password Call

The API template is available at #263

INITIAL CONTEXT:

The “Voice One Time Password Call” API is used to send short-lived one time passwords (OTP) to a phone number via voice call and validate it afterwards, in order to provide a proof of possession of the phone number.

AP1: Update the PR by creating a new entry under documentation/API-proposals instead of modifying documentation/API-proposal-template.md.

AP2: Create an issue with the API proposal label and link it to this PR.

AP3: Resolve the easyCLA error by clicking the provided link and signing the authorization

Sep 25, 2025: Not treated

Relation with Voice Verification Code (#233) - Herbert suggest if we can merge this with this issue.

Heksagon: Regarding your suggestion to merge our issue proposal with #233, we have checked and it looks like that their use case works only for "IMS based audio codes" as explained in their API description which is not the case for our API. So we don't think that merging the two issues would be a good idea. If there is any further discussion needed on that, we can have a call to evaluate it.

Oct 10, 2025, Oct 23, 2025, Nov 13, 2025,Nov 27, 2025, Jan 8, 2026: Not treated

Dec 11, 2025: Resolve the PR comments and upload the PowerPoint presentation - Not treated

Jan 22, 2026, Feb 12, 2026: Not treated

MEETING UPDATE:

Feb 26, 2026: Not treated

#288

T-Mobile US

Group Management API

The API template is available at #289

INITIAL CONTEXT:

The Group Management API enables API Consumers to create and manage named groups of pre-defined entities (e.g. devices or areas). It supports batch membership operations and event-driven notifications, making it ideal for Service APIs (e.g., Geofencing) that need to manage and track sets of entities, and be informed about changes to group member states.

Related Issue: Standardize Group Management for CAMARA Sub-Projects

Jan 8, 2026: Not treated

Jan 22, 2026: @Murat Karabulut Will be discussed in commonalities first.

Feb 12, 2026: Not treated

MEETING UPDATE:

Feb 26, 2026: @Murat Karabulut: Still open expected to be discussed in the next few weeks on Commonalities group.

#293

NCSRD
& Infolysis

Trust Worthiness Intent API

The API template is available at #294

INITIAL CONTEXT:

TWIA is an intent-based API that lets an app submit high-level trust requirements (Security, Privacy, Reliability, Resilience, Safety) in natural language and get back per-category scores plus an overall trustworthiness level, without dealing with low-level configuration.

Jan 8, 2026, Jan 22, 2026: Not treated

Feb 12, 2026: The owner presented the API. Discussion:

• @Eric Murray: Whether “assurance tiers” (higher reliability/security/privacy) are just a pricing negotiation, and asks what concrete input from the API consumer would make the provider actually change how the service is delivered (e.g., infrastructure/operations) to meet that higher tier.

  • Harilaos: the current “trustworthiness” score is effectively tied to specific user profiling; it’s not priced that way yet, but profiling could drive tiered pricing (validated commercially with a Greek mobile operator), potentially requiring API extensions to support negotiation of different profiling/charging levels.

• @Jan Friman: Ask for a concrete example of a service that would use this kind of profiling (e.g., connectivity or positioning), and whether it’s meant to apply to any service or only to specific service categories.

  • Harilaos: like VR/XR as the concrete example: a “highly trustworthy” XR app would justify different operational treatment (e.g., stricter service provisioning controls, core-network prioritization, and differentiated access/assurance mechanisms), etc.

AP1: Refine the PR:

• 1) Make the proposal more telco operator capability to differentiate it from AI-trust scoring, which does not require the telco.

• 2) Standardize the normative definition of 0-1 score to make multi-operator interoperability more realistic.

• 3) Focus only on POST/intents for now, and leave the subscriptions part for a future version.

• 4) Given the risk involved in entering free text (personally identifiable information/confidential data), apply protective measures in the proposal.

MEETING UPDATE:

Feb 26, 2026: AP: @Alberto Ramos Monaga and API proposal owner - get some feedback from Backlog WG and review the telco operator capability scope

#298

Infosys

Enterprise Connectivity Governance API - ConnectivityGovernance

The API template is not available yet

INITIAL CONTEXT:

The proposed Enterprise Connectivity Governance API enables telcos to enforce enterprise network policies at the operator network level (e.g., gateway/edge/core) across MPLS, SD-WAN and mobile networks, so enterprises can centrally control or restrict access to services/app categories (e.g., streaming sites) and optimize usage for compliance scenarios (including BYOD) without installing software on end-user devices.

Feb 12, 2026: Not treated

MEETING UPDATE:

• Scope is still unclear: it still looks like a persistent Operate/provisioning API, not clearly a CAMARA Service API; we need a clear definition (persistent CRUD vs request-time intent).

• Interoperability is not defined enough: no clear MVP target resource and no strict portable policy model yet (categories/semantics/fallbacks), with fragmentation risk from optional app catalogues.

• Author clarified the architecture concept (CAMARA intent + TMF/ODA realization), but the proposal is still not mature for alignment because the key scope and interoperability gaps remain open.

Feb 26, 2026:
AP1: Create a pull request with the API proposal template and the supporting documentation.

AP2: Review the https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/77922436 subproject to see if there’re any overlap

#299

Infosys

Network Contract Lifecycle Management

The API template is not available yet

INITIAL CONTEXT:

It aims to be an operator-agnostic interface for companies to manage long-term network SLA contracts throughout their lifecycle: defining metrics (bandwidth, latency, availability, error thresholds), monitoring compliance, notifying breaches (webhook/subscriptions), and managing changes (activation, amendments, closure).

MEETING UPDATE:

• Key scope and boundary gaps remain unresolved: the breach-notification use case still looks close to assurance/monitoring, and it is still unclear whether N-CLM only consumes external telemetry (e.g., CQM) or also defines breach evaluation logic.

• Further clarification is needed before alignment on: binding to a specific CAMARA service instance, normative SLA/metric/breach semantics for portability, and the explicit boundary/dependency with CQM (what CQM provides vs what N-CLM adds).

Feb 26, 2026: Not treated

#300

Infosys

Network‑Authenticated Assembly

The API template is not available yet

INITIAL CONTEXT:

Verifies if a defined group of devices has been physically co-present within a given zone and recent time window, returning a simple verdict (co_present/partial/not_co_present) and optionally a privacy-preserving attestation so workflows can trust presence without revealing exact locations.

MEETING UPDATE:

• The main concern remains unresolved: the core capability still appears to be “presence in an area within a recent time window,” which overlaps strongly with Device Location Verification; the proposed delta looks mainly like batching + server-side aggregation (k-of-n group verdict), which may fit better as an enhancement in the Device Location subproject rather than a new API family.

• Further clarification is needed before alignment on: device eligibility/interoperability (whether members are limited to operator-addressable devices vs tags/beacons/carts/etc.) and whether “continuous checks” implies a subscription/lifecycle model, which would need alignment with existing CAMARA subscription patterns (e.g., Geofencing Subscriptions).

Feb 26, 2026: Not treated

Issue #