Introduction to the BoB Standard
Introduction
The Ticketing and Payment Standard BoB (Biljett- och Betalstandard) was developed by Samtrafiken in cooperation with Samtrafiken’s owners. The goal was to create an open module based architecture and create possibilities for interoperability between different ticketing systems and sales clients. Another goal was to move towards a more uniform way for managing machine-readable mobile tickets. The standard also makes it possible to combine several tickets into one. This would enable a traveller to present a travel document containing multiple tickets from different transport companies.
The standard has a module based approach. The traditional ticketing system is broken down into individual modules that should work independently as described in the architectural picture below. The standard describes how to create a ticket so that it can be searched, sold, read, interpreted, validated digitally, repurchased and blocked. It describes how the communication is supposed to work between the various services in the architecture and how you do all this in a secure way. It does not explain exactly how you should build your services. It is done this way so that you can keep your business rules, your fare system, your customized app for selling tickets and your way of handling reporting.
Read more about the architecture here.
The BoB Standard contains of three parts:
Mobile Ticket Specifikations (MTS)
Application Programming Interface (API)
Schemas
The MTS's, API's and Schemas together with the architecture formulates the basis, components and interfaces, for a participant to build their own BoB-compliant ticketing system.
With an implementation based on the BoB specifications, the prerequisites are created for establishing an interoperable solution. But there is also a need for an agreement to be entered between interacting parties including business rules, clearing mechanisms, etc. in order to build a comprehensive solution that is interoperable.
Mobile Ticket Specifications (MTS)
The Mobile Ticket Specifications (MTS) describes the different components you need in your ticketing system to achieve interoperability according to the goals in the BoB-standard. They contains how to build a ticket (Mobile Ticket Bundle, MTB) so that it can be read, interpreted and validated mechanically. The Specifications enable the possibility to read and interpret tickets created in both your own system as well as tickets from other systems. The specifications also make it possible to have several suppliers in the same “system domain”. For example, it is possible to, within the same system, have several sales channels delivered by different suppliers.
There are 8 MTSs:
Describes how one or multiple tickets should be bundled and signed in a secure way (the structure of an MTB).
Describes how you connect the ticket and the carrier in a secure way.
Describes how to structure the ticket information (the content of the MTB).
Describes coordination and key management between participants and the administrative body (Samtrafiken).
Describes how you should do to identify yourself.
Describes the language, Tickle, that is used to express ticket validity and how to keep the size of the ticket down.
Describes how a chip should work in an ID based system.
Describes the format of how to express time and date.
Find and read more about the MTSs here.
Application Programming Interface (API)
APIs have been developed to describe how systems and system components exchange information between each other. The API with a number of endpoints cover the entire chain from where a sales system asks the cost of a ticket to how a ticket is validated. Even repurchase and other customer-related transactions can be carried out via these APIs.
Exactly which endpoints to use depends on how the cooperation between the different parties is intended to work. As a lowest common denominator however you need to be able to handle:
Authentication
Product
Ticket
ParticipantMetadata
Device
Validation
API endpoints are described briefly below:
Authentication, authenticates (allows) equipment and units to communicate with each other in accordance with clearly specified rules (Authentication + Authorisation)
Product, the Product Interfaces to Price and Product Services, they deliver information on available products and prices to the Sales Channels
Ticket, the Ticket Interface for “Ticketing Service”, the service that receives orders for tickets and creates an MTB with information and guarantees the validity by means of electronic signatures.
ParticipantMetadata, the interface for processing and updating the central information at Participant Meta Database.
Device, provides keys for copying protection. Device Signature
Validation, "Validation Service" back end interface that a validation device uses to submit completed validations or if validation takes place online where the actual validation is made.
Inspection, equivalent to Validation but for inspection equipment.
Traveller, interface for modules with passenger information.
Booking, used for reserving and booking of demand responsive travels.
Token, used for registration of tokens and to tie them to tickets for ID-based travel.
Account*, reserved for future use.
*Initial idea: account management functions for ID-based Travel.
Resource**, reserved for future use.
**Initial idea: seat booking component in Price and Product Service”
Find and read more about the APIs here.
Schemas
A number of schema files and translation tables are also included which describe in detail how objects and data content are to be formatted. The translation tables contain, among other things, a common definition of how data fields can be abbreviated so that the size of MTB can be kept down. You can find the schemas in the MTSs.
BoB Tickets
Tickets are named Mobile Ticket Bundle (MTB) in the BoB standard. You can issue a ticket from only one participant or you can build tickets that combine tickets from several participants (you collect tickets from different participants ticket engines and bundle them together so that the customer perceives them as one ticket for the whole journey. Combined tickets requires that the fares, some of the business rules and the geography are coordinated between the participants. However, the product range and prices have no direct connection, so these can be set individually.
To make validation easy the ticket is divided into boxes. The validator finds the right box by the Participant Identifier (PID). Off course this is not how the ticket actually looks like. Read more about electronic tickets here.
BoB In Reality
Let’s go through some practical examples to make this less theoretical.
Search a ticket
In this case the customer uses an app to search a ticket for the planned journey. The Sales Channel sends a request to the Price and Product in a Ticketing System and asks for suggestions. The Ticketing System finds two tickets that matches the journey in question. Sends over a manifest containing the information about the tickets. The app indicates those tickets that are possible to purchase based on the filtering options selected by the traveller from the Sales Channel app.
Buy ticket
The customer chooses one of the tickets that are offered and payment is made via the connection of the Sales Channel with the Payment Service Provider. An order is then sent to the Ticket Engine where the ticket information with its safety content is generated and returned to the app. This generates an Aztec code that contains the ticket information. A transaction is now created in the database linked to the Ticket Engine.
Validate ticket
The Aztec code that is shown in the App is displayed to a reader that translates the information in the code into a format that can be interpreted by the Validation Service. The ticket information that is obtained is then compared with the current time, place, etc. in order to check whether or not the ticket is valid, which is indicated to the customer. Information on the valid or invalid ticket is transferred to the transaction database in the Ticket Engine. Analysis tools can now collect information in order to create statistics, settlements, reports, etc.