ISO/IEC 24727-4:2008

INTERNATIONAL ISO/IEC
STANDARD 24727-4
First edition
2008-11-01
Identification cards — Integrated circuit
card programming interfaces —
Part 4:
Application programming interface (API)
administration
Cartes d'identification — Interfaces programmables de cartes à puce —
Partie 4: Administration d'interface de programmation (API)

Reference number
©
ISO/IEC 2008
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2008 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 2
4 Abbreviated terms . 3
5 Architecture specialization . 4
5.1 Full-network-stack . 6
5.2 Loyal-stack . 8
5.3 Opaque-ICC-stack. 9
5.4 Remote-loyal-stack. 10
5.5 ICC-resident-stack . 11
5.6 Remote-ICC-stack. 12
6 Security architecture . 12
6.1 Path-protection-policy. 12
6.2 ACL – ACR mapping. 14
6.3 Secure messaging . 14
6.4 Trusted-channel key administration. 15
7 Connection components. 15
7.1 Action request and response semantics. 15
7.2 Proxy – Agent Architecture . 15
7.3 Trusted-channel Interface. 16
7.3.1 TC_API_Open request. 17
7.3.2 TC_API_Close request . 18
7.3.3 TC_API_Read request . 19
7.3.4 TC_API_Write request . 20
7.3.5 TC_API_Reset request . 21
7.3.6 TC_API_GetStatus request . 22
7.4 Interface Device API . 23
7.4.1 Establish Context. 24
7.4.2 ReleaseContext . 25
7.4.3 ListIFDs. 26
7.4.4 GetIFDCapabilities. 27
7.4.5 GetStatus . 30
7.4.6 Wait. 32
7.4.7 Cancel . 33
7.4.8 ControlIFD . 34
7.4.9 Connect. 35
7.4.10 Disconnect. 36
7.4.11 BeginTransaction. 37
7.4.12 EndTransaction. 38
7.4.13 Transmit. 39
7.4.14 VerifyUser . 40
7.4.15 ModifyVerificationData. 43
7.4.16 Output . 45
7.4.17 SignalEvent . 47
© ISO/IEC 2008 – All rights reserved iii

Annex A (normative) Path-protection Mechanisms. 48
Annex B (normative) IFD - API: Web Service Binding . 55
Annex C (normative) IFD-Callback-API - Web Service Binding . 78
Bibliography . 81

iv © ISO/IEC 2008 – All rights reserved

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 and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 24727-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and personal identification.
ISO/IEC 24727 consists of the following parts, under the general title Identification cards — Integrated circuit
card programming interfaces:
⎯ Part 1: Architecture
⎯ Part 2: Generic card interface
⎯ Part 3: Application interface
⎯ Part 4: Application programming interface (API) administration
⎯ Part 5: Testing
⎯ Part 6: Registration authority procedures for the authentication protocols for interoperability

© ISO/IEC 2008 – All rights reserved v

Introduction
ISO/IEC 24727 is a set of programming interfaces for interactions between integrated circuit cards (ICCs) and
external applications to include generic services for multi-sector use. The organization and the operation of
the ICCs conform to ISO/IEC 7816-4.
ISO/IEC 24727 is relevant to ICC applications desiring interoperability among diverse application domains.
ISO/IEC 7498-1:1994 is used as the layered architecture of the client-application to card-application
connectivity. That is, the client-application, through the application interface, assumes that there is a protocol
stack through which it will exchange information and transactions among card-applications using commands
conveyed through the message structures defined in ISO/IEC 7816. The semantics of action requests through
the interface defined in ISO/IEC 24727-3 refers to application protocol data units (APDUs) as characterized
through the interface defined in ISO/IEC 24727-2, and in the following International Standards:
⎯ ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
⎯ ISO/IEC 7816-8:2004, Identification cards — Integrated circuit cards — Part 8: Commands for security
operations
⎯ ISO/IEC 7816-9:2004, Identification cards — Integrated circuit cards — Part 9: Commands for card
management
The goal of ISO/IEC 24727 is to maximize the applicability and solution space of software tools that provide
application interface support to card-aware client-applications. This effort includes supporting the evolution of
card systems as they become more powerful, peer-level partners with existing and future applications while
minimizing the impact to existing solutions conforming to ISO/IEC 24727.
By conforming to this part of ISO/IEC 24727, interoperable implementations of ISO/IEC 24727-3 and
ISO/IEC 24727-2 can be realized. Implementation details are not defined within this part of ISO/IEC 24727; it
is assumed that an implementation conforms to an accepted security policy. The specific security policy is
outside the scope of ISO/IEC 24727.

vi © ISO/IEC 2008 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 24727-4:2008(E)

Identification cards — Integrated circuit card programming
interfaces —
Part 4:
Application programming interface (API) administration
1 Scope
ISO/IEC 24727 defines a set of programming interfaces for interactions between integrated circuit cards and
external applications to include generic services for multi-sector use.
This part of ISO/IEC 24727 standardizes the connectivity and security mechanisms between the client-
application and the card-application.
It specifies API-Administration of service-independent and implementation-independent ISO/IEC 24727
compliant modules, including security, that enables action requests to a specific card-application of an ICC
such that, when coupled to data model and content discovery operations, the card-application can be used by
a variety of client-applications.
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/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 9797-1:1999, Information technology — Security techniques —Message Authentication Codes
(MACs) —Part 1: Mechanisms using a block cipher
ISO/IEC 24727-1, Identification cards — Integrated circuit card programming interfaces — Part 1: Architecture
ISO/IEC 24727-2, Identification cards — Integrated circuit card programming interfaces — Part 2: Generic
card interface
ISO/IEC 24727-3, Identification cards — Integrated circuit card programming interfaces — Part 3: Application
interface
IETF RFC 2246, The TLS Protocol Version 1.0
© ISO/IEC 2008 – All rights reserved 1

3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24727-1, ISO/IEC 24727-2,
ISO/IEC 24727-3 and the following apply.
3.1
channel
physical pathway allowing movement of information bits between a client-application and a card-application
3.2
component
executable code comprising a processing layer accessed with ISO/IEC 24727 defined application
programming interfaces
3.3
confidentiality
access restricted to some defined level of differential-identity authentication
3.4
dubious-channel
channel that might allow information messages to be altered, dropped, replayed or overheard by
eavesdroppers
3.5
instantiation
operational component implementation or communication channel implementation
3.6
integrity
state of immutability of information
3.7
ISO/IEC 24727 protocol stack
series of processing components connected by communication channels that connect a client-application to a
card-application
3.8
loyal-channel
channel that intrinsically maintains the integrity of channel end-points along with the confidentiality, integrity
and authenticity of information
3.9
loyal-platform
computing platform that is trusted to perform data transformations and communication while maintaining
confidentiality, integrity and authenticity of information
3.10
loyal-stack
ISO/IEC 24727 stack in which the full stack from client-application to the integrated circuit card that contains
the card-application is implemented on a single loyal-platform
3.11
path-protection-policy
specification of the security characteristics of all platforms and channels using ISO/IEC 24727 that connect the
client-application to the card-application
2 © ISO/IEC 2008 – All rights reserved

3.12
proxy
application programming interface implementation that conveys action requests and parameters to a layer
implementation located elsewhere
3.13
TC_API
application programming interface used by components of an ISO/IEC 24727 stack to effect the stack's
instantiation in a network environment
3.14
trusted-channel
channel that explicitly assures the confidentiality, integrity and authenticity of information during the transfer
process, independent of the characteristics of the transfer mechanism or media
3.15
trusted-path
connection between a client-application and a card-application in which all platforms and channels have
security characteristics as defined by the client-application
4 Abbreviated terms
TLS - transport layer security
CC - cryptographic checksum
CG - cryptogram
D - decipher
DES - data encryption standard
DO - data object
E - encipher
K - key
Le - expected length
MAC - message authentication code
SSC - send sequence counter
API - application programming interface
APDU - application protocol data unit
© ISO/IEC 2008 – All rights reserved 3

5 Architecture specialization
ISO/IEC 24727-1, ISO/IEC 24727-2 and ISO/IEC 24727-3 define an architecture, application programming
interface and a command-set communication message structure and protocol through which a client-
application can access information and computation services from a card-application. The objective of
ISO/IEC 24727 is to achieve interoperability among diverse implementations of card-applications and client-
applications. ISO/IEC 24727-1 specifies the overarching architecture of ISO/IEC 24727. ISO/IEC 24727-2
specifies a generic request set through which card-application services may be accessed. ISO/IEC 24727-3
specifies the application interface through which client-applications shall access services provided by card-
applications. The architectural overview of ISO/IEC 24727 as illustrated in Figure 1 envisions a variety of
implementations that can satisfy the standard in sufficient detail to successfully conform to the testing
procedures which will be specified in ISO/IEC 24727-5.
Testing
Client Client Client Client
Client
App App App App
cf ISO/IEC
1 2 3 4 24727-5
Card Service APIs cf ISO/IEC 24727-3
Testing ISO/IEC
Interface Connectivity
24727-3
cf ISO/IEC 24727-5
Card Service APIs cf ISO/IEC 24727-3
API Layer Implementation
Generic Card Interface cf ISO/IEC 24727-2
Testing ISO/IEC
Interface Connectivity
24727-2
cf ISO/IEC 24727-5
ISO/IEC 24727-1
Generic Card Interface cf ISO/IEC 24727-2
Architecture
GCI Layer Implementation
Physical Card Services
Interface Connectivity
Interface Device Access Mechanism
Interface Device Configuration Selection
Test
ICC ICC ICC
ICC
1 2 n
Multi-application ICCs
Figure 1 — Specialization of the ISO/IEC 24727 Architecture
This part of ISO/IEC 24727 details the stack instantiation and operational procedures that provide for the
preparation and use of a card-application to provide information storage, retrieval and associated processing
for client-applications.
This part of ISO/IEC 24727 does not mandate a specific implementation methodology, but it does provide a
detailed definition of information organization and content to be supported by any conformant implementation.
An ISO/IEC 24727 conformant stack shall instantiate at least one of the configurations defined in Clause 5.
This clause specifies a variety of instantiation configurations of the ISO/IEC 24727 protocol stack. The
spectrum of configurations range from the full-network-stack to the loyal-stack. The opaque-ICC-stack is a
4 © ISO/IEC 2008 – All rights reserved

ISO/IEC 24727-4
Security & Administration
configuration in which the ISO/IEC 24727-2 instantiation shall be tightly coupled to the card-applications that it
can support; tightly coupled meaning that the connection to the card-application containing ICC through
operating system specific code for accessing an interface device is encompassed by the ISO/IEC 24727-2
instantiation. The remote-loyal-stack considers a configuration in which a loyal-stack shall be utilized on a
platform that is remote from the client-application. The ICC-resident-stack considers a card-application that
shall support the ISO/IEC 24727-3 layer implementation. Finally, the remote-ICC-stack discusses a stack in
which the physical connection of the ICC shall be made to a different platform from the rest of the stack.
It is noted that all parts of ISO/IEC 24727 are neutral with respect to the physical interconnection mechanism
used to complete a communication channel(s) from the client-application to the card-application.
Consequently, references to ICC should be interpreted as being equally applicable to PICC or to non-card
resident card-applications and that references to IFD are equally applicable to PCD or other card-application
containing platform interfaces.
Figure 2 illustrates the generic elements of an ISO/IEC 24727 protocol stack.
Platform 1
app-to-app
Client-Application
stack
SAL - API - Proxy
TC-API
Channel 1
trusted channel
Platform 2
TC-API
Service Access Layer secure messaging (1)
(3)
TC-API
Channel 2 trusted channel
Platform 3
TC-API
ISO/IEC
GCI Layer
Protocol
Stack
secure messaging (2)
IFD API Proxy
TC-API
trusted channel
Channel 3
Platform 4
TC-API
Interface Device
Layer
interface
device
Channel 4
API
card-
application
Figure 2 — Generic Elements of the ISO/IEC 24727 Stack
© ISO/IEC 2008 – All rights reserved 5

These elements define a general stack configuration. This general stack configuration allows a full
ISO/IEC 24727 compliant stack to be segmented across a range of one to four distinct computer platforms. In
Figure 2, these platforms are designated as Platform 1, 2, 3 & 4 respectively.
In a fully segmented stack, four distinct communication channels are required to connected the components
that comprised the stack. These channels are designated as Channel 1, 2, 3 & 4 respectively. In Clause 5.1
through Clause 5.6, six distinct stack configurations are specified. These comprise the set of allowed
ISO/IEC 24727 conformant stacks. A conformant ISO/IEC 24727 stack instantiation shall encompass at least
one of these six stack specifications. A conformant ISO/IEC 24727 stack instantiation may encompass more
than one of these six stack configurations.
Figure 3 provides a descriptive legend to be used in interpreting the details of the remaining figures in
Clause 5.
Figure Legend
Connection Session API
Proxy
Marshalling
Marshalled
Actions &
Parameters
Agent
Layer
Secure
Messaging
Trusted Channel
Proxy - Agent Paradigm
Communication Channel
Interface - either a programming
interface or a communication interface
Software Layer
A software layer is an element
comprised of a software
implementation
Interface Device
Hardware Element
Stack Elements
Figure 3 — Legend for Following Figures
A proxy and agent pair (of processes) allow the extension of an API from one point in a stack to a different
point by conveying the action requests and associated parameters through a standard description; a
procedure known as "marshalling".
5.1 Full-network-stack
A general interconnection between a client-application and a card-application allows each component of the
stack to be connected to its adjacent components by way of a network connection, as illustrated in Figure 4.
The full-network-stack configuration of ISO/IEC 24727 entails a segmentation of the ISO/IEC 24727 stack into
its interoperable constituent components. While it may be unlikely that such a stack configuration shall be
used in a routine operational setting, by testing conformance of this configuration, a fine level of granularity of
component interoperability can be confirmed.
6 © ISO/IEC 2008 – All rights reserved

Realization of a full-network-stack shall be effected through static network configurations of the various
components. Dynamic process invocation of the components is not required by ISO/IEC 24727. The
establishment of end-to-end security characteristics shall be effected through parameters passed through the
ISO/IEC 24727-3 API. Stack instantiation and operation may subsequently entail out-of-band parameter
passing with respect to the ISO/IEC 24727-2 interface, particular in establishing the appropriate keys to
enable subsequent secure messaging between the ISO/IEC 24727-2 layer implementation and the card-
application.
Corresponding stack establishment and connection (and session) security characteristics establishment shall
be met by instantiations of all other stack configurations specified in the various sub-clauses of Clause 5.
Client-Application
SAL API
API Marshalling
TC API
Trusted Channel
Trusted Channel
TC API
SAL API Agent
Service Access
IFD API GCI API
API Marshalling
TC API
Trusted Channel
Independent Trusted
Channel Session Keys
Trusted Channel
TC API
GCI
API
IFD API
Marshalling
TC API
Trusted Channel
Trusted Channel
TC API
Interface Device Agent
Interface Device
Interface Device
Card Application
Stack Configuration
Figure 4 — Networked Connections Between Client-Application and Card-Application
© ISO/IEC 2008 – All rights reserved 7

In Figure 4, the client-application to SAL-API proxy connection is effected by a loyal-channel. All other
communication channels indicated in the figure are dubious-channels. If the path-protection-policy invoked by
the client-application specifies an increased level of security beyond a dubious-channel for any
communication channel, then this level shall be achieved through the use of trusted-channels or, if applicable,
through the use of secure messaging.
The ISO/IEC 24727-3 implementation, ISO/IEC 24727-2 implementation and card broker implementations all
comprise components that shall be effected on trusted platforms if the entire stack is to be viewed as a secure
category beyond a level of intrinsic security and discussed in Clause 6.
5.2 Loyal-stack
As illustrated in Figure 5, a loyal-stack is an implementation of the complete ISO/IEC 24727 stack on a loyal-
platform, hence using loyal-channels for all connections except for any connection to an ICC via an interface
device. For the operating system specific interface device API layer, an enhanced security category shall be
achieved for communication via the interface device to the card-application through the use of secure
messaging.
Client-Application
SAL API
Service Access
GCI
Interface Device
Interface Device
Card Application
Stack Configuration
Figure 5 — Proprietary Implementations of ISO/IEC 24727-2 & ISO/IEC 24727-3 Layers
A loyal-stack shall effect either an intrinsic path-protection-policy category, as defined in Clause 6, or be
completely instantiated in a loyal environment with the only possible dubious-channel being the connection of
the stack to the card-application via an interface device using secure messaging as noted above. The use of
the TC_API is not mandatory when running a secure channel within a Loyal Stack.
8 © ISO/IEC 2008 – All rights reserved

5.3 Opaque-ICC-stack
An opaque-ICC-stack incorporates the ISO/IEC 24727-2 layer instantiation and the interface device layer
instantiation into a single component. This component encompasses the operating system specific connection
via an interface device with the card-application. This component shall exist as a static network accessible
process in which its trusted-channel layer shall present itself as the server component (see IETF RFC 2246) in
the negotiation of a trusted-channel.
Client-Application
SAL API
Service Access
IFD API GCI API
API Marshalling
TC API
Trusted Channel
Trusted Channel
TC API
IFD Agent GCI
Interface Device
Interface Device
Card Application
Stack Configuration
Figure 6 — Opaque ICC Stack
The keys through which to effect secure messaging between the ISO/IEC 24727-2 layer instantiation and the
card-application shall be obtained through the procedural element invoked during the ISO/IEC 24727-2 layer's
bootstrap operation as specified in ISO/IEC 24727-2.
© ISO/IEC 2008 – All rights reserved 9

5.4 Remote-loyal-stack
A remote-loyal-stack segments a loyal-stack into two distinct components, allowing the client-application to be
displaced on a network from its supporting ISO/IEC 24727 stack and the card-application with which it
communicates. An SAL-API proxy component is directly linked to the client-application and this proxy
communicates through a trusted-channel with the remainder of the loyal-stack as illustrated in the Figure 7.
Client-Application
SAL API
API Marshalling
TC API
Trusted Channel
Trusted Channel
TC API
SAL API Agent
Service Access
GCI
Interface Device
Interface Device
Card Application
Stack Configuration
Figure 7 — Remote-loyal-stack
The ISO/IEC 24727-3 layer and ISO/IEC 24727-2 layer component shall exist as a static network accessible
component at the time the remote-loyal-stack is instantiated by action from the client-application. This
component shall exist as a static network accessible process in which its trusted-channel layer shall present
itself as the server component (see IETF RFC 2246) in the negotiation of a trusted-channel with the client-
application component.
10 © ISO/IEC 2008 – All rights reserved

5.5 ICC-resident-stack
An ICC-resident-stack provides the complete ISO/IEC 24727 stack instantiation within a card-application. The
only off-card components are the SAL-API-Proxy and the interface device layer which provide syntactic,
semantic and physical connectivity between the client-application and the card-application as illustrated in
Figure 8. As illustrated in Figure 8, either of two distinct paths can be used in conveying the marshalled API to
the client application. The appropriate path is determined through the addressing returned to the client-
application by the CardApplicationPath request defined in ISO/IEC 24727-3.
Client-Application Client-Application
SAL API
API Marshalling
IFD API
Marshalled API conveyed to
Marshalled API conveyed to
API Marshalling
card-application via on-card
card-application via
TC API
TLS
ENVELOPE apdu
encapsulation
Trusted Channel
Trusted Channel
Card Application Card Application
TC API
Interface Device Agent
Two path mechanisms between
Interface Device
client-application and card-
Interface Device
application
Card Application
Stack Configuration
Figure 8 — ICC Resident Stack
The card-application's trusted-channel layer instantiation shall exist as a static network accessible component
at the time the ISO/IEC 24727 stack is instantiated through action by the client-application. This component
shall exist as a static network accessible process in which its trusted-channel layer shall present itself as the
server entity (see IETF RFC 2246) in the negotiation of a trusted-channel with the client-application
component. Support of TLS by the ICC is not defined by ISO/IEC 7816. The marshalled elements of the SAL
API may also be conveyed to the card-application encapsulated within an ENVELOPE apdu as defined in
ISO/IEC 7816-4 and as indicated in Figure 8.
© ISO/IEC 2008 – All rights reserved 11

5.6 Remote-ICC-stack
Figure 9 illustrates a remote-ICC-stack. In this configuration, the full ISO/IEC 24727 stack is implemented on
the same platform as the client-application. The physical connection point of the card-application may be
present on a different platform from the client-application with a trusted-channel providing connectivity
between the two components of the complete stack.
Client-Application
SAL API
Service Access
GCI
IFD API
API Marshalling
TC API
Trusted Channel
Trusted Channel
TC API
Interface Device Agent
Interface Device
Interface Device
Card Application
Stack Configuration
Figure 9 — Remote-ICC-Stack
In this configuration, the interface device API layer instantiation shall exist as a static network accessible
component at the time of stack instantiation by action of the client-application. This component shall exist as a
static network accessible process in which its trusted-channel layer shall present itself as the server entity
(see IETF RFC 2246) in the negotiation of a trusted-channel with the client-application component.
6 Security architecture
Instantiation of a card-application, including the access control rules used within the card-application to secure
information storage and computational process access, shall be effected by a client-application through the
ISO/IEC 24727-3 API or by a completely functionally equivalent procedure. Connection to an ISO/IEC 24727
stack shall be effected by a client-application through the ISO/IEC 24727-3 API. Stack configurations to be
accessed by a client-application shall be instantiated prior to access by a client-application. Security
characteristics of any stacks made available shall be conveyed from the ISO/IEC 24727-3 layer to the client-
application through the ISO/IEC 24727-3 API CardApplicationPath request response. It shall be the
prerogative of the client-application to select the acceptable stack configuration that provides access to the
desired card-application. Clause 6.1 defines the semantics to be used to describe the stack security
characteristics.
6.1 Path-protection-policy
A conformant ISO/IEC 24727 stack shall effect a communication channel between a client-application and a
card-application via intermediate stack components. As illustrated in Figure 2, these components and adjacent
channels comprise several discrete segments. Each of these segments shall be based on a variety of
12 © ISO/IEC 2008 – All rights reserved

communication mechanisms, each with its own specific set of protocols specified by the stack configuration.
Accordingly, the security characteristics accorded the information flowing between the client-application and
the card-application shall be constrained to the (security) mechanisms specified through the path-protection-
policy established for each stack configuration. The only points of channel access, regardless of stack
configuration, shall be the client-application and the card application. The specification of the path-protection-
policy shall be conveyed to the client-application through the ISO/IEC 24727-3 API as a parameter of the
CardApplicationPath request of the Connection Service.
The coherence of the security characteristics of the communication channel between the client-application
and the card-application shall be characterized by a path-protection-policy-class that shall determine the
granularity of security mechanisms used to effect the channel according to the following definitions:
Path-protection-policy-classes
• end-to-end - a single key or key set shall be used to secure the channel between the client-
application and the card-application.
• segmented - different keys or key sets shall be used to secure the various segments of the
channel between the client-application and the card-application.
• agnostic - no specification is given for the security characteristics of the channel between
the client-application and the card-application; the strength or weakness of the
security characteristics of the channel is immaterial.
Within a specific path-protection-policy-class, various categories of security shall be established by a stack
configuration according to the path-protection-policy-category. The path-protection-policy-category determines
the specific security-facets that shall be achieved by the stack configuration and, implicitly, the mechanisms
that shall be used to effect these facets, according to the following definitions
Path-protection-policy-categories
• Intrinsic - result of platform + channel default facets
• Protected - confidentiality + data integrity
• Source-authenticated - card-application authentication + Protected
• Mutually-authenticated - card-application authentication + Source-authenticated + Protected
The card-application authentication and the Source-authenticated path-protection-policy-categories shall be
effected through the ISO/IEC 24727-3 CardApplicationStartSession request.
The security features to be established according to path-protection-policy-categories, and the implicit
mechanisms that may be used to effect these security-facets, are defined as follows:
Characteristics & Mechanisms
• confidential – eavesdropping prevented across the specific channel segment
(mechanisms)
o confidential-trusted-channel
o loyal-platform
o loyal-channel
• data integrity – data integrity maintained across the specific channel segment
(mechanisms)
o MAC-trusted-channel
o loyal-platform
o loyal-channel
• source integrity – authentication of differential-identity used to access information
(mechanisms)
o client-application authentication (internal-auth)
o client-application authentication (external-auth)
© ISO/IEC 2008 – All rights reserved 13

Due to the composition of the various stack configurations, not all path-protection-policy-classes are available
on all configurations. Table 1 illustrates the most stringent classes that can be achieved on the various stack
configurations defined in Clause 5.
Stack Protected Client-Source Mutual-Auth
Configuration
Loyal end-to-end end-to-end end-to-end
Full-Network segmented segmented segmented
Opaque-ICC segmented segmented segmented
Remote-Loyal segmented segmented segmented
ICC-Resident end-to-end end-to-end segmented
Remote-ICC end-to-end end-to-end segmented
Table 1 — Path-protection-policy-classes per category per stack configuration
In Table 1, "protected" refers to the establishment of data privacy (meaning protection from eavesdroppers)
and data integrity (meaning protection from any change in data values) within the various stack configurations.
"Client-source" refers to the establishment of an authentication state between the client-application and the
card-application or between the card-application and the client-application. "Mutual-auth" refers to the
simultaneous establishment of authentication states in both the client-application and the card-application.
Each element of the table indicates the highest level of path-protection-policy-class that can be achieved for a
specific path-protection-policy-category through a specific type of stack configuration.
Establishing a path between a client-application and a card-application is achieved by the client-application
selecting an acceptable stack configuration that is included as one element the available path(s) returned by
the CardApplicationPath request and then performing a CardApplicationConnect request to establish a
connection to the card-application. More stringent securty characteristics can then be establish by performing
a CardApplicationStartSession with the desired authentication protocol specified.
6.2 ACL – ACR mapping
All access rules defined by access control lists shall be enforced by any conformant ISO/IEC 24727-3 layer
implementation. It is expected that such enforcement will be accomplished by establishing access rules within
the card-application using mechanisms presented by an ISO/IEC 24727-2 layer implementation. This does not
preclude these AR enforcement mechanisms from being augmented by on-ICC or on-PICC mechanisms
where available.
6.3 Secure messaging
Any path-protection-policy that references secure messaging shall use Annex A mechanisms. Secure
messaging shall use common keys at each terminus of the secure messaging pathway in order to compute
the necessary cryptograms required by the Annex A mechanisms. Secure messaging can only be
implemented at the point within the stack at which all communication with the card-application has been
reduced to ISO/IEC 7816-4 compliant APDUs. This point is realized within either the ISO/IEC 24727-3 layer
implementation or the ISO/IEC 24727-2 layer implementation. In order to effect secure messaging, common
keys shall be available at this point as well as within the card-application. The key(s) used to effect secure
messaging within an ISO/IEC 24727-2 layer instantiation may either be intrinsic to the layer or derived by the
procedural elements during the bootstrap operation defined in ISO/IEC 24727-2. The key(s) used to effect
secure messaging within an ISO/IEC 24727-3 layer instantiation shall be provided by the client-application
directly, or through the successful execution of an appropriate authentication protocol.
14 © ISO/IEC 2008 – All rights reserved

Any conformant ISO/IEC 24727-2 layer instantiation that presents a capability to perform secure messaging
shall reside on a loyal-platform.
When an APDU is protected by secure messaging, it may be transmitted as such at the GCI according to
ISO/IEC 24727-2, or as an argument of a REQUEST or CONFIRMATION at the IFD-API.
6.4 Trusted-channel key administration
Security derived from the use of a trusted-channel shall be independent of any secure messaging, or of any
application-to-application security mechanisms used via the ISO/IEC 24727-3 session between a client-
application and a card-application. The trusted-channel encryption mechanisms, including all key
administration, shall be independent of any differential-identity mechanisms used within a card-application.
7 Connection components
The general architecture defined in ISO/IEC 24727-1 identifies a number of discrete components that can be
accessed through interfaces specified by the ISO/IEC 24727 standard.
All ISO/IEC 24727 conformant interfaces shall be uniquely identified through the version numbers established
by the ASN.1 specifications of the interfaces.
7.1 Action request and response semantics
All stack requests from the ISO/IEC 24727-3 API to the card-application shall occur synchronously.
...