Architecture

This section presents the static structure of the system using C4 model diagrams. Each level provides increasing detail about the software architecture. Update these diagrams when adding, removing, or significantly changing system components.

System Context

This diagram illustrates the high-level relationship between the Hashgraph DID-SDK and its primary users and dependencies. It provides a clear overview of how the SDK facilitates decentralized application development on the Hedera network.

system context diagram

Components

  • dApp Developer: Represents developers who utilize the DID-SDK to build decentralized applications that leverage decentralized identities on the Hedera network. They interact with the SDK to create, manage, and resolve DIDs, and to integrate verifiable credentials into their applications.

  • Hashgraph DID-SDK: A software development kit that provides tools and functionalities for managing decentralized identities on the Hedera Hashgraph network. It simplifies the process of working with DIDs by abstracting away the complexities of interacting with the Hedera network.

  • Hedera Network: The underlying distributed ledger technology that provides the infrastructure for creating and managing DIDs. It ensures the security and immutability of DID documents and verifiable credentials. The Hedera Consensus Service (HCS) plays a crucial role in anchoring DIDs to the Hedera network, providing a verifiable and auditable history of DID operations.

Interactions

  • dApp Developers use the Hashgraph DID-SDK: Developers utilize the SDK’s functions to integrate DID management capabilities into their applications. This includes generating key pairs, creating DID documents, updating DID information, and revoking DIDs when necessary.

  • Hashgraph DID-SDK uses the Hedera Network: The SDK interacts with the Hedera network to submit transactions related to DID management. This ensures that all DID operations are recorded on the Hedera ledger and are verifiable by anyone.

Container View

This diagram illustrates the containers within the Hashgraph DID-SDK and their interactions with external dependencies. It provides a more detailed view of the SDK’s internal structure and how it utilizes the Hedera network.

container view diagram

Components

  • dApp Developer: Represents developers who build applications utilizing the Hashgraph DID-SDK.

  • Hashgraph DID-SDK: The software development kit containing the Core Module.

  • Core Module: Provides the core functionalities for managing DIDs, including creating, updating, and deactivating DIDs, signing and verifying DID messages, and handling transaction signing and execution.

  • Hedera Topic Service: A service on the Hedera network that enables publish/subscribe communication. The DID-SDK uses this service for DID-related communication.

  • Hedera Node: A node in the Hedera network that acts as a gateway for submitting transactions and interacting with the network.

Interactions

  • dApp Developers use the Core Module: Developers interact with the Core Module to perform DID operations and integrate DID functionalities into their applications.

  • Core Module uses the Hedera Topic Service: The Core Module utilizes the Hedera Topic Service for communication related to DID management.

  • Hedera Topic Service communicates with Hedera Node: The Hedera Topic Service interacts with the Hedera Node to publish and retrieve messages, ensuring that DID-related communication is handled efficiently and reliably.

Component View

This diagram provides a detailed view of the components within the Hashgraph DID-SDK and their interactions with each other and with external dependencies. It illustrates the internal workings of the SDK and how it facilitates DID management.

component view diagram

Components

  • dApp Developer: Represents developers who build applications utilizing the Hashgraph DID-SDK.

  • Hashgraph DID-SDK: The software development kit containing the following components:

  • Registrar: Handles the creation, updating, and deactivation of DIDs.

  • Resolver: Resolves DIDs to their corresponding DID Documents.

  • Signer: Signs DID messages for secure communication.

  • Publisher: Signs and publishes transactions to the Hedera network.

  • Hedera Topic Service: A service on the Hedera network that enables publish/subscribe communication.

  • Hedera Node: A node in the Hedera network that acts as a gateway for submitting transactions.

Interactions

  • dApp Developers use Registrar and Resolver: Developers interact with these components to manage and resolve DIDs.

  • Registrar uses Signer and Publisher: The Registrar utilizes the Signer for signing DID-related operations and the Publisher for submitting transactions to the Hedera network.

  • Publisher publishes signed transactions to Hedera Topic Service: The Publisher component sends signed transactions to the Hedera Topic Service for processing.

  • Resolver retrieves DID Documents from Hedera Topic Service: The Resolver component retrieves DID Documents from the Hedera Topic Service.

  • Hedera Topic Service communicates with Hedera Node: The Hedera Topic Service interacts with the Hedera Node to publish and retrieve messages.

Runtime View

This diagram illustrates the runtime interactions between the components of the Hashgraph DID-SDK, a dApp developer, and the Hedera network during a typical DID management workflow. It shows the sequence of operations and how data flows between the components.

runtime view diagram

Components

  • dApp Developer: The developer interacts with the DID-SDK to manage DIDs.

  • Hashgraph DID-SDK: Contains the components responsible for DID operations:

  • Registrar: Handles DID creation, updates, deactivation, and resolution.

  • Resolver: Resolves DID Documents.

  • Signer: Signs DID messages.

  • Publisher: Signs and publishes transactions.

  • Hedera Topic Service: Provides a publish/subscribe mechanism for DID communication.

  • Hedera Node: Acts as a gateway to the Hedera network.

Interactions (Runtime Workflow)

  1. DID Management: The dApp developer initiates DID management operations (create, update, deactivate) through the Registrar component.

  2. Signature Request: The Registrar requests the Signer to sign the DID message.

  3. DID Document Publication: The Registrar sends the DID Document to the Publisher for publication.

  4. Transaction Publication: The Publisher signs the transaction and publishes it to the Hedera Topic Service.

  5. Communication with Hedera Network: The Hedera Topic Service interacts with the Hedera Node to process the transaction.

  6. DID Document Resolution: The dApp developer requests the Resolver to resolve a DID Document.

  7. DID Document Retrieval: The Resolver retrieves the DID Document from the Hedera Topic Service.