Contract Definition Unlisting

[wolf4ood]

Hi Folks I wanted to share ideas and get feedback on how to achieve contract definition unlisting within the EDC

As Dataspace participant acting as data provider, I may want to unlist/remove Contract Definition being offered without affecting the previously made contract agreements.

Currently a contract definition can be deleted via DataManagement APIs with:

DEL|{context_path}/contractdefinitions/{id}

and it's permanently deleted from the underlying ContractDefinitionStore implementation without checking if contract agreements based on the deleting contract definition are in place. see here.

The implications of this current behavior is:

• contract negotiation requests based on the deleted definition will fail, which is expected.

• transfer requests of assets in a contract agreement based on the deleted definition will fail, which is not expected.

Taken for granted (not yet implemented) that I cannot delete a contract definition if there are contract agreements based on that, how can we support definitions unlisting ?

I've identified a couple of options:

Option 1

An idea could be to introduce a state in the contract definition model, which tracks if the it's currently being offered or not. This will allow data providers to still serve the previously made contract agreements to consumers and prevent future contract negotiation based on the unlisted contract definition. The states are not defined yet but they could be something like:

• Created
• Published
• NotAvailable

Then we could provide a change of state via DataManagement APIs:

PUT|{context_path}/contractdefinitions/{id}/{action}

At this point we could use that state for driving filters where needed. For example if you start a contract negotiation based on
that contract definition that it's not listed, the negotiation will fail, while the transfer process will succeed.

I would still leave the option to delete contract definition not yet used in agreements (e.g. bad configuration).

Option 2

Another option to achieved this could be writing a custom functions on policy engine that operates in the contract.cataloging scope, that checks if the contract definition can still be offered by asking to an external system. This maybe be more flexible since it's custom made but it could require some extra work and it could affect the performance when evaluating the access policy on the ContractDefinition.

Let me know if you have other opinions or feedback on this.

Cheers
Enrico

[paullatzelsperger]

Having the state directly on the ContractDefinition would also make it much easier exposing it through the DataManagementApi, because it's "already there", whereas with option 2 we'd have to query the external system in order to compose the ContractDefinitionResponseDto which might introduce some unwanted latency.

Just one comment: the method to change the state should be a PUT, since we're updating, not creating.

[ndr-brt]

I have a question, why do we need the contract definition once the agreement is settled?
At that point the Contract Agreement should contain everything's needed: the asset reference and the complete policy.
In my opinion the Contract Agreement doesn't need to be bound with the Contract Definition

[paullatzelsperger]

had the same thought. Actually, the validation of the definition is performed when validating the agreement (see here), but it doesn't look like anything is done with the contractDefinition variable afterwards.

[wolf4ood]

Yeah it seemed strange when i tried that did that check, not sure if we need that on agreement validation.

[ndr-brt]

thinking at it, the definition is something we need to reach the agreement, but at the end the agreement should contain everything's needed for its validation (asset reference, policy, dates, eventual signature...).
I'd propose to remove that check and to not check for agreements existence when deleting definitions.

[wolf4ood]

I will formalize this in a DR so we can remove the check on ContractDefinition when validating the agreement