API design guidelines - Appendix A - Misleading description of User being identified

[JoachimDahlgren]

Problem description
The API design guidelines - Appendix A misleads the reader to believe that a three legged access token, a "device object" or a "phone number" identifies a "User", when the only thing the three legged access token, the "device object" or the "phone number" provides is a key that can be used to get resources or take actions related to the usage of a device associated with an MSISDN.

As the appendix reads today it is likely that "User" is interpreted as "End User" (defined as "the human participant using an Application on a Consumption Device").

Expected action

1. Do not use the word User in the Appendix.
2. Explain that a "device object" or "phone number" does not identify a user.
3. Clarify that no " human participant" is being identified and that there is no way to know if one or many "human participants" is using a device associated with an MSISDN and that there might also be multiple devices associated with one an the same MSISDN.
4. Clarity that it might not be the same entity that is generating data associated with an MSISDN that is the entity giving consent to an application to use the same data ( a child might be using a device but it ought to be the parent that give consent).

[eric-murray]

From ICM Glossary of Terms and Concepts:

Resource Owner or User: the End-User or Subscriber which Personal Data processed by a CAMARA API relates to, the Resource Owner has the authority to authorize access to CAMARA APIs which process Personal Data.

So a "User" may be, but is not necessarily, an "End User". However, to say that a person CANNOT be identified from a phone number or IP address is nonsense. GDPR and similar legislation is quite clear on this point.

[JoachimDahlgren]

It is as you say absolutely clear that phone number and IP address in GDPR and similar legislation is seen as sensitive and personal information and that if you know the MSISDN or IP used by a person you will be able to track and collect a lot of information.

That however is not the same as saying that an MSISDN or IP address on its own will identify a person. You need other data as well to do such correlation. Especially you will not be able to find out who at this moment is using a device tied to a specific MSISDN or IP address.

[eric-murray]

That however is not the same as saying that an MSISDN or IP address on its own will identify a person.

No, but it WILL allow the API provider to identify a "User" (as defined by CAMARA) from the access token, and there WILL be a person associated with that "User identifier". The text does not claim that the API consumer can identify the User from the access token (nor, indeed, from the ID token).

If the issue is the definition of or use of the term "User", then you need to try and change that in ICM.

[JoachimDahlgren]

The text does not claim that the API consumer can identify the User from the access token (nor, indeed, from the ID token).

Well the appendix title reads "template for when User identification can be from either an access token or explicit identifier" and the first sentence state "When an API requires a User to be identified in order to get access to that User's data (as Resource Owner), the User can be identified in one of two ways:"

The ICM definition of User is for that matter also a bit unclear. First it states that Resource Owner and User is the same concept. Then it states that it is "the End-User or Subscriber which Personal Data processed by a CAMARA API relates to". But if I use that definition and the definition of End User and do a search and replace in appendix A I would get the following rather different versions of Appendix A

• Resource Owner identification can be from either an access token or explicit identifier
• Subscriber identification can be from either an access token or explicit identifier
• End User identification can be from either an access token or explicit identifier
• human participant identification can be from either an access token or explicit identifier

The first two I find somewhat reasonable. The last two I find misleading as I stated in problem description above.

[eric-murray]

The text does not claim that the API consumer can identify the User from the access token (nor, indeed, from the ID token).

Well the appendix title reads "template for when User identification can be from either an access token or explicit identifier" and the first sentence state "When an API requires a User to be identified in order to get access to that User's data (as Resource Owner), the User can be identified in one of two ways:"

But none of that text says that the API consumer can learn who the User is from the API provider, only that the API provider needs to know this, and can learn from either the access token or an explicit identifier provided by the API consumer

End User identification can be from either an access token or explicit identifier

If the Subscriber is also the End User (not an unlikely scenario), then the End User will be identified by the access token or explicit identifier. The text in Commonalities does NOT say or imply that the End User WILL be identified by the access token or explicit identifier, only that they MAY be identified by such, which is entirely true.

human participant identification can be from either an access token or explicit identifier

ICM define "End User" as "the human participant", so they are the same thing