From b15d8c8e9282fa7fae224275b8f9d236009197b2 Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Fri, 2 Feb 2024 09:29:05 +0100 Subject: [PATCH 01/11] Update CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 50d0517a..9681fd8f 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -379,6 +379,11 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. +CAMARA guidelines defines a set of authorization flows which can grant API clients access to the API functionality. +Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client (the direct API invoker) and the Telco Operator exposing the API.T he negotiated flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +The possible authorization flows must be configured on the API product offering. Note that as of now, there is a 1:1 relationship between API product offering and exposed Service API envisioned. +The authorization flow to be used will be settled when the API product is ordered. The API invoker is supposed to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is reponsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. + ### Use of openIdConnect for `securitySchemes` In general, OpenID Connect is the protocol to be used for securitization. Each API specification must ONLY define the following openIdConnect entry in `securitySchemes`, as shown in document [CAMARA-AuthN-AuthZ-Concept.md](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md#documentation-and-specs-): From c9df3feabd972d3988ed55075d6cea4417e61f02 Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Fri, 2 Feb 2024 09:30:10 +0100 Subject: [PATCH 02/11] Update CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 9681fd8f..a2c478ce 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -379,7 +379,7 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. -CAMARA guidelines defines a set of authorization flows which can grant API clients access to the API functionality. +CAMARA guidelines define a set of authorization flows which can grant API clients access to the API functionality. Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client (the direct API invoker) and the Telco Operator exposing the API.T he negotiated flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. The possible authorization flows must be configured on the API product offering. Note that as of now, there is a 1:1 relationship between API product offering and exposed Service API envisioned. The authorization flow to be used will be settled when the API product is ordered. The API invoker is supposed to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is reponsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. From b9d93193e5f5e3b660c571f34384bb7c23242fe4 Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Fri, 2 Feb 2024 10:50:03 +0100 Subject: [PATCH 03/11] Update CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index a2c478ce..822cfe15 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -379,10 +379,11 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. -CAMARA guidelines define a set of authorization flows which can grant API clients access to the API functionality. -Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client (the direct API invoker) and the Telco Operator exposing the API.T he negotiated flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. -The possible authorization flows must be configured on the API product offering. Note that as of now, there is a 1:1 relationship between API product offering and exposed Service API envisioned. -The authorization flow to be used will be settled when the API product is ordered. The API invoker is supposed to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is reponsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. +CAMARA guidelines define a set of authorization flows which can grant API clients access to the API. +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the Telco Operator exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +The possible authorization flows must be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. Note that as of now, there is a 1:1 relationship between a single API product offering and exposed Service API envisioned. +The authorization flow to be used will be settled when the API product is ordered. +The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is reponsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From 3579061fc1b88759b76ec40f0f0d3794fec8c89c Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Mon, 5 Feb 2024 11:38:59 +0100 Subject: [PATCH 04/11] API provider, typo Signed-off-by: Axel Nennker --- documentation/CAMARA-API-access-and-user-consent.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 822cfe15..c03ebf30 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -380,10 +380,10 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. CAMARA guidelines define a set of authorization flows which can grant API clients access to the API. -Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the Telco Operator exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API provider exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. The possible authorization flows must be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. Note that as of now, there is a 1:1 relationship between a single API product offering and exposed Service API envisioned. The authorization flow to be used will be settled when the API product is ordered. -The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is reponsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. +The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From b2b37f452a7f2b250cd9486e2447ae1c78c3b6a9 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Mon, 5 Feb 2024 11:40:05 +0100 Subject: [PATCH 05/11] API provider Signed-off-by: Axel Nennker --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index c03ebf30..80decc3b 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -383,7 +383,7 @@ CAMARA guidelines define a set of authorization flows which can grant API client Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API provider exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. The possible authorization flows must be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. Note that as of now, there is a 1:1 relationship between a single API product offering and exposed Service API envisioned. The authorization flow to be used will be settled when the API product is ordered. -The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and Telco operator for this application, purpose, API/data scopes is applied. +The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API provider for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From aea5708f79bd16fe691ba4abb295f68972c1e56d Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Mon, 5 Feb 2024 11:51:44 +0100 Subject: [PATCH 06/11] API producer Signed-off-by: Axel Nennker --- documentation/CAMARA-API-access-and-user-consent.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 80decc3b..28ecac08 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -380,10 +380,10 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. CAMARA guidelines define a set of authorization flows which can grant API clients access to the API. -Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API provider exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API producer exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. The possible authorization flows must be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. Note that as of now, there is a 1:1 relationship between a single API product offering and exposed Service API envisioned. The authorization flow to be used will be settled when the API product is ordered. -The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API provider for this application, purpose, API/data scopes is applied. +The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From d3a186e96c032a3aae46a3f926f6a17aac1730f3 Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Mon, 5 Feb 2024 11:55:28 +0100 Subject: [PATCH 07/11] Update CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 28ecac08..fa0e4e2d 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -380,9 +380,9 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. CAMARA guidelines define a set of authorization flows which can grant API clients access to the API. -Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API producer exposing the API. The API product order flow can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. -The possible authorization flows must be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. Note that as of now, there is a 1:1 relationship between a single API product offering and exposed Service API envisioned. -The authorization flow to be used will be settled when the API product is ordered. +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API producer exposing the API. The API product order flow (preferably implemented with help of TMF 931) can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +When leveraging on TMF 931 for API product ordering, the possible authorization flows should be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. +The authorization flow to be used will therefore be settled when the API product is ordered The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From addbb47062637e79fe6e655c2cb463f9cbe708fd Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Mon, 5 Feb 2024 12:06:05 +0100 Subject: [PATCH 08/11] Update documentation/CAMARA-API-access-and-user-consent.md Co-authored-by: Shilpa Padgaonkar <77152136+shilpa-padgaonkar@users.noreply.github.com> --- documentation/CAMARA-API-access-and-user-consent.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index fa0e4e2d..d9c07892 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -379,7 +379,7 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. -CAMARA guidelines define a set of authorization flows which can grant API clients access to the API. +CAMARA guidelines define a set of authorization flows which can grant API Consumers access to the API. Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API producer exposing the API. The API product order flow (preferably implemented with help of TMF 931) can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. When leveraging on TMF 931 for API product ordering, the possible authorization flows should be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. The authorization flow to be used will therefore be settled when the API product is ordered From a0f6a6a25b5e5d49adf85c4fc3b34fa1715f5d73 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Mon, 5 Feb 2024 12:51:06 +0100 Subject: [PATCH 09/11] API consumer as per communalities, do not mention TMForum Signed-off-by: Axel Nennker --- documentation/CAMARA-API-access-and-user-consent.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index d9c07892..4ae8be3f 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -380,10 +380,10 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. CAMARA guidelines define a set of authorization flows which can grant API Consumers access to the API. -Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Client (the direct API invoker) and the API producer exposing the API. The API product order flow (preferably implemented with help of TMF 931) can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. -When leveraging on TMF 931 for API product ordering, the possible authorization flows should be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Consumer (the direct API invoker) and the API producer exposing the API. The API product order flow (preferably implemented with help of TMF 931) can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +The possible authorization flows should be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. The authorization flow to be used will therefore be settled when the API product is ordered -The API invoker is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied. +The API Consumer is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied. ### Use of openIdConnect for `securitySchemes` From cd5c9d0d7bd015efb8410095e6095d339ea85e86 Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Mon, 5 Feb 2024 16:42:05 +0100 Subject: [PATCH 10/11] Update CAMARA-API-access-and-user-consent.md --- documentation/CAMARA-API-access-and-user-consent.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 4ae8be3f..99b8f34c 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -380,11 +380,13 @@ More details about the standard flow can be found in the official IETF specifica The purpose of this document section is to standardise the specification of `securitySchemes` and `security` across all CAMARA API subprojects with common mandatory guidelines as agreed by the Technical Steering Committee (TSC) and the participants of this Working Group. CAMARA guidelines define a set of authorization flows which can grant API Consumers access to the API. -Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Consumer (the direct API invoker) and the API producer exposing the API. The API product order flow (preferably implemented with help of TMF 931) can consider the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation and eventually also consider the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. -The possible authorization flows should be configured on the API product specification used to build the API product offering. This configuration could be purpose dependent. -The authorization flow to be used will therefore be settled when the API product is ordered +Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Consumer (the direct API invoker) and the API producer exposing the API. When API access for an API consumer is ordered, the declared purpose for accessing the API can be taken into account. This is also being subject to the prevailing legal framework dictated by local legislation and eventually also considers the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. +The possible authorization flows should be configured on the API specification, eventually being purpose dependent. +The authorization flow to be used will therefore be settled when the API access is ordered. The API Consumer is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied. + + ### Use of openIdConnect for `securitySchemes` In general, OpenID Connect is the protocol to be used for securitization. Each API specification must ONLY define the following openIdConnect entry in `securitySchemes`, as shown in document [CAMARA-AuthN-AuthZ-Concept.md](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-AuthN-AuthZ-Concept.md#documentation-and-specs-): From 2ded25a5557c5e8e814a692622fd268897c28f3b Mon Sep 17 00:00:00 2001 From: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com> Date: Tue, 6 Feb 2024 18:38:34 +0100 Subject: [PATCH 11/11] Update documentation/CAMARA-API-access-and-user-consent.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jesús Peña García-Oliva --- documentation/CAMARA-API-access-and-user-consent.md | 1 - 1 file changed, 1 deletion(-) diff --git a/documentation/CAMARA-API-access-and-user-consent.md b/documentation/CAMARA-API-access-and-user-consent.md index 99b8f34c..cc120d97 100644 --- a/documentation/CAMARA-API-access-and-user-consent.md +++ b/documentation/CAMARA-API-access-and-user-consent.md @@ -381,7 +381,6 @@ The purpose of this document section is to standardise the specification of `sec CAMARA guidelines define a set of authorization flows which can grant API Consumers access to the API. Which specific authorization flows are to be used will be determined during the onboarding process, happening between the API Consumer (the direct API invoker) and the API producer exposing the API. When API access for an API consumer is ordered, the declared purpose for accessing the API can be taken into account. This is also being subject to the prevailing legal framework dictated by local legislation and eventually also considers the capabilities of the application (frontend and backend) ultimately involved in the API invocation flow. -The possible authorization flows should be configured on the API specification, eventually being purpose dependent. The authorization flow to be used will therefore be settled when the API access is ordered. The API Consumer is expected to initiate the negotiated authorization flow when requesting ID & access tokens. The AuthZ server is responsible to validate that the authorization flow negotiated between API Invoker and API producer for this application, purpose, API/data scopes is applied.