3. BoB Components

3.1 The Sales Channel

The architecture is centered around sales channel which is the traveler's entry point into the infrastructure. The sales channel, which has the customer relationship, is the part which registers the traveler's contact information (where necessary).

Apps

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

It is expected that the communication between the Apps 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. 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.

Customer Support functions

The Sales Channel may have to provide certain basic functions to entities responsible for customer support. For this reson there is a Traveller API endpoint, where customer support personel can lookup information pertaining to a traveller. A transport company is also able to convey notifications to the traveller through this interface, and it is also used for ID-based traveling, when issuance of new tickets are requested. 

3.2 Price and Product service

The Price and Product (P&P) service component implements all the business rules surrounding the tickets. The P&P service is therefor 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 an entities Ticketing service and its P&P service, whereas the Ticketing service will always issue any tickets modelled by P&P. The P&P provides an electronic ticket template called a manifest, which the Ticketing service accepts as proof of an existing and valid product. The Ticketing service uses that information for issuing a ticket (and generates the basis for set-off). The manifest is cryptographically signed by the P&P service, and this signature is subsequently validated by the Ticketing service to determine wether a manifest is legitimate and authentic.

The P&P service provides a search query interface which the sales channel can use to retrieve different product options for a specific trip. The P&P service 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 the P&P service can be used to retrieve prices and products for that trip, or a specific leg of a trip to be combined into a complete journey.

3.3 Ticketing service

The Ticketing Service issues tickets based on manifests. The manifests are issued by the Price- and Product service as described in section 2.3 and conveyed to the Ticketing service through the sales channel. The Ticketing service is normally stateless, and can be instantiated in multiple locations simultaneously to provide redundancy. The Ticketing Service registers all information pertaining to issued tickets in a data warehouse. Naturally, the Ticketing Service 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. 

3.4 Validation Service

The Validation Service provides the functionality required to determine if a ticket is valid at a specific time at a certain route. 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 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. Therefor, 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. 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.

3.5 The Coordination Function

The Coordination Function within the national BoB infrastructure is managed by Samtrafiken. This Coordination Function collects, aggregates and distributes so called Metadata from the different participants. By retrieving this 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 (wether 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. 

3.6 Authentication Service

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.