1.3.1.5
Participant onboarding: Certification - Identity and credentials issuance
Coverage: Assess the coverage of a minimally viable credential lifecycle is supported: request (credentials), issuance, validation, renewal, revocation.
The description of Test 1.3.1.5 was extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.
Information
-
Phase 1
-
Minimal? Yes
-
Related KPIs:
- Security: [Integrity] The credential issuance/verification services implements the minimum viable controls to manage the issuance and renewal/revoking of credentials and certificates.
-
Evaluation Criteria:
To calculate an overall score from the list of criteria, you can use the average of the individual scores for each VC Lifecycle Stage. Here is the updated table with a formula for calculating the overall score:
| VC Lifecycle Stage | Coverage | Score (0-4) |
|---|---|---|
| Issuance and Storage | ||
| Presentation | ||
| Verification & Use | ||
| Revocation/Expiration | ||
| Renewal/Re-Issuance |
Formula to Calculate Overall Score:
Overall Score = (Score_Issuance + Score_Presentation + Score_Verification + Score_Revocation + Score_Renewal) / 5
Results
- Fiware
- protoEMDS Final Stack (EDC-based)
- EDC + VC
The results for Test 1.3.1.5 for Fiware were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.
Environment
The test is conducted in the IONOS FIWARE_cluster cluster using node pool IP 85.215.161.198.
Tested quality metric and method
The test quality is based on the metric defined in iso27001_kpis_subkpis.xlsx. For the current phase (phase 1), the test focuses on the Functional Suitability quality metric.
Expected output
The expected output of the test is an assessment of whether the FIWARE connector supports the full credential lifecycle, including request, issuance, validation, renewal, and revocation.
Results
Assessment
Verifiable Credential Issuance
- The access token is created accessing keycloak test realm portal using the following command:
export ACCESS_TOKEN=$(curl --insecure -v -X POST https://keycloak.demo-portal.eu/realms/test-realm/protocol/openid-connect/token \
--header 'Accept: */*' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=password \
--data client_id=admin-cli \
--data username=admin-user \
--data password=test | jq '.access_token' -r); echo ${ACCESS_TOKEN}
- Check credential_configuration_id from Keycloak credential issuer info endpoint
curl --insecure -v -X GET https://keycloak.demo-portal.eu/realms/test-realm/.well-known/openid-credential-issuer
- Get offer uri
export OFFER_URI=$(curl --insecure -s -X GET 'https://keycloak.demo-portal.eu/realms/test-realm/protocol/oid4vc/credential-offer-uri?credential_configuration_id=natural-person' \
--header "Authorization: Bearer ${ACCESS_TOKEN}" | jq '"\(.issuer)\(.nonce)"' -r); echo ${OFFER_URI}
- Get Pre_authorized_code
export PRE_AUTHORIZED_CODE=$(curl --insecure -s -X GET ${OFFER_URI} \
--header "Authorization: Bearer ${ACCESS_TOKEN}" | jq '.grants."urn:ietf:params:oauth:grant-type:pre-authorized_code"."pre-authorized_code"' -r); echo ${PRE_AUTHORIZED_CODE}
- Get Credential_access_token
export CREDENTIAL_ACCESS_TOKEN=$(curl --insecure -s -X POST https://keycloak.demo-portal.eu/realms/test-realm/protocol/openid-connect/token \
--header 'Accept: */*' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code \
--data code=${PRE_AUTHORIZED_CODE} | jq '.access_token' -r); echo ${CREDENTIAL_ACCESS_TOKEN}
Request Verifiable Credential 6) Get Verifiable Credential
export VERIFIABLE_CREDENTIAL=$(curl --insecure -s -X POST https://keycloak.demo-portal.eu/realms/test-realm/protocol/oid4vc/credential \
--header 'Accept: */*' \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer ${CREDENTIAL_ACCESS_TOKEN}" \
--data '{"credential_identifier":"natural-person", "format":"jwt_vc"}' | jq '.credential' -r); echo ${VERIFIABLE_CREDENTIAL}
Verify Credentials
Credential verification is done using the Verifiert component. For more information consult: https://github.com/FIWARE/VCVerifier?tab=readme-ov-file#overview
Revoke Credentials User revocation is not available. However, since the vcverifier does check the existence of a participant in the TIR. Participants could be deleted from the TIR and then the access would be revoked.
Measured results
The VC lifecycle is partially covered by the FIWARE connector as follows:
| VC Lifecycle Stage | Coverage | Score (0-4) |
|---|---|---|
| Issuance and Storage | Covered | 4 |
| Presentation | Covered | 4 |
| Verification & Use | Covered | 4 |
| Revocation/Expiration | Not fully covered. API does not support it, but participants can be deleted to stop access. | 2 |
| Renewal/Re-Issuance | Not covered, but participants can be created and deleted. | 1 |
Overall Calculation: (4+4+4+2+1)/5 = 3
Functional Suitability Quality Metric Score: 3
The results for Test 1.3.1.5 for protoEMDS Final Stack (EDC-based) were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.
Environment
This section identifies the technical context in which the protoEMDS Final Stack assessment is performed.
| Field | Value |
|---|---|
| Assessment context | Integration phase assessment of the EMDS final technical infrastructure |
| Result perspective | protoemds_final_stack |
| Stack under assessment | protoEMDS Final Stack (EDC-based) |
| KPI1 area | 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.
The results for Test 1.3.1.5 for EDC + VC were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.
Environment
- The test is conducted in a local environment using IntelliJ IDE.
- The EDC MVD commit used is 650ed8f.
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 the test is an assessment of whether the EDC supports the full credential lifecycle, including request, issuance, validation, renewal, and revocation.
Results
Assessment
Protocol Support
The EDC identity hub implements the Eclipse Dataspace Decentralized Claims Protocol, also known as Identity And Trust Specifications. The protocol covers the credential issuance protocol and verifiable presentation protocol.
Current Implementation of the Protocol
The EDC identity hub version 0.8.1-SNAPSHOT provides endpoints for:
- Querying verifiable credentials:
/v1alpha/credentials
- Revoking verifiable credentials:
/v1alpha/participants/{participantId}/credentials/{credentialId}
- Presenting verifiable credentials:
/v1/participants/{participantId}/presentations/query
Additional identity management APIs are available identity-api.yaml. and ih-resolution-api.yaml.
However, the implementation of the Credential Issuance Protocol is planned for future updates and has not been implemented yet.
Evaluation of MVD Commit 650ed8f
The VC lifecycle is partially covered by the EDC MVD as follows:
- Issuance and Storage: Available with the workaround extension function
seedCredentials. - Presentation: Covered.
- Verification & Use: Covered, using public key validation as explained in edc-did. The validation function is in TokenValidationService.
In the MVD, a mock
DID Resolveris used to resolve the DID of the participant. - Revocation/Expiration: Covered, with API support for revoking verifiable credentials.
- Renewal/Re-Issuance: Not covered; renewal and re-issuance are not yet implemented.
The following sequence is performed whenever a request is received:
C ... Consumer, P ... Provider, CIH ... Consumer's Identity Hub, VC ... Verifiable Credential
- C presents JWT to P (in message header, i.e. in the authorization header)
- P resolves the DID URL from the VC received from C
- P resolves C's DID Document from the DID URL (in current case is the CIH)
- P verifies C's VC using C's public key (from the DID Document)
- P sends query to
CredentialServiceendpoint for the VC presentation of C, A typicalCredentialServiceis e.g.http://{service_url}/api/resolution/v1/participants/, the endpoint ofCredentialServiceis in the DID Document. - p validate the VPs using the public key of the VC issuer (from the DID Document)
- P looks for the expected claims in the VP
- P applies the claims to the policy and makes a decision.
Measured Results
The EDC implementation partially covers the VC lifecycle as outlined above. Based on the criteria outlined in the Comparative criteria (checklists, ...) section of the test description, the test is assigned the following score:
| VC Lifecycle Stage | Coverage | Score (0-4) |
|---|---|---|
| Issuance and Storage | Available with the workaround extension function seedCredentials. | 0 |
| Presentation | Covered | 4 |
| Verification & Use | Covered | 4 |
| Revocation/Expiration | Covered | 4 |
| Renewal/Re-Issuance | Not covered. | 0 |
Overall Calculation: (0+4+4+4+0)/5 = 2.4 Functional Suitability Quality Metric Score: 2.4
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 is a pluggable ecosystem primarily targeting Java/Kotlin developers. While some extensions are available for plug-and-play, specific use cases may require developers to create their own extensions.