[Open Planning R24.12] Brainstorming Features

[lgblaumeiser]

This Discussion should be a placeholder to create a Brainstorming List of Features to be addressed in the 24.12 Release for the TractusX-EDC.

In order to contribute your idea or request, please copy the following table and add your content accordingly.
Please take care of a consecutive number in regards to your predecessor post.

Number	Title	Description
x	Your great feature proposal title	An even greater description of your awesome feature proposal. Please state whether it is a concept, an implementation, or ... and add dependencies if there are.

[lgblaumeiser]

Number	Requestor	Title	Description
1	Florian Rusch	Big-Data transfers should not go through the EDC (S3, Azure Blob)	E.g. if two participants want to share TB or even PB of data via S3 this data will be streamed through the EDC which also means on the underlaying infrastructure the network traffic is increasing by TB or event PB. This can also lead to high costs for the corresponding (cloud) infrastructure providers. Possible solution: Find a way of copying the Data as near as possible to the source/destinations (e.g. within the AWS infrastructure)
2	Florian Rusch	Horizontal Scalability	I’m not sure if this already supported or not because of the state machines. To handle a lot of requests and data transfers and to guarantee high availability also while updating the pod we need the possibility to have multiple instances of control- and dataplane be running at the same time.
3	Florian Rusch	Faster Startup	We have the requirement to start the EDC as fast as possible to fulfill our internal requirements. With the following resource specs, the EDC needs around 40-50 seconds to start, and we don’t want to give him more Cores because most of the time he is idling around which would be then a waste of resources: CPU: 1 Core (AMD EPYC 7763), RAM: 3 GB.
4	Florian Rusch	Stable Management API	In the past almost with each version (also patch versions) breaking API changes were introduced in the EDC. This hurts a lot and creates a lot of efforts while adopting patched or new versions of the EDC into the Use-Cases of Catena-X as also for EDC as a Service providers and companies that need to link/integrate the EDC with 3th party software. Therefore breaking change should be handled correctly with semantic versioning.

[jimmarino]

@florianrusch-zf 40-50 seconds? Wow, that is a lot. Please take a look at your distribution configuration. Is it making many remote calls? EDC is designed to (and does) boot in milliseconds. This was an explicit design goal with the runtime boot subsystem - that's one of the reasons why it does not use classpath scanning or complex DI frameworks.

My guess is the issue is with remote startup calls.

[rafaelmag110]

Number	Title	Description
5	Terminate or Update contract agreements	Probably a controversial one. As it stands, once a contract agreement is celebrated between two connectors there is no way to terminate it, other than waiting for the termination conditions defined in the underlying contract policy to be reached. There are cases where the cancellation or update of a contract agreement might be valid, i.e. as CatenaX use cases evolve the respective frame contracts also do, and legally speaking the old contracts are no longer valid after the new version is released. Technically, there is no way to enable the business to cancel the old version of the contract of even update it.

[SebastianOpriel]

Hi @rafaelmag110, I had some time ago a discussion with @jimmarino about this matter in DSP discussion round, with the remark, that this is not intended to be introduced to DSP (maybe this opinion might have change). Nevertheless, we are currently finalizing exactly a "Terminate Contract" feature, in context of Mobility Data Space, which will available in our Open Source EDC repo about end of this month. We would be happy to contribute this to Tractus-X EDC or Core EDC.

[jimmarino]

That's not quite accurate. The discussions we had were about legal semantics and not tying this to the contract negotiation state machine. I said a few things:

1. We should not define the meaning of a contract as "termination," and we should probably not use that term to avoid any implication as to its meaning.
2. This feature should not be part of the contract negotiation process (i.e. ,state machine) as contract agreements are distinct and CN state machines should reach a terminal state by either producing a contract agreement or a termination/error message.
3. Because of point 2, this would involve significant additions to the DSP and at the time we should not look into it as we were preparing the specifications for submission to Eclipse.

Rather than a one-off, I think we need to look at this holistically, which should be done at the DSP and EDC levels, not in Tractus-X. First, introduce an upstream management API feature that allows one party to sunset a contract agreement without notifying the counterparty. This solves the immediate need.

Second, work in the DSP specification committee to define a generic technical lifecycle and event mechanism for contract agreements that does not imply business semantics. This mechanism can be used to handle other issues, such as key rotation for signatures, etc. This is a significant amount of work and I do not think it should be implemented in EDC prior to the specification committee looking at it.

[lgblaumeiser]

This feature was raised recently from the Data Sovereignity task force of the association. Actually, there is an open legal question. Can a contract be terminated from one side only. The discussed technical solution, you, @jimmarino, are referring to, would be a fast solution, but could be legally difficult. Imho, terminating contracts should be a feature of the DSP. We could provide the provider side termination as a clean up feature, i.e., official termination is handled outside of the DSP protocol, the termination in the connector is then simply a technical means to implement the external contract negotiation. Then, also the fact, that the consumer is not informed is a no-issue as he already knows about the termination.

The correct usage of the provider side termination has to be ensured by process, though, as the connector has no possibility to validate the correct usage of the termination mechanism.

[jimmarino]

I agree that this should be addressed by a standard. My thinking is DSP should provide a generic contract agreement eventing system but not define contract termination because that is a legal issue. Each dataspace would then define an overlay using the eventing system to match their business requirements. That could be a contract "invalidation" event or even an explicit "termination notification" with associated legal semantics. The key distinction here is that DSP does not define the event semantics and leaves this open for each dataspace.

It's important to note this eventing mechanism is not part of the contract negotiation protocol. Once a contract agreement is produced, the CN is in a terminal state and is essentially "read-only." The eventing protocol happens outside of that.

This work should be handled by the DSP specification group. Otherwise, it will lead to a breaking change in Catena-X and could significantly diverge from what the specification group ultimately decides.

Also, good points about having this handled by an outside process. Using the "simple" management API solution, the data sovereignty task force can define a set of procedures (non-code) that are executed outside of the technical infrastructure to handle this.

[rafaelmag110]

Number	Title	Description
6	Oauth authentication as an option to Api-keys for DMA access	Usually companies have their own IAM setup which they attach to their internal platforms to enable authorization/authentication. They are usually OAuth based, and from knowledge the EDC already supports OAuth. Now, TractusX-EDC could enable a quick integration with such an authentication systems to manage access to DMA instead of using the existing api key option. The solution could even enable the option to configure one or multiple roles that are able to successfully request the DMA.

[SebastianOpriel]

Hi @rafaelmag110, We have implemented such a solution for us. We are currently in discussions, if this could be made OS - might take a bit. I also talked with others in Catena-X if we would like to team up, to come up with a more sophisticated solution (proper roles/rights management in EDC), i.e. e.g. a contract negotiated by company-internal system A (via a unique service account) shall not be deletable by system B. I would be happy to be kept in loop with regards to that feature request.

[paullatzelsperger]

don't know if you are aware, but there is now a feature in EDC called "delegated auth", that allows using a third-party IdP for access control. In that scenario, the Management API ingress takes an access token instead of an API key.

here is the upstream issue: eclipse-edc/Connector#4261
here is the sig-release issue: eclipse-tractusx/sig-release#616

[rafaelmag110]

@SebastianOpriel Thanks for the info. I'll try to keep you in the loop.

@paullatzelsperger I wasn't aware of this new feature. I'll have a look and try it out. Thanks!

[lgblaumeiser]

Duplicate to eclipse-tractusx/sig-release#707

No planning feature created!

[lgblaumeiser]

Please be aware, that I will close the issue tomorrow morning, as the feature proposal phase ends Friday, 09:00.