MetaMask officially announced its support for EIP-4361. Many friends are confused about this protocol. On the surface, it is not much different from ordinary signatures. This article explains it for everyone. First of all, you must understand that EIP-4361 is actually a small thing, but the field that can be extended behind it is very large.

EIP4361 is a technical specification standard proposal related to Ethereum login. Ethereum login SiwE (Sign-in with Ethereum) is a decentralized identity authentication method that enables users to use their Ethereum accounts for unified login and control identity, rather than relying on traditional username/password authentication used by centralized companies. In a previous interview, Vitalik once proposed the three biggest opportunities for Web3 in 2023, including Ethereum login. He said that any technology that helps Ethereum take login rights away from centralized monopolies such as Facebook, Google, and Twitter will eventually enable Ethereum to gain more market dominance in Internet applications, so the login system is what Vitalik believes is an important direction for competing for the next billion people.

In fact, for Ethereum, I can feel its internal anxiety now. Although Ethereum's current position seems unshakable, it is now facing great competitive pressure, especially with high-performance new public chains such as aptos and sui in front, and application chain industry chains represented by cosmos in the back. This is why Ethereum must be so determined to switch to POS, engage in Layer, and do sharding, etc., to optimize and add chips in consensus and performance. On the other hand, it is also facing C-end entry-level fields such as ENS and login. Go deeper, deeply bind with the C-end to build its own moat. It is also worth noting that there are three supporters behind EIP4361, namely the Ethereum Foundation, ENS and Spruce. In addition to the Ethereum Foundation, the other two are DID companies. To some extent, it can be said that the two DID companies and the Ethereum Foundation have established industry standards together, so the standard cannot be completely neutral. You can see that the binding with ENS in the document is also relatively deep, including the ability to resolve ENS domain names, etc. The following is the official website of SiwE: https://login.xyz/

Among them, ENS is already very familiar to everyone, but Spruce is relatively unfamiliar. There are almost no reports and interpretations of it in the Chinese area. Its mission is to enable users to control their personal data. It has been supported by a number of star capitals including A16Z and YC. Its field is classified as SSI self-sovereign identity under the DID category, enabling individuals to control their own identity data, including deciding which third-party applications can use it and how to use it. So if we often understand DID as proving who you are after data collection, then SSI focuses on authorization, use and management at the data level.

Before talking about Ethereum logging into SiwE, we need to first talk about the traditional account login system and the existing connection wallet signature, and then we can understand the differences and advantages of SiwE.

The traditional account login system uses mobile phone numbers, email addresses, passwords, etc. to centrally save user accounts and perform login and verification. User accounts are completely stored in a centralized database, so there are problems such as cancellation, transfer, and data leakage. It has gone through two stages of development. Before the emergence of giant Internet companies with their own ecosystems, such as Tencent and Alibaba, each company or even each product independently maintained a set of user account systems. Generally speaking, there will be a User table to store all the user's account information, including the user's name, password, mobile phone number, email address, etc. Each time a user registers, a piece of data will be stored in the User table. When logging in later, the user enters the user name and password for corresponding matching. It is very troublesome for users to manage a large number of accounts and passwords by themselves, and it is easy to lose or forget them. For convenience, many users will set the account passwords of all products to the same, which means that as long as the database of a product is leaked, hackers will use database collision attacks to batch log in to all products. With so many accounts and centralized management, the risk is extremely high, but later a large number of mobile phone verifications were used, and the painful stage of changing mobile phone numbers appeared again.

Later, as Tencent and Alibaba had their own product matrix and ecosystem, users had to switch between different accounts to log in between their own products, which was very troublesome. The biggest problem was that the accounts between the products were isolated, which prevented Tencent and Alibaba from fully "utilizing user data". For example, I bought bed sheets on Taobao and ordered a takeaway on Ele.me. Then, through data analysis, I could actually be labeled as a "working single youth". However, because these are two products, each with its own account system, there is no way to know the relationship between the users of the two products. The method is either to match and identify through a unified account, such as using a mobile phone number to register, so that all products using the same mobile phone number are the same person. The other method is to use a single sign-on or unified login method, such as the most commonly used WeChat login. The figure below is a flowchart of WeChat login. Users using WeChat as the login method can avoid the redundant process of re-registering and managing accounts, which lowers the user threshold for third-party products and allows better customer acquisition. For WeChat, if more users and third-party products use WeChat as the account login entrance, its competitive barriers can be greatly improved.

The toC login system can use ecological-level enterprise solutions such as Tencent and Alibaba. The toB login system also faces more troublesome problems. As the company develops, the products used internally will be diverse, and the sources include third-party customized procurement, SaaS manufacturers, self-research, etc. In addition, the large number of employees involves a large number of permissions, data security and other issues. Therefore, how to enable tens of thousands of employees to use hundreds of internal products smoothly and safely is also a problem that needs to be solved. Companies such as Authing and Okta provide single sign-on solutions for enterprises.

The above is the main evolution of the account identity system of traditional Web2 in the past 20 years. The most intuitive difference in experience that Web3 brings to ordinary users is that all Web3 products can be used with one wallet. This is the most direct way for users to feel the meaning of the global network of blocks, or to truly realize the "interconnection" of the network.

However, due to the characteristics of on-chain assets, everyone is responsible for their own security. Unlike Web2, there is no longer a third-party platform that has the responsibility and obligation to ensure the security of user funds. As a result, users will be exposed to a large number of phishing websites. As long as relevant signatures and authorizations are made, assets may be stolen. In particular, the information disclosed during wallet interactions represented by metamask is too little and the readability is very poor. People without a technical background often cannot understand what the pop-up content requiring signatures and authorization means. Therefore, strict standards need to be established for actions that require user signatures and authorizations, and users need to be fully informed of the content to be executed.

EIP-4361 clarifies the standard process for how Ethereum accounts are authenticated by off-chain services. Authentication is performed by signing a standard message format, which is structured using session details, security mechanisms, and scopes. That is, it is presented with standard field parameters, providing developers with the infrastructure to create a unified identity layer for Web2 and Web3 applications. This process is free for users, who only need to sign the message. There is no need to trade with the blockchain or pay Gas to miners.

As stated in the document, "As a web2 company, you will have the opportunity to become the first point of contact for users to enter web3 and help them control their digital identity." SiwE hopes to standardize the process of connecting wallets, sending signatures, and completing logins, so that more Web2 products can access it and make it a login option. Just like when we use certain products, we can choose login methods including Google login, Twitter login, and Facebook login. Below, we can put an Ethereum login, and embed the login entrance to cover a large number of web2 products for users.

The motivation for these web2 products to connect to SiwE is that they can provide corresponding services based on the user's public on-chain assets. That is, if you log in with Google or Twitter, you only complete the login action, but if you log in with Ethereum, you can provide more specific services based on the assets held by the user, such as a 20% discount if you hold a certain NFT.

The proposal link for EIP-4361 is as follows: https://eips.ethereum.org/EIPS/eip-4361. The figure below shows the template message of SiwE, the complete ABNF and the corresponding pop-up window style. It can be seen that the content Message that the user wants to execute, the URL URI for requesting login, the current version Version, the logged-in chain Chain ID, the Nonce to prevent replay attacks, the login validity time Issued AT and the end time Expires AT are revealed in a very structured and standardized way.

ABNF stands for Augmented Backus–Naur form, which is a formal system for describing a language as a two-way communication protocol. This is also the focus of EIP-4361, which standardizes the login process.

As mentioned above, ENS is behind EIP-4361, so the proposal also includes a deep embedding of ENS. SiwE can be used to parse ENS data, including ENS name, ENS avatar, and any resolvable resources specified in the ENS document. As shown in the figure below, in addition to its own domain name, ENS can also bind a lot of information including wallet address, email, discord, twitter, etc.

In addition to standardized login, EIP-4361 can also prevent phishing attacks to a certain extent. Currently, a large number of users have their assets stolen by phishing websites every day. EIP-4361 has three steps in the process of wallet login.

1. Verify the message and check whether the signature content conforms to the ABNF standard format mentioned above

2. Verify the domain name. If it meets the login criteria of EIP-4361, the wallet will verify whether the URL for initiating login meets the URL submitted in ABNF, so as to avoid misidentification.

3. Then create an Ethereum login pop-up window. The specification is that all terms must be fully displayed to the user, and the user is required to scroll to the bottom of the page before signing. This is similar to the user guidelines of many apps. You must scroll to the bottom to ensure that you have read it in name before you can proceed to the next step.

There are 4 items mentioned in the design specifications

1. It is necessary to present a page that humans can understand, most of which do not work for machines, such as JOSN, hexadecimal code, base encoding, etc. This is the problem I mentioned above with current wallet interactions. Non-technical people have no idea what it means when they click on it.

2. The backend of the application needs to provide fully available support for its terminals, and there is no need to force the wallet to be modified. This is mainly to require that there should be no experience threshold for users when accessing SiwE.

3. For application wallets that already use SiwE, a simple and direct upgrade path should be prepared. As mentioned above, there will be a version number that identifies SiwE. Subsequent SiwE upgrades must also ensure compatibility.

4. You need to be fully prepared to prevent replay attacks, malicious signatures, etc.

In addition, the document also mentions the key management issue. That is, because SiwE hopes to have many Web2 products that can be connected and bring more non-circle users into the world of Web3, mainstream users are already accustomed to the "retrieve password" function of Web2 products. In Web3, if your private key is lost, it cannot be retrieved. Therefore, this issue has a high educational threshold for a large number of Web2 users. In fact, we also look forward to the popularization of account abstraction AA wallets to truly and effectively solve this problem.

The above is an interpretation of the transformation of the Web2 to Web3 account system based on EIP-4361. In fact, EIP-4361 itself is not an event with huge impact like account abstraction and Shanghai upgrade. It is more about establishing a standardized industry standard. However, it is precisely this kind of silent optimization that will gradually improve the experience of Web2 and Web3 users.