1.3.1.1A
Participant onboarding: Certification - Identity and credentials issuance
Test: Prove that the stack uses a credential framework that is compatible with this initiative: Gaia-X
The description of Test 1.3.1.1A was extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.
Information
-
Phase 1
-
Minimal? Yes
-
Related KPIs:
- Functional suitability: [Completeness] The credential framework supports attestations and (multiple?) trust anchors.
-
Evaluation Criteria:
The test assigns a numeric score based on the assessment, using the Functional Suitability metric from iso27001_kpis_subkpis.xlsx.
| Criteria | Scoring |
|---|---|
| No Coverage: The solution fails to meet any of the specified technical requirements. This indicates a complete lack of implementation concerning the requirements. The solution does not support using, issuing or validating verifiable credentials. | 0 |
| Minimal Coverage: The solution meets up to 25% of the technical requirements. The solution has minimal support for verifiable credentials. For example, a credential will be accepted and its signature checked. However, significant gaps exist, such as lack of compatibility with different credential types, no support for SD classes or integration with external trust intermediaries. | 1 |
| Partial Coverage: The solution satisfies approximately 50% of the technical requirements. The solution supports self-issued credentials with support for SD classes. The solution supports a GAIA-X compatible DID method but without any compliance or claim verification. | 2 |
| Significant Coverage: The solution covers about 80% of the technical requirements. Most key functionalities are implemented effectively. The solution supports and uses GAIA-X trust anchors. The stack has a service that verifies credential compliance and a connector has policies to ensure a participant has compliant GAIA-X descriptors. | 3 |
| Full Coverage: The solution fully meets all technical requirements, the stack implements policies that can use SD classes to interpret claims and use a GXDCH clearing house for business purposes. | 4 |
Results
- EDC+VC
- Fiware
The results for Test 1.3.1.1A for EDC+VC were extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.
Environment
- EDC IdentityHub 0.8.0
- Gaia-X VC Wizard
- EDC- MinimumViableDataspace: 2c7701
- Local deployment with MVD .run
Tested quality metric and method
The quality metric for this test is based on the criteria outlined in iso27001_kpis_subkpis.xlsx. In Phase 1, the focus is on the Functional Suitability metric. For detailed information, please refer to the Comparative criteria (checklists, ...) section in the test description.
Expected output
The expected output of this test is to evaluate the level of customization required to integrate Gaia-X issued VC to EDC Ecosystem
Test procedure
- Generate a self-issued (Not Signed) VC using the Gaia-X VC Wizard
with
IMEC VAT Identifier.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/suites/jws-2020/v1",
"https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/trustframework#"
],
"type": ["VerifiableCredential"],
"id": "did:web:wizard.lab.gaia-x.eu:api:credentials:2d37wbGvQzbAQ84yRouh2m2vBKkN8s5AfH9Q75HZRCUQmJW7yAVSNKzjJj6gcjE2mDNDUHCichXWdMH3S2c8AaDLm3kXmf5R8DWA1SrzhRkGLQLXtXP852M7hoH5hPXGueYtSN6cWyvnrXGkEYnXxDojTAVkCe44TbAPCXzgryYv33pwdVYxMoD1VDrMv9g6WksqPg6Ab76NNqEBPQR6Ncw8suXEGyMUqyZ53zrv1WNhmbNA8mt53AdL7WouUwX97gSuo5gYeBCNhbHULH2z8P1fFLCvWwTLj1Mh99fEtcdwzUeKZ9nXE7ULVvSmB9XLycHA59ArGK95ffgtTqpsVZ5DWBLEExPivNuNsBx2B5QzQDTcyucLgfnZXUXDW5A2jDgTJuAn5YQxkr6zcdvhX7jR8jbttZYYfEcRAgCNpF2tWFSBNHP3HNmjhHESHSjdRiCGPCGZ5VoRi7d9EFX3xPy8uXooe5pB5WTZAzmReFdDJZJnamFmY47VL36A8Hs5AxLKVbSBtnHMPZbSVvQgZnRMhPCJZyQEdLJj8xVdegcfx1B75vrst1e5ipyRKJsKxDHkHb6VHBB1h6fp7PskbJFDHGNAvdm8VSxccn8?uid=600f377a-ac0e-4628-abc6-334352861bf9",
"issuer": "did:web:wizard.lab.gaia-x.eu:api:credentials:REDACTED",
"issuanceDate": "2024-07-17T13:39:37.965Z",
"credentialSubject": {
"gx:legalName": "IMEC",
"gx:headquarterAddress": {
"gx:countrySubdivisionCode": "BE-LEU"
},
"gx:legalRegistrationNumber": {
"id": "https://wizard.lab.gaia-x.eu/api/credentials/2d37wbGvQzbAQ84yRouh2m2vBKkN8s5AfH9Q75HZRCUQmJW7yAVSNKzjJj6gcjE2mDNDUHCichXWdMH3S2c8AaDLm3kXmf5R8DWA1SrzhRkGLQLXtXP852M7hoH5hPXGueYtSN6cWyvnrXGkEYnXxDojTAVkCe44TbAPCXzgryYv33pwdVYxMoD1VDrMv9g6WksqPg6Ab76NNqEBPQR6Ncw8suXEGyMUqyZ53zrv1WNhmbNA8mt53AdL7WouUwX97gSuo5gYeBCNhbHULH2z8P1fFLCvWwTLj1Mh99fEtcdwzUeKZ9nXE7ULVvSmB9XLycHA59ArGK95ffgtTqpsVZ5DWBLEExPivNuNsBx2B5QzQDTcyucLgfnZXUXDW5A2jDgTJuAn5YQxkr6zcdvhX7jR8jbttZYYfEcRAgCNpF2tWFSBNHP3HNmjhHESHSjdRiCGPCGZ5VoRi7d9EFX3xPy8uXooe5pB5WTZAzmReFdDJZJnamFmY47VL36A8Hs5AxLKVbSBtnHMPZbSVvQgZnRMhPCJZyQEdLJj8xVdegcfx1B75vrst1e5ipyRKJsKxDHkHb6VHBB1h6fp7PskbJFDHGNAvdm8VSxccn8#279da7e31cce892065abd510920db68bc5996d55f4432763d16a407590115e94"
},
"gx:legalAddress": {
"gx:countrySubdivisionCode": "BE-LEU"
},
"type": "gx:LegalParticipant",
"gx-terms-and-conditions:gaiaxTermsAndConditions": "70c1d713215f95191a11d38fe2341faed27d19e083917bc8732ca4fea4976700",
"id": "did:web:wizard.lab.gaia-x.eu:api:credentials:2d37wbGvQzbAQ84yRouh2m2vBKkN8s5AfH9Q75HZRCUQmJW7yAVSNKzjJj6gcjE2mDNDUHCichXWdMH3S2c8AaDLm3kXmf5R8DWA1SrzhRkGLQLXtXP852M7hoH5hPXGueYtSN6cWyvnrXGkEYnXxDojTAVkCe44TbAPCXzgryYv33pwdVYxMoD1VDrMv9g6WksqPg6Ab76NNqEBPQR6Ncw8suXEGyMUqyZ53zrv1WNhmbNA8mt53AdL7WouUwX97gSuo5gYeBCNhbHULH2z8P1fFLCvWwTLj1Mh99fEtcdwzUeKZ9nXE7ULVvSmB9XLycHA59ArGK95ffgtTqpsVZ5DWBLEExPivNuNsBx2B5QzQDTcyucLgfnZXUXDW5A2jDgTJuAn5YQxkr6zcdvhX7jR8jbttZYYfEcRAgCNpF2tWFSBNHP3HNmjhHESHSjdRiCGPCGZ5VoRi7d9EFX3xPy8uXooe5pB5WTZAzmReFdDJZJnamFmY47VL36A8Hs5AxLKVbSBtnHMPZbSVvQgZnRMhPCJZyQEdLJj8xVdegcfx1B75vrst1e5ipyRKJsKxDHkHb6VHBB1h6fp7PskbJFDHGNAvdm8VSxccn8#6d9367bd0d7d3c21181acd57000beb8474dd4f1c4a004be812c24cfadaca697c"
}
}
- Deploy the EDC- MinimumViableDataspace: 2c7701 to local environment inside IntelliJ IDEA. Mount the above-mentioned VC to the IdentityHub, by adding it under deployment assets of the MVD.
- Spin up the EDC MVD, and query the IdentityHub API
/api/identity/v1alpha/credentialsto check if the VC is stored.
Test result
The Identity Hub API returns the stored VC, and the returned payload is as follows:
[
{
"participantId": null,
"id": "did:web:wizard.lab.gaia-x.eu:api:credentials:2d37wbGvQzbAQ84yRouh2m2vBKkN8s5AfH9Q75HZRCUQmJW7yAVSNKzjJj6gcjE2mDNDUHCichXWdMH3S2c8AaDLm3kXmf5R8DWA1SrzhRkGLQLXtXP852M7hoH5hPXGueYtSN6cWyvnrXGkEYnXxDojTAVkCe44TbAPCXzgryYv33pwdVYxMoD1VDrMv9g6WksqPg6Ab76NNqEBPQR6Ncw8suXEGyMUqyZ53zrv1WNhmbNA8mt53AdL7WouUwX97gSuo5gYeBCNhbHULH2z8P1fFLCvWwTLj1Mh99fEtcdwzUeKZ9nXE7ULVvSmB9XLycHA59ArGK95ffgtTqpsVZ5DWBLEExPivNuNsBx2B5QzQDTcyucLgfnZXUXDW5A2jDgTJuAn5YQxkr6zcdvhX7jR8jbttZYYfEcRAgCNpF2tWFSBNHP3HNmjhHESHSjdRiCGPCGZ5VoRi7d9EFX3xPy8uXooe5pB5WTZAzmReFdDJZJnamFmY47VL36A8Hs5AxLKVbSBtnHMPZbSVvQgZnRMhPCJZyQEdLJj8xVdegcfx1B75vrst1e5ipyRKJsKxDHkHb6VHBB1h6fp7PskbJFDHGNAvdm8VSxccn8?uid=600f377a-ac0e-4628-abc6-334352861bf9",
"timestamp": 0,
"issuerId": null,
"holderId": null,
"state": 0,
"timeOfLastStatusUpdate": null,
"issuancePolicy": null,
"reissuancePolicy": null,
"verifiableCredential": null
}
]
Comparative criteria (checklists, ...)
-
Does the stack support VC?
-
The stack supports self-issued VCs
-
The stack supports self-issued VCs with support for SD classes?
-
The stack supports self-issued VCs where SD classes don't break the VC manager, a GAIA-X compatible DID method can be used. No compliance or claim verification are mandatory, just a smoke test.
-
The stack uses GAIA-X trust anchors. -> N/A, This test requires the setup of a GXDCH infrastructure that we don't have, yet.
-
The stack has a service that verifies credential compliance and a connector has policies to ensure a participant has compliant GAIA-X descriptors -> N/A, requires GAIA-X infrastructure
-
The stack implements policies that can use SD classes to interpret claims and use a GXDCH clearing house for business purposes -> N/A, requires GAIA-X infrastructure
Results
- As previously mentioned, the Gaia-X generated VC does not cause any EDC component to crash and can be integrated with the Identity Hub without issues.
- However, the Gaia-X VC lacks fields expected by the Identity Hub, such as participantId.
- Additionally, Identity Hub is unable to properly parse the Gaia-X VC because there is no issuance flow implemented yet. The IdentityHubExtension#seedCredentials() extension, used as a workaround to seed credentials for mocking the issuance flow, cannot parse Gaia-X credentials. This is evident from the improperly parsed credentials in the response payload from the Identity Hub API. However, EDC supports LDP-VC and LDP-VPs if the credential can be seeded correctly, with certain limitations regarding the supported signature suites and the intermixing of LDP-VC and JWT-VCs. Identity Hub uses the VC 1.1 data model for LDP-VCs.
- To support parsing of Gaia-X VC,
VerifiableCredentialResourceneeds to be adapted. - Moreover, there is no out-of-the-box solution from EDC for resolving the DID method used by Gaia-X VC, and the VC issuance flow is also currently missing in the Identity Hub.
Assessment result
Based on the criteria outlined in the Comparative criteria (checklists, ...) section of the test description, the test is assigned the following score:
[x] Does the stack support VC? - PASS
[x] The stack supports self-issued VCs - PASS
[x] The stack supports self-issued VCs with support for SD classes? - PASS
[X] The stack supports self-issued VCs where SD classes don't break the VC manager, a GAIA-X compatible DID method can be used. No compliance or claim verification are mandatory, just a smoke test. - PASS, but EDC cannot parse the VC.
[] The stack uses GAIA-X trust anchors. -> N/A, This test requires the setup of a GXDCH infrastructure that we don't have, yet. EDC doesn't have an open-box solution for integrating Gaia-X trust anchor.
[] The stack has a service that verifies credential compliance and a connector has policies to ensure a participant has compliant GAIA-X descriptors -> N/A, requires GAIA-X infrastructure. EDC doesn't have an open-box solution for integrating Gaia-X trust anchor.
[] The stack implements policies that can use SD classes to interpret claims and use a GXDCH clearing house for business purposes -> N/A, requires GAIA-X infrastructure. EDC doesn't have an open-box solution for integrating Gaia-X trust anchor.
Functional suitability quality metric: 2
Notes
-
EDC components are plugin-based. Support for various verifiable credential formats is possible by implementing a plugin (this applies to both decentralized as well as centralized solutions). For example, support for web DID resolution is just a preview of a method that can be created. See docs.
-
EDC ecosystem primarily targets Java/Kotlin developers. Some extensions are available on the market for plug-and-play, but for certain specific use cases, developers need to write their own extensions.
The results for Test 1.3.1.1A for Fiware were extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.
Environment
The test is conducted in the IONOS FIWARE_cluster cluster using node pool IP 85.215.161.198.
Tested quality metric and method
The test quality is based on the metric defined in iso27001_kpis_subkpis.xlsx. For the current phase (phase 1), the test focuses on the Functional Suitability quality metric.
Comparative criteria (checklists, ...)
Asses that the stack uses a credential framework that is compatible with this initiative: Gaia-X
Expected output
Compatibility specifications regarding Gaia-X.
Results
Assessment
The documentation states in the onboarding steps that the organization validates that the VC containing its description as organization is compliant with Gaia-X specifications using the services of a Gaia-X Digital Clearing House. Therefore it is compatible with Gaia-X framework.
Measured results
The FIWARE Connector provides partial coverage as it supports self-issued credentials, including GAIA-X compatible DID methods. However, it lacks comprehensive compliance or claim verification capabilities. While it supports key functionalities like ABAC and OPA integration, it does not fully implement policies for interpreting claims using SD classes or leveraging a GXDCH clearing house for business purposes.
Score: 2 (Partial Coverage)
Functional Suitability Quality Metric Score: 2
Notes
More information about it: https://github.com/FIWARE/data-space-connector