How On-Chain Identity Is Built

DID Architecture and Core Components

The goal of DID design is to enable verifiable, scalable, and long-term usable digital identities without relying on centralized identity providers. Its architecture doesn’t directly store complete identity information but instead uses a combination of identifiers, resolution, and credentials.

Looking at the overall structure, a typical DID system usually consists of several core components:

• DID Identifier: Uniquely identifies an entity, typically formatted as did:method:identifier
• DID Document: Describes the public key, verification methods, service endpoints, and other relevant information for that identity
• Verifiable Credentials: Claims about specific attributes issued by third parties
• Decentralized storage or on-chain anchoring mechanisms: Ensures identity information is tamper-proof and persistently available

The key principle behind this architecture is minimal on-chain data: blockchains only record immutable critical information, while detailed data can be flexibly stored off-chain or in decentralized storage solutions—balancing both security and scalability.

Public/Private Keys, Resolution, and Registration Mechanisms

In the DID framework, cryptography underpins identity trust. Unlike traditional account-password models, DID relies on public-private key pairs for identity control and verification, eliminating the need for centralized validation nodes.

Specifically, generating and using a DID typically involves these steps:

• The user locally generates one or more public-private key pairs
• The private key is securely managed by the user and used for signing and identity proof
• The public key is recorded in the DID Document for external verification
• The DID identifier and document are anchored via on-chain records or registration contracts

When an external system needs to verify a DID, it queries the corresponding DID Document using a DID Resolver and validates the signature with the public key provided. This resolution process is open and standardized, without dependency on any single organization.

It’s important to note that a DID is not equivalent to a blockchain address—a single DID can be linked to multiple keys, supports key rotation, revocation, and hierarchical permissions, making identities safer and more flexible over long-term use.

Mainstream DID Methods and Standards

To accommodate different underlying networks and use cases, there’s no single implementation of DID. Instead, DID Method extensions define how identities are registered, updated, and resolved for each scenario.

Currently, the most representative DID Methods include:

• did:ethr: A DID implementation based on Ethereum addresses and smart contracts
• did:key: A lightweight DID derived directly from public keys without requiring on-chain registration
• did:web: Hosts DID Documents via domain names and HTTPS for seamless integration with existing web systems
• did:ion: A highly scalable solution built on the Bitcoin network using the Sidetree protocol

At the standards level, W3C leads the development of DID and verifiable credentials. The main value includes:

• Ensuring interoperability between different DID Methods
• Enabling cross-platform and cross-ecosystem universal identity verification logic
• Providing unified interfaces for Web3, enterprise systems, and public services

As these standards mature, DIDs are evolving from experimental technology into scalable foundational infrastructure.