Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Purpose of the lastChecked field in the response? #80

Open
sfnuser opened this issue Aug 14, 2024 · 4 comments · May be fixed by #88
Open

Purpose of the lastChecked field in the response? #80

sfnuser opened this issue Aug 14, 2024 · 4 comments · May be fixed by #88
Labels
documentation Improvements or additions to documentation

Comments

@sfnuser
Copy link
Contributor

sfnuser commented Aug 14, 2024

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.

@sfnuser sfnuser added the documentation Improvements or additions to documentation label Aug 14, 2024
@eric-murray
Copy link
Collaborator

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
Copy link
Collaborator

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

@eric-murray eric-murray linked a pull request Dec 5, 2024 that will close this issue
@eric-murray
Copy link
Collaborator

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

@sfnuser
Copy link
Contributor Author

sfnuser commented Dec 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants