search

camaraproject / APIBacklog

Repository to maintain the API Backlog for CAMARA.
https://wiki.camaraproject.org/x/I4tF
Apache License 2.0
5 stars 13 forks source link

Device Identifier API Proposal #11

Closed eric-murray closed 1 year ago

eric-murray commented 2 years ago

A proposal for a Device Identifier API has been uploaded here. Please add any comments you may have.

Unfortunately, I don't have permissions to add labels to this issue, so maybe somebody could do that for me.

jordonezlucena commented 1 year ago

@eric-murray:

eric-murray commented 1 year ago

@jordonezlucena

API consumers in this case might be insurance or content providers.

For example, an insurance provider might offer mobile phone insurance. When a customer calls up, they can determine via this API exactly what device they are using, provide an insurance quote without asking the customer for more details about the phone, and then tie the insurance directly to the IMEI. And when the consumer calls up a week later and says that they have lost their new iPhone 13, and it turns out that is exactly the device they are calling from, well then they can use the API for fraud detection.

Another example would be content delivery. A streaming content provider might like to determine the size and resolution of the screen being used by a customer who is not using the content provider's own app (for example, the consumer is using a web browser or some other 3rd party app). Knowing the phone model being used by the customer would help them estimate this.

I expect "device manufacturer" would be largely be used as a proxy for OS, but there will be other use cases. But I would let the API consumer make the association between manufacturer and OS ("Apple" = "iOS", "Samsung" = "Android") because this is not 100% reliable and it might look like we know more than we do if we offer that association. Determining the manufacturer from IMEI should be reliable when it works, though not all IMEIs are registered to known manufacturers.

IMEI is available from the Sh interface. I don't know about the SCEF/NEF.

miguel-garcia-ericsson commented 1 year ago

I think it should always be possible for the API consumer to receive the IMEI(SV). And it may be optional for the core network to deliver the manufacturer and device model, if it can be determined from the IMEI(SV).

But the OS is something that is more difficult, I don't think there is a reliable way to determine the OS of the device by just inspecting the IMEI(SV). If a user reflashes his device with a different OS, I think the IMEI remains, so I have doubts on the OS.

Regarding the SCEF/NEF, there is one Monitoring service that is able to inform the API consumer of a change of a SUPI-PEI (IMSI-IMEI) association. So this might be a good starting point for looking into delivering the IMEI to the API consumer.

eric-murray commented 1 year ago

@miguel-garcia-ericsson Thanks for your comments

IMEI(SV) is known to the core network, and all other information can be derived from this identifier. To derive the manufacturer and device model requires access to the GSMA IMEI Database, so would not be a capability of the core network itself. I would expect that this database could either stored directly in the API gateway, or accessed remotely possibly via a 3rd party service.

Providing this additional information would be part of the "value" added by the API as there are use cases where the knowledge of the device manufacturer and model is more important to the API consumer than the IMEI itself. Furthermore, privacy restrictions may prevent the full IMEI being given to some API consumers, but they could still be given the device manufacturer and model.

My proposal does not include returning an indication of the OS by the API. Rather, the API consumer themselves would be free to infer this knowing the device manufacturer and model. So that is one reason why the API consumer might request such information, and I would agree that the API itself attempts to infer the device OS.

jordonezlucena commented 1 year ago

Apart from MSISDN, we understand that IPv4 adds might be also possible for UE identification. The same rationale behind the new QoD version that has been issued as PR here: https://github.com/camaraproject/QualityOnDemand/pull/25 and https://github.com/camaraproject/QualityOnDemand/pull/24

eric-murray commented 1 year ago

@jordonezlucena Any means of identifying the UE would be acceptable, and UE source IP address / port is one option. In fact, all the UE identification methods recognised by CAMARA should be supported.

My expectation is that the major use case for this API will be when an end user makes a POTS call to a 3rd party who get their MISISDN from Caller Id, but of course there are scenarios where the end user is making a data call to an application server who may not know the MSISDN.

jordonezlucena commented 1 year ago

Hi, PR https://github.com/camaraproject/WorkingGroups/pull/79 has been merged together with the rest of API proposals. It will be sent out for SC approval by 13/10. If not approved, I will reopen this PR.