Merge pull request #3 from TEF-RicardoSerr/main

Migrating old repo

CODEOWNERS

@@ -6,4 +6,4 @@
 
 # These are the default owners for the whole content of this repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file.
 
-* @TEF-RicardoSerr @jgarciahospital @NoelWirzius
+* @TEF-RicardoSerr @jgarciahospital @NoelWirzius @caubut-charter

documentation/API proposals/APIFamilyproposal_Identity&Consent.md

@@ -0,0 +1,11 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Identity and Consent Management |
+| API family owner| Telefonica  |
+| API family summary | **High level description**<br>Operator (NaaS) platform implementing CAMARA APIs should be built with a privacy-by-default approach to fully comply with data protection regulations like the [GDPR regulation](https://gdpr-info.eu) in Europe, which emphasises on user's privacy. These regulations note that some CAMARA APIs may require user consent to be accessed. This forces the operators to provide means and appropriate solutions to capture, store and manage this consent through its lifecycle. Otherwise, the scoped CAMARA APIs cannot be rolled out in production networks. <br>Building such a solution also means bringing in scope the identity of the end user and/or the subscriber (as both could be different) and making sure that end user experience of using the API is not compromised while doing so.<br><br>**Input params**<br>N/A<br><br>**Output params**<br>N/A<br><br>**Notifications** <br> N/A <br><br>**Notes**<br>APIs around managing consent are expected to be contributed in this subproject. Certain concepts from this subproject will be contributed to the [Commonalities WG](https://github.com/camaraproject/WorkingGroups/tree/main/Commonalities). |
+| Technical viability | N/A | 
+| Commercial viability | There is no a direct commercial expectation from this API family -- it is an enabler instead. Identity and Consent Management API family includes one or more APIs which will allow other CAMARA APIs to be commercialized, provided those CAMARA APIs require user consent to be accessed as per in-scope data protection regulations.|
+| YAML code available? | N/A <br>|
+| Validated in lab/productive environments? | No <br>|
+| Validated with real customers? | No <br><br> |
+| Validated with operators? | No  </em> |

documentation/API proposals/APIProposal_CPE-Management_Charter.md

@@ -0,0 +1,19 @@
+| **Field** | Description |
+| --- | --- |
+| API family name | CPE Management |
+| API family owner | Charter Communications |
+| API family summary | Service enabling API for customer premises equipment (CPE) management. |
+||**Terms:** <br>  - `Service Site`: A physical location serviced by an internet service provider. <br> - `Device`: Hardware supplied by a service provider (CPE) to enable network access to a subscriber at a `Service Site`.  <br> - `Isolated Network`: One or more networks available on a `Device` that are logically separated and do not support inter-network communication between WiFi clients (`Home Devices`). |
+||**High-Level Scope** <br> - Reboot one or more `Devices` (scheduled and immediate). <br> - List, create, modify, or delete WiFi `Isolated Networks` on one or more `Devices`. |
+|| **B2C Scope:** The subscriber uses the API to manage their own `Device` supplied by a service provider, for example, through [Home Assistant](https://www.home-assistant.io/). <br><br> - List or modify their main WiFi `Isolated Network`. <br> - List, create, modify, or delete one or more secondary WiFi `Isolated Networks` for guest or IoT `Home Devices`. <br> - Reboot their `Device` to recover from a faulty network state.
+|| **B2B2C Scope:** A subscriber delegates limited authorization to manage a secondary guest `Isolated Network` to a short-term rental app for guest stays. <br><br> - Create temporary `Isolated Networks` for rental guests. <br> - Automatic removal of `Isolated Networks` using an expiration period. <br> - Assign guest networks to a subscriber's "default" `Device`, allowing the subscriber to benefit from the functionality without granting access to `Service Site` or `Device` resources. |
+||**B2B2B2C Scope 1:** A business with several properties (e.g., long-term rentals, hotels) using their service provider's `Devices` delegates authorization to manage the `Devices` and `Isolated Networks` to a third-party IT company. The property owner is the subscriber of the internet services, not the individual tenants. <br><br> - List the various `Service Sites`, if consent is granted by the property owners, including the location address through _additional_ consent to reconcile data sets when `Service Site` counts range from 100 to 10,000+. <br> - List the `Devices` at each `Service Site`, if consent is granted by the property owners, including the hardware address through _additional_ consent to reconcile data sets when `Device` counts range from 100 to 10,000+. <br> - Reboot `Devices` to recover from a faulty network state. <br> - List, create, modify, or delete primary and secondary `Isolated Networks`. <br> - Deploy the same `Isolated Network` to multiple `Devices` for coverage in common areas. |
+||**B2B2B2C Scope 2:** The same scenario as the previous, except the tenants are the internet subscriber. <br><br> - Mirror the previous use cases, but require consent from _each and every_ tenant through granular OAuth scopes. <br> - Set a `description` on resources, allowing tenants to label their `Devices` as an alternative to exposing hardware addresses when multiple `Devices` are present. |
+|| [!IMPORTANT] <br> When designing this API, it was intended that third-parties must provide a justification during API client registration to request scopes for sensitive information, such as `Service Site` location addresses or `Device` hardware addresses, due to their protected status by many governments. A short-term rental app would be unlikely to have the ability to request those scopes from a subscriber in order to protect the subscriber's privacy against apps that request excessive permissions for data collection purposes. |
+| Technical viability | This API requires remote management of CPE `Devices` for all management features (e.g., TR-069, TR-369, OVSDB, SNMP, etc.).<br> This API definition is agnostic to the network isolation technique (e.g., separate Layer 3 networks, VLANs, OpenFlow, etc.). |
+| Commercial viability | **TR-069:** [RUCKUS Networks](https://www.ruckusnetworks.com/) (commercial cloud), [prpl](https://prplfoundation.org/) (open source `Device` firmware)<br>**OVSDB:** [Plume](https://www.opensync.io/) (commercial cloud), [OpenSync](https://github.com/plume-design/opensync) (partially open source `Device` firmware with commercial modules by Plume) |
+| YAML code available? | YES - [yaml - GitHub](https://github.com/caubut-charter/WorkingGroups/blob/feat/api-proposal-cpe-mgmt/APIBacklog/documentation/SupportingDocuments/others/cpe-management-api.yaml) - [yaml - Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/caubut-charter/WorkingGroups/feat/api-proposal-cpe-mgmt/APIBacklog/documentation/SupportingDocuments/others/cpe-management-api.yaml) - [slides - GitHub](https://github.com/caubut-charter/WorkingGroups/blob/feat/api-proposal-cpe-mgmt/APIBacklog/documentation/SupportingDocuments/others/cpe-management-api.pptx) <br> |
+| Validated in lab/productive environments? | YES - Field deployed on the production network using a UAT cloud with a production launch slated for the end of Q2. |
+| Validated with real customers? | In-progress for **B2B2B2C Scope 1 & 2** with Charter, 1x API client, and 1x subscriber that has 30,000 properties.  Some of the properties have the property owner as the subscriber and others the tenant is the subscriber.  Charter is actively looking for a **B2B2C** API client partner. |
+| Validated with operators? | Liberty Global, Vodafone, VodafoneZiggo, Charter, CableLabs |
+| Supporters in API Backlog Working Group | Liberty Global, Vodafone, VodafoneZiggo, Charter, CableLabs |

documentation/API proposals/APIProposal_KYC-Age Verification_Orange.md

@@ -0,0 +1,15 @@
+Age Verification API submission
+
+| **Field** | Description |
+| ---- | ----- |
+| API name | Age Verification |
+| API owner | Orange but this API should be part of KYC project lead by Toshi Wakayama (KDDI) |
+| Initial API Contributors | Gille Renoux/ Ludovic Robert - Orange | 
+| API summary | This API allows for the API Consumer to check if the owner/user of the line is older than a provided age. The request parameter are a device identifier (like other CAMARA API) and an age (provided in years). The answer indicate if the user/owner is older than this age. The API objective **is not to provide the exact age** but to provide an information from telco aggregated information. Minimum Age requested could be limited per country (For example only age above 18 year could be checked). <br/> Illustration of use: Operator can send back a 0: KO, 1: OK but also an -1 if operators have any doubts and so aware the service provider that additional way of checking should be needed. Of course detail of the API will be discussed in the WG.|
+| Technical viability | This API uses mobile subscriber info to determine with aggregated information if the user/owner of the line is older than the request age to be checked.  </em>.
+| Commercial viability | This service is requested in several UC to limit app access service in being  compliant with laws in countries, access to specific contents Betting, Gambling( 18, 21, 23, 25 years old depending on countries or state), adults,… social networks,… <br/> This service can be serves also in APPs to verify the availability for a transaction (payment, money transfert,… in App payment)
+. |
+| YAML code available? | No - to be provided |
+| Validated in lab/productive environments? | No |
+| Validated with real customers? | No </em> |
+| Validated with operators? | Yes in GSMA Drop 3</em> |

documentation/API proposals/API_Proposal_Device_Location_Retrieval.md

@@ -0,0 +1,14 @@
+Device Location - Location  Retrieval API submission
+
+| **Field** | Description |
+| ---- | ----- |
+| API name | Location Retrieval |
+| API owner | Ericsson DT Orange Telefonica Vodafone |
+| Initial API Contributors | Joachim Dahlgren Ericsson & Ludovic Robert - Orange | 
+| API summary | This API is part of the Device Location family. Additionally to device verification that allow to check a device presence in a given area, and, Geofencing that allow to get notification about location entered or left, this API allows for the API Consumer to get the raw location of a mobile device. Location data should be provided in form of geographical coordinates (x, y). The reason for this is that network identities such as CellID etc. are typically not known by developers (and should perhaps not even be exposed externally). The location could be given as a point or a shape with uncertainty area. Location is in most jurisdictions considered to be sensitive data and thereby consent by device owner/user must be verified before providing it to the developer.|
+| Technical viability | This API uses mobile subscriber info to retrieve cell identifier and then from that cell iidentifier get the location.  </em>.
+| Commercial viability | This service is requested in several UC to track device location for moving "things" like container or truck. <br/> This service can be serves also in APPs to verify the validity for a transaction (check that both party are in a same location for an App payment). |
+| YAML code available? | Yes - done |
+| Validated in lab/productive environments? | Yes (Orange lab) |
+| Validated with real customers? | No </em> |
+| Validated with operators? | No </em> |

documentation/API proposals/APIproposal_ NumberVerification_DeustcheTelekom.md

@@ -0,0 +1,14 @@
+Number Verification API submission
+
+| **Field** | Description |
+| ---- | ----- |
+| API name | Number Verifiaction <br/>Mobile Connect Verified MSISDN|
+| API owner | Dawid Wróblewski, DT, GSMA IDG |
+| Initial API Contributors | Sudhir Mittal - Airtel, Varun Talus - Airtel, Toshi Wakayama - KDDI | 
+| API summary | Mobile Connect Verified MSISDN allows Service Providers to verify the phone number of the device connected to the mobile data network through which a User is accessing a service provided by a Service Provider.<br><br>Mobile Connect Verified MSISDN is defined as two service variants:<br>•Verified MSISDN Match: in which the Operator compares the MSISDN associated with the mobile device against that provided by the SP in the service request.<br>•	Verified MSISDN Share: in which the Operator provides the mobile device MSISDN to the SP who can then perform the check itself|
+| Technical viability | API enabled on MNO ID Gateway in Mobile Connect (API Gateway) </em>.
+| Commercial viability | API Commercially available (Mobile Connect APIs).<em>|
+| YAML code available? | Yes - Sample from DT <br/> OPEN API Definition available - Yes <br /> Postman collection for MC vMSISDN available on Demand |
+| Validated in lab/productive environments? | YES - Available on DT Test environment (Also available in MC Test Suite)|
+| Validated with real customers? | YES- Validated c 10 aggregators. </em> |
+| Validated with operators? | YES. Vodafone, Orange, KPN, Telia A1</em> |

documentation/API proposals/APIproposal_AnonymisedSubscriberIdentifier_Vodafone.md

@@ -0,0 +1,18 @@
+# Anonymised Subscriber Identifier
+
+
+ | **Field** | Description | 
+ | ---- | ----- |
+ | API name | Anonymised Subscriber Identifier |
+ | API owner | Vodafone |
+ | API summary | It can be useful for a web service to automatically identify a client device (specifically, the associated ISP subscription) attempting to access its services, independently of any identity that the device itself may announce. This may be because the web service does not require the customer to identify themselves (e.g. a free service, or one funded by advertising rather than subscription), or because it is desirable to identify the device on first contact before formal identification / authentication has been completed. |
+ | | The client device can usually be identified from the source IP and port they have been allocated by the network, which are dynamic but can be associated with the device at any instant in time by the network (this is the basis for lawful intercept). Any identity information (e.g. MSISDN) is personally identifiable information (PII) which the customer is unlikely to agree can be shared, and anyway has implications for the web service to securely store or process this information. However, it can be anonymised (e.g. by hashing), allowing the web service to recognise that a customer is returning to the site, even if the identity of the customer is not known. By using different anonymisation parameters (e.g. hashing salt) for each API consumer (i.e. application server), separate identifiers can be generated for each application server when accessed by the same client device. Because the anonymised identifier is application server specific, it will not be possible to track clients across different application servers. |
+ | |For example, such information could be useful in the following scenarios: (1) to present the customer with a customised landing page, before formal identification / authentication, (2) for security / fraud reasons, to establish that the anonymised identifier matches other credentials presented, (3) for customer tracking to provide customised content, such as advertising. |
+ | | Inputs: the source IP and port allocated with the device accessing the web service. The device itself will not call this API, and hence these values are not those of the API consumer. |
+ | Technical viability | UE identity information can be from the network lawful intercept system and anonymised using any suitably secure algorithm (e.g. SHA256). |
+ | Commercial viability | Lawful intercept system is usually tied to network implementation, and relies on existing network capabilities |
+ | YAML code available? | NO |
+ | Validated in lab/productive environments? | YES, validated in lab environment |
+ | Validated with real customers? | NO |
+ | Validated with operators? | NO |
+

documentation/API proposals/APIproposal_BlockchainPublicAddress_Telefonica.md

@@ -0,0 +1,12 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Blockchain Public Address |
+| API family owner| Telefonica  |
+| API summary | **High level description**<br> This API allows to manage a Blockchain Public Address associated to a phone number, i.e. to retrieve the blockchain public address(es) and to bind/unbind a Blockchain Public Address. The Blockchain Public Address is utilized as Decentralized Identifier (DID). With the proposed API, telco service providers have the opportunity to provide 3rd parties with the following capability: pairing phone number with Blockchain Public Address whenever this 3rd party wants to offer its customers a way to make transactions more easily based on the phone number instead of the Blockchain Public Address. <br><br>**Rationale**<br>Blockchain is a long set of alphanumeric characters, e.g. 26-35 characters in BitCoin. This identifier is not memorisable or usable by a person, so there is the possibility of positioning the telephone number as the predominant identifier on web3. This new identity protocol will make it possible to have a system similar to the Telcos' bizum in web3 ecosystem.
+| Technical viability | For this API to work, the following is needed: <li> Wallets, which will be in charge of generating the DID.</li><li> Storing this DID together with the user's phone number, with prior validation that the targeted user has a telephone number. </li><li>Designing this API for it to be interoperable among the different operators</li>The operators will make this API available to 3rd parties through their API marketplaces. The operators have to protect the API against fraudulent uses, e.g. detection based on invocation patterns. |
+| Commercial viability | TBD | 
+| YAML code available? | YES |
+| Validated in lab/productive environments? | NO<br>|
+| Validated with real customers? | NO <br><br> |
+| Validated with operators? | NO  </em> |
+

documentation/API proposals/APIproposal_Call_FWD_Signal_TIM.md

@@ -0,0 +1,12 @@
+
+| **Field** | Description | 
+| ---- | ----- |
+| API name | Call Forwarding Signal |
+| API owner | TIM |
+| API summary |The Application Server invokes the Call Forwarding Signal API to determine if a specific telephone number has an active "call forwarding" setup. "Call forwarding" is a network service that redirects incoming calls to another phone number (configured in the service).  The Call Forwarding Signal API can be used by a bank to verify if a “call forwarding” option is active on the customer’s phone number to avoid frauds. A call from the bank to the customers can indeed be forwarded to a different number because of a fraud attempt.|
+| Technical viability |This API uses MSISDN info, usually stored by the Mobile Network Operator, to determine if a "call forwarding" service is enabled |
+| Commercial viability | The API is useful to avoid frauds. Banks offer the option for users to receive telephone calls to solve problems, e.g. in case of issues with the bank App, issues with Smartphones, the bank website or any tool providing access to the online bank account management system.<br>How does the fraudster operate?<br>• Through social engineering, the fraudster gathers information about bank customers who are engaged in such a situation, needing the bank to contact them.<br>• Once they identify the service provider and phone number of a customer, they manage to successfully activate, on the customer profile, the 'call forwarding' to a phone number they control.<br>• After successfully setting up 'call forwarding,' the fraudster then contacts the bank, claiming an inability to access online banking services and requesting a call from a bank representative. <br>• When the bank calls the registered contact number of the user, the active 'call forwarding' diverts the call directly to the fraudster, thus completing their scheme.<br> The Call Forwarding Signal API can be used by the bank to verify if a "call forwarding" option is active on the customer's phone, avoiding such a fraud.|
+| YAML code available? | NO |
+| Validated in lab/productive environments? | NO |
+| Validated with real customers? | NO |
+| Validated with operators? | NO |