.gitlab-ci.yml

@@ -4,9 +4,9 @@ pages:
   variables:
     PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
     PAGES_BRANCH: gl-pages
-    HTTPS_REMOTE: https://gitlab-ci-token:${ACCESS_TOKEN}@${CI_SERVER_HOST}/rep/${CI_PROJECT_PATH}.git
+    HTTPS_REMOTE: https://gitlab-ci-token:${CUSTOM_PROJECT_ACCESS_TOKEN}@${CI_SERVER_HOST}/rep/${CI_PROJECT_PATH}.git
   before_script:
-    - pip install -q mkdocs-material mike
+    - pip install -q mkdocs-material mkdocs-glightbox mkdocs-markdownextradata-plugin mike 
     - apt-get update -qq && apt-get -qq install -y git > /dev/null
     - git config --global --replace-all user.name $GITLAB_USER_NAME
     - git config --global --replace-all user.email $GITLAB_USER_EMAIL
@@ -19,8 +19,6 @@ pages:
         mike set-default --deploy-prefix public -r $HTTPS_REMOTE -p -b $PAGES_BRANCH latest
       elif [ "$CI_COMMIT_REF_NAME" == "develop" ]; then
         mike deploy --deploy-prefix public -r $HTTPS_REMOTE -p -b $PAGES_BRANCH -u $CI_COMMIT_BRANCH latest
-      elif [ -n "$CI_CLEAN" ]; then
-        rm -rf public/$CI_CLEAN
       fi
 
     - git checkout $PAGES_BRANCH -- public/

doc/configuration/configuration.md

+# CAPIF Dynamic Configuration
+
+## Overview
+CAPIF supports dynamic configuration management, enabling modifications without requiring redeployment. This is achieved by storing configurations in MongoDB collections for both CAPIF and Register services, allowing CAPIF to retrieve and apply configuration changes dynamically.
+
+This new approach provides:
+  
+* **Real-time configuration updates**: Modify parameters on the fly.
+* **Extensibility**: Add new parameters or sections dynamically.
+* **Improved flexibility**: Reduce static configuration dependencies.
+
+## CAPIF Configuration
+
+In the CAPIF MongoDB instance, it is included a collection of the configuration.
+
+```json
+capif_configuration: {
+  "config_name": "default",
+  "version": "1.0",
+  "description": "Default CAPIF Configuration",
+  "settings": {
+    "certificates_expiry": {
+      ttl_superadmin_cert: "4300h",
+      ttl_invoker_cert: "4300h",
+      ttl_provider_cert: "4300h",
+    },
+    "security_method_priority": {
+      oauth: 1,
+      pki: 2,
+      psk: 3
+    },
+    "acl_policy_settings": {
+      allowed_total_invocations: 5,
+      allowed_invocations_per_second: 10,
+      allowed_invocation_time_range_days: 365
+    }
+  }
+}
+```
+
+
+## Register Configuration
+
+Similarly, the Register service includes a dynamic configuration stored in its MongoDB instance:
+
+```json
+capif_configuration: {
+  "config_name": "default",
+  "version": "1.0",
+  "description": "Default Register Configuration",
+  "settings": {
+    "certificates_expiry": {
+      ttl_superadmin_cert: "4300h",
+    }
+  }
+}
+```
+
+## Configuration Management Endpoints
+
+Both CAPIF and the register configuration are managed via API, the general configuration of CAPIF from the Helper service and the register configuration from the register. In both services these endpoints enable:
+
+1. Retrieving the current configuration – View the existing settings stored in MongoDB.
+
+2. Modifying configuration parameters – Update specific values dynamically.
+
+3. Adding new configuration settings – Introduce additional parameters within existing sections or create entirely new sections in the configuration.
+
+For more details, you can check the API documentation of the Helper and Register services:
+
+- [Helper Service API Documentation](../helper/swagger.md)
+- [Register Service API Documentation](../register/swagger.md)
+
+
+
+

doc/contribute/documenting.md

@@ -14,7 +14,7 @@ Documenting OpenCAPIF is limited to active contributors. So, if you:
 
 [MkDocs](https://www.mkdocs.org/) is a fast and simple static site generator that's geared towards building project documentation. Documentation source files are written in `Markdown`, and configured with a single `YAML` configuration file. Start by reading the [introductory tutorial](https://www.mkdocs.org/getting-started/), then check the [User Guide](https://www.mkdocs.org/user-guide/) for more information.
 
-### How it works?
+### How does it work?
 
 There are 2 ways to upgrade documentation published on the [OCF Documentation] website:
 
@@ -25,14 +25,15 @@ There are 2 ways to upgrade documentation published on the [OCF Documentation] w
 
 This documentation repository has 2 protected branches:
 
-  * **main**: this branch will store the information stable;
-  * **develop**: any change uploaded on this branch will upgrade **develop** version of the documentation published on the [OCF Documentation] website.
+  * **main**: stable timeline on which tags are made;
+  * **develop**: edge timeline, also published on the [OCF Documentation] website.
 
 ### Structure
 
 In the `mkdocs.yml` file you will find the navigation structure of the documentation, there you can sections with sub-sections.
 
 *For example:*
+
 ```yaml
 nav:
   - Overview:
@@ -54,9 +55,11 @@ As you can see here, we have at the time of writing this page, 5 main sections:
   * Contribute: details about how to contribute code and docs;
   * FAQ.
 
+Please take a moment to understand the current structure of the documentations and think to update after contributing if necessary.
+
 ### Main Page
 
-The page shown first is at **doc/index.md**. That page should be updated with the latest changes of OpenCAPIF, also including the version.
+The page shown first is at **doc/index.md**. That page should be updated with the latest changes of OpenCAPIF and should reference the version (useful shortcut is ``{{{ documentation_version }}}``).
 
 ## Getting Started
 
@@ -75,14 +78,26 @@ cd ./documentation
 git checkout develop
 ```
 
-3) Setup a local ``mkdocs`` server, using a virtual environment:
+3) Setup a virtual environment:
+
+* On Linux/macOS:
+
+```bash
+python3 -m venv venv # Linux/macOS
+source venv/bin/activate #Linux/macOS
+```
+
+* On Windows:
+
+```bash
+python -m venv venv # Windows
+venv\Scripts\activate # Windows
+```
+
+4) Setup a local ``mkdocs`` server by installing requirements:
 
 ```bash
-python3 -m venv venv
-source venv/bin/activate
-python -m pip install mkdocs
-python -m pip install mkdocs-material
-python -m pip install mike
+python -m pip install -r requirements.txt
 ```
 
 4) Wait for all downloads to finish and start the local ``mkdocs`` server:
@@ -104,18 +119,17 @@ To update the documentation properly during development, follow those additional
 3. Update the documentation and any relevant parts (ie: the ``index.md`` with new functionalities for the latest version or if a new test plan has been defined, remember to *update the test plan documentation*);
 4. Check if errors are not being produced by ``mkdocs`` [locally](#getting-started);
 5. Commit and push changes to the new branch;
-6. Create a merge/pull request;
+6. Create a merge/pull request towards **develop**;
 7. Send the request for review and approval to at least one **TSC Member**.
 
-> The documentation website supports branches, so your accepted changes will be reflected to the **develop** branch which becomes the **release** branch after each corresponding cycle.
+> The documentation website supports branches, so your accepted changes will be reflected to the **develop** branch which then becomes the **release** branch after each corresponding cycle.
 
 ### Release a New Version of the Documentation
 
 When **OpenCAPIF** code repository is ready for a new release, we need to follow these steps (made by a **TSC Member**):
 
-1. Create a new branch with the released version, and merge it to **develop**;
-2. Create a Merge request from **develop** to **main**;
-3. When develop is merged to **main**, then we need to **create a tag with the released version**.
+1. Create a PR from **develop** towards **main**;
+2. When **develop** is merged to **main**... then **create a tag with the released version** scheme... and you're done!
 
 [OCF Web]: https://ocf.etsi.org/ "OCF Web"
 [OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation"

doc/event-filter/event-filter.md

+# Event Filter
+
+The **Event Filter** is a feature of the CAPIF Events service that allows you to receive specific notifications about the events you are subscribed to. This tool is essential for efficiently managing and monitoring relevant events, ensuring that users receive only the information they need.
+
+## How it works
+
+To specify the desired filter during subscription, you can use the ***eventFilters*** field, provided that the ***Enhanced Event Report*** flag is enabled in the ***Supported Features*** characteristics.
+
+The ***eventFilters*** field consists of a list of filters that correspond one-to-one with the list of events in the ***events*** field. Thus, the first element of the filter list corresponds to the first element of the events list, the second filter element to the second event element, and so on.
+
+Each filter contains three lists:
+
+- **apiIds**: Identifiers of the APIs from which you want to receive notifications.
+- **apiInvokerIds**: Identifiers of the invokers from which you want to receive notifications.
+- **aefIds**: Identifiers of the AEFs from which you want to receive notifications.
+
+Depending on the event you subscribe to, you can use one or more of these lists. The following table shows the filtering options available for each event:
+
+| Event                           | apiIds | aefIds | apiInvokerIds |
+|---------------------------------|:------:|:------:|:-------------:|
+| SERVICE_API_AVAILABLE           |   X    |        |               |
+| SERVICE_API_UNAVAILABLE         |   X    |        |               |
+| SERVICE_API_UPDATE              |   X    |        |               |
+| API_INVOKER_ONBOARDED           |        |        |       X       |
+| API_INVOKER_OFFBOARDED          |        |        |       X       |
+| API_INVOKER_UPDATED             |        |        |       X       |
+| ACCESS_CONTROL_POLICY_UPDATE    |   X    |        |       X       |
+| SERVICE_API_INVOCATION_SUCCESS  |   X    |   X    |       X       |
+| SERVICE_API_INVOCATION_FAILURE  |   X    |   X    |       X       |
+| API_TOPOLOGY_HIDING_CREATED     |        |        |               |
+| API_TOPOLOGY_HIDING_REVOKED     |        |        |               |
+
+In cases where 2 or 3 lists are specified simultaneously for an event, notifications will only be sent when there is at least one matching element in each of the subscription lists. For example, if you subscribe to the ***ACCESS_CONTROL_POLICY_UPDATE*** event using the ***apiIds*** and ***apiInvokerIds*** filter lists, you will only be notified when the access control policy update corresponds to an API in the ***apiIds*** list and an invoker in the ***apiInvokerIds*** list at the same time.
+
+[OCF Web]: https://ocf.etsi.org/ "OCF Web"
+[OCF Documentation]: https://ocf.etsi.org/documentation/ "OCF Documentation"

doc/helper/helper.md

+# Introduction to the Helper Service
+
+## Overview
+
+CAPIF does not include any built-in mechanism to expose data via API. This makes it difficult to retrieve essential information such as the number of registered API Invokers, a list of available API Invokers, etc.
+
+Without a dedicated tool, accessing this data requires direct database queries, making it inefficient and impractical.
+
+## Helper Service
+
+The Helper Service addresses this limitation by acting as an intermediary that exposes CAPIF’s stored data in a structured and accessible manner. This service provides APIs that allow users to query the CAPIF database and obtain valuable insights, such as:
+
+- The total count and details of registered API Invokers and API Providers.
+- A structured and API-driven way to retrieve CAPIF-related information.
+- Simplified access to important data without the need for direct database interactions.
+- Access to security contexts, helping manage authentication and authorization processes.
+- Retrieval of event records, providing insight into CAPIF system activities.
+- The ability to delete different CAPIF entities, facilitating resource management.
+- Full control over CAPIF dynamic configuration, including:
+    - Retrieving the current configuration.
+    - Modifying specific parameters.
+    - Adding or updating configuration settings dynamically.
+
+By this Helper Service, CAPIF users can effortlessly retrieve and manage critical system information, improving overall visibility and efficiency.
+
+
+## API Documentation
+
+For a detailed API reference, please check the **Helper Service Swagger Documentation**:
+
+➡️ [Helper Service API Documentation](../helper/swagger.md)

doc/helper/swagger.md

+## Helper API Documentation
+
+<div id="swagger-ui"></div>
+<script>
+    window.onload = function() {
+    const ui = SwaggerUIBundle({
+        url: "../../swagger/helper_swagger.yaml",
+        dom_id: '#swagger-ui',
+        presets: [SwaggerUIBundle.presets.apis, SwaggerUIStandalonePreset],
+        layout: "StandaloneLayout"
+    });
+    };
+</script>
\ No newline at end of file

doc/register/register.md

+# Register Service
+
+## Overview
+
+The Register Service is responsible for user management within the CAPIF ecosystem.  
+It provides a structured way to register, authenticate, and manage user that interact with CAPIF, ensuring a secure and efficient process.
+
+
+## API Documentation
+
+For more details, refer to the **API documentation**:
+
+- [Register Service API Documentation](../register/swagger.md)

doc/register/swagger.md

+## Register API Documentation
+
+<div id="swagger-ui"></div>
+<script>
+    window.onload = function() {
+    const ui = SwaggerUIBundle({
+        url: "../../swagger/register_swagger.yaml",
+        dom_id: '#swagger-ui',
+        presets: [SwaggerUIBundle.presets.apis, SwaggerUIStandalonePreset],
+        layout: "StandaloneLayout"
+    });
+    };
+</script>

doc/releasenotes.md

+## **Release 3.x.x**
+
+### **New Features**
+
+#### **Added Event Filters**
+
+- Check [Event Filter section](./event-filter/event-filter.md)
+- New filters for Event service subscriptions.
+    - You can now specify from which API, AEF, or Invoker you want to receive the event notifications.
+    - These filters are specified in the ***eventFilters*** of the subscription if the ***Enhanced Event Report*** feature of the ***Supported Features*** is activated.
+- More detailed information about event filters can be found in [Event Filter].
+
+### **Testing**
+
+- New Event Filter test suite with 8 tests. [Event Filter test suite](./testing/testplan/event_filter/README.md)
+
+
+### **Technical Debt Solved**
+
+- Implemented in the API Provider Management the supported features negotiation for the suppFeat field during provider registration. The server now decodes the negotiated feature set based on client capabilities and system support.
+
+#### **Hardening on startup scripts for services interacting with Vault**
+
+The startup scripts of the ***Invoker Management Service***, ***Provider Management Service***, and ***Security Service*** have been improved to ensure reliability when the Vault service takes longer to become ready. These new scripts check responses from the Vault to ensure the returned information is valid before starting each service.
+
+This will also helps on the restart issue on k8s deployed OpenCAPIF.
+
+#### Dynamic configurations
+- Add new collection in CAPIF mongo with the init configuration.
+- New endpoints in Helper to manage the CAPIF configuration.
+- Add new collection in Register mongo with the init configuration.
+- New endpoints in Register to manage the Register configuration.
+- Documentation about Dynamic Configuration.
+- Documentation about Helper and Register swaggers.
+
+### **Documentation**
+
+#### Improvements over documentation
+- New [Event Filter section](./event-filter/event-filter.md)
+- New [Vendor Extensibility section](./vendor-ext/vendor-ext.md)
+- New [API Status section](./api-status/api-status.md)
+- New [Dynamic Configuration section](./configuration/configuration.md)
+
+#### Testplan
+- New tests related with [Api Status Feature](./testing/testplan/api_status/README.md).
+- New tests related with [Event Filter Feature](./testing/testplan/event_filter/README.md).
+- New tests related with [Vendor Extensibility](./testing/testplan/vendor_extensibility/README.md)
+- [Security Service Testplan](./testing/testplan/api_security_service/README.md) updated according to new features and Technical debts.
+
 ## **Release 2.0.0**
 
 ### **New Features**
@@ -12,6 +61,7 @@
 
 #### **Vendor Extensibility**
 
+- Check [Vendor Extensibility section](./vendor-ext/vendor-ext.md)
 - Publish API:
     - On publishing a service API, **SupportedFeatures** is read and checked whether VendExt feature is enabled.
     - When VendExt is enabled, vendor-specific fields are searched and stored in the db inside the ServiceAPIDescription object
@@ -67,12 +117,14 @@
 
 #### **Api Status feature**
 
+- Check [API Status section](./api-status/api-status.md)
 - New logic to support ***API Status*** feature on Publish and Events Services.
 - Events API:
     - Event internal notifications between services improved to accomplish specification.
     - On event subscription **SupportedFeatures** is read and stored in db to accomplish specification.
     - Also **SupportedFeatures** is checked before send event notification, in order to accomplish specification, sending **eventDetails** and related information according to ***enhanced_event_report*** and ***apiStatusMonitoring*** supported features activated.
 
+
 #### Remote Scripts
 
 New scripts developed to help on remote deployment, configuration and testing. All this script are stored under helm/scripts in capif repository.

doc/sandbox/relevantinfo.md

+This section provides users with essential details to interact with the OpenCAPIF Sandbox, including endpoint URLs, example requests, and client implementation references.
+
+## Public Sandbox URLs
+Below are the key endpoints required for API interactions within the sandbox environment:
+
+- **Registration Service**: `https://register-opencapif.etsi.org`
+- **OpenCAPIF Service**: `https://opencapif.etsi.org`
+
+## Postman collection and flows
+To facilitate API testing and integration, we provide example requests that can be used in Postman:
+
+- **[Postman Collection for OpenCAPIF](../testing/postman/README.md)**: A ready-to-use collection with predefined requests to interact with the sandbox APIs including flows.
+
+## Example Client Implementations
+For users who wish to integrate OpenCAPIF into their applications, we provide [invoker and provider example](../example-clients/example-clients.md) clients:
+
+- **Invoker Client**: [invoker-cli Repository](https://labs.etsi.org/rep/ocf/example-clients/invoker-cli)
+- **Provider Client**: [provider-cli Repository](https://labs.etsi.org/rep/ocf/example-clients/provider-cli)
+
+These resources are continuously updated to align with the latest OpenCAPIF developments, ensuring users have access to functional and relevant examples.
+
+## Disclaimer
+The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.

doc/sandbox/requestaccess.md

+To request access to the OpenCAPIF Sandbox, users can choose one of the following methods:
+
+- **Email Request**: Send an email to [OCF_TECH](mailto:OCF_TECH@list.etsi.org) with the required information.
+- **Slack Channel**: Contact us through the OpenCAPIF User an Developer Communities Slack channel [#sandbox-access](https://opencapif.slack.com/archives/C08K1AJ9ZTJ) and provide the necessary details.
+
+### Required Information
+Regardless of the method chosen, users must include the following details in their request:
+
+- **Company Name**: The name of the organization requesting access.
+- **Purpose of Access**: A brief description of why access is needed.
+- **Contact Information**: Email address (mandatory), telephone number (optional).
+- **Preferred Username**: A desired username for the account (subject to availability; may require modification if already in use).
+
+Once the request is received, the OpenCAPIF team will review the details and provide the necessary credentials or follow up if additional information is required.
+
+## Disclaimer
+The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.

doc/sandbox/sandbox.md

+The OpenCAPIF Sandbox is a dedicated environment designed to allow developers, researchers, and potential users to explore and test the latest developments in OpenCAPIF. This controlled setting provides a safe and isolated space to interact with OpenCAPIF APIs, ensuring that users can evaluate functionalities, experiment with integrations, and validate use cases without affecting live systems.
+
+### Benefits of Using the Sandbox
+- **Risk-Free Testing**: Users can experiment with the latest OpenCAPIF features without impacting production environments.
+- **Hands-On Experience**: Gain practical insights into OpenCAPIF capabilities through real API interactions.
+- **Rapid Prototyping**: Test and refine API integrations efficiently before deploying in real-world scenarios.
+- **Up-to-Date Environment**: Always access the most recent OpenCAPIF developments and improvements.
+
+For more details on accessing the Sandbox and utilizing its features, please refer to the following sections:
+
+- [Request Access](./requestaccess.md): Learn how to create a user account and obtain credentials to interact with the Sandbox.
+- [Relevant Information](./relevantinfo.md): Find important details such as endpoint URLs and links to example use cases in the documentation.
+
+## Disclaimer
+The OpenCAPIF Sandbox is a temporary and non-persistent testing environment. Any data stored within the sandbox is not backed up and may be periodically cleaned or reset without prior notice. Users should not store critical or long-term data in this environment. Always ensure that any necessary backups are maintained externally.

doc/swagger/helper_swagger.yaml

@@ -312,6 +312,196 @@ paths:
                 $ref: '#/components/schemas/EventsResponse'
         "400":
           description: Invalid page or page_size supplied.
+  /helper/getConfiguration:
+    get:
+      tags:
+        - Configuration
+      summary: Retrieve CAPIF configuration
+      description: Fetches the current CAPIF configuration from MongoDB.
+      operationId: GetConfiguration
+      responses:
+        "200":
+          description: Returns the current CAPIF configuration.
+          content:
+            application/json:
+              schema:
+                type: object
+                example:
+                  config_name: "default"
+                  version: "1.0"
+                  settings:
+                    certificates_expiry:
+                      ttl_superadmin_cert: "4300h"
+                      ttl_invoker_cert: "4300h"
+                      ttl_provider_cert: "4300h"
+                    security_method_priority:
+                      oauth: 1
+                      pki: 2
+                      psk: 3
+                    acl_policy_settings:
+                      allowed_total_invocations: 5,
+                      allowed_invocations_per_second: 10,
+                      allowed_invocation_time_range_days: 365
+  /helper/updateConfigParam:
+    patch:
+      tags:
+        - Configuration
+      summary: Update a configuration parameter
+      description: Updates a specific configuration parameter inside CAPIF settings.
+      operationId: UpdateConfigParam
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "settings.security_method_priority.oauth"
+                new_value:
+                  type: integer
+                  example: 2
+      responses:
+        "200":
+          description: Configuration parameter updated successfully.
+        "400":
+          description: Missing 'param_path' or 'new_value' in request body.
+  /helper/replaceConfiguration:
+    put:
+      tags:
+        - Configuration
+      summary: Replace the entire CAPIF configuration
+      description: Completely replaces the CAPIF configuration with a new one.
+      operationId: ReplaceConfiguration
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              example:
+                  config_name: "default"
+                  version: "1.0"
+                  settings:
+                    certificates_expiry:
+                      ttl_superadmin_cert: "5000"
+                      ttl_invoker_cert: "2500"
+                      ttl_provider_cert: "3300"
+                    security_method_priority:
+                      oauth: 2
+                      pki: 3
+                      psk: 1
+                    acl_policy_settings:
+                      allowed_total_invocations: 15,
+                      allowed_invocations_per_second: 20,
+                      allowed_invocation_time_range_days: 200
+      responses:
+        "200":
+          description: Configuration replaced successfully.
+        "400":
+          description: Missing new configuration in request body.
+  /helper/addNewConfiguration:
+    post:
+      tags:
+        - Configuration
+      summary: Add a new configuration category
+      description: Adds a new category inside the 'settings' section of CAPIF configuration.
+      operationId: AddNewConfiguration
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                category_name:
+                  type: string
+                  example: "new_policy_settings"
+                category_values:
+                  type: object
+                  example:
+                    max_invocations: 50
+                    rate_limit: 5
+      responses:
+        "200":
+          description: Category added successfully.
+        "400":
+          description: Missing 'category_name' or 'category_values' in request body.
+  /helper/addNewConfigSetting:
+    patch:
+      tags:
+        - Configuration
+      summary: Add a new configuration parameter
+      description: Adds a new parameter inside an existing category in 'settings'.
+      operationId: AddNewConfigSetting
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "settings.certificates_expiry.new_ttl"
+                new_value:
+                  type: integer
+                  example: 10
+      responses:
+        "200":
+          description: Parameter added successfully.
+        "400":
+          description: Missing 'param_path' or 'new_value' in request body.
+  /helper/removeConfigParam:
+    delete:
+      tags:
+      - Configuration
+      summary: Delete a specific parameter inside 'settings'
+      description: Removes a specific configuration parameter inside a 'settings' category.
+      operationId: RemoveConfigParam
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "settings.security_method_priority.oauth"
+      responses:
+        "200":
+          description: Parameter removed successfully.
+        "400":
+          description: Missing 'param_path' in request body.
+        "404":
+          description: No configuration found or parameter not removed.
+
+  /helper/removeConfigCategory:
+    delete:
+      tags:
+      - Configuration
+      summary: Delete an entire category inside 'settings'
+      description: Removes an entire category inside 'settings'.
+      operationId: RemoveConfigCategory
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                category_name:
+                  type: string
+                  example: "new_policy_settings"
+      responses:
+        "200":
+          description: Category removed successfully.
+        "400":
+          description: Missing 'category_name' in request body.
+        "404":
+          description: No configuration found or category not removed.
 components:
   schemas:
     InvokersResponse:

doc/swagger/register_swagger.yaml

+openapi: 3.0.0
+info:
+  title: Register Service API
+  description: API for user registration and configuration management in CAPIF.
+  version: 1.0.0
+
+servers:
+  - url: https://localhost:8084
+    description: Local development server
+
+paths:
+  /login:
+    post:
+      summary: Admin login
+      description: Logs in an admin user and returns access and refresh tokens.
+      tags:
+        - Authentication
+      security:
+        - basicAuth: []
+      responses:
+        "200":
+          description: Successfully logged in
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  access_token:
+                    type: string
+                  refresh_token:
+                    type: string
+        "401":
+          description: Unauthorized
+
+  /refresh:
+    post:
+      summary: Refresh access token
+      description: Generates a new access token using a refresh token.
+      tags:
+        - Authentication
+      security:
+        - bearerAuth: []
+      responses:
+        "200":
+          description: New access token generated
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  access_token:
+                    type: string
+        "401":
+          description: Unauthorized
+
+  /createUser:
+    post:
+      summary: Register a new user
+      description: Allows an admin to create a new user.
+      tags:
+        - Users
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                username:
+                  type: string
+                password:
+                  type: string
+                enterprise:
+                  type: string
+                country:
+                  type: string
+                email:
+                  type: string
+                purpose:
+                  type: string
+      responses:
+        "201":
+          description: User registered successfully
+        "400":
+          description: Missing or invalid fields
+        "409":
+          description: User already exists
+
+  /getauth:
+    get:
+      summary: Get user authorization
+      description: Retrieves authorization information for a user.
+      tags:
+        - Users
+      security:
+        - basicAuth: []
+      responses:
+        "200":
+          description: Authorization details returned
+        "400":
+          description: User not found
+
+  /deleteUser/{uuid}:
+    delete:
+      summary: Delete a user
+      description: Removes a user from the system.
+      tags:
+        - Users
+      security:
+        - bearerAuth: []
+      parameters:
+        - name: uuid
+          in: path
+          required: true
+          schema:
+            type: string
+      responses:
+        "204":
+          description: User deleted successfully
+        "400":
+          description: Invalid UUID
+
+  /getUsers:
+    get:
+      summary: Get all users
+      description: Retrieves a list of all registered users.
+      tags:
+        - Users
+      security:
+        - bearerAuth: []
+      responses:
+        "200":
+          description: Users retrieved successfully
+
+  /configuration:
+    get:
+      summary: Retrieve register configuration
+      description: Fetches the current configuration of the register service.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      responses:
+        "200":
+          description: Configuration retrieved successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  config_name:
+                    type: string
+                  description:
+                    type: string
+                  version:
+                    type: string
+                  settings:
+                    type: object
+                    properties:
+                      certificates_expiry:
+                        type: object
+                        properties:
+                          ttl_superadmin_cert:
+                            type: string
+        "404":
+          description: Configuration not found
+    patch:
+      summary: Update register configuration
+      description: Updates a specific parameter in the register configuration.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "settings.certificates_expiry.hola"
+                new_value:
+                  type: string
+                  example: "2500h"
+      responses:
+        "200":
+          description: Parameter updated successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Parameter 'settings.certificates_expiry.ttl_superadmin_cert' updated successfully"
+        "400":
+          description: Invalid request body
+    put:
+      summary: Replace register configuration
+      description: Replaces the entire configuration with a new one.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                config_name:
+                  type: string
+                  example: "default"
+                description:
+                  type: string
+                  example: "Updated Register Configuration"
+                version:
+                  type: string
+                  example: "1.1"
+                settings:
+                  type: object
+                  properties:
+                    certificates_expiry:
+                      type: object
+                      properties:
+                        ttl_superadmin_cert:
+                          type: string
+                          example: "4300h"
+      responses:
+        "200":
+          description: Configuration replaced successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Register configuration replaced successfully"
+        "400":
+          description: Invalid request body
+
+  /configuration/addNewCategory:
+    post:
+      summary: Add new configuration category
+      description: Adds a new category inside the register configuration.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                category_name:
+                  type: string
+                  example: "new_category"
+                category_values:
+                  type: object
+                  example: {"config1": 1, "config2": "xxxx"}
+      responses:
+        "200":
+          description: Category added successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Category 'new_category' added successfully"
+        "400":
+          description: Invalid request body
+
+  /configuration/addNewParamConfigSetting:
+    patch:
+      summary: Add new configuration setting
+      description: Adds a new parameter inside a category in settings.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "certificates_expiry.new_config_ttl"
+                new_value:
+                  type: string
+                  example: "1000h"
+      responses:
+        "200":
+          description: Parameter added successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Parameter 'certificates_expiry.new_config_ttl' added successfully"
+        "400":
+          description: Invalid request body
+  
+  /configuration/removeConfigParam:
+    delete:
+      summary: Remove a configuration parameter
+      description: Deletes a specific parameter in the register configuration.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                param_path:
+                  type: string
+                  example: "settings.certificates_expiry.some_config"
+      responses:
+        "200":
+          description: Parameter removed successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Parameter 'settings.certificates_expiry.some_config' removed successfully"
+        "400":
+          description: Missing 'param_path' in request body
+        "404":
+          description: Parameter not found
+
+  /configuration/removeConfigCategory:
+    delete:
+      summary: Remove a configuration category
+      description: Deletes an entire category in the register configuration.
+      tags:
+        - Configuration
+      security:
+        - bearerAuth: []
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: object
+              properties:
+                category_name:
+                  type: string
+                  example: "deprecated_category"
+      responses:
+        "200":
+          description: Category removed successfully
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    example: "Category 'deprecated_category' removed successfully"
+        "400":
+          description: Missing 'category_name' in request body
+        "404":
+          description: Category not found
+
+components:
+  securitySchemes:
+    basicAuth:
+      type: http
+      scheme: basic
+    bearerAuth:
+      type: http
+      scheme: bearer
+      bearerFormat: JWT

doc/testing/testplan/README.md

@@ -15,3 +15,4 @@ List of Common API Services implemented:
 ## Features
 * [Vendor Extensibility](./vendor_extensibility/README.md)
 * [Api Status](./api_status/README.md)
+* [Event Filter](./event_filter/README.md)

doc/testing/testplan/api_events_service/README.md

@@ -353,7 +353,7 @@ At this documentation you will have all information and related files and exampl
   1. Register provider and publish one API at CCF
   2. Register Invoker and Onboard Invoker at CCF
   3. Discover published APIs and extract apiIds and apiNames
-  4. Subscribe to **SERVICE_API_AVAILABLE** and **SERVICE_API_UNAVAILABLE** event filtering by aefId. Enhanced_event_report active at supported features.
+  4. Subscribe to **SERVICE_API_AVAILABLE** and **SERVICE_API_UNAVAILABLE** event. Enhanced_event_report active at supported features.
   5. Retrieve {subscriberId} and {subscriptionId} from Location Header
   6. Provider publish new API.
   7. Provider remove published API.
@@ -373,12 +373,11 @@ At this documentation you will have all information and related files and exampl
 
      * Get **Api Ids** And **Api Names** from response.
 
-  5. Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE of provider previously registered:
+  5. Event Subscription to SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE:
      1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
      2. body [event subscription request body] with:
         1. events: **['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']**
-        2. eventFilter: only receive events from provider's aefId.
-        3. supportedFeatures: binary 0100 -> string **4**
+        2. supportedFeatures: binary 0100 -> string **4**
      3. Use **Invoker Certificate**
 
   6. Publish new Service API at CCF:
@@ -429,7 +428,7 @@ At this documentation you will have all information and related files and exampl
   1. Register Provider and publish one API at CCF
   2. Register Invoker and Onboard Invoker at CCF
   3. Discover published APIs and extract apiIds and apiNames
-  4. Subscribe to **SERVICE_API_UPDATE** event filtering by aefId. Enhanced_event_report active at supported features.
+  4. Subscribe to **SERVICE_API_UPDATE** event. Enhanced_event_report active at supported features.
   5. Retrieve {subscriberId} and {subscriptionId} from Location Header at event subscription
   6. Provider update information of Service API Published.
 
@@ -449,12 +448,12 @@ At this documentation you will have all information and related files and exampl
 
      * Get **Api Ids** And **Api Names** from response.
 
-  6. Event Subscription to SERVICE_API_UPDATE of provider previously registered:
+  6. Event Subscription to SERVICE_API_UPDATE:
      1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
      2. body [event subscription request body] with:
         1. events: **['SERVICE_API_UPDATE']**
-        2. eventFilter: only receive events from provider's aefId.
-        3. supportedFeatures: binary 0100 -> string **4**
+        2. supportedFeatures: binary 0100 -> string **4**
+        3. **eventFilter** set to apiId from published API.
      3. Use **Invoker Certificate**
 
   7. Update published API at CCF:
@@ -852,7 +851,7 @@ At this documentation you will have all information and related files and exampl
      1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
      2. body [event subscription request body] with:
         1. events: **['SERVICE_API_INVOCATION_SUCCESS','SERVICE_API_INVOCATION_FAILURE']**
-        2. eventFilter: only receive events from provider's aefId.
+        2. eventFilter: Not present.
         3. supportedFeatures: binary 0000 -> string **0**
      3. Use **Invoker Certificate**
 
@@ -927,7 +926,7 @@ At this documentation you will have all information and related files and exampl
      1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
      2. body [event subscription request body] with:
         1. events: **['SERVICE_API_AVAILABLE','SERVICE_API_UNAVAILABLE']**
-        2. eventFilter: only receive events from provider's aefId.
+        2. eventFilter: Not present.
         3. supportedFeatures: binary 0000 -> string **0**
      3. Use **Invoker Certificate**
 
@@ -1003,7 +1002,7 @@ At this documentation you will have all information and related files and exampl
      1. Send **POST** to **https://{CAPIF_HOSTNAME}/capif-events/v1/{subscriberId}/subscriptions**
      2. body [event subscription request body] with:
         1. events: **['SERVICE_API_UPDATE']**
-        2. eventFilter: only receive events from provider's aefId.
+        2. eventFilter: Not present.
         3. supportedFeatures: binary 0000 -> string **0**
      3. Use **Invoker Certificate**
 

doc/testing/testplan/api_security_service/README.md

@@ -16,15 +16,19 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Store signed Certificate
-  3. Create Security Context
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  4. Create Security Context
 
 **Information of Test**:
 
-  1. Perform [Invoker Onboarding]
-  2. Create Security Context for this Invoker
+  1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+  3. Create Security Context for this Invoker
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
-     * body [service security body]
+     * body [service security body] with aefId and apiId
      * Use **Invoker Certificate**
 
 **Expected Result**:
@@ -49,15 +53,18 @@ At this documentation you will have all information and related files and exampl
 
 **Execution Steps**:
 
-  1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  1. Register and onboard Invoker at CCF.
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context using Provider certificate
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
-
-  2. Create Security Context for this Invoker but using Provider certificate.
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+  3. Create Security Context for this Invoker but using Provider certificate.
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **AEF Certificate**
@@ -90,13 +97,17 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register Provider at CCF
-  2. Create Security Context using Provider certificate
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  3. Create Security Context using Provider certificate
 
 **Information of Test**:
 
-  1. Perform [Provider Registration]
-
-  2. Create Security Context for this not valid apiInvokerId and using Provider certificate.
+  1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+  3. Create Security Context for this not valid apiInvokerId and using Provider certificate.
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}**
      * body [service security body]
      * Using **AEF Certificate**
@@ -128,13 +139,17 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Create Security Context using Provider certificate
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  3. Create Security Context using Provider certificate
 
 **Information of Test**:
 
-  1. Perform [Invoker Onboarding]
-
-  2. Create Security Context for this Invoker:
+  1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+  3. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}**
      * body [service security body]
      * Use **Invoker Certificate**
@@ -154,7 +169,7 @@ At this documentation you will have all information and related files and exampl
 
 ## Test Case 5: Retrieve the Security Context of an API Invoker
 
-**Test ID**:: ***capif_security_api-5***
+**Test ID**:: ***capif_security_api-5***, ***smoke***
 
 **Description**:
 
@@ -167,13 +182,17 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context using Provider certificate
   4. Retrieve Security Context by Provider
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
   2. Create Security Context for this Invoker.
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
@@ -205,13 +224,18 @@ At this documentation you will have all information and related files and exampl
 
 **Execution Steps**:
 
-  2. Register Provider at CCF
+  1. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context using Provider certificate
   4. Retrieve Security Context by Provider of invalid invoker
 
 **Information of Test**:
 
-  1. Perform [Provider Registration]
+  1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
   2. Retrieve Security Context of invalid Invoker by Provider:
      * Send **GET** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}**
@@ -243,9 +267,10 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Store signed Certificate
-  3. Create Security Context
-  4. Retrieve Security Context as Provider.
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  3. Store signed Certificate
+  4. Create Security Context
+  5. Retrieve Security Context as Provider.
 
 **Information of Test**:
 
@@ -273,7 +298,7 @@ At this documentation you will have all information and related files and exampl
 
 ## Test Case 8: Delete the Security Context of an API Invoker
 
-**Test ID**:: ***capif_security_api-8***
+**Test ID**:: ***capif_security_api-8***, ***smoke***
 
 **Description**:
 
@@ -286,24 +311,28 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context using Provider certificate
   4. Delete Security Context by Provider
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Create Security Context for this Invoker but using Provider certificate.
+  3. Create Security Context for this Invoker but using Provider certificate.
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **AEF Certificate**
 
-  3. Delete Security Context of Invoker by Provider:
+  4. Delete Security Context of Invoker by Provider:
      * Send **DELETE** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * Use **AEF Certificate**
 
-  4. Retrieve Security Context of Invoker by Provider:
+  5. Retrieve Security Context of Invoker by Provider:
      * Send **GET** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * Using **AEF Certificate**
 
@@ -336,19 +365,24 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register Provider at CCF
-  2. Create Security Context using Provider certificate
-  3. Delete Security Context by Invoker
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  3. Create Security Context using Provider certificate
+  4. Delete Security Context by Invoker
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Create Security Context for this Invoker:
+  3. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **Invoker Certificate**
 
-  3. Delete Security Context of Invoker:
+  4. Delete Security Context of Invoker:
      * Send **DELETE** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * Use **Invoker Certificate**
 
@@ -437,7 +471,7 @@ At this documentation you will have all information and related files and exampl
 
 ## Test Case 12: Update the Security Context of an API Invoker 
 
-**Test ID**:: ***capif_security_api-12***
+**Test ID**:: ***capif_security_api-12***, ***smoke***
 
 **Description**:
 
@@ -450,7 +484,7 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context By Invoker
   4. Update Security Context By Invoker
   5. Retrieve Security Context By Provider
@@ -458,6 +492,10 @@ At this documentation you will have all information and related files and exampl
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
   2. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
@@ -501,20 +539,24 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context
   4. Update Security Context as Provider
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Create Security Context for this Invoker:
+  3. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **Invoker Certificate**.
 
-  3. Update Security Context of Invoker by Provider:
+  4. Update Security Context of Invoker by Provider:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/update**
      * body [service security body] but with notification destination modified to **http://robot.testing2**
      * Using **AEF Certificate**
@@ -545,14 +587,18 @@ At this documentation you will have all information and related files and exampl
 
 **Execution Steps**:
 
-  1. Register Provider at CCF
+  1. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   2. Update Security Context as Provider
 
 **Information of Test**:
 
   1. Perform [Provider Registration]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Update Security Context of Invoker by Provider:
+  3. Update Security Context of Invoker by Provider:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update**
      * body [service security body]
      * Using **AEF Certificate**
@@ -583,13 +629,18 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Update Security Context
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
+  3. Update Security Context
 
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Update Security Context of Invoker:
+  3. Update Security Context of Invoker:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/update**
      * body [service security body]
      * Using **Invoker Certificate**.
@@ -620,7 +671,7 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context by Invoker
   4. Revoke Security Context by Provider
   5. Retrieve Security Context by Provider
@@ -629,17 +680,22 @@ At this documentation you will have all information and related files and exampl
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
 
-  2. Create Security Context By Invoker:
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+
+  3. Create Security Context By Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **Invoker Certificate**
 
-  3. Revoke Authorization by Provider:
+  4. Revoke Authorization by Provider:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete**
      * body [security notification body]
      * Using **AEF Certificate**.
 
-  4. Retrieve Security Context by Provider:
+  5. Retrieve Security Context by Provider:
      * Send **GET** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * Using **AEF Certificate**.
 
@@ -672,7 +728,7 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context
   4. Revoke Security Context by invoker
   5. Retrieve Security Context
@@ -681,17 +737,22 @@ At this documentation you will have all information and related files and exampl
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
 
-  2. Create Security Context for this Invoker:
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
+
+  3. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **Invoker Certificate**.
 
-  3. Revoke Authorization by invoker:
+  4. Revoke Authorization by invoker:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}/delete**
      * body [security notification body]
      * Using **Invoker Certificate**
 
-  4. Retrieve Security Context of Invoker by Provider:
+  5. Retrieve Security Context of Invoker by Provider:
      * Send **GET** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * Using Provider Certificate
 
@@ -726,7 +787,7 @@ At this documentation you will have all information and related files and exampl
 **Execution Steps**:
 
   1. Register and onboard Invoker at CCF
-  2. Register Provider at CCF
+  2. Register Provider at CCF, store certificates and Publish Service API **service_1** at CCF.
   3. Create Security Context
   4. Revoke Security Context by Provider
   5. Retrieve Security Context
@@ -734,18 +795,22 @@ At this documentation you will have all information and related files and exampl
 **Information of Test**:
 
   1. Perform [Provider Registration] and [Invoker Onboarding]
+  2. Publish Service API at CCF:
+     * Send **POST** to ccf_publish_url **https://{CAPIF_HOSTNAME}/published-apis/v1/{apfId}/service-apis**
+     * body [service api description] with apiName **service_1**
+     * Use **APF Certificate**
 
-  2. Create Security Context for this Invoker:
+  3. Create Security Context for this Invoker:
      * Send **PUT** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}**
      * body [service security body]
      * Using **Invoker Certificate**.
 
-  3. Revoke Authorization by Provider:
+  4. Revoke Authorization by Provider:
      * Send **POST** **https://{CAPIF_HOSTNAME}/trustedInvokers/{API_INVOKER_NOT_VALID}/delete**
      * body [security notification body]
      * Using **AEF Certificate**.
 
-  4. Retrieve Security Context of Invoker by Provider:
+  5. Retrieve Security Context of Invoker by Provider:
      * Send **GET** **https://{CAPIF_HOSTNAME}/trustedInvokers/{apiInvokerId}?authenticationInfo=true&authorizationInfo=true**
      * This request will ask with parameter to retrieve authenticationInfo and authorizationInfo
      * Using **AEF Certificate**.
@@ -768,7 +833,7 @@ At this documentation you will have all information and related files and exampl
 
 ## Test Case 19: Retrieve access token
 
-**Test ID**:: ***capif_security_api-19***
+**Test ID**:: ***capif_security_api-19***, ***smoke***
 
 **Description**:
 
@@ -1285,5 +1350,6 @@ At this documentation you will have all information and related files and exampl
 
   [invoker onboarding]: ../common_operations/README.md#onboard-an-invoker "Invoker Onboarding"
   [provider registration]: ../common_operations/README.md#register-a-provider "Provider Registration"
+  [service api description]: ../api_publish_service/service_api_description_post_example.json  "Service API Description Request"