Is the QoS Profiles auth process a two-legged flow (client credentials)?

[trehman-gsma]

Hello QoD team 👋

I hope this is an appropriate channel to ask about auth flows.

As per the title - will the QoS Profiles endpoints be secured by a two-legged auth flow?

I understand that the API spec currently states "oAuth2ClientCredentials" but my understanding is that some of the endpoints contain user data and will therefore switch to a three-legged flow.

I am asking in context of routing requests to target operators in a federated/aggregated model. The routing discussion is possibly out of scope of CAMARA - but you are probably aware of discussions in related forums whereby the user identifier in a three-legged flow can be used to facilitate routing to target operators.

The QoS Profiles endpoints do not contain user data, which means they are likely to be secured by Client Credentials (which does not contain user data either). Is my understanding correct? If so, I will feed this into the relevant platform for routing discussions (that we have use cases where user data is not present to facilitate routing).

Thanks!

[eric-murray]

Hi Toyeeb

Auth flows have not really been discussed for QoD as there are still open points in both Identity & Consent and Commonalities.

However, client credentials will not be suitable for POST /sessions or GET /sessions/{sessionId} as both these end points involve "user resource" (in this case, the end user identity, whether than be by MSISDN, NAI or IP address). For those end points, 3-legged authentication is required as end user consent may be required and hence must be checked.

For DELETE /sessions/{sessionId}, there is no user resource in either the request or response, but as this operation affects the service to an end user, I suspect 3-legged is also required here.

There is an issue with both GET /sessions/{sessionId} and DELETE /sessions/{sessionId} that you cannot identify the end user from the request itself, which may present a challenge for routing that needs resolved. It may be that the sessionId needs to be treated as an end user identifier.

For GET /profiles and GET /profiles/{name}, client credentials will remain acceptable.

[trehman-gsma]

Thanks for confirming the current position, @eric-murray. I will provide this feedback into the wider routing discussions (that we have valid client credentials use cases where user data is not present to facilitate routing).

I'll leave this discussion open for a week and then close if no further comments (unless the codeowners consider it a closed discussion point already).

[trehman-gsma]

Hi @eric-murray,

Does the QoD group (or perhaps yourself) have a view on how routing could be achieved for GET /profiles and GET /profiles/{name}? I believe these endpoints do not contain any user identifiers - so there is a challenge in identifying the target operator for these requests (in an aggregator/federation context).

Would appreciate your advice on how to further this discussion within QoD. I can raise an issue / another discussion / join meeting if required.

Thank you.

[eric-murray]

Hi @trehman-gsma

It doesn't make sense to fulfil these API requests as defined within a aggregated or federated context. The solution is to add an optional PLMN ID query parameter allowing the API consumer to specify which network they are interested in retrieving profiles for. If that parameter is missing, then the API provider returns their own default set of profiles.

If the project decide to query by MSISDN ("tell me which profiles are available for this specific device"), then we are back to 3-legged and the problem is solved that way.

On my previous response, I suggested that sessionId might have to be treated as an end user identifier, but this will be problematic. Instead, I'm thinking that if a valid sessionId exists, then the end user can be assumed to have consented to all future operations on that sessionId.

This would allow 2-legged tokens to be used for GET or DELETE of a session without knowing in advance to which device the session belongs. For routing, some formatting rule for sessionIds would be required that allows the issuer to be identified.

[trehman-gsma]

Thanks @eric-murray.

You mentioned 3 possible options (1- PLMN ID query param, 2- query by MSISDN, 3- SessionID as user ID). I take it that these are still to be officially proposed? I can't see anything in Issues or PRs at the moment.

[eric-murray]

Yes, valid authorisation schemes for QoD following the decisions within I&C and Commonalities have not yet been formally treated within the sub-project. So security for all endpoints remains either client credentials or, for some, optionally authorisation code for now.