[Discussion]: DESIGN PRINCIPLE: Support for federation/interconnected TREs/multi-domain

[machintim]

Summary

Propose a principle that SATRE supports data being brought together

Source

DARE federation paper and other discussions

Detail

The SATRE architecture should support federation and connections between different data providers and data domains. This also aligns with the DARE federation paper and the work being done in TRE-FX etc.

Not to sure what this one should say but again it should have a statement, rationale and implications.

Intended Output

No response

Who can help

@jemrobinson @harisood - do you have Rob B's username? would be good to get his input on this one.

[harisood]

Not sure if he has GH, will share the issue with him!

[rmbaxter67]

Here I am ;-). Good principle to have; the future's going to be full of connected TREs (probably maybe ;-) ). I think I'd word it as "support for interconnected TREs". Federation is (I'll assert) something that can sit alongside TREs: vis, you don't need a pair of Security Servers to connect TRE A to TRE B (TELEPORT doesn't, f'r instance), but in a future network of many-to-many, you need something to standardise and formalise the trust relationship between them all, and that's what federation (and its standard Security Server gateways) is all about (as Simon T has observed). Interconnectedness reaches inside a TRE, though, so is firmaly in SATRE's scope. The way I draw the "API Services" is meant to indicate they're part-TRE scope, part-Federation scope -- the principal interfaces between TREs. My classification into types -- Query/Result, Data Movement, Indexing and Software -- is pretty abstract and may not necessarily survive contact with the enemy (as in, people like yourselves actually doing the details ;-) ) -- in which case I'll adapt accordingly. Sometime, before the end of October but not too much before, you, I, TELEPORT and TRE-FX should proabbly have a big old integration brainstorm about these connection points.

[machintim]

Interesting @rmbaxter67 as a principle rather than any specific addition to the design I think would look something like the below. I am sure there will be lots of other implications, @harisood , be good to hear the community on this.

Research environments will support interconnectivity and federation Rationale The quality, scope and speed at which research is delivered can be increased by the ability to interconnect data of different types across multiple TREs. While much of the architecture to achieve this may sit outside the scope of the SATRE architecture must support and enable interconnectedness.

Implications

• A cross federation service and service provider will be required to govern standards and manage shared infrastructure and applications.
• Existing environments will need to change to align with a set of standards for which they were not originally designed.
• Identities, authentication, and authorization needs to be independent of a single organisation.
• Increasing need for standards for APIs, software services, indexing and cataloguing.

[JimMadge]

@all-contributors please add @rmbaxter67 for ideas

[allcontributors[bot]]

@JimMadge

I've put up a pull request to add @rmbaxter67! :tada:

[harisood]

Hi team, as this principle wasn't discussed in the Collab Cafe, and haven't seen any further convos since, should it be dropped as a principle? It's loosely/tacitly touched upon in standardisation (see #241) but not very specific on federation. What do we think?

[manics]

I think we should drop it, but add it as a FAQ- SATRE can form the basis for future federation/interoperability/etc standards, but in itself is not about interoperability.