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

[jlurien]

To me it is applicable to Device Location what is being proposed in camaraproject/Commonalities#233, as Device Location APIs will likely be used in 3-legged mode as they are very privacy sensitive. That would imply making device optional. The deprecation of networkAccessIdentiifer makes sense unless some implementation sees a use case for it in the short term. In the future we may need to consider other type of identifiers for IoT devices or similar.

[JoachimDahlgren]

In the work group meeting today we agreed that in case a three legged access token is provide the device object could be optional. After reading https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#user-authenticationauthorization--consent-management it looks like the three legged access token will not be enough in what will probably be one of the most common use cases when it comes to location services.

The three legs are as described in above document to represent the three involved parties: user (the resource owner), authorization server (operator, i.e. service provider), and the client (third-party application). I then assume that the user (set as sub in the example flows) is what should replace the Device object.

Let me give you an example: My daughter has a smartphone and I am paying for the subscription. My wife has installed an application on her phone which will enable her to see the location of family members. My wife now wants to add our daughter as a family member. As our daughter is under age I will be asked to approve of her being tracked.

When reading the CIBA flow the backend-app would enter a login-hint to the API exposure platform. If this login hint should identify the resource it requests access to, it will be the phone number of our daughter. Using this information the Consent Master (operator) is to check consent. What I feel is missing in this flow is information about that it is my wife that is requesting access. I would never give consent in such situation unless I knew which person is asking.

[jlurien]

Your example assumes that the operator knows who is using each of the lines under your contract and other characteristics (who has to provide consent for what, etc), The owner of the resource should receive a petition, such as "App {client_id} wants to access {scopes} for {login_hint} for certain purpose". But how you know that is your wife initiating the request is not in scope of the flow. In real life, if she knows that you have to give consent, she would need to warn you in advance.

[JoachimDahlgren]

See that is the problem. I will get asked to approve tracking of my daughter by an unknown application. In best case I recognize the application name. I will however not know who is the person using it.

As for my wife warning me. How would she even know that I need to provide consent? She is opening her app and ask to track her daughter. The app will not know who is the person to give consent (providing that information is probably not even allowed from a legal perspective).

This is a simple example. You could imagine cases when the consent giver is responsible of a multitude of devices and many people asking to track.

What I am trying to point to is that with location being sensitive information a three legged access token will only work properly when the application calling the API want to verify/retrieve the location of the device its application client is running on.

[alpaycetin74]

Is it clear from the descriptions how much is in the scope of the communication between systems, and how much is assumed to be handled "offline" by humans ? If the line is not clearly drawn, it may lead to inconsistent implementations.

[jlurien]

@JoachimDahlgren The situations you are commented are not related to making device optional or not in the API, they are related with the Consent Management and authorization flows that must happen prior to invoking the API. In your examples it is clear that the target device is your daughter's.

For sure you will not give consent to a petition you don't recognize. The problem is the same if your wife or the bank wants to track your location. You will be asked to provide your location to certain client and if you don't recognize the context of the petition you will reject it. That's why Apps usually inform the user about the process in advance, by means of UX, e.g. prior to asking for permissions in Android. In your example, your wife may be warned in advance that consent is required by the person or their legal responsible, or in case of error, she will know that consent is not granted.

[jlurien]

Completed in #228