Page Comparison

...

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.

...

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.

...

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 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. 

...

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.

...