1.2.1.1

Participant onboarding: Evaluation - Self-assessment

Assessment: If an onboarding online facility is provided, evaluate the level of customisation required to input participants’ metadata.

note

The description of Test 1.2.1.1 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: A self-assessment process exists with well-defined inputs and outputs standardised information that will be a relevant part of the profile of the aspiring participant.

• Evaluation Criteria:

The criteria used to measure the results was the one specified by the Data Product Publication ISO25010 Quality file regarding Functional Suitability.

Criterion	Description	Score (0-4)
Functional Completeness	Technical requirements cover all the specified tasks and user objectives.
Functional Correctness	Technical requirements meet results with the needed degree of precision.
Functional Appropriateness	Technical requirements facilitate the accomplishment of specified tasks and objectives.

Results

EDC+VC

note

The results for Test 1.2.1.1 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

• The test is carried in the IONOS environment as documented in the edc_mvd_deployment.md
• The test uses the EDC MVD commit [84f3c5f7] (https://github.com/eclipse-edc/MinimumViableDataspace/commit/84f3c5f70b4eea94de7ebee83da377e62fc759fd)

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 input participants' metadata if an onboarding online facility is provided.

Results

Assessment

Onboarding Online Facility Scope

The scope of the onboarding online facility is detailed in the EDC MVD commit 84f3c5f7, which includes:

• EDC Connector
• Identity Hub (EDC component)

Evaluation of MVD Commit [84f3c5f7] (https://github.com/eclipse-edc/MinimumViableDataspace/commit/84f3c5f70b4eea94de7ebee83da377e62fc759fd).

The MVD participates in the onboarding procedure as outlined in the MVD version tag: 84f3c5f7.

• The MVD uses an extension to mount the pre-configured verifiable credentials to the Identity Hub with the configurable key edc.mvd.credentials.path: Link. The mounting action is provided by this extension.

• Managing the access key of the protected API of the Identity Hub is achieved by provisioning a super user with this extension:

  IdentityHub's Identity API does not provide a feature for participant self-registration, as it is not an end-user-facing API. This is intentional. New participant contexts must be created by the super-user.

  For more details, refer to the IdentityHub API documentation.

• The Identity Hub does not currently provide an API for storing verifiable credentials issued by an issuer: Storage API documentation (tag: 2de93ac6add4b34d499eb210471d4e0590f5d0c3).

Evaluation of Identity hub commit 572a6b0

Identithy hub provides following APIs

• identity-api contains the functions for CRUD on the Verifiable Credentials, Key Pairs, DID, and Participant Context.
• ih-resolution-api contains VC presentation /v1/participants/{participantId}/presentations/query

Measured results

The MVD test link demonstrates onboarding a new participant to the Dataspace system. However, the entire onboarding process is not fully implemented in the EDC system and is not user-friendly for non-technical users. The DID resolver must be implemented to resolve the participant's DID, which depends on the specific DID method used. Besides that, the VC insurance flow is currently missing in the Identity hub.

Is the feature available out of the box in EDC+VC (without the need for development)? No, plugin adoption is required. Given a development effort, is it possible to implement to the fullest extent of the spec? Yes, but the DID resolver is context-specific.

Based on the criteria outlined in the Comparative criteria (checklists, ...) section of the test description, the test is assigned the following score:

Criterion	Description	Score (0-4)	Explanation
Functional Completeness	Technical requirements cover all the specified tasks and user objectives.	2	The EDC solution only partially covers the Verifiable Credential (VC) flow, with the issuance process entirely missing.
Functional Correctness	Technical requirements meet results with the needed degree of precision.	3	While the existing features of the EDC solution are generally accurate, the resolver requires domain-specific customization, which may affect precision in certain contexts.
Functional Appropriateness	Technical requirements facilitate the accomplishment of specified tasks and objectives.	2	The EDC solution requires significant customization and development work, particularly for the resolver, to fully support the required tasks and objectives within the domain context.

Overall Calculation: (2+3+2)/3 = 2.33 Functional Suitability Quality Metric Score: 2.33

Notes

EDC is a pluggable ecosystem primarily targeting 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.

Fiware

note

The results for Test 1.2.1.1 for Fiware were extracted from this page in the GitHub repository.
This file was last modified at 2025-06-02 13:59:01 UTC.

The test is conducted in the IONOS FIWARE_cluster cluster using node pool IP 85.215.161.198.

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

How participant onboarding is made.

Results

Assessment

Before participating in a data space, an organization needs to be onboarded at the data space's Participant List Service by registering it as trusted participant. The user invoking the onboarding process needs to present a VC issued by the organization to the user itself, a VC containing the self description of the organization and a VC issued by a trusted Compliancy Service for the organization self description.

The commands used for this process are:

    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}

To 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

To get the 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}

To get the 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}

To get the 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}

To get the 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}

Measured results

The criteria used to measure the results was the one specified by the Data Product Publication ISO25010 Quality file regarding Functional Suitability.

Criterion	Description	Score (0-4)	Explanation
Functional Completeness	Technical requirements cover all the specified tasks and user objectives.	4	The Fiware connector fully supports the participant onboarding process, covering all necessary steps for registering an organization as a trusted participant, including issuing and validating Verifiable Credentials (VCs). This ensures a comprehensive onboarding process.
Functional Correctness	Technical requirements meet results with the needed degree of precision.	3	While the onboarding process is generally accurate, there may be some areas where precision could be improved, particularly in handling edge cases or specific configurations. However, the core functionalities perform as expected.
Functional Appropriateness	Technical requirements facilitate the accomplishment of specified tasks and objectives.	3	The process is appropriate for the task, enabling organizations to onboard effectively. However, some steps could be streamlined to enhance efficiency, such as reducing the complexity of commands or improving the integration with identity providers.

Overall Calculation: (4+3+3)/3 = 3.33

Functional Suitability Quality Metric Score: 3.33

Notes