Typos fix

### Where is the registration done?

Registration is done in a REST API outside of the CAPIF specification taht we have implemented.

Registration is done in a REST API outside of the CAPIF specification that we have implemented.

### Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?

### When doing the register_provider where can I find the CSRs that are generated?

When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.

When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. In each of them, the apiProbPubKey field corresponds to the CSR.

### How to use the example client (CAPIF_INVOKER_GUI)?

### What is the purpose of the "get_security_auth" function in the invoker client?

Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.

It is used to request the token or refresh it in case it has expired. You have to use that token to call the API from the invoker.

### What is the purpose of the "register_security_context" function in the invoker client?

### **OpenCAPIF Services**

Te OpenCAPIF Component consists in X services, each one related with one API:

The OpenCAPIF Component consists of 12 services, each one related to one API:

- **CAPIF Discover Service**: Allows API invokers to search for and discover published APIs based on query filters, retrieving API metadata and interface information.

- **CAPIF Publish Service**: Allows API providers to publish, update and unpublish their APIs in the CAPIF Core, making them discoverable to authorized invokers.

- **NGINX**: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.

- **REDIS**: Used for internal communication of services.

- **Celery**: This component is responsible of send event messages when eventReq feature is active.

- **Celery**: This component is responsible for sending event messages when eventReq feature is active.

- **CAPIF DB**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.

The token has an expiration time of 10 minutes, so if it expires you will have to request a new one.

#### register_invoker

It is usedd to perform the onboarding of an Invoker,

It is used to perform the onboarding of an Invoker.

```

register_invoker <name>

```

#### get_security_auth

It is used to request the token necessary for the cunsumption of an API.

It is used to request the token necessary for the consumption of an API.

```

get_security_auth <api name>

As an administrator, you can manage which users can use CAPIF with the following commands.

#### login_admin

It is used to login as an administrator and obtain the tokenes needed to perform admin operations

It is used to login as an administrator and obtain the tokens needed to perform admin operations

```

login_admin <admin username> <admin password>

```

#### refresh_admin

It is used to refresh the tokenes of the admin user

It is used to refresh the tokens of the admin user

```

refresh_admin

Complete deployment of OpenCAPIF involves below services:

- Hasicorp Vault.

- Montoring stack (Prometheus, Grafana, ...)

- HashiCorp Vault.

- Monitoring stack (Prometheus, Grafana, ...)

- OpenCAPIF.

All needed files, like helm deployments and scripts are under [Helm Main] directory at OpenCAPIF repository.

## Helm Directory

In order to simplify the way to deploy, OCF SDG created different helms definitions to allow the deployment of all related services, like Vault, Montoring Stack and OpenCAPIF.

In order to simplify the way to deploy, OCF SDG created different helm definitions to allow the deployment of all related services, like Vault, Monitoring Stack and OpenCAPIF.

Those helms are fully functional, you will need to configure each one and also load security information to vault, and also you will need the knowledge to launch helm deployment on your environment. This is ***out of the scope*** of this Documentation.

Those helm are fully functional, you will need to configure each one and also load security information to vault, and also you will need the knowledge to launch helm deployment on your environment. This is ***out of the scope*** of this Documentation.

But we also created some scripts to simplify this proccess.

But we also created some scripts to simplify this process.

## Helm Scripts

```

> **IMPORTANT NOTE:** In some versions change of hostname in local deployment (setting some value different than ***capifcore***) creates wrong certificates on vault component. This prevents successful requests using the certificates. if this is your case, here is a little workaround to solve this issue meanwhile SDG is solving it:

> **IMPORTANT NOTE:** In some versions change of hostname in local deployment (setting some value different than ***capifcore***) creates wrong certificates on vault component. This prevents successful requests using the certificates. if this is your case, here is a workaround to solve this issue while SDG investigates a permanent fix:

> * Modify the hostname in the file ***capif/services/vault/vault_prepare_certs.sh*** on lines 43, 68, and 95.

> * Update the url parameter of the CCF from capifcore to the desired hostname in the file ***capif/services/register/config.yaml***.

| create_users.sh                    | Create users at local deployment.                                                                    |

| remove_users.sh                    | Delete users at local deployment.                                                                    |

| run_capif_tests.sh                 | Run Capif tests by using robot image.                                                                |

| run_interonnection_environments.sh | Deploy locally two instances of OpenCAPIF. You must specify the envs to be used.                     |

| run_interconnection_environments.sh | Deploy locally two instances of OpenCAPIF. You must specify the envs to be used.                     |

| run_mock_server.sh                 | Deploy locally the mock server instance.                                                             |

| run.sh                             | Deploy locally an OpenCAPIF Instance.                                                                |

| show_logs.sh                       | Shows the logs of local deployed OpenCAPIF Services.                                                 |

| variables.sh                       | This script just set default values to be used by local environment. Can be overrided by envs files. |

| variables.sh                       | This script just set default values to be used by local environment. Can be overridden by envs files. |

#### Start Your Testing with OpenCAPIF