Allow to use operator token for device authentication in OpenID Auth code flow

[Elisabeth-Ericsson]

Problem description
With issue #145 it was agreed to allow using the operator token for device authentication by passing this token as value in the /bc_authorize request as 3rd option for -loginhint, in addition to tel and ipport. This extension is only added for CIBA flow.
However, also authorization code flow would greatly benefit from the ability to pass the operator token. It shall be possible to leverage the -loginhint parameter in the /authorize request and lower the burden on Authorization server to convert an IP address to an MSISDN.

Possible evolution
Proposal is to allow loginhint parameter in the authorization code flow authorization request and extend the description in the CAMARA-Security-Interoperability.md (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md) as follows:

Authorization code flow allows the client to use id_token_hint or login_hint as a hint in the authentication request. The client shall be enabled to use the optional login_hint. If used, the login_hint must be populated with one of the 3 formats described in "Format of login_hint" section (https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#format-of-login_hint)

Alternative solution

Additional context

[AxelNennker]

The new format was added in #218
The format section applies to all flows.
So, operator token support is already part of CAMARA. CIBA and OIDC authorization code flow.

[jpengar]

The new format was added in #218 The format section applies to all flows. So, operator token support is already part of CAMARA. CIBA and OIDC authorization code flow.

I disagree as mentioned here: #191 (comment) and here #215 (comment)

This issue was originally intended to clarify the authentication method for the Auth Code flow as defined by CAMARA today. I don't see operator tokens in the scope of this issue discussion.

Also, the use of operator tokens is something that will be discussed and included in Spring25 and not in the current Fall24 meta-release. CAMARA has so far defined an additional possible value for the operator token as login_hint (besides MSISDN and IP), which CAMARA has so far only discussed for CIBA. The login_hint has never been discussed for the auth code flow, because it is not needed, since the subscription identity is known anyway from network-based authentication.
...

[jpengar]

@Elisabeth-Ericsson Could you please provide more details on the benefits of using the operator token as a login hint in the Auth Code flow? If the Auth Code flow is used, the network auth can still resolve the corresponding subscription identifier. The operator token is another alternative in CIBA for identifying a user by MSISDN or IP address. When an operator token is obtained, the API consumer could just use CIBA to obtain an access token. Operator tokens also need to be validated.

It is also important to note that any information such as IP, MSISDN or the operator token should not be included in the request URL as query parameters for security purposes. In order to achieve this, it may be necessary to utilise the request object.

[AxelNennker]

Also, the use of operator tokens is something that will be discussed and included in Spring25 and not in the current Fall24 meta-release. CAMARA has so far defined an additional possible value for the operator token as login_hint (besides MSISDN and IP), which CAMARA has so far only discussed for CIBA. The login_hint has never been discussed for the auth code flow, because it is not needed, since the subscription identity is known anyway from network-based authentication.

The API Subject (subscription identity) is associated with the operator token. So, no need for network-based authentication.

[AxelNennker]

@Elisabeth-Ericsson Could you please provide more details on the benefits of using the operator token as a login hint in the Auth Code flow? If the Auth Code flow is used, the network auth can still resolve the corresponding subscription identifier. The operator token is another alternative in CIBA for identifying a user by MSISDN or IP address. When an operator token is obtained, the API consumer could just use CIBA to obtain an access token. Operator tokens also need to be validated.

The operator token can contain all the subscription information the MNO's entitlement server has access to.
MSISDN, IMSI, IMEI, ...
That is why the operator token is encrypted.

It is also important to note that any information such as IP, MSISDN or the operator token should not be included in the request URL as query parameters for security purposes. In order to achieve this, it may be necessary to utilise the request object.

Why do we accept the tel:MSISDN in CIBA requests as an login_hint URL parameter if that is a security concern?

A signed and potentially encrypted request object is preferable because URL parameters are sometimes logged and they have no integrity protection. I recommend to always use signed request objects.

[Elisabeth-Ericsson]

There are several benefits when allowing the login_hint as described in OIDC Auth code flow:

1. Supporting the login_hint parameter in the authorization code flow allows to overcome the burden of Network authentication based on IP. The IP might be nat'ed (if the authorization server is deployed ouside of CSP's internal NW). The translation of nat'ed IP to internal IP is cumbersome and not always unique.
2. Avoid security problem: For IP to MSISDN translation it is a common method to let the gateway enrich the MSISDN in the header. This must only happen when contacting the authorization server, but not for other server targets. Nevertheless, this is a security hole by itself. It is dangerous to assume that all gateways can properly distinguish.
3. Performance benefit:The operator token can include encrypted MSISDN and or IMSI information, which can be extracted by the authorization server by one call to the entitlement server and used for consent check.
4. Consistency between the two 3-legged flows: authorization code flow and CIBA flow + standard compliance

[eric-murray]

@AxelNennker, @jpengar
I agree with you both!

I agree with Axel that CAMARA already "allows" login_hint to be used for authorisation code flow (because OIDC core allows it, and CAMARA do not say otherwise), But I also agree with Jesús that CAMARA have not defined any use case that requires use of the login_hint parameter for authorisation code flow. Vodafone's own implementation will ignore this parameter, if present.

@Elisabeth-Ericsson, @AxelNennker
I still don't understand how an operator token in a login_hint provided for the /authorize endpoint will in any way "authenticate" the end user device (UE).

If "device A" requests and receives an operator token, which is then stolen and used in the authentication (/authorize) request from "device B", how is the network operator expected to know that the authentication request has not come from "device A" if they are NOT using network authentication? Maybe you could explain.

[AxelNennker]

I think it does not really matter that VF ignores login_hint=operator_token: because the client would not have gotten an operator token in the first place because VF does not issue operator tokens for that client.
That is probably true for all operators and all clients if they do not support operator token, I think.

I heard that VF does not support consent collection in any front-end flow as described in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md . Please correct me if that hearsay is wrong. That, if true, would be an example of something ICM provides guidelines for but not all operators support that feature. It is not the only example where we describe something in ICM but leave it to the onboarding process to tell the API consumer that e.g. CIBA is the only supported flow.
I think there is no harm done. Although I wished most operators would support consent collection and prompt=consent.

[eric-murray]

@AxelNennker
My point was that Vodafone ignore any login_hint parameter in the authorisation code flow, irrespective of its contents. Whilst we do not support operator tokens, I'm pretty sure we have devices that support telephone numbers and IP addresses. But even then, we ignore the login_hint, because it is not needed.

If any API provider is NOT ignoring the login_hint if present in the CAMARA authorisation code flow, I'd be interested to know what they are doing with it.

[DT-JensPoeschl]

Usecase for MSISDN as login_hint: For KYC fill in on cross devices e.g. Desktop or Tablet in a WIFI environment, user consent for such an API needs always user authentication. In this case, network authentication is not possible. SMS OTP would be a standard for this. For KYC fill in, there has to be done some look ups/ Eligibility Checks e.g. Business Customer Y/N, More than one MSISDN per account Y/N before you are redirect the customer to a MSISDN request webpage for SMS OPT . Without MSISDN as Login_hint, you are not able to do eligibility checks before you start any redirect to any CSP webpage.

[eric-murray]

@DT-JensPoeschl
Sure - network authentication fails because the connection is over WiFi, and so you resort to out of band authentication using something like SMS OTP. This would also be a valid use case for the operator token, as the token itself in a login_hint cannot be trusted any more than the MSISDN.

Alternatively, as the application knows the device is connected via WiFi, it could have made the KYC Fill-In API request using CIBA. The authorisation code flow is adding nothing to the use case here other than latency.

But back to the proposal of @Elisabeth-Ericsson for CAMARA to explicitly document use cases of login_hint for the authorisation code flow. So I can understand that an operator token can act in exactly the same way as MSISDN does for your scenario - it allows the network operator to work out who to send the SMS OTP to.

But in no way does it "authenticate" the device, even though it will be harder to send a false operator token than a false MSISDN.

[jpengar]

I believe there may be a misunderstanding regarding the role of the operator token in CAMARA. It seems that there is an assumption that possessing the token equates to authenticating the device. In the context of CAMARA, where the operator token is provided as a login hint, it should be noted that this does not actually authenticate the device. The token is simply a means of identifying a device based on its contents. However, there is no guarantee that the token is not being used by a third party, or used in a different device from the one used to obtain the operator token, etc...

The proposal to use the Authorization Code flow, passing the operator token as a login_hint and considering that sufficient for authenticating the device, is not an optimal solution in my view. It would be necessary to validate the login_hint against the actual authentication mechanism (in the case of the Authorization Code flow in CAMARA, this would be network authentication). Based on the outcome of the aforementioned validation, the Auth server would then be able to determine whether to generate an error if the operator token does not match the authenticated device, to ignore the operator token in the event of discrepancies, or to pursue an alternative course of action. It is important to note, however, that CAMARA has not yet defined any of these potential actions for login_hint in the auth code flow. Given that the operator token would still require validation, I believe that the operator token's utility is limited to CIBA.

@Elisabeth-Ericsson additionally asserted that this approach addresses specific scenarios, such as when a device is connected to a Wi-Fi network or roaming with local breakout (AFAIK the majority of operator services are currently available with Home Routing, where the IP address will correspond to the home network). However, CAMARA ICM ruleset recommends the use of the Authorization Code flow for on-net scenarios, where the device is connected to the operator's network. For other cases, such as when the device is off-net, the correct solution is to use CIBA. In situations like Number Verification, which requires the Authorization Code flow, if the device is on Wi-Fi, it simply won’t work—that’s by design. Number Verification is specifically intended to validate against the mobile network, which is the value proposition of that API.

[AxelNennker]

Many operators are working on enabling CAMARA over Wifi. Specifically getting an API access token over Wifi.
Requiring a mobile connection or the sending of an SMS are both a big drawback. Both lead to bad user experience and prevent API consumers from adopting CAMARA APIs. Also, SMS fraud is a reality that operators face.

The operator token is supposed to be the replacement for network-based authentication.
The operator token enables subscriber authentication over any network (e.g. wifi) because it leverages SIM-based authentication (EAP-AKA) - something only MNOs can provide.

[AxelNennker]

... Given that the operator token would still require validation, I believe that the operator token's utility is limited to CIBA.

The operator token leverages SIM-based authentication and is a replacement for networkbased-authentication.
I think that the operator token eliminates the requirement for Telco Finder, if we associate routing information to the operator token.

I think that CIBA is the wrong flow anyway, if consumption device equals authentication device.
CIBA is reasonable e.g. for the end-user visiting the bank's website on their non-sim-device (e.g. Laptop) and the bank's backend sends a CIBA request. If the end-user is on a sim-device e.g. their smartphone then we should enable SIM-based-authentication. Think of e.g. the first-run of the bank's mobile application and that device using the operator token for CAMARA KYC APIs.

[kwokonn-looi]

The operator token leverages SIM-based authentication and is a replacement for networkbased-authentication. I think that the operator token eliminates the requirement for Telco Finder, if we associate routing information to the operator token.

I think that CIBA is the wrong flow anyway, if consumption device equals authentication device. CIBA is reasonable e.g. for the end-user visiting the bank's website on their non-sim-device (e.g. Laptop) and the bank's backend sends a CIBA request. If the end-user is on a sim-device e.g. their smartphone then we should enable SIM-based-authentication. Think of e.g. the first-run of the bank's mobile application and that device using the operator token for CAMARA KYC APIs.

If according to the GSMA ASAC.01, the abovementioned routing towards the MNO Entitlement Server (ECS) will need to be addressed also at the Eligibility Token stage by the Aggregator. So the similar routing for the Operator Token consumption will apply.

If the use-case of the Operator Token consumption is for 3rd party APPs like mobile banking, we still need to address how the Operator Token may be acquired in this case for non-carrier/OS-privileged APPs to call the TS.43 client.

[AxelNennker]

If according to the GSMA ASAC.01, the abovementioned routing towards the MNO Entitlement Server (ECS) will need to be addressed also at the Eligibility Token stage by the Aggregator. So the similar routing for the Operator Token consumption will apply.

I am confident that the routing can be solved.

If the use-case of the Operator Token consumption is for 3rd party APPs like mobile banking, we still need to address how the Operator Token may be acquired in this case for non-carrier/OS-privileged APPs to call the TS.43 client.

For iOS appclips look promising. Appclips remove the need that we (the carriers) have to install a privileged application.
Obviously it would be best if the mobile operating system would allow an access to carrier-related methods that allow the API consumer to find the API provider's endpoints. I put a feature request into Android's issuetracker for an Carrier OpenId API https://issuetracker.google.com/issues/308240647 That would help with the routing and feature detection e.g. PKCE or DPoP support. That (DT) feature request is public, there are other non-public discussions with vendors (of course).

[Elisabeth-Ericsson]

@eric-murray: Hi Eric, you stated that the operator token cannot be used for device authentication. due to the risk that a token, securely delivered to device A, could get stolen by device B. Thus you think that it cannot be used for Number Verify. According to you, only IP based Network authentication is good enough.
Do you have any proposal on how Number Verify could work in LBO scenarios ?

[eric-murray]

According to you, only IP based Network authentication is good enough.

I didn't say that. But I did (effectively) say that I thought this proposal for using an operator token as a means of authenticating the end user device was not secure.

Do you have any proposal on how Number Verify could work in LBO scenarios ?

The operator token needs to contain the CAMARA scopes (including purpose) and the registered CAMARA client id of the application, and be "short dated". That way, the API provider knows exactly what API requests the token authorises, and that this authorisation was given recently.

Additionally, the operator token should always be sent to the API provider using CIBA (ideally, the operator token itself could be used as an access token, but that is too radical a proposal for now). There would be no value in sending operator tokens using the authorisation code flow in "offnet" (e.g. LBO) scenarios when the token already contains the accepted scope parameters.

The application provider will need to satisfy themselves that the device has provided them with a valid operator token. The role of API providers in a Number Verification scenario involving operator tokens will only be to confirm or deny that a given MSISDN (or hashed MSISDN) matches that of the operator token.

[Elisabeth-Ericsson]

Hi Eric, thanks for your response. However, I'm not convinced that the operator token needs to contain the CAMARA scopes.
The operator token is not a replacement of the access token and not demanded by TS 43 either.
However, if we can tie the operator token to the requesting application (registered CAMARA Client ID) and potentially also include the IP address (this is beyond current TS 43), then it should be secure enough to also allow device authentication.

[eric-murray]

... also include the IP address ...

This would be the public source IP address seen by the entitlement server?

This issue is that all devices connected to the same WiFi network will use the same public IPv4 source address (because of NATing). So any of those devices that steal the operator token could still "authenticate" themselves as the original device. But I agree it does further limit the scope for the operator token to be misused.

Including both the source IP and port in the token would be more secure (the source port will eventually be re-used by a different device, but not for some time). But there is no guarantee that the device will allocated the same source port to connect to the authorisation server.

[Elisabeth-Ericsson]

The main argument against the use of Operator Token for authentication is that the Operator token poses a security risk that it can be stolen from the legitimate device and can be misused by a malicious actor from another device. In the current state of how operator tokens are generated, this is possble in the Android system. For the iOS case using CSP app clips/native apps that are priviledged to have operator tokens, the same attack is not possible.

The main reason why the misuse of operator token is possible in the Android ecosystem is that the operator token is not bound to the app that has requested the token. Hence, any app that can steal that token can use it as it’s own. To prevent that misuse, we are currently working with Android team to bind the token with the requesting app with the help of Android OS that cannot be manipulated by any app. Once we do that, it mitigates the risk of misuse for operator token by another app. Then, it is sufficient to rely solely on the operator token for authentication purposes.

For iOS case, where the token is not bound to the requesting app either, the operator token itself never leaves the CSP app clip/ native app boudary and hence that cannot be misused by another 3rd part app.”

[eric-murray]

For iOS case, where the token is not bound to the requesting app either, the operator token itself never leaves the CSP app clip/ native app boudary and hence that cannot be misused by another 3rd part app.

Can you clarify "never leaves the CSP app clip/ native app boundary"?

The encrypted operator token is just a text string, and in order to be sent to the authorisation server in login_hint, it has to "leave" the device as an HTTP GET request query parameter. Are you referring to the unencrypted token?

[Elisabeth-Ericsson]

Can you clarify "never leaves the CSP app clip/ native app boundary"?

Hi Eric, Apple/iOS demands, that the carrier token / operator token is only used in privileged / carrier apps. Such an app can interact with the entitlement server to retrieve the token. It then can use the token to retrieve an authorization code (OIDC auth code flow), but only on the direct encrypted connection between the app and the operator. There are no redirects nor tokens returned to other apps on the device. It therefore cannot be stolen by a malicious app on the device. This is what I meant with "never leaves the CSP app clip / native app boundary.

[eric-murray]

There are no redirects nor tokens returned to other apps on the device

So how would a non-privileged 3rd-party app (e.g. a banking app) use the CAMARA authorisation code flow with an operator token login_hint on iOS? Would the privileged carrier app need to present a CAMARA-specific interface to such apps in order to provide them with the code needed to request an access token?

Also, for CIBA flows, how would the application server learn the operator token to use that in the CIBA login_hint if no 3rd-party app can know the operator token? Would the privileged carrier app need an additional CAMARA-specific interface such as "append the operator token as a query parameter to this HTTPS GET request and send it"?

[Elisabeth-Ericsson]

So how would a non-privileged 3rd-party app (e.g. a banking app) use the CAMARA authorisation code flow with an operator token login_hint on iOS?

You are right, there is much more to the problem. The "operator token" cannot be used "as is" today.
There is the need of converting the carrier token (on iOS) / temporary token (on Adroid) into an eXtended token (Xtoken, subscriberToken) bound to the 3rd party application. Only this extended token can be shared.
I think that DT has some sample code on this and can give more details.