## 2 Related Work
### On-Boarding
When the node starts, the corresponding public key of the private key is uploaded to the central server, which concludes the installation. Hewlett Packard (HP) has its own Swarm Learning (similar to DA) framework for the analysis of decentralised data [25]. Their on-boarding manual ([[https://github.com/HewlettPackard/swarm-learning/blob/master/docs/setup.md](https://github.com/HewlettPackard/swarm-learning/blob/master/docs/setup.md)]([https://github.com/HewlettPackard/swarm-learning/blob/master/docs/setup.md](https://github.com/HewlettPackard/swarm-learning/blob/master/docs/setup.md)), accessed on 18 February 2022) states a sequence of Docker commands to be executed until the software is deployed. Lastly, a mandatory licence installation has to be conducted. In their whitepaper ([[https://www.hpe.com/psnow/doc/a5000034](https://www.hpe.com/psnow/doc/a5000034) tenw]([https://www.hpe.com/psnow/doc/a5000034](https://www.hpe.com/psnow/doc/a5000034) tenw), accessed on 18 February 2022), they state that the on-boarding is an offline process and future participating parties need to communicate beforehand to find mutual requirements of the decentralised system. Another framework, called _Flower_, has been proposed by [PERSON] et al. [26]. They provide wrapper functions for the communication between each data node. Similar to vantage6, the necessary software can be downloaded using the pip installer ([[https://flower.dev](https://flower.dev)]([https://flower.dev](https://flower.dev)), accessed on 18 February 2022). To connect clients with the server, the wrapper functions have to be implemented by the station admins such that a mutual encryption policy and a customisable communication configuration can be established. A more use-case-specific and ad hoc on-boarding workflow has been presented by [PERSON] et al. [15]. They have made installation manuals online available ([[https://github.com/RadiationOncologyOntology/20](https://github.com/RadiationOncologyOntology/20) kChallenge/wiki/Tutorial]([https://github.com/RadiationOncologyOntology/20](https://github.com/RadiationOncologyOntology/20) kChallenge/wiki/Tutorial), accessed on 18 February 2022) and have provided remote support for the establishment of their data sharing network to perform distributed learning on 20,000+ lung cancer patients. After reviewing the current state-of-the-art of DA on-boarding workflows, we have detected several potential shortcomings, which we have classified into three categories. First, some workflows do not contribute to FAIR data management or _FAIRification_ of DA infrastructures as participating parties are not necessarily findable, for example. Therefore, each infrastructure acts as a blackbox to its users since the participating parties are not visible. Consequently, the connection information or other metadata for an institution has to be communicated through other channels to access the data. Additionally, there is a lack of _automation_ in these workflows. Especially, the manual key exchange mechanism might pose some security risks if these are distributed within third-party channels. Further, the needed detailed configuration for some components (e.g., IP addresses, ports, certificates, secrets) might be another obstacle for non-technicians to set up a connection to the central services. Lastly, the _installation_ or deployment should support the acceptance of the system-particularly if CLIs are involved. In this work, we address all these mentioned potential shortcomings (FAIRification, automation, and installation) and propose an on-boarding process for DA infrastructures. We hypothesise that such a seamless on-boarding contributes to an increased acceptance of the software and by fostering the FAIR principles from the very beginning, it accelerates the execution of collaborative clinical studies. In the next section, we present the workflow in more detail.