Skip to main content

4.2.3.1

Sharing agreement: Negotiation - Refusal or registration of sharing agreement

Assessment: Check whether the negotiation API, or the status messages, or the negotiation logs, are not accessible to entities other than the negotiating participants and the system admin (privileged role).

note

The description of Test 4.2.3.1 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 system ensures that confidential details of the agreement are only shared between authorized participants.

  • 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. This indicates a complete lack of implementation concerning the requirements. There is no functionality to manage negotiation APIs, status messages, or logs, or they are accessible by unauthorized users, compromising security.0
Minimal Coverage: The solution meets up to 25% of the technical requirements. Basic elements may be present, such as rudimentary access controls or a partial implementation of the negotiation API. However, significant gaps exist, such as missing or improperly secured status messages and logs, allowing unauthorized access, or only basic encryption without role differentiation.1
Partial Coverage: The solution satisfies approximately 50% of the technical requirements. The negotiation API is implemented with basic access control, but not all security measures are in place. For instance, status messages and logs might be accessible only to participants but not properly restricted from non-participating users or system admins. Encryption might be present but inconsistently applied.2
Significant Coverage: The solution covers about 80% of the technical requirements. Most key functionalities are implemented effectively. The negotiation API, status messages, and logs are generally restricted to negotiating participants and the system admin. However, there may be minor vulnerabilities or inconsistencies, such as edge cases where unauthorized access could occur or some roles are not clearly distinguished.3
Full Coverage: The solution fully meets all technical requirements, ensuring that the negotiation API, status messages, and negotiation logs are strictly accessible only to the negotiating participants and the system admin. The system admin role is fully defined and technically privileged, with no overlap with participant identities unless explicitly intended. Strong encryption and access controls are applied consistently.4

Results​

note

The results for Test 4.2.3.1 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 evaluate whether the negotiation API, status messages, and negotiation logs are accessible only to the negotiating participants and the system admin. The system admin is a technically privileged role whose identity is not necessarily that of a participant.

Results​

Assessment​

Log Monitoring​

EDC Connector Commit 417ad15 does not provide an API endpoint for viewing negotiation traces. According to the testing results from EDC MVD commit 9a5f93c, logs are only displayed on the connector runtime console and are accessible solely to users with technical privileged roles.

Status Messages and Corresponding APIs​

EDC Connector Management API 0.7.1 Snapshot provides endpoints for the corresponding APIs for Contract Negotiation:

  • /v3/contractnegotiations
  • /v3/contractnegotiations/request
  • /v3/contractnegotiations/{id}
  • /v3/contractnegotiations/{id}/agreement
  • /v3/contractnegotiations/{id}/state
  • /v3/contractnegotiations/{id}/terminate

The API endpoints allow consultation of the negotiation states. As stated in TEST 4.2.1.6, EDC provides an AuthenticationService for integrating authentication protection into the APIs, ensuring that the APIs can only be triggered with the correct authentication method.

Measured Results​

As previously mentioned, EDC offers built-in extensions to secure the API endpoints and restrict logging access exclusively to participants and privileged system administrators. 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.