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-08-13 14:49:05 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
- EDC+VC
- protoEMDS Final Stack (EDC-based)
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-08-13 14:49:05 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 EDC+VC were extracted from this page in the GitHub repository.
This file was last modified at 2026-08-13 14:49:05 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.
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-08-13 14:49:05 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) | Carlos (i2Cat) / Wilhelm (Fraunhofer IVI) |
| Reviewer | Casper (imec) |
| Deployment model assessed | CaaS / IONOS-managed deployment |
| Target environment | Ionos DCD EMDS-PROD |
| EDC version / release | emds-edc-connector 9916cc56b682ae70988300d301b752ca8eb05121 based on eclipse edc connector 0.10.0 |
| Connector deployment reference | deployEMDS-k8s-deployment, branch prepare-prod, commit 846e5f1d7a388e664fe9e4942e553021752d63c6 |
| Assessment evidence | resources-protoemds_final_stack/evidence-manifest.md, including DSP-01 |
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.
The reproducible execution procedure is in code-protoemds_final_stack/README.md and resources-protoemds_final_stack/evidence-manifest.md.
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
The CaaS / IONOS-managed deployment was assessed using two ready EDC connectors. Both public DSP endpoints advertise HTTPS through their DID documents, validate with trusted TLS 1.3 certificates, and redirect plaintext HTTP to HTTPS.
The running control planes were verified to receive the expected DSP callback, did:web identity, STS, and trace-exporter settings. A single approved negotiation reused the provider's existing asset1 offer, associated with existing policy1 and contract3, without changing any asset, policy, contract definition, participant, credential, or data-transfer state.
The negotiation initiated by connector-b against connector-a reached FINALIZED on both connectors. The consumer and provider records share agreement f48bd1f2-8c0c-4e0d-a9f1-890bf2c4ad48, and filtered control-plane logs show the DSP agreement, verification, and finalization exchange. See DSP-01.
The collected evidence demonstrates encrypted DSP transport and a successful connector-to-connector agreement exchange. The proposed assessment is Full Coverage because the authenticated connector workflow finalized on both sides over the validated HTTPS DSP path. The captured logs do not provide a standalone authentication-event record that attributes peer authentication to a specific credential or verification decision.
Supplementary platform checks
The connector dashboard is available over the same verified HTTPS ingress and redirects plaintext HTTP to HTTPS. Its implementation is a static single-page application that stores the connector API key only in browser session storage and uses it for management API requests. The dashboard route itself has no server-side session cookie; unauthenticated management access returned 401, while one controlled read-only request with the approved key returned 200. See UI-01.
Collected observability data is persisted in Elasticsearch on a bound IONOS HDD PVC. However, encryption at rest is not evidenced, Elasticsearch HTTP and transport TLS are disabled, and the OpenTelemetry Collector is configured with insecure TLS to Jaeger. Jaeger trace endpoints allowed unauthenticated access through the internal service, while Elasticsearch and Kibana required the approved credential. These are supplementary platform findings and do not change the proposed 4.2.1.6 score. See LOG-01. Authorization to negotiation logs remains in the scope of test 4.2.3.1.
Deployment model assessed
| Deployment model | Status | Evidence | Consolidated assessment |
|---|---|---|---|
| CaaS / IONOS-managed deployment | Assessed | ENV-01, AUTH-01, AUTH-02, TLS-01, TLS-02, DSP-01 | TLS, runtime configuration, and a minimal existing-offer negotiation were assessed. |
| On-premise deployment | Not assessed | N/A | No on-premise evidence was collected. |
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. | Not selected | TLS-01, TLS-02 | Valid TLS was demonstrated for both DSP endpoints. |
| 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. | Not selected | AUTH-01, AUTH-02 | Runtime identity and authentication architecture evidence exceeds basic configuration-only coverage. |
| 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. | Not selected | DSP-01 | A completed encrypted DSP agreement exchange exceeds partial coverage. |
| 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. | Not selected | AUTH-01, AUTH-02, TLS-01, TLS-02, TLS-03, DSP-01 | The same evidence supports Full Coverage as the proposed reviewer interpretation. |
| 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 | AUTH-01, AUTH-02, TLS-01, TLS-02, TLS-03, DSP-01 | Both connectors finalized the same agreement over the validated HTTPS DSP path. No standalone authentication-event record was captured. |
Functional Suitability Quality Metric: 4
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 is supported by consolidated technical evidence, including endpoint responses, runtime configuration inspection, management API responses, and filtered connector logs.
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 test-local runbook and evidence manifest are versioned with this result to enable replication without exposing credentials, cluster configuration, raw logs or other sensitive operational information.