Skip to main content

4.2.1.1

Sharing agreement: Negotiation - Negotiating sharing agreement

Test: Test completeness: Two connectors can negotiate a data sharing agreement that supports a defined minimal state machine (the definition of the minimal state machine must be agreed beforehand).

note

The description of Test 4.2.1.1 was extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.

Information​

  • Phase 1

  • Minimal? Yes

  • Related KPIs:

    • Interoperability: The system provides components that negotiate a data sharing agreement through a common protocol. The data sharing protocol implements requests, responses, and states that produce an iterative data sharing negotiation which is semantically interpretable by an observer.

  • Evaluation Criteria:

The test assigns a numeric score based on the assessment, using the Functional Suitability metric from iso27001_kpis_subkpis.xlsx.

CriteriaScoring
No Coverage: The solution fails to implement any negotiation flow for the data sharing agreement based on the defined minimal state machine.0
Minimal Coverage: The solution meets up to 25% of the technical requirements. This might include only a basic framework for the negotiation flow, with a significant part of the defined minimal state machine not implemented.1
Partial Coverage: The solution satisfies approximately 50% of the technical requirements. This could involve a partially implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with several key elements missing or incomplete.2
Significant Coverage: The solution covers about 80% of the technical requirements. This includes a well-implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with only minor elements or details that may still need refinement.3
Full Coverage: The solution fully meets all technical requirements. This includes a fully implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with all elements thoroughly addressed and tested.4

Results​

note

The results for Test 4.2.1.1 for EDC+VC were extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.

Environment​

  • The test utilizes the EDC MVD commit 5d58b38.
  • The test is executed in an Ubuntu environment using IntelliJ.

Tested quality metric and method​

The quality metric for this test is based on the criteria outlined in iso27001_kpis_subkpis.xlsx. In Phase 1, the focus is on the Functional Suitability metric. For detailed information, please refer to the Comparative criteria (checklists, ...) section in the test description.

Expected output​

The test aims to assess the state machine implementation of the EDC ecosystem regarding the sharing negotiation.

Results​

Assessment​

The states of contract negotiation are possible with the following states, the states in bold are covered by Data Space Protocol State Machine.

  • REQUESTED: A contract for a Dataset has been requested by the Consumer based on an Offer and the Provider has sent an ACK response.
  • PENDING: A contract negotiation is on hold on one of the parties, might wait for external approvals.
  • OFFERED: The Provider has sent an Offer to the Consumer and the Consumer has sent an ACK response.
  • ACCEPTED: The Consumer has accepted the latest Offer and the Provider has sent an ACK response.
  • AGREED: The Provider has accepted the latest Offer, sent an Agreement to the Consumer, and the Consumer has sent an ACK response.
  • VERIFIED: The Consumer has sent an Agreement verification to the Provider and the Provider has sent an ACK response.
  • FINALIZED: The Provider has sent a finalization message including his own Agreement verification to the Consumer and the Consumer has sent an ACK response. Data is now available to the Consumer.
  • TERMINATED: The Provider or Consumer has placed the CN in a terminated state. A termination message has been sent by either of the Participants and the other has sent an ACK response. This is a terminal state.
  • COUNTER_PROPOSAL: The contract negotiation is on hold on the provider side waiting for a COUNTER_PROPOSAL from the consumer party.
  • EXPIRED: The negotiation has expired due to a timeout or elapsed deadline without reaching an agreement.
  • REVOKED: One of the parties has revoked their offer or request before it could be accepted or rejected.
  • CANCELLED: The negotiation has been cancelled by mutual agreement of both parties.
EDC implementations​

As there is no TCK (Technology Compatibility Kit) has been published, there is no implementation can "conform" to DSP. However, there is a work in progress and EDC does intend to pass the TCK when it is available. Refer here.

EDC implements the following states in the ContractNegotiationStates

  • INITIAL(50)
  • REQUESTING(100)
  • REQUESTED(200)
  • OFFERING(300)
  • OFFERED(400)
  • ACCEPTING(700)
  • ACCEPTED(800)
  • AGREEING(825)
  • AGREED(850)
  • VERIFYING(1050)
  • VERIFIED(1100)
  • FINALIZING(1150)
  • FINALIZED(1200)
  • TERMINATING(1300)
  • TERMINATED(1400)

The state machine is here
edc-state-machine.png

EDC provides a documentation which details the mapping between existing EDC states, the corresponding new EDC states, and the IDS specification states, please refer to here.

The test runs a successful negotiation flow: for the consumer: initiated → requested → agreed → verified → finalized, for the provider: requested → agreed → verified → finalized.

  • This is for a successful negotiation; if not it will go from the current state to “terminated”
  • Other defined states(e.g. “offered” etc), these are currently not used, but they could be useful if there are other options than just accepting the provider contract as is (currently not implemented in EDC).
  • Policies are evaluated during the “requested” phase on the provider.
  • During ContractNegotiation, the negotiation has a different id on both provider and consumer

Logs for ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb on the consumer connector as follows:

DEBUG 2024-07-24T12:35:55.205642506 [ConsumerContractNegotiationManagerImpl] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state INITIAL
DEBUG 2024-07-24T12:35:55.470100382 [ConsumerContractNegotiationManagerImpl] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state REQUESTING
DEBUG 2024-07-24T12:35:55.470552694 ContractNegotiation: ID a1a32534-6c1d-4875-bd48-3b2cc41da8eb. [Consumer] send request
DEBUG 2024-07-24T12:35:55.816844368 ContractNegotiation: ID a1a32534-6c1d-4875-bd48-3b2cc41da8eb. [Consumer] send request
DEBUG 2024-07-24T12:35:55.816948427 [ConsumerContractNegotiationManagerImpl] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state REQUESTED
DEBUG 2024-07-24T12:35:56.503153685 DSP: Incoming ContractAgreementMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process: a1a32534-6c1d-4875-bd48-3b2cc41da8eb
DEBUG 2024-07-24T12:35:56.888602662 [CONSUMER] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state AGREED.
DEBUG 2024-07-24T12:35:57.549414156 [ConsumerContractNegotiationManagerImpl] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state VERIFYING
DEBUG 2024-07-24T12:35:57.549611466 ContractNegotiation: ID a1a32534-6c1d-4875-bd48-3b2cc41da8eb. [consumer] send verification
DEBUG 2024-07-24T12:35:57.838410104 ContractNegotiation: ID a1a32534-6c1d-4875-bd48-3b2cc41da8eb. [consumer] send verification
DEBUG 2024-07-24T12:35:57.838515447 [ConsumerContractNegotiationManagerImpl] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state VERIFIED
DEBUG 2024-07-24T12:35:58.533433993 DSP: Incoming ContractNegotiationEventMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process: a1a32534-6c1d-4875-bd48-3b2cc41da8eb
DEBUG 2024-07-24T12:35:58.72499179 [CONSUMER] ContractNegotiation a1a32534-6c1d-4875-bd48-3b2cc41da8eb is now in state FINALIZED.

The corresponding ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb logs in the provider connector are as follows:

DEBUG 2024-07-24T12:35:55.588913773 DSP: Incoming ContractRequestMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process
DEBUG 2024-07-24T12:35:55.75999992 [PROVIDER] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state REQUESTED.
DEBUG 2024-07-24T12:35:56.30306143 [ProviderContractNegotiationManagerImpl] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state AGREEING
DEBUG 2024-07-24T12:35:56.303415276 ContractNegotiation: ID c4dec03e-e21f-4103-b186-6a0e8447d1fb. [Provider] send agreement
DEBUG 2024-07-24T12:35:56.890075427 ContractNegotiation: ID c4dec03e-e21f-4103-b186-6a0e8447d1fb. [Provider] send agreement
DEBUG 2024-07-24T12:35:56.890262842 [ProviderContractNegotiationManagerImpl] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state AGREED
DEBUG 2024-07-24T12:35:57.622123397 DSP: Incoming ContractAgreementVerificationMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process: c4dec03e-e21f-4103-b186-6a0e8447d1fb
DEBUG 2024-07-24T12:35:57.837314656 [PROVIDER] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state VERIFIED.
DEBUG 2024-07-24T12:35:58.44331619 [ProviderContractNegotiationManagerImpl] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state FINALIZING
DEBUG 2024-07-24T12:35:58.443776224 ContractNegotiation: ID c4dec03e-e21f-4103-b186-6a0e8447d1fb. [Provider] send finalization
DEBUG 2024-07-24T12:35:58.726042394 ContractNegotiation: ID c4dec03e-e21f-4103-b186-6a0e8447d1fb. [Provider] send finalization
DEBUG 2024-07-24T12:35:58.726205646 [ProviderContractNegotiationManagerImpl] ContractNegotiation c4dec03e-e21f-4103-b186-6a0e8447d1fb is now in state FINALIZED
Extensibility of EDC implementations​

As we can see, EDC supports several states of a contract negotiation, there are still some states not covered, which could be required. e.g. a PENDING state. To extend the state flow, few options are available as follows:

  • Use State Transition Functions: State transition functions (StateTransitionFunction) can be registered at specific callback points which are responsible for transitioning the Contract Negotiation State Machine (CNSM) to a new state. These functions can be used to implement custom workflows. In runtime configurations that support it, transition functions will be called transactionally as part of the ContractNegotiationManager process loop. This will ensure state transitions are atomic. Scanning through the code taught it’s not yet implemented though commit 1ce468.
  • Use Event Subscriber: Depending on how the EventSubscriber is registered to the EventRouter (synchronous or asynchronous), in synchronous mode, the subscriber will block the main thread until the event is dispatched, allowing a 'PENDING' state to be added to the flow. To recover the flow, State Machine Specific Manager, specifically the AbstractContractNegotiationManager, runs in a loop and picks up the entity in a certain state, moving it to the next state when the PENDING tag is reset to false. The managers specific to the contract negotiation state are ProviderContractNegotiationManagerImpl and ConsumerContractNegotiationManagerImpl, both of which implement AbstractContractNegotiationManager.

Measured results​

EDC has implemented a state machine and offers an extensible ecosystem; however, these features are not fully available out of the box and may require additional configuration and development. Therefore, based on the criteria outlined in the Comparative criteria (checklists, ...) section of the test description, the test is assigned the following score:

Functional suitability quality metric: 4

Notes​

EDC is a pluggable ecosystem primarily targeting Java/Kotlin developers. Some extensions are available on the market for plug-and-play, but for certain specific use cases, developers need to write their own extensions.