Do not _extract_ the device identification from the access token

[AxelNennker]

Problem description
The Appendix A: info.description template for device identification from access token contains text that gives the impression that some information can be "extracted" from the access token and that that information is therefore in the access token.

OAuth2, OIDC and Camara ICM do not specify the format of the access token. The access token can be self-contained and then would in fact contain said information or the access token is a reference to a database where the wording extract from the access token would not make much sense.

• The server will extract the device identification from the access token, if available.
• If the API request additionally includes a device object when using a 3-legged access token, the API will validate that the device identifier provided matches the one associated with the access token.

Expected behavior
Use language that does not suggest how access-tokens are implemented.

• If the API requires an device identifier, then the resource server obtains the device identifier associated with the access token.
• If the API request additionally includes a device object when using a 3-legged access token, then the API will validate that the device identifier provided in the request matches the one associated with the access token.

[jpengar]

I see your point... wording could be revisited if current description is misleading. The device identification can be derived from information associated with the access token. However, this information is not necessarily contained in the access token itself.

[eric-murray]

The came up for the Device Identifier API, and the proposed wording is now:

The API server will determine the mobile subscription identifier (e.g. phone number) from the access token itself if that information is associated with it (i.e. 3-legged token)

For that API, it is important to distinguish between the mobile subscription identifier and the physical device identifier, hence the quite specific wording. A more generic wording would be:

The API server will determine the device identifier (e.g. phone number) from the access token itself if that information is associated with it (i.e. 3-legged token)

[sfnuser]

There is an assumption on the association between the device and the 3-legged access token - it is that the telco provider needs to record or associate the physical device used to call the /authorize endpoint with the access token (though this may be inherently true in CIBA flows because of the login_hint mechanism). I don't think this is a standard OIDC requirement or it is mentioned in the CAMARA Security profile.

For e.g. can one use a web interface of an app (instead of native app) that uses QoD API from a desktop and get an access token assuming the front-end flow is enabled by the API provider? It is still a valid use case to request a QoD session for the mobile device by passing the device object.