4.2.1.3
Sharing agreement: Negotiation - Negotiating sharing agreement
Test: Prove that the negotiation can use (one or more of) the following assets and parameters to define a contract:
- Claim verification
- Usage policy rules
- Service Agreements
The larger the coverage (i.e. more possibilities), the higher the rank.
The description of Test 4.2.1.3 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:
- Functional completeness: The protocol implements negotiation based on claims, usage policies, and business service descriptors.
-
Evaluation Criteria:
The test assigns a numeric score based on the assessment, using the Functional Suitability metric from iso27001_kpis_subkpis.xlsx.
| Criteria | Scoring |
|---|---|
| No Proof: The solution does not demonstrate the ability to use any of the specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in the negotiation process to define a contract. | 0 |
| Limited Proof: The solution demonstrates the ability to use only one of the specified assets or parameters in the negotiation process to define a contract. | 1 |
| Moderate Proof: The solution demonstrates the ability to use two of the specified assets or parameters in the negotiation process to define a contract. | 2 |
| Extensive Proof: The solution demonstrates the ability to use all three specified assets or parameters in the negotiation process to define a contract, though with some limitations in coverage or flexibility. | 3 |
| Comprehensive Proof: The solution fully demonstrates the ability to use all three specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in a flexible and comprehensive negotiation process, effectively covering a wide range of possibilities to define and manage contracts. | 4 |
Results
- Fiware
- protoEMDS Final Stack (EDC-based)
- EDC+VC
The results for Test 4.2.1.3 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
Because it has not been possible to carry out the deployment with all its characteristics, it has not been possible to evaluate this feature.
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.
Measured results
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: 0
Notes
The results for Test 4.2.1.3 for protoEMDS Final Stack (EDC-based) were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.
Environment
This section identifies the technical context in which the protoEMDS Final Stack assessment is performed.
| Field | Value |
|---|---|
| Assessment context | Integration phase assessment of the EMDS final technical infrastructure |
| Result perspective | protoemds_final_stack |
| Stack under assessment | protoEMDS Final Stack (EDC-based) |
| KPI1 area | Sharing agreement |
| Existing test ID | 4.2.1.3 |
| Level | Technical |
| ISO/IEC 25010 mapping | Functional suitability, Compatibility, Security |
| Owner (tentative) | Xavier (Eurocat) |
| Reviewer | TBD |
| Deployment model assessed | TBD |
| Target environment | TBD |
| EDC version / release | TBD |
| Connector deployment reference | TBD |
| Assessment evidence | TBD |
The assessment should be completed using the deployment model for which evidence is realistically available. It is not mandatory to execute the same test in both CaaS and on-premise environments.
If only one deployment model is assessed, the other one should be marked as Not assessed.
Tested quality metric and method
This result reuses the existing stack-agnostic test definition in test.md and adds an protoEMDS Final Stack integration-assessment perspective.
It does not replace the historical stack-specific result files, such as result_edc_vc.md or result_fiware.md.
The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment.
Test-specific assessment scope
Prove that the negotiation can use (one or more of) the following assets and parameters to define a contract:
- Claim verification
- Usage policy rules
- Service Agreements
The larger the coverage (i.e. more possibilities), the higher the rank.
Expected Output
The test aims to evaluate the coverage of the following criteria on contract negotiation:
- Claim verification
- Usage policy rules
- Service Agreements
Results
Assessment
Pending.
The assessment should be completed once consolidated technical evidence is available for the protoEMDS Final Stack deployment.
The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available.
Deployment model assessed
| Deployment model | Status | Evidence | Consolidated assessment |
|---|---|---|---|
| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as Not assessed. |
| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as Not assessed. |
Measured results
| Criteria | Measured KPI | Evidence | Notes |
|---|---|---|---|
| No Proof: The solution does not demonstrate the ability to use any of the specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Limited Proof: The solution demonstrates the ability to use only one of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Moderate Proof: The solution demonstrates the ability to use two of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Extensive Proof: The solution demonstrates the ability to use all three specified assets or parameters in the negotiation process to define a contract, though with some limitations in coverage or flexibility. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Comprehensive Proof: The solution fully demonstrates the ability to use all three specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in a flexible and comprehensive negotiation process, effectively covering a wide range of possibilities to define and manage contracts. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
Functional suitability quality metric: TBD
Notes
This result introduces an protoEMDS Final Stack perspective for the existing test 4.2.1.3 under the KPI1 area Sharing agreement.
This result should not be interpreted as part of the original Phase 1 / Phase 2 stack-comparison campaign. It is intended as an integration phase assessment of the current EMDS final technical infrastructure.
The assessment should be completed using consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner.
This result file was generated from the local test.md and, where available, the local result_edc_vc.md structure. EDC+VC-specific evidence, values and scores were intentionally not reused.
The results for Test 4.2.1.3 for EDC+VC 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 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 evaluate the coverage of the following criteria on contract negotiation:
- Claim verification
- Usage policy rules
- Service Agreements
Results
Assessment
EDC solution overview
The EDC connector features a policy engine designed to process specified usage policies. These policies can be defined across various scopes, such as:
- Cataloging scope:
contract.cataloging - Negotiation scope:
contract.negotiation - Manifest verification scope:
provision.manifest.verify
This policy engine can be added and activated as an extension to the EDC connector services.
EDC MVD implementation commit 5d58b38
Details on how policies are defined for assets in MVD Access Control can be found here. Specifically, for negotiating policy rules, an asset might require a Data Processor credential with a "level": "processing" to negotiate a contract and transfer data. The implementation of this requirement is explained here. An example of a policy requiring the consumer to present a DataProcessorCredential with an access level of processing, represented in ODRL, would look like this:
{
"@type": "http://www.w3.org/ns/odrl/2/Set",
"odrl:obligation": [
{
"odrl:action": "use",
"odrl:constraint": {
"@type": "LogicalConstraint",
"odrl:leftOperand": "DataAccess.level",
"odrl:operator": {
"@id": "odrl:eq"
},
"odrl:rightOperand": "processing"
}
}
]
}
The implementation of the policy engine for verifying the correct claim is detailed here.
Test result
After defining the asset and policy, when requesting the catalog, the mentioned processing policy is present as follows:
{
"@id": "asset-1",
"@type": "dcat:Dataset",
"odrl:hasPolicy": {
"@id": "bWVtYmVyLWFuZC1kYXRhcHJvY2Vzc29yLWRlZg==:YXNzZXQtMQ==:NWRiNjQxOTUtNGYyZC00ZWU0LTk0MWQtMWEwMGUyYzU0OTkz",
"@type": "odrl:Offer",
"odrl:permission": [],
"odrl:prohibition": [],
"odrl:obligation": {
"odrl:action": {
"@id": "use"
},
"odrl:constraint": {
"odrl:leftOperand": {
"@id": "DataAccess.level"
},
"odrl:operator": {
"@id": "odrl:eq"
},
"odrl:rightOperand": "processing"
}
}
}}
When the consumer holds the DataProcessorCredential with the correct claim level: processing:
{
"participantId": "did:web:localhost%3A7083",
"id": "40e24588-b510-41ca-966c-c1e0f57d1b15",
"timestamp": 1700659822500,
"issuerId": "did:example:dataspace-issuer",
"holderId": "did:web:localhost%3A7093",
"state": 500,
"timeOfLastStatusUpdate": null,
"issuancePolicy": null,
"reissuancePolicy": null,
"verifiableCredential": {
"rawVc": "REDACTED",
"format": "JWT",
"credential": {
"credentialSubject": [
{
"id": null,
"claims": {
"id": "did:web:localhost%3A7083",
"contractVersion": "1.0.0",
"level": "processing"
}
}
],
"id": "http://org.yourdataspace.com/credentials/1235",
"type": [
"VerifiableCredential",
"DataProcessorCredential"
],
"issuer": {
"id": "did:example:dataspace-issuer",
"additionalProperties": {}
},
"issuanceDate": "2023-12-12T00:00:00Z",
"expirationDate": null,
"credentialStatus": null,
"description": null,
"name": null
}
}
}
The contract negotiation can be finalized as shown in the following logs (provider connector):
DEBUG 2024-07-25T13:55:14.720153173 DSP: Incoming ContractRequestMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process
DEBUG 2024-07-25T13:55:14.723165306 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:14.913240117 [PROVIDER] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state REQUESTED.
DEBUG 2024-07-25T13:55:15.435605921 [ProviderContractNegotiationManagerImpl] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state AGREEING
DEBUG 2024-07-25T13:55:15.435949373 ContractNegotiation: ID 3b25dc23-d6cc-49b8-9646-08e05c6643dc. [Provider] send agreement
DEBUG 2024-07-25T13:55:15.505215217 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:15.5077679 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:15.774987457 ContractNegotiation: ID 3b25dc23-d6cc-49b8-9646-08e05c6643dc. [Provider] send agreement
DEBUG 2024-07-25T13:55:15.775180158 [ProviderContractNegotiationManagerImpl] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state AGREED
DEBUG 2024-07-25T13:55:16.806352433 DSP: Incoming ContractAgreementVerificationMessage for class org.eclipse.edc.connector.controlplane.contract.spi.types.negotiation.ContractNegotiation process: 3b25dc23-d6cc-49b8-9646-08e05c6643dc
DEBUG 2024-07-25T13:55:16.807737507 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:17.111140063 [PROVIDER] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state VERIFIED.
DEBUG 2024-07-25T13:55:17.517919388 [ProviderContractNegotiationManagerImpl] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state FINALIZING
DEBUG 2024-07-25T13:55:17.518778651 ContractNegotiation: ID 3b25dc23-d6cc-49b8-9646-08e05c6643dc. [Provider] send finalization
DEBUG 2024-07-25T13:55:17.561509541 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:17.562880316 Resolving secret did:web:localhost%3A7093-alias
DEBUG 2024-07-25T13:55:17.82966994 ContractNegotiation: ID 3b25dc23-d6cc-49b8-9646-08e05c6643dc. [Provider] send finalization
DEBUG 2024-07-25T13:55:17.829790031 [ProviderContractNegotiationManagerImpl] ContractNegotiation 3b25dc23-d6cc-49b8-9646-08e05c6643dc is now in state FINALIZED
If the correct VC is removed from the consumer who initiates the negotiation, we can see the negotiation is rejected by the provider:
DEBUG 2024-07-25T14:11:29.119011936 [Provider] Contract offer rejected as invalid: Policy in scope contract.negotiation not fulfilled for offer bWVtYmVyLWFuZC1kYXRhcHJvY2Vzc29yLWRlZg==:YXNzZXQtMQ==:NTlmNTEwMTctZGNmMy00MDZhLTg2YTQtNDdkNjM4OGMwYWJi, policy evaluation Duty constraint: [Constraint 'DataAccess.level' EQ 'processing']
Measured results
From the above behavior, we can conclude that EDC has a complete ecosystem that supports claim verification with policy rule definition and policy engine. However, due to the nature of EDC, these features are not out-of-the-box and require extension development work. The Service Agreements, specifically TM Forum Agreement, are not supported by the EDC architecture. Therefore, for this coverage test, the EDC ecosystem can check the first two boxes with an X.
- Claim verification
- Usage policy rules
- Service Agreements
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: 2
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.