ISO 22381:2018

INTERNATIONAL ISO
STANDARD 22381
First edition
2018-09
Security and resilience — Authenticity,
integrity and trust for products
and documents — Guidelines for
establishing interoperability among
object identification systems to deter
counterfeiting and illicit trade
Reference number
©
ISO 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Planning, implementing and controlling systems’ interoperability.2
5.1 Identify stakeholders and their needs . 2
5.2 Organize stakeholders . 3
5.2.1 Identify lead stakeholder . 3
5.2.2 Define roles and responsibilities . 3
5.2.3 Develop a contractual framework . 3
5.2.4 Set up an onboarding and leaving process . 4
5.3 Plan architecture . 4
5.3.1 General principles . 4
5.3.2 Identify participating OIASs and functional blocs to form the constituents
of the I-OP . 5
5.3.3 Study types and ownership of attributes to be handled . 6
5.3.4 Specify TEPs for secure I-OP access . 6
5.3.5 Specify access rules for users . 7
5.3.6 Define and improve trust levels . 7
5.3.7 Outline or delimit the usage of participating OIASs and their functional units . 8
5.3.8 Draft an I-OP architecture . 8
5.3.9 Return information back to the source . 8
5.4 Plan and implement operations . 9
5.4.1 Define data exchange formats . 9
5.4.2 Establish trust into the service behind a particular UID . 9
5.4.3 Delimit data inputs and outputs . 9
5.4.4 Define storage and custodianship of data inputs and outputs .10
5.4.5 Define operational responsibilities .10
5.4.6 Prepare for systems failures .10
5.4.7 Negotiate alarm responses of common interest .10
5.4.8 Run pilots .11
5.5 Review and improve .11
5.5.1 General.11
5.5.2 Revisit stakeholders’ expectations .11
5.5.3 Review operations .11
5.5.4 Review security .11
5.5.5 Review technology .12
Annex A (informative) Typical stakeholder interests in an I-OP .13
Annex B (informative) The role of trusted entry points for user groups .18
Annex C (informative) Types of information exchanged in I-OP architectures .19
Bibliography .20
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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 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 of the voluntary nature of standards, 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 www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 292, Security and resilience.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2018 – All rights reserved

Introduction
Identification systems based on unique identifiers are no longer restricted to individuals’ ID cards, car
licence plates or telephone numbers. For many years, product identification has been well established
in the world of things: unique identifiers are used on sales items and on their packaging, as well as on
other sales and transport units. This is seen as a major step forward in consumer safety, in particular
for uncovering counterfeit and illicit trade activities.
ISO 16678 outlines functional units and principles of systems based on unique identifiers. It has been
established that interoperability of such systems is key to future deployment, enabled by the vast use of
internet connectivity.
As object identification systems and various requirements by the public and the private sector are
being created, there is urgent need to enable interoperability. The automation of processes on an
interorganizational level is one of the core challenges of the digital era. By establishing interoperability,
collaborating organizations strive for operational connectivity between their business processes and
supporting infrastructures.
This guidelines document describes the landscape of safe, interoperable architectures. It encourages
the vast deployment of object identification and authentication systems to deter counterfeits, product
falsification and illicit trade, and to increase resilience against product fraud.
This allows industry and other sectors, confronted with the need to adopt object identification systems,
to run multiple identification schemes in parallel.
Governments, associations, industry and other stakeholders in the battle against counterfeiting
and illicit trade are encouraged to use this guidelines document. It is applicable to both simple and
sophisticated object identification systems.
The guidelines aim to leave competition open to current and future solutions in object identification
and authentication systems. By interoperability, the development of technologies, present and future, is
maintained.
Figure 1 shows the process of planning, implementing and controlling systems’ interoperability.
Figure 1 — Process of planning, implementing and controlling systems’ interoperability
INTERNATIONAL STANDARD ISO 22381:2018(E)
Security and resilience — Authenticity, integrity and trust
for products and documents — Guidelines for establishing
interoperability among object identification systems to
deter counterfeiting and illicit trade
1 Scope
This document gives guidelines for establishing interoperability among independently functioning
product identification and related authentication systems, as described in ISO 16678. The permanent
transfer of data from one system to another is out of the scope of this document.
It also gives guidance on how to specify an environment open to existing or new methods of
identification and authentication of objects, and which is accessible for legacy systems that may need to
remain active.
It is applicable to any industry, stakeholder or user group requiring object identification and
authentication systems. It can be used on a global scale, or in limited environments. This document
supports those involved in planning and establishing interoperation.
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.
ISO 22300, Security and resilience — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22300 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
attribute
category of information that comprises the content of object identification and authentication systems
3.2
inspector
anyone who uses the object examination function with the aim of evaluating an object
[SOURCE: ISO 16678:2014, 2.1.10, modified — The notes to entry have been deleted.]
3.3
lead stakeholder
single stakeholder organizing interoperability of object identification and authentication systems
(I-OPs), a group of stakeholders or a dedicated legal entity governing an I-OP
4 Abbreviated terms
AAF attribute assignment function
ADMS attribute data management system
I-OP interoperability of object identification and authentication system
NFC near field communication
OEF object examination function
OIAS object identification and authentication system
PUF physically unclonable function
RFF response formatting function
RFID radio frequency identification device
TEP trusted entry point
TQPF trusted query processing function
TVF trusted verification function
UID unique identifier
UIDGF UID generating function
VDS visible digital seal
5 Planning, implementing and controlling systems’ interoperability
5.1 Identify stakeholders and their needs
In each particular case, interoperability among product identification and authentication systems
(I-OPs) is driven by one or several stakeholders, such as professional or private user groups, brand
owners or regulating authorities.
All relevant stakeholders should be identified no matter how active their role is in creating the I-OP.
All identified stakeholders’ interests, needs, objectives and capabilities should be analysed. This can
be done by conducting interviews with the stakeholders and conducting literature studies as well as
by using other sources, as applicable. In particular, expectations and obligations should be analysed
concerning
— governance/control of OIASs,
— governance/control of particular functional blocs or subsystems thereof,
— data privacy,
— data ownership,
— access rights,
— security levels, and
— funding of I-OPs or subsystems.
2 © ISO 2018 – All rights reserved

Annex A provides an overview of some of the typical stakeholders and can be used as a starting point
for the identification of stakeholders and their possible needs and expectations.
5.2 Organize stakeholders
5.2.1 Identify lead stakeholder
One of the identified stakeholders, or an entity representing a group of stakeholders, should take the
initiative to be the lead stakeholder.
The role of lead stakeholder can change over time.
5.2.2 Define roles and responsibilities
The lead stakeholder should address the other identified stakeholders and negotiate their roles and
responsibilities, such as
— whose viewpoints need to be considered,
— who can fund what, and
— who can decide what.
This should be described in an agreement among the stakeholders who are intended to become part of
contractual relationships.
Depending on the business model, the lead stakeholder should implement the relevant business
structures to maintain the I-OP and its funding.
5.2.3 Develop a contractual framework
The lead stakeholder should investigate the regulations and technical means that are available and
feasible to develop a written contractual framework covering
— roles and responsibilities in planning, constructing and operating an I-OP,
— expected inputs and outcomes,
— categorization of types of data,
— access rights and ownership of these categories of data,
— security levels of participating functional units,
— security levels of transactions,
— new dependencies among participating systems or functional units, and
— I-OP system’s review and continuous improvement.
The lead stakeholder should employ methods and measures to mitigate identified risks, such as
— contractual and reputational risk,
— liabilities,
— conformities,
— noncompliance with legal environments,
— fraud and counterfeiting, and
— system vulnerability and failures.
As a measure of mitigating fraud risks, the availability of public security technical frameworks to
support the integrity of data access, transport and exchange should be considered.
As the I-OP can create new dependencies among participating systems or functional units, these should
be addressed in the contractual framework.
5.2.4 Set up an onboarding and leaving process
The lead stakeholder should set up procedures for onboarding the I-OP and should establish the rules
for out-phasing for when participants leave.
5.3 Plan architecture
5.3.1 General principles
The lead stakeholder should consider the following general principles in establishing the I-OP.
The I-OP creates decentralized data management environments in which participating systems
continue to function independently.
The I-OP requires that UIDs remain unambiguous over all participating services, over a defined or
undefined timespan.
UIDs can be depicted and stored by different print and storage formats, such as
— human readable text,
— barcodes,
— 2D codes,
— RFIDs of different standards, and
— others.
The lead stakeholder should outline which print, storage and reading techniques will be compatible
with the I-OP as planned. It is considered best practice not to narrow down the choice of presentations
to a degree beyond technical necessity or affordability.
The I-OP should be based on trusted functions. Trust levels should be defined for each type of
participating functional unit, such as for
— the receiver of the request (TEP),
— the system that processes the request (TQPF),
— the system that verifies the UID (TVF),
— the system that answers the request (RFF), and
— the information exchanged (ADMS).
The I-OP refers to data exchange among OIASs or their functional blocs, including data
— access,
— retrieval,
— inputs, and
— outputs.
4 © ISO 2018 – All rights reserved

Some OIASs use UIDs which themselves represent a group of subordinate UIDs. For example, the UID
of a shipping box could be related to all UIDs of the items inside, often referred to as aggregated UIDs.
Data exchange can be achieved by
— routing and linking,
— data input, output and exchange, and
— data access and retrieval.
In case of routing and linking, information, which is not predefined or pre-structured, could be accessed,
such as web pages coming as a response from a particular OIAS.
An I-OP can be established among, but is not limited to, systems focusing on
— object verification and authentication,
— supply chain traceability,
— life cycle traceability, or
— others and combinations of systems.
Participating OIASs or participating functional units of an OAIS can provide one, several or all of the above:
— OIASs with diverse focus points that can be connected via the I-OP;
— one OIAS or one functional bloc of OIAS that can connect to several I-OP frameworks simultaneously;
— one UID that can be used by different OIASs and I-OP frameworks.
Consideration should be given to different levels of quality and complexity of identification and
authentication measures without bringing them down to the lowest common denominator.
This guidance is intended to also support pre-existing systems that need to be accessed and continuously
used. This particularly applies for items that require identification during the entire life cycle, whereas
technologies used for an I-OP can evolve further during that life cycle.
5.3.2 Identify participating OIASs and functional blocs to form the constituents of the I-OP
The I-OP designates interoperability among OIASs, as they are independently functioning, or among
functional blocs of an OIAS.
These functional blocs (some of which are described in ISO 16678:2014) can comprise, but are not
limited to
— AAF,
— ADMS,
— I-OP,
— OEF,
— RFF,
— TEP,
— TQPF,
— TVF,
— UID, and
— UIDGF.
The lead stakeholder should
— analyse which of these functional blocs are available or should be created,
— understand which stakeholders are controlling these functions, and
— confirm that this is in line with the contractual framework as established.
5.3.3 Study types and ownership of attributes to be handled
The lead stakeholder, when planning an I-OP, should study the types of attributes involved.
These can be
— attributes of origin (e.g. production batch, production date, manufacturer, expiry date, product name),
— attributes added intentionally by supply chain participants, to add trace or track information, and
— attributes created in the process of verification, and which could be unintentional (e.g. IP address,
date, location of verification).
The choice of architecture should reflect stakeholder expectations and legal obligations towards these
attributes, their confidentiality and ownership.
It should be decided if the interoperable architecture should be delimited to predefined categories of
information, or whether participating services should share information that is non-structured and not
predefined.
NOTE An expiration date is an example of a predefined semantic and syntactic content. A response web page
from a participating OIAS displaying brand specific information is an example of a predefined content and layout.
Depending on the purpose of the I-OP, it should be clarified
— how much information will be shared, and
— how much this sharing will be structured.
After this has been defined, consideration should be given to attribute data
— ownership,
— right to add or change,
— obligation to add or change,
— availability and access rights, and
— security profiles in all aspects of creating, handling and accessing these data.
Use cases for the exchange of structured and unstructured informatio
...