The Final Battle of Decentralized Identity

*Original Author: Xia Ke Zhang, * Uncertain Thinking

Current Issues with Web3 Authentication

When users first play StepN, they need to register using an email account. After completing the registration, they need to import/create a cryptocurrency wallet. If they import an existing mnemonic phrase (from a wallet with assets), they may worry about the security of the mnemonic phrase being exposed online.

If they create a new wallet, there are still concerns about improper backup of hot wallets. This is a worry for experienced crypto users, but for a newcomer to web3, concepts like mnemonic phrases and how to securely store them are very unfamiliar, which can easily lead to asset loss.

When publishing articles using Mirror, users need to link their wallets for signature authentication. It provides a relatively friendly "remember me" feature, allowing users to avoid signing again for a period (about a week) after one signature, which makes it easier for users. However, for someone like me who updates monthly, having to connect a hardware wallet to sign every time feels cumbersome, especially just to publish an article.

A more extreme example is some current social web3 applications, where actions like following someone or commenting require signature verification. To make it easier, many people will create a hot wallet (if they are security-conscious).

However, some applications require using old addresses for verification due to historical behavior tagging and airdrop temptations. These addresses often contain many assets, and if users are not careful with their signatures, they can easily grant excessive permissions, leading to unnecessary asset loss.

For large assets participating in DeFi, users often utilize multi-signature and hardware wallets as relatively secure infrastructures. These addresses may also be used for trading NFTs, which often require signature authorization. Currently, the signature information in applications is not intuitive enough, and most users do not fully understand the specific content of the signatures, which can easily lead to excessive authorization and hacking.

These typical scenarios summarize the current issues with web3 identity verification: they are not user-friendly, convenient, or secure.

The root cause of these problems is largely due to the unclear definition of identity and accounts. In most cases, a wallet is considered both an account and a user's identity.

The development of decentralized non-custodial wallets is far from keeping pace with the current speed of web3 development. When DeFi emerged, this model did not seem to pose many problems. However, as more non-financial decentralized applications appear, this authentication method will highlight many issues.

Common Authentication Scenarios in Web2

In the early days of using web2 applications, most adopted an account + password authentication method for access. To make it easier, many websites set the same password (which is very insecure).

With the popularity of mobile applications, we gradually became accustomed to the phone number + verification code authentication method. Even on the web, this verification method has slowly gained support.

To make it even more convenient, many applications have adopted one-click verification methods based on WeChat/phone numbers, and passwords are rarely used now.

With the development of biometric technology, many devices now use facial recognition and fingerprint verification methods, and verification codes are constantly being updated and replaced.

Web2 identity verification is evolving towards a secure and convenient passwordless authentication direction.

Passwordless authentication is much safer than the account + password method, as the latter has weak password issues and a large amount of leaked data, allowing hackers to exploit big data and credential stuffing to crack accounts.

If good security habits are followed, most mobile applications are difficult to hack. Using applications like 1Password (one application, one password) makes it relatively secure for applications that require password setup.

Looking at the development of authentication in financial applications, online banking was initially inconvenient, requiring a password card for transfers. It later evolved to using USB keys for verification.

For individual users, mobile online banking now offers an experience similar to other non-financial applications, with phone number + facial recognition authentication, and transfers via facial recognition/verification codes, which is very convenient.

However, this also poses certain security risks; if a phone is hacked, there is a risk of bank accounts being stolen.

For enterprise users, the USB key (digital certificate) verification method is still in use. In interbank communication, point-to-point encryption is mostly adopted.

Many first-time web3 application users often wonder why these applications are so difficult to use. The most intuitive reason is that most are accessed via web browsers, and user authentication is generally not user-friendly enough.

Can’t the friendly and secure verification methods widely adopted in web2 be applied to web3?

Here we need to mention the most important difference between web3 and web2: the autonomy and control of user assets (ownership).

In web2, data and assets are on centralized platforms, making it difficult for users to have autonomy.

In web3, the decentralized nature allows users to have autonomy from a cryptographic perspective: your keys, your coins!

This is also why the authentication method in web3 requires users to sign independently, as only users possess this information.

What Services and Capabilities Should Web3 Identity Provide?

1. Self-Change of Keys

In commonly used web2 applications, passwords can be reset periodically to ensure security and prevent information leakage due to lost passwords.

If an account is found to be hacked, we can promptly change the password or recover the account through appeals.

In this case, our account can still be used, and other content, data, and applications associated with our account do not need to be re-authorized or linked.

However, for decentralized wallets, once the mnemonic phrase/private key is lost, the wallet can no longer be used. Because as long as someone knows the mnemonic phrase/private key, they can access the assets inside and verify various applications.

In web2, if an account is hacked, it can be appealed for recovery, and it is also easy to perform various disabling operations; as long as there is sufficient evidence, centralized handling of potential risks can be conducted. For example, appealing to different platforms, adding to blacklists, etc.

In web3, there is currently no effective preventive measure for hacked accounts. Once the private key is lost, the account becomes unusable. However, as more applications pay attention to identity behavior, many on-chain actions are related to account addresses. An address that has been used for a long time may represent a considerable wealth. Abandoning it would be a great pity.

Is there a way to allow us to change the mnemonic phrase/private key of a web3 wallet without changing the account (public key address), just like changing a password in web2?

2. Multi-Account Separation and Identity Aggregation

Currently, there are many application scenarios in China aimed at personal users for multi-account separation/identity aggregation.

For example, when using shared bicycles, sometimes we unlock them by scanning with Alipay, and sometimes we use WeChat to scan. We often don’t even notice, but we can unlock them all.

For various shared products, as long as there is a code on them, we instinctively scan with WeChat/Alipay to rent power banks, electric bikes, umbrellas, etc.

These applications are very convenient to use; we do not need to register any accounts or provide a lot of personal information, just a one-time authorization is sufficient.

In these scenarios, when renting various devices, we are actually still using the accounts of these applications, and this account is generated through identity authorization.

A large amount of our identity information and behavior is aggregated in a system called "Zhima Credit"/"WeChat Pay Score," which represents our aggregated identity in the internet world.

It is a credit evaluation system that holds various identity data and credit ratings. Different applications can apply for authorization through integration with it to read our identity and create temporary accounts.

As long as our credit meets the design requirements of these applications, we can use them smoothly.

For enterprise-level applications, an employee often uses dozens of different systems. If each system has an independent account, it becomes very inconvenient to remember. Most employees are also accustomed to using the same password, which is very insecure.

To solve this problem, there are specialized solutions for enterprise identity management (IAM) that provide a convenient and secure single sign-on and unified account password system, addressing security issues while making it easier for employees to use the systems.

Experiences like the above are also needed in web3. We hope to have different accounts while playing games, experiencing social applications, and participating in DeFi mining, but they can all be managed in a unified and secure way.

This allows for asset isolation across different accounts while enabling identity interoperability across different accounts. We can decide how to present our identity externally, controlling which identities are visible and which are hidden, as well as the behavioral relationships between them.

3. Flexible Key Management

Most internet users lack awareness of password management security and often use the same password everywhere. The most commonly used security measure is not using it at all, such as avoiding online banking.

The evolution of mobile application authentication technology is aimed at providing greater network utility for platform applications while genuinely enhancing user security and convenience. For example, methods like verification codes + facial recognition + risk control make it difficult for ordinary password leaks to cause serious impacts.

Web3 applications return identity sovereignty to users, but each person has significant differences in knowledge and skills regarding key management.

Even experienced users often make mistakes and lose their private keys, falling victim to phishing or having their hot wallets hacked due to compromised computers.

Using hardware wallets, cold wallets, and multi-signature wallets has a higher threshold, making it difficult for users without a technical background to truly master the secure usage methods of these wallets, and they may inadvertently lose their keys.

This unfriendly and not very secure key management method in web3 effectively hinders many people from participating in web3 applications.

In web2, we can use programs like 1Password or Google Password Manager to help manage keys. However, the use of mnemonic phrases and private keys often emphasizes offline backups, whether stored in hardware wallets or using more secure multi-signature technologies. This is manageable for professional users but poses some difficulty for web3 users.

Can we manage keys like in web2? Without needing to write them down or use hardware? Secure and quickly recoverable?

For different usage needs, there can be different key management strategies. Large assets can use professional-grade security solutions, while social applications can use more convenient methods. This separation of role authorization also alleviates excessive security and privacy concerns when using different applications.

Let Web3 Authentication Have the Same Experience as Web2

Many of the issues mentioned earlier, along with corresponding solutions, are currently being addressed by some web3 projects.

If we want the web3 user experience to be similar to web2, I believe widespread application of contract wallets is necessary, which will enable many currently unachievable experiences, such as key recovery, fee-less transactions, and risk isolation across multiple accounts.

1. ERC 4337 Ethereum Account Abstraction

ERC4337 is a proposal for account abstraction on Ethereum. Its main purpose is to upgrade user accounts to contract accounts without changing the consensus layer protocol, which brings many benefits.

Currently, Ethereum account types are divided into external accounts (EOA) and contract accounts. The ERC4337 account abstraction proposal suggests reducing these two account types to one, retaining only contract accounts.

The account abstraction scheme implemented by ERC4337 can enhance user experience in the following ways:

Supports Social Recovery: This scheme allows users to set multiple guardians for their wallet accounts, who can help recover wallet keys in case of key loss. Guardians can be other secure wallets owned by the user, family, friends, or even third-party institutions.

This feature can make users' wallet accounts more secure, avoiding accidental loss due to misunderstanding the principles of mnemonic phrases/private keys or poor management. Users can manage application accounts like in web2, recovering and resetting wallet account keys when they discover security risks or lose keys.

Supports Account Creation Fees Payment: This feature allows applications to help users pay the gas fees for creating accounts and can also assist users in paying transaction fees. Users can even use any ERC20 token to pay transaction fees. In simple terms, users can fully experience web3 applications without needing to deposit funds themselves.

This is very effective for ordinary users, as they do not need to pay for account creation fees, and even some transactions may not require payment. This can achieve zero-threshold user acquisition and create secure web3 wallets for users, especially useful for gaming and social applications.

Supports Account Upgrades: The wallet of account abstraction is controlled by smart contracts, allowing for upgrades to contract functionalities, enabling highly customizable capabilities for users, such as simplifying/personalizing signature algorithms.

For the implementation of ERC4337, Vitalik has provided a roadmap that includes:

Short-term:

• Launch ERC-4337 to support upgrading EOA to smart contract accounts
• Support user-friendly browser plugin wallets for ERC4337 accounts
• Implement Layer2-friendly features, promoting ERC4337 applications in Layer2 in the short term

Mid-term:

• Implement Verkle trees to reduce gas costs
• Add optional conversion from EOA to ERC4337
• Add crList logic

Long-term:

• Consider mandatory EOA conversion and a single ERC4337 account

2. Web3Auth

Web3Auth provides a social authentication method similar to web2, allowing web3 authentication to maintain a consistent user experience with web2.

Web3Auth is a B2B application that requires applications to integrate and configure it independently before users can experience the corresponding authentication experience, including:

Mainstream Social Account Login and Passwordless Authentication: Users can register through Google, Twitter, GitHub, and other OAuth providers. Users can also register through an email-based passwordless setup process.

Supports Web3 Wallet and Key Management: Users can authorize the use of wallets or key management of their choice. For example, users can log in with their existing wallets or choose key management (importing mnemonic phrases) and connect them directly to the application.

Web3Auth can provide users with a registration and authentication experience similar to web2, requiring only third-party social authentication to complete.

At the same time, Web3Auth also supports non-custodial public key infrastructure (SSS 2/3 Shamir's Secret Sharing), which greatly facilitates users who do not understand key management while ensuring that users fully control their assets without needing to manage keys themselves.

If users feel that this non-custodial method is not secure enough, they can also choose to link their commonly used wallets for login, such as Ledger, Phantom, etc. The browser plugin wallet Keplr is an extension of Web3Auth, allowing users to experience it themselves.

3. UniPass

UniPass is a multi-chain unified encrypted identity application that provides a non-custodial social recovery wallet solution based on email. It allows users to control their encrypted identity in a passwordless manner. It can also verify multi-chain addresses and even social accounts through encryption.

On the frontend, UniPass is similar to Web3Auth, providing social authentication, social recovery wallets, and other features. Compared to the functionalities already implemented, UniPass's 2022 product planning mentions capabilities that align closely with the evolution of decentralized identity expected in this article, including:

Web3 Identity Aggregation: Achieving aggregation of multi-chain and multi-account based on cryptography. Through this aggregation, users' behaviors across different addresses on different chains can be consolidated into a single identity ID, enabling trust transfer. In simple terms, it can maximize the scoring of users' on-chain behaviors.

Web2 Identity Verification: Providing the ability to verify email addresses, Twitter accounts, and Discord accounts within smart contracts, thereby natively offering Web2 identity information in Web3.

Single Sign-On and Access Portal: Using UniPass ID for unified login across multiple applications and providing users with a unified web3 portal navigation.

4. Account Naming

Identity identifiers are crucial for identity recognition. In web3, each account is a long string of seemingly random letters and numbers, which is difficult to remember and recognize.

5. ENS

ENS is a distributed, open, and scalable naming system based on the Ethereum blockchain. Its xxx.eth service maps readable names to identifiers like 0x123xxx…, which alleviates some of the recognition difficulties.

6. Nametag

Nametag aims to become a universal naming service built on the blockchain, allowing users to mint, store, trade, and use uniquely named NFTs as their universal usernames.

7. LENS

Lens is a Web3 social graph protocol on Polygon. Its goal is to form a fully composable, user-owned social graph. The protocol adopts a modular design from the start, allowing third parties to develop new features based on the protocol while ensuring that user-owned content and social relationships remain immutable.

ENS and Nametag aim to become foundational naming services for other applications to reference and adapt. Lens aims to serve as social infrastructure, with its xxx.lens being somewhat similar to WeChat names. Which method will be more popular in web3 remains to be seen.

8. Gnosis Safe

For web3 users, a more important need compared to web2 is autonomous security; all identities should be built on a foundation of autonomous control.

Compared to a simple mnemonic phrase-imported MetaMask hot wallet, hardware wallets are more secure, avoiding risks of mnemonic phrases being hacked or phishing.

Above hardware wallets, there are even more secure multi-signature solutions, primarily aimed at organizational/community management needs for large funds.

For general individuals, hardware wallets are already relatively secure. However, for organizations, considerations like single-point risk, malicious risk, and authorization risk must be addressed, making multi-signature more suitable for large fund security management.

Gnosis Safe is a smart contract wallet that operates across multiple chains and requires a minimum number of approvals to execute transactions (M-of-N).

Safe is a smart contract account that provides capabilities including: multi-signature, transfer amount restrictions, whitelisted transfers, bundled transactions, emergency freeze/recovery of accounts, and preset condition-triggered operations.

An Idealized Decentralized Identity Authentication Architecture

The extensive groundwork laid above aims to propose a framework that better helps users enter web3 applications while achieving greater security and better user experience.

In web3, the concepts of wallets, accounts, and identities are somewhat blurred, with no clear distinctions; often, a wallet is considered an account, and an account is treated as an identity.

In reality, identity is a collection, while accounts are the tangible carriers we use for applications, representing the extension of identity. Cryptocurrency wallets serve as a carrier and verification method for our accounts.

Decentralized identity can be divided into three levels: external identity, proxy identity, and sovereign identity.

1. Proxy Identity

Proxy identity consists of accounts with a series of exclusive functions, such as social accounts, gaming accounts, trading accounts, DeFi accounts, anonymous accounts, etc.

In this model, all proxy accounts can be contract accounts controlled by sovereign accounts. In case of danger, the sovereign account can reset the keys to prevent asset loss while maintaining various behavioral profiles.

These proxy accounts represent different identity roles for users, each having independent purposes and security boundaries. This avoids using a single account for everything while providing a convenient experience based on security.

For example, a social account has no assets and is specifically used for logging into various applications, commenting, liking, etc. A gaming account is dedicated to playing on-chain games, which can share or separate from an NFT account. An NFT account can be a dedicated Pi Xiu account, only buying and not selling, to avoid being hacked. When it’s time to sell, temporary authorization can be granted for listing.

Why adopt this role-separation account setup?

In reality, when using web2 applications, we often use different accounts for each application, with no unified connection between them; account names are also our subjective choices.

After the popularity of social logins, we mostly use WeChat, Gmail, and other authentication methods. This effectively establishes a new account mapping within applications rather than directly using Gmail as the account subject.

In this model, WeChat and Gmail are more akin to our sovereign identities, as they can recover accounts we’ve forgotten in different applications or reset those accounts' passwords.

The benefit of role separation is that it can isolate risks and enhance the experience of using different applications. We don’t need to open a hardware wallet for authorization every time we want to follow someone. When it comes to asset operations, we can implement more complex authorization strategies to avoid accidental or malicious theft.

Using proxy accounts, we might worry that the behaviors generated by proxy accounts cannot be shared, which could lower our ratings in certain scenarios. This issue can actually be resolved through the setup of external identities.

2. External Identity

External identity is a collection of credentials, identifiers, behaviors, relationships, and reputations.

We can simply understand external identity as a series of identity tags, primarily serving to facilitate external relationships in identifying our identities.

For example, ENS and Lens serve as identifiers for external identities, making identities more readable in social relationships.

POAP is a type of external identity that marks our participation in various activities, similar to Galaxy, RabbitHole, etc.

In Vitalik's SBT paper, many uses of soul-bound tokens are actually within the scope of external identity capabilities. For instance, our social relationships, reputation, academic credentials, etc., can all be bound to our identity using SBT.

In practical application, external identity can actually merge with proxy identity; they can be the same account address, but distinguishing them logically can better serve users or facilitate application design and experience enhancement.

For example, some users may prioritize security and privacy, so this external identity can be an independent account specifically for external display and relationship building.

The behavioral mapping of proxy identities can be completed through privacy computing, allowing our identity to appear more cohesive while enabling users to flexibly control which identity features are displayed externally. Furthermore, we can flexibly construct multiple external identities, some more authentic and others more anonymous. This will lower the psychological barriers for users.

From a technical perspective, to achieve this design, the current approach can adopt an on-chain proxy model, similar to signing an authorization on-chain to record the authorization relationship between proxy identity and external identity. If there are issues with the external identity, a new authorization can be signed to update or disable the authorization of identity behaviors. Listening to the podcast about DID in the Orange Paper, it was mentioned that UniPass adopts this on-chain authorization model.

Another more private method could use contract accounts + zero-knowledge proofs to establish an indirect relationship that cannot be directly accessed externally, proving that the user's identity is not forged, thus achieving the association and externalization of identity attributes.

Adopting this design approach of separating external identity from proxy identity provides the intuitive benefit of separating a user's WeChat account from their bank account. This way, if someone knows your WeChat ID, they cannot directly see your bank assets or even trace how your money was earned or lost.

3. Sovereign Identity

Not Your Keys, Not Your Coins.

This is the most important foundation of web3, ensuring that personal assets are sacred and inviolable.

The secure management of keys has always been the most crucial lesson for participating in the crypto game, as many people lose assets due to poor management.

However, how to securely manage keys is relatively specialized, making it difficult for new users to master in a short time. It requires a lot of practice and overcoming psychological barriers to safely use non-custodial wallets for asset management.

Keys represent our sovereign identity, asserting that everything is under our control, unlike in web2 where accounts can be disabled at will.

The secure management of keys must adopt a decentralized non-custodial approach. This allows us to have control over our accounts at all times.

For personal use, reaching the hardware wallet level is already relatively secure. For organizations/communities, a multi-signature approach can be adopted.

In the future architecture, this identity may be the least frequently used identity. It only needs to be used for authorization when creating proxy identities. When proxy identities are at risk, we can use it to recharge the keys of the proxy identity, ensuring that all assets remain within our ultimate control.

For newcomers to web3, this sovereign identity can also be implemented through third-party services. This is a decentralized non-custodial solution, such as the SSS solution from Web3Auth. This also lowers the threshold for newcomers to use keys.

The three levels of identity mentioned above can actually be a dialectical and unified whole. In extreme cases, they can be just one address, with all identities converging to a single public key address, which many users are currently using.

However, this application method is not secure enough, and many people have lost assets as a result. Due to various psychological barriers, it is also difficult to effectively combine various accounts, preventing some users who are actively building from achieving good on-chain ratings.

The current identity account system does not serve users as well as in web2. In web3, the most important issue is asset ownership, and the relationship between users and on-chain assets is bridged through identity.

Only by properly handling the relationship of identity can users better utilize on-chain assets and various web3 applications.

By implementing a layered design for decentralized identity, we can allow professionals to handle specialized tasks. If various projects can work towards a common consensus direction, they can also achieve a highly composable identity product matrix more quickly and effectively, genuinely benefiting users.

On the other hand, this is also to help users better understand the concept of web3 identity accounts. With advanced entry, they can gradually learn and familiarize themselves with the security management of identity through more usage.

Because web3 identity belongs to individuals, we need to take responsibility for our identity assets.

Ultimately, what we possess is a collection of identities (a collection of wallet accounts).

In the examples above, it may seem that there are many complex identity concepts. However, if there is such an application, it can aggregate these elements into one application, allowing users to not perceive these complex concepts and simply use it.

Future Development

To achieve this idealized architecture, what actions should we take:

• Professional web3 identity authentication service providers
• B2B first, with various DApps adopting web3 identity authentication components
• Standardized authentication services, interfaces, and processes
• User-friendly registration and authentication processes
• Provide proxy account capabilities to achieve identity authorization between accounts (on-chain)
• Support browser plugin contract wallets
• Support social authentication directly in web3 mobile applications
• Extensive support for contract accounts and secure key management in web3 applications
• One-stop comprehensive services for individual users
• Implementation of ERC4337 to achieve account abstraction
• Popularization of secure multi-signature and hardware wallets
• Decentralized non-custodial key infrastructure

What can we do for individual users:

• Based on existing conditions, define your account roles
• Use accounts of different roles to participate in different types of applications, isolating risks
• Securely manage mnemonic phrases/private keys and learn relevant knowledge
• Try using new foundational web3 authentication applications

What can be done for professional identity authentication, DID, social applications, etc.:

• Provide safer contract account functionalities
• Attempt to offer capabilities for fee payment for registration, transaction fees, etc.
• Try to penetrate web2 authentication capabilities, even to replace them.