The Ticket to Ride

Ticketing System Architecture

Author: Peter Tomlinson ([email protected] ) Version: 3.0 Date: 16 January 2009

Status

Updated January 2009 to reflect the current situation and qualify ephemeral material relevant only to the 2002 situation. As a result, the main body of the document continues to represent the position as seen in 2002, at which point multiple linked ticketing schemes were just beginning to be understood – but not much has changed since then.

Main ticketing system architecture is complete for single implementations. Associated security model not built, and therefore the security section is a set of working notes. New material for V2.0 was the beginning of a model for multiple co-existent schemes.

In this Word version, the reader may find unexpected page breaks. This is because of difficulties found with the line drawings when exported to other systems.

There is a short Glossary of abbreviations at the end.

Executive summary

For ticketing systems, a generalised model is set out. This is at the logical level. The ticket is here treated as both an identifier of, and partial representation of, the contract entered into; at times it will also be a receipt. The model demonstrates that the dataset (representing the ticket and associated data) and the process for handling the ticket are equally important and equally necessary for a practical ticketing system.

The model applies to those systems where it is intended that a record of the use of a ticket to obtain a service shall be returned to a back office for management and financial reimbursement purposes – as required in interoperable schemes, and as required in the IFM architecture.

Implementation of the model may be partially explicit and partially implicit. As a minimum, the user of a service must carry some sort of ticket, and the ticket processing equipment must be designed to record the use of the ticket and report that to a back office; the remainder of the implementation can be explicit (e.g. operated by the ticket processing equipment) or implicit (e.g. manual processes carried out by the service provider).

From the model, where smart card technology or related technologies are to be used, several implementations are derived, showing that there are many possible splits of allocation of both data and ticket processing functions between the ticket carrier (smart card, etc) and terminal (ticket machine, etc). At the same time, it is emphasised that practical implementations, like all successful applications of ICT (Information and Communications Technology), have to take account of many user-centric, commercial, and legal requirements and constraints.

tsa_v3-0.doc 1 V3.0 PWT 16/1/09 Since V1 of this document was produced, several discussions have brought out the possibility of the co-existence of multiple implementations – for example, a cardholder using public transport may travel regularly in and between schemes with significantly different implementations. A new dimension of the ticketing model is thereby opened up, in which both cards and terminal equipment are required to hold and process tickets from more than one implementation. Addressing this also addresses the situation where there is more than one ticket stored for a given user of the service, so that the process (even within one implementation of the model) has to make a choice between tickets. In 2002 this new dimension was addressed in the Annex, and the intention was that it be further developed into a main section of the paper – however, I note here that, at end 2007, a paper ‘Customer media ticket clipping/validation in UK rail’ was submitted by TheTrainline.com to the rail ticketing group chaired by Rail Settlement Plan Ltd. The paper contained material from this TSA paper, from Digital Locksmiths (about implementation within the ITSO Environment) and from Trainline; it provides examples of the handling of several types of ticket – but the problem of automatically making a choice between tickets was still not resolved. For further information contact Jeremy Acklam.

As this is primarily a concept paper, existing and planned schemes are not described, but brief mention is made of the ITSO specification (UK) and the IOPTA work (CEN – now published as EN 15320), showing that at present they both represent only one (the same one) of the possible implementations derived from the model.

Important sections on security and contracts are included in an Annex.

Introduction

This is the second published version of a paper describing a top-down logical model of a generalised ticketing system architecture. Underlying the model is the basic concept that the ticket represents the contract between the user of a service and the supplier (operator) of the service – the ticket is not the contract, but is a record of relevant information about the contract. The contract may be a simple one (purchase the ticket from the organisation that also supplies the service), or may be very complex (e.g. purchase the ticket from one organisation, but receive the service from several other organisations), or, indeed, be part of a web of contracts involving numerous service suppliers.

The paper goes on to derive various implementations on the assumptions that:

 a ticket will always be carried by the recipient of the service

 a pre-determined process will be used to handle (process) the ticket and associated data

 some definitive record(s) of every instance of service provision is/are to be returned to one or more back office processing systems (except in abnormal operating conditions)

The derived implementations illustrate several different allocations of data storage and processing functions between ticket carrier (smart media, typically a smart card, for the present studies) and terminal equipment, and are particularly oriented towards ticketing for public transport.

tsa_v3-0.doc 2 V3.0 PWT 16/1/09 New concepts introduced with version 2 of the paper were:

 multiple co-existent implementations

 multiple tickets within the dataset for a particular implementation

At present, the treatment of these concepts continues to be provisional, and is included in the Annex.

Developments (existing and proposed) in public transport ticketing systems have driven the production of this paper, but the model is proposed as being suitable for most, if not all, environments where a ticket is issued in advance of provision of the related service.

The concepts developed here were first set out (but only partially) as part of introductory working documents produced for discussion among members of the UK Mirror Group for CEN TC224 WG11. However, these concepts have wider application as a generalisation of the various ticketing implementations already in use and currently being designed for public transport in the UK, and possibly across Europe.

Contributors to the development of the concept are Bill Reding, Tony Emery, Ian Parsons, Colin Tanner, Steve Brunt, Jan de Meester and Donald Ramsbottom, but the text here is the work of the author. Copyright Notice: this work is © Peter Tomlinson 2002 – 2009. Reproduction is permitted providing that this Copyright Notice is included, along with the names of the other contributors as listed in this paragraph. Quotations are permitted providing that the title, date or version number, and the source (at least ‘Peter Tomlinson et al’) are acknowledged. Comments and offers of assistance with completing the security model are welcomed – emails should be sent to [email protected] .

When attempting to produce standards and specifications for the AFC (Automatic Fare Collection) environment, it is far too easy to become overwhelmed by all of the constraints, including:

 a systems supply industry where each supplier company develops its own concept of a ticketing system

 an operating regime where overall use of technology is at present mostly unsophisticated (even though the individual items of equipment may be quite sophisticated)

 operating cost constraints, operating speed requirements, the need to encompass a huge variety of ticket products, the difficulty at times of delivering the promised service, the requirements of public sector regulations, the pressures resulting from employing public sector finance, the existence of fraud in present systems, and the labyrinthine and slow and poorly funded standards development organisations

When attempting to develop specifications in this environment, it is too easy to ‘descend into the swamp’, and try to get out of it by building a raft from the fragments found scattered around but within reach. It is not therefore surprising that design work in 2002 for interoperability in this area had all the hallmarks of so many first generation attempts to bring IT to previously largely manual processes and do it quickly: a clutch of manual processes are

tsa_v3-0.doc 3 V3.0 PWT 16/1/09 codified and then implemented in an IT system, without sufficient regard to (a) custom and practice (i.e. the expertise of the existing practitioners – service providers - when faced with problems) and (b) a unifying model.

Fundamentally, the work here is concerned with automating the business of selling a ticket in electronic form and then on the one hand letting the ticket holder use the electronically stored ticket to claim the service, while on the other hand assisting the service provider to ensure that that service, and only that service, is delivered to the ticket holder. Other functions, even as far as re-imbursement of funds from ticket seller to service provider, are, at the logical level, ancillary to the relationships between service providers and the recipients of the service, in which tickets are the key representative of the contracts.

In information technology terms, the model embraces the flow and processing of information about the contracts and associated service provision. Such data is transformed as it flows through the system, and, ideally, should be secured throughout by security information carried end to end with the data. This paper admittedly concentrates on the data domain, providing only pointers to features of the security domain; this is partly because security methodology is very much implementation dependant, and partly because (in 2002) the author had not been able to construct an overall security model.

The major ‘ancillary function’ required to support the implementation of the model is that of handling the ‘consideration’ required as part of the contract, which consideration is usually some form of payment. Payment methodology (and other authorisation to travel) is outside the ticketing model, although the system that handles the ticket will often also carry payment information. In the model, claiming and allocation of revenues is one final result of processing ticket and journey information, but the process of calculating the financial outcome is outside of the security domain that protects the logical model.

Where the ticket seller is also the provider of the service (a closed system), there are few ancillary functions, the system is simple, and there are numerous successful implementations around the world. These implementations range from car parks to large metro area public transport systems, showing that many different implementations can come from the fundamental concept. And they encompass both smart cards and the earlier magnetic stripe technologies.

The much more complex open systems for which in 2002 we were trying to design a front end system standard (in CEN TC 224 WG11 – IOPTA, now EN 15320), a back office system standard (in CEN TC 278 – IFM, now EN ISO 24014-1) and, simultaneously, implementations and national interoperability specifications, are made so complex by bringing in a huge extra concept: ticketing interoperability across multiple service providers. Leaving aside all the operational and contractual problems, the work at the TC224 WG11 level aimed at carrying with the ticket sufficient information for each service provider to be able to deliver a service sold by another organisation, and the work at the TC278 level aimed at enabling the back offices to reimburse the service provider on an individual ticket basis.

Note that this paper tries not to use transport-specific terminology. The interoperable ticketing process can apply equally to (a) a through bus/coach/taxi/train ticket from a rural village in Cornwall to a rural village in Poland (and here I note that you can take a direct coach service to Krakow from outside a travel agent’s shop in Bristol, but it would probably be taxi, bus, coach (or train), bus to get from rural Cornwall to that travel agent here in Bristol, and

tsa_v3-0.doc 4 V3.0 PWT 16/1/09 perhaps similar in Poland to get to your ultimate destination by public transport), and (b) a theme park ticket where the individual attractions are separate businesses reimbursed on a per patron basis. And, although we might think in terms of a journey of 3 days, or an afternoon spent in a theme park, there is a good expectation that a logical model that allows ticketing systems for these services to be built can also, by reduction, deliver a single bus ticket, the issuing and ‘use’ of a driving licence or a citizen ID card, or a personal insurance policy – although the security requirements for a driving licence and a £1 (Eur 1.10) single trip ticket are somewhat different.

Today (as in 2002) there are examples of ad hoc financial reimbursement systems in public transport in particular1, but these are not generally based on precise records, securely obtained, of every person’s progress through the service providers’ systems, nor even on partial progress records supplemented by surveys and statistical models. They use a mixture of dead reckoning (number of seat miles provided, regardless of how many people sit on any particular seat – or, indeed, stand between the seats) and statistical surveys to provide estimates of actual passenger miles travelled. There is also a good deal of experience from closed transport systems (e.g. gated and ungated metros) about the level of success that those systems have in knowing how many people travel when and where and whether they have paid.

And there is the ever present fact that, although the (perhaps unspoken) agreement between the seller and the purchaser of the ticket always aims (should always aim) to contract for a specific service to be delivered in a particular way, many circumstances result in the contract being varied in a dynamic manner, and obligations on the service provider often result in the variation being accepted by the service provider’s staff in an offline situation (i.e. without reference to a central office). The decision making is truly distributed, be it codified in the ticket processing equipment, or at the discretion of the staff who interact with the users of the service as they travel or as they ride the attractions in the theme park.

What these existing systems and schemes do teach us is a set of watch points when implementing ticketing systems:

 Processing the ticket is generally an off-line operation

 The data returned to the back office is likely to be ‘dirty’, i.e. incomplete or containing the unexpected

 Contract variation during delivery of the service must be accommodated

 Operators (in the general sense – e.g. including in the UK the Passenger Transport Executives or PTEs) may find that moving from the present ad hoc reimbursement based on dead reckoning and estimation to a deterministic method based on transaction messages, is (a) too expensive to run and (b) leaves too many unresolved ticket use records

 Delivering interoperability based on ticket use records is extremely complicated

1 In particular ENCTS (concessionary bus travel) in England

tsa_v3-0.doc 5 V3.0 PWT 16/1/09  Fraud (embracing travel without a ticket as well as use of forged tickets, etc) will always be with us and may (for social policy reasons) have to continue to be tolerated

 The conflict of interest between customer and service provider over quality of service levels may be exacerbated by introducing the automated system

 It must be easy for the ticket holder to ‘read’ the ticket

 The systems and supply side has not yet solved some of the problems associated with building ticketing systems in generalised public transport

And we must always remember that service providers may be constrained by law not to identify individual ticket holders.

In other words, we are always in danger of never getting out of the swamp (incidentally, the swamp analogy came from another participant in this industry, whose identity is, perhaps conveniently, forgotten). However, this paper attempts to build a general model and then derive some implementation models. It is left to the reader (particularly those involved in implementing ticketing systems) to address the nine watch points above.

January 2009 update: it is beginning to be accepted in England that there is an overall ‘public good’ case, and the beginnings of a financial case, for operating public transport throughout with electronic, interoperable ticketing systems. At the same time, the capital investment needed (order of magnitude £500M) will not be provided by private sector operators alone.

Processing and protecting the ticket: system architecture

The fundamental principle is that the ticket is king! It represents the contract between ticket seller and ticket user throughout the period of provision of the service. Its integrity must be preserved at all costs – that is much harder in electronic systems than users of traditional printed tickets might think, but is often taken for granted because a printed ticket is so obviously a permanent representation of (receipt for) the contract entered into.

The fundamental system architecture for issuing and processing the ticket is shown in Fig 1.

This is a logical model, from which many implementations can be derived – some of them are described below. Note that, although the architecture model shown here is partitioned into 3 logical blocks, no assumptions of any kind are made at this stage about the location of functions and data elements in a physical implementation of the architecture. For example, fixed data defining the ticket may be stored wholly in a smart card, or partly in a card and partly in the associated terminals. The statement that is made here is that, at this logical level, all ticket processing schemes must, explicitly or implicitly, implement the elements in the diagram. However, of necessity, in an automated system using smart cards, something must be carried by the user of the service (cardholder), something must be implemented by way of a user interface, probably something by way of an operator interface, and definitely (in the general set of interoperable schemes) some type of link from back office to back office (see Fig 3) and from back office to system managers and owners. (Continued on next page)

tsa_v3-0.doc 6 V3.0 PWT 16/1/09 Operator and User Interface

State table

Back Ticket State indicator office Handling Process Fixed data (state machine) Variable data

Journey log

Figure 1: Ticket and Processing System Architecture

Implicit in the architecture is a duality:

 each ticket type (product) is defined as a unique representation of the service agreed with the ticketholder

 also defined is the process by which the ticket is managed until the service is completely delivered

Once again, it must be emphasised that this is a logical model, and implementation does not have to be explicit, so that the state machine and state tables may in some cases hardly be visible, or may be largely expressed as a set of ‘business rules’. Indeed, in many existing public transport systems, the process is mainly carried out by the vehicle operator, and it may even be that the physical ticket is non-existent. The contract with the ticketholder, however, must always be there. For more discussion of contract and implicit process, see the Annex.

The architecture proposes that the management of the ticket until the end of its life is carried out using a state machine and a state table. For those unfamiliar with state machine methodology, it is a method by which:

 all the permitted changes to the data are defined

 for every combination of inputs, one and only one action (which may be null) is defined; an alternative way of stating this is that, for every permitted change (e.g. purchasing a ticket) and required change (e.g. on detection of an error), the conditions required for the change to occur are defined in a way which results in there being only one permitted/required state change for each possible new combination of conditions.

 the process (e.g. purchasing and using a ticket) is managed as a set of states, inputs, state changes and permitted/required changes to data and outputs as a result of the state change

tsa_v3-0.doc 7 V3.0 PWT 16/1/09 Thus, for example, successfully passing through a metro station gate with a valid but as yet unused ticket carried in a smart card:

 providing that no error is detected, causes a state change from ‘valid unused ticket’ to ‘journey in progress’

 as a direct consequence of the state change, causes a change of variable data in the ticket (e.g. in a flat fare closed (gated) metro system, typically at the start of the journey the changes are the writing of start date and start time to the card when the ticket holder passes through a gate, and possibly logging other data, such as start point, for the benefit of the metro system managers)

But trying to pass through the gate with a card that has become hotlisted after the ticket was purchased causes a state change to ‘card rejected’.

Thus are deterministic machines programmed, representing processes which operate according to a set of rules.

(Continued on next page)

tsa_v3-0.doc 8 V3.0 PWT 16/1/09 Card Ticket sale Valid with free unused space ticket

Error Delete ticket Refund Journey in (usually at next progress sale start) Card rejecte Error on entry d to system Journey ends in Error when card Cancelle Journey next presented d ticket < 1 hour in progress

Journey ends in Don’t pay > 1hr Error on exit Pay from system Note: ‘Error’ includes card hotlisted Excess Card fare rejecte require d d

Figure 2: Example Single Ticket State Diagram

In a state diagram used to design a state machine, states are usually represented as circles, and changes as arrowed lines leading from one state to another. Figure 2 is an example state diagram (not guaranteed to be complete) for the life cycle of a single ticket for a flat fare, period validity (1 hour) gated metro system, with the ticket carried in a smart card. Note: (a) ticket inspection during the journey is not included (this particular state diagram assumes that an inspector carries a read only device, i.e. a card viewer – which is how inspection of Oyster cards on the London Docklands Light Railway (DLR) was working in 2008), and (b) the diagram shows the reasons for the state changes, but not the changes to the data in the ticket.

tsa_v3-0.doc 9 V3.0 PWT 16/1/09 The logical model shown in Figure 1 enables interoperability between different operators so long as they all connect to the single back office. They are, in effect, belonging to the same scheme, and that scheme defines the basic process and dataset that all the operators use. Present day business models, however, demand that public transport in particular implement multiple schemes across which tickets, quite literally, travel. The logical model then becomes one of interconnected back offices, each supporting processes and datasets (Figure 3). This necessitates a definition of the means to interoperability of tickets across these schemes:

For a ticket to be interoperable across independent schemes, those schemes must all, at the logical level, operate the same process to handle that ticket.

Operator and User Interface

State table System managers Back Process State indicator and office (state scheme #1 machine) Fixed data owner #1 Variable data

Journey log

System managers Back Each scheme (back office) must and office support the same process and scheme #2 dataset for the interoperable ticket owner #2

Figure 3: Interoperable Ticket and Processing System Architecture

Once again, the distinction between the logical model and the implementation must be emphasised: each implementation might only implement part of the model, but its process must be governed by the agreed overall process for that ticket. For example, when processing the single ticket from rural Cornwall to rural Poland, there is no need for the local buses from Bristol’s Temple Meads railway station to the coach departure point to have the functionality to process seat reservations.

tsa_v3-0.doc 10 V3.0 PWT 16/1/09 The life cycle of the ticket – governed by a state machine

Background

The life cycle of the ticket was the subject of the note that initiated the production of this paper.

In this section, specifics of smart card based ticketing systems are discussed, and some implementations are derived from the logical model set out above.

The life cycle of the ticket is from creation to eventual destruction. Completing the provision of the service is not enough: the recipient of the service may wish to keep the ticket. Also, within a smart card, operational requirements to recover storage space in the card will often mean that the ticket is either deleted when a new ticket is to be issued, or else ‘updated’ as a new ticket is issued. An example of updating is when a season ticket is ‘renewed’: a new expiry date is written into the ‘expiry date’ data storage space (data element) of the existing ticket, and other data elements may also be modified.

Smart cards and tickets

Smart cards contain two dimensions of functionality:

 data storage and algorithm storage and execution (together these are the ‘application’ in the smart card industry’s technical terminology)

 security mechanisms

These functions may be implemented in software, or in hardware, or in a mixture of both. Even a so-called memory card fits this model, although it will not have any provision for modification to built-in algorithms.

A ticketing system has to be able to control the processing of every data element in the ticket at every stage in the life cycle of the ticket. In the logical model in Figures 1 and 3, such control is included within the ‘Process’ element, supported by parts of the Data. Different implementations naturally implement this control in different ways, but it is important to note here that, within the smart card, a mixture of functions from the two dimensions are used.

Scheme security

Overall scheme security is a mix of:

 a deterministic design for the ‘Process’ and state tables (Figs 1, 3)

 specific security functions and its purpose is protection against both fraud and processing errors.

tsa_v3-0.doc 11 V3.0 PWT 16/1/09 New to the interoperable environment are the requirements to extend interoperability, and therefore security, to the multi-scheme environment – in terms of the model seen in Fig 3 – and to inclusion of acceptance of multiple card platforms. The aspirational slogan from Visa (‘anytime, anywhere’) applies, and we have added ‘any card platform’ (within reason).

The security functions should, of course, make use of the security mechanisms built into the smart card carried by the recipient of the service (the cardholder). They then build on those mechanisms, and add further functions in order to implement overall scheme security against fraud and errors in both communication and processing.

While scheme security must be considered from the very beginning of design of a smart card ticketing scheme, it becomes inevitable, in the interoperable ticketing environment, that there will be compromises in this area. Agreement on the interoperable ticket’s process are absolutely essential, but risk management will vary from scheme to scheme, and even from operator to operator within one scheme. As a study of the example implementations set out below will show, allowing several types of smart card to be used to carry the ticket (card types from high performance and large memory down to the baggage tag level of functionality) makes the implementation of security functions very complex.

The deterministic design of the process for handling the ticket ensures that, at every state change, there is complete control over changes to the data, control in a form that is visible at the stage when the process is configured (e.g. displayed by the software that is used to build the state tables).

ITSO (now in 2009 established, but in 2002 still the emerging UK national ticketing interoperability specification) has created an innovative solution to the problem of multiple card platforms, by decoupling (as far as possible) the overall scheme security from the particular security methodology of each card platform. The card platform is therefore handled by a matching driver and card-related security data in the terminal.

Thus ITSO defines ‘products’, plus a small number of service entities at the same level (e.g. journey log2). Ticket data structures are allocated product type numbers – more about this under the second type of implementation below. Application-level security between card and terminal is vested in certificates stored in the card, protecting each product, and also protecting a private ITSO Directory held at application level in the card. Note here that ‘certificate’ is used in a general sense in this type of ticketing environment. Typically, the certificate is a data string formed using an algorithm which involves first creating a digest of the data that it secures (e.g. using a hashing algorithm), then combining the resultant digest with other information (such as the card serial number), encrypting the result with a cryptographic key, and compressing the result into a relatively small number of bytes (typically between 8 and 32 bytes). Note also that such certificates, generated when the card is being processed by a terminal, have to be verifiable by all other terminals in the network, even when those terminals are operating offline.

Within the terminal (where at least part of the Process (Figs 1 & 3) must be run), there is an option to implement some security in a tamper-proof (or at least tamper-evident) security module. Often called a SAM (Security Access Module), this allows many security functions, plus storage of security keys, to be implemented in a manner that is both secure and

2 By 2009 the ITSO log had been truncated to 2 entries, and was not fully secured. It was thus unusable by the state machine. The 2007 Trainline paper put forward ideas for recreating the secure logging function.

tsa_v3-0.doc 12 V3.0 PWT 16/1/09 independent of the design of the terminal platform. The ITSO Environment implements such a module, known as the ISAM when used in terminals and the HSAM when used in the core (HOPS) back office systems.

The logical model revisited

The classical, deterministic method to implement this processing of the ticket is with a state machine:

 Every stage of the ticket’s life is a state

 All permitted (or required, as in the handling of errors) transitions from one state to another are defined in terms of the starting state, the conditions to permit (or require) each possible transition, and the permitted changes to the data which makes up the read/write data elements associated with the ticket

 The state machine monitors inputs, actions a state change when the relevant conditions are met, and produces the relevant outputs

The implementation is logically by way of creating the following entities (see Figs 1 and 3):

 The ticket-related parts of the data set (fixed data, variable data, state indicator)

 The process-related data, namely the state table to define: permitted state changes, the conditions required to enable the state change, and the permitted changes to variable data during the state change

 The state machine (uses the inputs, state tables and state indicator to action a state change, record that state change, and output the required messages)

But transport activities cannot be fully described by a classical state machine. Problems include:

 Permitted (even required) state changes might be skipped (often are skipped)

 Additional, unexpected state changes may occur

An example of the first kind (skipping a state change) is where a ticket is not processed at the start of a journey because the ticket gates are not working. This will occur when a station is unmanned, and at other times: as this paper was being written in 2002, Russell Square tube station in London was being refurbished, and there were no gates at all. With a magnetic stripe ticket system, starting a journey at Russell Square and changing trains at Kings Cross (where, for some changes of train, passengers go out through a ticket barrier and back in through another ticket barrier) resulted in the Kings Cross gates refusing to let the passenger out through the first ticket barrier because, according to the information on the card, the journey was not recorded as having started.

An example of the second kind is where a passenger buys a return ticket from A to B, but on the return journey alights at C. For example, if travelling from Bristol Temple Meads to London and then back to Bristol Parkway, the gates at Parkway will not let you out, yet

tsa_v3-0.doc 13 V3.0 PWT 16/1/09 this is a perfectly logical journey for me to make (I live half way between the two stations, which are 6 miles apart).

Practical implementations of state machines in public transport ticketing have to have a very sophisticated state machine which can (in conjunction with the operator) handle the unexpected. This is exactly what the present manual systems do, and therefore implementors of automatic systems have to use a great deal of skill and of knowledge of the way that the existing manual systems are operated by experienced and responsible staff. Practical implementations will, however, record the decisions taken when the unexpected occurs, and will therefore permit scheme managers to study the exceptions in order to build better systems (and know where staff training needs to be improved, and where to strengthen the defences against fraud).

In the logical model, data is described as ‘fixed’ and ‘variable’. CEN TC224 WG11 has, I believe, classified ticket data elements as

 write once (i.e. fixed data, where typically the sale of a ticket writes a set of ‘write once’ data elements into a smart card), and

 read/write (generally the data elements used to manage the progress of the ticket until it is fully spent and then discarded, i.e. the variable data in the model developed in this paper).

The deterministic method described in this paper then requires the variable data to be explicitly controlled via the state machine and state tables. Then, at each state change, the state table controls which data elements can be changed and what changes are permitted for each data element.

Little has been included here about the methodology for implementing software and data structures in terminals. Partly, this is because:

 there are many terminal types, built on many different hardware and OS (Operating System software) platforms

 there are many existing implementations for both non-smartcard and smartcard environments but also because much of the terminal software is somewhat ad hoc, dealing with local requirements and handling of external inputs and outputs. Such software has to handle payment, local ticketing products, local data formats to and from the back office, and perhaps even links to vehicle location systems. Instead, by concentrating on building implementation models from the dataset (smart card) end, this paper’s intention is to influence implementations rather than design them.

Note that, in the implementation where the state machine runs in the terminal, it could well be in a SAM (Secure Access Module) close coupled to the terminal – and increasingly terminals will contain SAMs for security control (holding keys and cryptographic algorithms, as noted above). The use of the SAM can go further: move the state table and fixed data into the SAM, and the terminal’s functions then reduce to peripheral handling: user card, keypad, operator/user display and sounder, SAM, plus the interface to the back office, payment processing, and perhaps an interface to the vehicle systems (e.g. vehicle location). Moving so

tsa_v3-0.doc 14 V3.0 PWT 16/1/09 much of the ticketing functionality makes management of the terminal population easier. It also mirrors the SyntiQ SAM implementation of the entire EMV application, as developed for Interpay (Holland).

Note also that the fundamental model does not incorporate any error recovery methodology, because that belongs at the implementation level. Wherever there is a physical interface (e.g. between card and terminal, between terminal and back office, between one back office and another), the implementation must use appropriate error detection and recovery (e.g. card anti- tear, which may be implemented either in the card (as proposed by TC224 WG11’s IOPTA project) or in the terminal (as used by ITSO for memory cards)).

tsa_v3-0.doc 15 V3.0 PWT 16/1/09 Example implementations

Figure 4 illustrates four possible implementations of the logical ticketing model – in that Figure, for the four implementations (Types 1 to 4), the divisions between smart card functions and terminal functions are shown by the dashed lines.

Operator and User Interface

State table

State indicator

Back Processor office (state Fixed data machine) #4 #3 Variable data

Journey log #1 #2

Figure 4: Ticket Processing System Architecture

1. Maximum security (Type 1, #1 in Fig 4)

State machines work quickly, so there need be no fear of implementing them in smart cards. Therefore the maximum security implementation is feasible (but expensive to develop): the state machine, state tables, current state indicator, fixed and read/write data – all these are in the card, and the software of the state machine is developed to be trusted (proven correct and also fault tolerant), plus the new discipline of being able to cope with the unexpected from a customer point of view. Provably correct software is a common discipline these days, but fault tolerance is not so easy (it requires tolerance of execution being stopped at any point, plus tolerance of transient errors in execution). There are groups of developers who are very well versed in the relevant methodologies. Other skills come into play in order to (a) develop the software that builds the state tables, and (b) define the life cycle of the ticket and the permitted data manipulations at each state change.

New is coping with the unexpected during a journey with a smart card ticket, but such a development is a natural progression from the present ad hoc logic used in ticket machines, station gates, and inspector's assessment of the ticket presented to him or her. Some of the logic is therefore already there, and has to be gleaned from skilled assessment of present day methodologies. Implicit state descriptions and permitted transitions are currently contained in the patterns of, and permitted changes to, the variable (read/write) data at each stage in the ticket’s life.

tsa_v3-0.doc 16 V3.0 PWT 16/1/09 This implementation is the most secure at the application level, although, being controlled by the terminal, it is of course dependent on the terminal giving it the correct information to trigger the correct state change. Implemented in a high security smart card, it is also the most secure against tampering unless the person carrying out the tampering has access to the terminal level, or perhaps back office, security keys. However, high security smart cards at present operate slowly, mainly because the card platform uses a huge proportion of the overall execution time in order to make the necessary security checks.

2. Data only in the card (Type 2, #2 in Fig 4)

Another implementation has only the data (all of it: fixed and variable) and the current state indicator in the card, with the state machine and state tables (or the relevant part thereof) effectively held in every terminal. A memory card implementation (such as Mifare® Classic) has to be like this, and there is pressure to do the same in microprocessor cards: low cost of implementation, ease of conversion from present paper ticket methods. However, both present experience with, and design studies for, this type of implementation in microprocessor cards show that performance is poor (excessive transaction times) and security (particularly against premature termination of the transaction process by, for example, removing a contactless Proximity card (ISO/IEC 14443 type) from its energising field) is relatively clumsy to implement.

From a security point of view, this Type 2 implementation puts much more trust in the terminal than does Type 1. With a large variety of terminal equipment types, built on a large variety of hardware and software platforms, implementing and proving security becomes very problematical – attention therefore turns to incorporating common security modules (SAMs) in the terminals, but that still leaves open the serious risk of fraud by cloning or ghosting a card or part thereof within the terminal.

2.1 ITSO

The ITSO model as described (2002) in the Version 2 ITSO Specification is a Type 2 implementation, but:

 it does not have an explicit current state indicator or formal state tables (thus it is not an explicit implementation of that part of the model)

 the Process is not fully defined, because ITSO is designed to be an interoperability layer overlaid on top of existing ticket handling methodologies

If overall national interoperability is to be achieved with ITSO as the starting point (e.g. national rail ticket types available over the whole network and also providing multi-model interoperability with local bus, tram and ferry services), then the relevant ticket types have to have their basic process algorithms defined and implemented in every terminal that has to handle those tickets. In January 2009 that has still not been done, and remains outside the envelope of ITSO Ltd’s responsibility – with the consequence, in the present state of public transport service delivery, that the ITSO vision (and the 1998 UK government vision) of seamless travel by public transport is nowhere near being realised.

ITSO, as noted above, puts each ticket into a ‘product’ dataset, with the aim of decoupling, as far as possible, the processing of the product from the requirements of the card platform.

tsa_v3-0.doc 17 V3.0 PWT 16/1/09 ITSO then defines a private directory of products (and additional items, such as the currently in January 2009 inadequate activity log) inside the ITSO application.

Each ITSO product is protected by a certificate:

 In 2002 the following statement was made: since the product (called by ITSO an Interoperable Product Entity or IPE) contains both the fixed data and the variable data associated with each product (ticket), and the present ITSO specification (Version 2) shows no provision to separately protect the fixed data from being modified during the later life of the ticket, ITSO places a great deal of reliance on the terminal to be designed and configured to correctly handle the ticket (and not make mistakes).

 By the time of Version 2.1, ITSO had established separation of the fixed product data (IPE body) and secure variable data (Value Record). However, sometimes we still hear of being able to modify the ticket (IPE body) – wrong.

2.2 IOPTA

IOPTA is the acronym for the transport ticketing standards work in CEN TC224 WG11; the full title is Interoperable Public Transport Ticketing Application – it has produced EN 15320. The proposed card type was Type 2 (in terms of the model in Fig 4, data only in the card), without an explicit state indicator or formal state tables, but with anti-tear in the card.

3. Small memory cards (Type 3, #3 in Fig 4)

For the small memory card or equivalent in ‘paper label’ format, the fixed ticket (product) data is held in the terminal along with the state machine and state table for the product. The card then holds a product code (which points to the fixed product data and state table in the terminal) and the variable data. In this scenario, the products are most likely to have only a limited geographical validity (e.g. within a single urban area), so only the terminals within that area will have the fixed product data and state table. Thus we have a closed system ticket, but that is a ticket which is typical of the low fare / high volume market.

4. Other ticketing technologies

What, then of other technologies, perhaps mixed with existing smart card designs? Methods suggested include:

 ‘sweeping’ a vehicle with a radio frequency field to which the ticket carriers respond by transmitting their serial numbers (that, and more complex transaction methods, has been studied for DfT in the BiBo research project, due for completion by end January 2009)

 active tags which contain a battery and transmit a data burst at intervals (again containing a serial number)

 people counters (e.g. infrared)

Generally these technologies will be used to provide information used in the back office (e.g. to calculate financial re-imbursement) or beyond (e.g. management information for planning purposes), and with the progress in technology could now handle the ticket as part of the

tsa_v3-0.doc 18 V3.0 PWT 16/1/09 contract delivery to the ticket holder. But in some cases they may be used to handle a very simple pass-style ticket, which is read only – and that is illustrated as #4 (Type 4) in Figure 4.

Transaction initialisation

Not to be forgotten is initialisation of the transaction with the ticket. Given that, at the very least, a data structure is held by the recipient of the service as a ticket in a carrier, the terminal has to identify the ticket and its carrier. In order to choose the correct methodologies for handling the ticket, the terminal has to recover information from both carrier and ticket at several levels. This is not an easy matter with smart cards, because the standards (and the custom and practice in the industry) have only ever dealt with a small part of this problem.

For microprocessor contact cards, the ISO/IEC 7816 Answer To Reset (ATR) is sent by the card immediately after startup. This provides some information about:

 the physical layer of the interface with the terminal

 the low level communications protocols supported by the card

It may also give the opportunity for the terminal to change some of the physical layer, in particular to change the data communications bit rate.

Optionally, the card may also make available (either in the ATR or in response to commands):

 the identity of the designer of the card

 the card specification version

 a pointer to a data record giving a little more information

What is not guaranteed to be provided is exact identification of the command level protocol and security protocol for commands issued to the card – information which allows the exact specification of the card (known as the ‘card edge’ specification, i.e. interface specification and any other relevant information about the functionality of the card) to be referenced. The identification of the security key set required to pass the security checks in the card is definitely not provided. There is not yet, apparently, any precise definition of the methodology to be used to differentiate between a Multos card and a Global Platform (Javacard style) card, yet there are fundamental differences between a Multos card and a Javacard. What is also not provided is any information about the application or applications loaded onto the card (although some card platforms will reveal the AIDs (Application Identifiers) of the applications loaded onto the card). If the URI function (User Related Information about the cardholder and the cardholder’s requirements or ‘personal preferences’) is loaded, it is unlikely that it will be possible to identify the methodology to retrieve that information or its format at the card edge.

Across an ISO/IEC 14443 Proximity contactless interface, a similar process applies, except that the terminal has to send a command in order to request the information. For contact interface memory cards, things are even worse: there is no de facto standard physical level protocol, with ISO/IEC 7816 Part 10 (which has information that was in the 1989 edition of

tsa_v3-0.doc 19 V3.0 PWT 16/1/09 7816-3) depicting only part of the whole spectrum of protocols in use. ISO/IEC 14443 does a little better for memory cards, using the same startup methodology for both memory and microprocessor cards, but those cards using proprietary protocols are merely flagged as ‘proprietary’ once they have been initialised.

In 2002, several specification and standards groups were looking at this problem, as they were in need of methods to find out information about and from the card in a deterministic manner and quickly, and as yet they have no common ground on which to approach card platform developers. Instead, they are trying to use existing card functions to provide a partial solution to their immediate problems, and are each beginning to specify new and more general methods. Groups known to be working in various ways on part or all of this problem area were:

 Global Platform (with Maosco for Multos)

 e-Europe Smart Cards TB4, TB7, and TB8 (and perhaps other TrailBlazers)

 CEN/ISSS Workshop ‘URI Extended’

 CEN TC224 WG11 (IOPTA) and associated CEN/ISSS Workshop FASTEST

 ITSO but there may well have been others.

In 2009, the problem is not entirely solved, and there is a new one: how to decide which to use of several possibly valid ticket products stored in the card. On a bus with a driver, the passenger could be asked to choose – but that delays boarding. At a rail station gate, or in any other automated situation, there is as yet no solution.

Extension to multiple, co-existent schemes

Where the carrier for the ticket dataset is to be used to hold datasets for multiple, independent schemes (e.g. a ticketing scheme and a building access scheme, or two independent ticketing schemes), logically a directory is used to select the required scheme before starting to process the ticket. Physically, this might be implemented at card platform level in a multi-application card platform’s application directory, or in the terminal as a table of potentially available applications, or there might be a table of start sectors when a memory card is used, with the table stored in the terminal.

Next we have to develop a universal model for multi-function, intersecting schemes, where any one ticket machine may have to make decisions not only on which scheme to operate but also between tickets spread across different, co-existing schemes. Further notes on this topic are found (V3.0) in the Annex.

tsa_v3-0.doc 20 V3.0 PWT 16/1/09 Change history

Independent version (not tied to the UK Mirror Group for CEN TC224 WG11).

Main ticketing system architecture complete. Associated security model not yet built, and therefore the security section is currently a set of working notes.

V1.1 6/3/02: Introduction p.2 1st para lines 6 & 7: clear up a logical error. Also correct a few typos.

V2.0 13/7/02: Notes added (Annex, Introduction, last section before Change history) re co- existence of multiple schemes and implementations.

V3.0 16/1/09: General detail updates and clarification.

tsa_v3-0.doc 21 V3.0 PWT 16/1/09 Annex

Security

I noted above:

the security requirements for a driving licence and a £1 (Eur 1.10) single trip ticket are somewhat different

In developing this model, I have come to realise why, in the development of implementations (and sometimes, but not always, of detailed technical specifications to go with them), overall scheme security has been neglected. This is because there has not been an overall coherent scheme concept that the security experts can use to develop classical top down security methodology. Can there be such a concept as automated distributed security methodology in a rococo (fragmented) scheme design? Mondex (bank e-purse secure enough to be used to hold money without having a backup account) proved that there can be a unifying and automated security methodology in a distributed scheme, but that was designed and implemented from the top down – we cannot adopt it here. Can we instead run a trust model such as that used by the credit card industry? No, we cannot, because the credit card model handles only money and not delivery of goods or service: that delivery contract is between seller and purchaser, although the card associations have reluctantly had to accept some responsibility for rogue traders. I left this one open in 2002 and to some extent still do, and have included here only a set of fragments rather than an overall methodology. However, to complete this paper, we should aim to introduce concepts of both ticket level and end to end security, in a situation where there is often little like that with present implementations. Security by obscurity tends to be the methodology, but that will have a shorter and shorter life as security cracking methods become cheaper and cheaper to use.

When building the security model and its implementation, it is important to understand that there is always a major constraint in transport ticketing in particular. This is the need, in very many situations, for high transaction speed, so that, for example, an RSA asymmetric crypto calculation was generally not permissible in 2002 – but it is viable in 2009.

The following fragments had in 2002 been collected as input to development of a security model for ticketing systems.

1. Because there is no overall security methodology in ticket processing in an interoperable environment, implementations frequently employ different security methodologies at different stages in the whole process. Data mining in the back office then has to be used to combat fraud.

2. One concept used is that of ‘binding’. For example, a ticket data set may be secured by a cryptographic certificate for which the key is computed from a combination of a master key, the permanent serial number of the card (the manufacturer’s serial number), the identity of the issuer of the ticket, etc. Thus the ticket is said to be bound to the card, the ticket issuer, etc. Further security comes from scrambling the contents of the certificate. This makes cloning the ticket/card/ticket issuer/etc combination difficult, but does not stop the ticket being altered by any equipment that has access to all the information (including the master key) required to compute a valid certificate.

tsa_v3-0.doc 22 V3.0 PWT 16/1/09 The above certificate methodology requires every terminal that processes that ticket to have the relevant master key at the application (ticket dataset) level, plus the usual card platform level keys for access to the storage units (EF or memory card sectors). In the situation where there is more than one ticket or related dataset (product) on the card, plus a directory, and many ticket issuers, there soon appears a huge key management problem.

3. A lower level concept is that of an incrementing serial number associated with a ticket. For example, a season ticket or concession pass may include a counter of journeys made. This count is returned to the back office every time the ticket is used, and the relevant back office checks for an always increasing value of the count during the life of the season ticket or concession pass (but making that check is not easy, as transaction messages may arrive out of order).

4. In a set of card schemes which are linked for interoperability purposes, messages generated by a card to terminal transaction may have to be distributed to several back offices. In general, the terminal builds the messages and includes in each one the destination address (or addresses) of the back office or offices that need that message. Each message is then secured with a certificate that the relevant back office or offices can check, and off it goes, but with a copy kept in the terminal. From there several models apply:

4.1 In the transmission of messages to the back office, it is often convenient and/or commercially necessary to send all messages, generated from an encounter with a ticket, to the logically local back office (as in Fig 3) – ITSO works like this. The local back office checks all the certificates, and, if all are good, sends an Ack back to the terminal. On receipt of the Ack, the terminal can delete its copy of the messages. If the back office finds messages for another back office, it sends them off to the relevant back office, keeping a copy; when it gets an Ack back, it can delete its copy. This is a store and forward method, but is not end-to- end secured transmission.

Problems which can occur here include:

 one back office may (due to error, or perhaps deliberately) fail to send on all of the messages addressed to the other back offices, and such failures are not immediately obvious

 a back office beyond the first one may Ack a message, but then later discover a problem with its content – by now the terminal has been sent an Ack, and will have destroyed (or will at least have permission to destroy) its copy of the message and of all associated messages

4.2 The messages are sent off as above, with the Ack being returned from each message’s from its ultimate destination, an Ack which has to reach the source terminal before not only the backup copy of that message but also all messages associated with that transaction can be deleted. This is very expensive to implement and operate.

4.3 One improvement here is to generate a transaction certificate as close as possible to the ticket dataset (in an implementation of Type 1 in Fig 4, which is a secure smart card with built-in state machine, this certificate can easily be generated in the card). This certificate is then attached to all back office messages generated as a result of the transaction with the card.

tsa_v3-0.doc 23 V3.0 PWT 16/1/09 One of the recipients is the back office holding the ‘application account’ used for backup purposes, and it and it alone shall have the means to decode the certificate. Coupled with suitably arranged holding times for keeping copies of the messages at the back offices, when a problem occurs all the messages associated with that card transaction can be retrieved by the ‘application account’ back office for analysis.

4.4 For memory cards, a variant of 4.3 is to create that certificate in the terminal when a ticket is loaded into the card, and then add it to the fixed data in the ticket stored in the card.

4.5 Another variant of 4.3 is to use the SAM in the terminal to generate the certificate that is sent with all the messages created from a single transaction with the card – as with some other implementation methods, this requires the terminal to be trusted not to spoof the SAM.

4.6 For the sale of high value tickets, it becomes both desirable and possible to use asymmetric encryption and online terminals, and thus carry out an end-to-end transaction between card and back office, protecting the fixed data of the ticket from being altered. The asymmetric encryption should be a high speed type, so that the ticket can be checked fairly quickly – but it may also be sensible to have a second certificate attached to the ticket (using, say, triple DES) for even faster checking.

4.7 And, of course, there are usually two levels to security in the card: data access mechanisms at the card OS or hardware level, and certificates at the application level.

4.8 Jan De Meester (Integri) has suggested the following:

If you want to make a generalised security model, I would recommend not to re-invent the wheel and to inspire yourselves on EMV. Of course this must be reviewed to cope with the different players and with the fact that it should also work with memory cards, but a lot of EMV remains useful.

As you want to support also low price ticket products, I would propose 3 kind of security levels (needs to be worked out in more detail of course) : - passive RSA : ticket includes a signed but static RSA cryptogram (protects against reproduction) (this is not acceptable in EMV, but would be make a ticket possible on a memory card) written onto the ticket with each transaction - passive RSA, active DES : ticket includes a signed but static RSA cryptogram (protects against reproduction) and a dynamic DES cryptogram (protects against replay) - active RSA : ticket includes a signed but active RSA cryptogram (protects against reproduction, duplication and replay)

(PWT: for RSA, we should read the more general word ‘asymmetric’ or the phrase ‘asymmetric cryptography’, as per David Everett’s suggestion at a 2002 seminar that there are much faster methods than RSA.)

Regarding your architecture in general, I personally would change the concept of a terminal to a more conceptual unit. In my opinion, one first needs to work out the security architecture, then see where the "assets" are to be protected and then in the end define if it will be necessary to have a classic POS device with SAM ! Maybe you will find out that you have sufficient level of security when e.g. a "low value sale"

tsa_v3-0.doc 24 V3.0 PWT 16/1/09 terminal works off-line without RSA. For this analysis, I would recommend to inspire yourselves on the Common Criteria, which is a superb guideline for doing security assessments, even when you are not interested in obtaining a certain EAL for a certain product.

(PWT: IOPTA started down the CC assessment route, but I don’t think that anything about that went into the standard.)

Update January 2009:

5. The ITSO security model has not significantly changed, remaining as a single security domain in which all the interoperable set of schemes are included. However, it has also not been documented separately by ITSO, so in 2004 the author and Dr David Everett, as part of a joint contract for DfT and ODPM, prepared an analysis under the title ‘Multiple smart card schemes in one security domain’. That document was submitted to the first meeting of AILO. For a copy of that document please email [email protected] .

6. It has recently become known that a European study group has been looking at interoperability across multiple security domains. ITSO Ltd is believed to be participating in the work, but no details have been released.

Contracts and tickets

Once again, it must be emphasised that implementation does not always have to be explicit. Indeed, in many existing public transport systems, the process is mainly carried out by the vehicle operator, and even the ticket may be non-existent. The legal contract between service provider and ticketholder, however, must always be there.

For example, boarding a bus and purchasing a ticket may not even produce a printed ticket (receipt) – merely boarding a bus, putting enough cash in the fare box while being observed by the driver, walking past the driver, and then exiting the bus at a later stop on the route, may comprise the entire ‘ticketing process’.

In a 2002 email, a solicitor (Donald Ramsbottom) gave an informal description of one style of contract negotiation between bus passenger and operator:

As for a bus ticket, legally all it is, is a receipt for monies proffered. It is not the contract, although as a receipt, it can still point to where T&Cs may be found. In the bus scenario, the passenger at the bus stop is putting out an "invitation to treat", the bus driver stops and the customer gets on and states the destination required, the "offer", the driver then accepts the fare, and the contract is complete, with the performance of the same being completed upon debussing.

That is a view of the law on contract as it exists in the UK. Other European countries will have different contract law, putting more emphasis on setting out beforehand the description of the contract being offered, interpreted here as a pro-forma of the ticket. Then details of the actual service being provided (e.g. start time of a period ticket in an urban metro system) are written into the pro-forma either at time of purchase of the ticket or at time of starting to receive the service.

tsa_v3-0.doc 25 V3.0 PWT 16/1/09 In talking to UK suppliers and reading standards and specification documents, I have become aware that there are some problems with terminology in this area. When a ticket is purchased, a contract is entered into: supply of (or a promise to supply) goods and/or services, in return for a consideration (payment now or later). (The concept of general ‘Stored Travel Rights’ (transport token purse) complicates this a little, but does not nullify the concept; also the existence of ticket selling agents complicates things, but still does not nullify the concept.) In an AFC (Automatic Fare Collection) system, during the entering into the contract, a ticket is loaded into the card. Since this is an AFC system, the card must have space for information describing the ticket’s progress, and that may be part of the ticket dataset or may be separate space on the card – ITSO is not always fully compliant in this area, but only because the service operators, etc, have not carried out the necessary work on the ticket handling and journey management processes, and thus ITSO Ltd has not been provided with the necessary information for inclusion in the ITSO Specification..

Now I have heard and seen:

 The ticket (as loaded into the card) described as the contract. This is incorrect in UK law – and one very practical point is that the contract still exists even if the ticket is lost or destroyed.

 Concession passes, etc, described as being part of the user’s ‘profile’. This is also incorrect: the concession pass (permission to travel at a discount or completely free) is just as much a ticket as the simple single trip ticket obtained as a result of paying on the vehicle. The concession pass represents a contract, perhaps between government and the operator of the service, to allow the pass holder to obtain service at a discount. Now it may be the case that some information in the cardholder’s profile (e.g. date of birth) has to be used to verify the validity of the concession pass, but that does not negate the fundamental position that the concession pass is a ticket.

 The term ‘sub-contract’ being used for the business of entering initial data into the progress area at the time that the ticket starts to be used; I contend that this is not the case. The initial contract was made at the point of sale. If, however, the operator delivering the service insists that you enter into a contract with him (if it was not his ticket that was sold), that is not a sub-contract; instead, your original contract only sold you a right to travel a specified route, etc, and you are now entering into a new (but derivative) contract with the operator, for which the consideration is handing over the right to travel (by means of which the operator can claim reimbursement from the collector of the money). If you purchase the ticket from the operator on whose service you travel, then again entering progress data at the time of travel is not a sub-contract; rather, it is more like a schedule of work such as is used in written contracts.

Multiple co-existent implementations, and multiple co-existent tickets within an implementation

The intent of the basic model is to permit multiple implementations, and a consequence of this is that significant numbers of cardholders will regularly receive services within and across more than one implementation.

tsa_v3-0.doc 26 V3.0 PWT 16/1/09 It is also clear that, within any one implementation, a cardholder may have more than one ticket type in that cardholder’s ticket dataset.

An example that includes both of the above situations is the commuter from one urban area to another urban area. This traveller may well have:

 a season ticket for commuting  a local ticket or set of (carnet) for one urban area  a local ticket or set of (carnet) for the other urban area

The two urban areas may operate different local implementations, and the inter-urban commuter route may operate another implementation. The commuter may wish to have one through ticket from home to office. The urban areas may agree to operate the inter-urban commuter route’s implementation.

Another example has more than one ticket type for one implementation: a traveller within one scheme may have a carnet containing unused single journey tickets, but may also make use of day tickets.

In between the two examples above is another one which is technical only (i.e. one which the cardholder should never be aware of): more than one implementation within one scheme. One ticket type within a single scheme may use a small memory card, another may use a sophisticated microprocessor card with an on-board high security state machine.

The ticketing equipment is therefore presented with multiple choice cards as well as multiple types of card, and has to make a very rapid decision on which ticket to use, and which implementation of the process to invoke. The implementation problem is (but within quite narrow bounds) already well reecognised in the following forms:

 within one scheme, use of a memory card with simple sector level security keys, and of a microprocessor card with application-level mutual authentication between card and terminal and a ‘commit’ function  ad hoc solutions where an urban scheme and a commuter scheme into the same urban area overlap

The multiple implementations within one card is only now becoming a serious concern (that statement was made in 2002, and it is a measure of the slow pace of progress that there was no change until 2007, at which point it became clear that rail service operators were going to bypass it by ensuring that there is only one relevant ticket product in a card).

To describe all this, first a new dimension has to be added to the model of the dataset: it has to include structured information to assist the ticketing process to make the choice between different tickets across different implementations.

There is a parallel here with the problem in the ISO/IEC 14443 inclusion of two card technologies: Type A and Type B. The terminal can poll in turn for Type A and Type B cards. If A and B cards are both introduced into the field of the terminal’s antenna, the terminal will lock onto whichever type of card it first detects (poll and response is needed), and then carry out an anti-collision sequence in order to resolve all the cards of that type. Cards of the other type are ignored during this sequence.

tsa_v3-0.doc 27 V3.0 PWT 16/1/09 In ticketing, where we tend to say that the cardholder must present only ONE card, the terminal cannot, within that card, search the dataset belonging to just one implementation until it finds a ticket that it can use, and ignore other implementations – thus is required a unified mechanism for indicating, within the card, actual or potential tickets for use. (This is an attempt to describe an abstract logical requirement, derived from statements from scheme operators such as ‘we need a top level directory in the card, allowing selection from tickets across more than one scheme’.) (Note also that, when using longer range contactless technology, such as Vicinity cards or tag technology, it becomes difficult to insist on the cardholder presenting only ONE card – unused day tickets in the pocket might be detected as well as the day ticket in the hand.)

A cautionary note: a model which significantly extends the processing time is unacceptable. Therefore, with present day technology, it is vital to minimise the number of commands to a card, and particularly the number of write commands.

Rather than use the term ‘directory’ at this stage, we have to extract the requirements, and this section of V2.0 of this paper was just a start in this area:

 As a high priority (i.e. very early in the processing of the card), all active tickets in the datasets have to be indicated; but, more generally, ticket status has to be indicated (e.g. no need to inspect used tickets, although they may be candidates for deletion if a new ticket is to be issued)  The applicability of tickets in the datasets has to be indicated (e.g. domains (schemes?) within which the tickets have been issued)

By referring back to earlier sections of this paper, we now see that:

 the status of all the relevant classes of tickets in a card has to be easily available (status includes unused/active/used) (this might mean all tickets in the card, whether they be for transport or concerts or fairgrounds)  the data associated with each ticket has also to be made available in a structure which relates directly to the ‘ticket choice’ decision process in the terminal

As with the IOPTA work and smart card work in other areas, thoughts immediately turn to descriptions of the dataset and its control structure using ASN.1 methodology, and, derived from that, TLV format implementations.

It also begins to be very important that there is provision for plain text ticket descriptions to be included in the card, for use with ticket viewers that do not or cannot hold those descriptions. A ticket viewer installed in every carriage of a train? By 2008, mobile phones were widely distributed, so another solution is to provide access by phone to a remote server holding details of the tickets issued – but that does not work everywhere.

References: Standards and specification bodies

AILO Association of ITSO Licensed (and would-be licensed) Operators

tsa_v3-0.doc 28 V3.0 PWT 16/1/09 CEN European Committee for Standardisation TC224 CEN’s Technical Committee 224 TC224 WG11 Working Group 11 of TC224, responsible for standardising the ‘front end’ of public transport ticketing systems TC278 CEN’s Technical Committee 278, responsible for standardising transport ticketing architecture ISO International Standards Organisation IEC International Electrotechnical Commission (For numerous technologies, including smart cards, ISO and IEC work together through their Joint Technical Committee 1 – JTC1) IFM Interoperable Fare Management, standardised for single security domains by TC278 as EN ISO 24014-1 IOPTA Inter-Operable Public Transport Application, standardised by TC224 WG11 as EN 15320 ITSO Now just ITSO Ltd, but in 2002 Integrated Transport Smartcard Organisation Ltd: a UK membership company developing a voluntary specification for public transport ticketing, with support from the UK Govt’s DfT (previously DTLR)

tsa_v3-0.doc 29 V3.0 PWT 16/1/09