Sign-In with Ethereum is a game-changer for user choice on the Internet.
Instead of submitting to "Big Login," users can now login using the same keys controlling their blockchain accounts--without an intermediary. This approach has the promise but not guarantee to rebalance power dynamics in favor of the user. With Sign-In with Ethereum, we open a path where large corporations can no longer strip a user's ability to access services nor spy on their actions.
Sign-In with Ethereum is an open standard for authentication developed entirely in the open, informed through public discourse with community members across dapps, apps, wallets, security firms, and far more. You can find all the meeting recordings and notes on login.xyz. This approach is a far cry from the closed development of proprietary identity systems found in tech giants or government vendors, rightfully protested by privacy and digital rights advocates.
In contrast, Sign-In with Ethereum (EIP-4361) defines an open creative commons (CC) signing format for Ethereum accounts to securely authenticate with any web-based services. It was built by the community with direct support from the Ethereum Foundation and ENS, with Spruce tapped to lead the charge late last year. I'm excited to discuss the significance of Sign-In with Ethereum, and how it is so much more than "Connect Wallet" for all builders in Web3.
Connect Wallet vs. Sign-In
The "Connect Wallet" button is a staple of dapps today. Hitting the button starts one's journey into Web3 and blockchain interactions.
However, connecting a wallet allows you to tell the app which account you claim to be using, and the guarantees stop there. It's more for your wallet to understand which account you want to use to interact with smart contracts, send crypto around, or even sign messages through the dapp. Connecting a wallet is incredibly basic--the dapp remembers nothing about you and is establishing a front for simple interactions.
When applications want richer contextual interactions with users, such as loading their preferences or private chat messages, we need to first ensure we're talking to the actual keyholder behind the account, and not someone just pretending to control the account. "Connect Wallet" does not provide this guarantee, but Sign-In with Ethereum (SIWE) does. Put another way, we need to authenticate the user to establish a session with them to securely read and write their data. For this example, I would like to introduce Connected Carl and Session Sam:
Connected Carl uses dapps and has a great time. He can make trades on Uniswap, lend on Aave, or even buy an NFT on OpenSea, just by connecting his wallet. For a while, things are going quite well for Carl until one day, he runs into an issue: he wishes these dapps remembered something about him to give him a better experience when he came around the third, fourth, and fifth times he used them.
Carl is thinking about how much better his experience could be if Uniswap automatically imported his liquidation preferences, Aave remembered his favorite lending markets or even OpenSea remembered his name rather than a 0x2Fe1a3... account. Carl has to restart from square one each time he connects his wallet.
Session Sam doesn't have this problem. After authenticating with dapps and establishing a session, this information is saved. Even if Sam disconnects and authenticates again, Sam continues from where he left off and has everything still remembered about him in the application. His information can even be saved in a remote data vault that he controls.
Unifying Sign-In with Ethereum
Across Web3, you will find many existing services offering some form of "Sign-In with Ethereum," but not many to standard. They will typically use this to establish a cookie-based session with a user which can manage privileged metadata about the account. For example, if you want to give users the ability to customize their own profiles on your website (such as OpenSea does), you should authenticate the user before they can make any changes, ensuring that only the user can edit their own profile. The workflow for this looks like the following:
The first step after connecting a wallet is to give users a human-readable message so they can understand what they're getting themselves into. There have been plenty of cases where users are presented with "LOGIN," some inconsistent phrasing about "signing in," or even sometimes just an arbitrary number ("here, sign this random crazy set of letters and numbers"). Instead, we can define a set of required fields based on existing practices, a number of good security measures, and a rigid grammar that strikes the balance between human-readable and safe. Additionally, wallets wouldn't have to change their existing interfaces and practices to at least continue to serve users this kind of message.
We can first take all these jumbled 'Sign-In with Ethereum' messages and have an accepted common way of presenting users with the request:
Common Message - Common Interface
With an agreed-upon signing message format, apps and wallets can now speak the same language. As the app presents the user with a signing request, the wallet can then check the request, check if it would fit as an EIP-4361 message, and let the user know that they're signing into a website.
At this point, instead of presenting the user an arbitrary block of text to sign, the wallet can present a friendly stylized interface that feels good and removes any doubt about the action the user is about to take. The user can now just "Sign-In" by clicking a confirmation dialog because the wallet understands the signing request. For full transparency, the specification states that the entire message and fields must still be made available in additional sub-interfaces (such as a detail view).
From the EIP-4361 message, we now get a cleaner interface:
The specification also introduces additional security requirements for wallets, such as domain binding to prevent phishing attacks and nonces to prevent replay attacks, the user is further protected throughout the experience. For example, if the wallet finds a valid SIWE message but the user is signing for example.com but is actually on exampie.com, the wallet can warn the user about the situation:
Beyond Authentication
Sign-In with Ethereum messages can also be interpreted as authorizations to access particular resources, or a delegation to a session key for increased functionality and ease-of-use around dapp UX. For example, imagine a world where instead of an app holding a user's data, a user can instead enrich their session with data they retain? For more on that, we highly recommend checking out the following:
From Sign-In with Ethereum to Session Keys
Session keys let users root all their digital interactions to their keys.
