diff --git a/README.md b/README.md
index 14105da45a7318457e5e4275f715b900d283c784..a3cf02f946a64fc853a3153bd34124988e03ea6d 100644
--- a/README.md
+++ b/README.md
@@ -8,6 +8,7 @@ OpenCAPIF SDK provides a set of libraries to enable either CAPIF provider and in
 
 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.
 
@@ -17,15 +18,16 @@ This document serves as the [main bootstrap reference](#networkapp-developer-pat
  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
@@ -46,7 +48,7 @@ This document serves as the [main bootstrap reference](#networkapp-developer-pat
 
 - [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),
@@ -66,13 +68,13 @@ Next image illustrates how CAPIF works and where the SDK provides means to integ
 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:
 
@@ -100,7 +102,6 @@ NOTE: Above mentioned CAPIF APIs are defined in these 3GPP references:
 - [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.
@@ -108,7 +109,7 @@ NOTE: In the [3GPP Technical Specification (TS) 29.222 V18.5.0 Common API Framew
 
 ## 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).**
 
@@ -163,20 +164,18 @@ Code is next explained step by step:
     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`.
 
-    The provider_capif_ids variable is a dictionary which contains key-values of all the APFs and AEFs stored as name: ID.
+    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.**
+   
+    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.**
 
@@ -197,11 +196,11 @@ Within the `provider_folder`, the SDK stores the created folders named with pref
 - `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
@@ -249,7 +248,7 @@ Code is next explained step by step:
   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.
 
@@ -263,7 +262,7 @@ Make sure that the [Provider-Network App](./network_app_samples/network_app_prov
 
 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. 
 
@@ -285,9 +284,9 @@ In the `invoker_folder`, it will be located several folders with each `capif_use
     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
 
@@ -302,4 +301,3 @@ There are some features which **are not currently available at latest OpenCAPIF
     - /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)
diff --git a/config/capif_sdk_config.json b/config/capif_sdk_config.json
index db4f074c1776ed2d6fb0023aa2f48f59714dbeea..34844f5a344cae2d12a0110e4ccfc61b4de0ce5f 100644
--- a/config/capif_sdk_config.json
+++ b/config/capif_sdk_config.json
@@ -10,9 +10,10 @@
     "invoker_folder": "",
     "capif_callback_url": "",
     "supported_features":"",
-    "check_authorization":{
+    "check_authentication":{
       "ip":"",
       "port":""
+    },
     "cert_generation": {
       "csr_common_name": "",
       "csr_organizational_unit": "",
diff --git a/doc/sdk_configuration.md b/doc/sdk_configuration.md
index e172f6f20fd13b16c59c109b34968e20e97492ec..a9a0b21e602537f1dfb6332466a413f56023e53e 100644
--- a/doc/sdk_configuration.md
+++ b/doc/sdk_configuration.md
@@ -7,7 +7,7 @@ Before starting the configuration process, it is required that both the [require
   - [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`
 
@@ -35,9 +35,8 @@ When configuring the SDK as a **Network App Invoker**, the following fields must
 - `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
 
@@ -54,7 +53,9 @@ For SDK configuration as a **Network App Provider**, the following fields are re
 
 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.
 
diff --git a/doc/sdk_full_documentation.md b/doc/sdk_full_documentation.md
index 2ecdba56dc219149e0c0d0d11ad7655985afa9ff..6dc3c6d40be3e0dcb00c03574242bd6a0c0d8a89 100644
--- a/doc/sdk_full_documentation.md
+++ b/doc/sdk_full_documentation.md
@@ -25,7 +25,7 @@ The repository provides two modes for utilizing the OpenCAPIF SDK:
 
 **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
 
@@ -86,28 +86,31 @@ OpenCAPIF SDK references:
 
 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
@@ -120,13 +123,18 @@ OpenCAPIF SDK references:
 - **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**:
@@ -140,6 +148,9 @@ OpenCAPIF SDK references:
 - **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)
@@ -198,12 +209,11 @@ The SDK facilitates JWT token creation for secure access to target APIs. This pr
 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)
@@ -211,7 +221,6 @@ It is important to have obtained the [JWT token](#obtain-jwt-tokens) previously.
 ### 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`
 
@@ -221,7 +230,6 @@ Onboarding is required before utilizing these functions.
 
 ## Other Features
 
-
 ### CAPIF Registration and Login
 
 OpenCAPIF SDK reference:
@@ -236,5 +244,4 @@ OpenCAPIF SDK reference:
 
 Simplifies the logout process for admin users and removes a CAPIF user.
 
-
 ![Register picture](./images/flows_sdk_with_register.jpg)
diff --git a/network_app_samples/network_app_invoker_sample/network_app_invoker.py b/network_app_samples/network_app_invoker_sample/network_app_invoker.py
index fb282bf57cef99b88dee83420180a3bdcaaa8fff..e3c1e6238ceb05306e16896cd6c4cf2df0bbf908 100644
--- a/network_app_samples/network_app_invoker_sample/network_app_invoker.py
+++ b/network_app_samples/network_app_invoker_sample/network_app_invoker.py
@@ -96,9 +96,9 @@ if __name__ == "__main__":
         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()
diff --git a/samples/enviroment_variables_sample.txt b/samples/enviroment_variables_sample.txt
index 79d2ee03ffdbd596f383a75def3e6d48a7f79577..8e76ace94adc95c8c0e088d2fe55ce7eca22fdc1 100644
--- a/samples/enviroment_variables_sample.txt
+++ b/samples/enviroment_variables_sample.txt
@@ -9,7 +9,7 @@ export CAPIF_PASSWORD=your_capif_password
 export DEBUG_MODE=False
 
 # INVOKER
-export CAPIF_CALLBACK_URL=https://your_callback_url
+export INVOKER_CAPIF_CALLBACK_URL=https://your_callback_url
 
 # CSR (Certificate Signing Request) Configuration INVOKER
 export INVOKER_CSR_COMMON_NAME=your_csr_common_name
@@ -20,6 +20,8 @@ export INVOKER_CSR_STATE_OR_PROVINCE_NAME=your_state_or_province
 export INVOKER_CSR_COUNTRY_NAME=your_country_name
 export INVOKER_CSR_EMAIL_ADDRESS=your_email_address
 
+export INVOKER_CHECK_AUTHENTICATION_IP =
+export INVOKER_CHECK_AUTHENTICATION_PORT = 
 #DISCOVER FILTER
 export DISCOVER_FILTER_API_NAME=""
 export DISCOVER_FILTER_API_VERSION=""
@@ -49,9 +51,9 @@ export PROVIDER_CSR_COUNTRY_NAME=your_country_name
 export PROVIDER_CSR_EMAIL_ADDRESS=your_email_address
 
 # Provider Specific Values
-export APFS=your_apfs_value
-export AEFS=your_aefs_value
-export API_DESCRIPTION_PATH=/path/to/api_description
+export PROVIDER_APFS=your_apfs_value
+export PROVIDER_AEFS=your_aefs_value
+export PROVIDER_API_DESCRIPTION_PATH=/path/to/api_description
 
 # Publish Request Configuration
 export PUBLISH_REQ_SERVICE_API_ID=your_service_api_id
diff --git a/sdk/capif_invoker_connector.py b/sdk/capif_invoker_connector.py
index 1835908309857238407aeea95ac762215baef541..e43a94784dbc028712ff49f047e0e5a0085b2071 100644
--- a/sdk/capif_invoker_connector.py
+++ b/sdk/capif_invoker_connector.py
@@ -81,7 +81,7 @@ class capif_invoker_connector:
         capif_username = os.getenv('CAPIF_USERNAME', config.get('capif_username', '')).strip()
         capif_invoker_password = os.getenv('CAPIF_PASSWORD', config.get('capif_password', '')).strip()
         
-        capif_callback_url = os.getenv('CAPIF_CALLBACK_URL', invoker_config.get('capif_callback_url', '')).strip()
+        capif_callback_url = os.getenv('INVOKER_CAPIF_CALLBACK_URL', invoker_config.get('capif_callback_url', '')).strip()
         supported_features = os.getenv('INVOKER_FOLDER', invoker_config.get('supported_features', '')).strip()
         check_authentication = invoker_config.get('check_authentication', {})
         self.check_authentication = {
diff --git a/sdk/capif_provider_connector.py b/sdk/capif_provider_connector.py
index dd278aa8a174c36bca9e24e678e3f658060e4594..a1ae41856b2ea44edfdb5be3a5dc97ac03f1462e 100644
--- a/sdk/capif_provider_connector.py
+++ b/sdk/capif_provider_connector.py
@@ -99,9 +99,9 @@ class capif_provider_connector:
             csr_email_address = os.getenv('PROVIDER_CSR_EMAIL_ADDRESS', cert_generation.get('csr_email_address', '')).strip()
 
             # Retrieve provider specific values (APFs, AEFs)
-            apfs = os.getenv('APFS', provider_config.get('apfs', '')).strip()
-            aefs = os.getenv('AEFS', provider_config.get('aefs', '')).strip()
-            api_description_path = os.path.abspath(os.getenv('API_DESCRIPTION_PATH', provider_config.get('api_description_path', '')).strip())
+            apfs = os.getenv('PROVIDER_APFS', provider_config.get('apfs', '')).strip()
+            aefs = os.getenv('PROVIDER_AEFS', provider_config.get('aefs', '')).strip()
+            api_description_path = os.path.abspath(os.getenv('PROVIDER_API_DESCRIPTION_PATH', provider_config.get('api_description_path', '')).strip())
 
             # Check required fields and log warnings/errors
             if not capif_host:
@@ -468,7 +468,7 @@ class capif_provider_connector:
                             revoke = True
                             if custom["custOpName"] == "check-authentication":
                                 check = False
-                            if custom["custOpName"] == "revoke-authentication ":
+                            if custom["custOpName"] == "revoke-authentication":
                                 revoke = False
                         # If 'check-authentication' custom operation doesn't exist, add it
                         if check: