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 2026-06-24 15:37:50 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 Fiware were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.

Environment​

The test environment Fiware v0.2 was used as described in Fiware Deployment v0.2

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​

According to TMF622 Product Ordering Management API User Guide a product order can be in the states:

  • Acknowledged
  • Rejected
  • Pending
  • InProgress
  • Held
  • AssessingCancellation
  • PendingCancellation
  • Cancelled
  • Completed
  • Failed
  • Partial

Measured results​

The current example only deals with placing the order with a request sent by the customer:

curl -v -X POST "${tmf_api_complete_url}/tmf-api/productOrderingManagement/v4/productOrder" \
   -H 'Accept: */*' \
   -H 'Content-Type: application/json' \
   -H "Authorization: Bearer ${SERVICE_ACCESS_TOKEN}" \
   -d "{
       \"productOrderItem\": [
         {
           \"id\": \"random-order-id\",
           \"action\": \"add\",
           \"productOffering\": {
             \"id\" :  \"${OFFER_ID}\"
           }
         }  
       ],
       \"relatedParty\": [
         {
           \"id\": \"${FANCY_MARKETPLACE_ID}\"
         }
       ]}"

Therefore, it is unclear how the transition of states is handled. Especially:

  • How a state change is triggered?
  • By whom a state change is triggered?
  • What effect does a state change or the state of an order item in general have to other components in the ecosystem?

There are no components that negotiate a state as mentioned in the test description.

In the current implementation of the FIWARE Connector and its components, the negotiation state is only minimally covered by having an entity that holds the state.

Functional suitability quality metric: 1

Notes​

To consume an ordered product, a provider has to provide access to the consumer to that product. This is done by issuing a VC to the consumer that is accepted by the Policy Decision Point (PDP) of the provider and registering the issuer of the VC in the Trusted Issuer Registry (TIR) that is used by the providers' VCVerifier. In the current setup, there seems to be no relation between the state of a product ordering and the act of enabling access to a resource as described before.