search

International-Data-Spaces-Association / IDS-RAM_4_0

Focusing on the generalization of concepts, functionality, and overall processes involved in the creation of a secure 'network of trusted data' , the IDS-RAM resides at a higher abstraction level than common architecture models of concrete software solutions do. The document provides an overview and dedicated architecture specifications.
Creative Commons Attribution 4.0 International
38 stars 27 forks source link

chore: update Section 3.3.4 Data Exchange #113

Closed juliapampus closed 2 years ago

juliapampus commented 2 years ago

Closes #28

HeinrichPet commented 2 years ago

After having learned more about the Eclipse Data Space Connector during preparations for the recent Gaia-X hackathon (especially this presentation from the MVP WG (Link).

I see the reasons and the need for the structural changes, and I generally support them. I expect modularization and scaling will become an important issue in growing commercial environments. So I support extensions in this area.

Nice to hear that :)

When reading the above mentioned presentation (page 41, contract execution) it mentions source/target environment provisions (to enable ongoing policy enforcement during data operation).

This sounds like a possible way to go in the future, although the technical details behind it are unknown to me so far. But this breaks with the current IDSA status of having to send ALL data through connectors. Furthermore, provisioning of environments is not part of IDSA so far and it is unfinished in Gaia-X evolution.

Without having details/commitments about how to generally do that, no separate connector developers can work on interoperable components. This would not improve interoperability between different connectors in the field.

You are right, we extend the data transfer protocol diversity in the IDS, which can lead to incompatibilities. However, every implementation and every data provider is still free to go the "old way" via IDSCP, Multipart, HTTP Header,... . Nevertheless, we should not be too restrictive in the IDS standard. The world consists of various data transfer protocols for a good reason, all of them have certain advantages and disadvantages. With the described approach we leave it to the data provider or the connector developer to choose the appropriate protocol for the data exchange only, not for the control plane which handles all IDS metadata.

As mentioned above, I support the extensions in this area, there is overlap with my initiative in REST.

What I do not support is bringing such big changes directly into the RAM4.0. This should be introduced in IDS-G pre, be discussed and it should go through at least the IDSA TSC to be stamped IDSA compliant.

So this change was already introduced by the Dataspace Connector in mid 2021 and presented various times in the IDSA Plugfest. Also it was presented in the WG Architecture on September 15th 2021, where most of the TSC was participating. There is an open issue for that topic since November 2021: https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0/issues/28 @juliapampus presented this Pull Request/the document in the WG Architecture on March 15th 2022.

Regardless of this, the order is quite clear that the specification (IDS-G(-pre)) must follow the architecture and not vice versa.

And I would welcome short term alignments on these topics as well as be happy to support this.

It is aligned.