2024-05-23 - Commonalities Ad-Hoc Meeting - Device Object review

Attendees & Representation

LF Staff:

Community:

Agenda

• Discuss Issue #171 on how to simplify the existing Device Object definition so that it is fully supported by all implementations and/or provide mechanisms to make it interoperable and usable by developers.

Minutes

- Jesús/TEF explains the current situation regarding the device object in the CAMARA APIs and describes the proposals raised in issue #171.

- Randy raises the need to cover scenarios of fixed networks and/or data-only devices (e.g. WiFi-only devices) where phoneNumber/IMSI would not always be possible to use. He suggests using something "broader" like network/IP addresses.
- Tanja suggests that networkAccessIdentifier might be best for this "generic" identifier.

- Mark mentions the possibility of having a "standard identifier" and talks about UID2.0 (https://iabtechlab.com/tech-lab-update-on-uid2-0/). The possibility of getting this UID2.0 token in exchange for some other known identifier. 

- Diego raises the issue of interoperability. It's clear that we can't just rely on phoneNumber. And we may have a shorter or longer list of identifiers to cover the required scenarios. But rather than looking for a "universal identifier", Diego reinforces the message that TEF focuses on in #171, that we need to mandate the implementation and support of a set of identifiers if we are to ensure interoperability. And at the moment, we are not mandating support of the defined identifiers on the server side. So the suggestion is to shorten the list and identify what needs to be implemented. He suggests to focus the discussion on the fact that we need to come up with a solution that fixes interoperability and guarantees global implementation of an API.

- Jesus points out that if we want to have a solution to improve interoperability and simplify the definition of device object for the next meta-release, we need to focus on the scenarios that we are currently covering in CAMARA and in the existing APIs, because we are discussing some scenarios that we are not even covering now. And maybe it should be a separate discussion to consider as an enhancement for future releases.

- Shilpa agrees that for the Fall24 meta-release we can be more restrictive, perhaps excluding identifiers such as networkAccessIntifier if it is not used by operators yet, and then raise another issue later to start discussions for future releases.

- Tanja says they are looking at networkAccesIdentifiers. Jesus says that we need to hear from other operators to be sure that this identifier is not being used.

- Randy says that for this release we can focus on interoperability and reduce the number of identifiers that need to be supported and look at other identifiers for future use in future meta releases. Jesus agrees.

- Jesús makes a specific proposal for the next meta release:
    1) Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios. This would fix interoperability in all these scenarios, which is a huge improvement. We can define the device identifier as optional in the API specification and, if not provided, simply refer to access_token. The developer would simply not provide any further device information, which is simpler. The operator does not need to check that the device identifier actually matches the access_token provided and could simply rely on the access_token itself.
    2) Validate the current situation among operators regarding the support and use of the networkAccessIdentifier in order to agree on the removal of this identifier for this meta-release.
At least these two points would be a big improvement over the current situation. To cover all 3-legged scenarios, and in other cases where it is necessary to explicitly provide the device object in the request (such as 2-legged access with client credentials), we would have a smaller set of identifiers that would mitigate the problem a bit. So far, the APIs we are discussing (Device Location family, Device Status, Quality On demand) are mostly consumed with 3-legged access_tokens.

- Fabrizio is fine with the proposal, but he would like to see documentation on how to rely on the access_token from a developer's point of view. It may be necessary to document it in the API specs so that developers can understand how it works.

- Jesus asks participants to call if they agree with the previous proposal to be the candidate solution for the next meta release, it will of course be written up and described in issue #171 for further review and comments.

- The proposal makes sense to Shilpa, and she suggests setting a deadline for people to object or respond to the proposal. But if we want to finalise a solution for the next meta release, we need to have a deadline.

- It is agreed to set the end of next week (31/05) as the deadline to agree on the solution.

- Rafal follows Fabrizio's suggestion to create a description of how the solution would work from a developer's point of view to be included in the YAML spec files (Tanja suggests using the info.description field).

AOB

N/A

Action items

• Jesús Peña Create meeting notes in CAMARA Confluence and link them in #171
• Jesús Peña Document simplification proposal for next meta-release in #171
• Jesús Peña Include in #171 the agreed deadline (end of next week - 31/05) to provide feedback on the simplification proposal
• Jesús Peña As per request of Fabrizio Moggio , include a comment in #171 pointing reviewers to existing CAMARA API Specs already delegating to the information associated to the access_token
• Jesús Peña Make a text proposal for the API specs, aimed at the API consumer, on how the access_token delegation mechanism would work