PR incorporating the existing DRAFT proposal to simplify the device object and improve interoperability as per issue #171.
The solution proposed to be covered in the scope of this meta release was:
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.
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.
DISCLAIMER: The proposal is a minimum proposal that does not aim to solve all existing problems, and it is recognised that it does not cover all possible future use cases. However, in the context of the next meta-release, the two proposed measures could already be of great benefit.
Please find relevant context in #171
As agreed at the 10 June WG meeting, the DRAFT proposal has been included as an appendix to the API Design Guidelines for the time being. But we would need to decide what is the best place to document it. It could be as an appendix, in another specific document in the Commonalities, or even document it in ICM if the mechanism for relying on the access token is considered more appropriate for the ICM (e.g. in "CAMARA APIs access and user consent management" doc).
Changelog input
- Device object simplification
- Mechanism to rely on access token to obtain device information
What type of PR is this?
What this PR does / why we need it:
PR incorporating the existing DRAFT proposal to simplify the device object and improve interoperability as per issue #171.
Reference: https://github.com/camaraproject/Commonalities/issues/171#issuecomment-2129218755
Which issue(s) this PR fixes:
Fixes #171
Special notes for reviewers:
DISCLAIMER: The proposal is a minimum proposal that does not aim to solve all existing problems, and it is recognised that it does not cover all possible future use cases. However, in the context of the next meta-release, the two proposed measures could already be of great benefit.
Changelog input
Additional documentation
2024-05-23 - Commonalities Ad-Hoc Meeting - Device Object review