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 QoD 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.
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.
- We may also try to define some specific behaviour for this service, such as applying the service to a default SIM id providers have this concept (but this may not be a universal solution).
- 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.
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 QoD 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.
Alternative solution