In this working group we will identify common concepts that SREs/TREs implement in different flavors, suggest common interfaces between those concepts and communicate them to the public in three different work streams (subgroups).

1. Blueprints
2. Interoperability
3. Risks

Read more in our WG Case Statement or click “view more” below.

Working Group:

The conflicting goals of protecting and maintaining control over sensitive data, confidential data or data protected by intellectual property rights, while striving to give third parties access to the data, pose a significant challenge. Trusted Research Environments (TREs), also referred to as Secure Research Environments (SREs), have been established in the last decade that, when properly set-up and operated, help ease this problem by providing high security guarantees of a highly controlled and monitored environment.

The Working Group on Trusted Research Environments for Sensitive Data (WG-TRESD) seeks to produce a better understanding of the elements making up TREs (and their different extensions, flavors, etc.) and the processes running in and supported by them, bridging terminology boundaries to ease the set-up and operations of, and the co-operation and interoperability between, such infrastructures, enabling FAIR access and use of data in such restricted settings.

Following the TRE Green Paper requirements we consider systems where users are presented with a remote desktop where they can run analysis on confidential data (applying algorithms to datasets exploratively). With this working definition, we do not consider job-submission systems like Blind SANE who apply (approved) algorithms to sensitive/confidential data a full TRE, while such components may form part of the tooling environment for specific types of interaction. We found that many SREs/TREs are similar in architecture design and technical implementation. There is, however, a lack of openly available guidelines and explanations on design decisions for setting up and running a SRE/TRE, including technical implementation of roles and their permissions, ingesting data, processing data, exporting data, provision of virtual machines/compute units, isolation, privacy-preserving techniques, etc. This deficiency comes to light especially when planning towards federation across SREs/TREs to connect infrastructure providers with shared interfaces, bilateral trust and shared resources or data, due to the lack of standards.

In this working group we will identify common concepts that SREs/TREs implement in different flavors, suggest common interfaces between those concepts and communicate them to the public in three different work streams (subgroups).

1. Blueprints
2. Interoperability
3. Risks

Read more in our WG Case Statement or click “view more” below.

Working Group:

The conflicting goals of protecting and maintaining control over sensitive data, confidential data or data protected by intellectual property rights, while striving to give third parties access to the data, pose a significant challenge. Trusted Research Environments (TREs), also referred to as Secure Research Environments (SREs), have been established in the last decade that, when properly set-up and operated, help ease this problem by providing high security guarantees of a highly controlled and monitored environment.

The Working Group on Trusted Research Environments for Sensitive Data (WG-TRESD) seeks to produce a better understanding of the elements making up TREs (and their different extensions, flavors, etc.) and the processes running in and supported by them, bridging terminology boundaries to ease the set-up and operations of, and the co-operation and interoperability between, such infrastructures, enabling FAIR access and use of data in such restricted settings.

Following the TRE Green Paper requirements we consider systems where users are presented with a remote desktop where they can run analysis on confidential data (applying algorithms to datasets exploratively). With this working definition, we do not consider job-submission systems like Blind SANE who apply (approved) algorithms to sensitive/confidential data a full TRE, while such components may form part of the tooling environment for specific types of interaction. We found that many SREs/TREs are similar in architecture design and technical implementation. There is, however, a lack of openly available guidelines and explanations on design decisions for setting up and running a SRE/TRE, including technical implementation of roles and their permissions, ingesting data, processing data, exporting data, provision of virtual machines/compute units, isolation, privacy-preserving techniques, etc. This deficiency comes to light especially when planning towards federation across SREs/TREs to connect infrastructure providers with shared interfaces, bilateral trust and shared resources or data, due to the lack of standards.