feat: contract termination

profiling/README.md

@@ -1,18 +1,17 @@
 # Best Practices on Profiling the Dataspace Protocol
 
-The [Dataspace Protocol](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/) defines a set of adaption 
+The [Dataspace Protocol](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/) (DSP) defines a set of adaption 
 points. They are left initially ambiguous to guarantee agnosticity and extensibility. 
 This document describes how to further specify those extension
 points for end-to-end interoperability. It suggests three different types of profiles:
-- **Policy Profiles**
-- **Authentication Profile**
-- **Data Transfer Profiles**
+- [Policy Profiles](./policy-profiles/README.md)
+- [Authentication Profile](./authentication-profiles/README.md)
+- [Data Transfer Profiles](./data-transfer-profiles/README.md)
 
 ## Status of this document
 
 The Best Practices are created and published by the [Eclipse Dataspace Working Group](https://dataspace.eclipse.org/).
-They are applicable only to the release candidates for version `2025-1`. Extension mechanisms for earlier versions may
-vary.
+They apply only to the release candidates for version `2025-1` and to all subsequent versions. Extension mechanisms for earlier versions may vary.
 
 ## General remarks
 

profiling/policy-profiles/README.md

@@ -1,8 +1,8 @@
-# Policy Profile
+# Policy Profiles
 
-## Policies
+## Custom Constraints
 
-The Dataspace Protocol `Offer` is a JSON object reusing properties from the Open Digital Rights Language (ODRL).
+The Dataspace Protocol (DSP) `Offer` is a JSON object reusing properties from the Open Digital Rights Language (ODRL).
 `Offer`s contain `Constraint`s that signify a boolean operation: They consist of three components
 - `leftOperand`: This is (by definition in the JSON-LD context) a IRI that must either be fully qualified in the payload
   or implicitly namespaced by an additional entry in the `@context` object.
@@ -16,4 +16,183 @@ These conventions are codified in **Credential-Constraint-Profiles**. Such a pro
 1. a set of terms that are valid for `leftOperand`, `operator` and `rightOperand` in the context of the profile.
    Together they constitute the set of supported `Constraints`.
 2. validation mechanisms for each `Constraint` and the required side-effects to execute the specified mechanism. This
-   may include inspecting an authorization token or querying a remote service.
+   may include inspecting an authorization token or querying a remote service.
+
+## Contract Termination
+
+There are multiple scenarios why a contract may be terminated or implicitly terminated. In practice, creating an agreement, amendment, termination, or similar produces new documents that are added to the contract process, business relationship, purchasing process, etc. The DSP can be used for technically representing contract-related processes such as termination.
+
+---
+
+**Note:** The scope of DSP is to define technical processes for _policies_, not legally binding implications that _contracts_ have.
+
+- **Business perspective (Contracts):** The business ambitions are to comply with legal requirements. Before sharing data, two parties must agree on data sharing conditions (costs, usage conditions, etc.) in form of a _contract_, and both parties can express their willingness to terminate a contract at any time.
+- **Technical perspective (Policies):** Focusing on the policy part, the DSP contains a technical specification for creating _policies_ (policy agreements), along with creating requests, offers, and negotiating these. The policy agreement forms the basis for policy enforcement (access control, compliance checks, etc.) during data handling (transfer, usage, etc.).
+
+The mapping of technical processes (policies) and their legal implications (contracts) is done by the [Dataspace](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1/#dfn-dataspace).
+
+_For example, the Catena-X association specifies that a policy agreement has legally binding effects. This is implemented by the association agreeing on generally applicable contract clauses and linking these to ODRL rules and constraints. See <https://github.com/catenax-eV/cx-odrl-profile> for reference._
+
+---
+
+As with legal processes, the recommendation is to create a new [Agreement](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1/#dfn-agreement) wherever a new paper document is / would be produced. With this, we aim for a _record of contractual transactions_ for one [Dataset](https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1/#dfn-dataset).
+
+### Provider-initiated contract termination
+
+The technical representation implies a change of the subject of the created Agreement, from permission/obligation to prohibition. Thus, a new Agreement referring to the same Dataset must be negotiated.
+
+#### Example
+
+An Agreement has been negotiated between two dataspace members. The provider wants to stop the use of a specific Dataset. The provider has to actively terminate the contract and data access will no longer be granted.
+
+#### Approach
+
+The negotiation takes place according to the DSP Negotiation Protocol.
+
+1. The Provider sends a `ContractOfferMessage`.
+    - The `prohibition` must target every `action` that has been negotiated before. For example, one prohibition `use` terminates a list of permissions and obligations of type `use`. A prohibition `distribute` terminates the rules of type `distribute` but not every of type or subtype of `use`.
+    - The `target` refers to the original Dataset ID.
+    - The `constraint` refers to the Agreement that is replaced/terminated, in case there are multiple Agreements for the same Dataset.
+
+ ```json
+ {
+   "@type": "ContractOfferMessage",
+   ...
+   "offer": {
+     "@type": "Offer",
+     "@id": "urn:uuid:d526561f-528e-4d5a-ae12-9a9dd9b7a518",
+     "target": "someAssetId",
+     "prohibition": [
+       {
+         "action": "use",
+         "constraint": [
+           {
+             "leftOperand": "dspace:agreement",
+             "operand": "eq",
+             "rightOperand": "someAgreementId"
+           }
+         ]
+       }
+     ]
+   },
+   "callbackAddress": "https://example.com/callback"
+ }
+ ```
+
+2. The Consumer sends a `ContractNegotiationEventMessage`.
+
+ ```json
+ {
+   "@type": "ContractNegotiationEventMessage",
+   ...
+   "eventType": "ACCEPTED"
+ }
+ ```
+
+3. The Provider sends a `ContractAgreementMessage`.
+
+ ```json
+ {
+   "@type": "ContractAgreementMessage",
+   ...
+   "agreement": {
+     "@id": "urn:uuid:e8dc8655-44c2-46ef-b701-4cffdc2faa44",
+     "@type": "Agreement",
+     "target": "assetId",
+     ...
+     "prohibition": [
+       {
+         "action": "use",
+         "constraint": [
+           {
+             "leftOperand": "dspace:agreement",
+             "operand": "eq",
+             "rightOperand": "someAgreementId"
+           }
+         ]
+       }
+     ]
+   }
+ }
+ ```
+
+4. The Consumer sends a `ContractAgreementVerificationMessage`.
+5. The Provider sends a `ContractNegotiationEventMessage`.
+
+### Consumer-initiated termination
+
+The technical representation implies a change of the subject of the created Agreement, from permission/obligation to prohibition. Thus, a new Agreement referring to the same Dataset must be negotiated.
+
+#### Example
+
+An Agreement has been negotiated between two dataspace members. The consumer has confirmed a purchase that they wish to cancel. The consumer has to actively terminate the contract and data access will no longer be granted.
+
+#### Approach
+
+The flow takes place according to the DSP Negotiation Protocol.
+
+1. The Consumer sends a `ContractRequestMessage`.
+    - The `prohibition` must target every `action` that has been negotiated before. For example, one prohibition `use` terminates a list of permissions and obligations of type `use`. A prohibition `distribute` terminates the rules of type `distribute` but not every of type or subtype `use`.
+    - The `target` refers to the original Dataset ID.
+    - The `constraint` refers to the Agreement that is replaced/terminated, in case there are multiple Agreements for the same Dataset.
+
+ ```json
+ {
+   "@type": "ContractRequestMessage",
+   ...
+   "offer": {
+     "@type": "Offer",
+     "@id": "urn:uuid:2828282:3dd1add8-4d2d-569e-d634-8394a8836a89",
+     "target": "assetId",
+     "prohibition": [
+       {
+         "action": "use",
+         "constraint": [
+           {
+             "leftOperand": "dspace:agreement",
+             "operand": "eq",
+             "rightOperand": "someAgreementId"
+           }
+         ]
+       }
+     ]
+   },
+   "callbackAddress": "https://example.com/callback"
+ }
+ ```
+
+2. The Provider sends a `ContractAgreementMessage`.
+
+ ```json
+ {
+   "@type": "ContractAgreementMessage",
+   ...
+   "agreement": {
+     "@id": "urn:uuid:e8dc8655-44c2-46ef-b701-4cffdc2faa44",
+     "@type": "Agreement",
+     "target": "assetId",
+     ...
+     "prohibition": [
+       {
+         "action": "use",
+         "constraint": [
+           {
+             "leftOperand": "dspace:agreement",
+             "operand": "eq",
+             "rightOperand": "someAgreementId"
+           }
+         ]
+       }
+     ]
+   }
+ }
+ ```
+
+3. The Consumer sends a `ContractAgreementVerificationMessage`.
+4. The Provider sends a `ContractNegotiationEventMessage`.
+
+### Further considerations
+
+1. The technical representation of this process is equivalent to a "termination agreement". In practice, a termination of a contract results in no running contractual conditions. Technically, with the above-mentioned approaches, the termination of a contract agreement results in a new, valid one. The legal implications of the DSP process must be specified by the dataspace.
+2. A connector could implement a lifecycle management for Agreements and/or Datasets by linking multiple Agreements and creating a history (e.g., in form of a list).
+3. The Agreement classified as contractual termination should not be actually negotiated. The legal implications of the DSP process must be specified by the dataspace. This specification of legal implications should answer questions like: What happens when a Consumer and/or Provider does not technically agree to the termination request, is the Agreement then still active? What happens when the termination request gets technically rejected?