Consistent User Authentication and Consent Collection #229
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -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. | ||
|
There was a problem hiding this comment. In regard to business contracts, I believe this is a distinct issue that has not yet been addressed in CAMARA. In my view, this requirement falls outside the scope of the #215 discussion. Should it be deemed necessary, we could consider opening a separate issue to conduct a more thorough analysis, given that it would involve considerations that are unique to CAMARA and not yet defined. It has not been agreed that in these scenarios the Authorization Server must return an error. I would therefore not consider this topic in the PR on what refers to fix issue #215. There was a problem hiding this comment. I'll change that. The issue is not so much whether the contract is a business contract but rather whether the end-user equals the subscriber. This PR tries to capture the current understanding and replace assumptions by specifications what the defined behavior is. |
||
| * 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. | ||
|
There was a problem hiding this comment. If I have correctly understood the scenario you wish to raise, then existing flows such as the Auth code flow with network-based auth or CIBA with an IP/phone number as login hint always result in an access token being associated with a specific subscription identifier. Consequently, it is always possible to determine which identifier an API request refers to. This is why CAMARA defines it as possible to delegate in the access token when using 3-legged access tokens. It is not anticipated that this scenario will result in an error from the Authorization Server. If a user has, for example, five MSISDNs under their contract, the existing CAMARA authentication flows will enable the operator to issue an access token associated with one of them. This could be either the one linked to the device authenticated by the network in the authentication code flow or the one linked to the IP/phone number provided as the login hint in CIBA. There was a problem hiding this comment. I rephrased that part. I think if the authorization server cannot determine that the end-user reasonably equals the subscriber then the authorization server cannot check whether consent was given or revoked by the end-user. Example: A spouse has two contracts with the API provider. After receiving the authentication request the authorization server does network-based authentication and identifies the subscriber. The authentication server knows nothing whether the other spouse ,who is not the subscriber, consented to e.g. device location. Starting consent collection does not meaningfully work in this case because in general only the subscriber can be authenticated as the end-user the API provider usually created one account for the subscription but not two for each person. Assuming the API provider created two separate accounts, one for each person, then consent collection would work but in CAMARA we need consistent API provider behavior, so returning an error in this case is the (privacy-)safe option. |
||
| * If the subscription identifies one MSISDN but other subscriptions for the same MSISDN exist then the authoriztoin server MUST return an error. | ||
|
There was a problem hiding this comment. I understand this point relates to multi-SIM scenarios. With regard to Multi-SIM, CAMARA does not assume an error response from the Authorization Server in these cases. Indeed, the Commonalities (camaraproject/Commonalities#302) and API subprojects are working specifically on defining the expected behaviour when dealing with multi-SIM scenarios to ensure clarity and consistency. There was a problem hiding this comment. The last point is about Multi-SIM. This list tries to capture the current understanding. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment. I disagree, see my comment above. |
||
| 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). | ||
|
|
||
|
|
||
|
There was a problem hiding this comment. I believe #228 and #229 are adding a significant amount of supplementary information, which, as previously stated, may be appropriate for instances such as clarifying prompt parameter behavior. However, if we reach a specific conclusion in #215, wouldn't it be more efficient to address the issue by simply including that concise and straightforward conclusion in the profile document? There was a problem hiding this comment. I strongly suggest that PR content be kept as concise as possible, focusing on clarifying the conclusion proposed in #215 and using the same wording. This is in line with the intention to reach an agreement on the conclusion in #215 comments. The proposed PR content introduces additional topics that will require more detailed discussion in ICM. These topics could be initiated in parallel in new issues, although it would be necessary to ascertain whether they can be included in Spring25. Otherwise, it will be challenging to merge this PR. If the WG considers that we have not yet reached a final conclusion in #215, this should be addressed as a priority. There was a problem hiding this comment. This PR is an attempt to come to a conclusion in #215 by specifying behavior of the authorization server that is interoperable. OIDC provides everything we need.
|
||
| ### Cross-Site Request Forgery Protection | ||
|
|
||
| CAMARA REQUIRES cross-site request forgery (CSRF) protection. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of network-based authentication is not dependent on the prompt parameter. I would simply reiterate the conclusion proposed in #215:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There a some APIs that explicitly require the device to be identified like e.g. NumberVerification.
There a some APIs that do not restrict their use cases in this way e.g. KYC-fill-in
We want to make CAMARA APIs useful and attractive to API consumers. If we specify how authorization servers react to requests, then we get an interoperable solution that covers more use cases.