Future roadmap: WiFi and non-handset IoT device support in Device Identifier API

[albertoramosmonagas]

Hi team,

We’ve been reviewing the Device Identifier v0.3 implementation under the CAMARA framework, and had two questions regarding potential future extensions:

1. WiFi scenarios:
Currently, the API seems limited to mobile devices authenticated through the mobile core (HLR/HSS/UDM). Are there any plans to extend /retrieve-identifier or /retrieve-type to support WiFi-attached sessions, for example when the subscriber device is connected through a broadband CPE or trusted WiFi gateway?

2. IoT and non-handset devices:
The documentation mentions support for IoT/M2M when a SIM/eSIM is present. Could the API, in future releases, be generalized to identify non-handset devices (e.g., connected cars, drones, smart home devices) that use a mobile subscription or NAI — potentially through an extended TAC or IoT registry?

We’re exploring use cases in connected mobility and device trust frameworks (EUDI Wallet, fraud prevention) and would like to understand if these scenarios are considered in the roadmap.

Thanks in advance for any clarification.

[eric-murray]

Hi @albertoramosmonagas

Apologies for ignoring this discussion for so long! I missed the notification that you had created this.

You raise some good questions. My thoughts:

WiFi Scenarios
The IMEI and related identifiers are inherently for a mobile device but, as you note, this can be connected via WiFi. The mobile operator may still know the IMEI, as mobile devices anyway generally attach to the mobile network, even if they are also connected to a WiFi network. So the API should still work so long as the device is identified by phone number (as the mobile operator will not be able to identify the device from the IP address it is using).

Even if the device is not attached to the mobile network, the mobile operator may have historical information from when the device did last connect to the mobile network. It can signal that the information is historical using the lastChecked response field.

Finally, even if the device has not been connected to the mobile network for a long time, the IMEI is signalled to the mobile operator should the device perform an EAP-AKA authentication. So the IMEI can be retrieved via that route, albeit that retrieving it from the Entitlement Configuration Server may not be so straightforward.

IoT and non-handset devices
My thought is that the API should still work for these scenarios so long as a 3-legged access token can be obtained (using IP address for CIBA if the subscription has no associated phone number) or, for 2-legged access tokens, the device is identified directly (in this case, by IP address or NAI).

Identifying by alternative subscription identifiers (e.g. IMSI) is not currently supported by CAMARA. My preference is that mobile network operators would support NAI for IoT devices, and the API be called using 2-legged access tokens (which is fine for IoT use cases). But, without NAI support and no allocated phone number, we are left with either identification from IP address or front-end flow, neither of which is ideal.

Do you have specific proposals for this scenario?

[albertoramosmonagas]

Thanks Eric, this is very helpful. My takeaway is that Device Identifier should not be framed as “WiFi support” in a generic sense, but rather as “mobile-subscription device identity, even when the device may currently be on WiFi, as long as the HPLMN still has a valid last observed device record”.

For me, the important boundary is that this doesn't seem to extend to fixed-access / broadband CPE scenarios where there is no deterministic mobile-core context. On IoT, I agree the meaningful scope is SIM/eSIM-attached devices for which the operator can observe IMEI/TAC in the mobile core. In practice, that would cover some non-handset devices, but not arbitrary IoT endpoints.

The main gap I see is NAI: it feels like the right long-term selector for IoT, but today it is still not consistently available/enabled across CAMARA implementations. Would it make sense for the roadmap/documentation to make these boundaries explicit? For example:

• clarify “WiFi path” as last-observed mobile-device semantics rather than generic WiFi support,
• explicitly state support for SIM-attached cellular IoT with IMEI/TAC visibility, and
• track NAI enablement as the key interoperability item for IoT/non-MSISDN subscriptions.

At the moment, we at TEF don't have a specific proposal, but these are some questions that have come up during the implementation of the API