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
Current Stage
9020 - International Standard under periodical review
Start Date
15-Jul-2021
Ref Project

Buy Standard

Standard
ISO/IEC 29161:2016 - Information technology -- Data structure -- Unique identification for the Internet of Things
English language
18 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 29161:2016 - Information technology -- Data structure -- Unique identification for the Internet of Things
English language
18 pages
sale 15% off
Preview
sale 15% off
Preview

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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
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:

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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
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
© 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
---------------------- 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
© 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

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

“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.

Booch, G., Objected-Oriented Analysis And Design With Applications, 2nd Ed., Menlo Park, CA: Addison-Wesley, 1994

© 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].
© 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.
© 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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.