Support of Multi-SIM lines in DeviceLocation APIs

[jlurien]

Problem description
As introduced in camaraproject/Commonalities#302, for Multi-SIM services. providing a phoneNumber as input does not identify a single device uniquely.

Current DeviceLocation specs do not consider or give guidelines about how to behave in scenarios when the input is only a phoneNumber of a Multi-SIM service and specific device (SIM) cannot be inferred from the access token or other device identifier.

Possible evolution
Discuss the problem and alternatives. There may be impact in other tracks, such as IC&M. We may need also to discuss implications in the short term when dealing with this situation in current versions.

In the case of DeviceLocation each API has each own considerations, as each SIM may be located in a different place:

• For location-verification, the input area can match the location of one of the SIMs but not others. Do we return TRUE if there is a single match, or PARTIAL or another new value?
• For location-retrieval, do we have to return an array with several locations? Do we want to disclose that the client has multi-SIM? Would we need to identify each device?
• For geofencing-subscriptions? Do we trigger an event when any of the SIMs enter or leaves the area? How do we identify which device/SIM is the one affected?

Alternative solution

• Relying on 3-legged tokens as much as possible would minimize the problem, but currently we cannot assure that they always identify a single device instead of a phone number.
• Finally we can handle the situation with errors, such as 422 UNIDENTIFIABLE_DEVICE, or another dedicated code, informing clients to provide an alternative identifier that can identify the specific device. But this should be limited to corner situations as it is not dev friendly and in most cases developers do not know if a phone number belongs to a multi-SIM service.

[alpaycetin74]

• For location verification, I prefer to avoid simply saying "PARTIAL". We need to indicate to the caller there are other devices and the devices have their own area match results. We can return multiple results, where we indicate one of them is for the "primary" device and the other results are for "secondary" devices.
• For all APIs, if we return multiple results, should we return the secondary device identifiers in the response? Would there be a privacy concern? Are the secondary identifiers even useful for the caller ?
• For geofencing-subscriptions, the secondary devices may not be compatible with the purpose of the subscription. I don't have a concrete example, but the caller may want to trigger a speicifc action like sending data, automated call or SMS, which may not make sense if the matching device is a smartwatch or fitbit.

[eric-murray]

We should wait until Commonalities (Issue #302) and probably ICM have clarified the treatment of multi-SIM groups before making any decisions. Currently, it is implicit that the device object and 3-legged tokens only identify a single device and not a related group of devices. I don't think it is at all a given that end user consent for the primary device means end user consent for all devices in the group, and APIs need to consider this.

What this sub-project can do is clarify or extend the use cases supported by the API given the existence of multi-SIM groups. The implication above is that the API should locate the entire group as a whole. But maybe the API consumer wants to locate only a single device from within the group (such as a "Find my smartwatch" app)?

By clarifying the use cases you want to support, the requirements on how CAMARA should handle multi-SIM groups may become clearer.

[jlurien]

A problem is that probably we cannot generalize the concept of a primary or main device in a multi-SIM pack, as not all implementations support this concept, A MSISDN may be linked to several IMSIs without any hierarchy between them. Also, there is no a simple universal solution to identify several devices in a response in a way that is friendly to the client (e.g. smartphone, smart watch, tablet, etc), apart from the privacy issues that this kind of identification would imply.

[eric-murray]

@jlurien
Yes, I agree that some implementations of multi-SIM may make some use cases impossible for API providers that use these implementations. If the use case requires to locate an individual device, and a given device identifier (in this case MSISDN) is ambiguous, then that identifier cannot be used. Either another identifier (e.g. ip / port) or a new identifier (e.g. IMSI) should be used. But really this is something Commonalities and ICM should resolve, before pushing a solution to impacted APIs.

I'd recommend being careful to define API use cases around what an API consumer would find useful, and not around what all implementations can currently support. I don't really see the use case for locating a multi-SIM group as a whole, but that is for the sub-project to decide.

[bigludo7]

As discussed during Oct22th meeting, we still need to think about UC as location retrieval will be probably mainly used for non-personal device (for user-privacy reason). For IoT we do not have the question of multi-sim and if we have very few UC for location-retrieval and multi-sim this is perhaps a corner case for our API.

[javier-carrocalabor]

Assuming that we won't have changes in the interface of the output responses of the APIs, I agree that it is very difficult to have a unique and deterministic implementation for the MultiSIM issue.
Trying to document the scenarios and considerations we are addressing in this conversation, and similar to the considerations added for QoD here: camaraproject/QualityOnDemand#378 I suggest to generate some documentation like the following (just a proposal for DLVerification; DLRetrieval and Geofencing could be similar):

In multi-SIM scenarios, where more than one mobile device is associated with the phone number given as input in the API call (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device whose location is to be verified. Then, if the phone number is used as the device identifier, and assuming that the interface of the API only allows a unique response, there are three main options for the API to give as a response:

1. Return an error as multiSIM scenarios are not supported.
2. Return the verification just for the main SIM, in the case of such concept makes sense.
3. Return a value that combines the location verification of all the SIMs associated to the requested MSISDN. For example, a PARTIAL response calculating the overlapping between all the detected coverages of the SIMs and the requested area or providing a verification in case one of the devices fulfils the requirement of being in the requested area.

Applying just the first option is deterministic but misses some useful use cases. Additionally, this option potentially provides extra information about account nature, apart from the location information, that could be exploited by the developers.

The second one can be right in most cases but is not completely deterministic and can fail to verify the location of the intended SIM.

The third option don’t miss use cases, but there may be cases where the response is not useful (e.g. phone is in the area but a personal wearable is outside, so the user is indeed not inside the area, false positive).

An additional option is to apply one of those options depending on the type of addressed devices: for example, in the case of machine SIMs or IoT, it may make sense to leave the multiSIM issue as a corner case returning an error, and for residential SIMs a polygon containing all the coverages of the SIMs may be used to return a PARTIAL result.

The recommended ways to avoid this issue are:

• Using the authorisation code flow to obtain an access token, which will automatically identify the intended device.
• Identifying the intended device from a unique identifier for that device, such as its source IP address and port.
• Check with the SIM provider whether a unique "secondary" phone number is already associated with each device and use the secondary phone number to identify the intended device if available.

[javier-carrocalabor]

And this one is a similar proposal specific for DLRetrieval:

In multi-SIM scenarios, where more than one mobile device is associated with the phone number given as input in the API call (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device whose location it to be retrieved. Then, if the phone number is used as the device identifier, and assuming that the interface of the API response only allows one location, there are three main options for the API to give as a response:

1. Return an error as multiSIM scenarios are not supported.
2. Return the location of the main SIM, in the case of such concept makes sense.
3. Return a value that combines the location verification of all the SIMs associated to the requested MSISDN. For example, a polygon or circle containing all the detected coverages of the SIMs.

Applying just the first option is deterministic but misses some useful use cases. Additionally, this options potentially provides extra information about account nature, apart from the location information, that could be exploited by the developers.

The second one can be right in most cases but is not completely deterministic and can fail to verify the location of the intended SIM.

The third option don’t miss use cases, but there may be cases where the response is not useful.

An additional option is to apply one of those options depending on the type of addressed devices: for example, in the case of machine SIMs or IoT, it may make sense to leave the multiSIM issue as a corner case and return an error, and for residential SIMs a polygon containing all the coverages of the SIMs may make sense.

The recommended ways to avoid this issue are:

• Using the authorisation code flow to obtain an access token, which will automatically identify the intended device.
• Identifying the intended device from a unique identifier for that device, such as its source IP address and port.
• Check with the SIM provider whether a unique "secondary" phone number is already associated with each device and use the secondary phone number to identify the intended device if available.

[alpaycetin74]

It is possible to use variations of 422 error in this case.
If one simply wants to deny a response in a MultiSIM case (option 1):

If one wants to direct the API consumer to use other/more identifiers:

Having said that, I hope we have IMSI as an identifier in requests in the future. I understand it is a big change, but IMSI is a better identifier of a device imho, where an IP address may change when a device disconnects from the network for a moment.
If the API itself is data oriented , like QoD, yes IP address makes sense because the service must be provided to an IP address.

[bigludo7]

@alpaycetin74 but as far as I know an app developer cannot get the IMSI from iOS SDK no? (and probably same for android) so not sure how it can work.

Sorry if my question is a bit stupid but we have this question only if the call is done under CIBA flow? If we call the API under Front end auth code flow we should not have the issue as the device queried will be identified by the network...

[alpaycetin74]

yes, @bigludo7 , developers can't access IMSI on iOS. I forgot about that :(