ISO/IEC 29161:2016

INTERNATIONAL ISO/IEC
STANDARD 29161
First edition
2016-08-01
Information technology — Data
structure — Unique identification for
the Internet of Things
Technologies de l’information — Structure de données —
Identification unique pour l’Internet des Objets
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Identification of an “entity” . 2
5.1 General . 2
5.2 Overview of the “IoT Network” . 3
6 Unambiguous wrapper for unique identifiers in IoT applications .4
6.1 Overview . 4
6.2 URN schemes suitable for identification in IoT systems . 5
6.2.1 Instances of URN schemes . 5
6.2.2 Listing of existing URN schemes referenced by this International Standard . 6
6.3 URI usage in IoT systems . 6
7 Use of unique identification . 7
7.1 UI concept . 7
7.2 UI encoding . 7
Annex A (informative) URI usage with ISO/IEC JTC 1/SC 31 standards . 8
Annex B (informative) OID wrappers and sensor networks .10
Annex C (informative) Identification Schemes possible to use in Networks .12
Annex D (informative) Ontology of Identification .13
Bibliography .15
© ISO/IEC 2016 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 31, Automatic identification and data capture techniques.
iv © ISO/IEC 2016 – All rights reserved

Introduction
In applications of the Internet of Things (IoT), one “thing” can communicate with other “things” via the
Internet. For that “thing” to communicate, it should possess an identifier of “which” it is.
The ISO/IEC 15459- series does a good job identifying how groups that have been assigned an issuing
agency code can create a character-based system of unique identification.
There is no shortage of claimants to provide that identifier. Each is understandable due to its origins
and the perspective from which it comes. The Internet is a network and groups such as the International
Telecommunications Union (ITU) and the Internet Engineering Task Force (IETF) view this identifier as
a mechanism to facilitate network routing. ITU-T X.668 | ISO/IEC 9834-9 and ITU-T X.660 | ISO/IEC 9834-
1 attempt to fill this need from a network perspective. From a network perspective, it is accepted that
the identification of an entity must resolve to an IP address for contacting it, whether its domain name
“hangs” from an OID root using an OID resolver, or from a more general DNS node (which may end up as
the same thing).
However, not everything is viewed from the perspective of the network, nor necessarily should it so be
viewed. The network is a transport mechanism and the entities themselves have historic identifiers,
which have their genesis from supply chain applications and identification.
Ultimately, the various forms of unique identification identified within this International Standard
need to be combined in a single message in an unambiguous form. This International Standard provides
a method enabling this combination in an unambiguous form.
© ISO/IEC 2016 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 29161:2016(E)
Information technology — Data structure — Unique
identification for the Internet of Things
1 Scope
This International Standard establishes a unique identification scheme for the Internet of Things (IoT),
based on existing and evolving data structures. This International Standard specifies the common
rules applicable for unique identification that are required to ensure full compatibility across different
identities. The unique identification is a universal construct for any physical object, virtual object,
or person. It is used in IoT information systems that need to track or otherwise refer to entities. It is
intended for use with any IoT media.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the
following apply.
3.1
coap
constrained application protocol
[SOURCE: RFC 7252]
3.2
entity
any concrete or abstract thing of interest, including associations among things
[SOURCE: ISO/PAS 16917]
Note 1 to entry: Information also provided in Annex D.
3.3
rest
representational state transfer
4 Abbreviated terms
2D 2 Dimensional
AIDC Automatic Identification and Data Capture
IC Integrated Circuit
IoT Internet of Things
© ISO/IEC 2016 – All rights reserved 1

IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
MAC Media Access Control
RF Radio Frequency
RFID Radio Frequency Identification
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
XMPP Extensible Messaging and Presence Protocol
5 Identification of an “entity”
5.1 General
For the purpose of this International Standard, the term “thing” considers the following as synonyms;
“item”, “object” and “entity”. A thing may be a person, object, or location; see also Annex D.
When one considers the Internet of Things (IoT), the definition of the “thing” is most often coloured
by the perspective of the person undertaking the consideration. If one is coming from the world of
sensors, the IoT is simply an expansion of a sensor network. If one is coming from the world of RFID,
the IoT is simply an expansion of an RFID infrastructure. If one is coming from the world of geospatial
data, the IoT is simply an expansion of a location-based network. If one is coming from the world of
telecommunications, the IoT is simply an expansion of a telecommunications network. In truth, all are
correct. Figure 2 shows some of the possible iterations of “things” that would be possible to connect
through the IoT, using various existing communication interfaces. Of course, there are other possibilities
and these iterations of IoT might actually be combined, e.g. a mobile phone reading a 2D symbol, an RF
tag, or a wireless IC device.
Figure 1 — IoT — everything possible being connected
2 © ISO/IEC 2016 – All rights reserved

A single transaction may need to capture several identities as it progresses from origin to destination
(and return). For example, there may exist a need to capture, each time a transaction is recorded, the
following:
— item identification;
— sensor identification;
— node identification;
— gateway identification;
— target resource identification;
— location of data capture, if mobile;
— time of data capture;
— identification of the individual;
As a virtual thing, software, or software content, ISO/IEC 8824-1:2015, 3.8.52 defines an “object” as
A well-defined piece of information, definition, or specification which requires a name in order to identify
its use in an instance of communication. An object is an abstraction or simulation of physical things such
as people (“people” are included in this definition of object only to be true to the quote, whereas this
International Standard discriminates between people, objects, and locations) and machines or intangible
things such as events and processes that captures their characteristics and behaviour. Something you can
do things to. An object has state, behaviour, and identity; the structure and behaviour of similar objects
[ ]
are defined in their common class. 64
The following are properties that may characterize a thing:
a) Identity: the property of an entity that distinguishes it from other entities;
b) Type: describes the type of entity;
c) Data: describes if and how persons, locations and/or other entities can be tied to the entity;
d) Behaviour: describes the methods in the location’s interface by which the location can be used.
5.2 Overview of the “IoT Network”
The Internet of Things (IoT) network aims to enable almost everything to communicate with each other,
being connected using various communication interfaces and protocols like IPv4, IPv6, MAC addresses,
CoAP/REST, XMPP, etc.
Prerequisite for the IoT network is the possibility to tie various information to the right thing for a given
purpose using unambiguous identities to which specified information is tied which is then exchanged
using application defined protocols.
© ISO/IEC 2016 – All rights reserved 3

Figure 2 — Possible information exchange using IoT
Figure 2 shows an example where the items positions in a minibar in a hotel room are defined and
monitored using sensing techniques. When an item is removed, it is automatically sensed and
information is sent so it is registered as being removed. The item will then be added as purchased and
the price added to the room bill, to be paid at check out. Received information will also trigger refilling
of minibar with the removed item.
The scenario above requires that everything is possible to be uniquely identified, for which this
International Standard is to provide a method for adding a wrapper to already existing identification
schemes.
6 Unambiguous wrapper for unique identifiers in IoT applications
6.1 Overview
Each form of unique identification stands on its own within the context of applications within that
specific identification’s domain. When one travels outside of that closed system, an open system form
of the identification is required. The nature of the Internet of Things (IoT) is for people and objects to
communicate with one and the other. This means that the unique identification scheme will need to
accommodate established forms of identification.
For the purposes of this International Standard, the “unambiguous wrapper” for identifiers used in
IoT communications shall be a Uniform Resource Identifier (URI) defined by IETF, in RFC 3986. URIs
are traditionally classified as either a Uniform Resource Locator (URL, using a string starting with
“http://”) denoting a web resource, or a Uniform Resource Name (URN, using a string starting with
“urn:”) as defined in RFC 2141. In both cases, the URI is a text string from a limited subset of US ASCII
(for maximum portability across systems). The URI syntax is organized hierarchically, with components
listed in order of decreasing significance from left to right. Other structures were considered, but the
URI structure is widely accepted and extensively used with today’s AIDC data carriers, while providing
the flexibility of a broader implementation.
This International Standard is primarily concerned with supporting the interoperable use of
Identification schemes from different domains, using existing URNs as needed to provide this
interoperability in an efficient manner. Although URLs will also be used extensively in IoT applications,
no special treatment of them is required for interoperability, and so this International Standard does
not also define headers for URLs.
4 © ISO/IEC 2016 – All rights reserved

Various current AIDC data carriers and published ISO/IEC standards already make extensive use of
URIs, including the following:
— the encoding of web addresses such as “http://www.iso.org/iso/home.html” in QR Code symbols;
— EPCglobal identifiers such as “urn:epc:id:sgtin:0614141.033254.1” encoded in RFID tags;
— the encoding and transmission protocols for RFID data objects using object identifiers (such as
“urn:oid:1.0.15961.9.1” for GS1 Application Identifier “01”) in accordance with ISO/IEC 15961-2 and
ISO/IEC 15962.
Messages may freely and unambiguously mix identifiers from various AIDC media if published standards
already specify a URI format for the identifier. However, no standard URI format is specified for many
other identifier schemes that will likely see widespread usage in IoT systems. If an unambiguous wrapper
for those identification schemes is needed, it is recommended to use ITU-T X.668 | ISO/IEC 9834-9.
6.2 URN schemes suitable for identification in IoT systems
6.2.1 Instances of URN schemes
Several instances of unique identifiers have already been assigned URN schemes and one of these shall
be used if there does not exist an URN representation for an identification scheme to be used. In general,
pre-existing URN formats for Identifiers that are recognized by this International Standard include all
of those listed in the IANA Registry of URN Namespaces (see http://www.iana.org/assignments/urn-
namespaces). Two forms of registered URNs are already in widespread use in AIDC applications and are
of particular interest for IoT identification; these URNs are those with a prefix of:
— urn:epc [RFC 5134] in a format defined in the GS1/EPCglobal Tag Data Standards
— urn:oid:1.0.sssss [RFC 3061] where:
— Per RFC 3061, the first numeric arc of “1” denotes an ISO-assigned OID, then
— Per ITU-T X.660, the second numeric arc of “0” denotes an International Standard issued by ISO
or IEC, and sssss is a specific standard number. Arcs below this are determined as necessary by
the corresponding International Standard.
— Pre-existing urn schemes of this form, of particular relevance to IoT identification, include those
with a prefix of:
— urn:oid:1.0.15961.df, as defined in ISO/IEC 15962 and the ISO/IEC 15961 multi-part series
of standards;
NOTE These OID formats may be utilized both to encode individual data items on RFID tags using a
registered Data Format ‘df’ and to convey the resulting identifier “names” in RFID middleware protocols.
— urn:oid:1.0.15434.fh, which assigns an OID when the data structure represents an entire
ISO/IEC 15434 Format Envelope that utilizes Format Header “fh”, as might be encoded in a
two-dimensional bar code or RFID tag;
— urn:oid:1.0.15459.gh, which assigns an OID for the unique identification of products,
packages, transport units and groupings. Where “gh” indicates which part of ISO 15459
that is used.
— Other registered urns of interest for identification purposes in IoT applications include (but are not
limited to) urn:clei (RFC 4152), urn:isbn (RFC 3187), urn:issn (RFC 3044), urn:iso (RFC 5141), and
urn:uuid (RFC 4122).
© ISO/IEC 2016 – All rights reserved 5

6.2.2 Listing of existing URN schemes referenced by this International Standard
The following listing shows some of those URN schemes already defined.
— Unique identifiers called out in ISO standards using the Object Identifiers as listed in the
ISO/IEC 15961-2 Data Constructs Register. For example, Table 3 of the ISO/IEC 15961-2 Data
Construct Register, includes the unique identifier starting with the character string “25S” that is
part of the Data Identifier system (see ISO/IEC 15418). The Data Constructs Register shows that this
corresponds to the URN “urn:oid:1.0.15961.13.1” because 15961 assigns a Data Format number “13”
for Data Identifiers, and the associated Relative OID Table assigns ‘1’ for “25S.”
— Unique identifiers called out in ISO standards using the Object Identifiers as listed in the
ISO/IEC 15459-1, ISO/IEC 15459-4, ISO/IEC 15459-5 and ISO/IEC 15459-6, URN for ISO/IEC 15459-
1 is “urn:1.0.15459.1”
— IPV4: see RFC 3291. The inetAddressMIB is 1.3.6.1.2.1.76 and the type ipv4 (1).
— IPV6: see RFC 3291. The inetAddressMIB is 1.3.6.1.2.1.76 and the type ipv6 (2).
— Jabber ID: RFC 3920, 5.1.1 defines this OID: urn:oid:1.3.6.1.5.5.7.8.5.
— MII: urn:oid:2.27.1, per ISO/IEC 29174 and the Data Constructs Register.
6.3 URI usage in IoT systems
In some existing applications, a specific data carrier only encodes one type of identifier, and the choice
of a specific URI as an unambiguous wrapper is predetermined. In other cases, however, a data carrier
may encode a wide variety of different unique identifiers, and the appropriate “wrapper” cannot be
unambiguously distinguished from context. Therefore, it will often be the case that the appropriate URI
wrapper must be determined (from some sort of encoded signal in the data carrier) in order to include
that encoded identifier in a mixed-format IoT message.
It is important to note that the URI always provides an unambiguous name for the identifier and in
some cases provides the value of that identifier as well. For example, URLs always provide a value (the
destination web address) along with the name of the identifier (“http”). The same is true for some forms
of URN, such as the “urn:epc” form. For example, “urn:epc:id:sgtin:0614141.033254.1” not only names
the identifier (as a pure SGLN) but also provides the specific unique value of that instance.
In other cases, such as the “urn:oid:1.0.15961.n.n” form used to encode item-attendant data in
ISO/IEC 18000-63 tags, the URI supplies only the name of the identifier. In this case, the name
is efficiently encoded on the tag as a “relative oid,” and the complete identifier is both encoded and
transmitted as a pair. This format can be easily represented in many
relevant protocols, such as those based on XML.
For example, in a hypothetical XML-based protocol, a identifier could be represented as
follows:
25S123456789ABC123
Continuing the same hypothetical example, an identifier whose urn conveys both name and value could
be represented as an empty-element tag, such as:

or
urn:epc:id:sgtin:0614141.33254.1”>
Annex A details how “unambiguous wrapper” URIs could be encoded or otherwise signalled in relevant
SC 31 data carriers, and how they could be conveyed in relev
...