Discussions about DID can be found everywhere, but the concept of DID seems somewhat broad and confusing; Are you expecting someone to help you sort out the DID thing? Then don’t miss this article!
- DID is now generally referred to as “Decentralized Identity”, which is a digital identity without the final guarantee of a centralized institution, which is an extension and extension of the Web2 “user portrait” concept in Web3.
- DID-related tracks are mainly divided into three layers: application scenarios, identity and credentials. The credential layer is the constituent component of DID, the identity layer is the specific form of DID, and the application scenario layer is the value embodiment of DID.
- The final form of DID development may be that each user has a unique network-wide identity, and a local identity of multiple subdivided scenarios. Users can remember and identify DID through domain names, manage DID and interact with application projects through wallets, and integrate different credentials and local identities on multiple chains through various protocols in wallet integration.
- DID is not currently the direct needs of users, but more of the needs of the project side of the application scenario.
- DID development is still in its infancy, and the iteration is relatively slow, so far no DID system can accumulate a certain network effect; This is mainly due to the difficulty of the current development of Web3 non-financial application projects.
- The overall logic of DID first-level investment: starting from the user, the application precedes the protocol
DID is a hot concept in the field of Web3. On Twitter, there are Twitter spaces that discuss DID almost every week; In various Web3 sharing sessions offline, DID is also one of the enduring hot topics; On the financing deck of the project, whether it is an application project such as social, GameFi, DeFi, NFT, or an infra/middleware project such as wallet, domain name or even public chain, DID may be added to its narrative.
However, such a high degree of popularity inevitably makes the word DID widely used and even abused:
- In the beginning, the full name of DID was “Decentralized Indentifiers”, which literally translates to “decentralized identifier”. It is the most influential international Internet technology standards body, the World Wide Web Consortium (W3C), which is a set of standards led by concerns about the centralized identity system of Web2. This DID concept has no direct correlation with blockchain/Web3 at the beginning, but if you search for “DID” directly, you can still see that many articles talk about DID is this specific standard
- In today’s Web3 communication, DID is more often seen as the abbreviation of “Decentralized Identity”, that is, “decentralized (digital) identity”. However, decentralized identity itself is also a word that lacks a clear definition, and although at first glance everyone can understand its general meaning, the specific things referred to in different scenarios may be very different; And in the world of Web3, it seems that anything you can do can be related to it. This is why the concept is confusing in the current discussion of DID.
The DID discussed next in this article will adopt the latter concept of “decentralized digital identity” and will refer to the W3C’s Decentralized Indentifiers standard in DIDs to avoid confusion.
This article is divided into the first part and the next part. In the previous part, the author will systematically sort out the DID track by application scenario layer, identity layer, and data layer to help readers understand the differences and connections between various concepts; In the next part, I will elaborate some subjective views on the future development and early investment of the DID track for the reader to think about.
Part 1: Panoramic interpretation of decentralized tracks
In Web2, digital identities are platform-centric, and different products within the same group are connected through an account system. For example, Tencent’s email, games, finance, etc. can all use the same account; Google, Facebook and other Internet companies also have their own account systems. Although this identity system is easy to build, its drawbacks have been widely known: the platforms do not communicate with each other’s accounts, and users have no way to control their identity data.
In current Web3, user interactions are primarily based on wallet addresses, so a series of activities around addresses constitute Web3’s most native digital identity. But the cost of creating a new address is almost negligible, and few people will bind themselves to an address. This results in users giving up the “identity” represented by an address at any time, or creating a large number of address “identities” at zero cost, which in turn leads to application scenarios that limit this digital identity.
The problem that DID hopes to solve is to construct a depiction of a person’s identity in a decentralized digital world.
First, the application scenario of DID: If we already have a mature set of DID…
DID is an abstract concept, in order to have a better intuitive understanding of it, let’s first block out the details about how DID is implemented, starting from the application scenario: if there is already a mature set of DID in the Web3 world, what can it do?
The author roughly divides the narrative of DID at the application scenario level into two categories: Reputation and Relationship.
Their main way of distinguishing them is to assume that if you are ready to give up your existing “digital identity”, can you reconstruct a new identity that can represent you in a shorter period of time?
If it’s the former, it’s the Reputation class; If it’s the latter, it’s the Relationship class.
1.1 Reputation: Reputation/resume/social display
This type of application scenario focuses on evaluating and classifying users by simplifying digital identity into some explicit trusted labels, so as to achieve a rapid screening effect. Here are three specific related examples: credit lending, job hunting, and stranger socializing
Web3 credit lending, hoping to give the user’s account address a “credit score”, so as to calculate the amount of pledge in the credit loan can be reduced. This credit score can be completed through the on-chain identity/asset proof, and can also be combined with the analysis of the past operation records of the user’s on-chain address.
Web3 job recruitment, hoping to be able to generate a user’s resume on the chain, so that users can quickly prove their ability to Web3 project parties/DAO/communities, etc., and reduce the information friction in the Web3 job recruitment process. The certification of work experience and Web3 ability in the resume can be completed through on-chain address analysis, multi-signature wallet address signature of the former owner, Web2 company mailbox authentication, etc.
Web3 Stranger Social (including opposite-sex social, interest social, etc.), hoping to quickly construct a tag description of a user. The description of such tags can depend on NFT holdings, for example, BAYC holders can be labeled “rich”, and holders of various interest classes and community NFTs can also be labeled accordingly. Users can integrate these tags and put them on their social pages to show; Users can also quickly filter who they want to socialize with based on these tags and have a preliminary understanding of their interest preferences.
1.2 Relationship: DID relationship application scenario narrative
This type of application scenario focuses on doing some more complex and comprehensive application analysis by viewing digital identity as the accumulation of users’ data in Web3. Here are four specific related examples:
The Web3 recommendation system hopes to form a user portrait through the accumulation of the user’s Web3-related data, and then carry out targeted personalized recommendation and advertising display. The narrative of this set of user portraits is actually inherited from the core logic of the platform manufacturers in the mobile Internet era, which has been proved feasible. And in Web3, not only can identity data be interconnected across platforms, users can also have ownership of their own identity data, open sharing rights, so that the user portrait system built may be more user-friendly than Web2.
Web3 acquaintance socialization, hoping to form a set of users’ social graphs through the accumulation of users’ social interactions in Web3, which can be used by various new apps. In this way, users can quickly find their acquaintances and friends when using new applications and entering new games, without having to add them back to themselves like Web2.
Web3 games hope to build a set of game account system (GameID) to portray users’ interests and abilities in games through the accumulation of user data in Web3 games. For example, if A user may have a very early record of participation in several Web3 card games, these can be recorded in GameID, so that if a new card game wants to find early users, it can give priority to someone like A.
DAO voting governance, sometimes want to have a “one person, one vote” fair vote. But how to prove that a person only votes once, rather than registering multiple accounts to swipe votes (witch attack), is a puzzle. This problem can be solved through the analysis of the user’s address history or the authentication of real people.
1.3 The connection between the two types of scenarios: from point to surface, and then from surface to point
In fact, the relationship between Reputation and Relationship applications is not so clear-cut, more of a network of interlaced relationships.
More precisely, various explicit trusted labels are like “dots”, which accumulate around the same identity over time, eventually generating a complete “face” of the user profile; When the user or project party really wants to use this “surface”, it also needs to be further processed to simplify it into several “points” that are easy to describe and understand.
For example, in the case of NFT holding, in the early stages, a user may only be labeled as BAYC holder, Azuki holder, etc. (dots); But over time, if we find that whenever a popular NFT appears, the user will participate in the transaction (face), then we can do a generalized analysis and label him as a “hot NFT trader” (point).
The above is basically a summary of all DID narratives at the level of application scenarios. As you can see, it basically covers almost all Web3 application layer narratives, which is why DID is also known as the “identity infrastructure” of Web3 applications.
Second, the original data form and credentials: where do the attributes that make up the DID come from
Perhaps the reader has sensed that in the above different application scenario narratives, each digital identity specifically refers to different things, but they can all be called “DID”. In fact, there are two key issues:
- This “decentralized identity”, what specific labels/attributes/credentials are it composed of? For example, what it wants to connect to is the user’s NFT holding, on-chain interaction records, or the user’s social relationships, or the user’s identity information off-chain?
- This “decentralized identity”, which identifiers (IDs) are aggregated on, or what is the main interface for external interaction? For example, do we use an NFT, an address, or a domain name to represent an identity? How do we take an identity to interact with the app?
Sort out these two questions, you can clearly see the various types of projects at the DID level at the identity level.
Let’s first consider the first question, i.e., where exactly do the properties that make up a DID come from.
2.1 Credentials: Why is it important for decentralized identities?
Let’s look at the following example: You have a new acquaintance, he said, “I am Zhang San, born in 1990, graduated from Peking University with a bachelor’s degree, and you know your father very well.” He asks for you, but for some reason you have a great distrust of the content of his self-introduction. So how should he prove to you the truth of what he says?
If he wants to prove his name and age, he can show his ID card, and even go to the police station with you to prove that the ID card is his; If he wants to prove his academic qualifications, he can show his graduation certificate or send you a certificate of the student information network; If he wants to prove that he knew your father well, he can contact your father to come to you for instructions. Conversely, if he asks you to prove his identity, but he can’t do so when you want him to provide the specific credentials described above, then you have enough reason to doubt the veracity of his statement.
Therefore, we can see that an identity is composed of many attributes, such as the name, birth year, education, social circle and other attributes involved in Zhang San’s statement to himself just now. However, without the corresponding specific credentials, these attributes have no credibility, and most applications will not adopt a digital identity without credibility. Because in Web3, the attribute sources of an identity are more diverse and the potential users are more extensive, it is difficult to find a centralized total guarantor, so the credential verification of each attribute is more prominent.
2.2 Classification of the source of the original data of the document
So, when we study the specific composition of a DID, we are actually focusing on specific credentials.
The user’s on-chain data, due to the immutable nature of the underlying layer of the blockchain, is the most natural and intuitive source of credential data. Even this trust can be based solely on the underlying public chain, without the need for a specific certificate issuer. For example, to prove that wallet address A has indeed transferred money to wallet address B, simply check the corresponding on-chain information. This lack of trust from the issuer of credentials is something that several other sources of credential data do not have, and is one of the core charms of blockchain. There are many Web3 tool products, which do the integration and analysis of on-chain data.
However, in the current Web3 world, on-chain data is mainly based on transfers, DeFi interactions, and NFT transactions/holdings, and the identity information it can bring is limited. However, in the real world, many times the premise of trusting a credential is to trust the issuer of a credential and the construction of this trust relationship is in Web2 or the real world. Many times, it’s hard to put the entire verification process entirely on the chain, such as a driver’s license – no matter how digitized, the test itself still happens in the real world.
At present, there are three main forms of Web 2, real-world data and trust relationships into trusted credentials: SBT, VC, and PoP.
2.2.1 Soul binding token (SBT)
SBT (Soul Bound Token), or Soul Bound Token, is a new concept elaborated in the article “Decentralized Society” published by Vitalik et al. in May 2022.
Since SBT does not currently have a general clear standard, in fact, SBT can be simply understood as Non-Transferrable Token, that is, “non-transferable token”. In fact, credentials in the form of such tokens have long existed, such as those issued by POAP and Project Galaxy.
The implementation of SBT is the simplest, and it naturally has very good interoperability and openness. And, since SBT is on-chain native, it can also be used as a “result certificate” for on-chain data analysis methods, such as on-chain credit scores.
The main problem with SBT is the user privacy-related issues caused by its openness. The openness of SBT makes it easy for anyone to associate and infer about a person, and can make privacy invisible and stimulate some forms of discrimination. For example, a racist employer may discriminate against potential employees by peeking into a job applicant’s wallet to show that he or she has participated in a Black Life Care organization.
In theory, through the combination of ZK technology and SBT, the privacy protection of users can be realized. However, this not only involves some difficulties in specific technical implementation, but also may affect the openness and interoperability of SBT.
2.2.2 Verifiable Certificates (VCs)
Verifiable Credentials, literally translated as “verifiable certificate”.
At the beginning of this article, it was mentioned that as early as when there was no blockchain, some people began to think about the decentralized identity of the digital world, and VC is also part of the concept and standard system proposed by W3C.
Let’s intuitively understand VC through the following example of cross-border driver’s license certification:
- If a German Hans obtains a driver’s license, a VC can be issued and signed to the German official application with its decentralized identifiers (DIDs). This VC exists in the form of a digital document and is a voucher for Hans to obtain a driver’s license, which Hans keeps for himself.
- If Hans travels to Australia and starts a road trip and needs to show his driver’s license, he can show the Australian government the VC he got from the German authorities; Australian officials can assume that Hans has the ability to drive after seeing the digital document signed by the official German ID and the information on it.
Although, strictly speaking, VCs are written in a set of standards defined by W3C, and the decentralized identifiers in them are also DIDs within the W3C system. But from the perspective of Web3, broadly using the wallet address to replace this decentralized identifier is basically logical and works, and the following figure shows the relationship between the user, the VC issuer, and the VC authenticator:
It can be seen that VC compared with SBT, its main advantage is the protection of user privacy, users can naturally disclose their own information. Moreover, its implementation can be independent of blockchain technology, that is, it has good compatibility with Web2.
The main problem with VCs is that although it has a relatively recognized set of standards, this set of standards needs to be supported by DIDs (see later below), and the advancement of DIDs is relatively slow. If the project party or Web3 community wants to set a set of VC operation process standards, then how to promote this standard will also be a difficult point.
2.2.3 Proof of personality (PoP)
Proof of Personhood, the main thing to do is to prove the uniqueness of digital identity by binding it to the information of real people under the chain. Proof of Humanity, BrightID, and IDENA are among the representative projects.
The specific implementation is mainly through KYC and video face recognition two technologies. KYC is the classic authentication method prevailing on exchanges, through KYC, a digital identity will be bound to your legal entity information (name, nationality, etc.) under the chain; Face recognition, such as BrightID, mainly enters your face information into the database, ensuring that a person can only register one ID in a project ID system.
It can be seen that the most direct application scenario of PoP class authentication at present is anti-witch attack. In addition, in the context of the consideration of cryptocurrency regulation in various countries, KYC may become a necessary condition for the formation of “legal identity”.
Third, the identity layer: the connection between the application scenario and the credential and the specific DID form
We have discussed the specific application scenarios of DID, and we have also discussed the specific components of DID identity – credentials. What connects the application scenarios and credentials is what the identity layer project does. For example, domain names, wallets, social graphs, address association analysis…
How to tell if a project is doing identity aggregation or not? Here the author proposes a judgment method: if a project (or project module) does something, neither uses DID in the specific user-oriented scenario, nor generates new credentials for the user, the main thing to do is a variety of “binding” and “connection”, then it is most likely to be the project of the identity aggregation layer.
But how to do a Web3 identity aggregation, different types of projects give different paths and ways of thinking. They can be broadly divided into two broad categories: the processing and aggregation of on-chain raw data, various credentials, and user-facing identity management tools that help users achieve data sovereignty.
3.1 Information Aggregation Protocol
The user’s on-chain data is often scattered in multiple public chains and multiple project smart contracts, so they need to be processed and aggregated to form an identity. Many projects do such an information aggregation protocol.
These protocols, often do not have a direct-to-user product, they are mainly for the project side and other agreements, can cooperate with each other in information aggregation. Here are some examples:
- Cyberconnect hopes to make an on-chain social graph that aggregates users’ social relationship data
- KNN3 Network hopes to build a user social relationship graph across multiple chains through the integration of Footprints correlation analysis, Cyberconnect and other social graphs
- RSS3 hopes to do an aggregation of on-chain content and social information, and then may develop in the direction of Web3’s information distribution and recommendation system
The following types of identity management tool projects hope to provide users with active identity management capabilities and are direct tools for users to achieve data sovereignty.
3.2 Identity Management Tool – Wallet
The wallet is directly user-facing and is currently recognized as the “Web3 portal”. Although it cannot be said to be a DID application scenario in itself, it is a natural channel connecting the application scenario and the credentials held by the user.
An ideal “DID wallet” may be like this: First, it can aggregate the addresses of all mainstream public chains, and integrate the data fragmented by users on different chains while having basic signatures, transfers and other transactions; Secondly, it can display a variety of SBT/VC/PoP credentials owned by the user, and when interacting with the application project, the user can independently authorize what data to disclose to the project, thereby helping the user achieve data sovereignty. Many wallets will mention the DID narrative, such as Unipass, ABT Wallet, Selfkey, etc.
However, current mainstream wallets such as Metamask do not have these features. An important reason is that they are basically EOA wallets, and these wallets basically only support the most native operations of on-chain addresses – query and transfer. The smart contract wallet is expected to achieve more expansion in the function of the wallet. There are actually many challenges in the implementation of DID wallet-related technologies, but they are also worth looking forward to.
3.3 Identity Management Tool – Domain Names
Although each of us has a unique ID number, in daily life, we generally use “name” as an identifier for a person’s identity (although there may be duplicate names) because it is more convenient for daily communication.
In the world of Web3, too, there is a problem: although people’s current interactions are mainly based on wallet addresses, no one wants to remember that long string of strings. If Web3’s digital identity needs a “name”, then what the domain name project does is to want to be this “name”.
ENS, the most recognizable project in domain names, has the official support of the Ethereum Foundation to provide registration services for .eth suffix domain names, and now has nearly 1.8 million registrations. Notably, SpruceID is working with ENS to advance EIP-4361: Sign In With Ethereum. If the proposal goes well, it will replace Connect Wallet, allowing the domain name to be above the wallet address and become the entrance to Web3. In addition, ENS also hopes to complete its vision of “Web3 Name” through the integration of a series of identities in the domain name.
Another domain name project worth paying attention to is Space ID, which has the official support of Binance and provides a registration service for .bnb suffix domain names. Space ID also hopes to idend the .bnb domain name with multiple addresses of users on different chains, Twitter and other Web2 accounts to become a Universal name in the Web3 field. Compared with ENS, Space ID’s product iteration speed and landing speed will appear faster.
In addition to ENS and Space ID, .bit and Unstoppable Domain have also recently completed a large amount of financing. They tell narratives related to DID, and they are basically the same.
It is worth noting that although domain names and wallets can be used as identity management tools, they are very different in terms of role positioning. They do not conflict in theory, but can work closely together: a wallet can use a domain name as an alternative to the wallet account name and use it as a “name” when interacting with the application party; Domain names can also integrate multiple on-chain addresses or even multiple wallet accounts.
3.4 Other identity management tools – Take Next.ID as an example
There are also some identity management products, the specific understanding of identity management implementation is different from the previous types of projects, but the core of the work is mainly a variety of connections and aggregation, and not limited to specific areas, hoping to do a network-wide identity integration. Let’s take Next.ID as an example, which is a new identity management product made by Mask Network.
Unlike the non-user-facing identity aggregation protocol project, Next.ID is a user-facing product. In the V1 version, users can connect and aggregate Web2 platform accounts and Web3 public chain wallet addresses through Mask Network, and can do active identity management; Compared with domain names and DIDs, it can be said that Next.ID is also doing a unified digital identity level aggregation, and does not emphasize a dominant identifier, but hopes to make it into an infrastructure for App calls after aggregating identities. If Next.ID and then start promoting your own domain name, or promote identifiers such as Mask account usernames, then what it does will have a certain degree of overlap with domain name projects such as Space ID and ENS.
However, in addition to the aggregation of the user side, developers can realize the specific operation and Next.ID interoperability between the user accounts in their products through the Next.ID Avatar system, as shown in the following figure; To a certain extent, it can do a lot of things that the identity aggregation protocol wants to do, and it can also choose to cooperate with these protocols and aggregate them again.
3.5 Local scene identity management tool
In addition to some identity management tool projects that want to make a large aggregation of user network-wide data, there are also some projects that build identity management tools based on local scenarios.
A more understandable example is the GameID that aggregates users’ various on-chain game information, such as Loots, which was more popular last year.
The ID in GameID refers more to the account system that is interconnected within an ecosystem, similar to the Shanda account and QQ number in Web2, which only want to depict the characteristics of users within the ecosystem, and do not want to do a large aggregation that represents the user’s digital identity across the network.
Therefore, instead of saying that it is DID, it is better to say that it is a local fragment and a piece of the puzzle of the user’s DID.
For example, Zhang San registered the domain name zhangsan.eth, and his ‘Shanda’ ID is 123456, which contains 5 credentials from different “Shanda Department” game projects; His “Tencent” ID is 567890, which contains 9 credentials from the “Tencent Department” game project. So although “Shanda” and “Tencent” may both have a special identity management tool to help users manage the corresponding platform accounts, they can both be aggregated by the “Web3 name” of zhangsan.eth to become a label for zhangsan.eth identity.
After years of research and discussion, the W3C finally launched the V1.0 official standard for decentralized identifiers (DIDs) in July 2022. As the original definition of “DID”, it is also necessary to clarify the relationship between W3C DIDs and the current Web3 DID system.
In the decentralized identifier architecture of the W3C standard, the user directly controls the identifier and the corresponding document. The APP can read the DID linked document with the user’s permission to achieve business, and the document contains digital identity-related information, such as signatures, encrypted data, and so on. The user proves ownership of the DID through an encryption signature. The user’s data is stored in a trusted database (such as a blockchain), and the identity data does not rely on the APP.
DIDs have three constituent elements, as shown in the following figure: DID scheme, similar to http, ipfs and other method declarations; DID Method, is a specific method identifier, every project that wants to build a DIDs identity system can apply for one, for example, Tencent can apply for a tencentqq identifier for QQ; DID Method-Specific Identifier is a specific id, what it is used for depends on the definition of the specific project side, for example, Tencent can use did:tencentqq:123456789 to refer to your QQ number 123456789.
The detailed operation process and technical details of DIDs are relatively complex, and will not be described in detail here.
DIDs are somewhat in competition with Web3 domain names, and here is a comparison between the main differences between DIDs and domain names:
- In terms of readability, DIDs lack user-level readability compared to domain names, but due to the existence of DID Method, it can have an additional layer of semantics and better flexibility
- In terms of the potential of information aggregation, DIDs coupled with supporting VC and other verification methods can theoretically aggregate more off-chain information, especially digital credentials provided by authoritative institutions; At present, the data aggregation of domain name projects is still based on on-chain information, and if you want to better aggregate off-chain information, you may need to match the VC standard
- In terms of data storage, the data storage of DIDs is not specified, it can be directly stored on the public chain, there can also be some decentralized data network (such as Ceramic Network), and even directly to the user to store itself; The data storage of domain name projects is on-chain
Overall, the DIDs system is a top-down design, more comprehensive, and more compatible standard. There are also many projects that use DIDs to implement digital identity, such as Ontology.
However, the lack of user readability of DIDs is difficult to become the “Web3 name” remembered in the user’s daily life in the long run, coupled with the fact that the user can have different DIDs in different DID Methods, so that DIDs may be an object aggregated by the domain name in the long run, so it can be called “identifier for subdivision scene / local identity management”. In addition, although DIDs have good compatibility with off-chain information in theory, for the sake of interests, Web2 companies rarely do related advances based on DIDs, and how to promote DIDs is also a problem.
3.6 Identity management tools: network-wide identity vs local identity
This local identity aggregation feature of GameID and DIDs also leads to thinking about the totality and locality of identity management:
If your identity management product cannot, or can’t aggregate, the user’s network-wide digital identity product, that is, it does not become the user’s “Web3 name”, then due to the interoperability of on-chain data, your ID may become part of those larger identity management products. For example, a small GameID is aggregated by a large GameID, a GameID is aggregated by an .eth domain, and even an .eth domain name can be aggregated by a .bnb domain. The aforementioned DIDs are likely to become such “local identities” in the future. Even to some extent, a single wallet address can be said to be a “local identity”.
However, local identity management tools also have their own value, because it can create more functions for specific application scenarios, which is not necessarily done by network-wide identity management tools, otherwise it will become bloated. For example, in a GameID management platform, users may be able to make friends with players of the same magic class in the same MMORPG based on other GameID information displays, but if a wallet/domain name project does multiple then subdivided functions, it will increase the complexity of the product and face many product design challenges.
Fourth, the ultimate form of DID’s future development
First of all, in the future, everyone will have a digital identity that is deeply bound to their daily lives:
- This DID can only have one per person (through PoP), which is passed through the entire Web3 network, and may even be bound to the user’s real identity through KYC and other ways, so as to better interact with the offline world.
- The Web3 domain name is the unique identifier of the DID, which is the user’s name in Web3.
- Users manage this DID through a wallet with far more powerful functions than it is now; Inside the wallet, multiple identity aggregation protocols may be integrated to achieve multi-address and multi-contract data aggregation of users, comprehensively displaying the user’s credentials, local identities, relationship graphs, etc. on each chain and address, as a whole user profile.
- Users interact with application scenarios such as social, recruitment, and DAO governance through wallets. Through encryption technology, users can independently control the permission of the project party to obtain data, so as to realize that the sovereignty of the data belongs to the user.
Second, everyone has multiple different digital identities in some local scenes (such as game platforms), or some scenes that do not require PoP, so as to show different selves in different scenarios. Users can freely control the interconnection between these identities, using the corresponding identities in specific scenarios.
V. Summary of the previous part
Through the above combing, I hope that in the future, when readers see a project talking about DID-related narratives, they can clearly know what kind of “decentralized identity” this “DID” refers to: is it talking about the release of a specific type of credential or the process of aggregating various credential into identity, or is it talking about the user’s management of identity, or is it talking about the specific application scenario of this identity system?
It is worth mentioning that a DID-related project tends to do more than one layer; For example, the previously analyzed Next.ID not only do user-side identity interaction like domain names, but also do identity aggregation like many identity protocols; ARCx is ready to do both the issuance of credit scoring credentials and the applications associated with them.
The following figure is a combing of DID-related tracks as a closing part of the previous part.
Next: DID Soul Three Questions
1.1 DID, is not the user’s demand now
Through the previous combing, many readers may have found that in many cases, DID itself is not the direct needs of users! From the perspective of the product manager, if DID is intended to be user-oriented, it often has to go through specific application scenarios.
Just think, if you don’t have specific application requirements now, are you interested in actively obtaining various credentials (such as going to BrightID to do a video face authentication), or going to some identity aggregation/management tools (such as Next.id), connecting your email, Twitter, and wallet addresses? I believe that most users will not.
Although if the project side provides a certain incentive, it will certainly be able to attract some users, but the characteristics of DID products determine that it is difficult to bring about the continuous retention of users by relying on this incentive itself, which is not the same as other types of projects such as NFT and GameFi.
In the long run, with the gradual improvement of DID development, users’ awareness of the management and utilization of personal identity data will become higher and higher, so it is possible that the demand for identity management will precede specific application scenarios. But at a time when the DID track is still in its infancy, this is unlikely.
1.2 DID is the requirement of the project side of the application scenario
In fact, the project side that benefits more from DID is the project side of the specific application scenario. Whether it’s quick credential filtering or quick acquisition of a user’s profile in Web3, it will bring direct gains to the project side during the cold start phase.
However, when the application scenario really uses DID and builds DID, it is not necessary to emphasize the concept of DID with the user, it is abstracted in the logic of the product. Therefore, it is not surprising that more often the concept of DID appears in the narrative of the project and in everyone’s discussion, rather than in the specific application scenario.
2.1 Three reasons for the slow development of Web3 non-financial application scenarios
The author believes that the following three logics apply to the analysis of all Web3 non-financial application scenario projects, including social, gaming, recruitment, etc. (Items with partial tool attributes such as wallets are not discussed)
- The user experience of Web3 applications is far from the current and corresponding Web2 applications. Whether it is the use threshold of the product, network latency or operating costs, it is higher than Web2.
- The user base of Web3 applications is much smaller than Web2 and scattered around the world. This not only hinders the connection between the real world and the on-chain world, but also brings more difficulties to the accumulation of network effects.
- Now in the bear market cycle, many users’ asset losses, the frequency of on-chain activities has decreased, and even some users have begun to doubt the entire industry as in 2018 and directly “withdraw from the circle”; This makes launching a Web3 application project even harder
Each of the above may be an important reason why it is difficult to develop a Web3 application scenario project. Is it that there is no development opportunity for Web3 application projects? Not. In some scenarios where Web3 is native and Web2 can’t do, even if there are the above problems, the related products can also reflect its value.
2.2 To C’s credit loan is a false proposition in the short and medium term
(To B credit lending involves more CeFi logic, so here is mainly discussed to To C credit lending)
Credit lending is the most financialized of DID’s application scenarios. This is also a frequent issue, because the existing DeFi is almost over-pledged, the capital utilization efficiency is low, in theory, credit lending can improve the user’s capital utilization efficiency, Web3 users will also have a strong demand for this.
However, I believe that To C credit lending is a false proposition in the short to medium term (such as three years), or an extremely niche field.
The main reason is that the Web3 world does not have a recourse mechanism for non-repayment of loans, as Web2 does. The ultimate cost of not repaying a loan is therefore the loss of the availability of an on-chain identity.
One could argue that digital identities are valuable in their own right, and you may not want to give up the identities you have used for many years, such as addresses and domain names, including the accumulation of various credentials and relational data above. But the question is, ask yourself, how much is the current on-chain identity of most Web3 users worth? If you can “credit loan” 100U, how many users may think of not paying back the money and would rather rebuild their identity? Unless the threshold for credit review is extremely high, it will also make it an extremely niche product.
Some people may say that if you do KYC and face recognition, you may be able to circumvent this problem. In fact, however, in rural areas of underdeveloped countries, worthless personal real identity data abounds. Think about the information that everyone sees every day such as “a certain exchange KYC account is sold in batches”, as long as the “credit limit” is higher than the construction cost of an identity, there will be professional “raising number” users, batch construction of identities that meet the requirements, and then do not repay the loan, the wool of the project party.
The maturity of To C credit lending may need to wait for the maturity of the entire DID system: on the one hand, with the accumulation of various high-value certificates and various data relationships, the cost of digital identity construction and the abandonment threshold will become higher and higher; On the other hand, with the infiltration of national regulation, Web3 loans may also establish a legal recourse mechanism, which will increase the cost of users not paying off loans.
Third, what is the logic of DID track first-class investment?
Here, I would like to share some of my personal overall thoughts on the first-class investment of DID Circuit:
- The overall logic: Starting from the user, the application precedes the protocol
- Specific priorities: Identity management > Application scenarios > Credential publishing > (not user-facing) identity aggregation protocol
3.1 Overall logic: Starting from the user, the application precedes the protocol
The “application” here is a broad “user-oriented” concept, including specific scenarios, identity management, and credential publishing; “Protocol” refers to various protocol products that are not directly user-oriented, and they often serve the application project party or other protocols in the form of API calls.
There are some protocol project parties, may think like this: as a protocol, I will continue to persuade more application project parties to access my protocol, most of these applications may be only short-lived, a few may develop well, but in any case, my data has accumulated, began to have data barriers and network effects; In this way, my value is getting higher and higher, and more and more application-layer projects will come to me to cooperate; Finally, I can charge for the API or provide related value-added services. It is true that the above logic is already reasonable, and there is also the possibility of going through.
However, the author is more inclined to give priority to applications for the following reasons:
- First of all, in the flow of data, the application must be ahead of the protocol, so there will be a greater initiative. At first glance, the agreement and application battle seems a bit like “chicken or egg”, but it is not. Because it has been discussed above, the accumulation of DID data depends on the interaction of users in specific application scenarios.
- Second, what the agreement project party does may not be mature and is still in the concept/testing stage; Even if it is mature, it may not be able to meet the needs of the application project side very well. Instead of feeding back to the protocol and expecting its iteration, the application party should make one of its own.
- More realistically, data barriers, network effects, such an excellent narrative that has been verified by Web2, in the embryonic development of the track, no good, ambitious application project team will actively abandon this narrative, and completely leave the capture of this value to other project parties to make agreements.
After all, the current financing of Web3 application projects is itself very difficult, why don’t the application project parties also talk about the DID narrative related to the agreement as their valuation support? For example, first attract user participation and accumulate data through the application itself, and then protocolize the user’s data in the application to relevant partners and ecosystems, so as to further accumulate data and eventually develop into a DID system. This narrative is often completely unreasonable.
In addition, most DID protocols actually lack technical barriers, and the barriers are more reflected in a certain engineering complexity; For a good team, it will not be difficult to develop the agreement at the beginning; Even if the application project party initially uses other protocols for rapid product iteration, if the application can really achieve certain success, the project party may consider a self-developed agreement to increase the development limit of the project.
3.2 Specific subdivisions that deserve attention
Priority: Identity Management > Scenarios ≈ Credential Publishing > (not user-facing) Identity aggregation protocol
Identity management tool projects: wallet and domain name projects are preferred. After all, in the future author’s ultimate morphological conception of DID, both of these occupy a very central position.
Application scenario projects: As mentioned earlier, more opportunities arise in Web3 native application requirements than in forks of Web2 products. Credentials-based Web3 recruitment, NFT-based interest social/heterosexual socializing, etc., all belong to this irreplaceable Web3 scenario.
Credential release projects: credential publishing tools/platforms may run out of 1-2 heads of general projects, and several corresponding tools for subdividing application scenarios; If the specific credential publishing project can provide high-value vouchers, it is also worth paying attention to.
If you disagree with the author’s point of view;
If you have new and interesting thinking about DID-related tracks;
If you are doing DID-related entrepreneurship;
Feel free to contact me to discuss the exchange!
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/did-track-the-most-detailed-combing-did-soul-three-questions/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.