diff --git a/public/latest b/public/latest index ce57f645631949ca9e6bf328b5796c9263cc7a2a..c5c23a13a4211c4ef0781dc1a0d6cbb78a2b0eb7 120000 --- a/public/latest +++ b/public/latest @@ -1 +1 @@ -develop \ No newline at end of file +v3.0.0-release \ No newline at end of file diff --git a/public/v3.0.0-release/404.html b/public/v3.0.0-release/404.html new file mode 100644 index 0000000000000000000000000000000000000000..7ae57d2f71b0ef433fcaa3b2c0485c53b350d226 --- /dev/null +++ b/public/v3.0.0-release/404.html @@ -0,0 +1,1387 @@ + + + +
+ + + + + + + + + + + + + + + + + + +No, you only have to make the request to the "/onboarding" endpoint. In it you must specify a CSR for the AEF, APF and AMF and you will receive the certificates for each of them in the response.
+There are different services, the APF, intended for publishing the APIs, and the AEF, intended so that the invoker can call it. The APF is what connects to the Capif Core Function to publish the service and when the service is up, you need the AEF service so that invokers can connect to it.
+Vault is a secrets management system used to securely store and manage sensitive information like API keys, TLS certificates, and authentication tokens. In the context of OpenCAPIF, Vault is used to securely handle and distribute the certificates and private keys for the AEF, APF, and AMF components during onboarding. This ensures that secrets are not exposed in code or configuration files, and enables automated certificate rotation, audit logging, and fine-grained access control.
+Yes, before publishing an API you must register using the POST /register endpoint.
+Registration is done in a REST API outside of the CAPIF specification taht we have implemented.
+When you make the request to the "/endpoint" of register, you will be returned a username and a password determined by CAPIF.
+A CSR is a Certificate Signing Request. It is a generated data block where the certificate is planned to be installed and contains key information such as public key, organization, and location, and is used to request a certificate from a certificate authority (CA). In CAPIF, 3 CSRs are necessary to register a provider, for AEF, APF and AMF.
+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.
+First you have to make a "./run.sh host:port" indicating the address of the public CAPIF. Once the Docker containers are up, you have to do a "./terminal_to_py_netapp.sh" and then a "python main.py". At this point we will find ourselves in a console with some predefined commands to use the Client. If we press tab twice it will bring up the list of available commands.
+The CAPIF public instance can be found at the following URLs: +- capif.mobilesandbox.cloud:37211 (HTTPS) +- capif.mobilesandbox.cloud:37212 (HTTP)
+No, you only have to publish a single API but each component is responsible for a specific service, whether publishing or exposing.
+It is better to unsubscribe the API every time you exit the application since otherwise it could be republished and it would be double.
+Yes, a user can have multiple invokers at the same time, and as such, the username and password would be the same.
+This is the callback URL used to notify events. CAPIF has an Event service to subscribe to that notifies actions such as a subscription to an API, a change in the state of an API...
+No, it is not mandatory, but if you do not enter it you will not receive any CAPIF events. For example, the APF may delete the API, you will not be notified that the API is no longer available.
+The discover_service returns a json with all the services that exist exposed in CAPIF at that moment.
+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.
+To consume the API it is necessary to have a Security Context registered with the data and the authentication method.
+No, a user registers in CAPIF and once done can have the role of invoker, provider or both.
+You have to set your endpoint when doing the "publish_service" functionality:
+publish_service capif_ops/config_files/service_api_description_hello.json
In the file "service_api_description_hello.json" you configure the service that is going to be exposed and by developing one to suit you, you expose your API.
+ + + + + + + + + + + + + +The API Status feature, introduced in the 3GPP Common API Framework (CAPIF) technical specifications starting from Release 17, offers significant enhancements for operators and developers.
+This feature in OpenCAPIF provides real-time insights into the operational status of APIs, enabling stakeholders to quickly determine whether an API is functioning as expected. By improving API availability tracking, it helps users make more informed decisions about integration and usage.
+This new functionality is found in two CAPIF services, the publish service and the events service.
+The API Status in the publish service allows providers to show in which AEFs the published API is available.
+In order to use the API Status, it is necessary to have apiStatusMonitoring enabled in supportedFeatures when publishing an API. With this enabled, we can use the publication's apiStatus, which is composed of a list of AEF identifiers in which the API is available.
+This gives us 4 options for displaying the status of an API:
+If apiStatusMonitoring is not supported and apiStatus is used to show API availability, a 400 error will be returned.
+The API Status within the Events service provides critical insights into the availability of subscribed services.
+Both API Invokers and Providers can subscribe to the SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE events to receive timely notifications about the operational status of an API, whether it becomes available or unavailable.
+Additionally, if the enhanced_event_report function is supported, the API description could be received as event details in the eventDetails field if apiStatusMonitoring is also enabled. This will make it easier for event subscribers to know if any changes have been made to the API, such as a change in API availability to other AEFs.
+ + + + + + + + + + + + + +The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:
+Each component is separated into different namespaces and all communications between them use Rest APIs.
+Apart from the communication between components, there are 2 other entities that can use them:
+This namespace belongs to the Register service, and we find 2 components:
+This namespace belongs to Vault.
+This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.
+This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:
+You can check the details of all these changes in the conversation on the OCF wiki.
+ + + + + + + + + + + + + +