From ab6478d6454e713db66e0df15e8490cd1f5fff19 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 09:21:27 -0700 Subject: [PATCH 1/8] Add KPI1 EMDS integration baseline proposal --- .../test_5_1_1_1/result_emds_final_stack.md | 102 +++++++++++++ .../kpi1-integration-baseline.mdx | 136 ++++++++++++++++++ 2 files changed, 238 insertions(+) create mode 100644 tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md create mode 100644 web/docs/tech-testing/kpi1-integration-baseline.mdx diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md new file mode 100644 index 00000000..887ba199 --- /dev/null +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md @@ -0,0 +1,102 @@ +# Result: EMDS Final Stack + +## Information + +| Field | Value | +|---|---| +| Result perspective | EMDS Final Stack | +| Existing test ID | 5.1.1.1 | +| Existing test name | Request data transfer | +| KPI | KPI1 - Maturity, reliability and security of the common technical infrastructure building blocks deployed | +| Assessment purpose | Integration readiness baseline | +| Assessment level | UC validation + technical validation | +| Installation model | CaaS / On-premise / Mixed | +| Status | Draft baseline template | + +## Context + +This result file does not replace the historical EDC+VC or Fiware test results. It adds a new result perspective for the current EMDS integrated technical infrastructure. + +The purpose is to reuse the existing deployEMDS technology testing catalogue for KPI1, while adapting the assessment to the current project phase. The focus is not stack comparison, but the integration readiness of the selected common infrastructure. + +## Quality model mapping + +For KPI1, this test is mapped to the following ISO/IEC 25010 characteristics: + +| ISO/IEC 25010 characteristic | Interpretation for this test | +|---|---| +| Functional suitability | The stack provides a mechanism to request and manage data transfer | +| Compatibility / interoperability | The transfer process can operate across relevant EMDS components and participants | +| Reliability | Transfer status, results and past actions can be retrieved or traced | +| Security | The transfer request and related APIs are protected by the expected access control mechanisms | +| Maintainability | Evidence is available to troubleshoot and repeat the test | + +## Expected capability + +The EMDS final stack should provide a documented and secured mechanism to: + +- initiate a data sharing request; +- retrieve data sharing information and status; +- receive or inspect the outcome of the request; +- retrieve information about past data sharing actions; +- provide enough operational evidence through API responses, logs, screenshots, GitHub/Jira issues, deployment status or test execution records. + +## Assessment dimensions + +| Dimension | Question | +|---|---| +| UC validation | Can the use case or tech buddy execute or observe the data transfer flow in practice? | +| Technical validation | Is the underlying common infrastructure deployed, integrated, secured and technically verifiable? | +| Installation model | Is the evidence coming from CaaS, on-premise or a mixed setup? | +| Evidence | Is there a concrete artefact supporting the score? | + +## Scoring scale + +| Score | Meaning for KPI1 | +|---:|---| +| 0 | Not available / not attempted / no evidence | +| 1 | Available conceptually or blocked | +| 2 | Deployed or in progress, but only partially tested | +| 3 | Working with evidence in a local or controlled context | +| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | + +Scores of 3 or 4 require supporting evidence. + +## Results + +| Requirement | UC validation | Technical validation | Installation model | Evidence | Score | +|---|---|---|---|---|---:| +| Initiate a data sharing request | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | +| Retrieve data sharing information and status | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | +| Receive or inspect the data sharing request outcome | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | +| Retrieve information about past data sharing actions | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | +| Access logs, status or operational evidence for troubleshooting | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | + +## Installation model considerations + +### CaaS + +For CaaS deployments, the infrastructure availability, endpoint exposure, service health, logs and operational evidence should mainly be validated by IONOS and the relevant component owners. The UC or tech buddy validates whether the capability can be used from the use case perspective. + +### On-premise + +For on-premise deployments, the UC technical team validates local installation, network access, firewall/DNS/certificate constraints and connectivity with the common or federated infrastructure. Component owners support the validation of integration points. + +### Mixed + +For mixed setups, evidence should explicitly state which part of the flow is running in CaaS and which part is running locally. + +## KPI1 assessment + +| Item | Value | +|---|---| +| Overall score | TBD | +| Main maturity gap | TBD | +| Main reliability gap | TBD | +| Main security gap | TBD | +| Main blocker | TBD | +| Owner / next action | TBD | + +## Notes + +This file is intended as a draft template to demonstrate how KPI1 can be integrated into the existing deployEMDS testing structure without changing the historical EDC+VC and Fiware results. diff --git a/web/docs/tech-testing/kpi1-integration-baseline.mdx b/web/docs/tech-testing/kpi1-integration-baseline.mdx new file mode 100644 index 00000000..eda9d2a2 --- /dev/null +++ b/web/docs/tech-testing/kpi1-integration-baseline.mdx @@ -0,0 +1,136 @@ +--- +sidebar_position: 3 +--- + +# KPI1 Integration Baseline + +## Objective + +This page proposes a simplified baseline approach for **KPI1: maturity, reliability and security of the common technical infrastructure building blocks deployed**. + +The objective is not to repeat the initial stack comparison exercise. Instead, the proposal reuses the existing deployEMDS technology testing catalogue and adapts it to the current project need: monitoring the integration readiness of the selected EMDS technical infrastructure. + +## Rationale + +The original technology testing methodology was designed to compare testing facilities such as EDC+VC and Fiware using common, stack-agnostic test definitions and stack-specific result files. + +For KPI1, the same evidence-based logic can be reused, but with a different purpose: + +- focus on the **EMDS final / integrated stack**, not on comparing alternative stacks; +- assess **integration readiness**, not only isolated component availability; +- distinguish between **UC validation** and **technical validation**; +- distinguish between **CaaS**, **on-premise** and **mixed** installation models; +- keep the historical EDC+VC and Fiware results unchanged. + +## Proposed result perspective + +A new result perspective should be added to selected existing tests: + +```text +EMDS Final Stack +``` + +This perspective should be documented as a new result file next to the historical EDC+VC and Fiware results, for example: + +```text +tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +``` + +This does not replace the historical results. It adds a new baseline view for the current EMDS integrated infrastructure. + +## Scope of KPI1 + +The KPI1 baseline should focus on a limited set of integration areas: + +| KPI1 area | Main purpose | +|---|---| +| Participant onboarding and identity | Validate whether participants can be onboarded and represented in the trust framework | +| Connector and data plane | Validate whether the connector and data transfer mechanisms are available and usable | +| Catalogue and metadata | Validate whether data offers can be published, discovered and described with appropriate metadata | +| Sharing agreement and negotiation | Validate whether agreement flows can be initiated and traced | +| Data sharing and transfer | Validate whether test or real data payloads can be transferred | +| Observability and logging | Validate whether failures, transactions and component health can be monitored | +| Security and access control | Validate whether authentication, authorization and policy mechanisms are applied | +| Blockers and support needs | Track unresolved dependencies, ownership and next actions | + +## Assessment levels + +KPI1 should not be completed only by use cases or only by technical teams. It should combine two complementary levels. + +| Level | Completed by | Purpose | +|---|---|---| +| UC validation | Use case technical experts / tech buddies | Validate whether the use case can use the stack in practice | +| Technical validation | Component owners / infrastructure teams | Validate whether the common building blocks are deployed, integrated, reliable and secured | + +The UC questionnaire should be treated as an operational input to KPI1, not as the KPI1 assessment itself. + +## Installation models + +The KPI1 baseline should explicitly distinguish the installation model used by each use case. + +| Installation model | Meaning | Main responsibility | +|---|---|---| +| CaaS | IONOS-managed deployment | IONOS and relevant component owners validate infrastructure, endpoints and operational evidence | +| On-premise | Deployment managed in the UC local environment | UC technical team validates infrastructure, network, firewall, DNS, certificates and local deployment | +| Mixed | Combination of CaaS and local/on-premise components | Shared responsibility between the UC team, IONOS and component owners | + +## ISO/IEC 25010 mapping + +The KPI1 baseline should not try to cover the complete ISO/IEC 25010 model. For the current integration monitoring purpose, the following quality characteristics are sufficient: + +| ISO/IEC 25010 characteristic | KPI1 interpretation | +|---|---| +| Functional suitability | The building block provides the required capability | +| Compatibility / interoperability | The building block integrates with related components and external participants | +| Reliability | The capability is stable, repeatable and observable enough to support testing | +| Security | Authentication, authorization, trust and policy controls are in place | +| Maintainability | Configuration, deployment, versioning and troubleshooting evidence are available | + +## Simplified scoring + +The baseline should reuse the 0–4 scoring principle from the existing technology testing results, but simplify the interpretation for integration readiness. + +| Score | Meaning for KPI1 | +|---:|---| +| 0 | Not available / not attempted / no evidence | +| 1 | Available conceptually or blocked | +| 2 | Deployed or in progress, but only partially tested | +| 3 | Working with evidence in a local or controlled context | +| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | + +Scores of 3 or 4 should require supporting evidence such as an endpoint response, screenshot, GitHub/Jira issue, log, test execution result, deployment status, or confirmation from the relevant component owner. + +## Proposed dynamic tracker + +A shared Excel Online / SharePoint tracker can be used to connect the weekly WP2 questionnaire updates with KPI1 consolidation. + +Suggested tabs: + +| Tab | Purpose | +|---|---| +| Weekly UC questionnaire | Raw weekly responses from use cases and tech buddies | +| KPI1 mapping | Mapping between questionnaire questions, existing test IDs and KPI1 areas | +| KPI1 scoring | Consolidated score by week, UC, installation model, area and evidence | +| Blockers and actions | Blocker, owner, priority, status and next action | +| Dashboard | Pivot views by UC, component area, installation model and blocker owner | + +## Proposed minimum test set + +The initial KPI1 baseline should reuse a small subset of the existing deployEMDS tests, rather than creating a new test catalogue. + +| KPI1 area | Example existing test IDs | +|---|---| +| Participant onboarding and identity | 1.2.1.1, 1.3.1.5 | +| Connector and data plane | 2.1.1.3 | +| Policies and usage control | 2.1.3.1, 2.2.2.1 | +| Catalogue and metadata | 2.2.3.1A/B/D, 3.1.1.1, 3.1.1.4 | +| Sharing agreement and negotiation | 4.2.1.1, 4.2.1.6, 4.2.1.7, 4.2.3.1, 4.2.3.2 | +| Data sharing and transfer | 5.1.1.1, 5.1.1.2, 5.2.1.1 | + +## Proposed decision + +The WP2 questionnaire and KPI1 should be aligned through a common tracking format, but not fully merged conceptually. + +The questionnaire provides the weekly operational input from the use cases. KPI1 provides the consolidated assessment of maturity, reliability and security of the common technical infrastructure. + +The existing EDC+VC and Fiware results should remain as historical stack-comparison evidence. A new `EMDS Final Stack` result perspective should be added to selected tests to support the KPI1 integration baseline. From 323c8df027ccd9206f63f0fbb211a7d373c74067 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 10:02:55 -0700 Subject: [PATCH 2/8] Align EMDS Final Stack result with existing test format --- .../test_5_1_1_1/result_emds_final_stack.md | 158 ++++++++++-------- 1 file changed, 85 insertions(+), 73 deletions(-) diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md index 887ba199..41e51e9f 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md @@ -1,102 +1,114 @@ -# Result: EMDS Final Stack +## [5.1.1.1] Data sharing: Data sharing request - Request data transfer -## Information +### Stack: EMDS Final Stack (EDC-based) -| Field | Value | -|---|---| -| Result perspective | EMDS Final Stack | -| Existing test ID | 5.1.1.1 | -| Existing test name | Request data transfer | -| KPI | KPI1 - Maturity, reliability and security of the common technical infrastructure building blocks deployed | -| Assessment purpose | Integration readiness baseline | -| Assessment level | UC validation + technical validation | -| Installation model | CaaS / On-premise / Mixed | -| Status | Draft baseline template | +### Statement of assessment -## Context +#### Environment -This result file does not replace the historical EDC+VC or Fiware test results. It adds a new result perspective for the current EMDS integrated technical infrastructure. +- The assessment targets the current EMDS integrated technical infrastructure. +- The stack is based on the EDC connector and the common/federated EMDS building blocks selected for the current project phase. +- The assessment should distinguish between the following installation models: + - CaaS: IONOS-managed deployment. + - On-premise: deployment managed by the local UC technical team. + - Mixed: combination of CaaS and local/on-premise components. +- The exact EDC version, deployment environment, release and component configuration must be confirmed during the KPI1 baseline execution. +- This result perspective does not replace the historical EDC+VC or Fiware results. It introduces an EMDS Final Stack perspective focused on integration readiness. -The purpose is to reuse the existing deployEMDS technology testing catalogue for KPI1, while adapting the assessment to the current project phase. The focus is not stack comparison, but the integration readiness of the selected common infrastructure. +#### Tested quality metric and method -## Quality model mapping +The quality metric for this test is based on the criteria outlined in [iso27001_kpis_subkpis.xlsx](../../../../../design_decisions/background_info/iso27001_kpis_subkpis.xlsx). -For KPI1, this test is mapped to the following ISO/IEC 25010 characteristics: +For the KPI1 baseline, the original evidence-based technology testing approach is reused and simplified. The objective is no longer to compare stacks, but to assess the maturity, reliability and security of the common EMDS technical infrastructure building blocks deployed. -| ISO/IEC 25010 characteristic | Interpretation for this test | -|---|---| -| Functional suitability | The stack provides a mechanism to request and manage data transfer | -| Compatibility / interoperability | The transfer process can operate across relevant EMDS components and participants | -| Reliability | Transfer status, results and past actions can be retrieved or traced | -| Security | The transfer request and related APIs are protected by the expected access control mechanisms | -| Maintainability | Evidence is available to troubleshoot and repeat the test | +The assessment is mapped to selected ISO/IEC 25010 quality characteristics: -## Expected capability +- Functional suitability: the transfer request capability provides the expected functionality. +- Compatibility / interoperability: the transfer flow integrates with the relevant EMDS components and data planes. +- Reliability: the transfer request can be executed and monitored in a repeatable way. +- Security: the API and related flows are authenticated, authorised and protected. +- Maintainability: the flow can be configured, monitored, troubleshot and documented. -The EMDS final stack should provide a documented and secured mechanism to: +The result should be informed by two complementary validation levels: -- initiate a data sharing request; -- retrieve data sharing information and status; -- receive or inspect the outcome of the request; -- retrieve information about past data sharing actions; -- provide enough operational evidence through API responses, logs, screenshots, GitHub/Jira issues, deployment status or test execution records. +| Level | Completed by | Purpose | +|---|---|---| +| UC validation | Use case technical experts / tech buddies | Validate whether the use case can execute or use the transfer flow in practice | +| Technical validation | Component owners / infrastructure teams | Validate whether the common building blocks are deployed, integrated, reliable and secured | -## Assessment dimensions +#### Expected Output -| Dimension | Question | -|---|---| -| UC validation | Can the use case or tech buddy execute or observe the data transfer flow in practice? | -| Technical validation | Is the underlying common infrastructure deployed, integrated, secured and technically verifiable? | -| Installation model | Is the evidence coming from CaaS, on-premise or a mixed setup? | -| Evidence | Is there a concrete artefact supporting the score? | +The test aims to provide a comprehensive evaluation of the following aspects: -## Scoring scale +- **Assess the availability of the data transfer API:** Ensure that the relevant API or transfer mechanism is accessible and functional in the EMDS final stack. +- **Test data sharing requests:** Verify that data sharing requests are correctly processed, covering these steps: + - Initiating a data sharing request. + - Retrieving information and status of the data sharing request. + - Receiving the outcome of the data sharing request, including conditions. + - Accessing information on past data sharing activities. +- **Distinguish local and federated execution:** Identify whether the transfer flow works only locally, through the common/federated infrastructure, or across sites. +- **Capture evidence:** Collect endpoint responses, screenshots, logs, GitHub/Jira references, deployment status or confirmation from the relevant component owner. +- **Identify blockers:** Record technical, organisational, infrastructure, security or documentation blockers. -| Score | Meaning for KPI1 | -|---:|---| -| 0 | Not available / not attempted / no evidence | -| 1 | Available conceptually or blocked | -| 2 | Deployed or in progress, but only partially tested | -| 3 | Working with evidence in a local or controlled context | -| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | +The system will score higher if the transfer request is integrated with the common/federated EMDS infrastructure, secured, stable, repeatable and supported by evidence. + +### Results -Scores of 3 or 4 require supporting evidence. +#### Assessment -## Results +The EMDS Final Stack assessment reuses this existing test definition to validate whether the current EDC-based EMDS infrastructure can support data transfer requests from an integration-readiness perspective. -| Requirement | UC validation | Technical validation | Installation model | Evidence | Score | -|---|---|---|---|---|---:| -| Initiate a data sharing request | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | -| Retrieve data sharing information and status | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | -| Receive or inspect the data sharing request outcome | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | -| Retrieve information about past data sharing actions | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | -| Access logs, status or operational evidence for troubleshooting | To be completed | To be completed | CaaS / On-premise / Mixed | TBD | TBD | +The assessment should verify whether the selected deployment model, CaaS, on-premise or mixed, can support the following capabilities: -## Installation model considerations +- initiate a data sharing request; +- retrieve data sharing information and status; +- receive the outcome of the request; +- retrieve information about previous data sharing actions; +- provide sufficient logs or operational evidence to troubleshoot the flow; +- confirm whether the flow is local, federated or cross-site. -### CaaS +For CaaS deployments, infrastructure availability, endpoint exposure, access credentials and logs are mainly validated by IONOS and the relevant component owners. -For CaaS deployments, the infrastructure availability, endpoint exposure, service health, logs and operational evidence should mainly be validated by IONOS and the relevant component owners. The UC or tech buddy validates whether the capability can be used from the use case perspective. +For on-premise deployments, the UC technical team validates the local installation, network configuration, firewall/DNS/certificate constraints and connectivity with the common/federated infrastructure. -### On-premise +#### Measured results -For on-premise deployments, the UC technical team validates local installation, network access, firewall/DNS/certificate constraints and connectivity with the common or federated infrastructure. Component owners support the validation of integration points. +| Requirement | UC validation | Technical validation | Evidence | Measured KPI | +|---|---|---|---|---:| +| Initiate a data sharing request | To be completed | To be completed | TBD | TBD | +| Retrieve data sharing information and status | To be completed | To be completed | TBD | TBD | +| Receive data sharing request outcome condition | To be completed | To be completed | TBD | TBD | +| Retrieve data sharing information of past data sharing actions | To be completed | To be completed | TBD | TBD | + +**Overall Calculation:** TBD +**Functional Suitability Quality Metric Score:** TBD + +#### KPI1 scoring interpretation + +For the KPI1 baseline, the following simplified 0-4 scale is proposed: + +| Score | Meaning | +|---:|---| +| 0 | Not available / not attempted / no evidence | +| 1 | Available conceptually or blocked | +| 2 | Deployed or in progress, but partially tested | +| 3 | Working with evidence in local or controlled context | +| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | -### Mixed +A score of 3 or higher should be supported by evidence. -For mixed setups, evidence should explicitly state which part of the flow is running in CaaS and which part is running locally. +#### Notes -## KPI1 assessment +This result perspective is intended as a baseline template for the EMDS Final Stack. -| Item | Value | -|---|---| -| Overall score | TBD | -| Main maturity gap | TBD | -| Main reliability gap | TBD | -| Main security gap | TBD | -| Main blocker | TBD | -| Owner / next action | TBD | +It should be completed during the KPI1 assessment using evidence from: -## Notes +- WP2 questionnaire updates; +- UC validation tests; +- technical validation by component owners; +- IONOS CaaS deployment status, where applicable; +- on-premise deployment evidence, where applicable; +- GitHub/Jira issues; +- logs, screenshots, endpoint responses or test execution records. -This file is intended as a draft template to demonstrate how KPI1 can be integrated into the existing deployEMDS testing structure without changing the historical EDC+VC and Fiware results. +The result should not be interpreted as a new stack comparison. It is an integration-readiness assessment of the selected EMDS technical infrastructure. \ No newline at end of file From 4a510532e9f4db4c8a891cc07710b21dd4067c8b Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 13:00:24 -0700 Subject: [PATCH 3/8] Document EMDS Final Stack integration assessment approach --- .../test_5_1_1_1/result_emds_final_stack.md | 113 ++++++--------- .../kpi1-integration-baseline.mdx | 136 ------------------ web/docs/tech-testing/way-of-working.mdx | 95 ++++++++---- 3 files changed, 110 insertions(+), 234 deletions(-) delete mode 100644 web/docs/tech-testing/kpi1-integration-baseline.mdx diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md index 41e51e9f..d0a44094 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md @@ -6,109 +6,76 @@ #### Environment -- The assessment targets the current EMDS integrated technical infrastructure. -- The stack is based on the EDC connector and the common/federated EMDS building blocks selected for the current project phase. -- The assessment should distinguish between the following installation models: - - CaaS: IONOS-managed deployment. - - On-premise: deployment managed by the local UC technical team. - - Mixed: combination of CaaS and local/on-premise components. -- The exact EDC version, deployment environment, release and component configuration must be confirmed during the KPI1 baseline execution. -- This result perspective does not replace the historical EDC+VC or Fiware results. It introduces an EMDS Final Stack perspective focused on integration readiness. +- Assessment context: Integration phase assessment of the EMDS final technical infrastructure. +- Deployment model: TBD + - CaaS / IONOS-managed deployment + - On-premise deployment +- Target environment: TBD +- EDC version / release: TBD +- Connector deployment reference: TBD +- Assessment evidence: TBD #### Tested quality metric and method -The quality metric for this test is based on the criteria outlined in [iso27001_kpis_subkpis.xlsx](../../../../../design_decisions/background_info/iso27001_kpis_subkpis.xlsx). +The quality metric for this test is based on the criteria outlined in [iso27001_kpis_subkpis.xlsx](../../../../../design_decisions/background_info/iso27001_kpis_subkpis.xlsx). For detailed information, please refer to the [Comparative criteria (checklists, ...)](./test.md#comparative-criteria-checklists-) section in the test description. -For the KPI1 baseline, the original evidence-based technology testing approach is reused and simplified. The objective is no longer to compare stacks, but to assess the maturity, reliability and security of the common EMDS technical infrastructure building blocks deployed. +This result does not belong to the original deployEMDS Phase 1 / Phase 2 testing campaign used for the initial stack comparison. Instead, it reuses the existing test definition to assess the EMDS final technical infrastructure during the integration phase. -The assessment is mapped to selected ISO/IEC 25010 quality characteristics: - -- Functional suitability: the transfer request capability provides the expected functionality. -- Compatibility / interoperability: the transfer flow integrates with the relevant EMDS components and data planes. -- Reliability: the transfer request can be executed and monitored in a repeatable way. -- Security: the API and related flows are authenticated, authorised and protected. -- Maintainability: the flow can be configured, monitored, troubleshot and documented. - -The result should be informed by two complementary validation levels: - -| Level | Completed by | Purpose | -|---|---|---| -| UC validation | Use case technical experts / tech buddies | Validate whether the use case can execute or use the transfer flow in practice | -| Technical validation | Component owners / infrastructure teams | Validate whether the common building blocks are deployed, integrated, reliable and secured | +For the EMDS Final Stack, the assessment focuses on whether the current EDC-based infrastructure provides a documented, secured and testable mechanism to initiate and manage data transfer requests. #### Expected Output The test aims to provide a comprehensive evaluation of the following aspects: -- **Assess the availability of the data transfer API:** Ensure that the relevant API or transfer mechanism is accessible and functional in the EMDS final stack. +- **Assess the availability of the API:** Ensure that the API or equivalent transfer mechanism is accessible and functional in the EMDS Final Stack. - **Test data sharing requests:** Verify that data sharing requests are correctly processed, covering these steps: - - Initiating a data sharing request. - - Retrieving information and status of the data sharing request. - - Receiving the outcome of the data sharing request, including conditions. - - Accessing information on past data sharing activities. -- **Distinguish local and federated execution:** Identify whether the transfer flow works only locally, through the common/federated infrastructure, or across sites. -- **Capture evidence:** Collect endpoint responses, screenshots, logs, GitHub/Jira references, deployment status or confirmation from the relevant component owner. -- **Identify blockers:** Record technical, organisational, infrastructure, security or documentation blockers. + - Initiating a data sharing request. + - Retrieving information and status of the data sharing request. + - Receiving the outcome of the data sharing request, including conditions. + - Accessing information on past data sharing activities. +- **Assess deployment-specific evidence:** Indicate whether the assessment was performed in a CaaS or on-premise deployment. -The system will score higher if the transfer request is integrated with the common/federated EMDS infrastructure, secured, stable, repeatable and supported by evidence. +The system will score higher if the API is secured, implements common methods such as REST, and can be validated with repeatable technical evidence in the selected deployment model. ### Results #### Assessment -The EMDS Final Stack assessment reuses this existing test definition to validate whether the current EDC-based EMDS infrastructure can support data transfer requests from an integration-readiness perspective. +TBD. + +The assessment should be completed once consolidated evidence is available for the EMDS Final Stack deployment. -The assessment should verify whether the selected deployment model, CaaS, on-premise or mixed, can support the following capabilities: +The result should indicate whether the score applies to: -- initiate a data sharing request; -- retrieve data sharing information and status; -- receive the outcome of the request; -- retrieve information about previous data sharing actions; -- provide sufficient logs or operational evidence to troubleshoot the flow; -- confirm whether the flow is local, federated or cross-site. +- CaaS / IONOS-managed deployment; +- on-premise deployment; +- or both deployment models. -For CaaS deployments, infrastructure availability, endpoint exposure, access credentials and logs are mainly validated by IONOS and the relevant component owners. +#### Deployment model assessed -For on-premise deployments, the UC technical team validates the local installation, network configuration, firewall/DNS/certificate constraints and connectivity with the common/federated infrastructure. +| Deployment model | Status | Evidence | Consolidated assessment | +|---|---|---|---| +| CaaS / IONOS-managed deployment | TBD | TBD | TBD | +| On-premise deployment | TBD | TBD | TBD | #### Measured results -| Requirement | UC validation | Technical validation | Evidence | Measured KPI | -|---|---|---|---|---:| -| Initiate a data sharing request | To be completed | To be completed | TBD | TBD | -| Retrieve data sharing information and status | To be completed | To be completed | TBD | TBD | -| Receive data sharing request outcome condition | To be completed | To be completed | TBD | TBD | -| Retrieve data sharing information of past data sharing actions | To be completed | To be completed | TBD | TBD | +| Requirement | Measured KPI | Evidence | Notes | +|---|---:|---|---| +| Initiate a data sharing request | TBD | TBD | Pending assessment based on execution evidence from the selected deployment model. | +| Retrieve data sharing information and status | TBD | TBD | Pending assessment based on evidence of transfer process status retrieval. | +| Receive data sharing request outcome condition | TBD | TBD | Pending assessment based on evidence that the transfer request outcome can be retrieved and interpreted. | +| Retrieve data sharing information of past data sharing actions | TBD | TBD | Pending assessment based on evidence of traceability or access to previous transfer actions. | **Overall Calculation:** TBD **Functional Suitability Quality Metric Score:** TBD -#### KPI1 scoring interpretation - -For the KPI1 baseline, the following simplified 0-4 scale is proposed: - -| Score | Meaning | -|---:|---| -| 0 | Not available / not attempted / no evidence | -| 1 | Available conceptually or blocked | -| 2 | Deployed or in progress, but partially tested | -| 3 | Working with evidence in local or controlled context | -| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | - -A score of 3 or higher should be supported by evidence. - #### Notes -This result perspective is intended as a baseline template for the EMDS Final Stack. +This result introduces an **EMDS Final Stack** perspective for the existing test. It does not replace the historical **EDC+VC** or **Fiware** results. -It should be completed during the KPI1 assessment using evidence from: +This result should not be interpreted as part of the original Phase 1 / Phase 2 testing campaign. It is intended as an integration phase assessment of the current EMDS final technical infrastructure. -- WP2 questionnaire updates; -- UC validation tests; -- technical validation by component owners; -- IONOS CaaS deployment status, where applicable; -- on-premise deployment evidence, where applicable; -- GitHub/Jira issues; -- logs, screenshots, endpoint responses or test execution records. +The assessment should be completed using consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub/Jira references, deployment status or confirmation from the relevant component owner. -The result should not be interpreted as a new stack comparison. It is an integration-readiness assessment of the selected EMDS technical infrastructure. \ No newline at end of file +If the test is executed in both CaaS and on-premise environments, the result should clearly indicate whether the score applies to one deployment model or to both. \ No newline at end of file diff --git a/web/docs/tech-testing/kpi1-integration-baseline.mdx b/web/docs/tech-testing/kpi1-integration-baseline.mdx deleted file mode 100644 index eda9d2a2..00000000 --- a/web/docs/tech-testing/kpi1-integration-baseline.mdx +++ /dev/null @@ -1,136 +0,0 @@ ---- -sidebar_position: 3 ---- - -# KPI1 Integration Baseline - -## Objective - -This page proposes a simplified baseline approach for **KPI1: maturity, reliability and security of the common technical infrastructure building blocks deployed**. - -The objective is not to repeat the initial stack comparison exercise. Instead, the proposal reuses the existing deployEMDS technology testing catalogue and adapts it to the current project need: monitoring the integration readiness of the selected EMDS technical infrastructure. - -## Rationale - -The original technology testing methodology was designed to compare testing facilities such as EDC+VC and Fiware using common, stack-agnostic test definitions and stack-specific result files. - -For KPI1, the same evidence-based logic can be reused, but with a different purpose: - -- focus on the **EMDS final / integrated stack**, not on comparing alternative stacks; -- assess **integration readiness**, not only isolated component availability; -- distinguish between **UC validation** and **technical validation**; -- distinguish between **CaaS**, **on-premise** and **mixed** installation models; -- keep the historical EDC+VC and Fiware results unchanged. - -## Proposed result perspective - -A new result perspective should be added to selected existing tests: - -```text -EMDS Final Stack -``` - -This perspective should be documented as a new result file next to the historical EDC+VC and Fiware results, for example: - -```text -tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md -``` - -This does not replace the historical results. It adds a new baseline view for the current EMDS integrated infrastructure. - -## Scope of KPI1 - -The KPI1 baseline should focus on a limited set of integration areas: - -| KPI1 area | Main purpose | -|---|---| -| Participant onboarding and identity | Validate whether participants can be onboarded and represented in the trust framework | -| Connector and data plane | Validate whether the connector and data transfer mechanisms are available and usable | -| Catalogue and metadata | Validate whether data offers can be published, discovered and described with appropriate metadata | -| Sharing agreement and negotiation | Validate whether agreement flows can be initiated and traced | -| Data sharing and transfer | Validate whether test or real data payloads can be transferred | -| Observability and logging | Validate whether failures, transactions and component health can be monitored | -| Security and access control | Validate whether authentication, authorization and policy mechanisms are applied | -| Blockers and support needs | Track unresolved dependencies, ownership and next actions | - -## Assessment levels - -KPI1 should not be completed only by use cases or only by technical teams. It should combine two complementary levels. - -| Level | Completed by | Purpose | -|---|---|---| -| UC validation | Use case technical experts / tech buddies | Validate whether the use case can use the stack in practice | -| Technical validation | Component owners / infrastructure teams | Validate whether the common building blocks are deployed, integrated, reliable and secured | - -The UC questionnaire should be treated as an operational input to KPI1, not as the KPI1 assessment itself. - -## Installation models - -The KPI1 baseline should explicitly distinguish the installation model used by each use case. - -| Installation model | Meaning | Main responsibility | -|---|---|---| -| CaaS | IONOS-managed deployment | IONOS and relevant component owners validate infrastructure, endpoints and operational evidence | -| On-premise | Deployment managed in the UC local environment | UC technical team validates infrastructure, network, firewall, DNS, certificates and local deployment | -| Mixed | Combination of CaaS and local/on-premise components | Shared responsibility between the UC team, IONOS and component owners | - -## ISO/IEC 25010 mapping - -The KPI1 baseline should not try to cover the complete ISO/IEC 25010 model. For the current integration monitoring purpose, the following quality characteristics are sufficient: - -| ISO/IEC 25010 characteristic | KPI1 interpretation | -|---|---| -| Functional suitability | The building block provides the required capability | -| Compatibility / interoperability | The building block integrates with related components and external participants | -| Reliability | The capability is stable, repeatable and observable enough to support testing | -| Security | Authentication, authorization, trust and policy controls are in place | -| Maintainability | Configuration, deployment, versioning and troubleshooting evidence are available | - -## Simplified scoring - -The baseline should reuse the 0–4 scoring principle from the existing technology testing results, but simplify the interpretation for integration readiness. - -| Score | Meaning for KPI1 | -|---:|---| -| 0 | Not available / not attempted / no evidence | -| 1 | Available conceptually or blocked | -| 2 | Deployed or in progress, but only partially tested | -| 3 | Working with evidence in a local or controlled context | -| 4 | Integrated with the common/federated infrastructure, secured, stable and repeatable | - -Scores of 3 or 4 should require supporting evidence such as an endpoint response, screenshot, GitHub/Jira issue, log, test execution result, deployment status, or confirmation from the relevant component owner. - -## Proposed dynamic tracker - -A shared Excel Online / SharePoint tracker can be used to connect the weekly WP2 questionnaire updates with KPI1 consolidation. - -Suggested tabs: - -| Tab | Purpose | -|---|---| -| Weekly UC questionnaire | Raw weekly responses from use cases and tech buddies | -| KPI1 mapping | Mapping between questionnaire questions, existing test IDs and KPI1 areas | -| KPI1 scoring | Consolidated score by week, UC, installation model, area and evidence | -| Blockers and actions | Blocker, owner, priority, status and next action | -| Dashboard | Pivot views by UC, component area, installation model and blocker owner | - -## Proposed minimum test set - -The initial KPI1 baseline should reuse a small subset of the existing deployEMDS tests, rather than creating a new test catalogue. - -| KPI1 area | Example existing test IDs | -|---|---| -| Participant onboarding and identity | 1.2.1.1, 1.3.1.5 | -| Connector and data plane | 2.1.1.3 | -| Policies and usage control | 2.1.3.1, 2.2.2.1 | -| Catalogue and metadata | 2.2.3.1A/B/D, 3.1.1.1, 3.1.1.4 | -| Sharing agreement and negotiation | 4.2.1.1, 4.2.1.6, 4.2.1.7, 4.2.3.1, 4.2.3.2 | -| Data sharing and transfer | 5.1.1.1, 5.1.1.2, 5.2.1.1 | - -## Proposed decision - -The WP2 questionnaire and KPI1 should be aligned through a common tracking format, but not fully merged conceptually. - -The questionnaire provides the weekly operational input from the use cases. KPI1 provides the consolidated assessment of maturity, reliability and security of the common technical infrastructure. - -The existing EDC+VC and Fiware results should remain as historical stack-comparison evidence. A new `EMDS Final Stack` result perspective should be added to selected tests to support the KPI1 integration baseline. diff --git a/web/docs/tech-testing/way-of-working.mdx b/web/docs/tech-testing/way-of-working.mdx index afabc67f..8f164c6d 100644 --- a/web/docs/tech-testing/way-of-working.mdx +++ b/web/docs/tech-testing/way-of-working.mdx @@ -1,13 +1,14 @@ --- -sidebar_position: 1 ---- + +## sidebar_position: 1 # Way of working ## Repository + The [**deployEMDS** GitHub repository](https://github.com/imec-int/deployEMDS) is the reference container of a thorough assessment of multiple data space technology stacks, more in detail: -* The technical implementations of the `test facilities`_(see infra)_ +* The technical implementations of the `test facilities` *(see infra)* * The test environment, where reference data sources, data schemas, vocabularies, and usage control policies are shared across all tests. * The tests and assessments, these are linked to the data space participants' customer journeys covering the essential data space capabilities. @@ -18,8 +19,7 @@ Each test facility develops tests adapted to the data space's technology. The te The test results can be found in the `tests/` directory of the repository, and have the following directory structure. This structure was used to implement comparative reviews to align the results of testing facilities. - -```. +```text |- Business capabilities (i.e. data_product_publication) | |-- Customer journeys (i.e. provision) | | |-- Sub-customer journeys (i.e. data_source_endpoint_provisioning) @@ -35,39 +35,83 @@ The test results can be found in the `tests/` directory of the repository, and h | | | | |-- resources-facility B (i.e. resources-fiware) ``` - ## Workflow + A **sandbox environment** is provided by IONOS to deploy data space stacks. SaaS providers must make sure that their services are accessible from this environment. -A **data space stack** is the combination of technical building blocks, and it might span over more than one framework (e.g., EDC + iShare). The choice of the stack is delegated to the EMDS Building Block Working Group. The deployment of the stack should result in a mock data space. +A **data space stack** is the combination of technical building blocks, and it might span over more than one framework, for example EDC + iShare. The choice of the stack is delegated to the EMDS Building Block Working Group. The deployment of the stack should result in a mock data space. + +The **testing facility** is the composition of infrastructure, data space stack, and test squad/team. We define one stack per test facility, and the mock data space should be consistent for each testing facility. They should have: + +* The same participants and their identities. +* The same data product(s) being shared. +* The same usage policies. +* The same data planes. +* The same root taxonomies and vocabularies describing the data product(s). +* The same certificate authority. -The **testing facility** is the composition of infrastructure, data space stack, and test squad (team). We define one stack per test facility, and the mock data space should be consistent for each testing facility. They should have: -- The same participants and their identities. -- The same data product(s) being shared. -- The same usage policies. -- The same data planes. -- The same root taxonomies and vocabularies describing the data product(s). -- The same certificate authority. +The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. -The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. -The progress of each testing facility will be tracked by use of reporting tools, _in casu_ the [GitHub issues](https://github.com/imec-int/deployEMDS/issues) of the GitHub repository. +The progress of each testing facility will be tracked by use of reporting tools, *in casu* the [GitHub issues](https://github.com/imec-int/deployEMDS/issues) of the GitHub repository. ![deployEMDS workflow](./assets/workflow_overview.png) ## Planning + The deployEMDS testing is planned to be executed in three phases: - 1. **Phase 1**: 2024-07-01 - 2024-07-19 - * _[Minimal](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aminimal)_: The minimal set of tests to be executed in each testing facility. - * _[Extended](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+-label%3Aminimal)_: The extended set of tests to be executed in each testing facility, should time allow. - 2. **Phase 2**: 2024-07-22 - 2024-08-09 - * _Minimal_: The minimal set of tests to be executed in each testing facility. - * _Extended_: The extended set of tests to be executed in each testing facility, should time allow. + +1. **Phase 1**: 2024-07-01 - 2024-07-19 + + * *[Minimal](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aminimal)*: The minimal set of tests to be executed in each testing facility. + * *[Extended](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+-label%3Aminimal)*: The extended set of tests to be executed in each testing facility, should time allow. + +2. **Phase 2**: 2024-07-22 - 2024-08-09 + + * *Minimal*: The minimal set of tests to be executed in each testing facility. + * *Extended*: The extended set of tests to be executed in each testing facility, should time allow. + +## Integration phase assessment + +Following the initial stack-comparison testing campaign, the existing deployEMDS technology testing catalogue may also be reused during the integration phase. + +The objective of this integration phase assessment is not to compare alternative testing facilities, but to assess the selected EMDS technical infrastructure and its readiness to support the expected data space capabilities. + +For this purpose, selected existing tests may include an additional result perspective: + +```text +EMDS Final Stack +``` + +This result perspective should be added next to the historical stack-specific result files. + +Example: + +```text +test.md +result_edc_vc.md +result_fiware.md +result_emds_final_stack.md +``` + +The existing test definition remains unchanged. The additional result file captures the assessment of the current EMDS final technical infrastructure using the same requirement structure and 0–4 scoring approach. + +The assessment should distinguish the deployment model used for the evidence collected: + +| Deployment model | Meaning | +| ---------------- | ----------------------------------------- | +| CaaS | IONOS-managed deployment | +| On-premise | Deployment managed in a local environment | + +The integration phase assessment should be supported by consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub/Jira references, deployment status or confirmation from the relevant component owner. + +This approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected EMDS technical infrastructure. ## Testing facilities + The following testing facilities are currently proposed: | Facility Name | Stack | Components available | Technical buddy | Test squad 1 | Test squad 2 | Status | -|-------------------|-----------------------------------------------------|------------------------------------------------------------|----------------------------------------|----------------|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| +| ----------------- | --------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------- | -------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | EDC+VC | EDC v0.7 with Verifiable Credentials | TBD | | imec | i2cat (ph 1), NTTDATA (ph 2) | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aedc%2Bvc+label%3Aminimal) | | Fiware | Fiware with Verifiable Credentials | TBD | Gernot (Fiware) | Fraunhofer | Cefriel | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Afiware+label%3Aminimal+) | | Pontus-X | Gaia-X compliant decentralized data economy toolbox | TBD | TBD | TBD | TBD | Interview had, seems interesting (?) | @@ -75,6 +119,7 @@ The following testing facilities are currently proposed: | ~~EDC+iShare~~ | ~~EDC v0.7 with iShare~~ | ~~TBD~~ | ~~Ferdinand (Fairsfair)~~ | ~~Fraunhofer~~ | ~~NTTDATA~~ | ~~Not developed~~ yet | | ~~Fiware+iShare~~ | ~~i4Trust~~ | ~~TBD~~ | ~~Gernot (Fiware)~~ | ~~imec~~ | ~~Cefriel~~ | ~~Deprecated, will not test~~ | | ~~EDC+XFSC~~ | ~~EDC v0.7 with some XFSC components~~ | ~~Catalog, identity provider, wallet from XFSC (Eclipse)~~ | ~~Christoph Lange-Bever (Fraunhofer)~~ | ~~TBD~~ | ~~TBD~~ | ~~Info session completed, difficult deployment and lower maturity~~ | + * **Technical buddies** are either commercial providers or experienced partners who help deploying the stacks. -* The **Test squads** are deployEMDS WP2 workgroup _"Building blocks"_ partners that are responsible for phase 0 and phase 1. -* Please notice: any secret keys have been intentionally redacted and will need to be replaced by user-provided keys to ensure functionality. \ No newline at end of file +* The **Test squads** are deployEMDS WP2 workgroup *"Building blocks"* partners that are responsible for phase 0 and phase 1. +* Please notice: any secret keys have been intentionally redacted and will need to be replaced by user-provided keys to ensure functionality. From 4d97e787004eb993bbd884981f2d101ad66fb834 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 13:27:36 -0700 Subject: [PATCH 4/8] Replace Jira reference with GitHub evidence --- web/docs/tech-testing/way-of-working.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/web/docs/tech-testing/way-of-working.mdx b/web/docs/tech-testing/way-of-working.mdx index 8f164c6d..297392e9 100644 --- a/web/docs/tech-testing/way-of-working.mdx +++ b/web/docs/tech-testing/way-of-working.mdx @@ -1,6 +1,6 @@ --- - -## sidebar_position: 1 +sidebar_position: 1 +--- # Way of working @@ -102,7 +102,7 @@ The assessment should distinguish the deployment model used for the evidence col | CaaS | IONOS-managed deployment | | On-premise | Deployment managed in a local environment | -The integration phase assessment should be supported by consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub/Jira references, deployment status or confirmation from the relevant component owner. +The integration phase assessment should be supported by consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub references, deployment status or confirmation from the relevant component owner. This approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected EMDS technical infrastructure. From 166a871cf294253474be09d770755013014d0eb2 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 14:13:13 -0700 Subject: [PATCH 5/8] Add EMDS Final Stack integration test overview --- README.md | 260 ++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 165 insertions(+), 95 deletions(-) diff --git a/README.md b/README.md index 5cdfd574..e52fbc20 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,17 @@ -deployEMDS -======== +# deployEMDS + ### deployEMDS empowers interoperable, trustworthy and accessible data sharing -[deployEMDS](https://deployemds.eu/) is a project co-funded under the [EU Digital Europe Programme](https://digital-strategy.ec.europa.eu/en/activities/digital-programme) and responds to its outlined challenges. The project will help make the common European mobility data space a reality.  The initiative will cultivate a broad European ecosystem of data providers and users, facilitating the adoption of common building blocks. 16 use cases from nine EU countries will contribute to the development of innovative services and applications. +[deployEMDS](https://deployemds.eu/) is a project co-funded under the [EU Digital Europe Programme](https://digital-strategy.ec.europa.eu/en/activities/digital-programme) and responds to its outlined challenges. The project will help make the common European mobility data space a reality. The initiative will cultivate a broad European ecosystem of data providers and users, facilitating the adoption of common building blocks. 16 use cases from nine EU countries will contribute to the development of innovative services and applications. The European mobility data space (EMDS) will offer a framework for interlinking and federating ecosystems. deployEMDS supports the EMDS initiative through: + * **Data interoperability:** Sharing and exchaging data in a standardised way * **Data sovereignty and trust:** Retaining authority and control over data * **Accessibility:** Discoverability and availability of mobility data -The project supports real-life implementations in nine cities and regions: +The project supports real-life implementations in nine cities and regions: + * Barcelona (ES) * Île-de-France (FR) * Milan (IT) @@ -22,11 +24,11 @@ The project supports real-life implementations in nine cities and regions: These initiatives focus on the development of innovative services and applications in urban mobility, while assisting in policymaking through the sharing and reuse of data. -The repository -============== +# The repository + The **deployEMDS** repository is the reference container of a thorough assessment of multiple data space technology stacks, more in detail: -* The technical implementations of the `test facilities`_(see infra)_ +* The technical implementations of the `test facilities`*(see infra)* * The test environment, where reference data sources, data schemas, vocabularies, and usage control policies are shared across all tests. * The tests and assessments, these are linked to the data space participants' customer journeys covering the essential data space capabilities. @@ -35,119 +37,187 @@ For instance: EDC using verifiable credentials, EDC using iShare, Fiware, ... Each test facility develops tests adapted to the data space's technology. The test definitions are data space stack-agnostic, while the test implementations are specific to the facility. Tests must produce the same expected outcome, but no assumption is made on approaches and technology. -The workflow -============ +# The workflow + A **sandbox environment** is provided by IONOS to deploy data space stacks. SaaS providers must make sure that their services are accessible from this environment. -A **data space stack** is the combination of technical building blocks, and it might span over more than one framework (e.g., EDC + iShare). The choice of the stack is delegated to the EMDS Building Block Working Group. The deployment of the stack should result in a mock data space. +A **data space stack** is the combination of technical building blocks, and it might span over more than one framework (e.g., EDC + iShare). The choice of the stack is delegated to the EMDS Building Block Working Group. The deployment of the stack should result in a mock data space. + +The **testing facility** is the composition of infrastructure, data space stack, and test squad (team). We define one stack per test facility, and the mock data space should be consistent for each testing facility. They should have: -The **testing facility** is the composition of infrastructure, data space stack, and test squad (team). We define one stack per test facility, and the mock data space should be consistent for each testing facility. They should have: -- The same participants and their identities. -- The same data product(s) being shared. -- The same usage policies. -- The same data planes. -- The same root taxonomies and vocabularies describing the data product(s). -- The same certificate authority. +* The same participants and their identities. +* The same data product(s) being shared. +* The same usage policies. +* The same data planes. +* The same root taxonomies and vocabularies describing the data product(s). +* The same certificate authority. -The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. -The progress of each testing facility will be tracked by use of reporting tools, _in casu_ the [GitHub issues](https://github.com/imec-int/deployEMDS/issues) of this repository. +The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. +The progress of each testing facility will be tracked by use of reporting tools, *in casu* the [GitHub issues](https://github.com/imec-int/deployEMDS/issues) of this repository. ![deployEMDS workflow](./static/workflow_overview.png) -Planning -======== +# Planning + The deployEMDS testing is planned to be executed in three phases: - 1. **Phase 1**: 2024-07-01 - 2024-07-19 - 1. _[Minimal](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aminimal)_: The minimal set of tests to be executed in each testing facility. - 2. _[Extended](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+-label%3Aminimal)_: The extended set of tests to be executed in each testing facility, should time allow. - 2. **Phase 2**: 2024-07-22 - 2024-08-09 - * _Minimal_: The minimal set of tests to be executed in each testing facility. - * _Extended_: The extended set of tests to be executed in each testing facility, should time allow. -Testing facilities -================== +1. **Phase 1**: 2024-07-01 - 2024-07-19 + + 1. *[Minimal](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aminimal)*: The minimal set of tests to be executed in each testing facility. + 2. *[Extended](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+-label%3Aminimal)*: The extended set of tests to be executed in each testing facility, should time allow. +2. **Phase 2**: 2024-07-22 - 2024-08-09 + + * *Minimal*: The minimal set of tests to be executed in each testing facility. + * *Extended*: The extended set of tests to be executed in each testing facility, should time allow. + +# Testing facilities The following testing facilities are currently proposed: -| Facility Name | Stack | Components available | Technical buddy | Test squad 1 | Test squad 2 | Status -|-------------------|--------------------------------------|--------------------------------------------------------|----------------------------------------|--------------|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| EDC+VC | EDC v0.7 with Verifiable Credentials | TBD | | imec | i2cat (ph 1), NTTDATA (ph 2) | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aedc%2Bvc+label%3Aminimal) | -| Fiware | Fiware with Verifiable Credentials | TBD | Gernot (Fiware) | Fraunhofer | Cefriel | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Afiware+label%3Aminimal+) | -| Pontus-X | Gaia-X compliant decentralized data economy toolbox | TBD | TBD | TBD | TBD | Interview had, seems interesting (?) | -| ~~EDC+Gaia-X~~ | ~~EDC v0.7 with Gaia-X~~ | ~~TBD~~ | ~~Jonathan (Eona-X)~~ | ~~NTTDATA~~ | ~~i2cat (ph 1), imec (ph 2)~~ | ~~Info session completed, not a lot of useful components ready right now~~ | -| ~~EDC+iShare~~ | ~~EDC v0.7 with iShare~~ |~~TBD~~ | ~~Ferdinand (Fairsfair)~~ | ~~Fraunhofer~~ | ~~NTTDATA~~ | ~~Not developed~~ yet | -| ~~Fiware+iShare~~ | ~~i4Trust~~ | ~~TBD~~ | ~~Gernot (Fiware)~~ | ~~imec~~ | ~~Cefriel~~ | ~~Deprecated, will not test~~ | -| ~~EDC+XFSC~~ | ~~EDC v0.7 with some XFSC components~~ | ~~Catalog, identity provider, wallet from XFSC (Eclipse)~~ | ~~Christoph Lange-Bever (Fraunhofer)~~ | ~~TBD~~ | ~~TBD~~ | ~~Info session completed, difficult deployment and lower maturity~~ | +| Facility Name | Stack | Components available | Technical buddy | Test squad 1 | Test squad 2 | Status | +| ----------------- | --------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------- | -------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | +| EDC+VC | EDC v0.7 with Verifiable Credentials | TBD | | imec | i2cat (ph 1), NTTDATA (ph 2) | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Aedc%2Bvc+label%3Aminimal) | +| Fiware | Fiware with Verifiable Credentials | TBD | Gernot (Fiware) | Fraunhofer | Cefriel | [Ready to start](https://github.com/imec-int/deployEMDS/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Phase+1%22+label%3Afiware+label%3Aminimal+) | +| Pontus-X | Gaia-X compliant decentralized data economy toolbox | TBD | TBD | TBD | TBD | Interview had, seems interesting (?) | +| ~~EDC+Gaia-X~~ | ~~EDC v0.7 with Gaia-X~~ | ~~TBD~~ | ~~Jonathan (Eona-X)~~ | ~~NTTDATA~~ | ~~i2cat (ph 1), imec (ph 2)~~ | ~~Info session completed, not a lot of useful components ready right now~~ | +| ~~EDC+iShare~~ | ~~EDC v0.7 with iShare~~ | ~~TBD~~ | ~~Ferdinand (Fairsfair)~~ | ~~Fraunhofer~~ | ~~NTTDATA~~ | ~~Not developed~~ yet | +| ~~Fiware+iShare~~ | ~~i4Trust~~ | ~~TBD~~ | ~~Gernot (Fiware)~~ | ~~imec~~ | ~~Cefriel~~ | ~~Deprecated, will not test~~ | +| ~~EDC+XFSC~~ | ~~EDC v0.7 with some XFSC components~~ | ~~Catalog, identity provider, wallet from XFSC (Eclipse)~~ | ~~Christoph Lange-Bever (Fraunhofer)~~ | ~~TBD~~ | ~~TBD~~ | ~~Info session completed, difficult deployment and lower maturity~~ | + * **Technical buddies** are either commercial providers or experienced partners who help deploying the stacks. -* The **Test squads** are deployEMDS WP2 workgroup _"Building blocks"_ partners that are responsible for phase 0 and phase 1. +* The **Test squads** are deployEMDS WP2 workgroup *"Building blocks"* partners that are responsible for phase 0 and phase 1. + +# Integration phase assessment + +Following the initial stack-comparison testing campaign, the existing deployEMDS technology testing catalogue may also be reused during the integration phase. + +The objective of this integration phase assessment is not to compare alternative testing facilities, but to assess the selected EMDS technical infrastructure and its readiness to support the expected data space capabilities. + +For this purpose, selected existing tests may include an additional result perspective named `emds_final_stack`. This result perspective is added next to the historical stack-specific result files, while keeping the existing test definitions unchanged. + +Example: +* `test.md` +* `result_edc_vc.md` +* `result_fiware.md` +* `result_emds_final_stack.md` + +The assessment should distinguish the deployment model used for the evidence collected: + +| Deployment model | Meaning | +| ---------------- | ----------------------------------------- | +| CaaS | IONOS-managed deployment | +| On-premise | Deployment managed in a local environment | + +The integration phase assessment should be supported by 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 approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected EMDS technical infrastructure. + +# Integration phase test overview + +This gives a quick view of the existing deployEMDS tests proposed for the EMDS Final Stack integration phase assessment. + +The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an `emds_final_stack` result file when the corresponding assessment evidence is available. + + + +Last updated: TBD + +| Test | Title | Phase | Minimal | Results | +| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | --------------------------------------------------------------------------------------------------------------------------------- | +| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | +| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | Integration | Yes | emds_final_stack pending | +| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | Integration | Yes | emds_final_stack pending | +| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | Integration | Yes | emds_final_stack pending | +| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | Integration | Yes | emds_final_stack pending | +| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | Integration | Yes | emds_final_stack pending | +| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | Integration | Yes | emds_final_stack pending | +| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | Integration | Yes | emds_final_stack pending | +| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | Integration | Yes | emds_final_stack pending | +| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | Integration | Yes | emds_final_stack pending | +| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | Integration | Yes | emds_final_stack pending | +| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | Integration | Yes | emds_final_stack pending | +| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md) | +| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | Integration | Yes | emds_final_stack pending | +| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | + + + +`emds_final_stack pending` indicates that the EMDS Final Stack assessment is still being consolidated. Once the evidence for a test is available, the corresponding result should be documented in a `result_emds_final_stack.md` file next to the existing historical result files. + +# Test overview -Test overview -============= This gives a quick view of the tests from Phase 1 and Phase 2 that were deemed crucial for a Minimum Viable Data Space. + Last updated: 2024-09-06 13:16:10 UTC -| Test | Title | Phase | Minimal | Results | -|------|-------|-------|---------|---------| -| [1.1.1.1] | [Participant onboarding: Registration - Gather information](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_edc_vc.md) ❌
| -| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_edc_vc.md) ✅
| -| [1.2.2.1] | [Participant onboarding: Evaluation - Proof of identity](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_edc_vc.md) ✅
| -| [1.3.1.1A] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_edc_vc.md) ✅
| -| [1.3.1.1B] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_edc_vc.md) ❌
| -| [1.3.1.1C] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_edc_vc.md) ❌
| -| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_edc_vc.md) ✅
| -| [2.1.1.1] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_edc_vc.md) ❌
| -| [2.1.1.2] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_edc_vc.md) ❌
| -| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_edc_vc.md) ✅
| -| [2.1.1.4] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_edc_vc.md) ❌
| -| [2.1.1.5] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_edc_vc.md) ❌
| -| [2.1.1.6] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_edc_vc.md) ❌
| -| [2.1.1.7] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_edc_vc.md) ❌
| -| [2.1.2.1] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_edc_vc.md) ❌
| -| [2.1.2.2] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_edc_vc.md) ❌
| -| [2.1.2.4] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_edc_vc.md) ❌
| -| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_edc_vc.md) ✅
| -| [2.1.3.2] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_edc_vc.md) ✅
| -| [2.1.3.3] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_edc_vc.md) ❌
| -| [2.1.3.4] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_edc_vc.md) ❌
| -| [2.2.1.3] | [Data product publication: Publication - Data product offering submittal](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_edc_vc.md) ✅
| -| [2.2.2.10] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_edc_vc.md) ✅
| -| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_edc_vc.md) ✅
| -| [2.2.2.4] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_edc_vc.md) ✅
| -| [2.2.2.5] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_edc_vc.md) ❌
| -| [2.2.2.6] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_edc_vc.md) ❌
| -| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_edc_vc.md) ✅
| -| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_edc_vc.md) ✅
| -| [2.2.3.1C] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_edc_vc.md) ✅
| -| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_edc_vc.md) ✅
| -| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_edc_vc.md) ✅
| -| [2.2.3.4] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_edc_vc.md) ✅
| -| [2.2.4.1] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_edc_vc.md) ❌
| -| [2.2.4.2] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_edc_vc.md) ❌
| -| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_edc_vc.md) ✅
| -| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_edc_vc.md) ✅
| -| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_edc_vc.md) ✅
| -| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_edc_vc.md) ✅
| -| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_edc_vc.md) ✅
| -| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_edc_vc.md) ✅
| -| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_edc_vc.md) ✅
| -| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_edc_vc.md) ✅
| -| [4.3.2.1] | [Sharing agreement: Agreement management - Rating & billing](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_edc_vc.md) ❌
| -| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_edc_vc.md) ✅
| -| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_edc_vc.md) ❌
| -| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_edc_vc.md) ✅
| -| [5.3.3.1] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_edc_vc.md) ❌
| -| [5.3.3.2] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_edc_vc.md) ❌
| +| Test | Title | Phase | Minimal | Results | +| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [1.1.1.1] | [Participant onboarding: Registration - Gather information](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_edc_vc.md) ❌
| +| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_edc_vc.md) ✅
| +| [1.2.2.1] | [Participant onboarding: Evaluation - Proof of identity](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_edc_vc.md) ✅
| +| [1.3.1.1A] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_edc_vc.md) ✅
| +| [1.3.1.1B] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_edc_vc.md) ❌
| +| [1.3.1.1C] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_edc_vc.md) ❌
| +| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_edc_vc.md) ✅
| +| [2.1.1.1] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_edc_vc.md) ❌
| +| [2.1.1.2] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_edc_vc.md) ❌
| +| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_edc_vc.md) ✅
| +| [2.1.1.4] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_edc_vc.md) ❌
| +| [2.1.1.5] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_edc_vc.md) ❌
| +| [2.1.1.6] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_edc_vc.md) ❌
| +| [2.1.1.7] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_edc_vc.md) ❌
| +| [2.1.2.1] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_edc_vc.md) ❌
| +| [2.1.2.2] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_edc_vc.md) ❌
| +| [2.1.2.4] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_edc_vc.md) ❌
| +| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_edc_vc.md) ✅
| +| [2.1.3.2] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_edc_vc.md) ✅
| +| [2.1.3.3] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_edc_vc.md) ❌
| +| [2.1.3.4] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_edc_vc.md) ❌
| +| [2.2.1.3] | [Data product publication: Publication - Data product offering submittal](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_edc_vc.md) ✅
| +| [2.2.2.10] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_edc_vc.md) ✅
| +| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_edc_vc.md) ✅
| +| [2.2.2.4] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_edc_vc.md) ✅
| +| [2.2.2.5] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_edc_vc.md) ❌
| +| [2.2.2.6] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_edc_vc.md) ❌
| +| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_edc_vc.md) ✅
| +| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_edc_vc.md) ✅
| +| [2.2.3.1C] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_edc_vc.md) ✅
| +| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_edc_vc.md) ✅
| +| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_edc_vc.md) ✅
| +| [2.2.3.4] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_edc_vc.md) ✅
| +| [2.2.4.1] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_edc_vc.md) ❌
| +| [2.2.4.2] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_edc_vc.md) ❌
| +| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_edc_vc.md) ✅
| +| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_edc_vc.md) ✅
| +| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_edc_vc.md) ✅
| +| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_edc_vc.md) ✅
| +| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_edc_vc.md) ✅
| +| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_edc_vc.md) ✅
| +| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_edc_vc.md) ✅
| +| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_edc_vc.md) ✅
| +| [4.3.2.1] | [Sharing agreement: Agreement management - Rating & billing](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_edc_vc.md) ❌
| +| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_edc_vc.md) ✅
| +| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_edc_vc.md) ❌
| +| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_edc_vc.md) ✅
| +| [5.3.3.1] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_edc_vc.md) ❌
| +| [5.3.3.2] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_edc_vc.md) ❌
| + -Information security -==================== +# Information security + GitHub may be utilized for version control; however, code should be treated as an information asset. Prior to publication, all code must undergo a thorough assessment in addition to standard code review procedures. This assessment aims to prevent the unintended disclosure of sensitive information, such as credentials, to the repository. In accordance with the [deployEMDS Information Security Policy](https://acatechev.sharepoint.de/:b:/r/sites/EuropeanMobilityDataSpaceDeploymentConsortiumspace/Freigegebene%20Dokumente/General/07_Security%20Policy/2024-02-16%20Information%20security%20policy_DeployEMDS_V1.5_CLEAN.pdf?csf=1&web=1&e=SwIPb1), section 7.1 "Information asset protection responsibility," we are required to evaluate all information assets used or created during the project. This evaluation should adhere to the checklist provided in the risk assessment template (Annex 1, pp. 15) . The Security Advisory Board (SAB) and Project Security Officer (PSO) should only be consulted if information security concerns arise, such as when any question on the checklist is answered affirmatively. This process ensures compliance with our security protocols and safeguards the intellectual property and sensitive information. -Please note: secret keys have been redacted in this repository and must be replaced with user-provided keys to ensure functionality. \ No newline at end of file +Please note: secret keys have been redacted in this repository and must be replaced with user-provided keys to ensure functionality. From 1d689a52a052aa25b63e1a594566e1772c74e757 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Thu, 18 Jun 2026 14:37:16 -0700 Subject: [PATCH 6/8] Clarify EMDS Final Stack deployment assessment template --- .../test_5_1_1_1/result_emds_final_stack.md | 87 +++++++++++-------- 1 file changed, 51 insertions(+), 36 deletions(-) diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md index d0a44094..ef32f81b 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md @@ -6,68 +6,83 @@ #### Environment -- Assessment context: Integration phase assessment of the EMDS final technical infrastructure. -- Deployment model: TBD - - CaaS / IONOS-managed deployment - - On-premise deployment -- Target environment: TBD -- EDC version / release: TBD -- Connector deployment reference: TBD -- Assessment evidence: TBD +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +The assessment is expected to 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. + +| Field | Value | Guidance | +| ------------------------------ | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | Indicates that this result belongs to the integration phase and not to the original Phase 1 / Phase 2 stack-comparison campaign. | +| Result perspective | `emds_final_stack` | Identifies this file as the EMDS Final Stack result perspective for the existing test definition. | +| Stack under assessment | EMDS Final Stack (EDC-based) | Indicates that the selected EMDS technical infrastructure is being assessed. | +| Deployment model assessed | TBD | Specify the deployment model actually used to collect evidence. Usually this will be either CaaS / IONOS-managed deployment or on-premise deployment. | +| Target environment | TBD | Specify the concrete environment used for the assessment, for example the IONOS Kubernetes cluster, namespace, local environment or other deployment target. | +| EDC version / release | TBD | Specify the EDC version, release, image tag or commit used in the assessed deployment, if available. | +| Connector deployment reference | TBD | Reference the deployed connector version, image, Helm chart, Docker Compose setup, GitHub commit, release or other deployment artefact used for the assessment. | +| Assessment evidence | TBD | Reference the evidence used to support the assessment, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner. | + +The deployment model should be completed using the option that matches the available evidence: + +| Deployment model | When to use it | +| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | +| CaaS / IONOS-managed deployment | Use this when the assessment evidence comes from the EMDS infrastructure deployed or managed in the IONOS environment. | +| On-premise deployment | Use this when the assessment evidence comes from a locally managed or partner-managed deployment. | + +If only one deployment model is assessed, the other one should be marked as `Not assessed`. This is acceptable as long as the result clearly states which deployment model was used for the assessment. #### Tested quality metric and method The quality metric for this test is based on the criteria outlined in [iso27001_kpis_subkpis.xlsx](../../../../../design_decisions/background_info/iso27001_kpis_subkpis.xlsx). For detailed information, please refer to the [Comparative criteria (checklists, ...)](./test.md#comparative-criteria-checklists-) section in the test description. -This result does not belong to the original deployEMDS Phase 1 / Phase 2 testing campaign used for the initial stack comparison. Instead, it reuses the existing test definition to assess the EMDS final technical infrastructure during the integration phase. +This result does not belong to the original deployEMDS Phase 1 / Phase 2 testing campaign used for the initial stack comparison. Instead, it reuses the existing test definition to assess the selected EMDS technical infrastructure during the integration phase. For the EMDS Final Stack, the assessment focuses on whether the current EDC-based infrastructure provides a documented, secured and testable mechanism to initiate and manage data transfer requests. +The existing test definition remains unchanged. This result file adds an EMDS Final Stack perspective next to the historical stack-specific result files, such as `result_edc_vc.md` and `result_fiware.md`. + #### Expected Output The test aims to provide a comprehensive evaluation of the following aspects: -- **Assess the availability of the API:** Ensure that the API or equivalent transfer mechanism is accessible and functional in the EMDS Final Stack. -- **Test data sharing requests:** Verify that data sharing requests are correctly processed, covering these steps: - - Initiating a data sharing request. - - Retrieving information and status of the data sharing request. - - Receiving the outcome of the data sharing request, including conditions. - - Accessing information on past data sharing activities. -- **Assess deployment-specific evidence:** Indicate whether the assessment was performed in a CaaS or on-premise deployment. +* **Assess the availability of the transfer mechanism:** Ensure that the API or equivalent transfer mechanism is accessible and functional in the EMDS Final Stack. +* **Test data sharing requests:** Verify that data sharing requests are correctly processed, covering these steps: -The system will score higher if the API is secured, implements common methods such as REST, and can be validated with repeatable technical evidence in the selected deployment model. + * Initiating a data sharing request. + * Retrieving information and status of the data sharing request. + * Receiving the outcome of the data sharing request, including conditions. + * Accessing information on past data sharing activities. +* **Assess deployment-specific evidence:** Indicate which deployment model was actually assessed, either CaaS / IONOS-managed deployment or on-premise deployment. +* **Assess repeatability:** Ensure that the assessment can be supported by repeatable 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. + +The system will score higher if the transfer mechanism is secured, implements common methods such as REST where applicable, and can be validated with repeatable technical evidence in the selected deployment model. ### Results #### Assessment -TBD. +Pending. The assessment should be completed once consolidated evidence is available for the EMDS Final Stack deployment. -The result should indicate whether the score applies to: - -- CaaS / IONOS-managed deployment; -- on-premise deployment; -- or both deployment models. +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 | TBD | -| On-premise deployment | TBD | TBD | TBD | +| 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 -| Requirement | Measured KPI | Evidence | Notes | -|---|---:|---|---| -| Initiate a data sharing request | TBD | TBD | Pending assessment based on execution evidence from the selected deployment model. | -| Retrieve data sharing information and status | TBD | TBD | Pending assessment based on evidence of transfer process status retrieval. | -| Receive data sharing request outcome condition | TBD | TBD | Pending assessment based on evidence that the transfer request outcome can be retrieved and interpreted. | -| Retrieve data sharing information of past data sharing actions | TBD | TBD | Pending assessment based on evidence of traceability or access to previous transfer actions. | +| Requirement | Measured KPI | Evidence | Notes | +| -------------------------------------------------------------- | -----------: | -------- | -------------------------------------------------------------------------------------------------------- | +| Initiate a data sharing request | TBD | TBD | Pending assessment based on execution evidence from the selected deployment model. | +| Retrieve data sharing information and status | TBD | TBD | Pending assessment based on evidence of transfer process status retrieval. | +| Receive data sharing request outcome condition | TBD | TBD | Pending assessment based on evidence that the transfer request outcome can be retrieved and interpreted. | +| Retrieve data sharing information of past data sharing actions | TBD | TBD | Pending assessment based on evidence of traceability or access to previous transfer actions. | -**Overall Calculation:** TBD +**Overall Calculation:** TBD **Functional Suitability Quality Metric Score:** TBD #### Notes @@ -76,6 +91,6 @@ This result introduces an **EMDS Final Stack** perspective for the existing test This result should not be interpreted as part of the original Phase 1 / Phase 2 testing 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/Jira references, deployment status or confirmation from the relevant component owner. +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. -If the test is executed in both CaaS and on-premise environments, the result should clearly indicate whether the score applies to one deployment model or to both. \ No newline at end of file +If the test is executed in only one deployment model, the result should clearly indicate which deployment model was assessed. The other deployment model may remain marked as `Not assessed`. If evidence is later collected for the second deployment model, this result file may be updated accordingly. From 62034c8615429652cfbfa030b732f5f503c7c505 Mon Sep 17 00:00:00 2001 From: dmorperd Date: Tue, 23 Jun 2026 20:59:34 +0200 Subject: [PATCH 7/8] Add EMDS Final Stack result files for KPI1 tests --- README.md | 170 +++++++++--------- .../test_2_1_1_3/result_emds_final_stack.md | 93 ++++++++++ .../test_2_1_3_1/result_emds_final_stack.md | 98 ++++++++++ .../test_2_2_2_1/result_emds_final_stack.md | 85 +++++++++ .../test_2_2_3_1a/result_emds_final_stack.md | 86 +++++++++ .../test_2_2_3_1b/result_emds_final_stack.md | 86 +++++++++ .../test_2_2_3_1d/result_emds_final_stack.md | 85 +++++++++ .../test_2_2_3_3/result_emds_final_stack.md | 85 +++++++++ .../test_2_2_5_2/result_emds_final_stack.md | 82 +++++++++ .../test_2_2_5_7/result_emds_final_stack.md | 82 +++++++++ .../test_3_1_1_1/result_emds_final_stack.md | 87 +++++++++ .../test_3_1_1_4/result_emds_final_stack.md | 85 +++++++++ .../test_5_2_1_1/result_emds_final_stack.md | 93 ++++++++++ .../test_5_1_1_1/result_emds_final_stack.md | 101 ++++++----- .../test_5_1_1_2/result_emds_final_stack.md | 97 ++++++++++ .../test_1_3_1_5/result_emds_final_stack.md | 86 +++++++++ .../test_1_2_1_1/result_emds_final_stack.md | 85 +++++++++ .../test_4_2_1_1/result_emds_final_stack.md | 85 +++++++++ .../test_4_2_1_3/result_emds_final_stack.md | 93 ++++++++++ .../test_4_2_1_6/result_emds_final_stack.md | 85 +++++++++ .../test_4_2_1_7/result_emds_final_stack.md | 81 +++++++++ .../test_4_2_3_1/result_emds_final_stack.md | 85 +++++++++ .../test_4_2_3_2/result_emds_final_stack.md | 86 +++++++++ 23 files changed, 1968 insertions(+), 133 deletions(-) create mode 100644 tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md create mode 100644 tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md create mode 100644 tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md create mode 100644 tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md create mode 100644 tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md create mode 100644 tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md create mode 100644 tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md create mode 100644 tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md create mode 100644 tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md create mode 100644 tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md diff --git a/README.md b/README.md index e52fbc20..d662af44 100644 --- a/README.md +++ b/README.md @@ -2,11 +2,11 @@ ### deployEMDS empowers interoperable, trustworthy and accessible data sharing -[deployEMDS](https://deployemds.eu/) is a project co-funded under the [EU Digital Europe Programme](https://digital-strategy.ec.europa.eu/en/activities/digital-programme) and responds to its outlined challenges. The project will help make the common European mobility data space a reality. The initiative will cultivate a broad European ecosystem of data providers and users, facilitating the adoption of common building blocks. 16 use cases from nine EU countries will contribute to the development of innovative services and applications. +[deployEMDS](https://deployemds.eu/) is a project co-funded under the [EU Digital Europe Programme](https://digital-strategy.ec.europa.eu/en/activities/digital-programme) and responds to its outlined challenges. The project will help make the common European mobility data space a reality. The initiative will cultivate a broad European ecosystem of data providers and users, facilitating the adoption of common building blocks. 16 use cases from nine EU countries will contribute to the development of innovative services and applications. The European mobility data space (EMDS) will offer a framework for interlinking and federating ecosystems. deployEMDS supports the EMDS initiative through: -* **Data interoperability:** Sharing and exchaging data in a standardised way +* **Data interoperability:** Sharing and exchanging data in a standardised way * **Data sovereignty and trust:** Retaining authority and control over data * **Accessibility:** Discoverability and availability of mobility data @@ -28,7 +28,7 @@ These initiatives focus on the development of innovative services and applicatio The **deployEMDS** repository is the reference container of a thorough assessment of multiple data space technology stacks, more in detail: -* The technical implementations of the `test facilities`*(see infra)* +* The technical implementations of the `test facilities` *(see infra)* * The test environment, where reference data sources, data schemas, vocabularies, and usage control policies are shared across all tests. * The tests and assessments, these are linked to the data space participants' customer journeys covering the essential data space capabilities. @@ -52,7 +52,7 @@ The **testing facility** is the composition of infrastructure, data space stack, * The same root taxonomies and vocabularies describing the data product(s). * The same certificate authority. -The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. +The testing facilities will use a phased or agile approach, where in each phase specific components are deployed and tested. The progress of each testing facility will be tracked by use of reporting tools, *in casu* the [GitHub issues](https://github.com/imec-int/deployEMDS/issues) of this repository. ![deployEMDS workflow](./static/workflow_overview.png) @@ -104,10 +104,10 @@ Example: The assessment should distinguish the deployment model used for the evidence collected: -| Deployment model | Meaning | -| ---------------- | ----------------------------------------- | -| CaaS | IONOS-managed deployment | -| On-premise | Deployment managed in a local environment | +| Deployment model | Meaning | +| ------------------------------- | ------------------------------------------------------------ | +| CaaS / IONOS-managed deployment | Deployment managed in the IONOS environment | +| On-premise deployment | Deployment managed in a local or partner-managed environment | The integration phase assessment should be supported by 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. @@ -117,38 +117,40 @@ This approach keeps the historical EDC+VC and Fiware results unchanged while all This gives a quick view of the existing deployEMDS tests proposed for the EMDS Final Stack integration phase assessment. -The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an `emds_final_stack` result file when the corresponding assessment evidence is available. +The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an `emds_final_stack` result file to document the assessment of the selected EMDS Final Stack when the corresponding evidence is available. -Last updated: TBD - -| Test | Title | Phase | Minimal | Results | -| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | --------------------------------------------------------------------------------------------------------------------------------- | -| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | -| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | Integration | Yes | emds_final_stack pending | -| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | Integration | Yes | emds_final_stack pending | -| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | Integration | Yes | emds_final_stack pending | -| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | Integration | Yes | emds_final_stack pending | -| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | Integration | Yes | emds_final_stack pending | -| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | Integration | Yes | emds_final_stack pending | -| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | Integration | Yes | emds_final_stack pending | -| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | Integration | Yes | emds_final_stack pending | -| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | Integration | Yes | emds_final_stack pending | -| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | Integration | Yes | emds_final_stack pending | -| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | Integration | Yes | emds_final_stack pending | -| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md) | -| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | Integration | Yes | emds_final_stack pending | -| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | Integration | Yes | emds_final_stack pending | +Last updated: 2026-06-23 + +| Test | Title | Phase | Minimal | Results | +| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md) | +| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | Integration | Yes | [emds_final_stack pending](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md) | +| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md) | +| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md) | +| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md) | +| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md) | +| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md) | +| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md) | +| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md) | +| [2.2.5.2] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md) | +| [2.2.5.7] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md) | +| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md) | +| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md) | +| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md) | +| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md) | +| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md) | +| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md) | +| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md) | +| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md) | +| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md) | +| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md) | +| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md) | -`emds_final_stack pending` indicates that the EMDS Final Stack assessment is still being consolidated. Once the evidence for a test is available, the corresponding result should be documented in a `result_emds_final_stack.md` file next to the existing historical result files. +`emds_final_stack pending` indicates that the EMDS Final Stack assessment is still being consolidated. The linked `result_emds_final_stack.md` files provide the integration-phase result perspective for each selected test and should be completed once consolidated evidence is available. # Test overview @@ -160,55 +162,55 @@ Last updated: 2024-09-06 13:16:10 UTC | Test | Title | Phase | Minimal | Results | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [1.1.1.1] | [Participant onboarding: Registration - Gather information](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_edc_vc.md) ❌
| -| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_edc_vc.md) ✅
| -| [1.2.2.1] | [Participant onboarding: Evaluation - Proof of identity](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_edc_vc.md) ✅
| -| [1.3.1.1A] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_edc_vc.md) ✅
| -| [1.3.1.1B] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_edc_vc.md) ❌
| -| [1.3.1.1C] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_edc_vc.md) ❌
| -| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_edc_vc.md) ✅
| -| [2.1.1.1] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_edc_vc.md) ❌
| -| [2.1.1.2] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_edc_vc.md) ❌
| -| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_edc_vc.md) ✅
| -| [2.1.1.4] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_edc_vc.md) ❌
| -| [2.1.1.5] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_edc_vc.md) ❌
| -| [2.1.1.6] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_edc_vc.md) ❌
| -| [2.1.1.7] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_edc_vc.md) ❌
| -| [2.1.2.1] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_edc_vc.md) ❌
| -| [2.1.2.2] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_edc_vc.md) ❌
| -| [2.1.2.4] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_edc_vc.md) ❌
| -| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_edc_vc.md) ✅
| -| [2.1.3.2] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_edc_vc.md) ✅
| -| [2.1.3.3] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_edc_vc.md) ❌
| -| [2.1.3.4] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_edc_vc.md) ❌
| -| [2.2.1.3] | [Data product publication: Publication - Data product offering submittal](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_edc_vc.md) ✅
| -| [2.2.2.10] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_edc_vc.md) ✅
| -| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_edc_vc.md) ✅
| -| [2.2.2.4] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_edc_vc.md) ✅
| -| [2.2.2.5] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_edc_vc.md) ❌
| -| [2.2.2.6] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_edc_vc.md) ❌
| -| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_edc_vc.md) ✅
| -| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_edc_vc.md) ✅
| -| [2.2.3.1C] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_edc_vc.md) ✅
| -| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_edc_vc.md) ✅
| -| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_edc_vc.md) ✅
| -| [2.2.3.4] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_edc_vc.md) ✅
| -| [2.2.4.1] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_edc_vc.md) ❌
| -| [2.2.4.2] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_edc_vc.md) ❌
| -| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_edc_vc.md) ✅
| -| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_edc_vc.md) ✅
| -| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_edc_vc.md) ✅
| -| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_edc_vc.md) ✅
| -| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_edc_vc.md) ✅
| -| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_edc_vc.md) ✅
| -| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_edc_vc.md) ✅
| -| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_edc_vc.md) ✅
| -| [4.3.2.1] | [Sharing agreement: Agreement management - Rating & billing](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_edc_vc.md) ❌
| -| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_edc_vc.md) ✅
| -| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_edc_vc.md) ❌
| -| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_edc_vc.md) ✅
| -| [5.3.3.1] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_edc_vc.md) ❌
| -| [5.3.3.2] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_edc_vc.md) ❌
| +| [1.1.1.1] | [Participant onboarding: Registration - Gather information](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/registration/gather_information/test_1_1_1_1/result_edc_vc.md) ❌
| +| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_edc_vc.md) ✅
| +| [1.2.2.1] | [Participant onboarding: Evaluation - Proof of identity](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/evaluation/proof_of_identity/test_1_2_2_1/result_edc_vc.md) ✅
| +| [1.3.1.1A] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1a/result_edc_vc.md) ✅
| +| [1.3.1.1B] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1b/result_edc_vc.md) ❌
| +| [1.3.1.1C] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_1c/result_edc_vc.md) ❌
| +| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_edc_vc.md) ✅
| +| [2.1.1.1] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_1/result_edc_vc.md) ❌
| +| [2.1.1.2] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_2/result_edc_vc.md) ❌
| +| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_edc_vc.md) ✅
| +| [2.1.1.4] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_4/result_edc_vc.md) ❌
| +| [2.1.1.5] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_5/result_edc_vc.md) ❌
| +| [2.1.1.6] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_6/result_edc_vc.md) ❌
| +| [2.1.1.7] | [Data product publication: Provision - Data source endpoint provisioning](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_7/result_edc_vc.md) ❌
| +| [2.1.2.1] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_1/result_edc_vc.md) ❌
| +| [2.1.2.2] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_2/result_edc_vc.md) ❌
| +| [2.1.2.4] | [Data product publication: Provision - Submit vocabulary artifacts](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/submit_vocabulary_artifacts/test_2_1_2_4/result_edc_vc.md) ❌
| +| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_edc_vc.md) ✅
| +| [2.1.3.2] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_2/result_edc_vc.md) ✅
| +| [2.1.3.3] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_3/result_edc_vc.md) ❌
| +| [2.1.3.4] | [Data product publication: Provision - Reuse or create usage control policies / functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_4/result_edc_vc.md) ❌
| +| [2.2.1.3] | [Data product publication: Publication - Data product offering submittal](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/data_product_offering_submittal/test_2_2_1_3/result_edc_vc.md) ✅
| +| [2.2.2.10] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_10/result_edc_vc.md) ✅
| +| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_edc_vc.md) ✅
| +| [2.2.2.4] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_4/result_edc_vc.md) ✅
| +| [2.2.2.5] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_5/result_edc_vc.md) ❌
| +| [2.2.2.6] | [Data product publication: Publication - Deploy/config usage control functions](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_6/result_edc_vc.md) ❌
| +| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_edc_vc.md) ✅
| +| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_edc_vc.md) ✅
| +| [2.2.3.1C] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1c/result_edc_vc.md) ✅
| +| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_edc_vc.md) ✅
| +| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_edc_vc.md) ✅
| +| [2.2.3.4] | [Data product publication: Publication - Publication on EMDS catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_4/result_edc_vc.md) ✅
| +| [2.2.4.1] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_1/result_edc_vc.md) ❌
| +| [2.2.4.2] | [Data product publication: Publication - Publication on 3rd-party catalogues](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_publication/publication/publication_on_3rd-party_catalogues/test_2_2_4_2/result_edc_vc.md) ❌
| +| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_edc_vc.md) ✅
| +| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_edc_vc.md) ✅
| +| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_edc_vc.md) ✅
| +| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_edc_vc.md) ✅
| +| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_edc_vc.md) ✅
| +| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | 1 | No | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_edc_vc.md) ✅
| +| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_edc_vc.md) ✅
| +| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_edc_vc.md) ✅
| +| [4.3.2.1] | [Sharing agreement: Agreement management - Rating & billing](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/sharing_agreement/agreement_management/rating_&_billing/test_4_3_2_1/result_edc_vc.md) ❌
| +| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_edc_vc.md) ✅
| +| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_edc_vc.md) ❌
| +| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | 1 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_fiware.md) ✅
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_edc_vc.md) ✅
| +| [5.3.3.1] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_1/result_edc_vc.md) ❌
| +| [5.3.3.2] | [Data sharing: Post-sharing activities - Log data sharing transaction](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/test.md) | 2 | Yes | [fiware](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_fiware.md) ❌
[edc_vc](https://github.com/imec-int/deployEMDS/tree/main/tests/data_sharing/post-sharing_activities/log_data_sharing_transaction/test_5_3_3_2/result_edc_vc.md) ❌
| @@ -216,7 +218,7 @@ Last updated: 2024-09-06 13:16:10 UTC GitHub may be utilized for version control; however, code should be treated as an information asset. Prior to publication, all code must undergo a thorough assessment in addition to standard code review procedures. This assessment aims to prevent the unintended disclosure of sensitive information, such as credentials, to the repository. -In accordance with the [deployEMDS Information Security Policy](https://acatechev.sharepoint.de/:b:/r/sites/EuropeanMobilityDataSpaceDeploymentConsortiumspace/Freigegebene%20Dokumente/General/07_Security%20Policy/2024-02-16%20Information%20security%20policy_DeployEMDS_V1.5_CLEAN.pdf?csf=1&web=1&e=SwIPb1), section 7.1 "Information asset protection responsibility," we are required to evaluate all information assets used or created during the project. This evaluation should adhere to the checklist provided in the risk assessment template (Annex 1, pp. 15) . The Security Advisory Board (SAB) and Project Security Officer (PSO) should only be consulted if information security concerns arise, such as when any question on the checklist is answered affirmatively. +In accordance with the [deployEMDS Information Security Policy](https://acatechev.sharepoint.de/:b:/r/sites/EuropeanMobilityDataSpaceDeploymentConsortiumspace/Freigegebene%20Dokumente/General/07_Security%20Policy/2024-02-16%20Information%20security%20policy_DeployEMDS_V1.5_CLEAN.pdf?csf=1&web=1&e=SwIPb1), section 7.1 "Information asset protection responsibility," we are required to evaluate all information assets used or created during the project. This evaluation should adhere to the checklist provided in the risk assessment template (Annex 1, pp. 15). The Security Advisory Board (SAB) and Project Security Officer (PSO) should only be consulted if information security concerns arise, such as when any question on the checklist is answered affirmatively. This process ensures compliance with our security protocols and safeguards the intellectual property and sensitive information. diff --git a/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md new file mode 100644 index 00000000..5a744f8b --- /dev/null +++ b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md @@ -0,0 +1,93 @@ +## [2.1.1.3] Data product publication: Provision - Data source endpoint provisioning + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Connector and data planes | +| Existing test ID | `2.1.1.3` | +| Level | Technical | +| ISO/IEC 25010 mapping | Compatibility, Reliability | +| Owner (tentative) | Carlos (i2CAT) | +| Reviewer | Wilhelm | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assess the availability of multiple data planes that support multiple protocols. Refer to D2.1 for an overview of the most used protocols. The higher the coverage, the higher the ranking. + +#### Expected Output + +Evaluate the level of support for the following data formats + +- GTFS - [Public dataset](https://opendata-ajuntament.barcelona.cat/data/dataset/c46503e3-cec6-4032-894d-1063b7a365ee/resource/1c92542e-0346-4df5-9824-d7753ab02e33/download) with direct download via HTTPS +- GTFS-RT - [Public dataset](https://api.data.gov.my/gtfs-realtime/vehicle-position/ktmb/) via APIs +- DATEX-II - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs +- DATX II Light - No available datasets for this data format, tests are skipped +- GBFS - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs +- WMS/WFS - [Public dataset](https://openmaps.gov.bc.ca/geo/ows?SERVICE=WMS&REQUEST=GetCapabilities) via APIs + +Also access through APIs. +Access to private APIs is tested using the AMB mobilitat endpoint. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| **Criterion** | **Description** | **Score (0-4)** | **Explanation** | +|------------------------------|-----------------------------------------------------------------------------------------------------|-----------------|-------------| +| **Functional Completeness** | TBD | TBD | TBD | +| **Functional Correctness** | TBD | TBD | TBD | +| **Functional Appropriateness** | TBD | TBD | TBD | + +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.1.1.3` under the KPI1 area **Connector and data planes**. + +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. diff --git a/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md b/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md new file mode 100644 index 00000000..74b0ee9c --- /dev/null +++ b/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md @@ -0,0 +1,98 @@ +## [2.1.3.1] Data product publication: Provision - Reuse or create usage control policies / functions + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Policy management | +| Existing test ID | `2.1.3.1` | +| Level | Technical | +| ISO/IEC 25010 mapping | Security, Maintainability | +| Owner (tentative) | Xavier (Eurocat) | +| Reviewer | TBD | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assess how Usage Control Policies are deployed. Rank the result by API coverage and ease of use (i.e. avoiding multiple calls with parameter passing) by scoring the following actions + +1. Create a new policy +2. Assign a usage policy to a sharing agreement +3. Delete a sharing agreement +4. Delete a usage policy +5. Update existing sharing agreement +6. Update existing usage policy +7. Extend the usage policy language +7. Create new policy enforcement functions + +#### Expected Output + +See `test.md` for the complete expected output and comparative criteria for this test. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| Action | **Functional Completeness** | **Functional Correctness** | **Functional Appropriateness** | Explanation | +|----------------------------------------------|-----------------------------|----------------------------|--------------------------------|---------------------------------------------------------------| +| Create a new policy | TBD | TBD | TBD | TBD | +| Assign a usage policy to a sharing agreement | TBD | TBD | TBD | TBD | +| Delete a sharing agreement | TBD | TBD | TBD | TBD | +| Delete a usage policy | TBD | TBD | TBD | TBD | +| Update existing sharing agreement | TBD | TBD | TBD | TBD | +| Update existing policy | TBD | TBD | TBD | TBD | +| Extend the usage policy language | TBD | TBD | TBD | TBD | +| Create new policy enforcement functions | TBD | TBD | TBD | TBD | +| **Overall** | TBD | TBD | TBD | TBD | + +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.1.3.1` under the KPI1 area **Policy management**. + +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. diff --git a/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md new file mode 100644 index 00000000..0e3e685a --- /dev/null +++ b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [2.2.2.1] Data product publication: Publication - Deploy/config usage control functions + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Policy management | +| Existing test ID | `2.2.2.1` | +| Level | Technical | +| ISO/IEC 25010 mapping | Security, Maintainability | +| Owner (tentative) | Xavier (Eurocat) | +| Reviewer | TBD | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assess the completeness of the administrative interface (either API or GUI) so that it covers the most needed use cases for the deployment of usage policies: upload a new policy, (optional) bind a policy with a custom enforcement function, assign a policy to a sharing agreement, delete a policy, re-use an uploaded policy, persist uploaded policies. + +#### Expected Output + +See `test.md` for the complete expected output and comparative criteria for this test. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| **Assessment** | **Functional Completeness** | **Functional Correctness** | **Functional Appropriateness** | **Explanation** | +|-----------------------------|-----------------------------|----------------------------|---------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Upload a new policy | TBD | TBD | TBD | TBD | +| Re-use an uploaded policy | TBD | TBD | TBD | TBD | +| Persist uploaded policies | TBD | TBD | TBD | TBD | +| Delete a policy | TBD | TBD | TBD | TBD | +| **Overall** | TBD | TBD | TBD | TBD | + +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.2.1` under the KPI1 area **Policy management**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md new file mode 100644 index 00000000..46ed2258 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md @@ -0,0 +1,86 @@ +## [2.2.3.1A] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue publication | +| Existing test ID | `2.2.3.1A` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the process of catalogue publication for a data product under the following conditions: a new data product is published in the catalogue + +#### Expected Output + +The test aims to examine the process of catalog publication for a data product under the following conditions: a new data product is added to the catalog. The EMDS catalog, as defined in the relevant documentation, +refers to the Data Space-only catalog, specifically the internal EDC catalog and its federation component. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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:** No technical requirements are met. The solution fails to provide any functionality for the new data product in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for the new data product in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1A` under the KPI1 area **Catalogue publication**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md new file mode 100644 index 00000000..34058835 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md @@ -0,0 +1,86 @@ +## [2.2.3.1B] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue publication | +| Existing test ID | `2.2.3.1B` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the process of catalogue publication for a data product under the following conditions: an existing data product is published on the catalogue + +#### Expected Output + +Test the process of catalogue publication for a data product under the following conditions: an existing data product is published on the catalogue +The EMDS catalog, as defined in the relevant documentation, refers to the Data Space-only catalog, specifically the internal EDC catalog and its federation component. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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:** No technical requirements are met. The solution fails to provide any functionality for an existing data product published in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for an existing data product published in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1B` under the KPI1 area **Catalogue publication**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md new file mode 100644 index 00000000..d0588961 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [2.2.3.1D] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue publication | +| Existing test ID | `2.2.3.1D` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the process of catalogue publication for a data product under the following conditions: a data product is de-published. + +#### Expected Output + +The test aims to examine the process of catalog de-publication for a data product under the following conditions: a data product is removed (de-published) from the catalog. The EMDS catalog, as defined in the relevant documentation, refers to the Data Space-only catalog, specifically the internal EDC catalog and its federation component. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 does not provide any functionality for de-publishing a data product from the catalog. Users cannot remove or hide a data product once it is published, and achieving this requires extensive custom development or workarounds. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. It may offer basic de-publication functionality, but this is not fully operational out of the box and requires significant technical effort or development to implement. The process is cumbersome and not intuitive for end users. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. It allows for de-publishing of data products but requires some degree of customization or development to function correctly. Additionally, the process may be partially intuitive but could still pose challenges for end users in terms of usability. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. It provides effective de-publication functionality with minimal development required. The de-publication process is mostly intuitive and user-friendly, with only minor usability issues or adjustments needed. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all evaluation criteria. It offers complete, out-of-the-box functionality for de-publishing a data product, allowing users to easily remove or hide a data product from the catalog. The process is straightforward, intuitive, and requires no additional development or technical modifications. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1D` under the KPI1 area **Catalogue publication**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md new file mode 100644 index 00000000..fe0c7790 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [2.2.3.3] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue publication | +| Existing test ID | `2.2.3.3` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assess that a GUI for the functionality to publish a data product offering into the catalogue and discovery tools is available. + +#### Expected Output + +The test aims to verify the availability of a GUI for publishing a data product offering into the catalog and discovery tools. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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:** No technical requirements are met. The solution does not have a GUI tool for publishing a data product offering into the catalogue and enabling discovery. The system does not provide any GUI means for users to interact with or manage data product offerings. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. The solution provides limited functionality, such as a basic GUI tool with minimal features, allowing for partial publication of data products but lacks robust discovery options. User interface might be clunky, and only a few essential functions are available. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. The solution includes a GUI tool that allows for the publication of data products and some discovery features. However, it lacks advanced functionality, such as customizable search options, detailed metadata management, or integration with other systems. Usability and user experience are moderately acceptable. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. The solution offers a comprehensive GUI tool with most required features, such as advanced publication workflows, robust discovery capabilities, customizable search filters, and metadata management. Integration with other systems and platforms is partially supported, and the user experience is generally smooth. However, some advanced features or full system integration might still be lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution includes a fully featured GUI tool for publishing data product offerings into the catalogue, complete with advanced discovery features, customizable search options, detailed metadata management, and full integration with other systems. The user interface is intuitive and user-friendly, providing an excellent user experience. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.3` under the KPI1 area **Catalogue publication**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md new file mode 100644 index 00000000..6429e543 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md @@ -0,0 +1,82 @@ +## [2.2.5.2] Data product publication: Publication - Publication on federated data spaces + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Publication on federated data spaces | +| Existing test ID | `2.2.5.2` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Casper (Tentative) | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Give an existing data space, assess whether the system allows a federated data space can publish data product offerings on EMDS. More qualitative assessment comes in the KPIs that follow. + +#### Expected Output + +[TODO] Describe the expected output and how the ranking is calculated + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Overall Calculation:** TBD +**Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.5.2` under the KPI1 area **Publication on federated data spaces**. + +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. diff --git a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md new file mode 100644 index 00000000..c7176813 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md @@ -0,0 +1,82 @@ +## [2.2.5.7] Data product publication: Publication - Publication on federated data spaces + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Publication on federated data spaces | +| Existing test ID | `2.2.5.7` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Casper (Tentative) | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Does my product in a federated data space achieve equal visibility as native ones? + +#### Expected Output + +[TODO] Describe the expected output and how the ranking is calculated + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Overall Calculation:** TBD +**Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.5.7` under the KPI1 area **Publication on federated data spaces**. + +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. diff --git a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md new file mode 100644 index 00000000..e1e2c6b7 --- /dev/null +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md @@ -0,0 +1,87 @@ +## [3.1.1.1] Data product survey: Discover - Consult data space catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue discovery / metadata | +| Existing test ID | `3.1.1.1` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Carlos | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assessment: If an Online U/X is natively available, evaluate individual search features. If the Data space catalogue exposes an API, assess the technical debt to integrate it with a data search tool that is representative for EU projects. Criteria are: Open Source, hosted solution or EU-driven project. + +#### Expected Output + +The test aims to determine whether a native online user experience (U/X) is available and evaluate individual search features. +If the data space catalog exposes an API, the test assesses the technical effort required to integrate it with a data search tool representative of EU projects. +The criteria for evaluation include being open-source, a hosted solution, or part of an EU-driven project. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 provide a native online user experience (U/X), exposes no search features, and does not offer any integration with open-source solutions, hosted solutions, or EU-driven projects. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. This might include a basic online user interface with limited functionality, minimal search features, or an API that is available but requires significant technical effort to integrate with any of the three types of solutions: open-source, hosted, or EU-driven projects. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. This could involve a functional online user experience with some search features and an API that supports integration with at least one of the three types of solutions (open-source, hosted, or EU-driven projects) but requires moderate effort. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. This includes a well-developed online user experience with comprehensive search features, and an API that is well-documented and supports integration with two of the three types of solutions with minimal technical effort. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all evaluation criteria. This includes a fully developed native online user experience with advanced search features, and an API that seamlessly integrates with all three types of solutions (open-source, hosted, and EU-driven projects) with minimal or no technical effort. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `3.1.1.1` under the KPI1 area **Catalogue discovery / metadata**. + +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. diff --git a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md new file mode 100644 index 00000000..4c5ee01d --- /dev/null +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [3.1.1.4] Data product survey: Discover - Consult data space catalogue + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Catalogue discovery / metadata | +| Existing test ID | `3.1.1.4` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility | +| Owner (tentative) | Alessio (Cefriel) / Wilhelm | +| Reviewer | Carlos | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assessment: either the data product specification provides the necessary metadata to report quality, or the catalogue must be extended with an “-AP” profile. Ranks higher in the first case. + +#### Expected Output + +The test aims to determine whether the data product specification provides the necessary metadata for quality reporting or if the catalog needs to be extended with an "-AP" profile, with the former being ranked higher. The system may offer varying levels of support for Napcore's DCAT-AP profile, such as [MobilityDCAT-AP](https://mobilitydcat-ap.github.io/mobilityDCAT-AP/releases/index.html) profiles. The evaluation focuses on the level of support for the Napcore Profile and its vocabulary. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 DCAT-AP Support:** The implementation does not allow any DCAT-AP profile or functionality. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Breaks with Napcore DCAT-AP:** The implementation breaks if Napcore's DCAT-AP is used to describe data products. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Ignores Extensions but Functional:** The implementation ignores the extensions of Napcore's DCAT-AP, but the system works as expected, with extended metadata retrievable as part of the distribution. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Integration:** The implementation integrates Napcore's DCAT-AP profile and utilizes it for some search and listing functionalities, but with limitations. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Integration:** The implementation fully integrates Napcore's DCAT-AP profile and utilizes it effectively for search and listing functionalities. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `3.1.1.4` under the KPI1 area **Catalogue discovery / metadata**. + +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. diff --git a/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md new file mode 100644 index 00000000..d2f9a251 --- /dev/null +++ b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md @@ -0,0 +1,93 @@ +## [5.2.1.1] Data sharing: Data sharing activities - Enforce usage control + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS 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 EMDS 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 EMDS 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](https://internationaldataspaces.org/data-sovereignty-updated-position-paper-on-data-usage-control-in-the-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 EMDS 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 EMDS Final Stack assessment. | +| No out of the box policies but policies are available from a library | TBD | TBD | Pending EMDS Final Stack assessment. | +| Partial out-of-the-box-policies | TBD | TBD | Pending EMDS Final Stack assessment. | +| Full set of out-of-the-box policies | TBD | TBD | Pending EMDS Final Stack assessment. | +| Documented way to create/expand policies | TBD | TBD | Pending EMDS Final Stack assessment. | +| Documented way to create/expand policies + templates for basic polices | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS 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. diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md index ef32f81b..671c7ecc 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md @@ -8,53 +8,56 @@ This section identifies the technical context in which the EMDS Final Stack assessment is performed. -The assessment is expected to 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. +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Data sharing request | +| Existing test ID | `5.1.1.1` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Reliability, Security | +| Owner (tentative) | Casper (imec) | +| Reviewer | Wilhelm | +| 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`. -| Field | Value | Guidance | -| ------------------------------ | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | Indicates that this result belongs to the integration phase and not to the original Phase 1 / Phase 2 stack-comparison campaign. | -| Result perspective | `emds_final_stack` | Identifies this file as the EMDS Final Stack result perspective for the existing test definition. | -| Stack under assessment | EMDS Final Stack (EDC-based) | Indicates that the selected EMDS technical infrastructure is being assessed. | -| Deployment model assessed | TBD | Specify the deployment model actually used to collect evidence. Usually this will be either CaaS / IONOS-managed deployment or on-premise deployment. | -| Target environment | TBD | Specify the concrete environment used for the assessment, for example the IONOS Kubernetes cluster, namespace, local environment or other deployment target. | -| EDC version / release | TBD | Specify the EDC version, release, image tag or commit used in the assessed deployment, if available. | -| Connector deployment reference | TBD | Reference the deployed connector version, image, Helm chart, Docker Compose setup, GitHub commit, release or other deployment artefact used for the assessment. | -| Assessment evidence | TBD | Reference the evidence used to support the assessment, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner. | - -The deployment model should be completed using the option that matches the available evidence: - -| Deployment model | When to use it | -| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | -| CaaS / IONOS-managed deployment | Use this when the assessment evidence comes from the EMDS infrastructure deployed or managed in the IONOS environment. | -| On-premise deployment | Use this when the assessment evidence comes from a locally managed or partner-managed deployment. | +#### Tested quality metric and method -If only one deployment model is assessed, the other one should be marked as `Not assessed`. This is acceptable as long as the result clearly states which deployment model was used for the assessment. +This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. -#### Tested quality metric and method +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. -The quality metric for this test is based on the criteria outlined in [iso27001_kpis_subkpis.xlsx](../../../../../design_decisions/background_info/iso27001_kpis_subkpis.xlsx). For detailed information, please refer to the [Comparative criteria (checklists, ...)](./test.md#comparative-criteria-checklists-) section in the test description. +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 EMDS Final Stack deployment. -This result does not belong to the original deployEMDS Phase 1 / Phase 2 testing campaign used for the initial stack comparison. Instead, it reuses the existing test definition to assess the selected EMDS technical infrastructure during the integration phase. +#### Test-specific assessment scope -For the EMDS Final Stack, the assessment focuses on whether the current EDC-based infrastructure provides a documented, secured and testable mechanism to initiate and manage data transfer requests. +Coverage test: assess that the API is available and test that a data sharing request is properly covered: +- Initiate a data sharing +- Retrieve data sharing information and status +- Receive data sharing request outcome condition +- Retrieve data sharing information of past data sharing actions. -The existing test definition remains unchanged. This result file adds an EMDS Final Stack perspective next to the historical stack-specific result files, such as `result_edc_vc.md` and `result_fiware.md`. +The system ranks higher if the API is secured and implements common methods, like REST. #### Expected Output The test aims to provide a comprehensive evaluation of the following aspects: -* **Assess the availability of the transfer mechanism:** Ensure that the API or equivalent transfer mechanism is accessible and functional in the EMDS Final Stack. -* **Test data sharing requests:** Verify that data sharing requests are correctly processed, covering these steps: - - * Initiating a data sharing request. - * Retrieving information and status of the data sharing request. - * Receiving the outcome of the data sharing request, including conditions. - * Accessing information on past data sharing activities. -* **Assess deployment-specific evidence:** Indicate which deployment model was actually assessed, either CaaS / IONOS-managed deployment or on-premise deployment. -* **Assess repeatability:** Ensure that the assessment can be supported by repeatable 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. - -The system will score higher if the transfer mechanism is secured, implements common methods such as REST where applicable, and can be validated with repeatable technical evidence in the selected deployment model. +- **Assess the Availability of the API:** Ensure that the API is accessible and functional. +- **Test Data Sharing Requests:** Verify that data sharing requests are correctly processed, covering these steps: + - Initiating a data sharing request. + - Retrieving information and status of the data sharing request. + - Receiving the outcome of the data sharing request, including conditions. + - Accessing information on past data sharing activities. +The system will score higher if the API is secured and utilizes standard methods, such as REST. ### Results @@ -62,35 +65,35 @@ The system will score higher if the transfer mechanism is secured, implements co Pending. -The assessment should be completed once consolidated evidence is available for the EMDS Final Stack deployment. +The assessment should be completed once consolidated technical evidence is available for the EMDS 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`. | +| 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 -| Requirement | Measured KPI | Evidence | Notes | -| -------------------------------------------------------------- | -----------: | -------- | -------------------------------------------------------------------------------------------------------- | -| Initiate a data sharing request | TBD | TBD | Pending assessment based on execution evidence from the selected deployment model. | -| Retrieve data sharing information and status | TBD | TBD | Pending assessment based on evidence of transfer process status retrieval. | -| Receive data sharing request outcome condition | TBD | TBD | Pending assessment based on evidence that the transfer request outcome can be retrieved and interpreted. | -| Retrieve data sharing information of past data sharing actions | TBD | TBD | Pending assessment based on evidence of traceability or access to previous transfer actions. | +| Requirement | Measured KPI | +| -|--------------| +| Initiate a data sharing | TBD | +| Retrieve data sharing information and status | TBD | +| Receive data sharing request outcome condition | TBD | +| Retrieve data sharing information of past data sharing actions. | TBD | **Overall Calculation:** TBD **Functional Suitability Quality Metric Score:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test. It does not replace the historical **EDC+VC** or **Fiware** results. +This result introduces an **EMDS Final Stack** perspective for the existing test `5.1.1.1` under the KPI1 area **Data sharing request**. -This result should not be interpreted as part of the original Phase 1 / Phase 2 testing campaign. It is intended as an integration phase assessment of the current EMDS final technical infrastructure. +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. -If the test is executed in only one deployment model, the result should clearly indicate which deployment model was assessed. The other deployment model may remain marked as `Not assessed`. If evidence is later collected for the second deployment model, this result file may be updated accordingly. +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. diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md new file mode 100644 index 00000000..a44a205f --- /dev/null +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md @@ -0,0 +1,97 @@ +## [5.1.1.2] Data sharing: Data sharing request - Request data transfer + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Minimal data transfer | +| Existing test ID | `5.1.1.2` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility, Reliability | +| Owner (tentative) | Casper (imec) | +| Reviewer | Carlos | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Coverage test: for each data plane available, test a minimal data sharing and identify possible inconsistencies with the original data product protocol endpoint (e.g., during data querying, we aren’t allowed to send http headers to the data source). + +#### Expected Output + +Evaluate the support of a minimal data sharing for the following data formats + +- GTFS - [Public dataset](https://opendata-ajuntament.barcelona.cat/data/dataset/c46503e3-cec6-4032-894d-1063b7a365ee/resource/1c92542e-0346-4df5-9824-d7753ab02e33/download) with direct download via HTTPS +- GTFS-RT - [Public dataset](https://api.data.gov.my/gtfs-realtime/vehicle-position/ktmb/) via APIs +- DATEX-II - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs +- DATX II Light - No available datasets for this data format, tests are skipped +- GBFS - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs +- WMS/WFS - [Public dataset](https://openmaps.gov.bc.ca/geo/ows?SERVICE=WMS&REQUEST=GetCapabilities) via APIs + +Also access through APIs. +Access to private APIs is tested using the AMB mobilitat endpoint. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| Test | Functional Completeness | Functional Correctness | Functional Appropriateness | Explanation | +|-------------|-------------------------|-------------------------|----------------------------|------------------------------------------------------| +| GTFS | TBD | TBD | TBD | TBD | +| GTFS-RT | TBD | TBD | TBD | TBD | +| DATEX-II | TBD | TBD | TBD | TBD | +| GBFS | TBD | TBD | TBD | TBD | +| WMS/WFS | TBD | TBD | TBD | TBD | +| Private key | TBD | TBD | TBD | TBD | +| Overall | TBD | TBD | TBD | TBD | + +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `5.1.1.2` under the KPI1 area **Minimal data transfer**. + +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. diff --git a/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md new file mode 100644 index 00000000..06ad572a --- /dev/null +++ b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md @@ -0,0 +1,86 @@ +## [1.3.1.5] Participant onboarding: Certification - Identity and credentials issuance + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Participant onboarding / identity | +| Existing test ID | `1.3.1.5` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Security | +| Owner (tentative) | Alessio (Cefriel) / Delia M. (NTT DATA) | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Assess the coverage of a minimally viable credential lifecycle is supported: request (credentials), issuance, validation, renewal, revocation. + +#### Expected Output + +The expected output of the test is an assessment of whether the EDC supports the full credential lifecycle, including request, issuance, validation, renewal, and revocation. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| **VC Lifecycle Stage** | **Coverage** | **Score (0-4)** | +|---------------------------------|--------------------------------------------------------------------|-----------------| +| **Issuance and Storage** | TBD | TBD | +| **Presentation** | TBD | TBD | +| **Verification & Use** | TBD | TBD | +| **Revocation/Expiration** | TBD | TBD | +| **Renewal/Re-Issuance** | TBD | TBD | + +**Overall Calculation:** TBD +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `1.3.1.5` under the KPI1 area **Participant onboarding / identity**. + +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. diff --git a/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md new file mode 100644 index 00000000..131819c2 --- /dev/null +++ b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [1.2.1.1] Participant onboarding: Evaluation - Self-assessment + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Participant onboarding / identity | +| Existing test ID | `1.2.1.1` | +| Level | UC + Technical | +| ISO/IEC 25010 mapping | Functional suitability, Security | +| Owner (tentative) | Alessio (Cefriel) / Delia M. (NTT DATA) | +| Reviewer | Alessio | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +If an onboarding online facility is provided, evaluate the level of customisation required to input participants’ metadata. + +#### Expected Output + +**The expected output of this test is to evaluate the level of customization required to input participants' metadata if an onboarding online facility is provided.** + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| **Criterion** | **Description** | **Score (0-4)** | **Explanation** | +|------------------------------|------------------------------------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Functional Completeness** | TBD | TBD | TBD | +| **Functional Correctness** | TBD | TBD | TBD | +| **Functional Appropriateness** | TBD | TBD | TBD | + +**For more details, refer to the [IdentityHub API documentation](https:** TBD +**Overall Calculation:** TBD +**Functional Suitability Quality Metric Score:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `1.2.1.1` under the KPI1 area **Participant onboarding / identity**. + +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. diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md new file mode 100644 index 00000000..505cb3f7 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [4.2.1.1] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Sharing agreement | +| Existing test ID | `4.2.1.1` | +| Level | Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility, Security | +| Owner (tentative) | Xavier (Eurocat) | +| Reviewer | TBD | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test completeness: Two connectors can negotiate a data sharing agreement that supports a defined minimal state machine (the definition of the minimal state machine must be agreed beforehand). + +#### Expected Output + +The test aims to assess the state machine implementation of the EDC ecosystem regarding the sharing negotiation. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 implement any negotiation flow for the data sharing agreement based on the defined minimal state machine. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the technical requirements. This might include only a basic framework for the negotiation flow, with a significant part of the defined minimal state machine not implemented. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the technical requirements. This could involve a partially implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with several key elements missing or incomplete. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the technical requirements. This includes a well-implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with only minor elements or details that may still need refinement. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all technical requirements. This includes a fully implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with all elements thoroughly addressed and tested. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional suitability quality metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.1` under the KPI1 area **Sharing agreement**. + +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. diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md new file mode 100644 index 00000000..9fc44bf8 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md @@ -0,0 +1,93 @@ +## [4.2.1.3] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Sharing agreement | +| Existing test ID | `4.2.1.3` | +| Level | Technical | +| ISO/IEC 25010 mapping | Functional suitability, Compatibility, Security | +| Owner (tentative) | Xavier (Eurocat) | +| Reviewer | TBD | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Prove that the negotiation can use (one or more of) the following assets and parameters to define a contract: +- Claim verification +- Usage policy rules +- Service Agreements + +The larger the coverage (i.e. more possibilities), the higher the rank. + +#### Expected Output + +The test aims to evaluate the coverage of the following criteria on contract negotiation: +- Claim verification +- Usage policy rules +- Service Agreements + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 Proof:** The solution does not demonstrate the ability to use any of the specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Limited Proof:** The solution demonstrates the ability to use only one of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Moderate Proof:** The solution demonstrates the ability to use two of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Extensive Proof:** The solution demonstrates the ability to use all three specified assets or parameters in the negotiation process to define a contract, though with some limitations in coverage or flexibility. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **Comprehensive Proof:** The solution fully demonstrates the ability to use all three specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in a flexible and comprehensive negotiation process, effectively covering a wide range of possibilities to define and manage contracts. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional suitability quality metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.3` under the KPI1 area **Sharing agreement**. + +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. diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md new file mode 100644 index 00000000..d20503e0 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [4.2.1.6] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS 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. diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md new file mode 100644 index 00000000..0635e4be --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md @@ -0,0 +1,81 @@ +## [4.2.1.7] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Observability / logging | +| Existing test ID | `4.2.1.7` | +| Level | Technical | +| ISO/IEC 25010 mapping | Reliability, Maintainability | +| Owner (tentative) | Carlos (i2CAT) | +| Reviewer | Carlos | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Verify that the system outputs logs detailing the sharing agreement process. Rank higher if the logs provide business information under a standard format. + +#### Expected Output + +The test aims to verify that the system generates logs detailing the sharing agreement process. A higher rank will be given if these logs include business information in a standardized format. + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.7` under the KPI1 area **Observability / logging**. + +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. diff --git a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md new file mode 100644 index 00000000..9419dbf0 --- /dev/null +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md @@ -0,0 +1,85 @@ +## [4.2.3.1] Sharing agreement: Negotiation - Refusal or registration of sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Security and restricted access | +| Existing test ID | `4.2.3.1` | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +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). + +#### 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 + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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. 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. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.3.1` 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. diff --git a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md new file mode 100644 index 00000000..1bc79158 --- /dev/null +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md @@ -0,0 +1,86 @@ +## [4.2.3.2] Sharing agreement: Negotiation - Refusal or registration of sharing agreement + +### Stack: EMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the EMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `emds_final_stack` | +| Stack under assessment | EMDS Final Stack (EDC-based) | +| KPI1 area | Observability / logging | +| Existing test ID | `4.2.3.2` | +| Level | Technical | +| ISO/IEC 25010 mapping | Reliability, Maintainability | +| Owner (tentative) | Carlos (i2CAT) | +| Reviewer | Carlos | +| 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 EMDS 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 EMDS Final Stack deployment. + +#### Test-specific assessment scope + +Check whether the system provides a observability trace of the sharing agreement (privacy terms of observability are out of scope here). + +#### Expected Output + +The expected outcome of the current test is to evaluate whether the system provides an observability trace of the sharing agreement (privacy terms of observability are out of scope). + +### Results + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the EMDS 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 traceability. | TBD | TBD | Pending EMDS Final Stack assessment. | +| System logs, which record only a connection between two connectors using non-data space identifiers such as a public URL or IP address. | TBD | TBD | Pending EMDS Final Stack assessment. | +| Application logs that include process information, for example, "Connector control plane initiating on port...". | TBD | TBD | Pending EMDS Final Stack assessment. | +| Data space protocol status traces, such as "Data sharing agreement request". | TBD | TBD | Pending EMDS Final Stack assessment. | +| Data space protocol transaction traces, for instance, "Contract ID Op: negotiation". | TBD | TBD | Pending EMDS Final Stack assessment. | +| A complete data space protocol context dump, including the entire JSON dump with references. | TBD | TBD | Pending EMDS Final Stack assessment. | + +**Functional suitability quality metric:** TBD + +#### Notes + +This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.3.2` under the KPI1 area **Observability / logging**. + +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. From eb51b8c7495bbdd99472eda153c74aa7fdea76eb Mon Sep 17 00:00:00 2001 From: dmorperd Date: Wed, 24 Jun 2026 17:33:01 +0200 Subject: [PATCH 8/8] Address protoEMDS Final Stack review comments --- README.md | 73 ++++++++++--------- ...ack.md => result_protoemds_final_stack.md} | 45 ++++++++---- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 22 +++--- ...ack.md => result_protoemds_final_stack.md} | 22 +++--- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 32 ++++---- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 20 ++--- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 22 +++--- ...ack.md => result_protoemds_final_stack.md} | 30 ++++---- ...ack.md => result_protoemds_final_stack.md} | 32 ++++---- 23 files changed, 366 insertions(+), 302 deletions(-) rename tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/{result_emds_final_stack.md => result_protoemds_final_stack.md} (68%) rename tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (85%) rename tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (85%) rename tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/{result_emds_final_stack.md => result_protoemds_final_stack.md} (78%) rename tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/{result_emds_final_stack.md => result_protoemds_final_stack.md} (79%) rename tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/{result_emds_final_stack.md => result_protoemds_final_stack.md} (82%) rename tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/{result_emds_final_stack.md => result_protoemds_final_stack.md} (82%) rename tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/{result_emds_final_stack.md => result_protoemds_final_stack.md} (81%) rename tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/{result_emds_final_stack.md => result_protoemds_final_stack.md} (81%) rename tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (83%) rename tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/{result_emds_final_stack.md => result_protoemds_final_stack.md} (80%) rename tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (80%) rename tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (86%) rename tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/{result_emds_final_stack.md => result_protoemds_final_stack.md} (87%) rename tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/{result_emds_final_stack.md => result_protoemds_final_stack.md} (83%) rename tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (85%) rename tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (80%) rename tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/{result_emds_final_stack.md => result_protoemds_final_stack.md} (80%) rename tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/{result_emds_final_stack.md => result_protoemds_final_stack.md} (83%) rename tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/{result_emds_final_stack.md => result_protoemds_final_stack.md} (82%) rename tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/{result_emds_final_stack.md => result_protoemds_final_stack.md} (84%) rename tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/{result_emds_final_stack.md => result_protoemds_final_stack.md} (76%) diff --git a/README.md b/README.md index d662af44..c1bc485a 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# deployEMDS +# deployEMDS ### deployEMDS empowers interoperable, trustworthy and accessible data sharing @@ -91,16 +91,16 @@ The following testing facilities are currently proposed: Following the initial stack-comparison testing campaign, the existing deployEMDS technology testing catalogue may also be reused during the integration phase. -The objective of this integration phase assessment is not to compare alternative testing facilities, but to assess the selected EMDS technical infrastructure and its readiness to support the expected data space capabilities. +The objective of this integration phase assessment is not to compare alternative testing facilities, but to assess the selected protoEMDS technical infrastructure and its readiness to support the expected data space capabilities. -For this purpose, selected existing tests may include an additional result perspective named `emds_final_stack`. This result perspective is added next to the historical stack-specific result files, while keeping the existing test definitions unchanged. +For this purpose, selected existing tests may include an additional result perspective named `protoemds_final_stack`. This result perspective is added next to the historical stack-specific result files, while keeping the existing test definitions unchanged. Example: * `test.md` * `result_edc_vc.md` * `result_fiware.md` -* `result_emds_final_stack.md` +* `result_protoemds_final_stack.md` The assessment should distinguish the deployment model used for the evidence collected: @@ -111,46 +111,46 @@ The assessment should distinguish the deployment model used for the evidence col The integration phase assessment should be supported by 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 approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected EMDS technical infrastructure. +This approach keeps the historical EDC+VC and Fiware results unchanged while allowing the project to document the integration readiness of the selected protoEMDS technical infrastructure. -# Integration phase test overview +# protoEMDS Final Stack selected test overview -This gives a quick view of the existing deployEMDS tests proposed for the EMDS Final Stack integration phase assessment. +This section highlights the specific existing deployEMDS tests put forward for the protoEMDS Final Stack integration phase assessment. -The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an `emds_final_stack` result file to document the assessment of the selected EMDS Final Stack when the corresponding evidence is available. +The integration phase does not execute the full historical test matrix. It reuses a limited subset of existing test definitions and adds an `protoemds_final_stack` result file to document the assessment of the selected protoEMDS Final Stack when the corresponding evidence is available. - + Last updated: 2026-06-23 | Test | Title | Phase | Minimal | Results | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md) | -| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | Integration | Yes | [emds_final_stack pending](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md) | -| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md) | -| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md) | -| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md) | -| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md) | -| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md) | -| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md) | -| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md) | -| [2.2.5.2] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md) | -| [2.2.5.7] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md) | -| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md) | -| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md) | -| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md) | -| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md) | -| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md) | -| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md) | -| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md) | -| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md) | -| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md) | -| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md) | -| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | Integration | Yes | [emds_final_stack pending](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md) | - - - -`emds_final_stack pending` indicates that the EMDS Final Stack assessment is still being consolidated. The linked `result_emds_final_stack.md` files provide the integration-phase result perspective for each selected test and should be completed once consolidated evidence is available. +| [1.2.1.1] | [Participant onboarding: Evaluation - Self-assessment](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md) | +| [1.3.1.5] | [Participant onboarding: Certification - Identity and credentials issuance](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md) | +| [2.1.1.3] | [Data product publication: Provision - Data source endpoint provisioning](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md) | +| [2.1.3.1] | [Data product publication: Provision - Reuse or create usage control policies / functions](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_protoemds_final_stack.md) | +| [2.2.2.1] | [Data product publication: Publication - Deploy/config usage control functions](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md) | +| [2.2.3.1A] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md) | +| [2.2.3.1B] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md) | +| [2.2.3.1D] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md) | +| [2.2.3.3] | [Data product publication: Publication - Publication on EMDS catalogue](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md) | +| [2.2.5.2] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md) | +| [2.2.5.7] | [Data product publication: Publication - Publication on federated data spaces](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md) | +| [3.1.1.1] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md) | +| [3.1.1.4] | [Data product survey: Discover - Consult data space catalogue](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md) | +| [4.2.1.1] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md) | +| [4.2.1.3] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md) | +| [4.2.1.6] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md) | +| [4.2.1.7] | [Sharing agreement: Negotiation - Negotiating sharing agreement](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md) | +| [4.2.3.1] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md) | +| [4.2.3.2] | [Sharing agreement: Negotiation - Refusal or registration of sharing agreement](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md) | +| [5.1.1.1] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md) | +| [5.1.1.2] | [Data sharing: Data sharing request - Request data transfer](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md) | +| [5.2.1.1] | [Data sharing: Data sharing activities - Enforce usage control](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/test.md) | Integration | Yes | [protoemds_final_stack pending](tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md) | + + + +`protoemds_final_stack pending` indicates that the protoEMDS Final Stack assessment is still being consolidated. The linked `result_protoemds_final_stack.md` files provide the integration-phase result perspective for each selected test and should be completed once consolidated evidence is available. # Test overview @@ -223,3 +223,6 @@ In accordance with the [deployEMDS Information Security Policy](https://acateche This process ensures compliance with our security protocols and safeguards the intellectual property and sensitive information. Please note: secret keys have been redacted in this repository and must be replaced with user-provided keys to ensure functionality. + + + diff --git a/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md similarity index 68% rename from tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md rename to tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md index 5a744f8b..75a11346 100644 --- a/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_emds_final_stack.md +++ b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.1.1.3] Data product publication: Provision - Data source endpoint provisioning +## [2.1.1.3] Data product publication: Provision - Data source endpoint provisioning -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Connector and data planes | | Existing test ID | `2.1.1.3` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -47,13 +47,23 @@ Evaluate the level of support for the following data formats - GTFS - [Public dataset](https://opendata-ajuntament.barcelona.cat/data/dataset/c46503e3-cec6-4032-894d-1063b7a365ee/resource/1c92542e-0346-4df5-9824-d7753ab02e33/download) with direct download via HTTPS - GTFS-RT - [Public dataset](https://api.data.gov.my/gtfs-realtime/vehicle-position/ktmb/) via APIs -- DATEX-II - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs -- DATX II Light - No available datasets for this data format, tests are skipped -- GBFS - [Public dataset](https://opendata.emel.pt/cycling/biciparks?skip=1&limit=1) via APIs +- DATEX-II - [Flanders DATEX-II feed](https://www.vlaanderen.be/datavindplaats/catalogus/datex2-feed-verkeerscentrum-vlaanderen-full-version) via APIs +- DATEX II Light - No available datasets for this data format, tests are skipped +- GBFS - Candidate GBFS source to be confirmed before execution. The previous EMEL reference is currently unavailable during the open data portal transition and should not be used as execution evidence until validated. - WMS/WFS - [Public dataset](https://openmaps.gov.bc.ca/geo/ows?SERVICE=WMS&REQUEST=GetCapabilities) via APIs Also access through APIs. -Access to private APIs is tested using the AMB mobilitat endpoint. + +Access to private APIs should be tested using a representative private endpoint selected by the test executor or component owner. AMB Mobilitat may be used as an example if available, but the selected endpoint, authentication flow and access requirements must be documented before execution. + +The execution evidence should document: + +- the selected private endpoint or API route; +- the authentication method, without exposing API keys, tokens, credentials or secrets; +- the required request headers or token type, if applicable; +- the expected response status; +- a redacted example of the response payload; +- the component or owner confirming that the endpoint is representative for private API access. ### Results @@ -61,7 +71,7 @@ Access to private APIs is tested using the AMB mobilitat endpoint. Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -84,10 +94,19 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.1.1.3` under the KPI1 area **Connector and data planes**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.1.1.3` under the KPI1 area **Connector and data planes**. 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. + + + + + + + + + diff --git a/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md b/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_protoemds_final_stack.md similarity index 85% rename from tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md rename to tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_protoemds_final_stack.md index 74b0ee9c..82517eeb 100644 --- a/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_emds_final_stack.md +++ b/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.1.3.1] Data product publication: Provision - Reuse or create usage control policies / functions +## [2.1.3.1] Data product publication: Provision - Reuse or create usage control policies / functions -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Policy management | | Existing test ID | `2.1.3.1` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -60,7 +60,7 @@ See `test.md` for the complete expected output and comparative criteria for this Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -89,10 +89,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.1.3.1` under the KPI1 area **Policy management**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.1.3.1` under the KPI1 area **Policy management**. 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. + + diff --git a/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md similarity index 85% rename from tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md rename to tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md index 0e3e685a..fcd4f191 100644 --- a/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.2.1] Data product publication: Publication - Deploy/config usage control functions +## [2.2.2.1] Data product publication: Publication - Deploy/config usage control functions -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Policy management | | Existing test ID | `2.2.2.1` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ See `test.md` for the complete expected output and comparative criteria for this Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -76,10 +76,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.2.1` under the KPI1 area **Policy management**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.2.1` under the KPI1 area **Policy management**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md similarity index 78% rename from tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md index 46ed2258..5b92fcb0 100644 --- a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.3.1A] Data product publication: Publication - Publication on EMDS catalogue +## [2.2.3.1A] Data product publication: Publication - Publication on EMDS catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue publication | | Existing test ID | `2.2.3.1A` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -52,7 +52,7 @@ refers to the Data Space-only catalog, specifically the internal EDC catalog and Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -67,20 +67,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | Criteria | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** No technical requirements are met. The solution fails to provide any functionality for the new data product in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for the new data product in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** No technical requirements are met. The solution fails to provide any functionality for the new data product in the catalog. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for the new data product in the catalog. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1A` under the KPI1 area **Catalogue publication**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.3.1A` under the KPI1 area **Catalogue publication**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md similarity index 79% rename from tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md index 34058835..3912f808 100644 --- a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.3.1B] Data product publication: Publication - Publication on EMDS catalogue +## [2.2.3.1B] Data product publication: Publication - Publication on EMDS catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue publication | | Existing test ID | `2.2.3.1B` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -52,7 +52,7 @@ The EMDS catalog, as defined in the relevant documentation, refers to the Data S Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -67,20 +67,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | Criteria | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** No technical requirements are met. The solution fails to provide any functionality for an existing data product published in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for an existing data product published in the catalog. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** No technical requirements are met. The solution fails to provide any functionality for an existing data product published in the catalog. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. Only basic functionalities are implemented, leaving most requirements unaddressed. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. Key functions are partially implemented, but several critical aspects are lacking. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. Most functionalities work as expected, with only minor gaps needing improvement. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution provides a comprehensive, out-of-the-box solution for an existing data product published in the catalog. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1B` under the KPI1 area **Catalogue publication**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.3.1B` under the KPI1 area **Catalogue publication**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md similarity index 82% rename from tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md index d0588961..713f501d 100644 --- a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.3.1D] Data product publication: Publication - Publication on EMDS catalogue +## [2.2.3.1D] Data product publication: Publication - Publication on EMDS catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue publication | | Existing test ID | `2.2.3.1D` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to examine the process of catalog de-publication for a data produc Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** The solution does not provide any functionality for de-publishing a data product from the catalog. Users cannot remove or hide a data product once it is published, and achieving this requires extensive custom development or workarounds. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. It may offer basic de-publication functionality, but this is not fully operational out of the box and requires significant technical effort or development to implement. The process is cumbersome and not intuitive for end users. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. It allows for de-publishing of data products but requires some degree of customization or development to function correctly. Additionally, the process may be partially intuitive but could still pose challenges for end users in terms of usability. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. It provides effective de-publication functionality with minimal development required. The de-publication process is mostly intuitive and user-friendly, with only minor usability issues or adjustments needed. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** The solution fully meets all evaluation criteria. It offers complete, out-of-the-box functionality for de-publishing a data product, allowing users to easily remove or hide a data product from the catalog. The process is straightforward, intuitive, and requires no additional development or technical modifications. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** The solution does not provide any functionality for de-publishing a data product from the catalog. Users cannot remove or hide a data product once it is published, and achieving this requires extensive custom development or workarounds. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. It may offer basic de-publication functionality, but this is not fully operational out of the box and requires significant technical effort or development to implement. The process is cumbersome and not intuitive for end users. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. It allows for de-publishing of data products but requires some degree of customization or development to function correctly. Additionally, the process may be partially intuitive but could still pose challenges for end users in terms of usability. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. It provides effective de-publication functionality with minimal development required. The de-publication process is mostly intuitive and user-friendly, with only minor usability issues or adjustments needed. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all evaluation criteria. It offers complete, out-of-the-box functionality for de-publishing a data product, allowing users to easily remove or hide a data product from the catalog. The process is straightforward, intuitive, and requires no additional development or technical modifications. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.1D` under the KPI1 area **Catalogue publication**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.3.1D` under the KPI1 area **Catalogue publication**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md similarity index 82% rename from tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md index fe0c7790..6728a389 100644 --- a/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.3.3] Data product publication: Publication - Publication on EMDS catalogue +## [2.2.3.3] Data product publication: Publication - Publication on EMDS catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue publication | | Existing test ID | `2.2.3.3` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to verify the availability of a GUI for publishing a data product Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | Criteria | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** No technical requirements are met. The solution does not have a GUI tool for publishing a data product offering into the catalogue and enabling discovery. The system does not provide any GUI means for users to interact with or manage data product offerings. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** Up to 25% of the technical requirements are met. The solution provides limited functionality, such as a basic GUI tool with minimal features, allowing for partial publication of data products but lacks robust discovery options. User interface might be clunky, and only a few essential functions are available. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** Approximately 50% of the technical requirements are met. The solution includes a GUI tool that allows for the publication of data products and some discovery features. However, it lacks advanced functionality, such as customizable search options, detailed metadata management, or integration with other systems. Usability and user experience are moderately acceptable. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** About 80% of the technical requirements are met. The solution offers a comprehensive GUI tool with most required features, such as advanced publication workflows, robust discovery capabilities, customizable search filters, and metadata management. Integration with other systems and platforms is partially supported, and the user experience is generally smooth. However, some advanced features or full system integration might still be lacking. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** All technical requirements are fully met. The solution includes a fully featured GUI tool for publishing data product offerings into the catalogue, complete with advanced discovery features, customizable search options, detailed metadata management, and full integration with other systems. The user interface is intuitive and user-friendly, providing an excellent user experience. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** No technical requirements are met. The solution does not have a GUI tool for publishing a data product offering into the catalogue and enabling discovery. The system does not provide any GUI means for users to interact with or manage data product offerings. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** Up to 25% of the technical requirements are met. The solution provides limited functionality, such as a basic GUI tool with minimal features, allowing for partial publication of data products but lacks robust discovery options. User interface might be clunky, and only a few essential functions are available. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** Approximately 50% of the technical requirements are met. The solution includes a GUI tool that allows for the publication of data products and some discovery features. However, it lacks advanced functionality, such as customizable search options, detailed metadata management, or integration with other systems. Usability and user experience are moderately acceptable. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** About 80% of the technical requirements are met. The solution offers a comprehensive GUI tool with most required features, such as advanced publication workflows, robust discovery capabilities, customizable search filters, and metadata management. Integration with other systems and platforms is partially supported, and the user experience is generally smooth. However, some advanced features or full system integration might still be lacking. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** All technical requirements are fully met. The solution includes a fully featured GUI tool for publishing data product offerings into the catalogue, complete with advanced discovery features, customizable search options, detailed metadata management, and full integration with other systems. The user interface is intuitive and user-friendly, providing an excellent user experience. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.3.3` under the KPI1 area **Catalogue publication**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.3.3` under the KPI1 area **Catalogue publication**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md similarity index 81% rename from tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md index 6429e543..5aa4d36f 100644 --- a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.5.2] Data product publication: Publication - Publication on federated data spaces +## [2.2.5.2] Data product publication: Publication - Publication on federated data spaces -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Publication on federated data spaces | | Existing test ID | `2.2.5.2` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ Give an existing data space, assess whether the system allows a federated data s Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,17 +66,19 @@ The result should clearly indicate which deployment model was assessed. It is ac | Requirement | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | +| Test-specific requirement from `test.md` | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Overall Calculation:** TBD **Quality Metric Score:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.5.2` under the KPI1 area **Publication on federated data spaces**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.5.2` under the KPI1 area **Publication on federated data spaces**. 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. + + diff --git a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md similarity index 81% rename from tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md rename to tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md index c7176813..ae0fc010 100644 --- a/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_emds_final_stack.md +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [2.2.5.7] Data product publication: Publication - Publication on federated data spaces +## [2.2.5.7] Data product publication: Publication - Publication on federated data spaces -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Publication on federated data spaces | | Existing test ID | `2.2.5.7` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ Does my product in a federated data space achieve equal visibility as native one Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,17 +66,19 @@ The result should clearly indicate which deployment model was assessed. It is ac | Requirement | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | +| Test-specific requirement from `test.md` | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Overall Calculation:** TBD **Quality Metric Score:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `2.2.5.7` under the KPI1 area **Publication on federated data spaces**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `2.2.5.7` under the KPI1 area **Publication on federated data spaces**. 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. + + diff --git a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md similarity index 83% rename from tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md rename to tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md index e1e2c6b7..1bada4a4 100644 --- a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_emds_final_stack.md +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [3.1.1.1] Data product survey: Discover - Consult data space catalogue +## [3.1.1.1] Data product survey: Discover - Consult data space catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue discovery / metadata | | Existing test ID | `3.1.1.1` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -53,7 +53,7 @@ The criteria for evaluation include being open-source, a hosted solution, or par Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -68,20 +68,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** The solution fails to provide a native online user experience (U/X), exposes no search features, and does not offer any integration with open-source solutions, hosted solutions, or EU-driven projects. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. This might include a basic online user interface with limited functionality, minimal search features, or an API that is available but requires significant technical effort to integrate with any of the three types of solutions: open-source, hosted, or EU-driven projects. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. This could involve a functional online user experience with some search features and an API that supports integration with at least one of the three types of solutions (open-source, hosted, or EU-driven projects) but requires moderate effort. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. This includes a well-developed online user experience with comprehensive search features, and an API that is well-documented and supports integration with two of the three types of solutions with minimal technical effort. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** The solution fully meets all evaluation criteria. This includes a fully developed native online user experience with advanced search features, and an API that seamlessly integrates with all three types of solutions (open-source, hosted, and EU-driven projects) with minimal or no technical effort. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** The solution fails to provide a native online user experience (U/X), exposes no search features, and does not offer any integration with open-source solutions, hosted solutions, or EU-driven projects. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the evaluation criteria. This might include a basic online user interface with limited functionality, minimal search features, or an API that is available but requires significant technical effort to integrate with any of the three types of solutions: open-source, hosted, or EU-driven projects. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the evaluation criteria. This could involve a functional online user experience with some search features and an API that supports integration with at least one of the three types of solutions (open-source, hosted, or EU-driven projects) but requires moderate effort. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the evaluation criteria. This includes a well-developed online user experience with comprehensive search features, and an API that is well-documented and supports integration with two of the three types of solutions with minimal technical effort. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all evaluation criteria. This includes a fully developed native online user experience with advanced search features, and an API that seamlessly integrates with all three types of solutions (open-source, hosted, and EU-driven projects) with minimal or no technical effort. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `3.1.1.1` under the KPI1 area **Catalogue discovery / metadata**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `3.1.1.1` under the KPI1 area **Catalogue discovery / metadata**. 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. + + diff --git a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md similarity index 80% rename from tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md rename to tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md index 4c5ee01d..116252f4 100644 --- a/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_emds_final_stack.md +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [3.1.1.4] Data product survey: Discover - Consult data space catalogue +## [3.1.1.4] Data product survey: Discover - Consult data space catalogue -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Catalogue discovery / metadata | | Existing test ID | `3.1.1.4` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to determine whether the data product specification provides the n Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No DCAT-AP Support:** The implementation does not allow any DCAT-AP profile or functionality. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Breaks with Napcore DCAT-AP:** The implementation breaks if Napcore's DCAT-AP is used to describe data products. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Ignores Extensions but Functional:** The implementation ignores the extensions of Napcore's DCAT-AP, but the system works as expected, with extended metadata retrievable as part of the distribution. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Integration:** The implementation integrates Napcore's DCAT-AP profile and utilizes it for some search and listing functionalities, but with limitations. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Integration:** The implementation fully integrates Napcore's DCAT-AP profile and utilizes it effectively for search and listing functionalities. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No DCAT-AP Support:** The implementation does not allow any DCAT-AP profile or functionality. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Breaks with Napcore DCAT-AP:** The implementation breaks if Napcore's DCAT-AP is used to describe data products. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Ignores Extensions but Functional:** The implementation ignores the extensions of Napcore's DCAT-AP, but the system works as expected, with extended metadata retrievable as part of the distribution. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Integration:** The implementation integrates Napcore's DCAT-AP profile and utilizes it for some search and listing functionalities, but with limitations. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Integration:** The implementation fully integrates Napcore's DCAT-AP profile and utilizes it effectively for search and listing functionalities. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `3.1.1.4` under the KPI1 area **Catalogue discovery / metadata**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `3.1.1.4` under the KPI1 area **Catalogue discovery / metadata**. 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. + + diff --git a/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md similarity index 80% rename from tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md rename to tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md index d2f9a251..d336cb02 100644 --- a/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [5.2.1.1] Data sharing: Data sharing activities - Enforce usage control +## [5.2.1.1] Data sharing: Data sharing activities - Enforce usage control -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| 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 | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -58,7 +58,7 @@ The test aims to evaluate which usage policies are supported out of the box. For Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -73,21 +73,23 @@ The result should clearly indicate which deployment model was assessed. It is ac | Criteria | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| No out of the box policies | TBD | TBD | Pending EMDS Final Stack assessment. | -| No out of the box policies but policies are available from a library | TBD | TBD | Pending EMDS Final Stack assessment. | -| Partial out-of-the-box-policies | TBD | TBD | Pending EMDS Final Stack assessment. | -| Full set of out-of-the-box policies | TBD | TBD | Pending EMDS Final Stack assessment. | -| Documented way to create/expand policies | TBD | TBD | Pending EMDS Final Stack assessment. | -| Documented way to create/expand policies + templates for basic polices | TBD | TBD | Pending EMDS Final Stack assessment. | +| 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 **EMDS Final Stack** perspective for the existing test `5.2.1.1` under the KPI1 area **Usage control enforcement**. +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. + + diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md similarity index 86% rename from tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md rename to tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md index 671c7ecc..ebf6f232 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [5.1.1.1] Data sharing: Data sharing request - Request data transfer +## [5.1.1.1] Data sharing: Data sharing request - Request data transfer -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Data sharing request | | Existing test ID | `5.1.1.1` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -65,7 +65,7 @@ The system will score higher if the API is secured and utilizes standard methods Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -90,10 +90,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `5.1.1.1` under the KPI1 area **Data sharing request**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `5.1.1.1` under the KPI1 area **Data sharing request**. 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. + + diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md similarity index 87% rename from tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md rename to tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md index a44a205f..2b7f05ad 100644 --- a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_emds_final_stack.md +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [5.1.1.2] Data sharing: Data sharing request - Request data transfer +## [5.1.1.2] Data sharing: Data sharing request - Request data transfer -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Minimal data transfer | | Existing test ID | `5.1.1.2` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -61,7 +61,7 @@ Access to private APIs is tested using the AMB mobilitat endpoint. Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -88,10 +88,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `5.1.1.2` under the KPI1 area **Minimal data transfer**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `5.1.1.2` under the KPI1 area **Minimal data transfer**. 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. + + diff --git a/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md similarity index 83% rename from tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md rename to tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md index 06ad572a..8b202f51 100644 --- a/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_emds_final_stack.md +++ b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [1.3.1.5] Participant onboarding: Certification - Identity and credentials issuance +## [1.3.1.5] Participant onboarding: Certification - Identity and credentials issuance -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Participant onboarding / identity | | Existing test ID | `1.3.1.5` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The expected output of the test is an assessment of whether the EDC supports the Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -77,10 +77,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `1.3.1.5` under the KPI1 area **Participant onboarding / identity**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `1.3.1.5` under the KPI1 area **Participant onboarding / identity**. 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. + + diff --git a/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md similarity index 85% rename from tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md rename to tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md index 131819c2..a44afcf0 100644 --- a/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_emds_final_stack.md +++ b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [1.2.1.1] Participant onboarding: Evaluation - Self-assessment +## [1.2.1.1] Participant onboarding: Evaluation - Self-assessment -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Participant onboarding / identity | | Existing test ID | `1.2.1.1` | | Level | UC + Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ If an onboarding online facility is provided, evaluate the level of customisatio Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -76,10 +76,12 @@ The result should clearly indicate which deployment model was assessed. It is ac #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `1.2.1.1` under the KPI1 area **Participant onboarding / identity**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `1.2.1.1` under the KPI1 area **Participant onboarding / identity**. 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. + + diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md similarity index 80% rename from tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md index 505cb3f7..54c87ab0 100644 --- a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.1.1] Sharing agreement: Negotiation - Negotiating sharing agreement +## [4.2.1.1] Sharing agreement: Negotiation - Negotiating sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Sharing agreement | | Existing test ID | `4.2.1.1` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to assess the state machine implementation of the EDC ecosystem re Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Coverage:** The solution fails to implement any negotiation flow for the data sharing agreement based on the defined minimal state machine. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Minimal Coverage:** The solution meets up to 25% of the technical requirements. This might include only a basic framework for the negotiation flow, with a significant part of the defined minimal state machine not implemented. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Partial Coverage:** The solution satisfies approximately 50% of the technical requirements. This could involve a partially implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with several key elements missing or incomplete. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Significant Coverage:** The solution covers about 80% of the technical requirements. This includes a well-implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with only minor elements or details that may still need refinement. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Full Coverage:** The solution fully meets all technical requirements. This includes a fully implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with all elements thoroughly addressed and tested. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Coverage:** The solution fails to implement any negotiation flow for the data sharing agreement based on the defined minimal state machine. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Minimal Coverage:** The solution meets up to 25% of the technical requirements. This might include only a basic framework for the negotiation flow, with a significant part of the defined minimal state machine not implemented. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Partial Coverage:** The solution satisfies approximately 50% of the technical requirements. This could involve a partially implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with several key elements missing or incomplete. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Significant Coverage:** The solution covers about 80% of the technical requirements. This includes a well-implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with only minor elements or details that may still need refinement. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Full Coverage:** The solution fully meets all technical requirements. This includes a fully implemented negotiation flow for the data sharing agreement based on the defined minimal state machine, with all elements thoroughly addressed and tested. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional suitability quality metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.1` under the KPI1 area **Sharing agreement**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `4.2.1.1` under the KPI1 area **Sharing agreement**. 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. + + diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md similarity index 80% rename from tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md index 9fc44bf8..87c9fe38 100644 --- a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.1.3] Sharing agreement: Negotiation - Negotiating sharing agreement +## [4.2.1.3] Sharing agreement: Negotiation - Negotiating sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Sharing agreement | | Existing test ID | `4.2.1.3` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -59,7 +59,7 @@ The test aims to evaluate the coverage of the following criteria on contract neg Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -74,20 +74,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **No Proof:** The solution does not demonstrate the ability to use any of the specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Limited Proof:** The solution demonstrates the ability to use only one of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Moderate Proof:** The solution demonstrates the ability to use two of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Extensive Proof:** The solution demonstrates the ability to use all three specified assets or parameters in the negotiation process to define a contract, though with some limitations in coverage or flexibility. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **Comprehensive Proof:** The solution fully demonstrates the ability to use all three specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in a flexible and comprehensive negotiation process, effectively covering a wide range of possibilities to define and manage contracts. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **No Proof:** The solution does not demonstrate the ability to use any of the specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Limited Proof:** The solution demonstrates the ability to use only one of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Moderate Proof:** The solution demonstrates the ability to use two of the specified assets or parameters in the negotiation process to define a contract. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Extensive Proof:** The solution demonstrates the ability to use all three specified assets or parameters in the negotiation process to define a contract, though with some limitations in coverage or flexibility. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **Comprehensive Proof:** The solution fully demonstrates the ability to use all three specified assets or parameters (Claim Verification, Usage Policy Rules, Service Agreements) in a flexible and comprehensive negotiation process, effectively covering a wide range of possibilities to define and manage contracts. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional suitability quality metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.3` under the KPI1 area **Sharing agreement**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `4.2.1.3` under the KPI1 area **Sharing agreement**. 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. + + diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md similarity index 83% rename from tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md index d20503e0..1577b766 100644 --- a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.1.6] Sharing agreement: Negotiation - Negotiating sharing agreement +## [4.2.1.6] Sharing agreement: Negotiation - Negotiating sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| 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 | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to assess whether the data sharing protocol is compatible with cha Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **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 EMDS 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 EMDS 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 EMDS 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 EMDS 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 EMDS Final Stack assessment. | +| **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 **EMDS Final Stack** perspective for the existing test `4.2.1.6` under the KPI1 area **Security and restricted access**. +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. + + diff --git a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md similarity index 82% rename from tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md index 0635e4be..e3710383 100644 --- a/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.1.7] Sharing agreement: Negotiation - Negotiating sharing agreement +## [4.2.1.7] Sharing agreement: Negotiation - Negotiating sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Observability / logging | | Existing test ID | `4.2.1.7` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to verify that the system generates logs detailing the sharing agr Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,16 +66,18 @@ The result should clearly indicate which deployment model was assessed. It is ac | Requirement | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| Test-specific requirement from `test.md` | TBD | TBD | Pending EMDS Final Stack assessment. | +| Test-specific requirement from `test.md` | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.1.7` under the KPI1 area **Observability / logging**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `4.2.1.7` under the KPI1 area **Observability / logging**. 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. + + diff --git a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md similarity index 84% rename from tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md index 9419dbf0..cec5cc65 100644 --- a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.3.1] Sharing agreement: Negotiation - Refusal or registration of sharing agreement +## [4.2.3.1] Sharing agreement: Negotiation - Refusal or registration of sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Security and restricted access | | Existing test ID | `4.2.3.1` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The test aims to evaluate whether the negotiation API, status messages, and nego Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,20 +66,22 @@ The result should clearly indicate which deployment model was assessed. It is ac | **Criteria** | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | -| **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. | TBD | TBD | Pending EMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| **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. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional Suitability Quality Metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.3.1` under the KPI1 area **Security and restricted access**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `4.2.3.1` 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. + + diff --git a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md similarity index 76% rename from tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md rename to tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md index 1bc79158..3a0541b5 100644 --- a/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_emds_final_stack.md +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md @@ -1,18 +1,18 @@ -## [4.2.3.2] Sharing agreement: Negotiation - Refusal or registration of sharing agreement +## [4.2.3.2] Sharing agreement: Negotiation - Refusal or registration of sharing agreement -### Stack: EMDS Final Stack (EDC-based) +### Stack: protoEMDS Final Stack (EDC-based) ### Statement of assessment #### Environment -This section identifies the technical context in which the EMDS Final Stack assessment is performed. +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 | `emds_final_stack` | -| Stack under assessment | EMDS Final Stack (EDC-based) | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | | KPI1 area | Observability / logging | | Existing test ID | `4.2.3.2` | | Level | Technical | @@ -31,11 +31,11 @@ If only one deployment model is assessed, the other one should be marked as `Not #### Tested quality metric and method -This result reuses the existing stack-agnostic test definition in `test.md` and adds an EMDS Final Stack integration-assessment perspective. +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 EMDS Final Stack deployment. +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 @@ -51,7 +51,7 @@ The expected outcome of the current test is to evaluate whether the system provi Pending. -The assessment should be completed once consolidated technical evidence is available for the EMDS Final Stack deployment. +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. @@ -66,21 +66,23 @@ The result should clearly indicate which deployment model was assessed. It is ac | Criteria | Measured KPI | Evidence | Notes | | --- | ---: | --- | --- | -| No traceability. | TBD | TBD | Pending EMDS Final Stack assessment. | -| System logs, which record only a connection between two connectors using non-data space identifiers such as a public URL or IP address. | TBD | TBD | Pending EMDS Final Stack assessment. | -| Application logs that include process information, for example, "Connector control plane initiating on port...". | TBD | TBD | Pending EMDS Final Stack assessment. | -| Data space protocol status traces, such as "Data sharing agreement request". | TBD | TBD | Pending EMDS Final Stack assessment. | -| Data space protocol transaction traces, for instance, "Contract ID Op: negotiation". | TBD | TBD | Pending EMDS Final Stack assessment. | -| A complete data space protocol context dump, including the entire JSON dump with references. | TBD | TBD | Pending EMDS Final Stack assessment. | +| No traceability. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| System logs, which record only a connection between two connectors using non-data space identifiers such as a public URL or IP address. | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Application logs that include process information, for example, "Connector control plane initiating on port...". | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Data space protocol status traces, such as "Data sharing agreement request". | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Data space protocol transaction traces, for instance, "Contract ID Op: negotiation". | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| A complete data space protocol context dump, including the entire JSON dump with references. | TBD | TBD | Pending protoEMDS Final Stack assessment. | **Functional suitability quality metric:** TBD #### Notes -This result introduces an **EMDS Final Stack** perspective for the existing test `4.2.3.2` under the KPI1 area **Observability / logging**. +This result introduces an **protoEMDS Final Stack** perspective for the existing test `4.2.3.2` under the KPI1 area **Observability / logging**. 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. + +