|
| 1 | +# IdentityHub Data Models |
| 2 | + |
| 3 | +This document provides an overview of the core data models in the IdentityHub component, based on the upstream **Eclipse EDC IdentityHub** project. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Core Data Models |
| 8 | + |
| 9 | +The IdentityHub manages several interconnected entities that work together to provide comprehensive identity and credential management functionality: |
| 10 | + |
| 11 | +### 1. ParticipantContext |
| 12 | + |
| 13 | +The `ParticipantContext` (specifically `IdentityHubParticipantContext`) represents a dataspace participant and serves as the top-level organizational unit. |
| 14 | + |
| 15 | +* **Purpose:** Serves as the primary organizational entity that owns and manages all other resources (credentials, DIDs, key pairs) for a specific participant. |
| 16 | +* **Lifecycle Events:** |
| 17 | + |
| 18 | +* `ParticipantContextCreated`: Emitted when a new context is created. |
| 19 | +* `ParticipantContextUpdated`: Emitted when context properties change. |
| 20 | +* `ParticipantContextDeleting`: Emitted before deletion to allow cleanup. |
| 21 | + |
| 22 | +### 2. CredentialResource |
| 23 | + |
| 24 | +The `CredentialResource` represents a verifiable credential stored in the IdentityHub. |
| 25 | + |
| 26 | +* **Purpose:** Stores and manages verifiable credentials received from issuers, enabling participants to hold and present credentials during **DCP (Decentralized Claims Protocol)** flows. |
| 27 | + |
| 28 | +### 3. KeyPairResource |
| 29 | + |
| 30 | +The `KeyPairResource` represents a cryptographic key pair used for signing and verification operations. |
| 31 | + |
| 32 | +* **Purpose:** Manages cryptographic key pairs for signing credentials and presentations. Supports key rotation and comprehensive lifecycle management. |
| 33 | + |
| 34 | +#### Lifecycle States |
| 35 | + |
| 36 | +| State | Code | Description | |
| 37 | +| :--- | :--- | :--- | |
| 38 | +| **CREATED** | 100 | Key pair created in database but not yet active. Private key in vault. | |
| 39 | +| **ACTIVATED** | 200 | Actively used for signing. Public key added to the DID document. | |
| 40 | +| **ROTATED** | 300 | Can still verify signatures but cannot sign new ones. Transitional state. | |
| 41 | +| **REVOKED** | 400 | Completely retired. Verification method removed from DID document. | |
| 42 | + |
| 43 | +### 4. DidResource |
| 44 | + |
| 45 | +The `DidResource` wraps a DID Document and represents its lifecycle in the IdentityHub. |
| 46 | + |
| 47 | +* **Purpose:** Manages DIDs and their corresponding DID Documents, which contain public keys, service endpoints, and other metadata. |
| 48 | +* **Lifecycle:** DID Documents are automatically updated when `KeyPairResources` are activated or revoked. |
| 49 | + |
| 50 | +--- |
| 51 | + |
| 52 | +## Relationships |
| 53 | + |
| 54 | +The data models are interconnected as follows: |
| 55 | + |
| 56 | +* **ParticipantContext (1)** |
| 57 | + * └── *owns* → **CredentialResource** (many) |
| 58 | + * └── *owns* → **KeyPairResource** (many) |
| 59 | + * └── *owns* → **DidResource** (many) |
| 60 | +* **CredentialResource** |
| 61 | + * └── *references* → `ParticipantContext` (via `participant_context_id`) |
| 62 | +* **KeyPairResource** |
| 63 | + * └── *references* → `ParticipantContext` (via `participant_context_id`) |
| 64 | + * └── *influences* → `DidResource` (verification methods) |
| 65 | +* **DidResource** |
| 66 | + * └── *references* → `ParticipantContext` (via `participant_context_id`) |
| 67 | + |
| 68 | +--- |
| 69 | + |
| 70 | +## Data Flow |
| 71 | + |
| 72 | +1. **Participant Onboarding:** A `ParticipantManifest` is submitted; a `ParticipantContext` is created with an API token. |
| 73 | +2. **DID and Key Creation:** `DidResource` and `KeyPairResource` entries are created based on the manifest. |
| 74 | +3. **Key Pair Activation:** Key pairs transition to `ACTIVATED`, and public keys are added to the DID Document. |
| 75 | +4. **Credential Reception:** `CredentialResource` entries are created when credentials are issued to the participant. |
| 76 | +5. **Credential Presentation:** During DCP flows, credentials are retrieved, wrapped in presentations, and signed using active keys. |
| 77 | +6. **Key Rotation:** Old key pairs transition to `ROTATED` (verify only), while new keys are `ACTIVATED`. After a duration, old keys become `REVOKED`. |
| 78 | + |
| 79 | +--- |
| 80 | + |
| 81 | +## Additional Information |
| 82 | + |
| 83 | +For more detailed information about the Eclipse EDC IdentityHub architecture, refer to the upstream documentation: |
| 84 | + |
| 85 | +* **Architecture Overview:** [Identity Hub Architecture](https://github.com/eclipse-edc/IdentityHub) |
| 86 | + |
| 87 | +--- |
| 88 | + |
| 89 | +## NOTICE |
| 90 | + |
| 91 | +This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). |
| 92 | + |
| 93 | +* SPDX-License-Identifier: CC-BY-4.0 |
| 94 | +* SPDX-FileCopyrightText: 2026 LKS Next |
| 95 | +* SPDX-FileCopyrightText: 2026 Contributors to the Eclipse Foundation |
| 96 | +* Source URL: <https://github.com/eclipse-tractusx/tractus-x-identityhub> |
0 commit comments