diff --git a/README.md b/README.md index 5cdfd574..c1bc485a 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 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 -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,192 @@ 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 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 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 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. ![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 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 `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_protoemds_final_stack.md` + +The assessment should distinguish the deployment model used for the evidence collected: +| 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. + +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. + +# protoEMDS Final Stack selected test overview + +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 `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 | [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 -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. +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. + + + diff --git a/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md new file mode 100644 index 00000000..75a11346 --- /dev/null +++ b/tests/data_product_publication/provision/data_source_endpoint_provisioning/test_2_1_1_3/result_protoemds_final_stack.md @@ -0,0 +1,112 @@ +## [2.1.1.3] Data product publication: Provision - Data source endpoint provisioning + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 - [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 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 + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **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 **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_protoemds_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 new file mode 100644 index 00000000..82517eeb --- /dev/null +++ b/tests/data_product_publication/provision/reuse_or_create_usage_control_policies_functions/test_2_1_3_1/result_protoemds_final_stack.md @@ -0,0 +1,100 @@ +## [2.1.3.1] Data product publication: Provision - Reuse or create usage control policies / functions + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..fcd4f191 --- /dev/null +++ b/tests/data_product_publication/publication/deploy_config_usage_control_functions/test_2_2_2_1/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [2.2.2.1] Data product publication: Publication - Deploy/config usage control functions + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md new file mode 100644 index 00000000..5b92fcb0 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1a/result_protoemds_final_stack.md @@ -0,0 +1,88 @@ +## [2.2.3.1A] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the 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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Criteria | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md new file mode 100644 index 00000000..3912f808 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1b/result_protoemds_final_stack.md @@ -0,0 +1,88 @@ +## [2.2.3.1B] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the 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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Criteria | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md new file mode 100644 index 00000000..713f501d --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_1d/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [2.2.3.1D] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the 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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md new file mode 100644 index 00000000..6728a389 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_emds_catalogue/test_2_2_3_3/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [2.2.3.3] Data product publication: Publication - Publication on EMDS catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Criteria | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md new file mode 100644 index 00000000..5aa4d36f --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_2/result_protoemds_final_stack.md @@ -0,0 +1,84 @@ +## [2.2.5.2] Data product publication: Publication - Publication on federated data spaces + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| 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 **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_protoemds_final_stack.md b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md new file mode 100644 index 00000000..ae0fc010 --- /dev/null +++ b/tests/data_product_publication/publication/publication_on_federated_data_spaces/test_2_2_5_7/result_protoemds_final_stack.md @@ -0,0 +1,84 @@ +## [2.2.5.7] Data product publication: Publication - Publication on federated data spaces + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| 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 **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_protoemds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..1bada4a4 --- /dev/null +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_1/result_protoemds_final_stack.md @@ -0,0 +1,89 @@ +## [3.1.1.1] Data product survey: Discover - Consult data space catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md new file mode 100644 index 00000000..116252f4 --- /dev/null +++ b/tests/data_product_survey/discover/consult_data_space_catalogue/test_3_1_1_4/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [3.1.1.4] Data product survey: Discover - Consult data space catalogue + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..d336cb02 --- /dev/null +++ b/tests/data_sharing/data_sharing_activities/enforce_usage_control/test_5_2_1_1/result_protoemds_final_stack.md @@ -0,0 +1,95 @@ +## [5.2.1.1] Data sharing: Data sharing activities - Enforce usage control + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | Usage control enforcement | +| Existing test ID | `5.2.1.1` | +| Level | Technical | +| ISO/IEC 25010 mapping | Security, Maintainability | +| Owner (tentative) | Xavier (Eurocat) | +| Reviewer | Xavier | +| Deployment model assessed | TBD | +| Target environment | TBD | +| EDC version / release | TBD | +| Connector deployment reference | TBD | +| Assessment evidence | TBD | + +The assessment should be completed using the deployment model for which evidence is realistically available. It is not mandatory to execute the same test in both CaaS and on-premise environments. + +If only one deployment model is assessed, the other one should be marked as `Not assessed`. + +#### Tested quality metric and method + +This result reuses the existing stack-agnostic test definition in `test.md` and adds an protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test the policies that are supported out of the box. +For the policies that are not supported, describe the effort of how to build them, and rank the system consequently (e.g.: create a plugin in a documented environment ranks better than integrating an external function that introduces dependencies and interface maintenance). + +#### Expected Output + +Usage control is defined based on the IDSA Position Paper “[Data Usage Control in IDS](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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Criteria | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| No out of the box policies | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| No out of the box policies but policies are available from a library | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Partial out-of-the-box-policies | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Full set of out-of-the-box policies | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Documented way to create/expand policies | TBD | TBD | Pending protoEMDS Final Stack assessment. | +| Documented way to create/expand policies + templates for basic polices | TBD | TBD | Pending protoEMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **protoEMDS Final Stack** perspective for the existing test `5.2.1.1` under the KPI1 area **Usage control enforcement**. + +This result should not be interpreted as part of the original Phase 1 / Phase 2 stack-comparison campaign. It is intended as an integration phase assessment of the current EMDS final technical infrastructure. + +The assessment should be completed using consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner. + +This result file was generated from the local `test.md` and, where available, the local `result_edc_vc.md` structure. EDC+VC-specific evidence, values and scores were intentionally not reused. + + diff --git a/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..ebf6f232 --- /dev/null +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_1/result_protoemds_final_stack.md @@ -0,0 +1,101 @@ +## [5.1.1.1] Data sharing: Data sharing request - Request data transfer + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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`. + +#### Tested quality metric and method + +This result reuses the existing stack-agnostic test definition in `test.md` and adds an protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 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 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 + +#### Assessment + +Pending. + +The assessment should be completed once consolidated technical evidence is available for the protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| 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 **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_protoemds_final_stack.md b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md new file mode 100644 index 00000000..2b7f05ad --- /dev/null +++ b/tests/data_sharing/data_sharing_request/request_data_transfer/test_5_1_1_2/result_protoemds_final_stack.md @@ -0,0 +1,99 @@ +## [5.1.1.2] Data sharing: Data sharing request - Request data transfer + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| 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 **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_protoemds_final_stack.md b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md new file mode 100644 index 00000000..8b202f51 --- /dev/null +++ b/tests/participant_onboarding/certification/identity_and_credentials_issuance/test_1_3_1_5/result_protoemds_final_stack.md @@ -0,0 +1,88 @@ +## [1.3.1.5] Participant onboarding: Certification - Identity and credentials issuance + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **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 **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_protoemds_final_stack.md b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..a44afcf0 --- /dev/null +++ b/tests/participant_onboarding/evaluation/self-assessment/test_1_2_1_1/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [1.2.1.1] Participant onboarding: Evaluation - Self-assessment + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **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 **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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..54c87ab0 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_1/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [4.2.1.1] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +Test 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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md new file mode 100644 index 00000000..87c9fe38 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_3/result_protoemds_final_stack.md @@ -0,0 +1,95 @@ +## [4.2.1.3] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md new file mode 100644 index 00000000..1577b766 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_6/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [4.2.1.6] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | Security and restricted access | +| Existing test ID | `4.2.1.6` | +| Level | Technical | +| ISO/IEC 25010 mapping | Security | +| Owner (tentative) | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md new file mode 100644 index 00000000..e3710383 --- /dev/null +++ b/tests/sharing_agreement/negotiation/negotiating_sharing_agreement/test_4_2_1_7/result_protoemds_final_stack.md @@ -0,0 +1,83 @@ +## [4.2.1.7] Sharing agreement: Negotiation - Negotiating sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Requirement | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| Test-specific requirement from `test.md` | TBD | TBD | Pending protoEMDS Final Stack assessment. | + +**Functional Suitability Quality Metric:** TBD + +#### Notes + +This result introduces an **protoEMDS Final Stack** perspective for the existing test `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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md new file mode 100644 index 00000000..cec5cc65 --- /dev/null +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_1/result_protoemds_final_stack.md @@ -0,0 +1,87 @@ +## [4.2.3.1] Sharing agreement: Negotiation - Refusal or registration of sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | Security and restricted access | +| Existing test ID | `4.2.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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| **Criteria** | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| **No 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 **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_protoemds_final_stack.md b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md new file mode 100644 index 00000000..3a0541b5 --- /dev/null +++ b/tests/sharing_agreement/negotiation/refusal_or_registration_of_sharing_agreement/test_4_2_3_2/result_protoemds_final_stack.md @@ -0,0 +1,88 @@ +## [4.2.3.2] Sharing agreement: Negotiation - Refusal or registration of sharing agreement + +### Stack: protoEMDS Final Stack (EDC-based) + +### Statement of assessment + +#### Environment + +This section identifies the technical context in which the protoEMDS Final Stack assessment is performed. + +| Field | Value | +| --- | --- | +| Assessment context | Integration phase assessment of the EMDS final technical infrastructure | +| Result perspective | `protoemds_final_stack` | +| Stack under assessment | protoEMDS Final Stack (EDC-based) | +| KPI1 area | 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 protoEMDS Final Stack integration-assessment perspective. + +It does not replace the historical stack-specific result files, such as `result_edc_vc.md` or `result_fiware.md`. + +The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment. + +#### Test-specific assessment scope + +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 protoEMDS Final Stack deployment. + +The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available. + +#### Deployment model assessed + +| Deployment model | Status | Evidence | Consolidated assessment | +| --- | --- | --- | --- | +| CaaS / IONOS-managed deployment | TBD | TBD | Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as `Not assessed`. | +| On-premise deployment | TBD | TBD | Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as `Not assessed`. | + +#### Measured results + +| Criteria | Measured KPI | Evidence | Notes | +| --- | ---: | --- | --- | +| No 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 **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. + + diff --git a/web/docs/tech-testing/way-of-working.mdx b/web/docs/tech-testing/way-of-working.mdx index afabc67f..297392e9 100644 --- a/web/docs/tech-testing/way-of-working.mdx +++ b/web/docs/tech-testing/way-of-working.mdx @@ -5,9 +5,10 @@ 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 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 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 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 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.