ISO/IEC TS 22924:2021

TECHNICAL ISO/IEC TS
SPECIFICATION 22924
First edition
2021-05
Identification cards — Transport layer
topologies — Configuration for HCI/
HCP interchange
Cartes d'identification — Topologies de la couche transport —
Configuration pour les échanges HCI/HCP
Reference number
©
ISO/IEC 2021
© ISO/IEC 2021
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms .2
5 Architecture .4
5.1 System architecture view . 4
5.1.1 General. 4
5.1.2 Hosts . 5
5.1.3 Gates . 5
5.1.4 Pipes . 6
5.1.5 Host controller . 7
5.1.6 General aspects on APDU gate . 7
5.2 System architecture with legacy COS . 8
6 Configuration requirements.9
6.1 General . 9
6.2 Logical components of an APDU-enabled host . 9
6.3 Gates registry . 9
6.3.1 General. 9
6.3.2 Administration gate registry .10
6.3.3 Link management gate .11
6.3.4 Identity management gate . .12
6.3.5 Loop back gate .12
6.3.6 APDU gate .13
6.3.7 APDU application gate registry .13
6.4 Example of exchanging APDU via HCI/HCP .13
6.5 APDU transport versus HCP frames .14
6.5.1 General.14
6.5.2 Chaining of T=1 message blocks wrapping HCP packets .15
6.5.3 Handling of error recovery with T=1 features .15
6.6 APDU fragmentation .15
6.7 Supported set of commands and events .15
Annex A (informative) Examples of architecture variants .16
Annex B (informative) Background information .21
Bibliography .26
© ISO/IEC 2021 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
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 or www .iec .ch/ members
_experts/ refdocs).
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) or the IEC
list of patent declarations received (see patents.iec.ch).
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. In the IEC, see www .iec .ch/ understanding -standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and security devices for personal identification.
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 and www .iec .ch/ national
-committees.
iv © ISO/IEC 2021 – All rights reserved

Introduction
This document is laid on the ground of ISO/IEC 7816 (all parts) specifying integrated circuit cards and
the use of such cards for interchange, and on ETSI TS 102 622 defining the HCI core that is an application
independent logical interface.
ETSI TS 102 622 is referenced in this document as a well-known HCI specification, however it should
be noted ETSI TS 102 622 describes another host network with the host controller implemented by
the CLF/NFC controller and with hosts residing on UICCs/SEs all connected to the host controller.
ETSI TS 102 622 allows for other interfaces than SWP for data link layer of HCI, and does not mandate
using the SWP but just describes the condition if the SWP is used.
© ISO/IEC 2021 – All rights reserved v

TECHNICAL SPECIFICATION ISO/IEC TS 22924:2021(E)
Identification cards — Transport layer topologies —
Configuration for HCI/HCP interchange
1 Scope
This document specifies the requirements for a protocol derived from HCI/HCP (see ETSI TS 102 622)
enabling communication for devices regardless of data link and physical layers. This document covers
the following:
a) outline of a system comprised of one or more hosts and one controller;
b) extension of connection topology between hosts and host controller (i.e. star topology and
additional other topologies);
c) segregation between existing system using ETSI TS 102 613 and new system compliant to this
document (this document refers ETSI TS 102 613, but does not change its specification and does not
use RFU).
For ETSI TS 102 622, data link layer and physical layer like SWP specified in ETSI TS 102 613 is out of
the scope.
Albeit questioned in this document, the duplication of OSI transport layer by e.g. enforcing encapsulation
of HCP into T=1 or the reverse, is out of the scope.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical
interface and transmission protocols
ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
APDU gate
entry point to a service processing command APDU inside a host (3.6) or returning response APDU
3.2
APDU application gate
entry point to a service sending command APDU and retrieving correspondent response APDU
© ISO/IEC 2021 – All rights reserved 1

3.3
gate
entry point to a service that is operated inside a host (3.6)
[SOURCE: ETSI TS 102 622]
3.4
HCI network
star-topology network comprised of a host network (3.8) where hosts (3.6) are interconnected with a
host controller (3.7) through HCI
3.5
HCP stack
layout comprised of a routing layer, a messaging layer and a collection of gates (3.3)
3.6
host
logical entity that operates one or more service(s)
[SOURCE: ETSI TS 102 622]
3.7
host controller
host (3.6) that is also responsible for managing a host network (3.8)
[SOURCE: ETSI TS 102 622]
3.8
host network
network of two or more hosts (3.6)
[SOURCE: ETSI TS 102 622]
3.9
managing host
host (3.6) which is in charge of resolving conflicts and interoperability issues between different
contactless applications provided by different hosts
[SOURCE: ETSI TS 102 622]
3.10
pipe
logical communication channel between two gates (3.3) from different hosts (3.6)
[SOURCE: ETSI TS 102 622]
3.11
terminal host
host (3.6) allocated a static identifier HID '01'
4 Symbols and abbreviated terms
ADM_x arbitrary command for administration gate, see ETSI TS 102 622 clause 6.1, e.g. ADM_CRE-
ATE_PIPE
APDU application protocol data unit
API application programming interface
2 © ISO/IEC 2021 – All rights reserved

ANY_x arbitrary command for all gates, see ETSI TS 102 622 clause 6.1, e.g.
ANY_OPEN_PIPE
CB chaining bit
CLF contactless front end
COS card operating system
CPU central processing unit
CRC cyclic redundancy code
DF dedicated file
EVT_x arbitrary event, see ETSI TS 102 622 clause 6.3, e.g. EVT_HOT_PLUG
GID gate identifier
HCI host controller interface
HCP host controller protocol
HID host identifier
I C inter-integrated circuit
ICC integrated circuit card
IFD interface device
IRQ interrupt request
LRC longitudinal redundancy code
NAD node address
NFC near field communication
N(S) send sequence number
OSI Open System Interconnection
PCB protocol control byte
PID pipe identifier
PPS protocol and parameter selection
RF radio frequency
RFU reserved for future use
SCL smart secure platform common layer
SE secure element
SS SPI slave select wire
SSP smart secure platform
SWP single wired protocol
© ISO/IEC 2021 – All rights reserved 3

TPDU transmission protocol data unit
UART universal asynchronous receiver and transmitter
UICC Universal Integrated Circuit Card
USB universal serial bus
eSE (embedded) secure element
5 Architecture
5.1 System architecture view
5.1.1 General
This subclause describes the reference use case architecture where APDU gate fits. This architecture is
based on a star topology where one or more hosts (e.g. secure element, ICC-managed device) physically
connect to a component (e.g. IFD, device controller, contactless frontend) acting as a host controller. In
this topology, the HCI defines the interface between hosts.
Figure 1 — System architecture for reference use case
ICC-managed devices may also make use of off-card devices (see ISO/IEC 18328-1 for use cases and
ISO/IEC 18328-3:2016, Clause 7, for architecture description). The usage of ICC-managed off-card
devices needs a communication with an ICC (or a secure element) through an IFD. The prerequisite for
such communication is a COS or application which can handle additional devices and a host controller
providing the suitable bi-directional communication means. Figure 1 describes this architecture.
NOTE For simplification, drivers and interfaces are not represented on Figure 1.
The reference use case on Figure 1 is deployed on Figure 2 over a general HCP stack. The route conveying
instructions over a pipe created between the two gates is represented.
4 © ISO/IEC 2021 – All rights reserved

Figure 2 — HCI general stack representation
5.1.2 Hosts
This subclause contains a subset of information from ETSI TS 102 622 about hosts.
The identity of a host is coded in a byte named HID. Table 1 lists the reserved values for the HID.
Table 1 — Host identifiers
host HID
host controller '00'
terminal host '01'
a
RFU '02' to ''7F'
dynamically allocated '80' to 'BF'
proprietary 'C0' to 'FE'
b
not allowed 'FF'
a
In this table the value '02' is RFU whereas in ETSI TS 102 622 it is used for UICC host.
b
In this table the value 'FF' is not allowed whereas in ETSI TS 102 622 it is proprietary.
The generic term "host" is used to refer to any host (e.g. terminal host, UICC host) excluding the host
controller.
The dynamically allocated range of values shall be used by the host controller to assign a HID to any
host not identified in Table 1. The host controller shall always assign the same HID to a given host
throughout different sessions as long as there is no modification in the hardware configuration of the
device.
NOTE 1 In ETSI TS 102 622, there is no statement that a HID has to be unique.
NOTE 2 ETSI TS 102 622 does not describe how a host controller assigns an HID to a host.
5.1.3 Gates
This subclause contains a subset of information from ETSI TS 102 622 about gates.
A gate provides an entry point to a service that is operated inside a host. The HCP enables gates from
different hosts to exchange messages. There are two types of gates:
— management gates that are needed for the management of the host network;
— generic gates that are not related to the management of the host network.
© ISO/IEC 2021 – All rights reserved 5

The type of a gate is identified by a GID. GIDs are listed in Table 2 and are either unique within the scope
of a host ('10' to 'FF'), or their values refer to the same gate type for every host ('00' to '0F').
Table 2 — Gate identifiers
gate GID
reserved for proprietary use '00' to '03'
loop back gate '04'
identity management gate '05'
RFU '06' to '0F'
host specific '10' to 'EF'
reserved for proprietary use 'F0' to 'FF'
The GID for the application gates are dynamically assigned by the host running the application gate.
The following rules apply to hosts and gates.
a) All hosts and the host controller shall have one administration gate.
b) All hosts may have one link management gate and the host controller shall have one link
management gate.
c) All hosts and the host controller shall have one identity management gate.
d) All hosts and the host controller shall have one loop back gate.
e) All hosts and the host controller may have one or more generic gates.
5.1.4 Pipes
This subclause contains a subset of information from ETSI TS 102 622 about pipes.
A pipe is a logical communication channel between two gates. There are two types of pipes:
— static pipes that are always available, i.e. they do not need to be created and cannot be deleted;
— dynamic pipes that can be created and deleted.
The state of a pipe is either open or closed. The state shall remain persistent if the hosts are powered
down and up again. It shall also remain persistent if a host is temporarily removed from the host
network and is not replaced by a different device in the meantime. The state of a dynamic pipe after
creation and the initial state of a static pipe shall be closed.
The PID is 7 bits long. The value of PID is used in the header of HCP packets as routing information (see
B.6). For static pipes the PIDs are predefined with values as defined in Table 3. For dynamic pipes, PIDs
are dynamically allocated by the host controller.
Table 3 — Pipe identifiers
PID pipe ending at: pipe type
'00' link management gate
static
'01' administration gate
'02' to '6F' other gate dynamic
'70' to '7F' RFU
The following rules apply to gates and pipes.
a) A static pipe always connects a gate of a host to a gate of the host controller.
6 © ISO/IEC 2021 – All rights reserved

b) A dynamic pipe connects two gates from different hosts.
c) Static and dynamic gates connect to different types of gates; see Table 3 for the mapping.
d) Dynamic PIDs shall be unique in the host network.
5.1.5 Host controller
The host controller can be a dedicated physical device or a software component on a device exposing
the host controller and zero, one or more hosts in the HCI network. The host controller can provide
more than one physical interface. The host controller allocates dynamic HIDs and PIDs as applicable.
A host can request the host controller to create a new dynamic pipe between two gates. The host
requesting the pipe is the source host. If successful, then a pipe is created between the source host and
a destination host. The host controller uses the WHITELIST defined by the destination host in order to
verify that the source host is authorized to create a pipe.
Once a pipe is open between the gates of two hosts, the host controller handles packets of data between
the two hosts based on the routing information provided by the PID in the network field of the HCP
header. In case a packet length exceeds the physical buffers sizes present on the host and on the host
controller, data are transferred in multiple subsequent fragments of the packet, with fragments in
chaining mode specified by the CHAINING field in the HCP header. As the physical buffer size present on
each host interface may vary with each implementation, the host controller may need to perform data
re-assembly and re-segmentation before forwarding it, according to each interface specification.
Data integrity checking and flow control for communications with each host according to specific data
link layer rules applicable for each physical interface is performed on each connection between a host
and the host controller. The host controller should have the ability to set a host into a power saving mode
and resume a host for access with a sequence specific to each physical interface and host architecture.
These elements of the OSI physical layer and data link layer are not defined in this document.
5.1.6 General aspects on APDU gate
According to ETSI TS 102 622, the host sending the APDU command is called the "client APDU host";
and the host receiving and processing the APDU commands is called the "server APDU host". The server
APDU host has an APDU gate with GID='30'. The client APDU host has an APDU application gate.
APDUs shall be as defined in ISO/IEC 7816-4. Usage of both the basic logical channel and further logical
channel(s) is allowed.
Assume a secure element with a physical interface receives command APDU and sends corresponding
response APDU. Its physical interface has a data link layer and a transport protocol for communication.
If such a secure element acts as a server APDU host in an HCI network, then this secure element also has
an APDU gate. The physical interface of such a secure element acts as a pipe to APDU application gates
of other hosts. The APDU gate within such a secure element is the APDU handler of its COS.
A client APDU host shall not create more than one pipe to the APDU gate of a server APDU host. The
APDU gate may accept only an implementation specific maximum concurrent number of pipes from
other client APDU hosts.
The general rules are as follows.
a) A pipe bridges between two gates from two hosts.
b) A pipe identifier in a host shall address a unique gate within the other host.
c) A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless
determined otherwise by the application.
d) A gate shall not send a command or event on a pipe when it is waiting for a response to a previous
command on that pipe.
© ISO/IEC 2021 – All rights reserved 7

HCI interface operates as an abstraction layer regardless of the underlying data link and physical layers,
which leaves to the implementation a wide range of possibilities fitting the eSE with the context.
Interface activation, presence of power saving modes, entering and exiting a power saving mode,
electrical parameters for a certain interface and handling of communication errors are outside the
scope of this document and dedicated to physical layer and data link layer.
The underlying data link layer may vary depending on the ecosystem. As a general rule it is expected
that a data link layer definition should meet the following properties.
— The data link layer ensures data is error free and the order of the received/sent data is respected.
— The data link layer provides its own data flow control.
— The data link layer delivers packets of the upper layer up to a maximum size specific to the data link
layer.
— The data link layer reports the size of each received packet to its upper layer.
5.2 System architecture with legacy COS
In this subclause it is assumed that an eSE is connected to an HCI network, but the physical interface
of the eSE is not compatible with the HCI (legacy COS). In that case the implementation of the server
APDU host (host A in Figure 3) connects to the eSE using a specific driver. Figure 3 shows the complete
communication path from a client APDU host (host B in Figure 3), via the host controller, through host A
and driver to the eSE. Please note, that the communication path between host A and host B in Figure 3
is identical to Figure 2, although Figure 3 does not show any detail from Figure 2.
Figure 3 shows how HCI is an abstraction layer to the eSE, and how the route through an HCI pipe
stretches from the APDU application gate to the legacy COS of the eSE. This pipe is logical and does not
require necessarily a wired connection.
NOTE 1 Host A in Figure 3 can run on the same hardware as the host controller e.g. as an embedded software
that emulates the eSE.
NOTE 2 Host B can run on the same hardware as the host controller e.g. a mobile controller.
Key
legacy route
HCP route
Figure 3 — HCI stack representation with legacy COS support
Further architecture variants with legacy secure element are described in Annex A.
8 © ISO/IEC 2021 – All rights reserved

6 Configuration requirements
6.1 General
This clause describes the required configuration for a host providing APDU gate service.
6.2 Logical components of an APDU-enabled host
A host supporting the present HCI/HCP specification and able to handle APDUs shall be implemented
with, in addition to the APDU gate, the following other gates:
a) one (mandatory)administration gate allowing:
1) to create and delete dynamic pipes (access to services that manage the network of pipes in
HCI);
2) the management of permissions through WHITELISTS (each host informs the host controller
with its WHITELIST about which other hosts are allowed to communicate with it);
3) the discovery of hosts at the first start-up or when configuration has changed;
4) the management of sessions (session ID changes whenever the host configuration changes);
b) one link management gate allowing:
1) the management of the underlying transport layer (i.e. number of invalid or lost frames due to
communication error);
2) EVT_HCI_END_OF_OPERATION to be sent by a host to the host controller over the pipe
connecting the host and host controller link management gate to announce host entry into
a power saving mode and requiring a resume sequence before a next access (the resume
sequence is expected to be defined in other specifications describing the lower OSI layers).
c) one (mandatory) loopback gate allowing to verify pipe connectivity (for tests purposes);
d) one (mandatory) identity management gate allowing the discovery of software and hardware
information about the APDU-enabled host;
e) generic (optional) gate(s) allowing various service(s) supported by the host.
6.3 Gates registry
6.3.1 General
This subclause describes the required entries of the registry respective to each gate present in a host
and in the host controller. General rules related to registries are as follows:
a) A registry template defining parameters related to the gate may be associated with such a gate.
b) Within a registry, parameters are identified by identifiers consisting of one byte; parameter
identifiers are unique within the scope of the gate; a new instance of the registry is created for
every pipe that connects to the gate.
c) Upon pipe creation all registry parameters shall be set to their default values. A host is responsible
for managing its associated registries. When a pipe is deleted, its registry instance is also deleted.
© ISO/IEC 2021 – All rights reserved 9

6.3.2 Administration gate registry
6.3.2.1 Host controller administration gate
This subclause contains a subset of information from ETSI TS 102 622 about host controller
administration gate.
The administration gate in the host controller provides access to services that manage the network of
pipes in the HCI network. In addition, this gate provides access to services that allow the discovery of
hosts at the first startup and when the configuration of the host network has changed. The registry
shall be persistent.
Table 4 lists the entries in the gate registry. The values of HOST_LIST and HOST_TYPE_LIST shall
be updated if a host is connected to or disconnected from the host controller. The value of MH_
AVAILABILITY_STATE shall be updated to reflect current managing host availability.
Table 4 — Entries in the host controller administration gate registry
Len/
a b c
Type ID Parameter AR Comment Default
byte
'FFFF
Session identifier that is used to detect if FFFF
M '01' SESSION_IDENTITY RW 8
the connected host configuration changed. FFFF
FFFF'
Maximum number of created dynamic pipes
M '02' MAX_PIPE RO 1 '10'
supported by the host controller per host.
List of hosts that may communicate with
M '03' WHITELIST RW the host connected to this administration N empty
gate. Each entry in this list is a HID.
The list of the hosts that are accessible from
M '04' HOST_LIST RO this host controller including the host con- N '00'
troller itself. Each entry in this list is a HID.
HID of the host connected on this pipe either no default
M '05' HOST_ID RO 1
statically or dynamically assigned. value
Type of host connected on this pipe. The first
byte defines the host type family and the
M '06' HOST_TYPE RW 2 'FFFF'
second byte defines variant of this type and
is defined by the respective organizations.
The list of
...