ISO/IEC 29161:2016

Information technology — Data structure — Unique identification for the Internet of Things

ISO/IEC 29161:2016 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.

Technologies de l'information — Structure de données — Identification unique pour l’Internet des Objets

General Information

• Status: Published
• Publication Date: 27-Jul-2016
• ICS: 35.040 - Information coding
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 2 - Data and structure
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 07-Mar-2022

Standards Content (Sample)

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 29161:2016(E)
©
ISO/IEC 2016

---------------------- Page: 1 ----------------------
ISO/IEC 29161:2016(E)

COPYRIGHT PROTECTED DOCUMENT
© 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 3 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 4 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 7 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 8 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 9 ----------------------
ISO/IEC 29161:2016(E)

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

---------------------- Page: 10 ----------------------
ISO/IEC 29161:2016(E)

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 relevant data protocols. Therefore, Annex A
6 © ISO/IEC 2016 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/IEC 29161:2016(E)

provides multiple use cases for handling a specific scenario. Annex C provides an example of URI usage
in a protocol suitable for data carriers including sensor networks.
In many of the protocols that are likely to convey IoT identifiers, such as those based on XML, pure
binary data cannot be directly supported. That is to say that although the data carrier may encode such
identifiers as a series of 8-bit binary values, when transmitted each such byte value shall be represented
as two ASCII characters, each in the range ‘0’.’9’ or ‘a’.’f’.
7 Use of unique identification
7.1 UI concept
The Unique Identification (UI) concept employs a qualifier and string component which shall be
unambiguous within its qualifier, in the sense that no issuer re-issues the string within the qualifier
over the entire life cycle for the identified entity or until a sufficient period of time has passed so that
the identity has ceased to be of significance to any user.
7.2 UI encoding
Depending upon existing schemes Unique Identification (UI) can be either numeric, binary or
alphanumeric.
When the URN is encoded in a data carrier, it should comply with the encoding rules of that carrier
technology.
© ISO/IEC 2016 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/IEC 29161:2016(E)

Annex A
(informative)

URI usage with ISO/IEC JTC 1/SC 31 standards
A.1 Signalling URIs in SC 31 Data Carriers
In some existing AIDC applications, a specific data carrier only encodes one type of identifier, either by
design or due to the specific context in which it is used. In such cases, there is no need to modify the
encoding or usage of the data carrier in order to add an unambiguous wrapper, because the choice of
wrapper is predetermined. Examples include EAN/UPC bar codes (which by design only encode GTINs,
as described below), or a bar code on a cell phone card that encodes the phone’s IMEI. In the majority
of cases, however, a data carrier (bar code, RFID tag, etc.) may encode a wide variety of different
identifiers, and the appropriate “wrapper” cannot be unambiguously distinguished from context.
Therefore, it will usually be the case that the appropriate URI wrapper should 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. The following subclauses detail how URIs can be encoded or otherwise signalled in
relevant SC 31 data carriers.
A.2 EAN/UPC and GS1 DataBar symbols
A.2.1 General
With the exception of GS1 DataBar Expanded, these data carriers can only encode a GS1-defined GTIN,
and therefore the existence of the appropriate GS1 Application Identifier (01) is implied rather than
explicitly encoded. For conveying the GTIN into an IoT message, therefore, it is only necessary to
zero-preface the encoded number (as needed, to pad it to a 14-digit length) to create the appropriate
value, and the appropriate URI is represented (in a protocol-specific manner as described below) as
“urn:oid:1.0.15961.9.1” (per the GS1 table registration to the Data Constructs Register). For the case
of GS1 DataBar Expanded, the URI for the Unique Identifier shall be derived from the first encoded AI
string, and represented as “urn:oid:1.0.15961.9.n” where n is the first encoded AI.
A.2.2 Code 39, Code 128, and GS1 128 symbols
With the exception of GS1 128 (with FNC1 encoded in the first character position), Code 128 symbols
may signal the chosen URN by literally encoding it as a prefix to the data (terminated by two periods, to
separate the URN from the remaining data). However, the resulting symbol may be unacceptably long,
and so the second method may be preferred.
For the case of GS1 128, the URI is not explicitly encoded, but instead is derived, in exactly the same
manner as for GS1 DataBar Expanded.
A.2.3 Two-dimensional symbols
Several options are available for signalling a URI from a two-dimensional symbol.
— URIs that represent web addresses (URLs) are increasingly common, especially in QR Code
symbols. These may be unambiguously encoded as verbatim strings (e.g., starting with “http://”, or
starting with a symbology codeword that expands to such a string). However, because it may not
be possible to determine the boundary between the end of a URL and the start of a next data item,
this International Standard recommends that if a URL is encoded in a two dimensional symbol, that
it be the only data item encoded in that symbol. An exception can be made, however, if the URL is
prefaced by a data qualifier denoting the encoding of a URL.
8 © ISO/IEC 2016 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/IEC 29161:2016(E)

— Many two-dimensional symbologies support an encoded indicator for GS1 applications. When
these are employed, then the URN is not explicitly encoded, but instead a urn of the form
“urn:oid:1.0.15961.9.n” is derived, in exactly the same manner as for GS1 DataBar Expanded.
— Some two-dimensional symbologies support AIM Application Indicators, in which case a URN can
be unambiguously signalled.
A.2.4 RFID tags, per ISO/IEC 18000-63
...

DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 29161
ISO/IEC JTC 1/SC 31 Secretariat: ANSI
Voting begins on: Voting terminates on:
2015-06-16 2015-09-16
Information technology — Data structure — Unique
identification for lot
Technologies de l’information — Structure de données — Identification unique
ICS: 35.040
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 29161:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2015

---------------------- Page: 1 ----------------------
ISO/IEC DIS 29161:2015(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015, 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC CD 29161
Contents Page
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 7
4 Identification of an “entity” . 7
4.1 General . 7
4.2 Overview of the "IoT Network" . 8
5 The unambiguous wrapper for unique identifiers in IoT applications . 9
5.1 Overview . 9
5.2 URN schemes suitable for identification in IoT systems . 10
5.3 URI usage in IoT systems . 11
6 Unique identification . 12
6.1 General . 12
6.2 UI concept . 12
Annex A (informative) URI usage with ISO/IEC JTC 1/SC 31 standards . 13
A.1 Signalling URIs in SC 31 Data Carriers . 13
A.2 EAN/UPC and GS1 DataBar symbols . 13
A.3 How URIs are conveyed in relevant data protocols . 14
A.4 Examples . 14
Annex B (informative) OID wrappers and sensor networks . 15
B.1 Overview . 15
B.2 Use case . 15
Annex C (informative) Identification Schemes possible to use in Networks . 17
C.1 List of Network Identification Schemes . 17
Annex D (informative) Ontology of Identification . 18
D.1 Identification . 18
Bibliography . 19

© ISO/IEC 2014 – All rights reserved
iii

---------------------- Page: 3 ----------------------
ISO/IEC CD 29161
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. International
Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 29161 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques, Working Group 2, Data structure.
This International Standard has four annexes which provide informative information.
 Annex A - URI usage with ISO/IEC JTC1 SC31 standards
 Annex B – OID wrappers and sensor networks
 Annex C – Network Identification Schemes
 Annex D - Ontology of Identification


iv
 © ISO/IEC 2014 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC CD 29161
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 must 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 X.668 | ISO 9834-9 and ITU X.660 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 2014 – All rights reserved
v

---------------------- Page: 5 ----------------------
ISO/IEC CD 29161
Information technology – Data structure - Unique identification
for IoT
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.
This standard does not address GS1/EPC binary encodings as defined in GS1/EPC tag data standard.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions – Part 1: Country
codes
ISO/IEC 7812-1, Identification cards — Identification of issuers — Part 1: Numbering system
ISO/IEC 7812-2, Identification cards — Identification of issuers — Part 2: Application and registration
procedures
ISO/IEC 7816-5, Identification cards — Integrated circuit cards — Part 5: Registration of application providers
ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Inter-industry data elements for
interchange
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 15459 (All parts), Information technology — Unique identifiers
ISO/IEC 15961-2, Information technology — Radio frequency identification (RFID) for item management: Data
protocol — Part 2: Registration of RFID data constructs
ISO/IEC 19762, Information technology — AIDC techniques — Harmonized vocabulary
ISO/IEC 29174-1, Information technology — UII scheme and encoding format for Mobile AIDC services —
Part 1: Identifier scheme for multimedia information access triggered by tag-based identification
ANSI MH10.8.2, Data Identifier and Application Identifier Standard
IETF RFC 3061, A URN Namespace of Object Identifiers
IETF RFC 3291, Textual Conventions for Internet Network Addresses
IETF RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core
6
© ISO/IEC 2014 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/IEC CD 29161
IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace
GS1, GS1 General Specifications
GS1/EPC, GS1/EPC Tag Data Standards
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 [RFC 7252]
3.2
entity
- any concrete or abstract thing of interest, including associations among things [ISO/PAS 16917]
Note to entry: Information also provided in Annex D
3.3
rest
representational state transfer
4 Identification of an “entity”
4.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 2 – IoT - everything possible being connected
© ISO/IEC 2014 – All rights reserved 7

---------------------- Page: 7 ----------------------
ISO/IEC CD 29161
A single transaction may need to capture several identities as it progresses from origin to destination (and
return). For example there may exist 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 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
1 2
communication. An object is an abstraction or simulation of physical things such as people 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
3
objects are defined in their common class.
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
4.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.


1 ISO/IEC 8824-1:2008, Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation, §3.8.52
2
“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.
3
Booch, G., Objected-Oriented Analysis And Design With Applications, 2nd Ed., Menlo Park, CA: Addison-Wesley, 1994
8
© ISO/IEC 2014 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC CD 29161

Figure 3 – Possible information exchange using IoT
In Figure 3 the groceries marked with unique identities in a refrigerator placed in a home may be monitored
when entered or removed using for example 2D codes or RFID. Thresholds in the refrigerators monitoring
application set by the house owner are used so that the given retail store could get the information via so that
its inventory system could be triggered if the actual grocery does not exists. The inventory system monitors
the stores groceries so that orders for new groceries are sent in time so they are available when customer
needs them.
The scenario above requires that everything is possible to be uniquely identified, for which this standard is to
provide a method for adding a wrapper to already existing identification schemes.
5 The unambiguous wrapper for unique identifiers in IoT applications
5.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 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.
© ISO/IEC 2014 – All rights reserved 9

---------------------- Page: 9 ----------------------
ISO/IEC CD 29161
Various current AIDC data carriers and published ISO/IEC standards already make extensive use of URIs,
including:
 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:sgln:0614141.33254.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-n 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. This International Standard defines a
Uniform Resource Name (a string beginning with “urn:oid:1.0.29161.”) that provides an unambiguous wrapper
for those identification schemes without a published URI equivalent.
5.2 URN schemes suitable for identification in IoT systems
Several specific instances of unique identifiers, , have been assigned URN schemes; these are listed in sub
clause 5.2.1, one of these shall be used in the does not exist an URN representation for an identification
scheme. 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 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].
10
© ISO/IEC 2014 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC CD 29161
5.2.1 Listing of existing URN schemes referenced by this International Standard
The following listing shows those Unique Identification schemes listed in Clause 6 for which URNs are already
defined. They are listed in the order in which they appear in Clause 6.
 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 4, shows 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 parts 1, 4, 5 and 6, URN for part 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 section 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

5.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:sgln:0614141.33254.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:
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:

Annex C details how “unambiguous wrapper” URIs shall be encoded or otherwise signalled in relevant SC 31
data carriers, and how they shall be conveyed in relevant data protocols. Where Annex C provides multiple
options for handling a specific scenario, one of those options shall be utilized. Annex D provides an example
of URI usage in a protocol suitable for data carriers including sensor networks.
© ISO/IEC 2014 – All rights reserved 11

---------------------- Page: 11 ----------------------
ISO/IEC CD 29161
In many of the protocols that are likely to convey IoT identifiers, such as those based on XML, pure binary
data cannot be directly supported. For uniformity of implementations in a protocol-agnostic manner, this
International Standard defines a hexadecimal-character protocol-layer representation of every unique identifier
listed in Clause 6 that is described as a Binary value (as opposed to numeric or ASCII). That is to say, that
although the data carrier may encode such identifiers as a series of 8-bit binary values, when transmitted in
conformance with this annex each such byte value shall be represented as two ASCII characters, each in the
range ‘0’.’9’ or ‘a’.’f’.
6 Unique identification
6.1 General
Depending upon existing schemes Unique Identification (UI) can be either numeric, binary or alphanumeric.
Numeric coding simply uses the binary value of the various fields in the data structure. Alphanumeric coding
may also use the 6-bit encoding which is used in various International standards and is duplicated in Table 3.
Table 3 – Six-bit encoding
Space 100000 0 110000 @ 000000 P 010000
100001 1 110001 A 000001 Q 010001
100010 2 110010 B 000010 R 010010
100011 3 110011 C 000011 S 010011
100100 4 110100 D 000100 T 010100
100101 5 110101 E 000101 U 010101
100110 6 110110 F 000110 V 010110
100111 7 110111 G 000111 W 010111
( 101000 8 111000 H 001000 X 011000
) 101001 9 111001 I 001001 Y 011001
* 101010 : 111010 J 001010 Z 011010
+ 101011 ; 111011 K 001011 [ 011011
, 101100 < 111100 L 001100 \ 011100
- 101101 = 111101 M 001101 ] 011101
. 101110 > 111110 N 001110 011110
/ 101111 ? 111111 O 001111 011111

6.2 UI concept
The Unique Identification (UI) concept employs a qualifier and string component which shall be unambiguous
within its qualifier, in the sense that no issuer re-issues the string within the qualifier over the entire life cycle
for the identified entity or until a sufficient period of time has passed so that the identity has ceased to be of
significance to any user.

12
© ISO/IEC 2014 – All rights reserved

---------------------- Page: 12 ----------------------
ISO/IEC CD 29161
Annex A
(informative)

URI usage with ISO/IEC JTC 1/SC 31 standards
A.1 Signalling URIs in SC 31 Data Carriers
In some existing AIDC applications, a specific data carrier only encodes one type of identifier, either by design
or due to the specific context in which it is used. In such cases, there is no need to modify the encoding or
usage of the data carrier in order to add an unambiguous wrapper, because the choice of wrapper is
predetermined. Examples include EAN/UPC bar codes (which by design only encode GTINs, as described
below), or a bar code on a cell phone card that encodes the phone’s IMEI. In the majority of cases, however, a
data carrier (bar code, RFID tag, etc.) may encode a wide variety of different identifiers, and the appropriate
“wrapper” cannot be unambiguously distinguished from context. Therefore, it will usually 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. The following sub clauses detail how URIs can
be encoded or otherwise signalled in relevant SC 31 data carriers.
A.2 EAN/UPC and GS1 DataBar symbols
With the exception of GS1 DataBar Expanded, these data
...