This document accompanies the Work Package deliverable D2.1, which is a demo available as a video (screen recording) at https://www.youtube.com/watch?v=I0PlqiUBT0I. The demonstration itself would be of little information value without proper explanation. Moreover, the demo format does not provide opportunities to explain design decisions that led to the approach taken to build this federated EFSS infrastructure. Besides the demo description, this document sums up the first project year in Work Package 2, reporting on its progress during this time period. Note that this document summarises the work done in the first year and some topics in this document are still subject to discussion and have thus not been finalised yet. As of the inception of the project proposal, which was written between December 2018 and January 2019, it was expected that deliverable D2.1 would be about a demonstration of implemented federated identity management. We then held the view that federated identity management was crucial for the project and the sharing of data and applications over different Enterprise File Sync and Share (EFSS) systems could not exist without it. There has been extensive insight ever since that this may not be the best approach to tackle the problem. The Interoperability Platform (IOP) that is currently under development and has been deployed at majority of partner sites, plays a significant role in federating the infrastructure. Amongst other things, we have considered the option that the IOP would implement an invitation workflow, which would be of key importance to solving this issue in an elegant way. This workflow would result in an exchange of tokens which would allow users to share data and applications over different EFSS installations at different sites where they only need to know each other's email addresses or similar contacts. While still agreeing that federated identity and group management systems can be used for this end, we have realized that they are by no means a necessity in order to create the mesh functionality that the CS3MESH4EOSC project aims to deliver. In Section 2 we describe the demo itself. The description should be self-contained for readers and demo viewers who are just interested in the status of things. More in-depth information may be found in the subsequent sections, especially reasoning behind the design decisions. User, group and application workflows are described in Section 3. Building the Science Mesh federative infrastructure with AAI, monitoring, accounting, security, mesh governance and requirements related to the ingress of new sites are described in Section 4. In Section 5 we list the sites which have currently deployed the interoperability platform. Section 6 deals with entering EOSC and the requirements that need to be fulfilled. Finally, Section 7 contains a brief discussion about future work.