3Legs and Client Credential in the same API

[FabrizioMoggio]

For the Traffic Influence API, having the Device (with the phone number potentially) 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.

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.

[FabrizioMoggio]

The CAMARA Guidelines (https://github.com/camaraproject/IdentityAndConsentManagement/blob/release-0.1.0/documentation/CAMARA-API-access-and-user-consent.md#authorization-flows--grant-types) state: "Every time personal user data is processed by an API and the user can exercise their rights either via opt-in and/or opt-out, 3-legged access tokens must be used."

May understanding of that sentence: "Every time personal user data is processed BY AN API" was: "the whole API" must use 3Legs.According to my reasoning in the post above, in my opinion, the sentence should be: "Every time personal user data is processed BY AN ENDPOINT....."

[FabrizioMoggio]

@hdamker , @tanjadegroot , @rartych is it possible, according to the guidelines to have an API implementing some endpoints with 3Legs (when sensitive data are exchanged) and endpoints with Client/Credential (when no sensitive data is involved)?

[hdamker]

@FabrizioMoggio that's a discussion for the Identity and Consent Management Working Group, pinging here @AxelNennker and @jpengar. I would say that it should be possible, but the question is more how to a) implement it and b) make it transparent to the API client which flow to use.

BTW: there might be difference if the API client just provides sensitive data to the API, or the API is processing personal user data (which is hold by the operator). Therefore I wouldn't replace the wording "processed by an API" with "data exchanged". But that's more for the decision which flow is the right one in a specific case.

[FabrizioMoggio]

@hdamker you are totally right I should have opened the discussion in ICM. I can close this thread and open it again in ICM.

by the way, according to my knowledge it is not a problem technically to define endpoints with different "security"

The issue is for endpoints that are just machine to machine with no end user involved (e.g. get a status of an operation, or delete a resource), how can I use 3Legs with these endpoints is no user is involved in the flow?

[FabrizioMoggio]

Discussion created in ICM: camaraproject/IdentityAndConsentManagement#184