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.

@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.

@sfnuser
I created PR #88 to improve the description for the lastChecked field. Let me know if you have any comments.

@eric-murray: Apologies. I missed to follow-up this thread.
Thanks for the clarifications. I have approved the PR.