Separation of Control and Data Plane

[HeinrichPet]

The separation of Control and Data Plane must be implemented in RAM 4.0. So the exchange of Identity, Policies, Metadata etc. will done in the Control Plane whereas the raw data will be transfered via the Data Plane. Both Planes can use different transfer protocols.
First discussion can be found here: https://github.com/International-Data-Spaces-Association/IDS-G-pre/issues/60

[HeinrichPet]

Addition: We then have to think about Data Transfer Protocol Negotiation (REST, IDSCP, Wireguard, ....)

[mokamhuber]

good point. For IDSCP2 we differentiated this as transport layer and application layer

[HeinrichPet]

@mohuber I'm not sure we mean the same thing....

My point is that the connector do the handshake, identity verification, policy negotiation, etc. and for the data exchange, a completely different infrastructure is responsible. So for example the data exchange is done directly via Kafka cluster, cloud events, blob storage transfer, etc.
See also this EDC comment and the whole discussion there: eclipse-edc/Connector#51 (comment)

So to clearify that, it results not only in different transfer protocols (which is important for the process layer) but may also result in different infrastructure (which is important for certification) and in a adapted UC concept (@Brandstaedter ).

[gbrost]

Totally agree.
@milux Please keep this issue in mind and contribute your concepts from PMD.
One challenge will be to match this to certification (handling of private keys to access data etc). E.g., if we exchange wireguard keys, how are these protected, etc.

[juliapampus]

@gbrost @HeinrichPet This discussion here is becoming technology-specific. Does this still belong to RAM or rather to IDS-G-pre?

[juliapampus]

I'm asking because otherwise I'll attach my work on the Data Exchange Chapter to this issue. However, with a PR, this will be closed. If you want to discuss it further, it should probably be moved to the IDS-G-pre.

[HeinrichPet]

For me its fine to attach this ticket to a PR. Even if it is closed, it is not lost.

[gbrost]

Yes, we should not dive into technological debates here. But we need to address the topic if upgrading / changing the data exchange channel is possible and if and how this will affect certification. Can we re-open this after the PR is finished?

[gboege]

We from FIWARE are heavily in HTTP/S data exchange. We handle streams of data that do not recommend contract negotiations before each individual data exchange. Token with expiry dates help for defined periods of times together with caching. Maybe, a similar process like obtaining refresh token might help ("just" asking whether the contract situation is still OK or not)