An identity hub is a credential storage and message relay system run by a dataspace participant. In particular, the identity hub will be used to securely deliver Verifiable Credentials from a dataspace issuer to a dataspace participant. The hub will also be used to provide Verifiable Presentations on behalf of a participant. The Identity Hub will not be used as a message relay system.
This document focuses on what the first version of the Identity Hub will have to enable the MVD (Minimum Viable Dataspace).
The Identity Hub will adhere to the Decentralized Web Node specification implementing the following subset of operations.
- Collections Query to query Verifiable Presentations
- Collections Write to push Verifiable Credentials
- Feature Detection listing the operations above as supported.
The Verifiable Presentations returned by the Collections Query operation will be the available Verifiable Credentials. No derived data will be extracted from the Verifiable Credentials to generate separate Presentations.
Each participant in the dataspace will have a single decentralized identifier and a single Identity Hub instance available (no namespacing required). Communication with the Identity Hub will not be subject to authentication or authorization at this time.
During participant-to-participant communication via IDS REST, the request destination participant queries the Verifiable Presentations of the request originator participant. Access to resources is granted or denied according to the policies in place and the available Verifiable Presentations.
Verifiable Presentations are issued and signed by a trusted authority. Before applying any policies, participants access the public key of that trusted authority from its DID Document, and check that Verifiable Presentations are valid. Only valid Verifiable Presentations must be taken into account in policy evaluations. Participants are responsible for reacting to the presence of invalid Verifiable Presentations as they see fit.
Note that complex IDS flows, such as negotiating a contract agreement, requires multiple IDS requests flowing back and forth between participants. In that case, participants will alternate in the flow above, and both participants require an Identity Hub.
When a participant is successfully onboarded to a dataspace, the dataspace authority pushes a "dataspace membership" Verifiable Credential into the participant's Identity Hub. This Verifiable Credential is then handed over to other participants during the authorization flow, which can enforce dataspace membership as a requirement for communication.
The Identity Hub will be developed as an EDC extension and will be deployed in a collocated test deployment topology. In this scenario, the Identity Hub and all participant agents (such as IDS Connector and Federated Catalog) run together in a single process. The Identity Hub leverages the EDC runtime to deploy as a set of extensions.
- Decentralized Web Node draft specification
- Verifiable Credentials W3C recommendation
- Verifiable Presentations section of the previous document
- Web DID draft specification
- Stefan van der Wiele - Decentralized Identifiers and the Eclipse Dataspace Connector (YouTube video)