EDC - Terminate or Update contract agreements

[lgblaumeiser]

Requestor: @rafaelmag110

Description

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.

Impact

No impact outside of the communication of EDCs.

Additional information

• [ ] I'm willing to contribute to this feature

[lgblaumeiser]

Transfered Comment from @SebastianOpriel 1392

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.

[lgblaumeiser]

Transfered Comment from @jimmarino 1392

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:

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. 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. 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]

Transfered Comment from @lgblaumeiser 1392

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]

Reposting here because we seem to have duplicate discussions:

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]

@jimmarino would you see any possibility that this contract agreement eventing system could enable the auditing of physical contract amends? I'm thinking about the case where a user wants to "terminate" an existing contract agreement because the terms have been updated and the associated policy isn't a correct representation of the actual terms anymore. Could this system enable the user to inspect the trail of changes made a contract leading up to the most up to date one?

[jimmarino]

Short answer: I would not model it that way. Contract Agreements are immutable. I think the correct approach would be to negotiate a new contract agreement, which serves either as a replacement or as an amendment. Real contracts are essentially immutable append-only documents as well.

The eventing system could serve as a notification that a new contract supersedes an old one, however.

[stephanbcbauer]

Presented in the DRAFT Feature Freeze -> Committer is available

[lgblaumeiser]

Task:

• Terminate the contract on provider side, no interaction between consumer and provider out of the existing communication paths. Termination will lead to disabling data transfers.
• Will be solved in Tractus-X first