Use of two-legged authentication for MSISDN verify

[StefanoFalsetto-CKHIOD]

Problem description
At the moment it has been chosen to only use 3-legged authentication mechanism with this service to "uphold the principles of transparency and user-centric data control."
But in Camara guidelines it is also stated:

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.

Possible evolution
In cases where the onboarding process and the local legislation permits to use the MSISDN of an end customer (i.e., the consent has already been managed in some other way), it could be useful to allow the possibility to choose between 3-legged and 2-legged authentication flow.

[bigludo7]

Hello @StefanoFalsetto-CKHIOD

For me the 'golden rule' is defined in ICM documentation here

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.

After it is legal privacy regulation interpretation. As far as I know in most European countries the MSISDN is considered as a personal user data so 'mechanically' in CAMARA implem we have to to use 3-legs in these geographies.
Perhaps situation could differ in other part of the world but this need to be closely assessed from legal perspective.

[fernandopradocabrillo]

Hi @StefanoFalsetto-CKHIOD

Beyond of the privacy topic mentioned by @bigludo7, what is the use case you might have for 2-legged in this API? The core functionality is to compare the provided phone number with the one deducted from the access token. If the token is not related to a phone number how are you going to verify it?

[ab-ip]

Hi guys,
Actually it is possible to have 2-legged for Number Verification in some specific implementation cases.
If there is Delegated Consent and User Resolution/Identification is based on a NAT Session (PublicIP + Port).
And this is the best approach from many different perspectives including UX, Security, QoS.

@fernandopradocabrillo AccessToken is always related to resolved phone number. But with NAT Session to Phone Number resolution method, there is no need to have 3-legged with the MNO Auth Server.

[StefanoFalsetto-CKHIOD]

Thank you @ab-ip . I think that adding the optional phoneNumber could be useful to cover those use cases which can use the 2-legged authentication method.

[bigludo7]

I should confess that I'm a bit lost... If we do not pass the phoneNumber in the body what will you compare with the phone number obtained by the network @StefanoFalsetto-CKHIOD ?
I understood from @ab-ip that the mobile connection could be bypassed to get the number but we still need 2 phoneNumber to make a comparaison.

As told today in our call we have to be careful about the privacy topic any way.

[ab-ip]

@StefanoFalsetto-CKHIOD How do you mean optional phoneNumber can cover 2-legged?
It is mandatory to send phoneNumber for comparison/validation process. There must be 2 phoneNumbers as @bigludo7 mentioned. First one is "submitted" phoneNumber (via API), and second one is "resolved" phoneNumber via MNO backend platform.
@bigludo7 there is no privacy concerns for number verification, as user shares the number with the service.
There is privacy concern for phone sharing, if MNO shares number with the service, but this is anyway not recommended case.

[StefanoFalsetto-CKHIOD]

I am very sorry I mixed up two comments in two different projects. Please ignore my previous comment.

Let's stick on my original request: adding the possibility of using the two legged authentication.

@bigludo7, as @ab-ip just said, there could be some privacy-related problems with the number share (and by the way, from my previous experience I think it will be hard to see any MNO implementing it).

That's not the case for number match, since the information shared is just "match/no match".

[jgarciahospital]

Hi all,

First, confirm that of course API always requires a phone number parameter for comparison reasons. Otherwise, as said, there is nothing to validate (if we are speaking about the /verify endpoint).

Second, this number needs to be compared with other number. As @fernandopradocabrillo stated before, the 3-legged token obtained following a frontend flow is indeed the comparison pair that the API is supposed to use. If a 2-legged approach is used, where user is not identified in the token, there is no way to neither compare nor obtain the identity of the user's connection, since both frontend and 3-legged are the solution for it. if there is other way to solve this, obtain information of the device connection without a frontend integration, and include user info in a 2-legged token, please bring this proposal.

FInally, privacy. Even when the operator, in /verify, is "only" validating the phone number and not exposing it, there is a treatment of personal data that requires legitimization. Otherwise, same understanding could be taken for location, and I'm pretty sure that we are all aligned with the statement that location verification API is indeed treating personal data that requires privacy justification.

[ab-ip]

@jgarciahospital I already explained how it is possible to resolve User data based on the device NAT Session related to Service endpoint. It is not needed to have User in front of MNO Auth Endpoint. Service can provide NAT data (IP+Port) to MNO in order to resolve user, and to connect User for the Token.
The flow is always User - Service - MNO, and there is no direct User - MNO interaction which excludes 3-legged from MNO Auth Server.

[StefanoFalsetto-CKHIOD]

@jgarciahospital I am no GDPR expert but are you sure that from the privacy point of view the clear text information sharing (e.g., location, msisdn, in general all personal data) is totally the same thing of sharing a match (e.g., results obtained from msisdn match)?

[eric-murray]

@ab-ip

Service can provide NAT data (IP+Port) to MNO in order to resolve user, and to connect User for the Token.

And this option is supported by CAMARA as part of the CIBA flow, passing the end user IP / port in login_hint.

But, of course, CIBA is still a 3-legged flow. And we need to trust the "service" to provide the true IP/port it captured from the device. If we really want to be sure that the device itself is part of the flow, then we are back to the authorisation code flow, where the device itself makes the request (via a re-direct) for the first of the three legs. Then the MNO knows the true IP/port being used.

The 2-legged client credentials flow would only work if the device itself was requesting to call the API (so asking to verify its own MSISDN), or the API caller (application server) had previously provided the API provider the IP/port of the end user device using some mechanism not defined by CAMARA (so still "3-legged", but with the first "leg" not defined by CAMARA).

I don't see either of these being significant use cases.

[ab-ip]

@eric-murray
Yes this is correct explanation, thanks for jump in.
It is CIBA flow as User is included in the process and user initiates the action on Service side, but then Client(Service) initiates Auth to MNO and MNO backchannel is used for Auth (NAT Session --> MSISDN). The point is that Backchannel is implicit (seamless) in this case.

There is no special requirements for "trust" from the Service side. If they dont send valid IP/Port values the user/data wont be resolved or as the worst scenario verification will be false.

[jgarciahospital]

@eric-murray I cannot agree more, perfectly explained.

As operators, we are the one who provides the validation of the phone-number belonging to the user's connection, which is the intention (AFAIK) of this service. If looking for an API that translates an IP address into a phone number, maybe that could be covered in separate, but up to now the value proposal is based on the operator been who actively authenticates the user's connection.

And of course, in any case based on a two-legged approach, in which case no way of validating the API input phone number with any other parameter.

@StefanoFalsetto-CKHIOD about privacy, while of course this will depend on each country/region regulation, phone-number is indeed considered as personal information, and the fact that the API only validates doesn't imply that the developer ends-up with more information than at the beginning, provided by the telco. That is why even validating is supposed to be considered as personal data treatment.

[StefanoFalsetto-CKHIOD]

There is an unwritten agreement for at least some implementations that clients should poll immediately upon receiving the auth_req_id, irrespective of the value of the interval parameter.

That's an interesting approach, but at the end of the day it's a sort of trick. I mean, that's a way to overcome the intrinsic slowness (or poor definition) of the CIBA flow.

If you have experience of clients requiring to poll multiple times leading to poor latency performance, it would be good to understand the reasons for this need to poll. Or are they waiting 5 seconds before the first poll?

That's not a matter of experience, it's a matter of flows. Client Credentials involve just one request and one response. Any three-legged authentication mechanism involve more than one. That means more time spent for an API Consumer in waiting for a token.

I am not telling that 3-legged auth is something to avoid totally, I am just telling that it depends on context. In my opinion, using this service inside a complex anti-fraud set of checks is quite different from using it to enter into my fitness gym account.

[eric-murray]

That's not a matter of experience, it's a matter of flows

Indeed the CIBA standard allows repeated polling. My argument is that, in the context of CAMARA, there is no reason why the first poll should not succeed for these anti-fraud scenarios, as the API provider will not be seeking "out of band" consent. If all three legs call the same gateway, the same TLS connection can be used for each.

So the additional latency should just be the round-trip time for the additional legs. Experience will say what it actually is for different clients.

Client Credentials involve just one request and one response

And CAMARA allow client-credentials where local regulation permits it. That's why CAMARA APIs still support an explicit device or phoneNumber parameter to be provided even though that is not required when the token is 3-legged.

[StefanoFalsetto-CKHIOD]

And CAMARA allow client-credentials where local regulation permits it. That's why CAMARA APIs still support an explicit device or phoneNumber parameter to be provided even though that is not required when the token is 3-legged.

Unfortunately that's not true for this service.
In fact, this thread started from my question about allowing the possibility to also use CC.
From the API YAML code:

In the case of the Number Verification API scenario and according to the API definition, 3-legged access tokens must be used by API clients to invoke this API with dedicated scope. The API client must authenticate on behalf of a specific user to use this service. This must be done via mobile network authentication.

[eric-murray]

If you are primarily interested in Number Verification, then the use case for that API really requires the authorisation code flow, and discussions on CIBA or client credentials are somewhat irrelevant.

You could imagine a new API that verifies whether a given MSISDN matches a given IP address / port, but that is a different API for a different use case that does not verify that the device itself was involved in the transaction at all.

[StefanoFalsetto-CKHIOD]

So we are losing time talking in this thread about improving this service adding Client Credentials. That's unfortunate.

If there is no way to improve anything, for me we can close the discussion.

[bigludo7]

@StefanoFalsetto-CKHIOD I do not see action to be done following this thread but good discussion.
Could we convert it as a discussion?

[StefanoFalsetto-CKHIOD]

@bigludo7 yes we can convert it as discussion. Unfortunately I don't know how to do it.