Web3 Identity (DID): The Vision of Self-Sovereign Identity

What Is Web3 Identity?

On the traditional internet, users generally create a separate account for each platform. Social networks, shopping websites, games, and financial applications each store users' names, email addresses, passwords, and behavioral data.

These identities are created and managed by platforms. A platform can change its login rules, restrict an account, or discontinue a service, while users generally cannot take their identity, reputation, or social relationships directly from one platform to another.

Web3 identity attempts to change this model. Users can manage digital identities through wallets, cryptographic identifiers, and verifiable credentials, then prove that they hold a particular identity, qualification, or permission across different applications.

DID stands for Decentralized Identifier. It is a type of digital identifier that can be separated from centralized identity providers and certificate authorities. A DID can identify a person, organization, device, digital asset, or another entity.

DIDs are an important part of the Web3 identity system, but Web3 identity is not limited to DIDs. It may also involve wallets, verifiable credentials, domain names, reputation records, and privacy proofs.

For an overview of Web3, see What Is Web3? A Complete Guide to the Next Generation of the Internet.

What Is Self-Sovereign Identity?

Self-sovereign identity, or SSI, describes a vision for digital identity in which users have more direct control over their identity identifiers and digital credentials, instead of having all identity data stored and determined by a single platform.

Self-sovereign identity usually emphasizes the following principles:

• Users can control their own identity identifiers;
• Users can use their identities across different services;
• Third parties can independently verify identity credentials;
• Users can choose which information to share;
• The identity system should not depend entirely on the continued operation of a single platform;
• Unnecessary disclosure and collection of identity information should be minimized.

“Self-sovereign” does not mean that users can declare any identity and demand that everyone believe it. Information such as academic records, professional qualifications, and memberships must still be issued by trusted institutions, and verifiers decide whether to accept it.

A more accurate meaning of self-sovereign identity is that users control how they hold and present credentials, while the credibility of those credentials still depends on issuers, verification mechanisms, and real-world application rules.

How Does a DID Differ from a Traditional Identity?

A DID does not necessarily require a blockchain. Depending on the DID method, a verifiable data registry may use a blockchain, decentralized file system, distributed database, or another network.

It is therefore inaccurate to equate a DID with a “blockchain account.” A blockchain is only one type of infrastructure that some DID systems may use.

What Are the Components of a DID?

An example DID might look like this:

did:example:123456789abcdefghi │ │ │ scheme DID method method-specific identifier

A DID system mainly includes the following components.

4.1 DID Subject

The DID subject is the object represented by the identifier. It may be a person, organization, device, digital asset, data model, or another entity.

4.2 DID Controller

A DID controller is an entity that can update a DID document according to the relevant DID method. Control is usually proven with cryptographic keys, although different DID methods may use different mechanisms.

The DID subject and DID controller may be the same entity or different entities. For example, a guardian may manage an identity for a minor, while a company may manage DIDs for its devices.

4.3 DID Document

A DID document stores verification information related to the identity, usually including:

• The DID itself;
• Public keys or other verification methods;
• Authentication relationships;
• Key agreement methods;
• Service endpoints;
• Controller information.

A DID document should not be understood as a public file containing every piece of personal information. To protect privacy, sensitive information such as names, home addresses, and identification numbers generally should not be written directly into a public DID document.

4.4 DID Method

A DID method defines the rules for creating, resolving, updating, and deactivating a particular type of DID. Different DID methods may use different blockchains, databases, or peer-to-peer networks.

4.5 DID Resolver

A DID resolver receives a DID, then uses the corresponding method to locate and return its DID document. This process is called DID resolution.

What Is a Verifiable Credential?

A DID addresses how to identify an entity, but it does not automatically prove that the entity holds a particular qualification.

For example, a DID may represent a user, but the DID string alone cannot confirm that the user graduated from a particular university, is licensed to drive, or belongs to an organization. This is where a Verifiable Credential, or VC, is needed.

A verifiable credential usually contains:

• Issuer information;
• The credential holder or subject;
• One or more claims;
• The credential type;
• Issuance and validity dates;
• Credential status;
• Cryptographic proof.

Common verifiable credentials may include digital academic certificates, employee IDs, membership credentials, proof of age, event tickets, and professional qualifications.

Verifying a digital signature only confirms that a credential was issued by the corresponding issuer and has not been altered. It does not mean that every statement in the credential is necessarily true. The verifier must still decide whether to trust the issuer.

How Is a DID Identity Verified?

DIDs and verifiable credentials usually involve three roles:

Issuer │ │ Issues a verifiable credential ↓ Holder │ │ Creates a verifiable presentation ↓ Verifier │ └── Checks the signature, issuer, and credential status

Using proof of education as an example, the basic process is as follows:

1. A school issues a digital academic credential to a student;
2. The student stores the credential in an identity wallet or credential repository;
3. During a job application, an employer asks the student to provide proof of education;
4. The student selects the credential to present;
5. The employer verifies the school's digital signature;
6. The employer checks whether the credential has expired, been revoked, or become invalid;
7. After verification, the employer decides whether to accept it under its own business rules.

This process can reduce the need for a verifier to repeatedly query the issuing institution directly, but it does not eliminate the need to assess the issuer's reputation.

How Do DIDs, Wallet Addresses, and ENS Domains Differ?

DIDs, wallet addresses, and ENS domains can all relate to Web3 identity, but they serve different functions.

A wallet address can prove that someone controls the corresponding private key, but it cannot directly prove the holder's real-world identity. A DID can connect verification methods and service information, but verifiable credentials are still needed to express specific identity attributes.

ENS domains primarily address the difficulty of reading and remembering wallet addresses. An ENS domain can be associated with an address, avatar, or other records, but owning a .eth domain does not automatically provide an identity certified by an institution.

For more about ENS, see the cross-linked article Web3 Domains: The Value and Use of ENS and .eth.

What Are the Use Cases for DIDs?

8.1 Cross-Application Login

Users can access different applications with an identity they control, reducing the need to repeatedly register accounts and set passwords.

8.2 Digital Academic Records and Professional Qualifications

Schools, training providers, and professional organizations can issue verifiable credentials that users selectively present when applying for jobs or services.

8.3 DAO and Community Identity

DAOs can use on-chain contributions, voting records, and verifiable credentials to establish membership levels or community reputation. However, they should avoid permanently linking every activity to the same identity.

8.4 Gaming Identity

Players can use portable identities to record achievements, qualifications, or community contributions. Whether an identity can be used across games still depends on whether different projects adopt compatible standards.

8.5 Devices and the Internet of Things

DIDs can identify not only people but also devices, software agents, and organizations, enabling device identity or service endpoint verification.

8.6 Proof of Age and Eligibility

In systems that support selective disclosure, users may only need to prove that they have reached the required age without submitting their full name, birth date, home address, and other complete information.

Can DIDs Truly Protect Privacy?

DIDs are designed with privacy, portability, and user control in mind, but using a DID does not automatically provide privacy protection.

If a user repeatedly uses the same DID, wallet address, or public credential on every website, third parties may link different activities and build a more complete user profile.

To reduce these risks, identity systems generally need to consider the following:

• Use different DIDs for different contexts;
• Minimize publicly disclosed identity attributes;
• Do not store sensitive information in public DID documents;
• Use selective disclosure where appropriate;
• Regularly update or rotate verification keys;
• Configure service endpoints in DID documents carefully;
• Check whether credentials expose unnecessary information.

Some verifiable credential systems can combine selective disclosure or zero-knowledge proofs so that users prove only a specific condition without disclosing complete data. Actual support depends on the credential format, wallet, and verification system.

What Challenges Do DIDs Face?

10.1 Private Key Management

When control of an identity is tied to a key, losing the private key may prevent the user from continuing to control the identity. Systems therefore need mechanisms for key rotation, recovery, multisignature authorization, or trusted contacts.

10.2 Standards Compatibility

Different DID methods, wallets, and credential formats may have compatibility issues. Support for one DID in an application does not mean that every platform can recognize it.

10.3 Issuer Trustworthiness

A digital signature can prove that a credential came from a particular issuer, but it cannot automatically prove that the issuer is trustworthy. Verifiers still need to maintain lists of trusted issuers or use assessment mechanisms.

10.4 Credential Revocation

Academic qualifications, licenses, and memberships may expire or be revoked. A verifier must check credential status rather than only verifying the signature.

10.5 Identity Correlation Risk

If the same DID is linked to wallet transactions, social accounts, and a real-world identity, public data may be correlated and analyzed, reducing privacy instead of improving it.

10.6 Legal and Compliance Issues

Digital identity may involve rules concerning personal data protection, cross-border transfers, identity verification, and electronic signatures. Requirements vary by country and region.

How Do Web3 Wallets Relate to DIDs?

A Web3 wallet helps users manage private keys, addresses, and transaction signatures. It may also store DIDs, verifiable credentials, or identity authorization information.

However, a regular wallet address is not automatically a standards-compliant DID. Whether a wallet supports DIDs and verifiable credentials depends on its specific features, technical standards, and compatibility.

Users can visit the Hotcoin Web3 Wallet for the on-chain wallet entry point or download the Hotcoin App to explore the mobile product.

When using any wallet or identity application, users should:

• Never disclose a private key or seed phrase to anyone;
• Never sign an unfamiliar message they do not understand;
• Verify the identity information requested by an application;
• Avoid writing sensitive personal information to a public blockchain;
• Understand the available identity recovery and key rotation methods;
• Regularly review connected websites and authorizations.

Conclusion

The core value of a DID is that it allows a digital identity identifier to be separated from a single platform, centralized identity provider, or certificate authority, while using cryptographic methods to prove control.

In a complete Web3 identity system, DIDs identify entities, verifiable credentials prove identity attributes, wallets safeguard keys and credentials, and verifiers decide whether to accept a credential based on its signature, status, and their own rules.

Self-sovereign identity remains a vision under active development. It does not free users from every institution or make every self-declared claim trustworthy. Instead, it aims to give users more control over how identities are held, presented, and transferred.

Visit the Hotcoin website to learn more about the platform and related products.