camaraproject / DeviceIdentifier

Repository to describe, develop, document and test the Device Identifier API family
https://lf-camaraproject.atlassian.net/wiki/x/czLe
Apache License 2.0
2 stars 10 forks source link

Purpose of the `lastChecked` field in the response? #80

Open sfnuser opened 2 months ago

sfnuser commented 2 months ago

Problem description The definition and the purpose of the lastChecked field is not clear to me. The spec states Date and time the information was last checked - but checked by who?

I assume it is the last checked data (query) on the API provider side Network Function - If there is an expectation that there cannot be a synchronous device check for each API consumer request - how can a API consumer force a current status check? The spec states The Mobile Device Identifier API returns details of the mobile device (also know as the UE, or User Equipment) currently being used by a specified mobile subscriber.? Should there be a maxAge field in the request?

It does not make sense to assume that lastChecked field is associated to the API consumer side as they should already have this info.

Expected action Clarification on the lastChecked field in the spec.

eric-murray commented 2 months ago

The last time the information was checked by the API provider (i.e. the last time that IMEI was confirmed to be in use by the MSISDN). How they do that is up to them, Maybe the field could be renamed lastConfirmed.

If lastChecked equals (or is close to) the current time, then maybe it was a synchronous device identifier check. But there is always a risk that the end user has swapped the SIM to a new device since the API was called, which is why lastChecked is mandatory even for synchronous checks. It is not expected that lastChecked will be a long time in the past.

You can't "force" the API provider to actively interrogate the device to get the IMEI of the device the SIM is currently in. If a particular API provider is using an implementation that is returning very old data even for active SIMs, then the API consumer should complain that they need a better solution. Having a maxAge parameter will not solve the problem of bad implementations. If the API consumer uses old data, that's up to them.

My expectation is that the Device Identifier API will be used in conjunction with the Device Connectivity Status API. If the device is not connected, then probably asking for the IMEI will either give old data, or no data at all. The aim of the API is to provide the IMEI for connected devices. I think we should avoid specifying behaviour for devices that are not connected (such as specifying IMEI can only be returned for connected devices), so long as the lastChecked data is correct for any IMEI returned for a device that is not connected.

Note that the IMEI data itself cannot be "wrong" in the sense that the device is actually now being used by a different MSISDN on the same network. IMEI is personal data, and so if another MSISDN has started using that device, then that IMEI cannot be returned by the API for the old MSISDN. This is implicit by tying end user consent to the MSISDN. So if a very old IMEI is returned, the API provider is still confirming that the IMEI was used by that MSISDN and, as far as they know, the device is not now being used by another MSISDN.

Of the device was being used for a different network, then the API provider would not know this. This is the risk of storing such data for a long time and having no way for the end user to confirm it is still their personal data. It's certainly not how Vodafone are implementing the API.

eric-murray commented 1 month ago

@sfnuser Based on my comments above, do you want to propose updated documentation and/or a modified field name for the lastChecked field? If so, can you open a PR? Thanks.