Proposal: Add IMEI boolean match endpoint to Device Identifier API

[albertoramosmonagas]

Problem description
The Device Identifier API in CAMARA currently exposes retrieve-type operations (e.g. retrieve-identifier, retrieve-type and retrieve-ppid) that return detailed information about the device (IMEI/IMEISV/TAC), derived attributes or pseudonymous identifiers (PPID).

However, in many use cases (fraud prevention, device-based KYC, account takeover protection, digital onboarding, etc.), partners do not need to know the device identifier itself nor a reusable PPID. They only need to know whether the device they provide in their business flow matches or does not match the device that the network currently associates with that subscription.

This creates two issues:

1. Unnecessary data exposure

   • Returning IMEI/IMEISV/TAC or a PPID implies exposing more information than is strictly required for some use cases, which puts pressure on data minimisation principles and increases compliance overhead for both the partner and the CSP.

2. Lack of a “check/match” pattern equivalent to other CAMARA APIs

   • In CAMARA, there are already boolean /check or match-type operations (SIM Swap, Device Status, etc.) that respond with a simple true/false.
   • Device Identifier does not currently offer an analogous pattern for the question “does this device match what the network sees?”, which forces clients to consume retrieve endpoints when, functionally, they only need a binary signal.

---

Possible evolution
I propose introducing a new endpoint in the Device Identifier API, with semantics similar to /match endpoints in other CAMARA APIs, for example:

POST /match-identifier (working name, open to discussion in the group)

Proposed behaviour:

• Input

  • Subscription identifier, reusing the same schemes as the current API: msisdn, ipAddress, nai, etc.
  • Device identifier provided by the partner, for example:
    • providedIdentifierType: IMEI, IMEISV or TAC.
    • providedIdentifier: corresponding value

• Output

  • Main boolean field, for example:
    • match: true if the provided device identifier matches the one the network associates with that subscription under the request conditions; false otherwise.
    • Optionally a timestamp or evaluation window if alignment with SIM Swap / Device Swap time semantics is desired.

Positioning in the standard:

• The new endpoint could be defined as an additional operation within Device Identifier, keeping the semantics of retrieve-identifier, retrieve-type and retrieve-ppid intact.
• The network does not expose IMEI/TAC nor PPID; it only returns the boolean and, optionally, a high-level result code.
• For CSPs that have already implemented Device Identifier, this endpoint would reuse the same logic and data sources, exposing only a boolean, with low incremental cost.

---

Alternative solution
Today there are several ways to approach this problem, but none properly address the need for a boolean match:

1. Use retrieve-identifier and compare on the partner side

   • The partner calls retrieve-identifier, receives IMEI/IMEISV/TAC and compares it with the value in their system.
   • Advantages:
     • Fully supported by the current standard.
   • Drawbacks:
     • The partner becomes responsible for storing and protecting a high-value device identifier (IMEI).
     • The minimum disclosure principle is not respected: in many use cases a simple yes/no would be enough.

2. Use retrieve-ppid as a pseudonymous binding identifier

   • A PPID can be used to link subscription/device/partner in a pseudonymous and persistent way.
   • However:
     • It does not precisely answer the question “does this IMEI match what the network currently sees?”, but rather enables a broader and longer-lived binding.
     • It introduces additional privacy and governance considerations, as it is a reusable identifier across multiple transactions.
     • In some regulatory or business contexts there is explicit preference for point-in-time, binary signals rather than persistent identifiers.

For these reasons, introducing a dedicated IMEI boolean match endpoint provides a better balance between business value and data minimisation.

---

Additional context
The proposal does not intend to replace existing Device Identifier operations, but to complement them with a lighter and more privacy-friendly option for use cases where a boolean signal is sufficient.

[Kevsy]

Hi @albertoramosmonagas - this seems closely related to the Device Authenticity (formerly "IMEI Fraud"), please can you clarify the difference? We can discuss both on this week's call. Thanks!

[albertoramosmonagas]

Thanks @Kevsy! They’re related in the domain, but solve different problems:

• Device Authenticity takes an IMEI and answers “is this device clean / fraud-listed in operator/GSMA registers?” (device-centric, IMEI status).
• The proposed match-identifier takes a subscription (msisdn/IP/NAI) + IMEI/TAC and answers “does this device match what the network currently sees for this subscription?” (subscription-centric, boolean only for data minimisation).

So from my point of view one is about IMEI status, the other about subscription–device binding, but totally happy to align on the call!

[ALIIQBAL786]

Dear @albertoramosmonagas, @Kevsy,

Apologies that we were unable to discuss this during the previous meeting.

The proposed endpoint is not intended to reinvent existing functionality; rather, it is designed to complement both APIs.

The DeviceIdentifier API primarily focuses on retrieving device identifiers and does not explicitly address data minimization, whereas the DeviceAuthenticity API concentrates on evaluating the status and risk flags associated with the device under consideration.

This endpoint can operate across the overall use-case lifecycle, providing additional value by bridging these two perspectives.

[Kevsy]

Thanks both:

it is designed to complement both APIs.

I mentioned in the call that I was unsure if this proposed new endpoint to check the IMEI/subscription match is appropriate for DeviceIdentifier, or as an extension to DeviceAuthenticity...

the DeviceAuthenticity API concentrates on evaluating the status and risk flags associated with the device under consideration.

...makes me think the 'match' capability is best to go within DeviceAuthenticity, because it also relates to risk flags 🤔.

[eric-murray]

Considering the API implementation, any API provider that has implemented device-identifier will be able to implement the "match" endpoints.

So I would include the match check as additional mandatory endpoint(s) in device-identifier. Including it as part of DeviceAuthenticity (device-authenticity?) would impose an obligation on any API provider for that API to implement the functionality for device-identifier, even if they did not expose that API themselves.

My preference would be to use the verb verify.

So new endpoints could be:

• POST /verify-identifier
• POST /verify-type
• POST /verify-ppid

Alternatively, you could have a single verify endpoint, where the API consumer passes one of an IMEI, TAC or PPID.

[ALIIQBAL786]

Including it as part of DeviceAuthenticity (device-authenticity?) would impose an obligation on any API provider for that API to implement the functionality for device-identifier, even if they did not expose that API themselves.

I agree that this endpoint should be included in the Device Identifier API. Similar concepts are already present in APIs such as Location Verification and Location Retrieval.

Including this endpoint in Device Authenticity solely based on API category could create unnecessary additional work for the operator.

[albertoramosmonagas]

Hi @eric-murray, @Kevsy & @ALIIQBAL786.

Thanks all for the inputs — this is very helpful. From my side, I’m aligned with keeping this within Device Identifier. The core behaviour I’m aiming for is:

• Input: subscription (msisdn / ipAddress / nai / …) + device identifier (IMEI / IMEISV / TAC) provided by the partner.
• Output: a boolean answering “does this device match what the network currently sees for this subscription?”
  → a subscription–device binding check, with data minimisation (no IMEI/TAC/PPID in the response).

I’m flexible on the exact naming, as long as we keep this semantic: subscription + IMEI/TAC in, boolean match out.

From a ways-of-working perspective, what would you suggest as the right path forward?

• Do we need to explicitly confirm this direction in the next WG call, or is agreement in this issue enough to proceed?
• Once confirmed, what would you see as the concrete next steps?

Thanks again!