This document explains how the Self-Description of a dataspace participant will be stored into the Identity Hub and retrieved from it.
Gaia-X defines a set of rules representing the minimum baseline to be part of a Gaia-X Ecosystem. This set of rules is the Gaia-X Trust Framework, which is centered around the Self-Description document.
Each dataspace participant (consumer, provider, federator) is represented by a Self-Description document.
According to Gaia-X Architecture Document, "Self-Descriptions are W3C Verifiable Presentations in the JSON-LD format. Self-Description consist of a list of Verifiable Credentials. Verifiable Credentials themselves contain a list of Claims: assertions about Entities expressed in the RDF data model. Both Verifiable Credentials and Verifiable Presentations come with cryptographic signatures to increase the level of trust".
Note that a Self-Description can aggregate Verifiable Credentials from different issuers, each having its own cryptographic signature.
An example of valid Self-Description can be found here, which corresponds to the one used during the Gaia-X Hackathon #4.
The reason to serve the Self-Description document via the Identity Hub is to enable the dynamic generation and signature (cf. Gaia-X Trust Anchors) of the Self-Description from the Identity Hub at a later stage. As the Self-Description will already be served by the Identity Hub with this version, there will be no change for the user when Self-Description will be internally generated.
- Self-Description document is static, i.e. no update of the Self-Description is supported in this version.
- Verifiable Credentials contained in the Self-Description are not served by the main Identity Hub
POST
endpoint. Thus, they are not verified nor evaluated by the Policy Engine. This will be addressed in a later version. - No check is performed in current version to ensure that Self-Description is valid according to Gaia-X Compliance API.
The Self-Description will be loaded at startup from a static .json
file and stored in-memory. After being loaded, the Self-Description is then passed
to the API controller which expose it through an endpoint.
The Self-Description can be retrieved from the Identity Hub through a GET
endpoint under the path identity-hub/self-description
.
The base URL to access the Self-Description is the same as the one for the main Identity Hub REST API. Thus, the URL for accessing
the Self-Description document can be resolved from the same serviceEndpoint
of the DID document.