Sign-in With Ethereum - Proposed Workflows

The initial goal for the Sign-in With Ethereum efforts is to create a specification and reference implementation for an end-to-end authentication flow for Ethereum accounts to log in to traditional Web2 services, using ENS as a primary user-controlled data aggregator.

This will allow Ethereum users to provide their own digital identity based on their keys instead of using a centralized identity provider such as Google, Facebook, or Amazon. We will further specify and implement how relying parties can retrieve and verify claims about the user’s identity, such as email accounts, phone numbers, and social media accounts, in a privacy-preserving manner.

Today, when users log into websites, they choose between several large Internet companies that serve as identity providers (IdPs) for their digital identities. The OAuth 2.0 and OpenID Connect authors originally intended to spawn an entire ecosystem of IdPs for users to choose from, not just a few consolidated entities. These large IdPs control users’ identifiers by making authentication simple for end-user and developers alike, which means they also control access to (and give IdPs privileged visibility into) critical services including banking, payments, and social networks. The intermediary structure restricts direct access to online services in much the same way that centralized banks restrict direct access to financial markets.

With the growing adoption of Ethereum-compatible wallets, such as MetaMask sporting over 5 million monthly active users, there is a new opportunity to provide a direct form of authentication to Web2 services using message-signing and claims aggregation directly from a user’s Web3 wallet and ENS, rather than a traditional intermediary.

These claims can be used not only for the sign-in process but also can turn existing Web2 accounts into an opportunity for crypto adoption more generally.

With Sign-in With Ethereum, users will be able to:

• Sign in with their Ethereum wallet supporting WalletConnect to a Web2 service that has installed the Sign-in With Ethereum Server SDK.
• Understand what information the Web2 service needs to verify and from which sources to complete the sign-in process.
• Select which claims to present to the server from within the Sign-in with Ethereum Client SDK, so that the server can retrieve and verify the information from a variety of sources including Ethereum Name Service (ENS), Interplanetary File System (IPFS), HTTPS, and more.
• Use encrypted and authorization-required claims (note: this will likely be broken out from core library and specification in extension specifications).

While Web2 service hosts will be able to:

• Integrate the Sign-in with Ethereum Server SDK or specification into popular web frameworks and authorization libraries to support Sign-in with Ethereum, either directly or through an authentication method aggregator such as Auth0 or Passport.js.
• Specify Sign-in with Ethereum requirements. As part of the sign-in process, services can retrieve and verify claims presented by the user and/or aggregated by ENS, such as Web3 account balances, NFT ownership, W3C Verifiable Credentials, and more.
• Link Web2 accounts to Ethereum addresses. Services can retrieve and verify claims presented by the user and/or ENS to augment their Web2 accounts with new functionality, such as special portals or downloads for NFT owners only, private off-chain admin panels for DAO members, or other determinations made from on-chain data or off-chain signed Credentials.
• Integrate the Sign-in with Ethereum workflow to an existing OAuth 2.0/OpenID Connect relying party using configuration only. This workflow relies on a trusted Identity Provider, which supports the Sign-in With Ethereum authentication method and is able to establish an OAuth 2.0/OpenID Connect session.

In terms of how the workflow would look, the relying party would first present login requirements to the user, including which claims from ENS are required for different authentication types, a nonce to prevent replay, and a unique site identifier. In this case, ENS domain ownership can serve as a basic anti-sybil mechanism.

The user then performs an Ethereum-based authentication via WalletConnect signing, which is sent to the relying party. This step will use a data schema supporting user selection of relevant claims, allowing for a user to stipulate which claims should be queried by the relying party, (i.e. selected facts about their account that should be used to establish the session). These facts are retrieved through ENS as TXT records by value or by reference (i.e., URL).

Relying parties then use a claims-querying method to retrieve and verify the relevant claims for an Ethereum account, such as an ENS address, email verification(s), social media account links or verifications (e.g., through Uniswap Sybil), any other claims that both the user and server support.

The user is then able to enter and interact with the service as they normally would and is able to provide their own digital identity rather than be at the mercy of a centralized identity provider. We believe this will be a great step forward for user-controlled and managed interactions on the web.

A Note on Privacy. We will be initially focused on Web3 users who are already comfortable correlating their Ethereum addresses to their public personas and understand the implications, such as the many people on Twitter who proudly display their NFTs as their profile pictures (PFPs). We believe privacy is about achieving appropriate flows of information, not necessarily absolute confidentiality. As privacy requirements change for different user demographics (e.g., mainstream web users), so must our approach to privacy tools, such as using newly derived Ethereum addresses on a per-interaction basis, or incorporating zero-knowledge techniques to reduce correlation.

As we continue our work on Sign-in with Ethereum, we especially welcome implementers who already have users relying on similar workflows, authors of related EIPs, and wallet vendors who would like to do more to support user-owned identities to join the discussion. If you are interested in being involved, please join our Discord server: