There was consideration for providing granular permissions, where the Booking System controls what a Broker has access to - however as the availability is based on open data feeds, there is no straightforward mechanism provided for Brokers to filter out opportunities that they can’t book via the Booking System.
So rather than providing such mechanism (and increasing the complexity of the spec), it was preferred for the Seller to trust the Broker to be booking the right things within their system, and that this filtering and permissions would live entirely on the Broker, without the Booking System being expected to enforce this.
To minimise complexity overall there’s an assumed high trust relationship between the Broker and Seller, where the Seller can simply terminate the Broker’s access if they operate outside of any commercial agreement.
So although it’s possible to use the Authentication Credentials to add booking restrictions for directly integrated Brokers - the idea is that these restrictions are not very granular (e.g. by venue rather than down to the specific sessions), such that it’s feasible for the Broker to manually replicate these in their configuration.
Middleware as a catalyst
The idea with the middleware is that it acts as a catalyst, and the Authentication Credentials provide access to the superset of all opportunities bookable by all Brokers (or just all opportunities, which is what most have implemented given the trust principles above), and it’s incumbent on the middleware to ensure that access is enforced appropriately.
To take a practical example of how this works, scaled up:
A Middleware agrees a set of “default commercials” that apply to all Brokers connected via the middleware unless specific additional agreements are in place
Let's say the Middleware serves 100 Brokers, and 100 Sellers
The Middleware does not need to contact all 100 Sellers, each time it adds a new Broker, it simply uses existing credentials and the default commercials that are in place.
If each specific Broker required registration manually with each Seller, then the Middleware’s catalyst function is greatly diminished, and the barrier to entry to the ecosystem increased - as 100 conversations need to happen for every new Broker, regardless of the size of the Broker.
Though it’s possible to consider automation of the registration of Brokers with the Booking System, this further increases complexity of all implementations - so to keep it simple the spec includes only a minimal set of Broker details provided with each booking, that can be used for audit and display to the Seller, but with no explicit Broker registration or per-Broker restrictions outside of any broad restrictions optionally enforced by the Booking System at the level of the Authentication Credentials.
Permission to book
There was consideration for providing granular permissions, where the Booking System controls what a Broker has access to - however as the availability is based on open data feeds, there is no straightforward mechanism provided for Brokers to filter out opportunities that they can’t book via the Booking System.
So rather than providing such mechanism (and increasing the complexity of the spec), it was preferred for the Seller to trust the Broker to be booking the right things within their system, and that this filtering and permissions would live entirely on the Broker, without the Booking System being expected to enforce this.
To minimise complexity overall there’s an assumed high trust relationship between the Broker and Seller, where the Seller can simply terminate the Broker’s access if they operate outside of any commercial agreement.
So although it’s possible to use the Authentication Credentials to add booking restrictions for directly integrated Brokers - the idea is that these restrictions are not very granular (e.g. by venue rather than down to the specific sessions), such that it’s feasible for the Broker to manually replicate these in their configuration.
Middleware as a catalyst
The idea with the middleware is that it acts as a catalyst, and the Authentication Credentials provide access to the superset of all opportunities bookable by all Brokers (or just all opportunities, which is what most have implemented given the trust principles above), and it’s incumbent on the middleware to ensure that access is enforced appropriately.
To take a practical example of how this works, scaled up:
If each specific Broker required registration manually with each Seller, then the Middleware’s catalyst function is greatly diminished, and the barrier to entry to the ecosystem increased - as 100 conversations need to happen for every new Broker, regardless of the size of the Broker.
Though it’s possible to consider automation of the registration of Brokers with the Booking System, this further increases complexity of all implementations - so to keep it simple the spec includes only a minimal set of Broker details provided with each booking, that can be used for audit and display to the Seller, but with no explicit Broker registration or per-Broker restrictions outside of any broad restrictions optionally enforced by the Booking System at the level of the Authentication Credentials.