Registration Service is a component of a Dataspace Authority. In the current version, the Dataspace Authority is centralized to support the Minimum Viable Dataspace (MVD). In future versions, the Authority could also be partly or fully decentralized.
Responsibilities of the Dataspace Authority in MVD:
- Establishes a DID (Decentralized Identifier) defining the Dataspace.
- Manages policies defining who is allowed to participate in the dataspace.
- Manages enrollment process of the Dataspace participants.
- Lists the DID of available Dataspace participants.
The Registration Service is deployed as a separate component in the Dataspace environment. Deployment workflows and artifacts are provided in the Minimum Viable Dataspace repository.
The Registration Service endpoint can be resolved from the did:web document deployed for the Dataspace Authority.
In future versions, the Registration Service endpoint will be resolved in a Self-Description Document whose URL is available in the the did:web document. This version uses a simplified process omitting the Self-Description Document.
Operations supported by the Registration Service:
Operations that will be supported in future versions of the Registration Service:
- Dataspace participant offboarding
- Blacklisting
- Company1, an entity which intends to become a Dataspace participant
- The Dataspace Authority, which manages the enrollment process
A Client for Company1 initiates the enrollment process by resolving and contacting the enrollment API endpoint for the Dataspace Authority. (The client could be e.g. a CLI utility.)
The Dataspace Authority enrollment service obtains Verifiable Credentials (VCs) from Company1 to determine whether it meets enrollment policies. The enrollment service then issues a Verifiable Credential that establishes membership and pushes it to Company 1's Identity Hub, and stores membership and certificate information.
In simple scenarios, enrollment could be fast and fully automated. However, in advanced scenarios, enrollment policies could require interactions with external systems, and even manual processes, therefore, it is implemented asynchronously.
- Company1 has deployed an Identity Hub service, and a DID Document containing the Identity Hub URL.
- Company1 knows the DID URL of the Dataspace it intends to join.
- The Company1 Identity Hub contains VCs that satisfy the Dataspace Authority enrollment policy. In MVD, a credential
{"gaiaXMember": "true"}is seeded for each deployed participant, signed by a fake GAIA-X authority.
- The Company1 Identity Hub contains a VC signed by the Dataspace Authority, that establishes membership in Dataspace D. This is used by other participants to authorize requests from Company1.
- The Company1 DID URL is stored in the Registration Service Participants Store. This is used to serve participant requests.
- The Client for Company1 initiates the enrollment process based on the Dataspace DID URL. It retrieves the DID Document, and parses it to retrieve Dataspace enrollment HTTP endpoint.
- The client needs access to the Company1 Private Key to sign a JWS. The client sends an HTTP request to the Dataspace Authority enrollment endpoint. The request is accepted for asynchronous processing.
- The Registration Service uses the Distributed authorization sub-flow to authenticate the request...
- ... and retrieves credentials from Company1's Identity Hub.
- The Registration Service stores participant information in its store. This includes Company 1's DID URL.
- The Registration Service authorizes the request by applying the Dataspace enrollment policy on the obtained Verifiable Credentials. In MVD, the service checks for a credential
{"gaiaXMember": "true"}signed by any issuer (as the EDC policy engine does not currently allow restricting trusting claims to specific issuers). - The Registration Service updates the status of the participant's membership indicating that the participant's onboarding is successful/failed.
- The Registration Service issues and signs a membership Verifiable Credential.
- The Registration Service sends the Verifiable Credential to Company1's Identity Hub for storage. It uses the Identity Hub bearer token (from the Distributed authorization sub-flow) to authenticate the request.
- Company1's Identity Hub validates the bearer token and stores the membership Verifiable Credential.
- Company1, a Dataspace Participant with a Dataspace Connector (e.g. EDC application) that wants to discover IDS endpoints (e.g. in order to list contract offers)
- The Dataspace Authority, which manages Dataspace memberships
- Company2, Company3, etc., Dataspace Participants
A typical EDC deployment caches contract offers from other participants in a federated catalog, so that users can quickly browse and negotiate contracts. To regularly retrieve offers, it regularly contacts the Registration Service to refresh its list of Dataspace Participants, then obtains contract offers from each participants to refresh its cache.
In this flow, the EDC for Company1 obtains a list of Dataspace Participants and resolves their IDS endpoints.
Participants are registered as (currently valid) Dataspace Participants
- The EDC for Company1 determines the Registration Service endpoint from the Dataspace DID Document.
- The EDC for Company1 issues a request to the Registration Service, to list participants.
- The Registration Service uses the Distributed authorization sub-flow to authenticate the request...
- ... and retrieves Verifiable Presentations from Company1's Identity Hub.
- The Registration Service authorizes the request by applying the access policy on the obtained Verifiable Presentations. For example, the caller must be a valid Dataspace Participant.
- The Registration Service obtains the list of Dataspace Participant DID URIs from its storage...
- ... and returns it synchronously to the caller (Company1 EDC).
- The EDC for Company1 iterates through the Participants' DID URIs, and retrieves the collection of their IDS endpoints from their DID Documents.