Is the service API meant to validate the content of the access token and compare this against the API parameters ?

[Elisabeth-Ericsson]

Problem description It must be clarified, whether (for security reasons) a service API should use and/or validate the content of the access token against the API input respectively be enabled to use the access token content for the API logic implementation.

For improving security and assuring that the correct access token is used for an API call, it is suggested that a service API can interpret the access token content (eventually after an access token introspection call to the AuthZ server) and apply validation against the input parameters of the API.

Example: the access token has been acquired for MSISDN A, which is also noted in the sub claim of the access token. The service API, e.g. SIMSWAP should be enabled to compare the input MSISDN B against the MSISDN retrieved from the access token and only proceed when the comparison is successful.

In addtion there is a connection to ISSUE #171 "Revise the device object definition to simplify it" from the communalities work group. In this issue the wrong assumption is taken that the device can uniquely be derived out of the content of the "sub" claim of the access token. The recommendation in issue #171 does not fit the needs of the QoD API.

So it is of utmost importance to clarify the content of the access token in detail (not the format though) to avoid misinterpretation.

Expected action 1) Clarify the content of the access token in the different scenarios (3-legged with different content of login_hint, 2 legged) 2) Clarify the recommended behavior of a service implementation

Additional context

[jpengar]

Yes, the API server is supposed to validate the content of the access token and compare it with the API parameters. For example, in Commonalities there is a whole thread dedicated to the error scenarios related to the device identifiers provided as API parameters, and among these error scenarios are those corresponding to the validation of the device identifiers against the access token. https://github.com/camaraproject/Commonalities/issues/127

IMHO, the information associated with an access_token (whether it is self-contained or not) is actually implementation dependent on the operator side. Each operator could associate different information depending on their own requirements, but the information associated with the access_token is transparent to the API consumer (access_token is opaque). It would be up to the operators to internally resolve how the API server can validate the information associated with the access token. This has also been discussed in https://github.com/camaraproject/IdentityAndConsentManagement/issues/100 and from the TEF side we have also provided some clarifications in https://github.com/camaraproject/IdentityAndConsentManagement/issues/100#issuecomment-1911161417. I don't think CAMARA needs to standardise the information associated with an access_token.

[Elisabeth-Ericsson]

Hi Jesus, I think that we are causing a severe problem here. The service APIs can be delivered by CSPs and by vendors. Thus it must be clear to the developers of the service API, what the access token contains and how this is to be interpreted. The fact that we do not give clear information about what is the content of the access token, especially how to interpret the content of the sub filed, causes a wrong assumption in the QOD Work group of CAMARA. They assume that they can derive the device out of the sub field of the access token and do not need a device object in the API call any more. This is wrong in general and causes misinterpretations. I think that we must take action and clarify to avoid such misinterpretations. I guess that it is not necessary to standardize all of the information associated with an access token. However, it would be good to clarify the content of some selected claims, especially "sub" and "scope".

[jpengar]

Hi Jesus, I think that we are causing a severe problem here. The service APIs can be delivered by CSPs and by vendors. Thus it must be clear to the developers of the service API, what the access token contains and how this is to be interpreted. The fact that we do not give clear information about what is the content of the access token, especially how to interpret the content of the sub filed, causes a wrong assumption in the QOD Work group of CAMARA. They assume that they can derive the device out of the sub field of the access token and do not need a device object in the API call any more. This is wrong in general and causes misinterpretations. I think that we must take action and clarify to avoid such misinterpretations. I guess that it is not necessary to standardize all of the information associated with an access token. However, it would be good to clarify the content of some selected claims, especially "sub" and "scope".

Yes, that is exactly what is proposed here https://github.com/camaraproject/Commonalities/issues/171. Actually, I see the ability to rely on the access_token as quite beneficial for 3-legged uses cases, as explained in that issue.

[AxelNennker]

Not sure how this works in the HomeDeviceQoD usecase.

The "user" authenticates and gives consent that API consumer may manage QoD at their residential wifi accesspoint. For which internal ip address is unknown the the authorization server, which means the API consumer can manage all internal devices, right? In that case there would be no check (possible) which device gets better QoD. What the AZ knows (probably) is the public ip address of the wifi accesspoint which is then configured.

The access token must contain information which device to configure and also for which other internal device the API is used. Is this correct and relevant to this discussion? Maybe I am missing something

[jpengar]

Not sure how this works in the HomeDeviceQoD usecase.

The "user" authenticates and gives consent that API consumer may manage QoD at their residential wifi accesspoint. For which internal ip address is unknown the the authorization server, which means the API consumer can manage all internal devices, right? In that case there would be no check (possible) which device gets better QoD. What the AZ knows (probably) is the public ip address of the wifi accesspoint which is then configured.

The access token must contain information which device to configure and also for which other internal device the API is used. Is this correct and relevant to this discussion? Maybe I am missing something

It does not apply as explained here https://github.com/camaraproject/Commonalities/issues/171#issuecomment-2133397200

[AxelNennker]

@Elisabeth-Ericsson would you please provide an example (use case) where the sub gets or could be misinterpreted misinterpreted? My try to come up with one failed.

[jpengar]

Hi Jesus, I think that we are causing a severe problem here. The service APIs can be delivered by CSPs and by vendors. Thus it must be clear to the developers of the service API, what the access token contains and how this is to be interpreted. The fact that we do not give clear information about what is the content of the access token, especially how to interpret the content of the sub filed, causes a wrong assumption in the QOD Work group of CAMARA. They assume that they can derive the device out of the sub field of the access token and do not need a device object in the API call any more. This is wrong in general and causes misinterpretations.

I think @eric-murray explains it much better than me here https://github.com/camaraproject/Commonalities/issues/171#issuecomment-2141501682

...with the current three-legged authorisation flows, only a single end user can be associated with the access token. For the OIDC authorisation code flow, only a single device can call the /authorize end point and get the code. And for CIBA, login_hint is currently restricted to being a single phone number or single IP address (+ optional port).

So basically the existing uses cases for Auth Code and CIBA will result in a 3-legged access_token that would allow operators to identify the device. Please keep in mind that we are talking for the scope of the next meta-release, as explained in that Commonalities issue. We will need further discussion for other potential scenarios we may have in the future for next releases.

[eric-murray]

CAMARA do not need to make normative statements about the access token. An access token accepted by an API implementation will also have been issued by that implementation, and hence the API provider should understand how the access token is to be validated and interpreted without any format or content requirements being imposed by CAMARA.

In the case that the API provider has outsourced implementation of the authorisation server and service API to different organisations, and these organisations are unable to communicate to agree how the access token should be generated and processed, well that is a problem for the API provider to sort out, and not CAMARA.

However, it might be useful to provide some end-to-end examples of transparent (e.g. JWT) access token use for calling CAMARA service APIs to help clarify the intended information flows and processing steps, particularly around identifying the end user. These could be added to the exiting ICM Examples document.