The basic architecture of the different parts of a ticket system and it's BoB API's:
The Participant Metadata is in a National database maintained by Samtrafiken. This is a registry of all participant in the BoB community. To be able to communicate through BoB you need to be registered here with your public keys used to identify yourself to another participant. This is part of the security built into the standard.
A Token Publisher is an ID producer that provides IDs that comply to the BoB definition described in MTS7. These IDs are stored in a Proximity Integrated Circuit Card (PICC). When a traveller buys a journey then the right to travel is registered in the local ticketing system with a reference to the travellers ID. When the travellers wants to perform their journey they only have to show their ID and the right to travel will be found in the ticketing system. This produces new possibilities for a more flexible sales procedure and the ID can be stored in a form that is convenient to the traveller (e.g. in a phone or any other wearable accessory).
A Sales Channel can be one of many things such as a re-sellers system, an app, a ticketing vending machine or similar. This funcion 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.
The Local Back End Ticketing System, consisting of the Price & Product which stores data about prices and business rules, Ticket Engine which produces, stores and administers data on digital tickets and, in some cases, a module for On-demand Traffic booking.
The Validation/Inspection handles verification of travel rights. This is usually done through an app or different form of readers (validators) that can interpret BoB tickets or BoB IDs.
The BoB-standard is illustrated by the green boxes.
Other different colours in this picture, with exception of the Participant metadata, illustrates that they are stand-alone functions. They can be operated by one organisation only. However the standard makes it possible for different organisations to operate them. So the Token Publisher can be one organisation, the Sales Channel another and Validation/Inspection a third with a fourth being the one operating the Local Back End Ticketing System. Or any combination there of.