Simplification of Device object - short term solution

[Kevsy]

Problem description

(note: text below pasted from equivalent issue in Connectivity Insights/other repos)

Commonalities discussed the topic and proposed the short term solution (for the coming meta-release) summarized in https://github.com/camaraproject/Commonalities/issues/171#issuecomment-2129218755 :

• Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios.
• Remove the networkAccessIdentifier from Device object

Reviewing and providing the feedback on the impact of the proposed solution on this subproject was suggested by the TSC.

Possible evolution Review the proposed changes before Commonalities meeting on 10.06. https://github.com/camaraproject/Commonalities/issues/171

Alternative solution Review the PR related to https://github.com/camaraproject/Commonalities/issues/171 (should be created soon)

Additional context Initial proposal of text explaining using access token information to identify the target device of the API request: https://github.com/camaraproject/Commonalities/issues/171#issuecomment-2133228135 Dedicated meeting summary: https://wiki.camaraproject.org/display/CAM/2024-05-23+-+Commonalities+Ad-Hoc+Meeting+-+Device+Object+review

[javierlozallu]

@Kevsy I think this also affects to Traffic Influence and Endpoint Discovery APIs, as is being discussed on https://github.com/camaraproject/EdgeCloud/pull/119.

Basically we tend to agree that Device Object IP could be: "ipv4Address": { "publicAddress": "203.0.113.0", "publicPort": 59765 }

Apparently there is a meeting on 10.06 to conclude on the issue so I would be grateful if you could update us on the Edge Cloud meeting on 11.06.

[Kevsy]

Commonalities PR 233 was agreed and merged

This will be included in SED 0.11.0-alpha.1

[Kevsy]

Fixed in #30