Get Device Identifier without exposing the phone number

[HuubAppelboom]

In one of the discussion we have with potential customers for the Device Identifier, the question was raised whether it would be possible to use the API without using the phone number as an identifier. Background is that some customers are not interested in knowing the phone number, but just the IMEI, to keep the processing of personal data as limited as possible.

Can we use the front end flow for this ??

And the client credential (or CIBA) flow for cases where the phone number is known and has been verified already ??

[eric-murray]

I think this will follow automatically once the Identity & Consent procedures are finalised. My expectation is that the request body will be removed completely (with GET replacing POST) and the end user identified from the access token. This would work for both front end and CIBA flows. I'm waiting to see if that is the approach that will be adopted generally. Even if the request body is kept, the MSISDN specified there should be ignored in favour of that associated with the token.

Note for CIBA that the MSISDN is not "verified" as such. The API consumer requests an access token for a specified MSISDN and, if the end user has agreed that their IMEI can be provided to that API consumer, then they get it. But the device itself is not involved in that flow at all.

[HuubAppelboom]

I think the CIBA flow is less usefull for an application where you try to blacklist devices, because in that case you would require the msisdn to be verified, and in the end you will be using for example a number verify frond end flow just to do that anyway.

I spoke with number of potential customers today (for such a blacklist), but a lot of them currently don't store verified phone numbers, and in terms of privacy, it would also be a good idea if they are not forced to process the msisdn (also not for routing purposes). Hence I currently think that probably the front end flow may be the best choice, in combination with a routing to the right MNO based on mobile network code and/or ip address. However, this currently only works well (seamless) for smartphone apps today. For websites and wifi you will need to acquire the msisdn (or ask users to switch wifi off).

[eric-murray]

OK. As long as the flow is initiated by the device itself over the cellular connection (connecting to some application server) and it will process re-directs, then learning IMEI without requiring or learning MSISDN will work.

But note that the possibility exists to identify the device by its IP address. So the application server could call the API itself using the CIBA flow, providing IP address and port in the login_hint. That would work for any device that can send data to the application server. Main drawback of CIBA is that you cannot collect end user consent via a popup if you do not already have it. The end user must have already consented.