4.2.1.6
Sharing agreement: Negotiation - Negotiating sharing agreement
Test: Validate that the data sharing protocol is compatible with channel encryption (e.g. TLS), that a connector authentication has taken place exclusively for the data sharing negotiation.
The description of Test 4.2.1.6 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:
- Security: [Confidentiality] The data sharing agreement exchanges use an encrypted channel, the two parties have mutually authenticated, and the information of the negotiation is only visible to authorized users of the data producer and data consumer connectors
-
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 Coverage: The solution fails to meet any of the specified technical requirements. It is not compatible with essential security protocols such as channel encryption (e.g., TLS), and no connector authentication has been implemented for data-sharing negotiations. The solution is completely inadequate for secure and effective operation. | 0 |
| Minimal Coverage: The solution meets up to 25% of the technical requirements. It offers very basic functionality, with significant limitations. Some minimal security measures might be in place, but critical features like connector authentication or comprehensive encryption are largely absent or inadequately implemented. | 1 |
| Partial Coverage: The solution satisfies approximately 50% of the technical requirements. While it includes some important features and may partially support security protocols and authentication processes, there are still substantial gaps that limit its overall effectiveness and reliability. | 2 |
| Significant Coverage: The solution covers about 80% of the technical requirements. It demonstrates a strong alignment with the desired technical criteria, including robust support for channel encryption and authentication mechanisms, though there may be minor areas where further improvement is needed. | 3 |
| Full Coverage: The solution fully meets all specified technical requirements. It provides comprehensive support for all key features, including complete compatibility with channel encryption protocols (e.g., TLS) and effective connector authentication for secure data-sharing negotiations. There are no significant gaps, making the solution highly suitable for deployment. | 4 |
Results
- Fiware
- protoEMDS Final Stack (EDC-based)
- EDC+VC
The results for Test 4.2.1.6 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.6 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 | Security and restricted access |
| Existing test ID | 4.2.1.6 |
| Level | Technical |
| ISO/IEC 25010 mapping | Security |
| Owner (tentative) | Casper (imec) |
| Reviewer | Casper |
| 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
Validate that the data sharing protocol is compatible with channel encryption (e.g. TLS), that a connector authentication has taken place exclusively for the data sharing negotiation.
Expected Output
The test aims to assess whether the data sharing protocol is compatible with channel encryption (e.g., TLS) and whether connector authentication has occurred solely for the purpose of data sharing negotiation.
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 Coverage: The solution fails to meet any of the specified technical requirements. It is not compatible with essential security protocols such as channel encryption (e.g., TLS), and no connector authentication has been implemented for data-sharing negotiations. The solution is completely inadequate for secure and effective operation. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Minimal Coverage: The solution meets up to 25% of the technical requirements. It offers very basic functionality, with significant limitations. Some minimal security measures might be in place, but critical features like connector authentication or comprehensive encryption are largely absent or inadequately implemented. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Partial Coverage: The solution satisfies approximately 50% of the technical requirements. While it includes some important features and may partially support security protocols and authentication processes, there are still substantial gaps that limit its overall effectiveness and reliability. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Significant Coverage: The solution covers about 80% of the technical requirements. It demonstrates a strong alignment with the desired technical criteria, including robust support for channel encryption and authentication mechanisms, though there may be minor areas where further improvement is needed. | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Full Coverage: The solution fully meets all specified technical requirements. It provides comprehensive support for all key features, including complete compatibility with channel encryption protocols (e.g., TLS) and effective connector authentication for secure data-sharing negotiations. There are no significant gaps, making the solution highly suitable for deployment. | 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.6 under the KPI1 area Security and restricted access.
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.6 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 9a5f93c.
- 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 whether the data sharing protocol is compatible with channel encryption (e.g., TLS) and whether connector authentication has occurred solely for the purpose of data sharing negotiation.
Results
Assessment
Channel Encryption
Currently, all communication in MVD uses HTTP, and the data is transmitted in plain text. However, based on EDC security recommendations, there is no technical limitation preventing the use of EDC components within an encrypted channel, such as with TLS enabled, or behind a load balancer or API gateway. While it is generally advised to handle HTTPS/SSL/TLS termination through deployment mechanisms such as Kubernetes or an API gateway, EDC also provides an extension for Direct SSL Termination in the Connector Runtime, available at Jetty-core.
Connector Authentication
The MVD implementation uses Token Based Authentication Service to secure connector APIs, configured by the key EDC_API_AUTH_KEY. EDC provides an AuthenticationService for integrating authentication protection into the APIs. Additionally, out-of-the-box extensions are available from EDC here.
Measured Results
As mentioned above, EDC provides out-of-the-box extensions for TLS integration and Connector API authentication. 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 create their own extensions.