5.2.1.1
Data sharing: Data sharing activities - Enforce usage control
Coverage + Assessment: Test the policies that are supported out of the box.
For the policies that are not supported, describe the effort of how to build them, and rank the system consequently (e.g.: create a plugin in a documented environment ranks better than integrating an external function that introduces dependencies and interface maintenance).
The description of Test 5.2.1.1 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 suitability: [Functional completeness] The system provides a PEP function that supports usage control policies of classes: Allow-usage, Role-restricted, Connector-restricted, Purpose-restricted, Interval-restricted, Location-restricted, Log-usage-of-data. (see IDSA Position Paper on Usage Control).
-
Evaluation Criteria:
| Criteria | Scoring |
|---|---|
| No out of the box policies | 0 |
| No out of the box policies but policies are available from a library | 1 |
| Partial out-of-the-box-policies | 2 |
| Full set of out-of-the-box policies | 3 |
| Documented way to create/expand policies | +1 |
| Documented way to create/expand policies + templates for basic polices | +2 |
Results
- Fiware
- protoEMDS Final Stack (EDC-based)
- EDC+VC
The results for Test 5.2.1.1 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
The test is conducted in the IONOS FIWARE_cluster cluster using node pool IP 85.215.161.198.
Tested quality metric and method
The test quality is based on the metric defined in iso27001_kpis_subkpis.xlsx. For the current phase (phase 1), the test focuses on the Functional Suitability quality metric.
Comparative criteria (checklists, ...)
| Criteria | Scoring |
|---|---|
| No out of the box policies | 0 |
| No out of the box policies but policies are available from a library | 1 |
| Partial out-of-the-box-policies | 2 |
| Full set of out-of-the-box policies | 3 |
| Documented way to create/expand policies | +1 |
| Documented way to create/expand policies + templates for basic polices | +2 |
Expected output
Usage control is defined based on the IDSA Position Paper “Data Usage Control in IDS”. Usage control involves specifying and enforcing restrictions on what must (or must not) happen to data after access has been granted.
The test aims to evaluate which usage policies are supported out of the box. For those policies not natively supported, it should describe the effort needed to implement them and rank the system accordingly. For instance, creating a plugin within a documented environment is rated more favorably than integrating an external function that introduces dependencies and requires interface maintenance. The essential policies that need to be implemented are:
- Allow-usage: Always true or false.
- Role-restricted: Based on the role of the participant.
- Location-restricted: Based on the location of the consumer, typically "EU" or "Non-EU".
Results
Assessment
Fiware connector by itself does not offer data usage control. However, a consumer restriction can be achieved by using the APISIX plugin consumer-restriction. This plugin allows users to configure access restrictions on Consumer, Route, Service, or Global Rule.
Measured results
Functional Suitability Quality Metric: 0
Notes
More information on the topic: https://apisix.apache.org/docs/apisix/plugins/consumer-restriction/
The results for Test 5.2.1.1 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 | Usage control enforcement |
| Existing test ID | 5.2.1.1 |
| Level | Technical |
| ISO/IEC 25010 mapping | Security, Maintainability |
| Owner (tentative) | Xavier (Eurocat) |
| Reviewer | Xavier |
| 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
Test the policies that are supported out of the box.
For the policies that are not supported, describe the effort of how to build them, and rank the system consequently (e.g.: create a plugin in a documented environment ranks better than integrating an external function that introduces dependencies and interface maintenance).
Expected Output
Usage control is defined based on the IDSA Position Paper “Data Usage Control in IDS”. Usage control involves specifying and enforcing restrictions on what must (or must not) happen to data after access has been granted.
The test aims to evaluate which usage policies are supported out of the box. For those policies not natively supported, it should describe the effort needed to implement them and rank the system accordingly. For instance, creating a plugin within a documented environment is rated more favorably than integrating an external function that introduces dependencies and requires interface maintenance. The essential policies that need to be implemented are:
- Allow-usage: Always true or false.
- Role-restricted: Based on the role of the participant.
- Location-restricted: Based on the location of the consumer, typically "EU" or "Non-EU".
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 out of the box policies | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| No out of the box policies but policies are available from a library | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Partial out-of-the-box-policies | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Full set of out-of-the-box policies | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Documented way to create/expand policies | TBD | TBD | Pending protoEMDS Final Stack assessment. |
| Documented way to create/expand policies + templates for basic polices | 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 5.2.1.1 under the KPI1 area Usage control enforcement.
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 5.2.1.1 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 8da0c4e.
- EDC version 0.8.2-SNAPSHOT
- The test is executed in an Ubuntu environment using IntelliJ.
Tested quality metric and method
The test quality is based on the metric defined in iso27001_kpis_subkpis.xlsx.
For the current phase (phase 1), the test focuses on the Functional Suitability quality metric.
Comparative criteria (checklists, ...)
| Criteria | Scoring |
|---|---|
| No out of the box policies | 0 |
| No out of the box policies but policies are available from a library | 1 |
| Partial out-of-the-box-policies | 2 |
| Full set of out-of-the-box policies | 3 |
| Documented way to create/expand policies | +1 |
| Documented way to create/expand policies + templates for basic polices | +2 |
Expected Output
Usage control is defined based on the IDSA Position Paper “Data Usage Control in IDS”. Usage control involves specifying and enforcing restrictions on what must (or must not) happen to data after access has been granted.
The test aims to evaluate which usage policies are supported out of the box. For those policies not natively supported, it should describe the effort needed to implement them and rank the system accordingly. For instance, creating a plugin within a documented environment is rated more favorably than integrating an external function that introduces dependencies and requires interface maintenance. The essential policies that need to be implemented are:
- Allow-usage: Always true or false.
- Role-restricted: Based on the role of the participant.
- Location-restricted: Based on the location of the consumer, typically "EU" or "Non-EU".
Results
Assessment
Usage control is not included in the EDC MVD commit 8da0c4e. The policy engine embedded in the EDC solution, which processes ODRL (Open Digital Rights Language) policies, applies only to data access rights.
Implementation Gap
EDC has initiated a discussion to gather use cases for usage control here, but there is no implementation from EDC at this time.
IMEC has analyzed how usage control could be enforced. For example, a usage policy might specify that data must be deleted after 24 hours. If a consumer downloads a file from the provider connector to their S3 storage, trusted software can be implemented to monitor this storage (Policy Enforcement Point, or PEP). This software would automatically delete the data upon expiry and communicate this to the Policy Decision Point (PDP) and Policy Execution Point (PXP). The PDP or PXP can be part of the provider connector or communicate with connectors.
Measured results
As demonstrated above, there is no usage control feature currently implemented in the EDC development. As there is no implementation nor documentation, we cannot offer a +1 or +2 either. Therefore, the following score is given to the test:
Functional Suitability Quality Metric: 0
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.