Feature/kpi1 emds integration baseline

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

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

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