Fix minor changes (#6)

Current version of OpenCAPIF SDK is compatible with following publicly available releases:

- [OpenCAPIF Release 1.0](https://ocf.etsi.org/documentation/v1.0.0-release/)

- OpenCAPIF Release 2.0

This document serves as the [main bootstrap reference](#networkapp-developer-path) to start working with OpenCAPIF SDK. For advanced users, refer to [OpenCAPIF full documentation](./doc/sdk_full_documentation.md) section to dig into all available features.

 2. [Network App developers](#network-app-developers)

 3. [OpenCAPIF SDK summary](#opencapif-sdk-summary)

 4. [OpenCAPIF SDK requirements](#opencapif-sdk-requirements)

 5. [OpenCAPIF SDK Configuration](./doc/sdk_configuration.md)

 6. [Network App developer path](#network-app-developer-path)

 5. [OpenCAPIF SDK data schema](#opencapif-sdk-data-schema)

 6. [OpenCAPIF SDK Configuration](./doc/sdk_configuration.md)

 7. [Network App developer path](#network-app-developer-path)

    1. [Provider Network App](#provider-network-app)

        * [Provider Network App sample](#provider-network-app-sample)

    2. [Invoker Network App](#invoker-network-app)

        * [Provider Network App sample](#provider-network-app-sample)

 7. [**OpenCAPIF SDK full documentation**](./doc/sdk_full_documentation.md)

 8. [OpenCAPIF SDK known issues](#opencapif-sdk-known-issues)

 9. [OpenCAPIF SDK developers](./doc/sdk_developers.md)

 8. [**OpenCAPIF SDK full documentation**](./doc/sdk_full_documentation.md)

 9. [OpenCAPIF SDK known issues](#opencapif-sdk-known-issues)

 10. [OpenCAPIF SDK developers](./doc/sdk_developers.md)

# Repository structure

- [config](./config/): contains OpenCAPIF SDK configuration files samples. These samples illustrate the structure of the configuration files ir order to use SDK properly. Go to the [configuration section](./doc/sdk_configuration.md) for more details,

- [doc](./doc/): contains documentation related files to this README,

- [installation](./installation/): this folder stores the Pyhton [requeriments.txt](./installation/requirements.txt) file that is required to complete the [SDK developers section](./doc/sdk_developers.md),

- [installation](./installation/): this folder stores the Python [requeriments.txt](./installation/requirements.txt) file that is required to complete the [SDK developers section](./doc/sdk_developers.md),

- [network_app_samples](./network_app_samples/): this folder contains both provider and invoker Network App samples explained further in this document at [network app developer path](#network-app-developer-path),

- [samples](./samples/): contains sample files related to SDK configuration, API definitions and SDK configuration via environment variables,

- [scripts](./scripts/): single scripts to individually test functionality though command line. For more information on how to use these go to the [full documentation section](./doc/sdk_full_documentation.md),

For that purpose Network Apps play 2 different roles when interacting with CAPIF:

- **Invoker**: a Network App acting as an Invoker is responsible for consuming APIs exposed by other services. This role represents an external application or service that  calls the 3GPP northbound APIs to utilize the network’s functionalities.

- **Provider**: a Network App acting as a Provider is responsible for exposing its own APIs//services for use by Invokers. This role represents an entity that offers services through APIs, making them available to other external applications or Invokers.A provider also is distinguished for having three parts.

- **Provider**: a Network App acting as a Provider is responsible for exposing its own APIs/services for use by Invokers. This role represents an entity that offers services through APIs, making them available to other external applications or Invokers.A provider also is distinguished for having three parts.

  - The AMF(API Management function), supplies the API provider domain with administrative capabilities. Some of these capabilities include, auditing the service API invocation logs received from the CCF, on-boarding/off-boarding new API invokers and monitoring the status of the service APIs.One provider can have only one AMF.

  - The **AMF (API Management Function)**, supplies the API provider domain with administrative capabilities. Some of these capabilities include, auditing the service API invocation logs received from the CCF, on-boarding/off-boarding new API invokers and monitoring the status of the service APIs.One provider can have only one AMF.

  - The APF (API Publishing Function), is responsible for the publication of the service APIs to CCF in order to enable the discovery capability to the API Invokers.One provider can have multiple APFs.

  - The **APF (API Publishing Function)**, is responsible for the publication of the service APIs to CCF in order to enable the discovery capability to the API Invokers.One provider can have multiple APFs.

  - AEF(API Exposing Function), is responsible for the exposure of the service APIs. Assuming that API Invokers are authorized by the CCF, AEF validates the authorization and subsequently provides the direct communication entry points to the service APIs. AEF may also authorize API invokers and record the invocations in log files.One provider can have multiple AEFs

  - The **AEF (API Exposing Function)**, is responsible for the exposure of the service APIs. Assuming that API Invokers are authorized by the CCF, AEF validates the authorization and subsequently provides the direct communication entry points to the service APIs. AEF may also authorize API invokers and record the invocations in log files.One provider can have multiple AEFs

OpenCAPIF SDK brings a set of functions to integrate with the 5G Core's function CAPIF, as defined in [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framework for 3GPP Northbound APIs](https://www.etsi.org/deliver/etsi_ts/129200_129299/129222/18.05.00_60/ts_129222v180500p.pdf). This section shows the mapping between the Python functions available in this SDK and the CAPIF OpenAPI APIs defined the reference standard:

- [CAPIF Discover API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Discover_Service_API.yaml)

- [CAPIF Publish API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml) 

- [CAPIF Security API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Security_API.yaml)

- [AEF Security API specification](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml)

NOTE: In the [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framework for 3GPP Northbound APIs](https://www.etsi.org/deliver/etsi_ts/129200_129299/129222/18.05.00_60/ts_129222v180500p.pdf) the `service` concept is understood as equal as the `API` concept.

## OpenCAPIF SDK requirements

To utilize the OpenCAPIF SDK, a registered user account within the target CAPIF instance is required. 

To use the OpenCAPIF SDK, a registered user account within the target CAPIF instance is required. 

**Contact the administrator to obtain the required predefined credentials (CAPIF username and password).**

    In this phase, the SDK creates and stores all the necessary files for using CAPIF as a provider, such as the authorization certificate, the server certificate and each of the APFs and AEFs certificates .Furthermore creates a file named `provider_capif_ids.json`, which stores important information about the provider.

3. **Prepare API details:** \

    In the `provider_folder`, more specifically in the `capif_username` folder, it will be located the provider API details file.\

    This file contains all the APFs and AEFs ids that have already onboarded with this `capif_username`.\

    Also it is very important to have previously prepared the API description of the API is going to be published.\

    This file needs to follow the [CAPIF_Publish_Service_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml).

    Choose one APF and the AEFs identifiers, and fulfill the publish_req structure and the api_description_path.

    In the `provider_folder`, more specifically in the `capif_username` folder, it will be sotres the provider API details file. This file contains all the APFs and AEFs IDs that have already onboarded with this `capif_username`.

    It is also important to have previously prepared the **API schema description** file of the API to be published. **This file must follow the [CAPIF_Publish_Service_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Publish_Service_API.yaml) 3GPP specification.**

    The provider_capif_ids variable is a dictionary which contains key-values of all the APFs and AEFs stored as name: ID.

    Choose one APF and the AEF identifiers, and fulfill the `publish_req` structure and the `api_description_path`.

    This publish_req field can also be filled with object variables already stored at provider object.

    The `provider_capif_ids` variable is a dictionary which contains key-values of all the APFs and AEFs stored as name: ID.

4. **Publish the services:** \

   Use the publish_services() method to register the APIs with the CAPIF framework(don't forget to update the capif_provider_connector constructor in order to use the new APF and AEFs):

    This `publish_req` field can also be filled with object variables already stored at provider object.

   In this phase, the SDK does the publishing of the provided API specification.

5. **Publish the services:** \

   Use the `publish_services()` method to register the APIs with the CAPIF framework. In this phase, the SDK does the publishing of the provided API specification.

   **At the end of this step, the API will be available for Invokers to be consumed.**

- `service_received.json`: if it is already used to get an API or get all APIs functionality, it will contain the response of last request,

- `provider_service_ids.json`: contains the currently published APIs with their `api_id`.

All the configuration values are available within the object capif_provider_connector.

All the configuration values are available within the object `capif_provider_connector`.

The provider_service_ids variable stores the `provider_service_ids.json` content in a dictionary form.

The `provider_service_ids` variable stores the `provider_service_ids.json` content in a dictionary form.

The provider_capif_ids variable stores the `provider_capif_ids.json` content in a dictionary form.

The `provider_capif_ids` variable stores the `provider_capif_ids.json` content in a dictionary form.

## Invoker Network App

  Use the `get_tokens()` method to obtain the necessary tokens for authenticating API requests.

**At the end of this flow, the invoker has been onboarded and it is ready to use target APIs.** All required information, including the access_token to use the available APIs, is stored at `capif_api_security_context_details.json` file. This file is placed in the invoker_folder path, specifically in the folder that corresponds to the capif_username used in the capif_sdk_config.json. A sample of the [capif_api_security_context_details](./samples/capif_api_security_context_details_sample.json) is also available.

**At the end of this flow, the invoker has been onboarded and it is ready to use target APIs.** All required information, including the access_token to use the available APIs, is stored at `capif_api_security_context_details.json` file. This file is placed in the invoker_folder path, specifically in the folder that corresponds to the capif_username used in the `capif_sdk_config.json`. A sample of the [capif_api_security_context_details](./samples/capif_api_security_context_details_sample.json) is also available.

Now, Invoker Network App can use access tokens to consume real services.

For testing APIs availability, after running both samples([Provider-Network App](./network_app_samples/network_app_provider_sample/network_app_provider.py) and [Invoker-Network App](./network_app_samples/network_app_invoker_sample/network_app_invoker.py)) the invoker app will return the access token.

Also, in the same Invoker-Network folder is available a [Postman structure](./network_app_samples/network_app_invoker_sample/postman/).In order to test these APIs, the access token returned in the Invoker-Network App must be placed in the Postman environment, more specifically in the access_token variable.

Also, in the same Invoker-Network folder is available a [Postman structure](./network_app_samples/network_app_invoker_sample/postman/).In order to test these APIs, the access token returned in the Invoker-Network App must be set in the Postman environment, more specifically in the `access_token` variable.

Another alternative is to import the [Postman structure](./network_app_samples/network_app_invoker_sample/postman/) in your own postman account and fill the `postman_api_key` and the `environment_id` fields within the [Invoker-Network App](./network_app_samples/network_app_invoker_sample/network_app_invoker.py). Here is an example of these two fields that need to be fulfilled. 

    2. If the Service Discovery Functionality has already been used , it will be found all the available APIs with their information,

    3. If the Service Get Token functionality has already been used , it will be found the access token for using the APIs that has already been discovered.

The `token` variable is also available for retrieving the JWT token after the get_tokens() method.

The `token` variable is also available for retrieving the JWT token after the `get_tokens()` method.

The invoker_capif_details variable stores the `capif_api_security_context_details.json` content in a dictionary form.

The `invoker_capif_details` variable stores the `capif_api_security_context_details.json` content in a dictionary form.

# OpenCAPIF SDK known issues

    - /trustedInvokers/{apiInvokerId}/delete (POST)

    - /trustedInvokers/{apiInvokerId} (GET)

    - /trustedInvokers/{apiInvokerId} (DELETE)

  - [AEF_Security_API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml)

    "invoker_folder": "",

    "capif_callback_url": "",

    "supported_features":"",

    "check_authorization":{

    "check_authentication":{

      "ip":"",

      "port":""

    },

    "cert_generation": {

      "csr_common_name": "",

      "csr_organizational_unit": "",

  - [As a Network App Invoker](#network-app-invoker)

  - [As a Network App Provider](#network-app-provider)

  - [Descriptions of capif_sdk_config Fields](#descriptions-of-capif_sdk_config-fields)

- [Configuration via capif-sdk-register.json](#configuration-via-capif-sdk-registerjson)

- [Configuration via capif_sdk_register.json](#configuration-via-capif-sdk-registerjson)

## Configuration via `capif_sdk_config.json`

- `cert_generation` (fields such as `csr_common_name`, `csr_country_name`, etc.)

**Optional:**

To enable the discovery of specific APIs, the fields under [`discover_filter`](#configuration-of-discover_filter) can be configured.

To use check_authentication() it will be required to fill up the `ip` and `port` parameters within the `check_authentication` variable.

- `discover_filter`: useful to enable the discovery of specific APIs. Some fields under [`discover_filter`](#configuration-of-discover_filter) structure required to be configured when using discovery filters. Check devoted section below,

- `check_authentication`: useful to use `check_authentication()` function to validate features from a target provider, it will be required to fill up the `ip` and `port` parameters within the `check_authentication` variable.

### Network App Provider

The `discover_filter` section adheres to the parameters defined in the GET request schema of the [Discover Services API](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_CAPIF_Discover_Service_API.yaml).

To utilize the service discovery functionality, the `discover_filter` fields should be populated with the desired filters. It is important to note that fields such as `api-name` must contain only one object of each type (i.e., no lists are allowed).

To use the service discovery functionality, the `discover_filter` fields should be populated with the desired filters. **It is important to note that fields such as `api-name` must contain only one entry of each type (i.e., no lists are allowed in api-name).**

For instance if the invoker fill the `api-name` field, the `discover()` functionality will retrieve only one API, the one that matches the exact name of the `api-name`.

Before running the Invoker Service Discovery Functionality, the Invoker must be onboarded to CAPIF.

**IMPORTANT**: All SDK configuration files must be filled out based on the intended role and features. Further details can be found in the [Configuration Section](./sdk_configuration.md).

**NOTE**: The register file is not required for SDK usage, only for SDK consumers that wish to create their capif_username.

**NOTE**: The register file is not required for SDK usage, only for SDK consumers that wish to create their `capif_username`.

## Table of Contents

The SDK streamlines API publishing with the option to select specific APFs and AEFs. A copy of the uploaded API is stored in `capif_<api_name>_<api_id>.json`, and the `provider_capif_ids.json` is updated with the API name and its ID.

### Service Deletion

**Important**: The SDK will automatically add in the `custom operations`, within the API description path, the capabilities for exposing the [AEF_security](https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS29222_AEF_Security_API.yaml) methods. The developer must code this API endpoints. 

**Required SDK inputs**:

- publisher_apf_id

- publisher_aefs_ids

The SDK simplifies the process of publishing an API in CAPIF, with the option to select specific APFs and AEFs. Before publishing, ensure you’ve [onboarded as a provider](#provider-onboarding).

### Service Deletion

**Required SDK inputs**:

OpenCAPIF SDK references:

- **Function**: `unpublish_service()`

- **Script**: `provider_unpublish_api.py`

The SDK simplifies API deletion. Service deletion requires prior onboarding and service publication.

**Required SDK inputs**:

- publisher_apf_id

- publisher_aefs_ids

### Service Updates

### Service Update

OpenCAPIF SDK references:

- **Function**: `update_service()`

- **Script**: `provider_update_api.py`

This function enables the updating of a previously registered API. Selecting APFs and AEFs is possible. Onboarding and service publishing are prerequisites.

This function enables to update a previously registered API. Selecting APFs and AEFs is possible. Onboarding and service publishing are prerequisites.

**Required SDK inputs**:

- service_api_id

- **Function**: `get_service()`

- **Script**: `provider_get_published_api.py`

Retrieve information on a previously published service, stored in `service_received.json`. Prior onboarding and service publication are necessary.

Retrieve information of a previously published service, stored in `service_received.json`. Prior onboarding and service publication are necessary.

**Required SDK inputs**:

- service_api_id

- publisher_apf_id

### Get All Services

OpenCAPIF SDK references:

- **Function**: `get_all_services()`

- **Script**: `provider_get_all_published_api.py`

Retrieve information about all previously published services in `service_received.json`. Ensure you are [onboarded as a provider](#provider-onboarding) and have [published services](#services-publishing).

**Required SDK input**:

- **Functions**: `update_provider()` and `offboard_provider()`

- **Scripts**: `provider_capif_connector_update.py` and `provider_capif_connector_offboarding.py`

`update_provider()`: The provider updates his features such as `APFs`, `AEFs`, etc...

`offboard_provider()`: The provider offboards from CAPIF, this will cause the erase of the published APIs that were currently exposed. 

The provider must be onboarded before using these features.

![Provider_update-offboard](./images/flows_provider_update_offboard.jpg)

OpenCAPIF SDK references:

- **Function**: `check_authentication()`

The SDK allows the API invoker to confirm the `supported_features` from the API exposing function(AEF).

The SDK allows the Network App Invoker to check the `supported_features` from the target Provider's API exposing function (AEF).

It is important to have obtained the [JWT token](#obtain-jwt-tokens) previously. 

It is mandatory to have obtained the [JWT token](#obtain-jwt-tokens) previously. 

**Required SDK inputs**:

- check_authentication

![Invoker_check_authentication](./images/flows_invoker_check_authentication.jpg)

### Update and Offboard Invoker

OpenCAPIF SDK references:

- **Functions**: `update_invoker()` and `offboard_invoker()`

- **Scripts**: `invoker_capif_connector_update.py` and `invoker_capif_connector_offboarding.py`

## Other Features

### CAPIF Registration and Login

OpenCAPIF SDK reference:

Simplifies the logout process for admin users and removes a CAPIF user.

![Register picture](./images/flows_sdk_with_register.jpg)

        discoverer.get_tokens()

        details = discoverer.invoker_capif_details

        tamaño = len(details["registered_security_contexes"])

        ip = details["registered_security_contexes"][tamaño-1]["aef_profiles"][0]["ip"]

        port = details["registered_security_contexes"][tamaño-1]["aef_profiles"][0]["port"]

        lenght = len(details["registered_security_contexes"])

        ip = details["registered_security_contexes"][lenght-1]["aef_profiles"][0]["ip"]

        port = details["registered_security_contexes"][lenght-1]["aef_profiles"][0]["port"]

        discoverer.check_authentication["ip"] = ip

        discoverer.check_authentication["port"] = port

        discoverer.check_authentication()