Merge branch 'camaraproject:main' into trust_worhtiness_intent_api_proposal

Author: panos-ece

documentation/API proposals/API-Scope_Enhancement_Consent_Info_Controlled_Delegation.md

@@ -0,0 +1,53 @@
+# API Scope Enhancement Template
+
+This template captures all the information that a partner should fill out when proposing a scope enhancement for an existing CAMARA API.
+
+## API name  
+[Consent Info](https://github.com/camaraproject/IdentityAndConsentManagement/tree/main) 
+
+## New API name  
+No new name proposed at this stage. The enhancement is considered an evolution of the existing Consent Info API or could be a new API, to be decided during design phase. 
+
+## Scope Enhancement owner  
+Telefónica
+
+## Scope Enhancement summary  
+This scope enhancement aims to extend the capabilities offered by the existing **Consent Info API** to support a more flexible and user-friendly mechanism for **consent capture**, referred to as controlled delegation. 
+
+Under the current implementation, the end-user provides consent directly through operator-managed channels or web interfaces. The proposed enhancement introduces the possibility for **trusted developers or aggregators** to present the consent interface within their own applications, using the consent texts and parameters provided by the operator. 
+
+The operator remains fully responsible for consent registration, storage, and lifecycle management (including audit, traceability, and opt-out). The enhancement focuses on improving user experience and enabling new types of consent-driven interactions while maintaining operator control and compliance with privacy regulations. 
+
+**In-scope business cases include**: 
+- **App managed UX consent capture**: Developers collect end-user consent within their own app, their own look&feel and being free to choose the best moment to collect it by using operator-provided texts to later submit the use’s response. 
+- **Integrated onboarding**: Consent capture is embedded within customer registration, verification flows or any other flow the developer may find most suitable, avoiding redirections to external operator portals. 
+- **Consent renewal campaigns**: Applications can trigger consent renewal campaigns in their own interface while ensuring operator-level registration.
+
+## Technical viability  
+The proposed enhancement builds upon the existing Consent Info framework and its relationship with operator consent management systems. 
+
+It reuses the existing operator infrastructure (Consent Master) for consent validation, registration, and transparency, while adding a new controlled mechanism for capturing consent externally via developer applications. 
+
+Further analysis is ongoing regarding the secure identification and authentication of the subscriber during delegated consent capture. The proposal does not depend on any new 3GPP or TMForum feature, but aligns conceptually with identity and privacy control principles under development in the ICM scope. 
+
+## Commercial viability  
+The enhancement responds to developer and enterprise demand for smoother consent collection processes and reduced user friction in digital journeys. 
+
+It also aligns with current commercial deployments of consent management systems across operators, which can be extended to support delegated consent registration. 
+
+Several operators are already evaluating integration with trusted developers and aggregators under privacy-compliant frameworks. No dependency on commercial third-party technology is identified at this stage. 
+
+## YAML code available?  
+NO 
+
+## Validated in lab/productive environments?  
+Initial feasibility assessments and simulated flows have been conducted internally to validate integration feasibility with operator consent managers.
+
+## Validated with real customers?  
+Evaluation with selected customers is planned after initial review and alignment across operators.  
+
+## Validated with operators?  
+To be validated.
+
+## Supporters in API Backlog Working Group  
+To be confirmed.

documentation/API proposals/API-proposal-InHome_Device_Network_Management.md

@@ -0,0 +1,43 @@
+### API family name
+
+In-Home Device Network Management
+
+### API family owner
+
+Infosys Ltd.
+
+### API summary
+
+This API enables Apps to manage the In-home devices network connectivity with below functions:
+
+1. Network access control: Ability to block/un-block devices connected to home network
+2. Network health check: Ability to check device network health status \& provide recommendations to improve network connectivity.
+
+### Technical viability
+
+These APIs are applicable for devices (like smartphone, laptop etc.) connected to home network services provided by ISPs.
+
+### Commercial viability
+
+This API is proposed for use by 3rd party Apps to provide value added services to end users.
+
+### YAML code available?
+
+NO.
+
+### Validated in lab/productive environments?
+
+NO.
+
+### Validated with real customers?
+
+NO.
+
+### Validated with operators?
+
+NO.
+
+### Supporters in API Backlog Working Group
+
+Infosys Ltd.
+

documentation/API proposals/API-proposal-Strength_Rainfall.md

@@ -0,0 +1,47 @@
+
+### API family name  
+Radio signal strength API (for rainfall analysis  use cases)
+
+### API family owner  
+Ericsson
+
+### API summary  
+The API exposes microwave link endpoints, carrier frequencies and the current attenuation level  for a given geographical area. Furthermore, the API provides near real-time rainfall data by leveraging radio links in the operator's network, which can be affected by rain.
+
+The API may be used to estimate rain intensity over a given geographical area. Each CSP's microwave link has fixed coordinates which are the endpoints of a signal that fluctuates due to rain intensity. Rain absorbs the microwave signal energy in a deterministic manner for a given frequency. 
+
+API Consumer can convert a link's attenuation in dB into mm/h of rain intensity and incorporate these sources into its rain geographical model.
+
+
+### Technical viability  
+
+Coverage proven by existing Ericsson microwave information sources. 
+API exposes a streamed data source of dB attenuation per microwave link. Each link has a set frequency & 2 fixed geographical coordinates. Endpoints can be obfuscated by means of deviations of exact coordinates, to be discussed with operators in Camara.
+
+
+### Commercial viability  
+Service is in commercial operation already in some areas leveraging deployed microwave infrastructures.
+
+The API can complement other data sources such as weather stations, radar and satellites. Also, it can be used for weather forecasting and to  improve the rain models.
+Depending on links density and topology, a better spatial resolution can be achieved compared to normal weather radars. A better update frequency (e.g. every 10seconds) can be achieved. 
+
+Weather information is needed for manned and unmanned flight management systems. Especially for drones on lower altitudes, ground radars have problems with the curvature of the earth. No other good source for rain intensity exists below 5000 feet. 
+
+35% of drone flights don't take place because of weather uncertainties. This API can improve the data.
+
+
+### YAML code available?  
+NO.
+
+### Validated in lab/productive environments?  
+YES, productive environment 
+
+### Validated with real customers?  
+YES, with 2 universities and 2 weather companies
+
+### Validated with operators?  
+YES, with 2 operators
+
+### Supporters in API Backlog Working Group  
+List of supporters.  
+*NOTE: That shall be added by the Working Group. Supporting an API proposal means that the supporting company must provide at least 1 (one) Maintainer at the time of the Sub Project creation.*