EN ISO 24014-1:2007

SLOVENSKI STANDARD
01-februar-2008
Javni prevoz – Interoperabilni sistem vodenja (pre)voznin – 1. del: Arhitektura (ISO
24014-1:2007)
Public transport - Interoperable fare management system - Part 1: Architecture (ISO
24014-1:2007)
Öffentlicher Verkehr - Interoperables Fahrgeldmanagement System - Teil 1: Architekur
(ISO 24014-1:2007)
Transport public - Systeme de gestion tarifaire interopérable - Partie 1: Architecture (ISO
24014-1:2007)
Ta slovenski standard je istoveten z: EN ISO 24014-1:2007
ICS:
03.220.01 Transport na splošno Transport in general
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN ISO 24014-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2007
ICS 35.240.60; 03.220.01
English Version
Public transport - Interoperable fare management system - Part
1: Architecture (ISO 24014-1:2007)
Transport public - Système de gestion tarifaire Öffentlicher Verkehr - Interoperables Fahrgeldmanagement
interopérable - Partie 1: Architecture (ISO 24014-1:2007) System - Teil 1: Architekur (ISO 24014-1:2007)
This European Standard was approved by CEN on 12 March 2007.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as the
official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2007 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 24014-1:2007: E
worldwide for CEN national Members.

Foreword
This document (EN ISO 24014-1:2007) has been prepared by Technical Committee CEN/TC
278 "Road transport and traffic telematics", the secretariat of which is held by NEN, in
collaboration with Technical Committee ISO/TC 204 "Transport information and control
systems".
This European Standard shall be given the status of a national standard, either by publication of
an identical text or by endorsement, at the latest by January 2008, and conflicting national
standards shall be withdrawn at the latest by January 2008.

According to the CEN/CENELEC Internal Regulations, the national standards organizations of
the following countries are bound to implement this European Standard: Austria, Belgium,
Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United
Kingdom.
INTERNATIONAL ISO
STANDARD 24014-1
First edition
2007-07-01
Public transport — Interoperable fare
management system —
Part 1:
Architecture
Transport public — Système de gestion tarifaire interopérable —
Partie 1: Architecture
Reference number
ISO 24014-1:2007(E)
©
ISO 2007
ISO 24014-1:2007(E)
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 2006
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 2007 – All rights reserved

ISO 24014-1:2007(E)
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Terms and definitions. 2
3 Abbreviated terms . 4
4 Requirements . 5
5 Conceptual framework . 5
5.1 Description of Entities. 6
5.2 Basic framework of the generic IFM model . 8
6 The Use Case description for the IFM conceptual model. 9
6.1 Certification . 10
6.2 Registration . 11
6.3 Management of Application. 14
6.4 Management of Product. 16
6.5 Security management. 23
6.6 Customer Service Management (optional). 27
7 System interface identification. 27
8 Identification. 27
8.1 General. 27
8.2 Numbering scheme. 28
8.3 Prerequisites . 28
9 Security in IFMSs. 28
9.1 Protection of the interests of the public. 28
9.2 Assets to be protected . 29
9.3 General IFM security requirements. 29
Annex A (informative) Information flow within the IFM . 31
Annex B (informative) Examples of implementation . 43
Annex C (informative) List of terms which are defined both in this part of ISO 24014 (IFMSA) and
in APTA – UTFS. 53
Annex D (informative) Example of Action List processes . 54
Annex E (informative) Security domain, threats and Protection Profiles. 59
Bibliography . 63

ISO 24014-1:2007(E)
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.
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 24014-1 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with Technical Committee ISO/TC 204,
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
ISO 24014 consists of the following parts, under the general title Public transport — Interoperable fare
management system:
⎯ Part 1: Architecture
iv © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
Introduction
Interoperable fare management (IFM) encompasses all systems and processes designed to manage the
distribution and use of fare products in an interoperable public transport environment.
Such systems are called interoperable when they enable the customer to use a portable electronic medium
(e.g. a contact/contactless smart card) with compatible equipment (e.g. at stops, with retail systems, at
platform entry points or on board vehicles). IFM concepts can also be applied to fare management systems
not using electronic media.
Potential benefits for the customer include reductions in queuing, special and combined fares, one Medium for
multiple applications, loyalty programmes and seamless journeys.
Interoperability of fare management systems also provides benefits to operators and the other parties involved.
However, it requires an overall system architecture that defines the system functionalities, the Actors involved
and their roles, the relationships and the interfaces between them.
Interoperability requires also the definition of a security scheme to protect privacy, integrity and confidentiality
between the Actors to ensure fair and secure data flow within the IFM system (IFMS).
The overall architecture is the subject of this part of ISO 24014, which recognizes the need for legal and
commercial agreements between members of an IFM, but does not specify their form. The technical
specifications of the Component parts, and particularly the standards for Customer Media (e.g. smart cards),
are not included.
Note that there is not one single IFM. Individual operators, consortia of operators, public authorities and
private companies can manage and/or participate in IFMs. An IFM can span country boundaries, and can be
combined with other IFMs. Implementations of IFMSs require security and registration functionalities. This part
of ISO 24014 allows for the distribution of these functions to enable the coordination/convergence of existing
IFMSs to work together.
This part of ISO 24014 is intended to assist the managers of new and existing fare management systems to
find a way conveniently to establish Interoperability for the benefit of their customers.
This part of ISO 24014 intends to provide three main benefits.
a) It provides a framework for an interoperable fare management implementation with a minimum of
complexity.
b) It aims to shorten the time and lower the cost of IFM procurement, as both suppliers and purchasers
understand what is being purchased. Procurement against an open standard reduces cost, as it avoids
the need for expensive bespoke system development and provides for second sourcing.
c) It aims to simplify Interoperability between IFMs to the benefit of all stakeholders.
The work has benefited from the architecture work done in Electronic Fee Collection (CEN/TC 278/WG 1) and
other domains, including the following:
⎯ ISO/TS 14904, Road transport and traffic telematics — Electronic fee collection (EFC) — Interface
specification for clearing between operators;
⎯ ISO/TS 17573, Road Transport and Traffic Telematics — Electronic Fee Collection (EFC) — Systems
architecture for vehicle related transport services;
⎯ existing international data security standards.
INTERNATIONAL STANDARD ISO 24014-1:2007(E)

Public transport — Interoperable fare management system —
Part 1:
Architecture
1 Scope
This part of ISO 24014 provides the basis for the development of multi-operator/multi-service Interoperable
public surface (including subways) transport Fare Management Systems (IFMSs) on a national and
international level.
This part of ISO 24014 is applicable to bodies in public transport and related services which agree that their
systems need to interoperate.
While this part of ISO 24014 does not imply that existing interoperable fare management systems need to be
changed, it applies, so far as it is practically possible, to extensions of these.
This part of ISO 24014 covers the definition of a conceptual framework, which is independent of organisational
and physical implementation. Any reference within this part of ISO 24014 to organisational or physical
implementation is purely informative.
The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and to identify
the requirements that are relevant to ensure Interoperability between several Actors in the context of the use
of electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as
⎯ management of Application;
⎯ management of Products;
⎯ security management;
⎯ certification, registration and identification.
This part of ISO 24014 defines the following main elements:
⎯ identification of the different functional entities in relation to the overall fare management system;
⎯ a generic model of IFMS describing the logical and functional architecture and the interfaces within the
system and with other IFMSs;
⎯ Use Cases describing the interactions and data flows between the different functional entities;
⎯ security requirements.
This part of ISO 24014 excludes consideration of
⎯ the physical Medium and its management;
⎯ the technical aspects of the interface between the Medium and the Medium Access Device;
ISO 24014-1:2007(E)
⎯ the data exchanges between the Medium and the Medium Access Device;
NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other
standardisation committees.
⎯ the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
Action List
list of items related to IFM Applications or Products, downloaded to Medium Access Devices (MADs), actioned
by the MAD if and when a specific IFM Application or Product referenced in the list is encountered by that
MAD
2.2
Actor
user playing a coherent set of roles when interacting with the system within a particular Use Case
NOTE A user can, for instance, be a human, an Organisation or another (sub)system.
2.3
Application Rules
Application Owner requirements
2.4
Application Specification
specification of functions, data elements and security scheme according to the Application Rules
2.5
Application Template
technical master of the Application Specification for implementation
2.6
Application
implemented and initialised Application Template on a Customer Medium
NOTE 1 The Application is identified by a unique identifier.
NOTE 2 The Application houses Products and other optional Customer information (Customer details, Customer
preferences).
2.7
Commercial Rules
rules defining the settlement and commission within the IFMS
2.8
Contract
agreement between two or more Entities
2.9
Component
any piece of hardware and/or software that performs one or more functions in the IFM
2 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
2.10
Component Provider
anyone who wants to bring a Component to the IFMS
2.11
Entity
abstract object performing a set of functions within the IFM
NOTE An entity can exist in the real world (e.g. a service operator), in which case it is called a “legal entity”. It can
also be a model of this real world object (“abstract entity”). This part of ISO 24014 deals with the second kind of entity
(collection of technical functions). It covers the following sets of functions: Application Owner, Application Retailer, Product
Owner, Product Retailer, Service Operator, Collection and Forwarding, Security Manager, Registrar and Customer.
2.12
IFM Policies
commercial, technical and security objectives of IFM
2.13
Interoperability
ability of systems to provide services to, and accept services from, other systems
2.14
Medium
physical carrier of Applications
2.15
Message
set of data elements transferred between two Entities
2.16
Customer Medium
Medium initialised with an Application through an Application Contract
2.17
Medium Access Device
MAD
device with the necessary facilities (hardware and software) to communicate with a Customer Medium
2.18
Organisation
legal entity covering the functions and implied responsibilities of one or more of the following operational
entities: Application Owner, Application Retailer, Product Owner, Product Retailer, Service Operator, and
Collection and Forwarding
2.19
Pricing Rules
rules defining the price and payment relationships to the customer
2.20
Product Rules
set of Usage, Pricing and Commercial Rules defined by the Product Owner
2.21
Product Specification
complete specification of functions, data elements and security scheme according to the Product Rules
2.22
Product Template
technical master of the Product Specification for creating Products
NOTE The Product Template is identified by a unique identifier.
ISO 24014-1:2007(E)
2.23
Product
instance of a Product Template on a Medium stored in an Application
NOTE It is identified by a unique identifier and enables the customer to benefit from a service provided by a Service
Operator.
2.24
Seamless Travel
opportunity for customers to move between one part of an IFMS to any other part of the same or another
IFMS with the minimum of inconvenience, according to their own journey plan using any combination of
transport mode and Service Operator using a single Medium
2.25
Security Policy
security objectives within the IFM Policies
2.26
Set of Rules
regulations for achieving IFM Policies expressed as technical, commercial, security and legal requirements
and standards relevant only to the IFMS
2.27
Trigger
event that causes the execution of a Use Case
2.28
Usage Rules
rules defining the usage time, the usage area, the personal status and the type of service
2.29
Use Case
description of typical interactions between the Actors and the (sub)system itself, capturing the functional
requirements of the (sub)system by defining a sequence of actions performed by one or more Actors and the
system
3 Abbreviated terms
IFM interoperable fare management
IFMS interoperable fare management system
IFMSA interoperable fare management system architecture
PP protection profile
PT public transport
SSS security subsystem
TOE target of evaluation
4 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
4 Requirements
The purpose of ISO 24014 is to achieve Interoperability throughout fare management systems, while making
sure that participating companies in public transport remain as commercially free as possible to design their
own implementation in pursuing their own business strategies.
Specific requirements of the IFMS model are as follows.
⎯ A Customer shall be able to travel with all participating operators (the seamless journey) using a single
Medium.
⎯ There shall be a capability to extract data appropriate to the revenue-sharing and statistical requirements
of the transport operators.
⎯ The same Medium may carry additional Applications; conversely, other media may carry the IFM
Application.
⎯ The ticketing methods associated with the Application shall offer the opportunity to reduce the current
time taken to enter/exit the public transport system and may reduce payment handling costs significantly.
⎯ The IFMS model shall comply with data protection and financial services laws/regulations (e.g. privacy).
⎯ The IFMS model shall provide the capability to accommodate new Product Specifications as required,
regardless of those already in existence.
⎯ The IFMS model shall recognise and prevent internal or external fraud attacks.
⎯ The IFMS model shall identify the customer while protecting their privacy as appropriate.
⎯ The IFMS model shall protect the privacy of the Customer.
⎯ The IFMS model shall assure the integrity of exchanged data.
⎯ The IFMS model shall enable the implementation of additional services: loyalty programmes, car sharing,
park and ride, bike and ride, etc.
⎯ The IFMS model shall provide interface definitions between identified functions within public transport to
enable different operator networks to interoperate.
⎯ The IFMS model shall describe interfaces which are essential to enable data-forwarding functions
between different operator networks, allowing revenue-sharing agreements to be met.
⎯ The IFMS model shall provide a framework from which commercial agreements may be developed.
⎯ The IFMS model shall be neutral with regard to different technologies which may be deployed [e.g.
contact Medium, contactless Medium (short range, wide range), independent of access technologies].
⎯ The IFMS model shall be functionally neutral regarding specific transport Organisation structures.
5 Conceptual framework
The IFMS may be run by a single transport undertaking, a transport authority, an association of public and
private companies, or other groups.
An IFM Manager establishes and manages the IFM Policies on behalf of the IFMS. These policies are
embedded in the Set of Rules.
ISO 24014-1:2007(E)
To manage the elements of the IFMS dealt with in this part of ISO 24014, the IFM Manager shall appoint
⎯ a Security Manager,
⎯ a Registrar.
The functions and the responsibilities of the Security Manager and the Registrar may be distributed to several
Organisations within an IFM. This may be a necessary condition to allow the cooperation of existing IFMSs.
An example is shown in B.3. The example also shows how a new common Set of Rules for the joint IFMS is
built upon the existing sets of the cooperating IFMSs.
5.1 Description of Entities
Entities are identified by capitalized initial letters.
Product Owner The Product Owner is responsible for his Products.
Functions of ownership:
⎯ Specifying pricing, Usage Rules and Commercial Rules.
Functions of clearing:
⎯ Trip reconstruction — Product aggregation based on received usage data using
Product definition rules;
⎯ Linking of aggregated usage data with acquisition data;
⎯ Preparation of apportionment data based on Product Specification.
Functions of reporting:
⎯ Detailed:
⎯ acquisition data with no link to usage data within the reporting period;
⎯ usage data with no link to acquisition data within the reporting period;
⎯ linked aggregated Product data within the reporting period.
⎯ Summary:
⎯ apportionment data and clearing report.
⎯ Total acquisition data.
Product Retailer The Product Retailer sells and terminates Products, collects and refunds value to a
customer as authorised by a Product Owner.
The Product Retailer is the only financial interface between the customer and the IFMS
related to Products.
Application Retailer The Application Retailer sells and terminates Applications, collects and refunds value to
a customer as authorised by an Application Owner.
The Application Retailer is the only financial interface between the customer and the
IFMS related to Applications.
6 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
Collection and The role of Collection and Forwarding is the facilitation of data interchanges of the
Forwarding IFMS. The general functions are data collection and forwarding. They contain at least
the following functions.
Functions of collecting:
⎯ Receiving Application Template from Application Owner.
⎯ Receiving Product Template from Product Owner.
⎯ Receiving data from Service Operators.
⎯ Receiving data from Product Retailer.
⎯ Receiving data from Application Retailer.
⎯ Receiving data from other Collection and Forwarding functions.
⎯ Receiving security list data from Security Manager.
⎯ Receiving clearing reports from Product Owner.
⎯ Consistency and completeness check of the data collected on a technical level.
⎯ Receiving the address list of all Entities in the IFM from the Registrar.
Functions of forwarding:
⎯ Forwarding “Not On Us” data to other Collection and Forwarding functions.
⎯ Recording “Not On Us” data.
⎯ Forwarding data with a corrupt destination address to the Security Manager.
⎯ Forwarding “On Us” data to the Product Owner for clearing and reporting.
⎯ Forwarding clearing reports, Application Template, Product Template and security
list data to the Product Retailer and Service Operator.
⎯ Forwarding Application Templates and security list data to the Application Retailer
and Service Operator.
NOTE The “ON US and NOT ON US” concept is as follows.
⎯ A specific Collection and Forwarding function is to collect data from one IFM Entity and
forward it to other IFM Entities.
⎯ Logically there may be several COLLECTION AND FORWARDING functions within the IFM.
⎯ IFM Entities may be linked to different COLLECTION AND FORWARDING functions, but
each Entity can only be linked to one.
⎯ The concept of “ON US and NOT ON US” addresses this connectivity functionality: Data
held by a specific COLLECTION AND FORWARDING function is either “ON US” or “NOT
ON US” data.
⎯ Data collected by a specific COLLECTION AND FORWARDING function addressed to IFM
Entities directly linked to this COLLECTION AND FORWARDING function is termed “ON
US” data.
⎯ Data collected by a specific COLLECTION AND FORWARDING function addressed to IFM
Entities not linked to this COLLECTION AND FORWARDING function is termed “NOT ON
US” data.
ISO 24014-1:2007(E)
Service Operator The Service Operator provides a service to the customer against the use of a Product.
Application Owner The Application Owner holds the Application Contract for the use of the Application with
the customer.
Customer Service Subject to commercial agreements, Customer Service may provide “helpline” and any
similar facilities, including replacement of stolen and damaged Customer Medium and
consequent Product reinstalling.
Customer The Customer holds an Application and acquires Products in order to use the public
transport services.
Security Manager The Security Manager is responsible for establishing and coordinating the Security
Policy and for
⎯ certification of Organisations, Application Templates, Components and Product
Templates;
⎯ auditing of Organisations, Application Templates/Applications, Components and
Product Templates/Products;
⎯ monitoring the system;
⎯ operation of the security of the IFMS, e.g. key management.
Registrar After the certification, the Registrar issues unique registration codes for Organisations,
Components, Application Templates and Product Templates. The Registrar function
also issues unique identifiers or rules for generating unique identifiers for the
Applications, Products and messages.
5.2 Basic framework of the generic IFM model
The links between the operational Entities of the IFMS are illustrated in Figure 1 — Links between operational
Entities within the IFMS. These links represent information flows. Optional links and Entities are drawn in
dotted lines. It is assumed that the Customer already has a Medium or is provided with one by the Application
Retailer; therefore, the model considers only Application and Product issues. Within an IFMS there may be
several Organisations performing the functions of the Entities.

Figure 1 — Links between operational Entities within the IFMS
8 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
An IFM Manager establishes and manages the IFM Policies on behalf of the IFM. These policies are
embedded in the Set of Rules. The IFM Manager will have relationships with media issuers. The Customer will
have a relationship with the issuer of the Customer Medium they hold. Also, the Application Owner will have
relationships with media issuers.
To manage the elements, the IFM model includes two management Entities:
⎯ the Registrar — the Entity for the identification of any Organisation, Component, Application Template
and Application, Product Template and Product involved in the IFMS;
⎯ the Security Manager — the supporting Entity responsible for the secure operation of the IFMS.
Figure 2 shows the two domains of Entities of the IFM and the connection between them.
The interactions between Entities are described in detail in Clause 6.

Figure 2 — The two IFM domains (operational and management Entities)
6 The Use Case description for the IFM conceptual model
This clause describes Use Cases for the operation of an IFMS. The set of Use Cases described herein
provides a toolbox for the implementation of an IFMS. Where processes described within a Use Case are
implemented within an IFM the Use Case is mandatory.
The following Use Cases describe functional aspects of the IFM. Contractual matters are outside the scope of
this part of ISO 24014 but a prerequisite to implementation.
All Actors in the Use Cases are written in UPPER CASE characters.

ISO 24014-1:2007(E)
6.1 Certification
Each object to be brought into the IFM should meet the IFM requirements. The proof of compliance is given by
checking the object against a Set of Rules. This process is called certification.
Within the IFM, the certification certifies
⎯ Organisations,
⎯ security-related Components,
⎯ Application Specification and Template,
⎯ Product Specification and Template.
The Security Manager is responsible for the certification.
6.1.1 Certification of Organisation
Use Case name Certification of Organisation
Outline Each Organisation which wants to participate in the IFM shall agree to abide by the
Set of Rules.
Triggered by ORGANISATION
Actor(s) SECURITY MANAGER
ORGANISATION
Use Case description If the SECURITY MANAGER confirms that the Organisation agrees to abide by the
Set of Rules,
⎯ the ORGANISATION will be certified,
⎯ else the ORGANISATION will not be certified.

6.1.2 Certification of Components
Use Case name Certification of Components
Outline Each Component to be brought into the IFM shall meet the IFM requirements.
Proof of this is given by checking this Component against a Set of Rules.
Triggered by COMPONENT PROVIDER
Actor(s) SECURITY MANAGER
COMPONENT PROVIDER
Use Case description The SECURITY MANAGER checks the Component against the Set of Rules.
If the Component is compliant with the Set of Rules,
⎯ the Component will be certified,
⎯ else the Component will not be certified.

10 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
6.1.3 Certification of Application Specification and Template
Use Case name Certification of Application Specification and Template
Outline Each Application Specification and Template to be brought into the IFMS shall
meet the IFM requirements. Proof of this is given by checking this Application
Specification and Template against a Set of Rules.
Triggered by APPLICATION OWNER
Actor(s) SECURITY MANAGER
APPLICATION OWNER
Use Case description The SECURITY MANAGER checks the Application Specification and Template
against the Set of Rules.
If the Application Specification and Template is compliant with the Set of Rules,
⎯ the Application Specification and Template will be certified,
⎯ else the Application Specification and Template will not be certified.

6.1.4 Certification of Product Specification and Template
Use Case name Certification of Product Specification and Template
Outline Each Product Specification and Template to be brought into the IFM shall meet the
IFM requirements. Proof of this is given by checking this Product Specification and
Template against a Set of Rules.
Triggered by PRODUCT OWNER
Actor(s) SECURITY MANAGER
PRODUCT OWNER
Use Case description The SECURITY MANAGER checks the Product Specification and Template
against the Set of Rules.
If the Product Specification and Template is compliant with the Set of Rules,
⎯ the Product Specification and Template will be certified,
⎯ else the Product Specification and Template will not be certified.

6.2 Registration
Registration is necessary to ensure that each instance of an object is unique within the IFM. This is
guaranteed by a unique identifier. The process of managing these identifiers is called registration.
Objects and instances of objects within the IFM which have to be registered are the following:
⎯ Organisations,
⎯ Components,
⎯ Application Template and Application,
⎯ Product Template and Product.
The Registrar of the IFM is responsible for the registration process.
ISO 24014-1:2007(E)
6.2.1 Registration of Organisation
Use Case name Registration of Organisation
Outline A unique identification is given to each Organisation.
Triggered by ORGANISATION
Actor(s) REGISTRAR
ORGANISATION
Use Case description The ORGANISATION sends the Organisation certification to the REGISTRAR.
The REGISTRAR returns a unique Organisation identifier to the ORGANISATION.

6.2.2 Registration of Component
Use Case name Registration of Component
Outline A unique identification is given to each Component.
Triggered by COMPONENT PROVIDER
Actor(s) REGISTRAR
COMPONENT PROVIDER
Use Case description The Component certification is sent to the REGISTRAR.
The REGISTRAR returns a unique Component identifier to the Organisation which
asked for registration.
6.2.3 Registration of Application Template
Use Case name Registration of Application Template
Outline A unique identification is given to each Application Template.
Triggered by APPLICATION OWNER
Actor(s) REGISTRAR
APPLICATION OWNER
Use Case description The APPLICATION OWNER sends the Application Template certification to the
REGISTRAR.
The REGISTRAR returns a unique Application Template identifier to the
APPLICATION OWNER.
12 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
6.2.4 Registration of Application
Use Case name Registration of Application
Outline A unique identification is given to each Application.
Triggered by APPLICATION RETAILER
Actor(s) REGISTRAR
APPLICATION RETAILER
Use Case description a) The APPLICATION OWNER sends the Application Template identification to
the REGISTRAR and asks for an Application identification. The REGISTRAR
sends a unique Application identifier to the APPLICATION OWNER. This can
be done for a single identifier as well as for a batch of identifiers.
b) The APPLICATION RETAILER sends the Application Template identification
to the APPLICATION OWNER via the COLLECTION AND FORWARDING
and asks for an Application identification. The APPLICATION OWNER sends
the unique Application identifier via the COLLECTION AND FORWARDING to
the APPLICATION RETAILER.
The processes described in a) and b) could happen at any time in any order.

6.2.5 Registration of Product Template
Use Case name Registration of Product Template
Outline A unique identification is given to each Product Template.
Triggered by PRODUCT OWNER
Actor(s) REGISTRAR
PRODUCT OWNER
Use Case description The PRODUCT OWNER sends the Product Specification certification to the
REGISTRAR.
The REGISTRAR returns a unique Product Template identifier to the PRODUCT
OWNER.
6.2.6 Registration of Product
Use Case name Registration of Product
Outline A unique identification is given to each Product.
Triggered by PRODUCT RETAILER
Actor(s) REGISTRAR
PRODUCT RETAILER
a) The PRODUCT OWNER sends the Product Template identification to the
Use Case description
REGISTRAR and asks for a Product identification. The REGISTRAR sends a
unique Product identifier to the PRODUCT OWNER. This can be done for a
single identifier as well as for a batch of identifiers.
b) The PRODUCT RETAILER sends the Product Template identification to the
PRODUCT OWNER via the COLLECTION AND FORWARDING and asks for
a Product identification. The PRODUCT OWNER sends the unique Product
identifier via the COLLECTION AND FORWARDING to the PRODUCT
RETAILER.
The processes described in a) and b) could happen at any time in any order.
ISO 24014-1:2007(E)
6.3 Management of Application
The Management of Application comprises
⎯ dissemination of Application Templates,
⎯ acquisition of Applications,
⎯ termination of Application Templates,
⎯ termination of Applications.
Only certified and registered Application Templates shall be disseminated.
Updating of Application consists of terminating an Application and acquiring a new Application.
6.3.1 Dissemination of Application Template
Use Case name Dissemination of an Application Template
Outline Dissemination of an Application Template enables the authorised Retailer to sell an
Application and an authorised Service Operator to access this Application.
Triggered by APPLICATION OWNER
Actor(s) APPLICATION RETAILER
COLLECTION AND FORWARDING
SERVICE OPERATOR
APPLICATION OWNER
Use Case description Dissemination of Application Template comprises
⎯ distribution of registered Application Template by APPLICATION OWNER to
the APPLICATION RETAILER via the COLLECTION AND FORWARDING;
⎯ distribution of registered Application Template by APPLICATION OWNER to
the SERVICE OPERATOR via the COLLECTION AND FORWARDING.

6.3.2 Acquisition of Application
Use Case name Acquisition of Application
Outline An Application is loaded on the Customer Medium.
Triggered by CUSTOMER
Actor(s) APPLICATION RETAILER
APPLICATION OWNER
COLLECTION AND FORWARDING
CUSTOMER
Use Case description The authorised APPLICATION RETAILER installs an instance of a registered
Application Template on a Medium.
The APPLICATION RETAILER performs
⎯ installation of the instance of the registered Application Template;
⎯ distribution of the Application identifier and the Application acquisition data to
the APPLICATION OWNER via the COLLECTION AND FORWARDING.
14 © ISO 2007 – All rights reserved

ISO 24014-1:2007(E)
6.3.3 Termination of Application Template
The Use Case “Termination of Application Template” comprises:
⎯ regular termination of Application Template,
⎯ forced termination of Application Template.
6.3.3.1 Regular termination of Application Template
Use Case name Regular termination of Application Template
Outline An Application Template is terminated in the IFM by request of the Application
Owner.
Triggered by APPLICATION OWNER
Actor(s) APPLICATION RETAILER
COLLECTION AND FORWARDING
SERVICE OPERATOR
PRODUCT RETAILER
SECURITY MANAGER
REGISTRAR
APPLICATION OWNER
Use Case description The APPLICATION OWNER wants to terminate the Application Template. This
comprises
⎯ distribution of Termination of registered Application Template to the
APPLICATION RETAILER via the COLLECTION AND FORWARDING;
⎯ distribution of Termination of registered Application Template to the SERVICE
OPERATOR via the COLLECTION AND FORWARDING;
⎯ distribution of Termination of registered Application Template to the
PRODUCT RETAILER via the COLLECTION AND FORWARDING;
⎯ distribution of Termination of registered Application Template to the
SECURITY MANAGER;
⎯ distribution of Termination of registered Application Template to the
REGISTRAR;
⎯ (optional) distribution of Termination of registered Application Template to the
CUSTOMER SERVICE via the COLLECTION AND FORWARDING;
⎯ (optional) the MAD reports the Application Template identifier and Application
Template termination data to the APPLICATION OWNER and SECURITY
MANAGER via the COLLECTION AND FORWARDING.

6.3.3.2 Forced termination of Application Template
Use Ca
...