ENV ISO 14904:2002

SLOVENSKI STANDARD
01-oktober-2003
Cestna transportna in prometna telematika - Elektronsko pobiranje pristojbin –
Specifikacija vmesnika za poravnave med operaterji (ISO/TS 14904:2002)
Road transport and traffic telematics - Electronic fee collection (EFC) - Interface
specification for clearing between operators (ISO/TS 14904:2002)
Straßenverkehrstelematik - Elektronische Gebührenerfassung (EFC) -
Schnittstellenspezifikation für die Verrechnung zwischen den Betreibern (ISO/TS
14904:2002)
Télématique de la circulation et du transport routier - Perception du télépéage -
Spécification des interfaces pour la compensation des recettes entre opérateurs (ISO/TS
14904:2002)
Ta slovenski standard je istoveten z: ENV ISO 14904:2002
ICS:
03.220.20 Cestni transport Road transport
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 PRESTANDARD
ENV ISO 14904
PRÉNORME EUROPÉENNE
EUROPÄISCHE VORNORM
December 2002
ICS 35.240.60 Supersedes ENV ISO 14904:2002
English version
Road transport and traffic telematics - Electronic fee collection
(EFC) - Interface specification for clearing between operators
(ISO/TS 14904:2002)
Télématique de la circulation et du transport routier - Telematik für den Straßenverkehr und Transport -
Perception du télépéage - Spécification des interfaces pour Elektronische Gebührenerhebung -
la compensation des recettes entre opérateurs (ISO/TS Schnittstellenspezifikation für das Clearing zwischen
14904:2002) Betreibern (ISO/TS 14904:2002)
This European Prestandard (ENV) was approved by CEN on 26 May 2002 as a prospective standard for provisional application.
The period of validity of this ENV is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the ENV can be converted into a European Standard.
CEN members are required to announce the existence of this ENV in the same way as for an EN and to make the ENV available promptly
at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the ENV) until the final
decision about the possible conversion of the ENV into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece,
Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway, Portugal, 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
© 2002 CEN All rights of exploitation in any form and by any means reserved Ref. No. ENV ISO 14904:2002 E
worldwide for CEN national Members.

Contents
page
Contents .2
Foreword.3
1 Introduction.4
2 Scope.5
3 Normative references.5
4 Definitions .6
5 Basic interfaces for clearing between operators .8
6 Interface framework .8
7 Method of description.14
8 Message.15
Annex A (Informative): Conceptual Model .17
Annex B (Informative): Relation between Conceptual and Organisational Models.19
Annex C (Informative): Message frame format .23
Annex D (Informative): Protocol Data Unit.27
Annex E (Informative): Payment Objects based on data elements defined in ISO 8583 .34
Bibliography.35
Foreword
The text of ENV ISO 14904:2002 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 Prestandard supersedes ENV ISO 14094:1997.
In this European Prestandard, the annexes A to F are informative.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this European Prestandard: Austria, Belgium, Czech Republic, Denmark,
Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Malta, Netherlands, Norway,
Portugal, Spain, Sweden, Switzerland and the United Kingdom.
Introduction
Integration of payment systems concerns the co-ordination and handling of all payment services for traffic
and transport applications. This co-ordination involves:
a) the use of a common payment concept for services within or related to road traffic and transport;
b) the enabling of exchange of payment transactions and operational information between different
operators involved in public and private transport services; and
c) the method of payment itself, i.e. the access to electronic payment means, for the settlement of these
acquired services.
In order to enable the integration of payment systems on a higher (e.g. pan-European) level and make
clearing between operators possible, the interfaces involved need to be standardised.
Therefore this European Prestandard / ISO Technical Standard is designed as an interface specification
enabling data to be exchanged between different operators and systems adopting a variety of application
specifications.
It should be noted that although the data structures defined in the current version of the European
Prestandard / ISO Technical Standard reflect a focus on information transfers for clearing purposes, the
interface specification defined herein supports equally well other types of information transfers required
within and between payment systems.
1 Scope
This European Prestandard specifies the interfaces for clearing between operators and gives a framework
of the common message structure and data elements to be used on the interfaces. Its objective is to make
the transfer of payment and Electronic Fee Collection (EFC) related data possible both between different
payment systems and between different operators such as collection agents, clearing operators, or
providers of public and private transport services.
This European Prestandard supports:
a) different payment modes (e.g. pre-payment, post-payment);
b) a wide variety of transport and transport related services (tolling, parking, ferry/bridge/tunnel, public
transport, payment for route guidance etc.);
c) operator services (co-ordination between collectors of money and charge points etc.);
d) security and privacy.
It is not within the scope of this European Prestandard to define administrative procedures and
organisational structures. The specification of a higher (e.g. pan-European) level inter-operable payment
system is outside the scope of this European Prestandard.
Not described within this European Prestandard are indirect (external) participants such as authorities,
enacting general or special legislation concerning the payment system and other national regulations.
The models presented in this standard are generic. Simple systems (closed systems) can be designed by
selecting subsets of the interface framework described herein.
2 Normative references
This European Prestandard incorporates by dated or undated reference, provisions from other publications.
These normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply
to this European Prestandard only when incorporated in it by amendment or revision. For undated
references, the latest edition of the publication referred to applies (including amendments).
Identification cards - Identification of issuer.
ISO 7812,
ISO 7816-5, Identification cards - Integrated circuit cards with contacts - Registration system for
applications in IC cards.
ISO 8583, Financial transaction card originated message - Interchange message specifications.
ISO/IEC 8825-1, Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
ISO 9594, Information technology - The Directory.
ISO 11770-1, Information technology – Security techniques – Key management – Part 1: Framework.
ENV ISO 14816-2, Automatic vehicle and equipment identification - Part 2: Numbering and Data structures.
ENV ISO 14906, Road Transport and Traffic Telematics - Electronic Fee Collection - Application Interface
Definition for Dedicated Short Range Communication.
ENV 1545-1, Identification card systems - Surface transport applications - Part 1: General data elements.
3 Terms and definitions
For the purpose of this European Prestandard, the following terms and definitions apply.
3.1
Apportionment
allocation of money to transport service operators according to the consumption of the services provided,
e.g. a bus operator being paid an amount based on the number of a particular type of customer carried
3.2
Chained Services
combination of services that result in a discount and/or access rights in one or more of the consumed
services. The discount or access rights are usually given to the User as a result of having consumed a
previous service
3.3
Clearing
operation of re-allocating value generated in the payment system(s) between the various operators in a
payment system or between payment systems. This operation reflects commercial agreements existing
between those parties. An example of such an operation is the exchange of information between Service
Providers and an Issuer which enables the transfer of money from the Issuer, collecting the money from the
User, to the Service Provider
3.4
Clearing Operator
entity that collects and possibly aggregates transactions from one or more Service Providers for delivery to
the Issuer(s). The Clearing Operator can also handle the Apportionment between the Service Providers. In
the financial world this operator is equivalent to an Acquirer
3.5
Collection Agent
entity responsible for selling, reloading or delivering the Payment Means to the User and collecting the
payment from the User. The Collection Agent can also collect user related application specific data from
the User
3.6
Contract
expression of an agreement between two or more parties in a payment system or between payment
systems. An example of a contract is the specific relationship between a User and an Operator in a
payment system. The contract in this case defines the conditions under which the user may use the
services and the amount to be charged
3.7
(Intersector) Electronic Purse
application in an Integrated Circuit Card which stores and manipulates electronic value in a secure way and
which replaces cash for payments by the User
3.8
Electronic Fee Collection
collection of a fee for a transport service where the fee is collected via the exchange of data, e.g. via an air-
link communication, enabling the user to pay for the service with electronic values, e.g. an electronic purse
or values stored in a central account
3.9
Enforcement Operator
entity responsible for prosecution on the basis of violation information provided by the Service Providers.
3.10
Integrated Payment Systems
common framework of payment methods and information exchange between operators or payment
systems that makes transfer of money from one payment system or operator to another possible
(Clearing/Apportionment)
3.11
Issuer
entity responsible for the payment system and responsible for issuing the Payment Means to the User
3.12
Operator
generic term for the entities Issuer, Clearing Operator, Collection Agent, Service Provider, Enforcement
Operator or Trusted Third Party
3.13
Payment Means
expression of a Contract between the User and the Issuer (or via a Collection Agent) that allows the User to
access the services available in the Payment System, e.g. an account in a credit card system or an
Electronic Purse
3.14
Payment Method
combination of a Payment Means, a Payment Mode and a Payment Scope
3.15
Payment Mode
parameter defining the time dimension in payment by the User, e.g. Pre-payment or Post-payment
3.16
Payment Scope
application extent of the Payment Method, e.g. national transport or inter-sector
3.17
Payment System
financial system that includes the complete process of Issuing, use of Payment Means, Clearing and
Settlement of transactions
3.18
Service Provider
person, company, authority or abstract entity offering a service to the User for which the user has to pay a
fee (the fee can in some cases be zero, e.g. emergency vehicles)
3.19
Settlement
transfer of funds from one Operator to another according to the Clearing rules
3.20
Trusted Third Party
entity who might be responsible for operation monitoring, system and security assessment (including
security key management) as well as granting licences
3.21
User
entity that uses services provided by the Service Provider according to the terms of the Contract expressed
by the Payment Means. The User receives and reloads the electronic Payment Means through the
Collection Agent
4 Basic interfaces for clearing between operators
This European Prestandard identifies the following basic interfaces required for clearing between operators
within a payment system and between payment systems (see annex A Conceptual Model for further
explanations):
Table 1 – Overview of operator interfaces
Operators interfaced Interfaces covered by Interfaces NOT covered by
the standard the standard
Any Operator to any Operator (see X-
definition of Operator in 3)
User - Service Provider - X
Collection Agent – User - X
NOTE The interface specification defined in this European Prestandard is designed to be flexible enough to
accommodate any additional operator-to-operator information transfer paths which can be required by the integration
and operation of payment systems.
5 Interface framework
5.1 Introduction
Clause 5 defines a common message structure to enable the exchange of data on any of the interfaces
between operators.
The common message structure is summarised in 5.2 and described in more detail in annex C.
NOTE Message class, message type, sender ID, receiver ID and message ID are only normative requirements when
they are not provided by other communication layers.
5.2 Summary of message structure
The message structure shall be transferred either explicitly defined in this standard or implicitly using
services defined by other communication protocols.
EXAMPLE TCP/IP, XML/EDIFACT can be used to transfer messages.
Figure 1 shows graphically an example of the message structure for the Electronic fee Collection (EFC)
related Protocol Data Unit (PDU). The objects shown in the diagram (the information forming the Message
Body) can either be unsecured or secured globally or individually.
Figure 1 - Example of the message structure
5.3 Message header
At the beginning of each message is a message header. The message header contains a version identifier.
The version identifier is an integer that identifies the version of the protocol. As this integer is always the first
element in the sequence, the receiving party is always able to identify the version of the protocol being used
to send the data. This European Prestandard defines version 2 of the protocol.
NOTE ENV ISO 14904:1997 defines version 1 of the protocol.
5.4 Message frame
The message frame may be included in the message structure defined in 5.2. Annex C shows how the
message frame can be formatted.
5.5 Security data
The main objective of Data Protection in EFC systems is to protect the interests of those relying on the EFC
systems, from any harm or damage caused by lack of availability, confidentiality, integrity, non-repudiation
and privacy of personal data.
Part of the information exchanged over the interfaces is covered by this European Prestandard, constituting
an important asset for the respective parties involved. Whilst meeting the security needs of a closed system
remains the domain of the parties concerned, an interface specification constitutes a common ground for
the implementation of real-world interfaces for clearing between operators within the scope of a higher (e.g.
pan-European) level integrated payment system. The interface specification should make sufficient
provision to incorporate current and future security related items.
The security data at the message level and the secured data objects provide support for security related
items. The various security issues can be stated as follows:
Confidentiality Sensitive data and information are available only to authorised parties
(confidentiality of contents);
In addition to pure financial transaction information which may naturally be
subject to tampering, other, more transport related types of information are to
be carried through the same interface (i.e. volumes, type of operations, details
of activities, network etc.). This information can prove very sensitive in an
increasingly competitive environment;
Integrity Sensitive data, information and message sequencing are guarded in such a
way that any alteration or destruction by unauthorised parties is detected
(integrity of contents, integrity of message sequence);
Authentication The origin and destination of information and the entities involved in the
exchange of information are authenticated (message origin authentication,
message destination authentication, peer entity authentication);
Non-repudiation Protection against the denial, by one of the parties involved in the
communication through the interface, of having participated in all or part of the
communications. Support for the following forms of non-repudiation services
may be required:
- Non-repudiation with proof of origin;
- Non-repudiation with proof of delivery;
- Non-repudiation with proof of submission;
Availability Data, information are available to authorised parties;
Auditing/Accountability Protection against anomalies in the flow of transactions by the use of time
variant parameters. This may also include recording of system activity for
security related monitoring purposes.
5.6 Security and Privacy
As EFC systems need to address both data security and privacy issues, defined in the following as a
combined domain called Data Protection, their architecture needs also to provide the adequate support. In
EFC system architectures, and for the purposes of this standard, privacy is taken as being related to the
rights of individual users of the system in respect with the way their personal data is stored and handled
within the EFC system and possibly across EFC systems, e.g. clearing between operators.
5.7 Data Protection Framework
The model shown in Figure 2 provides a general framework for interpreting the primary relationships
between the main issues and elements involved in the planning design and operation of data protection
schemes:
Figure 2 - Data protection framework
In the Operator and Users domain, a data protection policy is defined based on the overall needs and
objectives of the operators and users of the EFC systems, the results of the risk analysis, and the
awareness of the general issues involved in data protection (i.e. data protection principles).
The results of the risk analysis — which consists mainly in an evaluation of the possible threats to the EFC
systems, their probability of occurrence and the possible impact — as well as the data protection policy and
the overall needs and objectives, are used to define detailed and precise Data Protection Requirements.
These requirements are in turn used as the basis for the definition of the measures to be applied in the EFC
systems to counter the threats or minimise their effect. In the associated process the constraints and
additional requirements of the application domain, as well as the costs associated with the measures and
their implementation — in accordance with the proportionality principle — are also taken into account when
defining the countermeasures.
In addition, the legal and institutional framework, as well as the constraints and other requirements of the
application domain need to be considered when establishing the data protection policy and data protection
requirements for the system(s).
Finally, in accordance with the reassessment principle, the system in operation is subjected to auditing
procedures, resulting in an evaluation and a reassessment of the threats, their probability and their impact.
5.8 Data Protection measures
Figure 3 gives an overview of a methodology for specifying the Data Protection:
Figure 3 - Specification of data protection measures
5.9 Keys and keys management
This part provides a general introduction to the use and handling of keys and key management, which is an
important part of clearing between operators. The description is according to ISO 11770-1.
5.9.1 Keys
Keys are a critical part in EFC systems when relying on cryptographic techniques. Keys have to be
protected against disclosure, modification and deletion.
Keys are generally organised in hierarchies, where keys in one level of hierarchy may only be used to
protect keys in the next level, while the lower keys are used for providing the security services. A security
system normally consists of two types of keys:
1) keys that are used for encryption of data;
2) keys that are used for encryption of keys.
Generally the latter need more protection than the first. A so-called Secure Application Module (SAM) may
provide secure storage of keying material.
A cryptographic key undergoes different phases in its life cycle, as shown in Figure 4:
Figure 4 - The life cycle of a cryptographic key
5.9.2 Key management
The objective of key management is to provide secure administration of the key management services. The
key management services are generation, registration, certification, de-registration, distribution, storage,
archiving, recovery, deletion, derivation and destruction of cryptographic keying material.
As shown in Figure 5, several users may use the key management services. In EFC systems this includes
first of all the Service Providers and the Trusted Third Party, but also the other entities are involved in
mainly the distribution service.
Figure 5 - Key management services
A key enters different states depending on the type of security and cryptographic system it consists of. This
means that key management varies between symmetric and asymmetric techniques.
5.9.3 Key distribution
The distribution of keys can be done either within one security domain or between two security domains.
Within one security domain the distribution may be done directly between the two entities that need to share
keys, or it can be done through a Key Distribution Centre, which is a common security authority (e.g. TTP)
that generates and distributes a common key between the two. This latter model may also be used when
the entities belong to two different security domains if they trust the authority of one of the domains. One of
the security authorities then generates and distributes the key to the respective authority of the other
domain, see Figure 6.
Figure 6 - Key distribution
6 Method of description
The data types used in the interface are specified using Abstract Syntax Notation One (ASN.1). This allows
for a flexible, yet unambiguous use of the interface as new data types can be defined that are uniquely
recognisable by interfacing parties.
To encode the data types specified in abstract notation into a transmittable data stream, encoding rules are
used.
To ensure inter-operability on a higher (e.g. pan-European) level, BER (Basic Encoding Rules) as defined
by ISO/IEC 8825-1 shall be used, unless the two interfacing parties have bilateral agreements which specify
the use of other encoding rules.
NOTE 1 ASN.1 (Abstract Syntax Notation One) is a formal language that defines a set of primitive data types and
provides a facility to construct new elements with their own typing inherent in the structure. The data types used in the
interface are specified using Abstract Syntax Notation One (ASN.1). This notation allows for the definition of abstract
syntaxes, enabling application layer standards to define the types of information required to transfer using the
presentation service."
NOTE 2 BER (Basic Encoding Rules) is a transfer syntax notation which maps the ASN.1 into a form where each data
type is encoded as tag, length and value.
NOTE 3 Since all data types are described using ASN.1, they can be transmitted applying different encoding rules. Of
the many encoding rules currently defined two types of encoding rules are most common: BER (Basic Encoding
Rules) and PER (Packed Encoding Rules).
The description includes the basic data elements that two communicating parties need. If additional data
elements are needed, the description can be extended to include these elements. It is also possible for
parties, other than the ones covered by this standard, to engage in a communication using this
communication protocol.
7 Message
The Message type describes the complete data transferred between two operators. The data is contained
within a sequence. See also 5.2 to 5.4 and annex C.
Message ::=
SEQUENCE {
version
INTEGER
{ version1(1),
version2(2) },
data
ProtocolDataUnit
}
To identify different versions of the protocol, the message starts with an integer identifying the version.
Since this integer is always the first element in the sequence, the receiving party is always able to identify
the version of the protocol in use. ENV ISO 14904:1997 defines version 1 of the protocol. This European
Prestandard defines version 2 of the protocol.
The ProtocolDataUnit is a choice between two types of data structures.
ProtocolDataUnit ::=
CHOICE {
EFCrelated [0]
EFCRelated-PDU,
other
EXTERNAL
}
EFCRelated-PDU
CHOICE {
globallySecuredEFCData
EXTERNAL
locallySecuredEFCData
LocallySecuredEFCData
}
NOTE Locally Secured EFC Data means that the data object may or may not be associated with a security object.
This allows data objects to be secured or unsecured individually.
The locallySecuredEFCData is the data structure defined in this European Prestandard.
The EXTERNAL data type allows for data types defined by other standards to be encapsulated in the
ProtocolDataUnit used in this European Prestandard. This could be used for example when two parties
are using an existing standard and want to continue using that standard for some types of data transfers. By
encapsulating that standard within the message structure defined in this European Prestandard, the same
communicating link can be used.
Since the data type is EXTERNAL, no interpretation of the data can be done using this European
Prestandard. The EXTERNAL data type can include identifiers that identify what kind of data is included. The
identities used can either be based on bilateral agreements or defined using global OBJECT IDENTIFIERS.
This European Prestandard does not define any identifiers for this data type EXTERNAL.
Annex A
(informative)
Conceptual Model
The basis for the interface specification defined in this European Prestandard is a conceptual model which
defines the entities present in a generic payment system along with the relations existing between these
entities.
This model was developed to fulfil the following goals:
a) comply with the scope of the European Prestandard;
b) remain valid in a great variety of situations, ranging from simple local transport systems involving only
one service and one organisation to the most complex systems operating on a higher (e.g. pan-
European) level and supporting many types of (chained) services, many service providers, many
collection agents, many issuers and many clearing operators;
c) support different organisational models (subsidiarity principle);
d) retain compatibility with the models
...