Support of Multi-SIM lines in CAMARA APIs

[jgarciahospital]

To be considered as part of #273

Intro

Current CAMARA APIs based their functionality on subscriber's line identity, usually phone_number. Specifically for mobile lines, that is a suitable identity for the most of scenarios, but there is an specific case that requires analysis.

MultiSIM lines

MNOs usually offer a line enhancement that allows users to install the same phone line (same MSISDN) in multiple devices, known as MultiSIM. Even when different technical solutions are posible, the service is based on multiple SIMs (phisical or virtual) that are binded to the same main phone_number, it is, multiple IMEIs associated to the same MSISDN This approach is commonly used to enable secondary/companion devices like:

• Wearables
• Tablets
• Wi-Fi hotspots
• Backup smartphones

MultiSIM in CAMARA APIs

While certain APIs are agnostic to MultiSIM situation, since they refer to information of the proper line or even subscriber like carrier billing, KYC, OTP..., other APIs are tied to a device and require a different consideration to be managed in a MultiSIM scenario.

Just as couple of examples:

• when enabling a QoD session targeted for a MSISDN, if multiple SIMs and devices are associated to that same MSISDN, the telco need to know/decide which of those SIMs are to be affected. Behaviour need to be defined.
• when verifying the location of an MSISDN, if multiple SIMs and devices are associated to that same MSISDN, the telco need to know/decide which device's location information to retrieve, since different geographical locations can co-exist for each device associated to the same MSISDN.

Action required

Based on this scenario analysis and handled by a common aligned approach for similar cases:
CAMARA APIs need to analyze their impact when a MultiSIM scenario is handled, define a specific behaviour and adapt the API (if needed)

As example of current discussions or defined behaviours, SIM Swap already considers MultiSIM lines as part of the information that the API needs to retrieve.

[eric-murray]

For the Vodafone implementation of multi-SIM, phoneNumber is still a valid identifier for each of the secondary devices, as each SIM still has its own MSISDN (the "secondary" MSISDN). For the "primary" device (usually the smartphone), the primary and secondary MSISDNs are the same.

Whether an implementation will treat a phoneNumber as the primary or secondary MSISDN is dependent on that implementation. For the Device Identifier API, I added a statement that phoneNumber would be treated as the secondary MSISDN, which would allow retrieval of the IMEI for secondary devices without affecting the ability to retrieve the IMEI for the primary device.

For at least some other APIs, I think treating the phoneNumber as the secondary MSISDN will also work just as well, but does pose the following questions:

• How does the API consumer learn the secondary MSISDN if they do not already know it?
• Are there any implementations of multi-SIM where secondary devices do not have their own MSISDN? If so, what identifiers for secondary devices are valid in those cases?

[jgarciahospital]

Thanks @eric-murray,

Let me include one other question:

• How does the API consumer learn the secondary MSISDN if they do not already know it?
• Are there any implementations of multi-SIM where secondary devices do not have their own MSISDN? If so, what identifiers for secondary devices are valid in those cases?
• How do we manage request when primary MSISDN is included? First because user may not be aware of the rest of secondary MSISDNs (if exist), and second because applications will for sure only have the primary.

1. Either consider that the users know that primary device is exactly the device identifier they want to use.
2. Or consider that maybe the user/developer only knows the primary MSISDN, and therefore we cannot be sure that they are targeting exactly primary device and a different behaviour need to be considered for the rest of devices too.

[sachinvodafone]

for MultiSim definition clarification, just checking whether we are considering multi-SIM as a scenario where both devices have separate MSISDNs under one account (i.e., the primary device has its own MSISDN, and each secondary device has its own distinct MSISDN), allowing each device to operate independently without sharing call/message capabilities?

Or, are we considering scenarios where secondary devices share the same MSISDN as the primary device, meaning all devices are linked to the same number under the same account, enabling users to receive calls and messages on any of the devices?

[jlurien]

It's the second one @sachinvodafone, several SIMs (IMSI) linked (publicly) to the same MSISDN. Implementations may assign internally a secondary MSISDN to each SIM, for network operation, but in general customers are not aware of this secondary MSISDN.

[AxelNennker]

I think this is only a problem with CIBA, right?

If the authentication request is from one of the devices with the same MSISDN and the API consumer is using OIDC authorization code flow then the device can be uniquely identified. The access token is then associated with that device.
The access token does not even need to be associated with the MSISDN.

[eric-murray]

@AxelNennker

I think this is only a problem with CIBA, right?

This issue also applies to client_credentials grant

[AxelNennker]

@eric-murray

This issue also applies to client_credentials grant

client_credentials and CIBA currently use the MSISDN.
If the device cannot be determined by the MSISDN, then bummer.

In client_credentials with MSISDN, I see no solution. We would need some other shared identifier e.g. iccid
In CIBA the MNO could provide a device-selection UI on the authentication device, but standardizing UI (capabilities) is not going to happen in my lifetime. I think that is possible, but unlikely to happen.

For OIDC authorization code flow, we do not have a problem for tablets and (backup) smartphones.

Wi-Fi Hotspots and Wearables fall in the standard OAuth2 use case of limited UI-capability devices like picture frames.
If the devices can show a e.g. a code or qrcode then, we are back to OAuth2. That can be made to should work with OpenId.
If we limit the devices to near-zero or zero UI-capabilities, then I would question the business viability of this use case.
Those devices are usually not running an standard OS and their capabilities vary at lot. Availability of Wifi or Bluethooth, hardware buttons and (touch-)screens. It is near to impossible to find a CAMARA solution that is not proprietary, I think.
This kind of hardware exists today and they have found solutions for their problems.
With wearables, I think, we are might be more in TS.43 territory and associating a secondary device with a primary device
Additionally, the danger of privacy and freedom violations are huge when the UI-capabilities on the device are low e.g. when the CAMARA API used is Device-Location.

My conclusion:
If the device is able to run a browser or mobile app, then use OIDC authorization code flow and there is no problem because we can identify the device directly and e.g. associate the access token with the IMSI.
I think that use case is the most important business case.

CIBA depends too much on the UI-capabilities of the device. I see no relevant business case.

client_credentials does not work if the only device identifier the API consumer and the operator share is the MSISDN.

Use OIDC authorization code flow and be happy!

[jlurien]

API specs are decoupled of the authorization method used to get the access token. Each operation just assumes that we have an access token and eventually some device/phoneNumber identification, and it would be good if information within each API gave some guidelines for the implementation. But I wouldn't expect a single solution applicable to every CAMARA API, as part of the Commonalities guidelines.

The problematic case is when input is a MSISDN assigned as common phoneNumber for a multiSIM pack, and an instance of SIM within the multi-SIM pack cannot be deducted from the access token. Options in this case are:

• To adapt the logic for the multiSIM case, keeping the same response schema.

  • This is, for example, what sim-swap proposes. For other APIs it may work as well (device-status. location-verification, etc). For others, like quality-on-demand or location-retrieval is not that simple. WGs may decide to document in the API spec a common approach to the problem, or leave some space for implementations to act upon the case.

• API server cannot fulfill the request if a single instance is not identifiable by means of the access token.

  • Then an error response makes sense. From the current set of proposed error codes, the one that is more suitable, IMO, is 422 SERVICE_NOT_APPLICABLE (The service is not available for the provided identifier), or even the generic 422 Unprocessable Content
  • Although it wouldn't be clear if service is not available for multiSIM lines, or if the service is potentially available for multiSIM lines, but the combination of access token + provided identifier is not processable. Implementations may provide some additional guideline by means of the message in the error response.