For a BoB participant to be able to take part in BoB together with other BoB participants certain conditions has to be fullfilled.
The particpant must be set up in the coordination function (participant metadata service), and be able to manage that data as described on this page.
The participant has to develop its own implementation of a BoB participant metadata client
Security mechanisms involving metadata keys is used to make sure that
any operation adding, updating, deleting or retrieving metadata for a specific participant that can be identified by the participant id (pid) is performed by the participant that is the owner of that metadata. The metadata owner is in posession of a participant id (pid) and is responsible for the publication and correctness of metadata for that specific PID.
that when a participant makes a request for metadata, it is guaranteed that it is the Administrative Body that has created the response containing that metadata.
The metadata keys therefore consists of two different key pairs. A client key pair used when the participants adds, uppdates, deletes or fetches (get) metadata and a server key pair used for signing and evaluating the response from the Administrative body.
Specific details on how to create and validate Proof of Posession (PoP) tokens in metadata requests using the metadata key pairs are described in MTS5.
An mandatory initial setup is performed for each participant in order make sure that the two main objectives described above for securing metadata is achieved. The setup process involves exchange of both server- and client key pairs and is described in the diagram below. The keys are ECDSA or RSA private/public key pairs. The format used for key exchange is JWK.
The metadata keys are used to implement security to both management of participant metadata and when exposing participant metadata.
The security mechanism for managing participant metadata works as follows.
This works equally well when a participant wants to retrieve specific metadata.