ISO/TR 24014-3:2013

TECHNICAL ISO/TR
REPORT 24014-3
First edition
2013-04-15
Public transport — Interoperable fare
management system —
Part 3:
Complementary concepts to Part 1 for
multi-application media
Transport public — Système de gestion tarifaire interopérable —
Partie 3: Concepts complémentaires à la Partie 1 pour medias
multiapplications
Reference number
©
ISO 2013
© ISO 2013
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
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 2013 – 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 . 4
5 General context and limitations . 4
6 Media functional architecture . 5
6.1 Multi-application . 5
6.2 Functional model of the Media . 5
6.3 Security Domain management . 7
6.4 Composite Customer Media certification and validation . 9
7 Public Transport requirements for multi-application Customer Media .10
7.1 Business requirements .10
7.2 General functional requirements .13
7.3 Secure Element’s profile .13
7.4 Security .14
7.5 Uniqueness .14
8 Insertion of the IFM functional model in the multi-application context .18
8.1 General .18
8.2 Media environment .20
8.3 SE Community .20
8.4 Intermediary Roles .21
8.5 Impact on the roles in the IFM Community.22
8.6 Certification of SE and Application Templates .23
9 Use cases .23
9.1 General .23
9.2 Main sequence diagram .24
9.3 Table of the use cases .25
9.4 Certification of SE .26
9.5 Installation of Application template .26
9.6 Personalisation of pre-installed Application template .27
9.7 Update of Application Template .27
9.8 Termination of application .28
9.9 Termination of SE .28
9.10 Customer service management .28
10 Practices for implementing the use of multi-application .29
10.1 General .29
10.2 Implementation of Roles into Organisations .29
10.3 Legal ownership of the Media and SE .29
10.4 Implementation of the Role of SD manager .29
10.5 Implementation of the Portal function .30
10.6 The EU-IFM Project proposal .31
10.7 Mobile SUICA .32
10.8 France interoperability project .34
10.9 Case of Korea .35
10.10 Comparison with EPC-GSMA white paper .36
Bibliography .39
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
In exceptional circumstances, when a technical committee has collected data of a different kind from
that which is normally published as an International Standard (“state of the art”, for example), it may
decide by a simple majority vote of its participating members to publish a Technical Report. A Technical
Report is entirely informative in nature and does not have to be reviewed until the data it provides are
considered to be no longer valid or useful.
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/TR 24014-3 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
ISO/TR 24014-3 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems in
collaboration with Technical Committee CEN/TC 278, Road transport and traffic telematics.
This first edition is a partial revision of ISO 24014-1:2007.
ISO 24014 consists of the following parts, under the general title Public transport — Interoperable fare
management system:
1)
— Part 1: Architecture
2)
— Part 2: Business practices [Technical Report]
— Part 3: Complementary concepts to Part 1 for multi-application media [Technical Report]
1) International Standard under development.
2) Technical Report under development.
iv © ISO 2013 – All rights reserved

Introduction
This Technical Report explains the functions to be identified by Public Transport stakeholders to set
up Interoperable Fare Management. From that functional view, there was no need to distinguish the
implementation as a stand-alone application from the implementation in a multi-application environment.
Since the publication of ISO 24014-1, multi-application contactless devices have become available such
as multi-application smart cards, USB-keys and mobile phones. They are able to host Public Transport
Applications in embedded or additional Secure Elements.
This Technical Report addresses the introduction of multi-application media into the transit ecosystem
from the organizational and functional perspectives with the objective to provide a basis for transit to
leverage its large customer base.
Only the use of standardized processes can put Public Transport in a position to benefit from such a
multi-application environment
— to diminish investment and operational costs with the use of Media issued by a third party,
— to increase the convenience and interoperability for the customer and therefore the ridership, and
— to make the same service available with multiple solution providers without developing specific
middleware.
This Technical Report therefore acknowledges technical requirements that refer to existing ISO and
non-ISO open standards to favour the convergence of transit Fare Management Systems.
Document outline
The technical points to be harmonized for regional implementations that need to find possibilities of
commercial interoperability are described:
— Common model of the multi functional architecture of the media (Clause 6).
— Requirements for a common management process of the Application Templates in multi-application
media and in the IFM Systems themselves (Clause 7).
The complements to the functional model of Part 1 and to Part 2 when independent Fare Management
Systems decide together to use multi-application media to develop interoperability are described:
— Insertion of the IFM functional model in a multi-application environment, and new roles that are
not included in Part 1 but are necessary for the management of the Media and of the Applications
(see Clause 8).
— Use cases and processes (see Clause 9).
These conclusions may be used to make different IFM Systems interoperable
— When each of them independently issues its Application Template for use in multi-application media.
— When they use a common complementary Application Template for a progressive integration.
TECHNICAL REPORT ISO/TR 24014-3:2013(E)
Public transport — Interoperable fare management
system —
Part 3:
Complementary concepts to Part 1 for multi-application
media
1 Scope
This Technical Report describes how to implement Interoperable Fare Management (IFM) Applications
in a multi-application environment, and the additional roles and use cases that appear.
Multi-application media open new possibilities for separate secure IFM Applications to be loaded and
operated separately on the same Media.
This enables a customer oriented commercial interoperability with the possibility for the customer
to use the same Media in different Fare Management Systems independently of the fare policies and
specific local systems and without the need for any common commercial policies.
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 (all parts), Identification cards — Integrated circuit cards
ISO/IEC 14443-1, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 1:
Physical characteristics
ISO/IEC 14443-2, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 2:
Radio frequency power and signal interface
ISO/IEC 14443-3, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 3:
Initialization and anticollision
ISO/IEC 14443-4, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 4:
Transmission protocol
ISO/IEC 18092, Information technology — Telecommunications and information exchange between
systems — Near Field Communication — Interface and Protocol (NFCIP-1)
ISO 24014-1:2007, Public transport — Interoperable fare management system — Part 1: Architecture
ISO/TR 24014-2, Public transport — Interoperable fare management system — Part 2: Business practices
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 24014-1, ISO/TR 24014-2 and
the following apply.
3.1
media
device that can hold at least one Secure Element
3.2
Customer Media
device that holds a Secure Element initialised with one or more Applications
3.3
Secure Element
SE
physical component, whatever its form factor (embedded, removable or not) that can be installed in a
media to host Applications in a secure environment for their execution
3.4
SE Specification
set of specifications designed to Install, select, process and delete Applications in the SE
3.5
Secure Channel
communication mechanism from any source to a Secure Element that provides the required level of assurance
3.6
Security Domain
SD
software unit providing support for the control, security, and communication requirements of a Role,
e.g. the Application Retailer
2 © ISO 2013 – All rights reserved

Extra part of set of rules
IFM ENVIRONMENT
IFM PARTNERSHIP
PARTNERS
IFIFM M COCOMMUNIMMUNITYTY
IFM Policy
Security
SE sec
Manager
Core part of set of rules
manager
Application
SE
Product
Other
Owner
owner Owner
roles
Application
SE Product
Retailer Registrar
retailer Retailer Service
Operator
SD
Manager
Intermediary
roles
Portal
Customer
Figure 1 — Main terms and definitions illustrated in the functional model
NOTE Figure 1 illustrates the above definitions in the functional model described in this Technical Report.
4 Symbols and abbreviated terms
GP GlobalPlatform
IFM Interoperable Fare Management
IFMS Interoperable Fare Management System
NFC Near Field Communication (refer to ISO/IEC 18092)
PT Public Transport
PTA Public Transport Authority
PTO Public Transport Operator
SCP Secure Channel Protocol
SE Secure Element
SD Security Domain
NOTE The usual term of ‘SD-Card’ may also be used in this Technical Specification in which case it refers to the
particular type of component.
UICC Universal Integrated Circuit Card
5 General context and limitations
This Technical Report first describes objectives and requirements for multi-application management
that are compatible with the type of Applications as described in the use cases of ISO 24014-1, which
require a high security level and must, in the multi-application context, be securely protected against
the other Applications (see Clauses 6 and 7).
A standardized technical architecture and standardised processes are needed to manage a multi-
application environment.
GlobalPlatform is acknowledged to be the only known currently available open standard to meet
the objectives and requirements defined herein. It is therefore proposed as today’s solution for the
standards process.
The internal security process of the Applications remains only dependant on each security policy.
Proprietary materials and methods do exist and may be chosen to address local needs for backward
compatibility, as a business alternative or as an answer to specific customers’ demands with limited
interoperability, despite the risk of unpredictable updates.
Other types of architectures mainly based on direct payment or on back-office centric systems using the
Media as an ID management have different needs and are not considered here.
The Technical Report then describes an extension of the ISO 24014-1 functional model to address
additional roles necessary to operate Applications in the new context independently of the Media form
factor or of its Secure Element (see Clause 8).
The details of applying multi-application to mobile ticketing form factors through the establishment of
associated partnerships agreements that may be needed between mobile network operators and transit
systems operators are not described herein.
The Technical Report does not address the financial processes that are attached to the Fare
Management System.
4 © ISO 2013 – All rights reserved

The ways the Fare Management System can address the variety of payment means, e.g. credit or debit
cards, debit accounts, loyalty programs, bank-to-bank transfers or any access control accounts that may
provide payment, are not described.
The ways they can serve different service operators via a clearing house is also not described.
The use cases provided at the end of this Technical Report are limited to the cases when the set of
Applications installed within the multi-application media accordingly to the customer’s demand is
installed and updated under the responsibility of an organization that is not the customer itself.
Use cases that permit self-managed media are not discussed (see Clause 9).
6 Media functional architecture
6.1 Multi-application
Multi-application in the context of this Technical Report is an environment for the Secure Element (SE)
with the following characteristics as defined in ISO/IEC 7816-13 standard for cards.
(In the following list (a) to (i), the term SE replaces the terms ‘card’ or ‘media’ originally used in
ISO/IEC 7816-13
a) An application is a uniquely addressable set of functionalities on a multi-application media that
provides data storage and computational services.
b) An application may be added to the SE before or after the SE is issued.
c) This Technical Report focuses on Applications that can be added or deleted after the issuance,
independently from the fact that some of them can be installed during the issuance of the SE.
d) More than one application may be added to the SE.
e) The SE platform provides mechanisms for managing SE resources, e.g. memory.
f) The SE platform provides a security boundary mechanism for each application to prevent
unauthorized interaction and security violation from any other application on the SE.
g) The life cycle of an application is independent from the life cycle of any other application in the same SE.
h) The life cycle of an application is independent from the life cycle of the SE except when the SE is in
the termination state, as defined in ISO/IEC 7816-9.
This rule (i) is to be understood technically, independently from any business rules and responsibilities
that can be agreed between the Application Owners and Media Owner.
6.2 Functional model of the Media
The functional architecture of the Media considered in this Technical Report is described by Figure 2.
NOTE Functional blocks drawn with dotted lines are optional.
Figure 2 — Media functional model
The Media is equipped with communication interfaces which may vary and use different protocols and
communication networks or links: USB, 3G/GSM mobile networks, Bluetooth, eSata, Firewire, etc and
may work over the air (OTA)or over the Internet (OTI).
It may also include a direct user interface (display outputs and/or command inputs) and be equipped for
other functionalities.
The Media contains a Secure Element that can host and execute the Applications.
Its operating system includes a security function (drawn as SE sec on Figure 2) that manages multi-
application environment and thus controls the downloading/upgrading/deletion operation of the
Applications.
This SE security function ensures application insulation with firewall and secures that the messages
coming from any communication interface are routed to the appropriate Application.
The routing process is performed without changing the content of the message itself.
A contactless proximity communication compliant with ISO/IEC 14443 or ISO/IEC 18092 standards is
compulsorily implemented.
It can be implemented in the Media itself or in the Secure Element.
For smart cards or contactless USB keys, the Secure Element – which is the card or token microcontroller
chip - will implement the RF protocol stack. For a NFC mobile phone using the UICC as the Secure Element,
the RF protocol stack may be implemented in the mobile phone and not by the Secure Element (UICC).
Each Application contains a set of data and functions.
Among these functions that are internal to the Application is the internal security management of the
Application (shown as App Sec on Figure 2) that remains fully independent from the SE itself.
The credentials required by the applicative security function may depend upon the communication
interface that is used.
6 © ISO 2013 – All rights reserved

As described, this functional architecture is
— Independent from the form factor of the Media itself that may be a contactless or dual (contact and
contactless) interface card, an NFC mobile phone with SE stored in the UICC, a contactless USB key
or take any other form.
It can be used to describe conventional contactless cards as they were considered when ISO 24014-1
was approved:
— The concepts of SE and of Media are merged.
— A contact interface could exist besides the contactless one in dual interface cards.
— Other functions also could exist in dual chip cards.
— No interface to the user existed.
— Independent from the type of implementation of the Secure Element itself inside the Media.
— The SE can be embedded in the Media. In that case, the technical implementation of the security
functions can be shared between the Media and the SE.
It is the case with Java Cards, USB contactless devices, Suica Mobile Handsets:
— The SE can be inserted in the Media.
— In the case of SIM cards, the Media security functions are also used to monitor the GSM link
as well as other functions inside the Media itself.
— In the case of mobiles or other devices equipped with slots for SDcards, the SE is completely
independent from the Media.
— Independent from the location of the necessary facilities (hardware and software) with which the
Application will communicate via the interface. These facilities can be local and accessed via a local
communication interface, e.g. in the contactless reader, or distant and implemented in remote servers.
In relation with this model, the functions of the Medium Access Device [MAD] are split into parts.
— Some communications will address the Media, some will address the Secure Element and some will
address the Application.
— Some communications will be established with local hardware or software facilities, some will
address distant servers.
— Furthermore, each local communication interface may link to a different device.
Similarly, the management and the life cycle of these three elements (Media, SE, Application) can be different.
Hence, new functions are necessary. They are described in Clause 8.
6.3 Security Domain management
Security domains are created in the Secure Element to achieve application insulation and provide the
security context of a specific Application Owner. An Application Template can only be installed in the SE
after a Security Domain has been assigned in the Secure Element to the Application Owner.
The creation of Security Domains and the loading/deletion of the Application templates in the SE have to
be secured and will only be possible using a Secure Channel Protocol (SCP) connection to the SE.
A SCP ensures the confidentiality and the integrity of the application code and of the application data
during application loading and personalisation.
It ensures the mutual authentication between the Secure Element and the system serving a role
(Application Owner, SE Owner, …) and protects the APDUs exchanged between them (over a logical
channel) by encrypting and/or signing each APDU.
In this Technical Report it is considered that this Secure Channel is under control of a role, called SD
Manager which is in charge of handling the commands to create the Security Domains and to let the
Application Retailer move the Application Templates inside them: loading, installation and deletion.
Figures 3, 4 and 5 describe the management process.
Load
Application
Retailer
Platform Identification
SD
SD
Creating or use of existing SD
management
Manager
Loading Loading App Template in SD
SCP link
Installation Defining AID for App Template
Application Template ready for personalisation
Figure 3 — Loading and installation of an Application Template
The personalisation phase of the application can then be performed by the Application Retailer either
using the application specific commands or requiring the SD Manager to use the SCP link to do it
Platform Identification
SD
done
Personalise
management Creating or use of existing SD
Application
Retailer
Loading App Template in SD
Loading done
Defining AID for App Template
SD
Manager
Initialising file structure
SCP link
& related access permissions
Personalisation
Registration of App serial number
Transferring App data & keys
Application commands
Any Link
Application ready for selection
Figure 4 — Personalising an Application
Once the Application Template has been personalised, the Application can be selected and then can be
run with any application specific commands without any need to involve the SD Manager
8 © ISO 2013 – All rights reserved

Platform Identification
SD
done
management Creating or use of existing SD
IFM Loading App Template in SD
Loading done
partners Defining AID for App Template
Initialising file structure
& access permissions
Personalisation
done
Registration of App serial number
Transferring App data & Keys
Life cycle of Products
Application commands
And customer profile
Any Link
Figure 5 — Running an Application
6.4 Composite Customer Media certification and validation
In the current clause, the term ‘Application’ is used for ‘Application Template’.
For mono application Media, the certification process is generally used to be a monolithic process
including the test of the chip, of the operating system and of the Application Template.
In a dynamic multi-application environment where Applications can be pre loaded at the issuance of
the Media or loaded after it, such a certification is not adapted anymore as each introduction of a new
Application cannot imply the full retesting of the complete Media.
The approach named “Composite evaluation” aims at targeting UICC certification in the NFC ecosystem.
This evolutionary certification process aims to be more cost and time effective in Application certification.
It allows the coexistence of standard and secure Applications.
Figure 6 — Composite Certification of a Media (source GlobalPlatfom)
— Chip certification:
Chip certification is achieved nearly as usual via standard Common Criteria certification.
It is managed by chip manufacturers.
— OS certification:
OS certification is specified for a defined perimeter excluding Applications.
It is managed with the Media manufacturer and requires cross industry players to agree on a
Protection Profile per type of Media.
— Initiatives are on going in the EU to define a UICC Protection Profile for the NFC use case with
the involvement of GlobalPlatform, EMVCo, Mobile Network Operators, certification authorities
and SIM vendors.
Some Protection Profiles have already been published [R20].
— Application certification:
Each certification is managed independently from the certification of other Applications.
It is managed by the Application Owner and certification tests are application dependent.
The respect by all the Applications of the OS security guidelines and the certification of the underlying
OS warranty to each Application Owner that its Application is executed in a trusted environment.
Basic Applications require some validation test to ensure that the Application is using the OS platform
in compliance with the security rules defined for OS certification.
Secure Applications go through the same validation test as standard Applications and in addition need to
go through a certification process to ensure that the Application is appropriately protecting its own assets
(keys, sensitive application data, …) according to the security policy defined by the Application Owner.
7 Public Transport requirements for multi-application Customer Media
7.1 Business requirements
7.1.1 Emulation of existing Applications
This Technical Report aims to propose solutions that do not require major changes in the existing IFM
Systems.
It considers the type of Applications as described in ISO 24014-1.
The multi-application media must therefore, whatever its form factor, allow the Application to
communicate as a regular smartcard
— at least when presented to a transport contactless reader such as a validation gate,
— optionally when using other communication channels.
The Media must support proximity exchanges in contactless mode regardless of the other interfaces
that depend on its form factor.
7.1.2 Security
The considered IFM Applications require a high security level and must, in a Multi-Application context,
be securely managed.
Other types of architectures, e.g. using vouchers, coupons or limited to an ID management, are out of the
scope of this Technical Report.
10 © ISO 2013 – All rights reserved

The multi-application media and the associated management processes must ensure that the Applications
and Products inside the Applications are secured both by themselves and against each other.
No level of certification of the chip or OS is specified as a minimum requirement. Each Application Owner
will specify it according to its security policy.
The transit industry requirement (January 2012) currently varies from EAL1+ to EAL 5+ for the chip
certification.
Cross industry Media will need to match the payment industry requirements for IC Chips.
7.1.3 Uniqueness
7.1.3.1 Universality of the communication layers
As a guarantee for universality, all types of Media able to host contactless IFM Applications, including
mobile phones, should be able to host any contactless application that could be used to pay fare products,
such as credit or debit or other payment Applications, loyalty programs, access controls.
7.1.3.2 Management of Applications
The proposed multi-application model must also be open to any type of Media and any communication
link to download/upgrade/delete the Applications.
The objective is therefore to provide a unique and universal management process of the Applications as
illustrated in Figure 7.
Figure 7 — Universality and uniqueness for application management
Figure 7 illustrates the fact that the same process is used to handle the Applications whatever the
communication channel:
— Industrial channel represented as the manufacturing plant for installing Applications in the Secure
Element when it is issued,
— Telephone link for use of NFC phones,
— Internet for accessing the Media via a personal computer,
— Local communication channels for vending machines.
7.1.3.3 Selection of Applications
PT terminals will be in a situation to meet not only PT Applications but also Applications from other
businesses.
The standard activation and anti-collision process is already defined by ISO/IEC 14443.
Application selection according to ISO/IEC 7816-4 has to be mandatorily supported.
For ISO/IEC 7816-4 selectable Applications, standardized AIDs shall be used.
Implicit or default selection processes may be used in dedicated terminals for local Applications.
12 © ISO 2013 – All rights reserved

Depending on the Media capabilities, implicit selection by a recognition algorithm on a first command
shall be possible.
7.2 General functional requirements
In this subclause, the term Media is used for requirements that apply to the Media and the Secure Element
considered together as a whole device, regardless of the implementation of the required features inside
the Secure Element or not.
[Req 1]. The customer can load and manage several (transport) Applications in the same device.
[Req 2]. The Media enables customers to select, buy and load a fare Product through the existing
product retailing channels.
[Req 3]. The Media enables customers to select, buy and load a fare Product remotely, at the user’s
chosen place and time (notably using a mobile phone or a Media connected to the Inter-
net)
[Req 4]. The customer can access the transport network and benefit from the service directly
with the Media.
[Req 5]. When the Media provides a user interface, the customer can use that interface to select
the fare Product or the transport Application he wants to use.
7.3 Secure Element’s profile
[Req 6]. Each Secure Element is assigned an “SE profile” by the SE Owner.
The characteristics of the Secure Element in terms of supported features, available
memory size and execution performance are known by the SE Owner and are important
for the Application Owner to determine if a third party Secure Element can be eligible for
hosting its Application.
There is a need for exchanging such information in a standardized way.
[Req 7]. The SE profile includes a set of information including:
—  List of supported RF protocols;
—  List of supported algorithms;
—  Available memory size;
—  Performance class.
[Req 8]. The way a performance class is assigned to an SE is defined through a universal method.
This can be based on the usage of a public test application providing execution times for
elementary operations (read/ write/crypto computation/etc.) and from which different
performance classes should be derived according to results.
[Req 9]. The SE profile is held on the Media. The SE profile shall be freely accessible in read mode
through all interfaces of the SE.
7.4 Security
The following requirements meet the security objectives previously listed.
[Req 10]. The Media holds a Secure Element which is a microprocessor based Component.
[Req 11]. The Application (and the Products inside the Application) is stored and executed in the
Secure Element.
[Req 12]. The Secure Element ensures an absolute separation between Applications to ensure
integrity and confidentiality of the Application code and data.
[Req 13]. If a common security policy defines a certification process for PT Application, each Appli-
cation Template is certified according to this process.
[Req 14]. The Secure Element supports a set of standard algorithms to offer the cryptographic
capabilities required by the security policies of the current existing transport Application
Templates: DES, 3DES, RSA, AES.
This list may evolve in the future. The ISO TC 204 group should agree collectively those
protocols suitable for Public Transport among the ones enabled by the approved version
of GP to remain compliant with [Req 25]
[Req 15]. Disposable Secure Elements that can be moved from one Media to another one support
the security algorithms independently from the OS of the Media.
[Req 16]. The management of transport Application Templates on the Secure Element is secured by
SCPs.
7.5 Uniqueness
7.5.1 General
Uniqueness requires standard processes and protocols for:
— Contact and contactless interfaces;
— Application management;
— Application selection;
— Application operation.
PT organisations that use proprietary technologies must be aware that it may be a barrier to
interoperability with other IFMs or with other businesses.
7.5.2 Contact and contactless interfaces
[Req 17]. The Media relies on the open industry standards widely used for contactless devices.
Table 1 summarizes the available standardized interfaces per type of Customer Media.
14 © ISO 2013 – All rights reserved

Table 1 — Types of Media and their interfaces
Type of Media SE SE contact interface SE contactless inter-
face
Contactless smart card IC Chip None ISO/IEC 14443
Dual (contact & contactless) smart IC chip ISO/IEC 7816 ISO/IEC 14443
card
a
NFC mobile phone with application UICC ISO/IEC 7816 None
stored in the UICC
a
NFC mobile phone with application Emb. SE ISO/IEC 7816 None
stored in an embedded SE
a
NFC mobile phone with application SD card/ ISO/IEC 7816 ISO/IEC 14443 or None
stored in a removable SE micro SD
Contactless USB key IC chip ISO/IEC 7816 ISO/IEC 14443
over USB protocol
a
For SE into mobile phone, contactless capabilities can be provided by the NFC chip + antenna inside the mobile phone.
The connection between SE and the NFC chip can be either ETSI HCI data protocol or SWP protocol for the UICC or dependent
on mobile phone implementations in other cases.
[Req 18].    The Media supports an ISO/IEC 14443 RF communication protocol.
To improve interoperability between contactless cards and readers, EMVCo has defined
additional requirements for implementing ISO/IEC 14443 communication protocol.
It is premature to evaluate if such recommendations are applicable to IFMSs, but this
evaluation should be done by the transport industry as multi-application devices like NFC
phones will have both to comply with EMVCo RF specifications and to communicate with
transport network contactless readers.
[Req 19]. Other interfaces to access to the SE may be optional.
[Req 20]. The Media behaves like a regular contactless card from a transport network contactless
reader point of view for transactions (validation, ticket top up, inspection …).
[Req 21]. The remote communication channels only support standard protocols:
—  For Internet communications (OTI): HTTP and SSL to communicate with the user’s
browser or a proxy application in a PC,
—  For mobile networks communications (OTA): wireless data connection to communi-
cate with a proxy application in the mobile or directly with the UICC.
7.5.3 Application management
7.5.3.1 GP acceptance
GlobalPlatform has been a field proven application management standard in the banking industry since
the end of the 1990s, and provides specifications for Secure Elements and system to support application
issuance and management into a multi-application environment.
GP Secure Communication Protocols ensure the confidentiality and the integrity of the application code
and of the application data during application loading and personalisation as required.
GlobalPlatform SCPs can also provide authentication and/or mutual authentication between the Secure
Element and the component serving a Role (Application Owner, SE Owner, …).
...