The BoB Architecture

Architectural overview

The reference architecture for BoB specifies the interfaces, data models and information flows required for interoperability between participants. How the functionality is implemented internally by each entity is heavily dependent upon the entities own business requirements. The architecture consists of four key components; sales channel, price and product , ticket engine and validation/inspection.

Sales Channel

A Sales Channel can be one of many things such as a re-sellers system, an app, a ticketing vending machine or similar. This function is usually the travellers interface through which they buy their journey. In some cases these can also store or deliver a ticket distributed by the Local Back End Ticketing System. A Sales Channel is generally linked to a payment service provider that handles the payments. The Sales Channel can be from the same company as the ticket provider but it can also be a totaly separate company.

The Sales Channel is the function that the customer faces. It needs to provide information about which tickets are available, how much they cost, how much time is left on your valid ticket etc. It gets a lot of this information by communicating with the other modules. The Sales Channel exposes an interface (the device endpoint) where trusted participants can retrieve individual device keys or current Key Derivation Keys (KDKs), depending on the degree of trust established between the two parties.

It is expected that the communication between the Sales Channel and the back-end systems is done through proprietary interfaces, as this is not something that affects interoperability within the infrastructure. Transfer of the device key needs to be done in a protected manner, preferably through the use of encryption. The device key should be encrypted by an encryption key known only by the software and the issuer of the key. It is common for such encryption keys to be produced by including a hash of the binary code being executed. In this way the hash (and therefore the encryption key) will be incorrect if the binary is manipulated. It is also appropriate to enforce access control to the interface with the backend, so that not any device can retrieve any other device's keys.

To enable a travel company to provide customer support in situations where another party (an independent sales function) has made the sale and manages the customer relationship, some basic information about the traveler is typically required to provide such support (for example a refund). For this purpose the sales channel also provides a special interface ( "traveler") that can be used by the carrier (or other party providing customer support for the carrier).

Prices and Product

The Price and Product module delivers information to the Sales Channel on available products, prices for journeys and other business rules. This information constitutes basic input for ordering a ticket from the Ticket Engine.

Price and Product implements all the business rules surrounding the tickets. Price and Product is therefore the authoritative source of such information, and this logic should not have to be implemented anywhere else in the infrastructure. There is a trust established between the Ticket Engine and its Price and Product, whereas the Ticket Engine will always issue any tickets modelled by Price and Product. The Price and Product provides an electronic ticket template called a manifest, which the Ticket Engine accepts as proof of an existing and valid product. The Ticket Engine uses that information for issuing a ticket (and generates the basis for set-off). The manifest is cryptographically signed by the Price and Product, and this signature is subsequently validated by the Ticket Engine to determine whether a manifest is legitimate and authentic.

The Price and Product provides a search query interface which the sales channel can use to retrieve different product options for a specific trip. Price and Product is however not a trip planner, it is required that the sales channel already has that functionality to ensure feasibility of a certain trip. When that has been determined Price and Product can be used to retrieve prices and products for that trip, or a specific trip to be combined into a complete journey.

Ticket Engine

The Ticket Engine receives orders for tickets and establishes the information that is to be stored on the ticket, including an electronic stamp that guarantees the validity of the ticket. The Ticket Engine then returns all the ticket information to the Sales Channel.

The Ticket Engine also stores and administers data on digital tickets. All transactions from validations that are made in Validation/Inspection Service are stored here. The transactions are made available in a data storage for further analysis, reports, etc.

The Ticket Engine issues tickets based on manifests. The manifests are issued by Price and Product and conveyed to the Ticket Engine through the sales channel. The Ticket Engine is normally stateless, and can be instantiated in multiple locations simultaneously to provide redundancy. The Ticket Engine registers all information pertaining to issued tickets in a data warehouse. Naturally, the Ticket Engine is a security-critical component of the participants ticketing and fare collection infrastructure. As such, it required adequate protection from attempts to compromise the integrity of the service and the confidentiality of the Ticket Signing Keys. 

Validation Service

The Validation Service provides the functionality required to determine if a ticket is valid or not. Validation is a check of the validity of a ticket in time and place. The result of a validation is either positive or negative. A positive validation result will confirm that the ticket is used at the right place, geography and/or vehicle type etc, at the right time. A negative validation result will indicate that the ticket is not valid for the place and/or time. A negative validation result can be handled in many ways depending on the business rules of the PTA/traffic company. Validation can be done by different devices such as bus validators, handheld units, gates or platform validators. A validation may also activate a ticket or payment procedure. 

The Validation Service interprets the ticket information, first by ensuring that the electronic signature provided are authentic and created by a trusted party. The second step is to check the ticket's content to determine if it is valid on the current trip, or not. It compares the information contained within the ticket with corresponding information provided from the environment in which the validator operates in, typically a vehicle where it is being provided information regarding location, direction, zones and time (among other things). The checking presupposes that the ticket is designed in accordance with the Mobile Ticket Specifications. The Validation Service typically implements a parser for the TICKLE language (MTS6), and works in a semi-offline scenario. The greater part of the validation takes place locally in the validator, where it can be executed in a matter of a few milliseconds. After the local validation, a validation transaction are sent to the ticketing backend, where additional checks can be made, for example to detect double-spending across different vehicles and revoking such tickets. Such on-line transactions may however be too slow to always be completed over cellular networks in real-time as passengers are boarding. Therefore, these checks will be opportunistic, meaning if they can not complete within a certain time window (which may vary depending on several factors, such as traveller volume and ticket types) the validation checks will pass if local factors indicate a valid ticket.

Another variant of the Validation Service is the type of validator used for ticket inspections. Inspection is a check of the validity of a ticket. If the ticket is found to be invalid, a fine could be issued. Inspection is typically handled by dedicated staff that are apart from bus drivers or train hosts. As the Validation Service is used for inspecting tickets the requirements may be different. On-line fraud checks may have longer time-outs, and the transactions sent to the ticketing back-end are sent using a different interface (the inspection endpoint), and the transactions are registered as ticket inspection events rather than validation events.

On-demand Traffic

The On-demand Traffic service is handling all the bookings of on-demand travels. On-demand travel is a form of transport which needs to be requested in advance, i.e. service will not run if there is no pre-bookings. It can be added as a request as part of an ordinary combined journey. 

When a travel is requested from the Sales Channel the Price and Product tells the Sales Channel that it has to call the On-demand Traffic Service. First a preliminary booking is made. When the Sales Channel gets the ticket from the Ticket Engine it confirms the booking of the on-demand journey and gets the booking that can be added to the ticket.

Token Publisher

The Token Publisher loads the BoB application ("Travel Card Application" according to MTS7) on a data chip in a secure way. This can then be used in an ID-based ticket system, i.e. when the traveller purcheses a right to travel (a ticket) their ID is connected to a ticket stored in the ticket engine. When a validation or inspection is performed the traveller presents his ID which is then used to find their right to travel stored in the back-end ticket engine.

Each travel document is unique since the token ID is generated from a cryptographic key (refer to MTS7 for details around cryptographic keys and ID derivation). The same Token ID (i.e. the same public-private key pair) must only reside in one physical bearer. The Token Publisher is responsible to ensure the keys can not be extracted from the bearer. The token has to be registered with each Sales Channel the traveller wishes to use. Validation service only interprets an ID (as a reference) from the travel document and sends a request about validity to the Ticket Engine.

Participant Metadata

The Participant Metadata service, also called coordination function, collects, aggregates and distributes so called Metadata from the different participants. This function is managed by Samtrafiken. By retrieving Metadata, participants are able to validate the authenticity of tickets issued by other entities and securely communicate directly with each other. The Metadata contains the Participant Identifier (PID) which uniquely identifies each entity within the infrastructure. In addition, it also contains the Uniform Resource Identifier (URI) of participants interface endpoints, public keys for validating tickets authenticity, public keys to authenticate other participants end-entities (such as validating devices, inspectors, ticket vending machines, et cetera) among other things.

As the Metadata constitutes the very foundation for interoperability, it is of particular security-critical nature. For this reason, all Metadata (whether being the complete set or an excerpt) it is cryptographically signed by the Coordination Function. Any requests to add, modify or remove metadata also required cryptographically signed operations. For this cryptography to work, there needs to be an initial key exchange between the participant and Samtrafiken. 

Authentication

Authentication in the BoB infrastructure is based on the principles of an identity federation, where trust is established bilaterally through agreements and, technically, by inclusion of the other participants' metadata in the respective systems.

The authentication function is provided by an Identity Provider (IdP) service through the authentication endpoint interface. Subjects within the infrastructure authenticates through the interface, and assigned an identity assertion in JWT format. The assertion, which is valid for a specific time period, contains information on which participant it belongs to and the subjects role, and can be used within the whole BoB-federation. The Authentication Service is thus a component of the BoB architecture which are required for interoperability.

It is often reasonable to implement the Authentication Service as part of a participant's device management for validation devices, inspection devices, ticket vending machines, etc., rather than to integrate this function is into an identity management platform.

Authentication Methods

Client TLS public key authentication is highly recommended, especially for devices in vehicles. Following this recommendation enables standardized equipment to operate within several participants' control without special adaptations. Using the public key authentication does not require a complete Public Key Infrastructure (PKI). The certificates can be self-signed and only act as a vehicle to carry the public key information in the TLS negotiation. Nothing prevents a PKI, but it is not necessary for the function. Each devices public key can be registered in a device management system and liked to the devices identity. Should the device be lost or compromised, the key can simply be blocked or removed from the registry.

Another reason to use the public keys authentication is to take advantage of so-called channel binding, i.e. that the public key (or rather a hash of the key) can be included in as an attribute in the issued JWT, enabling the receiving endpoint to make the comparison between the key used for terminating TLS session with that given in the JWT. This mitigates some of the risks associated with man-in-the-middle attacks and the unauthorized copying of JWT.

Authorization

Authorization is done in each service based on the organizational affiliation and the attributes specified in the assertion.