Skip to main content

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.

note

The description of Test 4.2.1.6 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:

    • 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.

CriteriaScoring
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​

note

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 2025-06-02 13:59:01 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.