Problem description
@HuubAppelboom raised an issue in today's SimSwap... - meeting

@HuubAppelboom raised a good point about potential use of SIM swap to perform a numberVerification

If the parameter phoneNumber is present and the phoneNumber is also in the access token, then SimSwap might also accidentally implementing NumberVerification because if the values do not match the result of the API request is different to when the values match.

This problem exists for APIs where identifying information is available in several places.

This leads to several topics worth considering:

• APIs are not "atomic"
• Privacy considerations because an API (e.g. SimSwap) is leaking information
• Legal considerations because API access was granted for one "purpose" which might might match or might not match the "emulated" API access
• Business implications because clients who bought one API (e.g. SimSwap) do not need to buy the emulated API (e.g. NumberVerification)

Expected behavior
API Design Guideline should make API designers aware of this problem and provide guidance on how to handle this.

e.g. add guidance e.g. to the API Design Guidelines' Security section like the following sentence
If identifying information is both available in a request parameter and in the access token then the resource server MUST ignore the request parameter. No error should be returned if information from the access token and information from request parameters are inconsistent or contradict each other, because the error message is doing the leaking of information.

ICM could also or additionally put some text into info.description?! @jpengar

Aditional Context

regarding device object:
camaraproject/DeviceLocation#201