3Legs and Client Credential in the same API

[FabrizioMoggio]

For the Traffic Influence API, having the Device (identified by the phone number) passed by the API Consumer to the API Producer, 3Legs was adopted FOR ALL the endpoints.

Actually not all the endpoints share sensitive data (Device). The Traffic Influence API can be indeed invoked to influence the traffic for ANY user that is accessing an Application. For this endpoint there is no Device used in the POST, so I assume that I can use Client Credential for these endpoints. Is this correct?

Moreover, there are other endpoints for the API Consumer to read (GET) the status of the TI Resource or to remove (DELETE) a traffic influence resource. These endpoints can be invoked when no user is online to participate in the 3Legs process and anyway the Device information usage was already certified during the POST action. What I need to use for these endpoints, 3Legs or Client Credentials? The point is that if the authorization token expires the API Consumer is not able to access those information or delete the resources on which he already got the consent for. This in the case the user is no more reachable to give the consent. For this reason I would like to use Client Credential for this operations on resources previously created with the consent of the user. Is this possible?

[jpengar]

Hi @FabrizioMoggio, I'll try to give my point of view on this topic.

For the Traffic Influence API, having the Device (identified by the phone number) passed by the API Consumer to the API Producer, 3Legs was adopted FOR ALL the endpoints.

Actually not all the endpoints share sensitive data (Device). The Traffic Influence API can be indeed invoked to influence the traffic for ANY user that is accessing an Application. For this endpoint there is no Device used in the POST, so I assume that I can use Client Credential for these endpoints. Is this correct?

As you mentioned in camaraproject/Commonalities#245, CAMARA ICM defines:

"It is important to note 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."

...which is the criteria to decide whether client credentials (2-legged) are allowed or not. Or vice versa, when 3-legged access becomes mandatory. This MUST be followed by all APIs.

So, whether the Traffic Influence API is allowed to use client credentials or not depends on the purpose under which the API is accessed, whether or not it is legally considered processing of users' personal data, and consequently which legal basis is applied (which may or may not require user's opt-in and/or opt-out). And that would depend on local regulations, legal rulings, definition of specific application use cases, and so on.

That's why ICM has defined a "generic" openId security scheme that provides the flexibility to support any of the defined flows (Auth code, CIBA or Client Credentials) to access CAMARA APIs and the allowed authorization flow(s) will be determined at onboarding time, taking into account all those context variables that have been decoupled from the API spec.

Long story short, if for Traffic Influence API (or some specific endpoint of the API) is legally guaranteed that there is no personal user data processing, then it could be consumed with Client Credentials and during API onboarding it will be defined accordingly

Moreover, there are other endpoints for the API Consumer to read (GET) the status of the TI Resource or to remove (DELETE) a traffic influence resource. These endpoints can be invoked when no user is online to participate in the 3Legs process and anyway the Device information usage was already certified during the POST action. What I need to use for these endpoints, 3Legs or Client Credentials? The point is that if the authorization token expires the API Consumer is not able to access those information or delete the resources on which he already got the consent for. This in the case the user is no more reachable to give the consent. For this reason I would like to use Client Credential for this operations on resources previously created with the consent of the user. Is this possible?

This is not a technical reason to perform a subsequent GET or DELETE request with Client Credentials. If the API client has a 3-legged access token and it expires, the API client can simply request a new one (no need to re-capture consent if it was previously captured), or better yet, use the refresh_token to get a new access_token for the same AuthN/AuthZ session. These are standard procedures as defined in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md

[FabrizioMoggio]

currently all the endpoints of the TI API are "under 3legs". Even if the sensitive data are optional and so no user is involved.

let's consider this use case: the API Consumer wants to setup a Traffic Influence for any user.

I don't have any user involved, how can I use 3Legs?

Currently the TI API has the same endpoint for the API Consumer to ask the "influence" for all the users or for a specific user. If the endpoint is used for a specific user, 3legs works. If it is used with no user involved, it doesn't work. The "Device" parameter is optional

My idea, to solve this situation, is to split the operation in two endpoints, one endpoint to be used when a user is involved, with 3 Legs and one endpoint when no user is involved, with client credential.

OR...is there a workaround to use 3legs also in the case no sensitive date is involved? I mean, in the endpoint the sensitive data is optional.

[jpengar]

Please bear with me because I don't have all the context about this API functionality :)
But, IMHO, I think it would make much more sense to have these features in separate endpoints (generic and user specific). And you could have access control with different scopes for each endpoint.

[FabrizioMoggio]

that was exactly my idea. to have one endpoint to be used when a device is involved (with 3 legs) and a separate endpoint when no user is involved (with client credential). Is this allowed by CAMARA?

My concern is that the Guideline states: "It is important to note 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."

So, wrapping up, my question is: is it mandatory to use 3Legs for the whole API (for all the endpoints) or it is mandatory for just the endpoints, in that API, that are actually processing the personal data?

[jpengar]

As I said, IMHO, if you define a separate endpoint, and if it is legally guaranteed that there is no processing of personal user data, then that specific endpoint could be consumed with Client Credentials. While others may still require 3-legged access.

[hdamker]

@FabrizioMoggio You can have a look on how we solved (or better: tried to solve) the similar topic for the quality-on-demand API. More or less we have described for each endpoint the behaviour of the two cases of 2-legged and 3-legged access token. E.g. for the DELETE /sessions/{sessionId} (which might be comparable to your case):

        **NOTES:**
        - The access token may be either 2-legged or 3-legged.
        - If a 3-legged access token is used, the end user (and device) associated with the session must also be associated with the access token.
        - The session must have been created by the same API client given in the access token

My view is that existing sessions should be able to be managed with 2-legged tokens (read, delete) even if the API Client created them with a 3-legged token (as they had the user consent for the "create" or "write" scope at that time). But we don't take this decision within the API specification, as it depends on the (legal) context.

[FabrizioMoggio]

For the TI API I would prefer to have two different endpoints:

• one to ask for network configuration for every user (security: clientCredentials - 2Legs)
• one to ask for network configuration for a specific user (security: openId - 3Legs)

I think, in the TI API scenario, this is more clear for the developer to understand and for the Operator to implement.

[hdamker]

@FabrizioMoggio fair point to have different endpoints if you have the case that you return a list of network configurations for all users (don't forget paging in this case ... if the lists can get long). In quality-on-demand the situation is different: we don't see that we return all sessions and API consumer has created, but always only for a specific device. So in case of 2-legged token the device object has to be provided.