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.