Enriching the contract offering/negotiation process with additional properties

[juliapampus]

Feature Request

Investigate whether it is possible to include custom properties in the Policy and Contract or Negotiation objects.

Which Areas Would Be Affected?

policy, negotiation

Why Is the Feature Desired?

The contracting process could be enhanced in two ways: (1) involve a human user, (2) increase the level of security.

(1) covers:

• Allowing manual state changes in the state machine for contract negotiations, add the support of counter offers
• Translating machine-processable ODRL (EDC) policies to human-readable (and legal binding) contract content

(2) covers:

• Signing the exchanged contracts (offers/agreements)
• Immutable and audited storage of contract objects

Solution Proposal

As both point either need to be addresses outside the EDC core, or affect the core architecture and therefore require a lot of conceptualization and implementation, a quick soluting could provide the following improvements:

• (1) Add a reference to the human-readable version of a contract/policy to the policy, e.g. called document, legalText. Enhance the IDS transformers to include this information when mapping EDC policies to IDS contracts.
• (2) Provide a hash of the exchanged contract objects within the negotiation process. (Evaluation would not be covered by the EDC in a first step.)

Open questions:

• Does it make sense to add the reference to the policy? Is it mapped to the data protocol (IDS)?
• Where to place the hash information (in the EDC model and in IDS)?

Checklist

• assigned appropriate label?
• Do NOT select a milestone or an assignee!

[juliapampus]

(1) The Policy class provides Map<String, Object> extensibleProperties. The ContractOfferToIdsContractOfferTransformer, ContractAgreementRequestToIdsContractAgreementTransformer, IdsContractAgreementToContractAgreementTransformer, IdsContractOfferToContractOfferTransformer and IdsContractRequestToContractOfferTransformer are missing a mapping from/to the IDS objects' attribute properties.

[juliapampus]

(2) We came to the conclusion that simply adding a hash as a contract objects' attribute during the negotiation would not bring any benefits. The process would have to be modified in general.

We came across multiple problems why this is not an easy solution:

• A hash value cannot be placed in the negotiation object because this is never exchanged by both connectors.
• During the negotiation, not both connectors send an agreement.
• The contract agreement is built automatically, so no attributes could be inserted from external. A usage would only make sense for static attributes, not dynamic.
• Having a connector sending the hash value as attribute of a contract object during the negotiation cannot prevent that the other connector manipulates this object and recalculates the hash value.

Any approach could have two different purposes:

• Tamper protection: A hash of exchanged objects allows the receiving participant to validate the received content against the hash and therefore make sure that this was not modified during communication.
• Authenticity and guarantee of origin: Signing the negotiated objects (contracts) ensures that the negotiating connectors have the authority to do so and adhere to each other's terms.

And must consider any way of attacking the negotiation process (assuming that the EDC is modified and used in a malicious way):

1. The provider manipulates the agreement before sending it to the consumer.
   • The consumer can validate against the last sent contract offer and send a rejection.
2. The provider manipulates the agreement after sending it to the consumer.
   • The consumer only notices this when he requests the data.
   • Technically not avoidable without a third-party service.
3. The consumer manipulates the agreement on its side
   • The content will be modified to, e.g., express that data will be retrieved for less money or beyond the agreed period of time. --> No benefit as the provider has the correct agreement and denies access to the data.
   • When the permissions are about data processing or transfer to third parties or similar, i.e. usage control or access control after data retrieval, the provider will never know. --> legal mechanisms apply

Motivation:

• The consumer should be able to prove the authenticity of the contract offers and agreements at a later date.
• In the event of a dispute, the consumer must be able to prove that the contract offer was actually created by a specific provider.
• Authenticity can be proven because the provider encrypts the contract with its private key and the consumer can decrypt the content with the provider's public key.
• The fact that the provider has the apparently correct version of the contract offer/agreement does not help in court. Only if the consumer has signed digitally, the provider can refer to its version.

[github-actions[bot]]

This issue is stale because it has been open for 28 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.