Consistent User Authentication and Consent Collection

[AxelNennker]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

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 PR (hopefully) defines that consistent approach.

Which issue(s) this PR fixes:

Update removed #215

Update: Please see #228

[jpengar]

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.

[AxelNennker]

The last point is about Multi-SIM. This list tries to capture the current understanding.
I moved that point/sentence to the CIBA section because the consistent API Provider behavior is to return an error if the device can't be determined by login_hint=tel: in the CIBA case.

[jpengar]

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.

[AxelNennker]

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.
I asked TDG what they implemented and they said "business contract -> no access token" because usually the business contract has multiple MSISDNs and we do not want the employee with one of the MSISDN to act on behalf of the subscriber.

[jpengar]

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.

[AxelNennker]

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.
Consent can only be granted by a data-subject (end-user), and if we can't identify the data-subject, then we do not know anything about their consent.

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.

[jpengar]

I disagree, see my comment above.

[jpengar]

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?

[jpengar]

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.

[AxelNennker]

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.

• the API consumer can test the water with prompt=none and if the response is "consent_needed" the API consumer can start OIDC consent collection with prompt=consent.

[jpengar]

The use of network-based authentication is not dependent on the prompt parameter. I would simply reiterate the conclusion proposed in #215:

• Currently, CAMARA only considers network-based authentication in the Authorization Code Flow. Therefore, access tokens are issued for the network authenticated identifier.

[AxelNennker]

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.

[AxelNennker]

I removed Fixes #215 and rephrased. The PRs #228 and #229 were started be cause of #215. I wanted to write the consensus down while not excluding operator token and clarify prompt behavior.

I want to achieve that we have a consistent behavior by all API producers.
I think that end-user not-equal subscriber leads to GDPR problems, and therefore wrote that we should fail in the privacy-safe side.