Inconsistent statements about applicable authorization flows

[hdamker]

Problem description

Commit 7675e3e in PR #92 introduced a restriction for the use of Client Credentials into the CAMARA-API-access-and-user-consent.md document which goes beyond the clear documented guideline. It states that "client_credentials grant type ... can only be used when no personal user data is processed". This is not in line with the agreed guideline.

The agreed guideline was discussed several weeks, even in the TSC, and was reviewed by many people:

Authorization and authentication

CAMARA guidelines defines a set of authorization flows which can grant API clients access to the API functionality, as outlined in the document CAMARA-API-access-and-user-consent.md. Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.

It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

It is mandatory for all CAMARA API subprojects to adopt and to include in info.description property in the CAMARA API specs. Therefore it should be expected that also the I&CM working group is adhering to it in all statements.

The essence of the text is that CAMARA does not take legal decision about the specific authorization flows, but leaves that to "API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation". Beyond that it is making clear that "in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory". But CAMARA as technical project can't decide across all local legislation in which cases the users can exercise such rights and in which cases this isn't the case.

Expected behavior

commit 7675e3e, merged together with PR #92 should be reverted. If necessary a reference to the above guideline can be added.

The original PR text is still valid IMHO: if the client_credentials grant type will be used in cases where personal user information is processed (e.g. if the legal base is a law), than this has to been agreed already during the onboarding process, and both API Client and the Telco Operator exposing the API has taken into account the declared purpose for accessing the API.

Alternative solution

None, at least not without reverting the consensus about the above agreed guideline.
Create a PR which will update the text to be in line with the agreed guideline.

Additional context

The issue was triggered by this discussion in PR #121, about a similar statement: #121 (comment)

Personal note: I agree that for most cases where a personal user resource is involved, 3-legged access tokens should be agreed. But we shouldn't make it mandatory if this would hinder certain use cases.

[jpengar]

I will just refer to Telefonica's position when issue #92 was originally discussed. #92 (comment)

The CAMARA community agreement on 2-legged vs. 3-legged access can be summarised (as documented) as "Every time personal user data is processed by an API and the user can exercise his rights either via opt-in and/or opt-out, 3-legged access tokens must be used."

However, this is an independent debate on whether the purpose for which personal data is consumed should be declared when using client credentials (2-legged access).

From Telefónica's point of view, when personal data is processed, the purpose must always be declared
(this is what the GDPR requires), regardless of the legal basis and whether it requires opt-in or the user can opt-out according to the local regulation that applies. And consequently, regardless of whether the use of "client credentials" is allowed.

Thank you @hdamker for bringing this up. I also added a v0.2.0 label.

[diegogonmar]

Hi,
We're fine with existing agreement about mandating 3-legged whenever opt-in or opt-out is required.
As stated by @jpengar, independently (or in addition) of this agreement, whenever personal data is processed, purpose has to be declared. This is what laws state.
Also, when no personal data is used in an API (e.g.: QoS Profiles) then Client Credentials is valid option and additionally the purpose concept discussions and conclusions do not apply.

Regarding the case of Personal Information but no opt-in nor opt-out required. We have some doubts about how interoperability can be solved in cases like: e.g.: Operator1 says dpv:FraudPrevention do not require opt-in nor opt-out; Operator2 says that opt-out is required. So 3-legged vs 2-legged being offered depending on the Operator?. This is why we did not oppose to less interpretative approach of "personal data processed or not".
Note: It is important that in the mid-term solution that we have to work on regarding purposes, we clarify these things also.

[hdamker]

Regarding the case of Personal Information but no opt-in nor opt-out required. We have some doubts about how interoperability can be solved in cases like: e.g.: Operator1 says dpv:FraudPrevention do not require opt-in nor opt-out; Operator2 says that opt-out is required. So 3-legged vs 2-legged being offered depending on the Operator?. This is why we did not oppose to less interpretative approach of "personal data processed or not".

Interoperability and how to achieve it, isn't the subject of this issue. The default might be 3-legged, and 2-legged only used if agreed between "API Client and the Telco Operator exposing the API". If there is such an agreement then there is also not an interoperability issue (might be that the Telco has to offer both ways then, as other API Clients need 3-legged for interoperability.

[hdamker]

As stated by @jpengar, independently (or in addition) of this agreement, whenever personal data is processed, purpose has to be declared. This is what laws state.

Two comments here:

• "This is what laws state" ... there is no such thing like universal law for privacy, I suppose you are referring to specific legislation here (GDPR). My understanding is that the guideline is formulated like it is to fit also for different legislations.
• But more important: If the onboarding has "taken into account the declared purpose for accessing the API" and it has been agreed that the legal base is e.g. a law or contract (e.g. the API Client only accessing own IoT devices), is there a legal obligation to send the "purpose" in every client_credential authorisation request again? This has already taken into account during the onboarding (and ordering of the API) and could have been documented there (btw also the legal base for the processing might need to be documented, not only the purpose).

[diegogonmar]

Regarding the case of Personal Information but no opt-in nor opt-out required. We have some doubts about how interoperability can be solved in cases like: e.g.: Operator1 says dpv:FraudPrevention do not require opt-in nor opt-out; Operator2 says that opt-out is required. So 3-legged vs 2-legged being offered depending on the Operator?. This is why we did not oppose to less interpretative approach of "personal data processed or not".

Interoperability and how to achieve it, isn't the subject of this issue. The default might be 3-legged, and 2-legged only used if agreed between "API Client and the Telco Operator exposing the API". If there is such an agreement then there is also not an interoperability issue (might be that the Telco has to offer both ways then, as other API Clients need 3-legged for interoperability.

Yes and no, if we define something that makes interoperability difficult or does not make clear how to be achieved, we would not be doing the best. You're right about the agreement, but in OpenGateway scenario we should not tell Channel Partners / developers that each operator offer different option and Channel Partner /developers behaves different. Anyway please notice I was just reflecting why we didn't oppose to more restrictive approach.

[diegogonmar]

As stated by @jpengar, independently (or in addition) of this agreement, whenever personal data is processed, purpose has to be declared. This is what laws state.

Two comments here:

• "This is what laws state" ... there is no such thing like universal law for privacy, I suppose you are referring to specific legislation here (GDPR). My understanding is that the guideline is formulated like it is to fit also for different legislations.
• But more important: If the onboarding has "taken into account the declared purpose for accessing the API" and it has been agreed that the legal base is e.g. a law or contract (e.g. the API Client only accessing own IoT devices), is there a legal obligation to send the "purpose" in every client_credential authorisation request again? This has already taken into account during the onboarding (and ordering of the API) and could have been documented there (btw also the legal base for the processing might need to be documented, not only the purpose).

I'm not an expert in laws, so I better clarify myself. Purpose has to be reflected and audited when personal info is accessed or managed. How to achieve it is not said in the law as law is not technical, different options may exist. GDPR or other laws does not say as far as I know that purpose has to be sent in each authorization request.
Yes I was referring to GDPR and similar laws.

[hdamker]

You're right about the agreement, but in OpenGateway scenario we should not tell Channel Partners / developers that each operator offer different option and Channel Partner /developers behaves different. Anyway please notice I was just reflecting why we didn't oppose to more restrictive approach.

@diegogonmar It's known that you / Telefonica are about following a more restrictive approach. But it was also you who insisted to stop questioning the agreement. Therefore I would really appreciate that you are also following this line and support that the document is consistent with the agreement.

BTW: I tend to agree with you in Open Gateway scenarios as I wrote already above, but the guidelines shouldn't hinder any operator or other network provider to use the API also outside of Open Gateway with 2-legged authentication if this is legally possible in a scenario (e.g. within non-public networks). Or in other words: OGW can be more restrictive but CAMARA shouldn't.

[diegogonmar]

Hi @hdamker. I have two suggestions for way forward.

1. We'd be fine with a PR reverting the one that included this extra restriction. This one: Add rule for requesting scopes for client credentials #109.
   Reverting only text of a commit will not be fine for us because, as explained, not using purpose is only valid for us if no personal information is involved.

Then reopen issue to discuss about client credentials and usage of purposes.

2. Change text to (bold used to reflect what would be changed)
   No purpose is required for the client_credentials grant type in scenarios when no personal user data is processed. The requested scope must be set directly to the value defined for the relevant endpoint within the OAS ("YAML") specification. "Wild card" scopes (i.e. specifying only the API name) are not valid for this grant type when no personal user data is processed

Then reopen issue to discuss about client credentials and usage of purposes in scenarios where personal user data is processed. Or have this discussion as a part of general purposes discussion.

Would it work for you to do either 1) or 2)? The PR needed in any of the options would need to also update other places already indicating same restriction.
https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#client-credentials
And in ongoing PR for OIDC profile --> https://github.com/camaraproject/IdentityAndConsentManagement/blob/d3950d68aa16a9ef0b8895053b45e3074faa9c89/documentation/CAMARA-Security-Interoperability.md#client-credentials-flow

@eric-murray you raised the issue and PR that eventually added extra restriction. In both proposals I don't suggest to just revert it and do nothing, but a mean to move to former consensus point and then agree and reformulate approach for client credentials scenario with/without personal information.

[hdamker]

@diegogonmar sorry for my late reaction, I got too many notifications from GitHub in the last weeks ...

To be able to restart the discussion clean, I propose to close the issue here and I create a new one to lift the additional restriction, with a summary of the discussion and a proposal based on your text above (which I not fully agree with, but that's to be discussed then in the new issue).

Would that be ok for you?

[diegogonmar]

Hi @hdamker, fine for me

[jpengar]

@diegogonmar sorry for my late reaction, I got too many notifications from GitHub in the last weeks ...

To be able to restart the discussion clean, I propose to close the issue here and I create a new one to lift the additional restriction, with a summary of the discussion and a proposal based on your text above (which I not fully agree with, but that's to be discussed then in the new issue).

Would that be ok for you?

@diegogonmar @hdamker Hopefully not necessary if we agree that #155 already fixes this.

[hdamker]

@jpengar I agree, let's aim to make it there consistent.

With that I close the issue here.