Include device identifiers used in IoT in addition to IP Address, MSISDN and Operator Token

[MarkCornall]

Problem description
IoT devices do not necessarily have a MSISDN when they have a data only connection. They can use other identifiers. These are presently not included as valid identifiers in CAMARA. We have an increasing number of use cases where enterprise are seeking an IoT solution but CAMARA will not support them with the identifiers presently defined

Possible evolution
Investigate and Include the use of IoT identifiers in IoT and other API calls.

[Kevsy]

It's a good point Mark!

The IoT identifier landscape is well-discussed in these papers (if anyone can find any more recent papers which discuss new schemes, please share them)

• Analysis of identifiers in IoT platforms
• Identifiers in Internet of Things, including survey results
• Industry IoT consortium

TL,DR: there's no single agreed 'universal identifier' scheme, rather, there are options for each layer being identified (physical device, network interface, application...)

Another consideration for CAMARA is portability: when the access network changes, do the identifiers persist?

[eric-murray]

Hi Mark

The networkAccessIdentifier (3GPP external id) was foreseen as an identifier for IoT use cases. As issues of opt-in/opt-out (generally) don't arise for IoT devices, it is currently only defined for client credentials, and not any of the 3-legged flows.

But the main issue is that it is not generally supported by network operators. Indeed, most APIs contain a disclaimer that this identifier is not currently supported, but only included for "future-proofing".

So maybe that future is now here, and network operators need to step-up and support the networkAccessIdentifier for IoT use cases.

[Kevsy]

support the networkAccessIdentifier for IoT use cases.

We should account for network portability for IoT, as we do for MSISDN.

A networkAccessIdentifier that represents a 3GPP External Identifier in the form <Local Identifier>@<Domain Identifier> will no longer represent the issuing operator ('Domain') if the IoT device is ported to another operator. And the original issuing operator will have little incentive to persist the Local Identifier if it no longer serves the device, so it can't be relied upon as a persistent GUID either. Note the 3GPP External Identifier is itself a reference to an IMSI (ref: TS 19.7.2 of 23.003)

(There's a related discussion about routing an API request with an IoT identifier to the serving operator, how that works with multi-IMSI SIMs, whether the IMEI can help here...)

[eric-murray]

Well, MSISDN is also bound to IMSI, and it wasn't so long ago that number portability was not a thing. It took regulation to enable that, and the solution will be similar for IoT identifiers - BYOD (Bring Your Own Domain), where the domain is owned by the customer, and not the telco.

We are not there yet, of course. But CAMARA have defined the networkAccessIdentifier for 2-legged authentication, and that could be used for IoT devices. Defining additional identifiers for IoT devices that are also not supported by network operators does not really get us any further forward.

Some may ask why don't we just allow IMSI as an identifier for IoT devices. I would be against this for various reasons, including:

• IMSI is mobile network specific, whereas CAMARA try to be more agnostic
• IMSI would be applicable to all mobile devices, not just IoT devices, and this would complicate APIs for non-IoT use cases
• IMSI is not, and never can be, a portable identifier

[tlohmar]

@eric-murray

But CAMARA have defined the networkAccessIdentifier for 2-legged authentication, and that could be used for IoT devices.

Maybe I am missing something: The device object still contains the following note: NOTE2: as for this Commonalities release, we are enforcing that the networkAccessIdentifier is only part of the schema for future-proofing, and CAMARA does not currently allow its use. After the CAMARA meta-release work is concluded and the relevant issues are resolved, its use will need to be explicitly documented in the guidelines.

IMSI is not, and never can be, a portable identifier

yes, the IMSI / SUPI is not designed as a portable identifier, neither within the same CSP (e.g. subscription renewal) nor between CSPs.

@Kevsy, on your comment

Note the 3GPP External Identifier is itself a reference to an IMSI (ref: TS 19.7.2 of 23.003)

It is probably better to refer to TS 23.501 (5G System spec), Clause 5.9.8 (Generic Public Subscription Identifier), where the GPSI is defined to be either an MSISDN or an External Identifier. Note that TS 23.501 does not limit the usage to IOT devices. Is there some reason to limit this to IOT services?

A networkAccessIdentifier that represents a 3GPP External Identifier in the form @ will no longer represent the issuing operator ('Domain') if the IoT device is ported to another operator

TS 23.003 Cl 19.7.2 refers to TS 23.682 Cl 4.6.2 (SCEF) for the definition. It only says, "Domain Identifier: identifies a domain that is under the control of a Mobile Network Operator (MNO). The Domain Identifier is used to identify where services provided by the operator network can be accessed (e.g. MTC-IWF or SCEF provided services). An operator may use different domain identifiers to provide access to different services and/or MTC Service Providers."

I dont read this as a requirement, that the must be a CSP owned domain. But I am also not sure, whether there is a identifier portability requirement for all cases.

[Kevsy]

HI @tlohmar

It is probably better to refer to TS 23.501 (5G System spec), Clause 5.9.8

Thanks, yes 👍

Note that TS 23.501 does not limit the usage to IOT devices. Is there some reason to limit this to IOT services?

I don't think so - we are talking about using it for IoT, but that does not restrict other scenarios

"Domain Identifier: identifies a domain that is under the control of a Mobile Network Operator (MNO). The Domain Identifier is used to identify where services provided by the operator network can be accessed (e.g. MTC-IWF or SCEF provided services). An operator may use different domain identifiers to provide access to different services and/or MTC Service Providers."

I don't read this as a requirement, that the must be a CSP owned domain. But I am also not sure, whether there is a identifier portability requirement for all cases.

OK, so that may give some flexibility. It would be preferable if we could account for portability, even if it can't be entirely solved with a network-centric identifier syntax.

[tlohmar]

@Kevsy thanks for the clarifications.

"Domain Identifier: identifies a domain that is under the control of a Mobile Network Operator (MNO). The Domain Identifier is used to identify where services provided by the operator network can be accessed (e.g. MTC-IWF or SCEF provided services). An operator may use different domain identifiers to provide access to different services and/or MTC Service Providers."
I don't read this as a requirement, that the must be a CSP owned domain. But I am also not sure, whether there is a identifier portability requirement for all cases.

OK, so that may give some flexibility. It would be preferable if we could account for portability, even if it can't be entirely solved with a network-centric identifier syntax.

I didnt want to challenge the need/requirement for identity portability. Would be good to think about supporting identity portability, e.g. by using a common domain like "3gppnetworks.org".

And, I assume that this issue of identity portability is motivated by long-lived identifiers (like the MSISDN). These numbers where printed in phone books in the past, thus, not meant to change. This may be different in modern IT environments. It could be reasonable to think also about short-lived identifiers or "identifiers with constrains", like time limited identifiers or purpose specific identifiers.

[Kevsy]

Good points -I think we have two areas to solve:

(1) given an identifier for an IoT device, how a CAMARA API request can be routed for fulfillment
(2) that the solution for (1) should minimise the impact to IoT developers, who already have a challenge sourcing and managing identifiers

We have an increasing number of use cases where enterprise are seeking an IoT solution

@MarkCornall can you share any of these use cases?

but CAMARA will not support them with the identifiers presently defined

...and say why networkAccessIdentifier is not suitable for those cases?

[rartych]

In our Glossary Network Access Identifier is defined as follows:

A public identifier addressing a subscription in a network, defined in IETF RFC 7542. In 3GPP mobile networks one such option is the General Public Subscriber Identifier (GPSI) formatted with the "External Identifier" as ({Local Identifier}@{Domain Identifier}). Unlike the phone number, the network access identifier is not subjected to portability ruling in force, and is individually managed by each operator.

[Kevsy]

Note that the "External Group Identifier" as defined in 4.6.3 of 3GPP TS 23.682 (which covers support for Machine Type Communications) may be useful for the IoT scenario. It uses the same format as 'External Identifier' but allows an internal mapping to an IMSI Group identifier, i.e. to more than one device. So it could be useful for cases where a group of devices need to be addressed by the API consumer.

[tlohmar]

This thread contains lots of interesting aspects. I start wondering about the objectives of this Issue, i.e. what are the needs specifically for IoT devices, i.e. for what reasons/how should a new identifier be used (e.g. use-cases) and what should it actually identify.

The Issue mentions various types of identifiers: "IoT device identifiers", "MSISDN", "IP addresses" and "Operator tokens". These identifies identify different aspects:

• An IoT device identifier hints to an identifier like an IMEI for mobile devices. The MSISDN has been designed as a subscription identifier (actually for speech calls), which is linked to the devices containing the SIM. Is this issue about a device identifier or about a subscription identifier (plugged in a devices and activated with a PIN)? Should the new identifier provide the same characteristics and usage patterns as an MSISDN?
• An IP Address is actually an host interface identifier and it identifies where a device is located on the network and how to route packets to and from it. It can be used to lookup the associated device / subscription, to which the IP address is assigned (potentially not uniquely).
• I am not sure, what an Operator Token is identifying. According to AI, it seems to identify the combination of a subscription, an operator, some operator specific services, some permissions and/or some additional aspects. I think, it is often also limited to a one-time usage.
  • Beside Operator tokens, there is also the general concept of security tokens (or assertions). Such identifiers carry much more information, similar to an Operator Token.

It could make sense for the discussion to clarify the intended purpose / the objectives of this new identifier and also, what the identifier is actually identifying. Maybe, it is one identifier format (like the NAI format), which can be used for different purposes and can carry different information (like these token realizations).