Original author: Eunice
Original source: PAKA
Introduction
Web3 based on blockchain technology emerges on the historical stage, with a considerable part of its driving force coming from people's expectations that it can counter the privileges of commercial organizations and involuntary censorship — safeguarding the rights and interests of every participant by replacing human rule with code. Based on the current situation, various solutions provided by the industry — users engaging in interactions by freely registering wallets — not only lead to frequent occurrence of witch attacks and phishing attacks without accountability but also erode the trust of the Web3 community, compromising the privacy and asset security of Web3 users. It also prevents Web3 users with on-chain reputation but lacking assets from enjoying quality financial services (similar to offline credit loan models).
Web3 has reproduced the wrongdoing of "the strong exploiting the weak" in Web2 and the traditional society, as well as the evil of "inferior money driving out good money". Even the data sovereignty (SSI) that Web3 advocates and believes in (which is one of its attractive features) is repeatedly hindered on the road to realization, as users' privacy data is either stored on centralized servers of decentralized projects or publicly presented in its entirety on the blockchain, without actual protection of security and privacy. It even brings about greater economic losses compared to Web2 to a certain extent, and once suffered, it is almost irreversible. Due to the lack of appropriate regulatory support, it is difficult to identify and hold malicious attackers accountable.
In this context, Web3 realizes that visualizing the credibility of identity subjects, suggesting identity-based contracts, and introducing appropriate regulations are essential for its sustainable development. Based on this fundamental awareness, the concept of decentralized identity, consisting of "Decentralized Identifiers (DID) + Verifiable Credentials (VC)," gradually becomes clear, providing a solution for the construction of the identity system in the Web3 society.
To briefly explain, the development of identity systems has evolved from centralized identities managed and controlled by a single authoritative institution, to federated identities that provide a certain degree of portability and cross-platform login for user identity data, such as cross-platform login using WeChat or Google accounts. It then progressed to initial decentralized identities that require authorization and permission for identity data sharing, such as OpenID. Finally, it advanced to self-sovereign identities (SSI) that truly allow individuals to own and control their data, typically referring to decentralized identity systems built on DID+VC in Web3. Centralization is being partially replaced by decentralization, which no longer involves centralized data storage and collection.
Current State of Identity Privacy Data
Identities and their related information are often used to prove "who I am" and "whether I meet specific requirements to access certain services." For example, educational qualifications for job applications, asset proofs for purchasing houses and applying for bank loans, and whether we meet the criteria to become VIP customers of certain entities or virtual service providers, etc., all require the use of identity information.
In real life, people's identity information is recorded in government systems and verified in various life scenarios by presenting corresponding documents and certificates. In the internet world, our identities are represented by account passwords, and the behavior data based on this is recorded by the data storage systems of the corresponding service providers.
They have the following commonalities:
User data is stored by third-party organizations (they cannot control identity-related information themselves);
Users cannot freely use their own data (thus unable to decide who has the right to access their identity information and cannot control the scope of authorization for visitors).
Because when users need to connect through the internet for activities such as socializing, gaming, finance, and shopping with people all over the world, their identity information needs to be uploaded to a platform without reservation. The user-generated online gaming identity data, social identity data, and so on are also stored in the servers of the giants—this means that users only have the right to view but not the right to delete, add, or trade their own data according to their own will. The unrestricted exposure of this data to institutions poses significant privacy and security risks. After all, the phenomena of institutions misusing user data seem to be all too common in Web 2.0.
At the same time, the relatively independent data systems of various organizations force user data to be fragmented and stored in systems that cannot be mutually accessed. Therefore, it is difficult for users to fully view, access, and interpret their own data. One of the prerequisites for implementing SSI is that users can control their own privacy data and have data sovereignty—the right to custody and use the data. And DID achieves this.
DID—Returning User Data Sovereignty S
What is DID
Simply put, a Decentralized Identifier (DID) is a string-form URI that has global uniqueness, high availability, resolution, and encrypted verification. It is beneficial to any application that benefits from self-managed, cryptographically verifiable identifiers—such as personal identities, organizational identities, on-chain activity history, IoT scenarios, etc. It can also be used to identify other entities—such as products or things that do not exist, such as ideas or concepts, etc.
Multiple blockchain platforms like Ethereum and Polygon are paying attention to DID, but they are still in the experimental stage and there is no systematic solution provided by any party. The most commonly used DID standards come from W 3 C (World Wide Web Consortium, the world's largest organization for the development of web standards) and DIF (Decentralized Identity Foundation), with the W 3 C standard being more widely used.
DID and VC are inseparable. W 3 C VC's commercial deployment uses DID extensively to identify individuals, organizations, and things, and to provide a certain level of security and privacy protection. Without permission, no other party can access, use, or disclose the identity data of the DID subject.
The user's DID is completely controlled by the user themselves, generated according to a specific algorithm, and not granted by a single organization. A DID can be resolved into a DID document stored on the blockchain, which includes information such as authentication keys, agreement keys, delegation keys, assertion keys, and service endpoint links for interacting with the DID subject. These keys can be understood as signatures we use for different purposes in life, where the signed document (purpose) may include confidentiality agreements, delegation letters, or authorization letters allowing someone to use your personal information, and so on.
It is because of this public key infrastructure that the DID+VC identity system allows users to better protect their data and choose whether and how to share data, as only the owner of the private key has full authorization over the DID. This is similar to assets being controlled by private keys in blockchain.
Speaking of which, this can also lead to the following problems:
It is very difficult to recover lost private keys;
If your private key is stolen, malicious activities such as impersonation can lead to unethical behavior on behalf of "you".
Therefore, all users have the responsibility to securely back up their private keys and mnemonics.
VC - Trusted Online Identity Information
VC is a deeper element of the identity system than SBT.
In May 2022, Vitalik Buterin, the co-founder of Ethereum, Glen Weyl, a researcher at Microsoft's Chief Technology Officer's office, and Puja Ahluwalia Ohlhaver, a strategist at Flashbots, jointly released "Decentralized Society: Finding Web3's Soul", which sparked discussions on SBT (SoulBound Token) and garnered more attention for the concept of decentralized identity.
SBT can partially replace VC in building social relationships within Web3. Protocols such as EIP-4973, EIP-5114, ERC 721S, and EIP-3525 represent conceptualizations of SBT applications. However, the inherent limitations of SBT prevent it from forming a complete decentralized identity system:
Firstly, SBT is essentially a Token.
The Token refers to a wallet address, rather than an identity identifier that represents identity. Anyone who can obtain the wallet address can view the SBTs owned by the wallet owner, without any privacy. What's more important is that we do not want the social contract entity to be wallets rather than identities, because transactions are only part of social activities.
Secondly, SBT depends on the existence of the chain.
Although it can prove identity in multi-chain compatible environments such as EVM, it is powerless for scenarios that cross ecosystems, platforms, or even go off-chain.
Lastly, SBT also has significant limitations in terms of presentation and application scenarios.
Similar to NFT, existing SBTs only have two forms of presentation: complete display and complete concealment, without comprehensive protection of data privacy.
Although the industry is also working on aggregating SBTs, the information payload form of the SBTs released by various projects is not standardized, so they can only be arranged and displayed on whiteboards, which has poor readability and is not user-friendly for use and interpretation.
Even now, SBTs can be selectively disclosed - that is, partial information in SBTs can be presented according to needs. However, it should be emphasized that this partial information is also plain text disclosure without any modification or concealment, which raises a problem. When users need to prove their identity, they have to partially expose the privacy data in SBTs. After multiple exposures, these privacy data can still be collected, organized, and analyzed to form a complete user profile, thereby threatening privacy and security. This is the same as the Web2 profile we mentioned before. Just imagine when you open Taobao and see push advertisements that are similar to the furniture store category you just visited, or Taobao always pushes products of corresponding styles, price ranges, and tastes based on your consumption habits. It's very much like an information cocoon. Not everyone always likes being in an information cocoon because it limits your information exploration and even more severely limits your cognition.
Therefore, as we can see, the SBT has a short-lived glory and very limited scenarios for extensive and in-depth use. We have cast doubt on the idea that "SBT can meet the complex identity data interaction needs of future Web3 society."
On the other hand, the DID+VC solution effectively overcomes the three limitations of SBT mentioned above, ensuring that the ultimate control of issuing, holding, and controlling DID and VC is in the hands of users through cryptographic and other technical means. And through a series of technologies and protocols, it guarantees that
The identity system can be used across chains, platforms, or even off-chain;
The identity information presentation scheme is unified, eliminating the need to use different presentation schemes for different scenarios;
It can even develop customized products on top of the DID protocol.
(Supplement: As for NFT, the author believes that it cannot be compared with VC because NFT represents ownership, and this ownership can be changed, transferred, and traced. VC, on the other hand, carries identity-related information that belongs to you and is unique, and cannot be transferred.)
What is VC
VC is a descriptive statement issued by one DID (such as a trusted institution, a DAO organization, a government system, a business institution) to endorse certain attributes of another DID (such as a user, a cooperative party). It is generated and verified based on cryptography to prove that the attributes (such as identity, abilities, qualifications, etc.) of its owner are true [1]. These authentication results can be recorded in other VCs stored on platforms like Arweave, IPFS, where all relevant information is open, verifiable, searchable, and permanently traceable, and anyone can independently verify them to ensure the authenticity and trustworthiness of the credential content [2]. These VCs can also be deployed on major public chains and interoperable with other ecosystem applications. Only the DID subject who owns the VC can control who can access and how to access their VCs.
Note that in the paragraph above, we mentioned two types of VCs. One is used to store users' private data [1], which we refer to as personal VC here; the other is used to store the verification of personal VCs [2], which we refer to as result VC here. Here comes a problem: currently, most verifiable credentials are stored in centralized databases or blockchains that cannot provide privacy protection. This is not a big problem for result VCs [2], but it is unacceptable for personal VCs [1].
So how can we ensure the storage security and privacy of VCs that include personal private data? This involves the storage methods of VCs:
Storage Methods of VCs
Currently, there are mainly three methods:
Stored and backed up locally by users.
This is similar to recording private keys in notebooks or on programs that are not connected to the internet. However, similar to those cases, once lost, it is almost impossible to retrieve them. Users need to take on more responsibility when enjoying more sovereignty.
Encrypted and stored in user-controlled cloud storage.
This approach is different from Web2, which directly stores data in centralized servers owned by Internet giants. The access, use, and deletion permissions of the encrypted VC can only be operated by the owner who holds the corresponding DID private key. Of course, users still need to securely store the DID private key or mnemonic phrase.
Store the VC information that needs to be made public on decentralized storage platforms.
This approach makes the information traceable and verifiable, and the ownership of this information still belongs to the VC owner.
It is emphasized here that regardless of the approach, users should backup the VC and private key.
Presentation of VC
Let's go deeper. The more attentive readers may realize that even if we achieve privacy and security in storage, if we cannot "let the other party know that I meet their conditions without revealing any private information" when presenting the VC, then the information we disclose is not still exposed on the Internet, right? Doesn't it bring us back to the previous discussion of SBT/NFT information being traced, collected, and forming a complete user profile, disturbing our daily lives and economic activities?
This lack of privacy protection in data presentation is not what SSI pursues!
This is also the entry point for the ZKP (Zero-Knowledge Proof) technology currently being widely discussed.
There are multiple technologies to achieve privacy, such as Secure Multi-Party Computation, Homomorphic Encryption, and Zero-Knowledge Proof.
Secure Multi-Party Computation requires the number of participants to be greater than n, which has significant usage limitations at the individual user level. However, it is the cryptographic foundation for implementing applications such as electronic voting, threshold signatures, and online auctions.
Homomorphic Encryption often requires higher computational time or storage costs, and it still lags far behind traditional encryption algorithms in terms of performance and strength.
Zero-Knowledge Proof does not have the limitations of the above two, and it can make the network highly scalable through multiple recursions. However, the only drawback is the relatively high development threshold.
ZKP is currently the most popular technology in Web3 for privacy security and network scalability. It can help users prove certain attributes or qualifications without revealing any information, or simply provide a "yes" or "no" answer to the service provider. The emerging zCloak Network has set a good example in this regard, achieving fine-grained control over identity information display. Its VC presentation methods include four types: ZKP Disclosure, Digest Disclosure, Selective Disclosure, and Full Disclosure 0.
In other words, based on ZKP technology, users can choose to disclose all, some, or none of their information, or obtain a "DeFi expert" label through discreet data analysis to demonstrate certain abilities and qualifications. At the same time, this allows service providers to identify whether users fully meet the criteria of their specific business. This not only greatly protects user data privacy and security, but also respects the diverse disclosure intentions of users.
Analysis of ZKP
ZKP is currently divided into two systems: SNARK (Scalable Transparent Argument of Knowledge) and STARK (Succinct Non-interactive Argument of Knowledge), both of which can be used to create proofs of validity. The main differences are explained in the following table:
SNARK:
The proof size is very small, resulting in short verification time. Therefore, the gas fee required to process SNARK proofs on blockchains like Ethereum is relatively low, which is a major advantage.
However, it relies on non-standard security assumptions and requires a trusted generation phase. If any issues arise during this phase, it may compromise the security of the system.
In comparison, STARK
Then based on weaker security assumptions, complete transparency, a generation phase that does not require trust, and resistance to quantum computing (i.e., very high security).
It is also more universal and has better adaptability to parallelization, without the need for circuit customization for different scenarios, which can greatly save development costs and simplify development work. SNARK is required.
( So, as we can see, currently SNARK is more commonly used in cross-chain and L2 scaling, while STARK is used more for privacy data protection. This is because the former has smaller proofs, shorter verification time, and lower gas fees, while the latter has extremely high security and is more conducive to development. On June 20th, Vitalik Buterin, co-founder of Ethereum, pointed out in his latest article "A Deeper Exploration of Cross L2 Readings for Wallets and Other Use Cases" that in the implementation of cross-chain proofs, zero-knowledge proofs (ZK-SNARK) are a very feasible technical choice, and zk-SNARK will be as important as blockchain in the next 10 years.)
Let's use a scenario to illustrate the application of these two technologies. Suppose we want to implement a privacy voting system on the blockchain. This system requires verifying if a user has voting rights, but it must not reveal the user's identity:
If we prioritize system efficiency and gas costs, then SNARK may be a better choice because it can generate smaller proofs and has faster verification speed. However,
If we are more concerned about system transparency and security, then STARK may be a better choice. Although it has larger proof size and longer verification time, it does not require a trusted generation phase and is based on weaker security assumptions.
Overall, SNARK and STARK have their own merits, and the specific choice of technology depends on the specific requirements and scenarios of the application.
Participants in the DID identity system
Mainly include VC Holder, Issuer, Verifier.
Holder is the owner of a certain DID, the holder of VC. They are the only ones authorized to share their credentials and the only ones authorized to select individuals or organizations they are willing to share their own identity information with.
Issuer is the issuer of the VC and is usually played by a trusted organization, such as DAO, government, industry association. It is important to note that even though the Issuer creates and issues the VC, it does not have the right to use the VC, as it requires the corresponding private key of the DID to be authorized and signed for use. However, the Issuer does not have the private key of the Holder. However, for certain types of VCs, the Issuer has the right to revoke them. For example, if a community member is found to be misbehaving, the DAO community can revoke the honorary certificate previously issued to him, or the traffic police department has the right to revoke the digital driver's license issued to a driver when handling traffic violations.
Verifier is the verifier and recipient of the VC. They can only verify the corresponding DID and VC and know whether the Holder has certain attributes or meets certain conditions (such as user compliance) with the authorization and consent of the Holder, so that the Holder can enjoy their services with certain limited conditions provided by their DID.
Let's take an example to understand the relationship between the three:
(Web 2) For example, during the background check for employment, a company needs to verify the job information of potential new employees to determine if they have the corresponding educational background, if their past work experience is true, and if they are legal citizens; in this case, the company is the Verifier, the educational institution that issues educational certificates and the former employer that issues occupational certificates are Issuers, and the new employees holding these certificates are Holders.
(Web 3) For example, a community proposal from mockDAO requires only community members with Level>2 to participate in voting. In this process, mockDAO needs to verify the member certificates (VC) issued in advance to confirm if they meet these conditions; in this case, mockDAO is both Issuer and Verifier, and the community members holding the member certificates are Holders.
Why do we need a decentralized identity system with DID+VC
The DID+VC identity system has a wide range of applications. Here, I will list 6 commonly used application scenarios in Web3:
1. Universal and secure login
Users can achieve direct login to all platforms through a single DID. VCs authorized by platforms or smart contracts can control user access permissions. This can break through the barriers between platforms, eliminating the need for different "username + password" for different platforms. At the same time, users can freely present different VCs to platforms to prove certain conditions, improving user login experience and privacy control.
In addition, the conventional wallet login method in Web3 exposes the interaction between the wallet and the platform on the blockchain, which may lead to discriminatory services based on blockchain data such as financial status. Using DID login can prevent this from happening.
2. KYC authentication
In a broader perspective, all real-life or online scenarios involving identity information can use DID. For example, many online services, including some cryptocurrency exchanges and wallets, require us to scan and upload identification documents for KYC authentication. This usually requires tedious documentation and electronic records for identity verification, which is expensive, time-consuming, and may expose user privacy. Moreover, service providers may not be able to verify the authenticity of the documents.
However, in the DID identity system, service providers verify user qualifications through VCs with the user's permission. Users can selectively or completely keep their sensitive information secret or share it partially or entirely. Therefore, compared to traditional KYC authentication, it is more trustworthy and significantly reduces communication costs between users and organizations.
Even in real life, the DID+VC identity system can help loan companies easily verify applicants' financial credentials while also respecting users' desire to keep certain data confidential. In employee due diligence, it is convenient for employees to access qualification materials and ensure proper custody, as well as to prevent tampering of materials during circulation. It also avoids the situation where it is difficult to verify the authenticity of information due to possible inconveniences in the verification process. And so on.
3. Community Governance
(1) Manage community identity and contribution data in a privacy-preserving manner:
Many Web3 platforms and communities use a centralized model to manage members' identities and contribution data. Even if some organizations try to put them on the chain, gas fees will become a significant cost for organizational operations. Moreover, even with the owners' permission, the content after being put on the chain cannot be modified, making it difficult to protect owners' privacy. Associating authorization keys and protocols with the DID+VC identity system can facilitate and discreetly manage identity and contribution data, fully protecting owners' data sovereignty and privacy.
(2) Efficient governance of DAOs
The example of mockDAO voting qualification certification mentioned earlier also illustrates how efficient management of DAOs and other organizations can be achieved based on the DID+VC identity system, saving the project party's comprehensive costs and providing users with a simpler and smoother operating experience. Since the custody and usage rights of VCs are entirely in the hands of users, community members can also use VCs to demonstrate their contributions to a project or DAO, greatly reducing their communication costs with the organization.
4. Anti-Sybil Attacks
Sybil attacks refer to a small number of people controlling a large number of bots to simulate human behavior in order to interfere with the operation of an organization and profit from it. Such attacks are often seen in airdrops and voting governance. The DID system can ensure that VCs are only issued to real and valid users. Users can only participate in these activities by presenting and verifying credentials, and their privacy will not be compromised.
5. Anti-Phishing Attacks
When mnemonic phrases and private keys are kept confidential, users' digital assets are usually secure. However, hackers launch attacks by taking advantage of human errors or centralized platforms, such as using Discord, email, Twitter, or trading platforms to publish false information, or directing users to make mistakes through forged websites. In addition to being vigilant, carefully verifying transaction information, and protecting sensitive account information, the most fundamental and effective measure is to promptly verify whether unknown information originates from a genuine organization. This verification process involves:
(1) Establishing the real and valid identity of the organization that publishes the information, ensuring it is not fake or already cancelled;
(2) Confirming that all content in the information comes from this genuine and valid organization;
Regarding the first point, from a use case perspective, users can learn about the organization's legal basis and official identity information through trustworthy yellow pages similar to "Tianyancha" or by trusting the "Verified" badge on major social platforms, which indicates the authenticity of the organization's official account and its published content. However, both of these methods are manual, centralized, and inefficient authentication processes. Platforms are also unable to update the development, cancellation, or ownership change status of projects in a timely manner or verify whether the statements of departing or departed senior executives represent the organization's intentions.
From a technical perspective, identity verification can be achieved through the Public Key Infrastructure (PKI) system of Certificate Authorities (CAs), or through the Personal Key System (PGP) and Web of Trust developed by Phil Zimmermann. The former is completely centralized and is limited to SSL/TLS encrypted communication on websites, with HTTPS websites using this type of certificate for website identity verification. The latter requires prior knowledge of the PGP public key of the interacting party and raises security and scalability concerns. There is no clear method to check the authenticity and validity of identities or to handle authentication errors. Furthermore, the use of cryptographic principles and command-line operations makes it unfriendly to regular users, making it difficult for general organizations or individuals to establish trust and achieve network effects.
Regarding the second point - "ensuring that all content in the information comes from a genuine and valid organization" - in the face of massive amounts of information, especially information involving wallet and asset interactions, both in Web2 and Web3, there is a need for a reliable verification path to help organizations and celebrities address rumors in a timely manner and help users verify information to maintain reputation and protect information and asset security.
Web3 has always lacked an anti-fraud identity verification method and a trustworthy path for verifying information that addresses these two issues. It wasn't until the emergence of the DID+VC identity system that a solution was proposed.
Since a subject's DID can be the result of KYB and KYC authentication, with its history recorded and verified through VC, in this process of authentication, recording, and verification, no one other than the user and the reputable organization responsible for issuing VC has knowledge of the user's private personal data.
Alternatively, for organizations sensitive to KYB, they can associate their DID with their official public channels for authentication, thereby authorizing an official attribute for the DID. From then on, only information published through that DID will be considered credible (although it may not have full legal protection, reputation is an important element of societal recognition). This helps with the identification of genuine and fake DIDs.
Driving DeFi Development
All user on-chain activities can be recorded in VC, gradually accumulating to form their own on-chain credit as an important attribute of their identity. This can provide convenience for users to access third-party services. The DID+VC identity system can reflect users' on-chain economic behavior while protecting their privacy. This information can be recorded, verified, and presented in the form of VC. It can help DeFi assess the on-chain financial credit of organizations or individual users and assist users in obtaining credit loan services similar to traditional finance. Token pledging models may be weakened or replaced, bringing better liquidity and capital efficiency to the current DeFi ecosystem.
At present, the expansion of DeFi credit business is mainly limited by the identification of on-chain identities corresponding to real identities. If DeFi wants to interact accurately and effectively with users' off-chain financial data to help evaluate users' on-chain credit and even pursue on-chain default behaviors, KYC authentication is inevitable. However, this may make the natives of Web 3 feel uncomfortable, as it involves the risk of privacy information exposure and the moral risks of certification institutions.
On the other hand, it is difficult to judge and measure the credit level of Web3 users, which has also become one of the main reasons hindering the realization of low collateralized credit business in DeFi. Therefore, it can only guarantee the safety of project funds itself by increasing user collateralization ratio or over-collateralization, but at the same time, it reduces the capital utilization efficiency of the DeFi ecosystem, weakens the overall liquidity of the crypto ecosystem, and excludes most cryptographic users who hope to use credit leverage. However, for this group of people, they borrow precisely because they lack funds or collateral, and due to the maturity and application scope limitations of the off-chain credit system, they may have difficulty obtaining ideal credit limits due to insufficient credit records in the real world.
The DID+VC identity system can provide a potential solution to the above-mentioned issues in DeFi credit business. With VCs that are entirely controlled by users and have multiple presentation functions, it can (1) reduce the cost for credit institutions to collect and verify past credit data, even if future DeFi interactions with off-chain data are required to implement KYC authentication; and (2) ensure the privacy demands during user data verification and presentation. Apart from the trusted public institutions for KYC authentication, the institutions that certify the corresponding financial data, and the users themselves, no one knows any relevant privacy data of the user. In case of any leakage, there is a clear path of responsibility. In this way, DeFi applications can easily provide targeted services for different users, such as verifying users' past on-chain and off-chain credit situations through users' DIDs and verifiable digital credentials. If the repayment records are good, they can obtain low-interest credit loans or loans with low collateral requirements.
Conclusion
DID+VC Identity System is the cornerstone for Web3 to reach the public.
As mentioned at the beginning, our expectations for blockchain or Web3 come from its ability to resist privilege and involuntary censorship. However, this does not mean we don't need trust at all. What we want is to weaken or eliminate trust in centralized institutions that would betray or tamper with our information, and to achieve this through data sovereignty. But at the same time, we still need credible institutions with legal obligations and responsibilities, such as public security and government, to authenticate the true credibility of various organizations and individuals in the network, as well as the credibility of information and objects. We need them to supervise all entities (organizations, individuals, information) in the network, to prevent and monitor fraud events caused by identity information forgery, and to implement legal accountability procedures afterwards, cutting off the chain of information leakage and recovering part or all of the economic losses. All of this requires regulatory support and the implementation of KYC and KYB. Even if a person can have multiple DIDs, we only have one true identity. Only when multiple DIDs of a person are associated and verified with their real unique identity in reality, can we effectively eliminate fraud events caused by information theft in both Web2 and Web3. This is also what makes Web2 data have to be used in some way in the Web3 world and enriches the application scenarios of on-chain DIDs. During the transition period when humans enter the cyber world, DIDs will carry the mapping of Web2 identity and social relationships in the Web3 world.
Of course, whether it is secure multi-party computation, homomorphic encryption, or zero-knowledge proofs, if KYC certification based on these encryption technologies can be widely implemented by credible institutions with legal responsibilities, Web3 can be considered safer than Web2, because currently, some of our KYC certifications and very important identity privacy data are controlled by many commercial institutions. And when the DID of an organization or individual has a certain degree of recognition in the network, more readable DIDs can endorse them. Of course, this road is very long, and there may be other solutions emerging in this process, so let's not discuss it in depth for now.
The DID Identity System, through cryptography and the technical interactive logic of the system, allows users to own their own identity data, breaks through the pain point of information abuse in the traditional Internet, and increases the "malicious" cost for organizations and hackers. While giving users data sovereignty, it gives them a sense of security. It shows people the dawn of the ideal DeSoc digital society in Web3, which is constituted by "code replacing human governance". It can combine user identification issues in DeFi, DAO, GameFi, and other tracks, solve on-chain KYC privacy protection issues, reform community governance methods, and prevent witch and phishing attacks, making Web3 a society that is safer than Web2, more inclusive to users, and more respectful of user rights and preferences.
Of course, the realization of this beautiful vision still requires a set of standard cross-chain, cross-platform, and even off-chain protocols to support it, as well as recognition from countless users, platforms, and even offline institutions, and the formation of network effects in its usage.
