Simplification of Device object - short term solution

[rartych]

Problem description

Commonalities discussed the topic and proposed the short term solution (for the coming meta-release) summarized in camaraproject/Commonalities#171 (comment) :

• 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. camaraproject/Commonalities#171

Alternative solution
Review the PR related to camaraproject/Commonalities#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: camaraproject/Commonalities#171 (comment)
Dedicated meeting summary:
https://wiki.camaraproject.org/display/CAM/2024-05-23+-+Commonalities+Ad-Hoc+Meeting+-+Device+Object+review

[hdamker]

For the attention of @camaraproject/quality-on-demand_maintainers

[RandyLevensalor]

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

This doesn't account for instances where the access_token applies to multiple devices. While this approach may cover some use cases, it doesn't cover all scenarios and could cause extra complication instead of simplifying the device identifier. Standard error handling, such a returning a list of all devices associated with the access_token along with unique identifiers could resolve this.

My earlier comment to this effect in the commonalities thread. camaraproject/Commonalities#171 (comment)

[sfnuser]

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

This doesn't account for instances where the access_token applies to multiple devices.

Could you please share the use case where 3 legged flow is used to get the access_token but it is also applicable to multiple devices (I assume by devices you mean device object identifier - e.g. msisdn, ip, network access identifier). The sub field of access_token uniquely identifies the End-User (OIDC)

[eric-murray]

My concern is that I cannot get a 3-legged access token if I only know the public and private IP address of the device, because this is not a login_hint option. So I would need to know some additional information about the device (e.g. MSISDN, or public port) to get the access token. Effectively this proposal rules out identifying devices by public and private IP address unless 2-legged access tokens are allowed (in which case the "optional" device object can be provided).

Why is this an issue? Because the public and private IP addresses can be mapped directly to parameters for the call to the NEF, whereas the access token, or identifiers that can be associated with the access token, cannot. So ruling out identifying the device by public / private IP addresses makes the implementation more complex.

I'd be happier with this proposal if login_hint supported identifying the end user by public and private IPv4 addresses.

[jlurien]

Not all 3-legged access tokens may identify always a single device, so we cannot simplify it as "do not send device when using a 3-legged access token". But there are authentication flows already specified for CAMARA where it is known that a single device is identified. Rules should make these scenarios clear, so developers in that situation can benefit from the simplification. For other scenarios, developers will have to include device, as now.

The case that @eric-murray points out for public and private addresses, is one of the latest. While passing an public_ip and port, or a phone number is covered. It would be a discussion for ICM if adding the case for public and private addresses in the login hint is an option to cover it as well.

Regarding the removal of networkAccessIdentifier, we still don't have a use case for it, so we are in favour of removing it.

[hdamker]

Discussion results from https://wiki.camaraproject.org/display/CAM/2024-06-14+Quality+on+Demand+-+Meeting+Minutes:

• Device object will be made optional, but we need to document the cases in which it can be omitted by the API consumer, and it which cases the additional information from device object is needed
• NAI might be needed for IoT device cases (which have no MSISDN assigned) - but that is a general decision for the project, not specific to QoD

[hdamker]

camaraproject/Commonalities#233 has been merged and will be part of Commonalities v0.4.0, therefore we need to adapt the quality-on-demand.yaml accordingly:

• make device object optional
• add the recommended documentation

[hdamker]

Closed by creating #313