chore: update Section 3.3.3 Contract Negotiation

International-Data-Spaces-Association / IDS-RAM_4_0

Focusing on the generalization of concepts, functionality, and overall processes involved in the creation of a secure 'network of trusted data' , the IDS-RAM resides at a higher abstraction level than common architecture models of concrete software solutions do. The document provides an overview and dedicated architecture specifications.

Creative Commons Attribution 4.0 International

38 stars 27 forks source link

chore: update Section 3.3.3 Contract Negotiation #111

Closed juliapampus closed 2 years ago

kragall commented 2 years ago

I checked the role of the Clearing House in the Contract Negotiation process and there's one issue I have with the description. The Clearing House does not support revocation of information that has been stored. As such, I would prefer that the Clearing House is only called, once the contract is validated and both parties are sure that the contract will not be revoked.

My current understanding is that once data is in the Clearing House, it may not be modified and both parties trust the Clearing House to store the data "immutable". As a result, once the contract agreement has been created mutually by Provider and Consumer neither party should be able to modify the agreement.

If we allow modification (including revocation) of data in the Clearing House we need to ensure that these modifications have been mutually agreed upon so that later, in case of disagreement, neither party can claim that the modifications were made without their consent

juliapampus commented 2 years ago

Thanks for your feedback @kragall! I understand your points, also with regards to @sebbader comments, I will modify some messages. Nevertheless, I have some questions:

As such, I would prefer that the Clearing House is only called, once the contract is validated and both parties are sure that the contract will not be revoked.

This would be a perfect flow, but we should also consider edge cases. What happens if an agreement gets revoked? How is this done technically if not by some kind of revocation? With this I don't mean the deletion (this cannot happen if it is persisted immutable) but some other process. Do we need some kind of contract revokation process for this?

created mutually by Provider and Consumer

Does this mean that both parties have to send the agreement to the clearing house to mark it as "active"?

If we allow modification (including revocation) of data in the Clearing House we need to ensure that these modifications have been mutually agreed upon so that later, in case of disagreement, neither party can claim that the modifications were made without their consent

Fits my first question. This means we need some kind of contract renewal (basically a new contract negotiation) but also contract revokation process, right?

kragall commented 2 years ago

This would be a perfect flow, but we should also consider edge cases. What happens if an agreement gets revoked? How is this done technically if not by some kind of revocation? With this I don't mean the deletion (this cannot happen if it is persisted immutable) but some other process. Do we need some kind of contract revokation process for this?

Yes, I do think we need some process for updating and revoking contract agreements. And similar to the original contract agreement process, it must be clear from the logs that both parties agreed to the same contract.

Does this mean that both parties have to send the agreement to the clearing house to mark it as "active"?

This depends on how the process works. If there is no point-of-return (i.e. both parties already agreed and we only document this fact) once the agreement has been sent to the Clearing House, then it should suffice if only one party sends the agreement to the Clearing House. If it is possible that the agreement is revoked even after it has been sent to the Clearing House then it's probably better to have both parties send the agreement.

juliapampus commented 2 years ago

This depends on how the process works. If there is no point-of-return (i.e. both parties already agreed and we only document this fact) once the agreement has been sent to the Clearing House, then it should suffice if only one party sends the agreement to the Clearing House.

I am not sure who initally created the sequence, so I need some feedback here. Does a Clearing House need the Contract Agreement from both participants or is the Provider sufficient? Maybe more from a legal perspective? @sebbader @Brandstaedter @HeinrichPet

hosseinzadeha commented 2 years ago

I am not sure who initally created the sequence, so I need some feedback here. Does a Clearing House need the Contract Agreement from both participants or is the Provider sufficient? Maybe more from a legal perspective? @sebbader @Brandstaedter @HeinrichPet

Policy Negotiation (AP6) We assumed that the Data Provider compares the latest received Request with the latest Offer and when they are identical, creates a Contract Agreement accordingly and sends it to the Data Consumer. The Data Consumer then sends the Contract Agreement back to "acknowledge". Supposedly, here the negotiation process is successfully over and the Data Provider can send the Agreement to the Clearing House.

juliapampus commented 2 years ago

Updated the sequences according to our discussion two weeks ago.

hosseinzadeha commented 2 years ago

Updated the sequences according to our discussion two weeks ago.

@juliapampus I checked the diagrams again. From the Contract language point of view, we have "Offer", "Request" and "Agreement". A Data Consumer always send a Request (to start a negotiation process as well as to proceed with the process). That is how it is defined in the deliverables of AP6, T14 and the IDS Usage Control document. Also, ODRL defines an Offer policy as follows: An ODRL Policy of subclass Offer represents Rules that are being offered from assigner Parties. An Offer policy only has assigner property but no assignee .

juliapampus commented 2 years ago

Updated the sequences according to our discussion two weeks ago.

@juliapampus I checked the diagrams again. From the Contract language point of view, we have "Offer", "Request" and "Agreement". A Data Consumer always send a Request (to start a negotiation process as well as to proceed with the process). That is how it is defined in the deliverables of AP6, T14 and the IDS Usage Control document. Also, ODRL defines an Offer policy as follows: An ODRL Policy of subclass Offer represents Rules that are being offered from assigner Parties. An Offer policy only has assigner property but no assignee .

@hosseinzadeha Could you please refine your review? Maybe by referring to specific lines.

Do you want me to update the terms? Do you think the sequence we aligned on will not work according to ordl syntax? Do you say a provider should never start the negotiation?