ISO/TS 21193:2019
(Main)Electronic fee collection — Requirements for EFC application interfaces on common media
Electronic fee collection — Requirements for EFC application interfaces on common media
This document defines requirements to support information exchanges among related entities of a common payment scheme. It defines: a) electronic fee collection (EFC) functional requirements for a common payment medium; b) an application structure in a common payment medium; c) EFC application data in a common payment medium. The following are outside the scope of this document: — requirements and data definitions for any other transport services such as public transport; — a complete risk assessment for an EFC system using a common payment medium; — security issues arising from an EFC application among all transport services; — the technical trust relationship between a CSRP and a service user; — concrete implementation specifications for implementation of security for an EFC system; — detailed specifications required for privacy-friendly EFC implementations; — any financial transactions of the CSRP.
Perception du télépéage — Exigences relatives aux interfaces d'application de télépéage sur média commun
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 21193
First edition
2019-10
Electronic fee collection —
Requirements for EFC application
interfaces on common media
Perception du télépéage — Exigences relatives aux interfaces
d'application de télépéage sur média commun
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – 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 . 3
5 Requirements for a common payment medium . 4
5.1 Requirements for EFC architecture . 4
5.2 EFC functional requirements . 5
6 Application structure in a common payment medium . 9
7 EFC application data in a common payment medium . 9
7.1 General . 9
7.2 EFC attribute data for a common payment medium .10
7.3 Additional EFC attribute data .11
7.3.1 Data group RECEIPT .11
7.3.2 Data group PAYMENT .12
Annex A (normative) Data type specifications .14
Annex B (normative) Implementation conformance statement (ICS) pro forma .15
Annex C (informative) Common payment medium concept .19
Annex D (informative) Application structure examples in common payment medium .21
Annex E (informative) General information for common payment medium and OBE .23
Annex F (informative) System migration .25
Annex G (informative) Reloading system for pre-payment medium in Korean ETC .28
Annex H (informative) EFC security requirements for common payment medium and EFC
scheme .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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved
Introduction
Transportation network improvement, including road and railway, is essential to drive economic
growth. Integrated transport service has been aimed at topics such as user convenience, transport
safety, reliability, efficiency and availability. For example, a traffic manager can find which kinds of
improvements are needed to relieve traffic bottlenecks by analysing user transport flows in a transport
system considered as a whole.
It is usually necessary to use different transport services to transfer people or goods from origin to
destination. Sometimes, using different transport services in the same trip becomes cumbersome when
transport services are operated by different operators, e.g. bad interconnections between different
transport modes due to user needs to search and compare transportation modes, need for separate
charging or payment for the transport services used. The connections between different transport
modes and the means to achieve seamless travel are improving with the use of information and
communication technologies (ICT).
ISO/TR 19639 investigated case studies on the use of a common payment medium when combining
public transport services and road services, based on the use of a common payment schema. This
common payment schema is further categorised into integrated central accounts and integrated on-
board accounts.
ISO/TR 19639 concluded by stating the need for new electronic fee collection (EFC) standards to
support on-board integrated accounts, among which is an application interface between the common
payment medium and the common service rights provider (CSRP). The background of on-board
accounts in EFC are:
— Operational methods of EFC systems might be different due to regional and local circumstances. EFC
systems can be classified into central accounts and on-board accounts, using a common payment
medium, which are widely adopted in Asian countries.
— On-board account payment media are commonly used for public transport in several countries, e.g.
Singapore, Malaysia and China.
— Central payment accounts are considered one of the common service rights methods explained in
ISO/TR 20526, whereas the EFC standards are currently predominantly based on a central account.
— A convergence on the usage of on-board account for both EFC systems and public transport should
be considered.
This document describes an EFC application as one type of transport service specific application and
the application interface requirements for a common service rights application. A common service
rights application is explained in informative Annex C of this document for understanding a common
payment scheme based on this concept as shown in Figure 1.
Figure 1 — Common payment medium concept for EFC scheme
Arrow lines (4) labelled 'money' and 'e-money' are monetary flows and out scope of this document.
Arrow line (2) labelled 'Transport service' is not an ICT interface but a physical transport service.
Other arrow lines are in the scope of ISO/TC 204 (EFC and public transport standards) and the thick
arrow line between common payment medium and OBE is within the scope of this document.
This document will extend the set of EFC standards to allow provisions for multi-modal transport
services by using a common payment medium.
This document defines among others, the role and responsibilities of a CSRP. The CSRP provides
a common payment medium for enabling use of EFC, a public transport service and retail shopping
service to service users with one account. CSRP may provide the usage record of user's multi modal
transport trip as a form of customer service.
This document contains a number of annexes. Data type specifications are given in Annex A, an
implementation conformance statement (ICS) proforma is given in Annex B. The common payment
medium concept for any transport service is presented in Annex C. General kinds of application
structure in a medium are presented in Annex D. General requirements from medium relating standards
is presented in Annex E. A typical system migration method and technical solution supporting medium
upgrading are presented in Annex F. Examples of reloading types and transactions are presented in
Annex G. The EFC security requirements for a common payment medium are presented in Annex H
based on EFC functional requirements.
The scope of this document includes an EFC application interface for a common payment medium as
shown in Figure 2, as well as the role and responsibilities of a Common Service Rights Provider (CSRP).
NOTE Figure 2 explains the relation of CSRP among related sectors including EFC. E-money is exchanged
between the Transport Service Provider (TSP) in the EFC sector and the CSRP. E-money is exchanged between
retail in the commerce sector and the CSRP.
vi © ISO 2019 – All rights reserved
Figure 2 — Scope within the EFC computational architecture
TECHNICAL SPECIFICATION ISO/TS 21193:2019(E)
Electronic fee collection — Requirements for EFC
application interfaces on common media
1 Scope
This document defines requirements to support information exchanges among related entities of a
common payment scheme. It defines:
a) electronic fee collection (EFC) functional requirements for a common payment medium;
b) an application structure in a common payment medium;
c) EFC application data in a common payment medium.
The following are outside the scope of this document:
— requirements and data definitions for any other transport services such as public transport;
— a complete risk assessment for an EFC system using a common payment medium;
— security issues arising from an EFC application among all transport services;
— the technical trust relationship between a CSRP and a service user;
— concrete implementation specifications for implementation of security for an EFC system;
— detailed specifications required for privacy-friendly EFC implementations;
— any financial transactions of the CSRP.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 14906:2018, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17573-1:2019, Electronic fee collection — System architecture for vehicle-related tolling — Part 1:
Reference model
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
central account
payment means (3.11) or common service rights in an electronic fee collection (EFC) system, stored in a
central system
3.2
common service rights
rights to use services offered by several toll domains or more than one transport mode
EXAMPLE Usage allowance for a number of trips or for a certain time span.
3.3
common service rights provider
CSRP
entity providing common service rights (3.2) to the service user
3.4
EFC architecture
description of the key elements of an electronic fee collection (EFC) system, their functions and
interrelationships
3.5
electronic money
e-money
value having its equivalence in real money, electronically stored, e.g. in a bank account or an IC-card,
which can be used by the user for payments
3.6
fare collection regime
set of rules, including enforcement rules, governing the fare system in the public transport domain
3.7
integrated circuit card
IC card
ICC
card with electronic components performing processing or memory functions with the capability to
communicate with an interrogator
Note 1 to entry: Contact IC cards are specified in the ISO/IEC 7816 series of standards, contactless proximity
IC cards are specified in the ISO/IEC 14443 series of standards, contactless near-field communication IC cards
are specified in ISO/IEC 18092 and ISO/IEC 21481, whereas contactless vicinity IC cards are specified in the
ISO/IEC 15693 series of standards.
Note 2 to entry: All references to an IC card are understood to be references to the IC of the card and not to any
other storage on the card (e.g. magnetic stripe).
3.8
issuer
entity responsible for issuing the payment means (3.11) to the user
3.9
multi-modal transport
the transportation performed with at least two different means of transport
3.10
on-board account
payment means (3.11) or common service rights (3.2) in an electronic fee collection (EFC) system, stored
on-board either in a payment medium (3.12) (e.g. IC card) or in an on-board equipment
3.11
payment means
value in an on-board account (3.10) (e.g. cash, tokens or stored electronic values) or a reference to a
central account (3.1) (e.g. a fleet card, bank account, credit card number or a contract ID) that gives the
user access to available services
2 © ISO 2019 – All rights reserved
3.12
payment medium
carrier of payment means (3.11)
EXAMPLE Paper ticket, IC-card, smart phone.
3.13
public transport services
shared passenger transport service which is available for use by the public
EXAMPLE Bus, tram, train.
3.14
sensitive EFC data
EFC related data, either the data itself or combined with other EFC related data, that could be used for
identifying an EFC user
3.15
toll regime
set of rules, including enforcement rules, governing the collection of a toll in a toll domain
[SOURCE: ISO 17573-1:2019, 3.18]
3.16
transaction model
functional model describing the structure of electronic payment transactions
[SOURCE: ISO 14906:2018, 3.17]
4 Symbols and abbreviated terms
CSR Common Service Rights
CSRP Common Service Rights Provider
DSRC Dedicated Short-Range Communications
EFC Electronic Fee Collection
ETC Electronic Toll Collection
OBE On-Board Equipment
PCI DSS Payment Card Industry Data Security Standard
PT Public Transport
RSE Roadside Equipment
RSU Roadside Unit
SAM Secure Access Module
SLA Service Level Agreement
SU Service User
TC Toll Charger
TSP Transport Service Provider
5 Requirements for a common payment medium
5.1 Requirements for EFC architecture
Any EFC architecture using a common payment medium shall comply with the EFC Roles model defined
in ISO 17573-1. The relation of role and responsibility of the "Provision of common service rights" and
the EFC role model described in ISO 17573-1 is shown in Figure 3 when enabling interoperability with
any transport services. The role of a common service rights provision includes a part of EFC function for
EFC regime. As an example, the EFC transaction data described in ISO 14906 and ISO 17575-1 include
account information stored in the common payment medium. The EFC role model belongs to the tolling
domain and the "Provision of the common service rights" role belongs to another domain, but the two
domains are linked together by the use of common service rights in EFC.
NOTE ISO 17573-1 also explains how any EFC-specific common payment medium is used when there is no
interoperability with other transport services.
Figure 3 — EFC role model with provision of common service rights
The role related to CSRP is responsible for providing the basic artefacts, mechanism, organizational
structure, and information transfer tools needed to integrate an interoperable EFC system into a multi-
modal transport system.
Responsibilities related to this role are only restricted to CSRP and include:
— providing basic provision, including
— providing a common payment medium,
— guaranteeing that the entity performing the charging of the transport service rights role will be
paid for it,
— providing the common service rights to the user or accepting an existing one,
— collecting the money from the signer of the EFC service contract and performing reloading
transaction for common payment medium,
— collecting all transport service transactions, clearing and distributing the money to the
Transport Service Provider (TSP),
— managing the customer relationships related to the use of the transport service concerning
information, claims, questions and answers, error handling and any contractual or financial
matters,
— implementing and adhering to the security and privacy policies for the transport systems, and
4 © ISO 2019 – All rights reserved
— monitoring the actual operational quality relative to agreed service level agreements (SLAs);
— acting as a contract agent, including
— offering contractual relations according to defined conditions to interested users and concluding
contractual agreements, and
The user needs to contract both use of OBE and use of common payment medium for EFC service.
— providing and managing the transport service contract including the service rights for the toll
service user;
— customizing the common payment medium, including
— customizing the common payment medium in a secure way;
— maintaining the common payment medium, including
— maintaining the functionality of the common payment medium,
— maintaining the hot listing of the common payment medium, and
— performing the refund of values stored on the common payment medium.
A common service right provider may make requirements to the TSP such as protecting some data,
security keys and so on for the TSP, toll service provider in an EFC environment.
5.2 EFC functional requirements
While an OBE is generally related to a vehicle, a common payment medium can be carried by the owner/
user also for use outside a vehicle. This means that the common payment medium should be considered
from the following points of view:
— Enabling the use in all transaction models, for payment modes (pre-pay and/or post pay) and
applying security requirements.
— Enabling the use of the EFC service with an OBE.
NOTE Enabling flexible EFC operation both with OBE and without OBE.
— Enabling confirmation of account information and usage record of service as basic user services.
Based on these viewpoints, requirements are derived for support of a common payment medium, as
shown in Table 1.
Table 1 — Basic EFC functional requirements
Functional EFC function item Functional requirement for a common
areas payment medium
Transaction types Closed Toll - Entry Transaction — Common payment medium shall be usable for all
transaction types with OBE
Closed Toll - Exit Transaction
— Common payment medium shall store EFC
Open Toll Transaction
contract information
Transit Transaction
— Common payment medium shall securely store
Checking Transaction
a minimum of 3 usage log entries including
Purse Reloading Transaction
transaction type and date and time for use of a
service
— Common payment medium shall store the entry
a
data for closed tolling system with OBE
Payment types Central Account — Common payment medium shall be usable for all
payment types
On-Board Account
— Common payment medium shall be usable for
Pre-Payment
common payment among transport services
Post-Payment
— Common payment medium shall be usable for
Electronic Purse Based Payment
reloading transaction if user signed a contract
Token Based Payment
'Open'(multiple service) Payment
System
'Closed'(single service) Payment
System
No/Zero Payment
Refunding
Contract types Area Dependent Contract — Common payment medium shall be usable for all
contract types
Time Dependent Contract
— Common payment medium shall be usable with
Vehicle Dependent Contract
OBE for vehicle dependent contract since vehicle
Person Dependent Contract
information is stored in OBE. Otherwise RSE shall
detect vehicle information for this contract when
Group of Persons Dependent
only common payment medium is used.
Contract
Anonymous Contract
Contract Contract Selection — Common payment medium shall be able to store
b
handling multiple contract information if necessary
Implicit Contract
Explicit Contract
Multiple Simultaneous Contracts
a
This also enables performing flexible EFC operations both with OBE and without OBE.
b
Multiple application access method is defined in ISO/IEC 7816-4.
6 © ISO 2019 – All rights reserved
Table 1 (continued)
Functional EFC function item Functional requirement for a common
areas payment medium
Security One Way Authentication — Common payment medium shall implement the
mechanism required security function(s)
Two Way Authentication
— Common service right provider as a common
Data Integrity Mechanism
payment medium issuer shall provide secure
No Specific Security
processing environment to toll service provider
Segment Integrity Mechanism
Signature Based Mechanism
Time/Event Based Mechanism
Password-based Access Mechanism
Encryption Mechanism
Operational Different gantries configurations — Operational requirements when a common
issues payment medium is used in EFC shall be
Different lane configurations
considered before implementation
OBE components addressing
— Common payment medium shall store Version
Alert/Warning information to the
Handling Mechanism
customer
— Common payment medium shall be able to be used
Dynamic classification
for Multi-Application Handling
Declared classification
— Common payment medium shall store a minimum
OBE Transaction Release
of 3 usage log entries including transaction type
and date and time for the use of a service
OBE Remote Switch Off
Version Handling Mechanism
— Common payment medium shall prevent
manipulating the road usage data by user
OBE Capability Handling Mechanism
Multi-Application Handling
Tariffing schemes Distance Dependent — Tariffing schemes shall be considered whenever
a common payment medium stores parameters
Time Dependent
corresponding to the tariff
Vehicle Dependent
Event Dependent
Fixed
Combined tariffing Scheme
a
This also enables performing flexible EFC operations both with OBE and without OBE.
b
Multiple application access method is defined in ISO/IEC 7816-4.
The requirements on the common payment medium relating to Payment Card Industry Data Security
Standard (PCI DSS) should also be considered as a part of EFC functional requirements. PCI DSS is the
security standard of the card industry that was developed for cardholder data protection including
technical requirements. Technical requirements relating to an EFC system using a common payment
medium are derived from a part of the 12 categories of requirements in PCI DSS. These are described in
Table 2.
No actor in an EFC system needs to be certified as PCI DSS compliant.
Table 2 — Requirements of PCI DSS for EFC function requirements
Functional PCI DSS requirement Functional requirement for common
areas payment medium
Data protection — Keep cardholder data storage to a minimum — Primary account number (PAN), shall
by implementing data retention and disposal be secured with strong encryption
policies, procedures and processes
— EFC system shall store necessary and
— Do not store sensitive authentication data minimalized personal account data
after authorization (even if encrypted) for operation, not store it if not used
— Mask primary account number (PAN) when — EFC system shall not store sensitive
displayed (first six and last four digits are authentication data after used
the maximum displayed)
— Render PAN unreadable anywhere it
is stored (including on portable digital
medium, backup medium, and in logs) by
using any of the approaches
Cryptographic key — Document and implement procedures to — Key lifecycle management, kind of
management protect keys used to secure stored cardholder key and key generation
data against disclosure and misuse
— Key updating method, on-line and
— Fully document and implement all key- off-line, secure transmission, key
management processes and procedures for switching during operation
cryptographic keys used for encryption of
— Secure key storage in hard and soft
cardholder data, including the following:
— List management, quantity of list,
— Generation of strong cryptographic keys
updating method, ensuring real-time
— Secure cryptographic key distribution
— Secure cryptographic key storage
— Cryptographic key changes for keys
— Retirement or replacement of keys
— If manual key management operations are
used, keys must be managed using split
knowledge and dual control
— Prevention of unauthorized substitution of
cryptographic keys
— Requirement for cryptographic key
custodians
Transmission — Use strong cryptography and security — Sensitive EFC data such as cardholder
of sensitive EFC protocols to safeguard sensitive cardholder data and PAN shall be encrypted
data data during transmission over open, public using strong cryptography at
networks, including the following: air interface such as WAN and
contactless card interface
— Ensure wireless networks transmitting
cardholder data or connected to the
cardholder data environment, use
industry best practices to implement
strong encryption for authentication and
transmission
— Never send unprotected PANs by end-user
messaging technologies
8 © ISO 2019 – All rights reserved
The following security measures derived above functional requirements shall be implemented in an
EFC system. These abstracts are described in Annex H and a detail of a security specification is provided
by medium issuer under contract.
— Key management, kind of key and key generation.
— Secure key storage in hardware and software.
— Key updating method, on-line and off-line, secure transmission, key switching during operation.
— List management, quantity of list, updating method, ensuring real-time.
— Sensitive EFC data.
— Secure data protection.
The business process requirements, derived from CEN/TR 16092 shown in Table E.1, should be
considered during developing of the specification of and EFC system.
6 Application structure in a common payment medium
This clause explains the application framework including EFC application in a common payment medium.
The common payment medium for usage in several transport services is a portable device such as an
IC card or a mobile device. For common use of a medium, this medium shall store either individual
applications provided by each TSP or an application that enables usage among all TSPs. In this latter
case the issuer of the medium is required to know all application details to support all service providers.
The common media can support three types of application structures:
— Type 1: Multi application. The common payment medium is configured with individual transport
service applications and an application containing the CSR for use by all other transport service
applications.
— Type 2: Shared data. The medium is configured with individual transport service applications and
application with shared data used for CSR by all other transport service applications.
— Type 3: Single application. The medium is configured with one common application that stores all
data for the use of corresponding transport services including CSR.
Explanations of these types are given in Annex D.
7 EFC application data in a common payment medium
7.1 General
This clause deals with the minimum set of EFC application data in the common payment medium
necessary only to serve the interface data according to ISO 14906 for carrying out all EFC schemes
described in 5.2, the EFC functional requirements.
NOTE 1 According to the additional threats and security measures listed in ISO 19299, some attribute data
are added to those defined in ISO 14906 when a common payment medium is used for a closed toll system to
prevent swapping a common payment medium in a toll road network for abusing and juggling the toll charge.
NOTE 2 Data elements defined in EN 1545 can be used when more transport-related data are necessary to be
stored in the medium.
The EFC attribute data defined in 7.2 are required for the integrated use of a common payment medium
within an EFC system. These additional attributes are only stored in the common payment medium.
7.2 EFC attribute data for a common payment medium
Table 3 shows the storage location of EFC attribute data in the case of a one-piece OBE (OBE built as
a single unit) and two-piece OBE (OBE built as a couple of units, one of which is the common payment
medium):
1) A one-piece OBE, shown as case 1, stores all attribute data required to operate EFC service defined
in ISO 14906 and attribute data defined in this document;
2) A two-piece OBE, shown as case 2, stores attribute data for EFC service between an OBE and a
medium defined in ISO 14906 and attribute data defined in this document. OBE stores vehicle
relating data and a medium stores personal relating data.
NOTE In Table 3, the double check indicator means "mandatory", the single check indicator means "option"
as explained in the following sentence.
According to the additional threats and security measures listed in ISO 19299, an additional attribute
data ReceiptEntryVehicle shall be added to those EFC attributes defined in ISO 14906 when a common
payment medium is used for a closed toll system to prevent swapping of a common payment medium in
a toll road network for abusing and juggling the toll charge.
On a common payment medium for pre-payment service(s), the user can select an option for reloading
stored values when EFC charging is performed at a toll station. An additional attribute data group
named ReloadingParameter is included as a general data group for the reloading function of stored
values on a common payment medium for pre-payment service(s) (see Table 5). This data group consists
of some parameters for on-site reloading such as validity of reloading, threshold value for low balance
and value for reloading.
This document does not inhibit the OBE from storing data stored in the common payment medium.
When the common payment medium is present, the stored EFC attribute data from the common
payment medium shall be used.
When the common payment medium is not present, the stored EFC attribute data in OBE shall be used.
This is an option for user convenience service as indicated by a single check in Table 3. Another example,
there are two parameters for ContractAuthenticator, one is stored inside the OBE and another is stored
on the common payment medium, and toll charger and toll service provider can check whether these
are authorised or not.
Table 3 — Additional attribute data for medium
EFC attributes defined in ISO 14906 Data location
Case1 Case 2 Additional
attribute for
Attr.
One- OBE Medi-
Data group Attribute
medium
ID
piece um
OBE
Contract 0 EFC-ContextMark
1 ContractSerialNumber
2 ContractValidity
35 ValidityOfContract
3 ContractVehicle
4 ContractAuthenticator
10 © ISO 2019 – All rights reserved
Table 3 (continued)
EFC attributes defined in ISO 14906 Data location
Case1 Case 2 Additional
attribute for
Attr.
One- OBE Medi-
Data group Attribute
medium
ID
piece um
OBE
Receipt 5 ReceiptServicePart
6 SessionClass
7 ReceiptServiceSerialNumber
36 ReceiptFinancialPart
9 ReceiptContract
10 ReceiptOBEId
11 ReceiptICC-Id
12 ReceiptText
13 ReceiptAuthenticator
14 ReceiptDistance
33 ReceiptData1
34 ReceiptData2
Vehicle 15 VehicleIdentificationNumber
16 VehicleLicencePlateNumber
17 VehicleClass
18 VehicleDimensions
19 VehicleAxles
20 VehicleWeightLimits
Equipment 24 EquipmentOBEId
25 EquipmentICC-Id
26 EquipmentStatus
Driver 27 DriverCharacteristics
Payment 32 PaymentMeans
29 PaymentMeansBalance
30 PaymentMeansUnit
31 PaymentSecurityData
Receipt ReceiptEntryVehicle
Payment ReloadingParameter
7.3 Additional EFC attribute data
7.3.1 Data group RECEIPT
This data group consists of some optional data elements. Typical data elements for a closed EFC system
is shown in Table 4.
Table 4 — Receipt data
Informative
EFC attribute Data element Definition Type
remarks
ReceiptEntryVehicle VehicleLicencePlateNumber Vehicle licence plate number LPN
recognized and stored at
entry toll gate.
e.g. enabling to detect swap-
ping common payment me-
dium at Service area and/
or Parking area for devious
toll payment.
EquipmentOBEId OBE ID copied and stored OCTET
at entry toll gate. STRING
e.g. enabling to detect swap-
ping common payment me-
dium at Service area and/
or Parking area for devious
toll payment.
VehicleClass Vehicle class classified and INT1
stored at entry toll gate
EntryAuthenticator Authenticator for this at- OCTET
tribute. STRING
NOTE Specification of calculation of authenticator is provided by medium issuer.
7.3.2 Data group PAYMENT
This data group consists of some optional data elements. Typical data elements for pre-payment values
stored on a common payment medium is shown in Table 5.
12 © ISO 2019 – All rights reserved
Table 5 — Payment data
EFC attribute Data element Definition Type Informative remarks
Reloading ReloadingValidity End date of the validity of the reloading DateAndTime
Parameter contract option.
ThresholdBalance Threshold value of balance in medium for SignedValue, INT3
reloading activation at EFC transaction.
ReloadingValue Value to add balance in medium at re- SignedValue, INT3
loading transaction.
DepositValue Amount of a deposit for checking when SignedValue, INT3 Described in EN 1545-2, as
auto-reloading transaction is performed. Amount.
Dynamic Flag for reloading value equal to charging Flag
Reloading value when insufficient balance.
ValueFlag
Reloading Authenticator calculated by the Contract- OCTET STRING Authenticator of all data ele-
Authenticator Provider called Common Service Right ment in ReloadingParameter
Provider when issuing the Contract, to
prevent tampering with contract data.
Autoload Start date of the period of the reloading DateAndTime Described in EN 1545-2, as
StartDate option service for checking when EFC DateStamp.
transaction is performed.
AutoloadEndDate End date of the period of the reloading DateAndTime Described in EN 1545-2, as
option service for checking when EFC DateStamp.
transaction is performed.
AutoRenewFlag A flag indicating whether auto-renew is Flag Described in EN 1545-2, as Flag.
enabled. Valid flag for automatic reloading
at EFC transaction.
NOTE Specification of calculation of authenticator is provided by medium issuer.
Annex A
(normative)
Data type specifications
The EFC data types and associated coding related to the EFC attribute data, described in Clause 7, are
defined using the Abstract Syntax Notation One (ASN.1) technique according to ISO/IEC 8824-1. The
unaligned packed encoding rules according to ISO/IEC 8825-2 are applied.
The actual ASN.1 module is contained in the attached files “ISO21193(2019)EfcCsrv1.asn”, which can be
directly imported in a compiler.
The syntax and semantics of the ASN.1 types in the attached file “ISO21193(2019)EfcCsrv1.asn” that
are imported shall comply with ISO 14906.
NOTE 1 The above referenced files (i.e. “ISO21193(2019)EfcCsrv1.asn“) are available for download
via a hyperlink at www .itsstandards .eu/index .php/efc #EFCstandards and at http: //standards .iso
.org/iso/ts/21193/ed -1/en.
Table A.1 provides the SHA-256 cryptographic hash digests for the referenced files, offering a means to
verify the integrity of the referenced files. The SHA-256 algorithm is specified in NIST 180-4.
Table A.1 — SHA-256 cryptographic hash digests
File name SHA-256 cryptographic hash digest
ISO21193(2019)EfcCsrv1.asn ec436359369c65a8203ef4b7f5829d1ccdb5ab5dbb-
5555c7f3e75690f8efd22a
NOTE 2 Pasting the text of the file into one of the hash digest computation pages available on the web can
result in a non-matching hash digest due to changes in the underlying coding.
14 © ISO 2019 – All rights reserved
Annex B
(normative)
Implementation conformance statement (ICS) pro forma
B.1 General
To evaluate the conformance of a particular implementation, it is necessary to have a statement of those
capabilities and options that have been implemented. This is called an implementation conformance
statement (ICS).
This Annex presents the pro forma to be used for the attributes defined in Clause 7 and Annex A, with
ICS templates that are to be filled in by equipment suppliers.
B.2 Purpose and structure
The purpose of this ICS is to provide a mechanism whereby a supplier of an implementation of the
attribute in medium defined in this document can provide information about the implementation in a
standardised manner.
The ICS is subdivided as follows corresponding to categories of information:
— identification of the implementation;
— identification of the protocol;
— global statement of conformance;
— ICS tables.
B.3 Instruction for completing ICS
B.3.1 Definition of support
A capability is said to be supported if the implementation under test (IUT) can
— generate the corresponding operation parameters (either automatically or because the end user
requires that capability explicitly), and
— interpret, handle and, when required, make available to the end user the corresponding error or result.
A protocol element is said to be supported for a sending implementation if it can generate it under certain
circumstances (either automatically or because the end user requires relevant services explicitly).
A protocol element is said to be supported for a receiving implementation if it is correctly interpreted
and handled and also, when appropriate, made available to the end user.
B.3.2 Status column
This column (see Tables B.1 to B.8) indicates the level of support required for conformance. The values
are as follows:
m mandatory support is required;
o optional support is permitted for conformance to the standard. If implemented, it shall conform
to the specifications and restrictions contained in the standard. These restrictions may affect the
optionality of other items;
c the item is conditional (support of the capability is subject to a predicate);
c: m the item is mandatory if the predicate is true, optional otherwise;
— the item is not applicable;
— the item is outside the scope of this ICS.
In the ICS tables, every leading item marked “m” shall be supported by the IUT. Sub-items marked “m”
shall be supported if the corresponding leading item is supported by the IUT.
B.3.3 Support column
This column (see Tables B.6 to B.8) shall be completed by the supplier or implementer to indicate the
level of implementation of each item. The proforma has been designed such that values required are the
following:
Y Yes, the item has been implemented;
N No, the item has not been implemented;
— the item is not applicable.
All entries within the ICS proforma shall be made in ink. Alterations to such entries shall be made
by crossing out, not by erasing or making the origin
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.