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.

[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.

[AxelNennker]

There were various reasons why we decided to limit the endpoints to have a single scope,

Which reasons would that be?

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.

I think that scopes do not violate the ICM "rule"

• openId:
  - device-identifier:retrieve-identifier-imei
• openId:
  - device-identifier:retrieve-identifier-imeisv
• openId:
  - device-identifier:retrieve-identifier-ppid

The above means that one of the scopes must be associated with the access token for access to be granted.
The resource server then retrieve all the scopes associated with the access token and puts those values into the response.

[eric-murray]

It was discussed in Issue #30

Other factors were:

• Complexity in implementing scope-dependent logic and response formatting
• Difficulty in defining scope-dependent response body schemas in OAS
• Simpler to split YAML into multiple files if separate endpoints are defined for each use case

[AxelNennker]

* Complexity in implementing scope-dependent logic and response formatting

Every off-the-shelf OpenId provider does that. The complexity is low to non-existing.

* Difficulty in defining scope-dependent response body schemas in OAS

200RetrieveIdentifier basically stays the same.

* Simpler to split YAML into multiple files if separate endpoints are defined for each use case

Using scopes is simpler. The current two endpoints are confusing because the API consumer can get every thing in "/retrieve-identifier" and a subset of the fields in "/retrieve-type". One endpoint returning one subset of attributes and the second using a different subset, seems quite random.

The second endpoint "/retrieve-type" can be removed.

Using scopes simplifies the API and every OpenId provider does this simple thing out-of-the-box.

[eric-murray]

Every off-the-shelf OpenId provider does that. The complexity is low to non-existing.

I'm pretty sure that "off-the-shelf" OIDC implementations will not give me an implementation of the Device Identifier API. What they will do is allow me to retrieve a list of scopes associated with the access token, and pass that list to my micro-service implementation. But then my implementation needs to parse that scope list and construct the API response accordingly.

That, by any definition, is an increase in complexity.

If an endpoint only has a single scope defined for it, then the very fact that the API gateway has passed the request on to the micro-service means that the defined scope MUST have been associated with the access token. So the micro-service does not even have to check the scopes in that case. So single-scope endpoints are much simpler to implement.

[AxelNennker]

Standard OIDC providers can handle the OIDC standard claims/scope e.g. email and profile
MobileConnect defined their own claims and scopes. I assume that operators who participated in MC know how to handle new scopes. I think "simpler" is not the point. Implementing scopes is simple enough and has the advantage that the API consumer can asked for what they need and not got a bunch of attributes the API provider happen to have in their customer database or not.

"claims" / scopes is the OIDC way to do this and to allow data-minimization.

[eric-murray]

Standard OIDC providers can handle the OIDC standard claims/scope e.g. email and profile
MobileConnect defined their own claims and scopes. I assume that operators who participated in MC know how to handle new scopes.

I'm not clear on your point. CAMARA has also defined plenty of new scopes that need to be implemented. That is not the issue here. In any case, the Mobile Connect approach of having multiple scopes per (single) endpoint was explicitly rejected by CAMARA.

Implementing scopes is simple enough

You're missing the point. Defining multiple scopes that are valid for an endpoint is indeed simple enough. Processing all these different scopes to produce the expected API behaviour for the different possible combinations is where the complexity arises. For single scope endpoints, the implementation logic does not even need to be aware of scopes.

... a bunch of attributes the API provider happen to have in their customer database or not.

It's explicitly stated in the documentation that TAC processing that manufacturer and model would come from the GSMA IMEI database. It is not data the API providers themselves would store. API providers can chose to query this database and return the values as a courtesy to the API consumer. Or they can decide not to do this.

That is why they are optional parameters - because support for then may not be implemented. If separate scopes were defined for each parameter, then effectively it is mandatory for an API provider to support them. Many would not agree to this, and so the parameters would need to either be removed, or moved to a separate and optional endpoint.

In any case, manufacturer and model can be queried knowing tac, and there are free services on the internet that allow this. By agreeing to share tac with the API consumer, the end user is effectively also agreeing to share the manufacturer and model if the API provider also wants to provide that information.

... to allow data-minimization

The response fields are hierarchical:

• IMEI can be derived from IMEISV
• TAC can be derived from IMEI
• Manufacturer and model can be derived from TAC (via GSMA database)

The API consumer may not need to know a specific parameter, but not providing it explicitly does not mean they are unable to derive it for themselves. An end user agreeing to share their IMEISV cannot claim they did not want to share the TAC. An end user agreeing only to share their TAC cannot claim they did not want to share the name of the device manufacturer.

[eric-murray]

200RetrieveIdentifier basically stays the same.

But that's the point. OAS does not offer any way to capture scope dependent behaviour of an endpoint other than through documentation, which is imprecise at best, and of no help to code generators. If an endpoint is single scope, then it is clear that that scope offers access to the full capabilities of the endpoint.

[AxelNennker]

Probably I do not see the point. I ran openapi-generator-cli generate -i device-identifier.yaml -g java on both branches and for the API consumer the change is not significant.
For both yaml files the code generator created a RetrieveIdentifier200Response.java
Maybe you mean the server-side code generator. Is the "no help to code generators" problem there?
I assume the generated server stub is prepared to use the same RetrieveIdentifier200Response.java class.

[eric-murray]

Probably I do not see the point. I ran openapi-generator-cli generate -i device-identifier.yaml -g java on both branches and for the API consumer the change is not significant.
Maybe you mean the server-side code generator. Is the "no help to code generators" problem there?

How does the API consumer know how the API behaviour will change dependent on the scopes attached to the access token? It is not "codified" by the OAS definition. They can only know this from documentation.

To give a concrete example, let's say the endpoint has two available scopes - device-identifier:retrieve-identifier-imei and device-identifier:retrieve-identifier-tac. The API consumer knows that the response is scope dependent, but how does the response change with scope? How do they know that, if scope device-identifier:retrieve-identifier-imei is present, then the response will contain the parameter imei, and similarly if scope device-identifier:retrieve-identifier-tac is present, the response will contain tac?

They can only "know" from documentation. You may claim "it's obvious from the scope names". But then you would be missing the point that the documentation has been embedded in the scope names. The requirement that, if a specific scope is present, then a specific parameter MUST be included in the response cannot be codified using OAS.

It can be captured somewhat by the test definitions, but these are so abstract as to be little better than documentation.

[eric-murray]

Using scopes is simpler

It has been discussed several times in CAMARA, and the preference of API consumers (application developers) was for "atomic" APIs that do one thing, rather than "multi-purpose" APIs that can do several dependent on the parameters (including scopes) passed.

In this case, there is not that much difference between the two existing endpoints, but they cover different use cases. An application developer is likely to be interested in one or other use case, which will determine which endpoint they use, and which scope they need the End User to agree to.

Also, by splitting the use cases into different endpoints, it is easy for an API provider to remove endpoints they have not implemented. If there is an issue with not fully implementing a given YAML, then we will split into different files, but we do not need to do that yet.

[AxelNennker]

Then API consumers (application developers) might also want an endpoint that give them name and address.
And another endpoint that give them idDocument and IMEI
And another endpoint that ...

An "atomic" API is good, I agree. But for KYC we end up with too many combinations.
Also, as an application developer I want to know upfront, if possible, which attributes are available. DT e.g. does not have idDocument. Using scopes and fixing the scopes at API consumer onboarding time fixes this.
I heard that in Greed the end-users-tax-id is required before a prepaid sim is activated.
We could have tax-id in Greece in KYC and agree on that at onboarding time. Maybe...

[eric-murray]

My only comments here are:

• The Device Identifier API is not a KYC API and not intended for KYC use cases
• KYC Fill-In and Match have defined single-scope single-endpoint definitions, in spite of the many different and unrelated parameters that might be matched or filled in
• Device Identifier currently has two single-scope endpoints, which cover separate use cases. Developers would use one or the other.