Alternative device identifiers

[eric-murray]

• Can an alternative device identifier be returned that identifies the device to the API consumer, but cannot be used by any third-party to identify the device?
• Does the API consumer need to be able to derive the IMEI from this identifier, or just know that all devices with the same identifier are the same device?
• Do any existing device identifiers satisfy this requirement? Would hashing the IMEI with an API consumer salt be sufficient?
• How is any alternative identifier derived, and how is it used by the API consumer?

[Kevsy]

Can an alternative device identifier be returned that identifies the device to the API consumer, but cannot be used by any third-party to identify the device?

It could - i.e. an opaque reference that can only be resolved by the issuing operator.

Does the API consumer need to be able to derive the IMEI from this identifier, or just know that all devices with the same identifier are the same device?

I suspect to be useful we would want the latter - otherwise we would just use the IMEI.

Do any existing device identifiers satisfy this requirement? Would hashing the MSISDN with an API consumer salt be sufficient?

Not sure. What happens if the MSISDN is ported to another operator?

How is any alternative identifier derived, and how is it used by the API consumer?

For further discussion :) - by 'used' do you mean use case scenarios?

[eric-murray]

Not sure. What happens if the MSISDN is ported to another operator?

Sorry, that was a typo. Should have been "Would hashing the IMEI with an API consumer salt be sufficient?". I'll edit.

For further discussion :) - by 'used' do you mean use case scenarios?

Yes, I mean what is the use case for the device identifier information. For example, for insurance purposes, the insurance company may well require to know the IMEI. But for fraud detection, they may just need to know that the device currently being used by their customer is different to the one that they were using previously and had insured.

[HuubAppelboom]

In general , there are 2 kinds of applications for device identifiers. One is a blacklist (or a grey list) of devices that have been used by fraudsters, or devices that have been stolen. For these list to be effective, it is indeed required that multiple independent parties can work with such a list. For this, IMEI as a device identifier is more suitable, although you run the risk that these IMEI's can be abused to track and trace people. Probably the only way to solve this is by having stringent rules on who can use this kind of information, which cases are approved, and to have transparency on both the legal basis for the use cases and who is using the data and for what purpose. For case of fraud consent will not work as a legal basis (because fraudsters will not give consent, and then you can not block access to a service), but only legitimate interest can be used. For ownership of devices and blokcing stolen devices, consent can be used as a legal basis.

The other main application is that of a whitelist of devices, ranging from a short list of devices that can be used by a specific user (as a possesion factor in authentication), to a list of devices which belong to trusted users. For whitelists of devices, an alternate device identifier can be much more privacy friendly, in case the identifiers are only relevant for a specific application (or service provider), and can not be used to track users across different applications. This alternate device identifier can for example be generated by hashing the IMEI in combination with a sufficient long Salt (which needs to be application specific), or the MNO can generate random identifiers and store there with the IMEI in a table for future lookup.

In this case of alternate identifiers, you probably also don't need to acquire users consent, because it is similar to the use of a functional cookie, which can be used without acquiring consent. The main advantage of such a white list based alternate device identifiers is that it can be made resilient towards factory resets of the device.

[nickvenezia]

So how can we help protect the personal data from bad actors? How would you combat marketplaces that sell identity resolution?

[nickvenezia]

@HuubAppelboom not just "resale" but "processes" the data of any EU citizen.

GDPR also has protection as the data flows "downstream".
Carrier >> Aggregator >> Developer >> Application.

What happens if the Developer has a third-party API integrated into the APP? Worst case that person is a bad actor?

[HuubAppelboom]

@nickvenezia Thats why there is a proposal for alternate identifiers. In this case, if there are two applications, the end user device has a different identifier for each application. Only the MNO knows the correlation between these two, nobody else.

[nickvenezia]

That sounds like a MAID.

Your suggestion of IMEI would allow all known device MAIDs, IP Addresses, AAID, emails, IDFA and more to be linked to that mobile number and IMEI.

IMEI is a persistent device identifier and would be the top level device identifier.

How would a user be able to delete the IMEI for opt-out requests.

Please, correct me where wrong.

[AxelNennker]

Technical solutions only get us so far. OpenId proposes pairwise-identifiers
https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
Which make it harder for 3rd-parties to collude and match identifiers for e.g. profile building - while opening up through the sector_identifier mechanisms that e.g. different 3rd-party apps from the same vendor get the same PPID.

So, technical proposals exist but in the end the law (e.g. GDPR) is what counts.

[eric-murray]

Hi @HuubAppelboom

So you discuss two (physical) device identifiers:

• IMEI, as already proposed / in-use
• Salted and hashed IMEI

My comments on the salted and hashed IMEI are:

• From a privacy / GDPR perspective, my understanding is that, if there is a one-to-one mapping between some identifier which is considered to be personal information and another identifier, then that alternative identifier is still considered to be personal information, no matter how useless it might be to anyone who knows it without context. It might simplify data security rules (for example, it is simpler to get approval to send a hashed MSISDN than a plaintext MSISDN), but it does not change the need to get end user consent.
• As an output from the device identifier API, it is only useful to tell the API consumer that the end user (identified by MSISDN) that the same or different device is in use compared to a previous request. What would be the use case here?
• As an input to the IMEI fraud API, then this would be useful to match the subscriber identifier (e.g. MSISDN) with the device fraud status without knowing the details of the actual device. Again, what would be the use case here, especially as it is unlikely that a specific MSISDN would be associated with a blacklisted device, as that device would not be allowed to connect to the network?

So currently I do not see value in using salted & hashed IMEI as an alternative device identifier, but am open to persuasion!

[HuubAppelboom]

Hi Eric,
From a GDPR perspective, there is also a legal basis that can be used for the processing of personal information which is called legitimate interest. Legitimate can and is often used in fraud prevention cases, and does not require explicit user consent.
In case of legitimate interest, you do need to make a documented balancing test, in which you can show that the interest of for example a company to prevent fraud outweighs the privacy impact of processing the personal data.
Now, if the device identifier is user-company specific, the device identifier can not be used for tracking users between different relying patties, which makes a large difference in the balancing test. You will still need to treat these device identifiers as personal information, with the same care and precautions, but in many anti-fraud cases you will be able these indentifiers without explicit user consent. This is very much the same as is with for example KYC Match and ATP is the case today, which are often processed on basis of legitimate interest. Hence, that is why a device identifier which is only relevant for the combination of user - relying party.

[HuubAppelboom]

The use cases you can think of for a "personal" device identfier can be to create a list of trusted devices, and use these as an authentication factor. For a blacklist this device identifier would be useless (because here you must be able to share the same device identifier with multiple parties), but for authentication purposes it would be much more privacy friendly.

[HuubAppelboom]

However, there may be alternative privacy friendly device identifiers already available in both IOS and Android that do the exact same thing, to be checked, In that case you may not be adding much value (except offering less dependency on the OS).

[eric-murray]

Hi @HuubAppelboom

So the legitimate interest test could be successfully applied to both IMEI and the salted / hashed version, though I take the point that it may be easier to get agreement for the salted / hashed version.

But what would be the ant-fraud use case here? If the API consumer wanted to check whether a particular mobile subscriber was using a device with a fraud marker, then the initial input to that check would be the subscriber identifier (e.g. MSISDN) rather than IMEI or salted / hashed IMEI. So the legitimate interest test would be applied to MSISDN in that case. Potentially the IMEI Fraud API could accept MSISDN as the input for that use case, thus avoiding the need to for the API to divulge any physical device identifier.

I can see that maybe the API consumer wants to track the "fraud history" of a physical device without knowing its true identity. In that case, the salted / hashed IMEI could be used, output once from Device Identifier and then used as an input to IMEI Fraud (maybe setting up notifications for any status change). But that appears an unlikely use case to me.

For authentication, I can see that knowing a mobile subscriber is using the same device as previously (or one of a set) without knowing the true identity of the device reduces the "personal information" content of the transaction. But, again, the input will be MSISDN (or some other subscription identifier), which is a way more sensitive personal identifier than IMEI will ever be. Also, there is a separate "Device Swap" API in progress, which will state whether the SIM has been recently moved to a new physical device without revealing the identity of the new device, and we should not try to duplicate that use case here.

[AxelNennker]

I do not see the difficulties with a salted/hashed IMEI as a PPID.

The API consumer opens the browser on the mobile device (on-net) for OIDC authorization code flow to get the access token for the API. The user authenticates e.g. with username and password to the API producer, then the user consents to API-usage by the API consumer. The authorization server uses whatever means (network authentication) it has to identify the subscription and "finds" the IMEI from the last network ATTACH for that subscription.
The browser is redirected with the code and the access token, which is associated to the subscription, is retrieved by the API consumer.
Then the API is called with the access token, the API provider finds the subscription data (IMEI) associated with the accesstoken, and the PPID is computed as ppid = SHA256(client_id | IMEI | salt) and the PPID is put into the response.

Yes, the PPID is still personal identifiable information, but it is better than IMEI because the PPID can't be used for tracking the user by colluding API consumers.

Please review https://github.com/AxelNennker/DeviceIdentifier/blob/pairwise/code/API_definitions/CAMARA%20Mobile%20Device%20Identifier%20API.yaml (not a PR yet). That Device Identifier API uses one endpoint and scopes to indicate what to retrieve e.g. ppid

[HuubAppelboom]

@AxelNennker @eric-murray In a technical sense, both are possible (IMEI as device identifier, and a salted/hashed IMEI as PPID).

In terms of privacy and legislation, there is another thing to consider besides the GDPR. We looked at it in more detail, and we think that in both cases the MNO is extracting information from a device. This falls under the ePrivacy directive in the EU, and as a consequence under the telecom laws of each of the EU countries. It is similar to cookies, as soon as you extract information from a device, you will need to acquire user consent (there is no legitimate interest construct in the ePrivacy Directive). This applies both to IMEI and PPID as identifiers, so this will be another bottleneck for many use cases.

In terms of privacy, PPID is indeed better, but it really depends on the use case whether PPID can be used, and whether the devcie information needs to be shared between multple parties (for example a centralized black list of fraudulent devices). In that case IMEI would be simpler to work with. PPID would be an option as well, but then the MNO's woud need to act as middle man for the ASP to access a centralized black list of fraudulent IMEI numbers. The ASP knows in that case only the PPID, and the MNO stores the IMEI on request of the ASP in a centralized blacklist.

[AxelNennker]

I started responding to the ePrivacy directive argument but I am not a lawyer, so I deleted my response. It would be good to have a legal-review.
I think consent collection is something we have to do for most Camara APIs anyway.

Not sure about the fraudulent devices use case. I remember that is already a difficult topic even with IMEI. Not sure whether Telcos really contribute to GSMA's IMEI blacklist.
I think for Anti-Fraud for Carrier Billing telcos are using the MSISND not the IMEI. For this use case we have legitimate interest, I think. Again a legal-topic.

I think PPID is better than IMEI and Device Identifier should offer PPID.

BTW, please add use cases to the use cases document...

[eric-murray]

I'm happy to support returning a PPID as an additional option to the two existing options (IMEI and TAC) if there is an associated use case.

We discussed before using scopes to control the output of a single endpoint, but rejected that in favour of separate endpoints. So introducing a PPID option would give us a third endpoint.

The two defined endpoints are currently "mandatory" (i.e. there is no 501 response defined to avoid implementing either endpoint). We would need to decide if this third endpoint was mandatory or optional for implementation. Although the concept of generating a PPID from an IMEI is straightforward, implementation is not trivial.

[AxelNennker]

We discussed before using scopes to control the output of a single endpoint, but rejected that in favour of separate endpoints. So introducing a PPID option would give us a third endpoint.

I only see pros when using scopes instead of endpoints.
The scopes for an API consumer are agreed upon at onboarding time and if the API consumer tries to get an access token that is not in the list of allowed scopes then they get an invalid_scope error from the authorization server.
No need for a 501.

Are the reasons for rejecting "scopes" in some other discussion? I did not find it https://github.com/camaraproject/DeviceIdentifier/discussions Or would you please repeat those reasons for the rejection, please?

I like the one-endpoint, scope-driven API better - obviously. Mainly for the reason I gave above (onboarding-time)
https://github.com/AxelNennker/DeviceIdentifier/blob/pairwise/code/API_definitions/CAMARA%20Mobile%20Device%20Identifier%20API.yaml

[eric-murray]

There were various reasons why we decided to limit the endpoints to have a single scope, but one is that only a single scope is allowed by the current ICM guidelines:

Generally, each operation is protected by a scope and it will include a security property with a single element in the array

At least this rule needs to be revised before we can re-consider multiple scopes being available for a single operation.

[HuubAppelboom]

This is very similar to a proposal that I have made for the Netherlands, to create a database with suspicious devices, but where users can't be linked. There is however one issue that needs to be adressed, and that is that you don't want it to be traceable when somebody sells their phone to somebody else. So the PPID would need to be unique for a user, for example by storing the IMEI-MSISDN combination.

[HuubAppelboom]

But if you make the device identifier completely privacy friendly (ie. the PPID is unique for the combination of ASP and end user), it will not work for certain use cases.

For example, In the Netherlands we have fraud with anonymous prepaid SIMs. What the scammers do is each they open up a new gmail account, take a fresh prepaid card from a stack, and start opening up accounts on platforms where they start advertising for goods. People pay for the goods, but they are never shipped. This kind of fraud can be stopped by sharing IMEI's (you can block their handsets when trying to register), but not by a privacy friendly PPID which depends on the phone number (in case of anonymous prepaid). Hence my point that there is market demand for both solutions.

[AxelNennker]

I guess scammers are always going to find ways to trick people.
And people are always going to ignore warnings from platforms that the seller's account is new, has no recommendations from happy buyers, etc.
Sounds like the proposed tenure API would provide input for platforms to fight the scam you are describing.
I think IMEI sharing between platforms is the wrong tool to fix the scam problem. And too privacy invasive.

[HuubAppelboom]

Tenure is one thing you can use with this kind of fraud, but in the end a solid device recognition can be much more effective, because it has a much bigger impact on the business case of the scammer. What you see in most cases that there is no single bullet, and that you may need multiple data points to come to an effective and efficient solution. Regarding the privacy aspects, and the worry about tracking: please don't forget that the phne number is already a data point that can be abused for tracking, and that there are also non-technical measures that you can take to avoid this kind of abuse, like a thorough screening of use case, auditing customers, etc.

[AxelNennker]

Regarding "phone number is already a data point", the API consumer does not necessarily know anything about the phone number in many Camara API, because the user authenticates and gives their consent and then the access token is opaque to the API consumer and the API Producer retrieves the subject associated with the access token and returns the API's response, without revealing anything else about the device, subscription and user.