Contract Agreement Lifecycle

[saschaisele-zf]

Contract Agreement Lifecycle

Problem

There is currently no way to mark a Contract Agreement for archivation or deletion.

Goal of this discussion

The goal of this discussion is to find a mechanism that enables the user to either automatically or manually mark a Contract Agreement as obsolete and archive/delete it afterwards.

Use-Cases involving this topic

Asset cleanup

Over time, the Connector Database will bloat, since there are no ways to delete an Asset that is referenced by a Contract Agreement.
While storage is cheap nowadays, it will still inevitably impact performance over time and generate additional costs.
This problem is exacerbated by the fact that automated contract negotiation by a large number of participants might lead to an undeleteable Asset table containing millions of entries.

Connector decommissioning

Once a connector is at the end of its lifecycle, a proper decommissioning needs to take place.
Since Contract Agreements symbolize legally binding contracts, they either need to be exported to other connectors for continuation of service, or archived until the mandatory retention period has passed, and they can be safely deleted.
This differentiation is currently very hard, if not impossible due having to manually check every possible Contract Agreement to determine its status.

Diagram showing the relationship and states of entities

This diagram was jointly created by @stefan-ettl @yurimssilva @ndr-brt @alexandrudanciu @rafaelmag110 and @saschaisele-zf .

Diagram


Possible solution proposals

Define a default duration for Contract Agreements that marks them as obsolete after expiry and is overwritten by the edc:inForceDate Policy contained in the Contract Agreement.

In the same vein, the edc:inForceDate Policycould be made mandatory and thereby manage the Contract Agreement lifecycle.

[florianrusch-zf]

Please also consider, that the solution needs to work for all dataplane implementations. So for http, S3, Azure Blob and what else is out there in the world 😉

[arnoweiss]

Another use-case could be canceling a contract. A Provider may have a legitimate interest to end a contract previously agreed with a Consumer. The exact end date will not be known at negotiation-time. If it were, it could be encoded in the a policy. There's a discussion to be had

1. if a provider should be able to cancel the contract at any time
2. how long in advance the cancelation would be communicated
3. how the consumer would be notified

Cancelation is especially relevant in scenarios with continuous data flow like HTTP-pull (with ever-renewing EDR-Tokens) or pubsub. This topic could be relevant for interop and should sometime in the future be handled on the protocol-level. But there should perhaps be an implementation-level solution first.