From a81a909fa22dd06131d1156113105b42e116c110 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Thu, 14 Nov 2024 16:58:47 +0100 Subject: [PATCH 1/3] Consistent User Authentication and Consent collection --- .../CAMARA-Security-Interoperability.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index 0a55da5..40c07cb 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -66,6 +66,26 @@ All network connections MUST use TLS 1.2 or better. The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) +### Consistent User Authentication and Consent collection + +It is up to the operator to make a decision when consent collection is needed or not, based on the scope(s)/purpose declared by the API client and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a *consistent* approach. + +This document defines that if the optional prompt parameter is absent from the OIDC authentication request then the API consumer uses network-based authentication to identify the subscription. +* If the subscription belongs to a business contract then the authorization server MUST return an error. +* If the subscription belongs to a private contract but there are several contracts to the contract holder then the authorization server MUST return an error. +* If the subscription identifies one MSISDN but other subscriptions for the same MSISDN exist then the authoriztoin server MUST return an error. + +The API provider could start User-Interaction to resolve the above cases, but that likely leads to different behaviour by different API producers. + +The document defines that if the optional prompt parameter is absent from the OIDC authentication request and network-based authentication identifies one subscription that belongs to one person and that person does not own other subscriptions with that API provider, then the API provider can assume that the subscriber equals the end-user. +The decicion whether consent needs to be collected or not is then determined by the API provider +* by determining the legal basis of the purpose e.g.: contract, legitimate_interest, consent, etc, +* and then checking if consent is required for the legal basis of the purpose +* and then checking whether consent was already granted or revoked out-of-band. + +If consent needs to be optained then the API provider optains it according to [OIDC section 3.1.2.4](https://openid.net/specs/openid-connect-core-1_0.html#Consent). + + ### Cross-Site Request Forgery Protection CAMARA REQUIRES cross-site request forgery (CSRF) protection. From d0e8088c3548aa64ea0d8f3ecb3e34266ee0e5e0 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Fri, 15 Nov 2024 17:31:03 +0100 Subject: [PATCH 2/3] Multi-SIM error only if CIBA --- documentation/CAMARA-Security-Interoperability.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index 40c07cb..817d6ac 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -73,7 +73,6 @@ It is up to the operator to make a decision when consent collection is needed or This document defines that if the optional prompt parameter is absent from the OIDC authentication request then the API consumer uses network-based authentication to identify the subscription. * If the subscription belongs to a business contract then the authorization server MUST return an error. * If the subscription belongs to a private contract but there are several contracts to the contract holder then the authorization server MUST return an error. -* If the subscription identifies one MSISDN but other subscriptions for the same MSISDN exist then the authoriztoin server MUST return an error. The API provider could start User-Interaction to resolve the above cases, but that likely leads to different behaviour by different API producers. @@ -106,6 +105,8 @@ Communication with the Backchannel Authentication Endpoint MUST utilize TLS. CIBA allows the Client to get the authentication result in three ways: poll, ping, or push. This profile allows clients to use the *poll* mode. In the Poll mode, the authentication result is retrieved by the Client by polling the token endpoint using the new grant type. +If the the login_hint is not sufficient to identify one device, e.g. a phone number is specified but several subscriptions for the same phone number exist, then the authoriztion server MUST return an error code `DEVICE_NOT_FOUND` (???). + ### Optional Parameters The parameters `binding_message`, `user_code`, and `requested_expiry` are currently not implemented in CAMARA and for interoperability this document defines that the authorization server SHOULD ignore them. From e2583350d97ec18b7d30125823bfbe499065c024 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Fri, 15 Nov 2024 17:58:49 +0100 Subject: [PATCH 3/3] unify business and private case to end-user != subscriber case --- documentation/CAMARA-Security-Interoperability.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index 817d6ac..e1b554f 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -70,9 +70,14 @@ The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.n It is up to the operator to make a decision when consent collection is needed or not, based on the scope(s)/purpose declared by the API client and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a *consistent* approach. -This document defines that if the optional prompt parameter is absent from the OIDC authentication request then the API consumer uses network-based authentication to identify the subscription. -* If the subscription belongs to a business contract then the authorization server MUST return an error. -* If the subscription belongs to a private contract but there are several contracts to the contract holder then the authorization server MUST return an error. +This document defines that if the optional prompt parameter is absent from the OIDC authentication request then the API consumer uses network-based authentication to identify the subscription. If the subscription identified by network-based authentication cannot assure that the end-user equals the subscriber then an error MUST be returned. + +Examples for cases where the authorization server cannot assue that the end-user equals the subscriber: +``` +* A business owner has one contract that is associated with multiple MSISDNs + then the authorization server cannot assume that the end-user is the subscriber. +* A family has several contracts which all have the same subscriber then the authorization server cannot assume that the end-user is the subscriber. +``` The API provider could start User-Interaction to resolve the above cases, but that likely leads to different behaviour by different API producers.