Sign-In with Ethereum - Decentralizing an Identity Provider Server

While digging deeper on Sign-In with Ethereum adoption vectors for Web2, we found that many traditional services wanted to integrate Sign-In with Ethereum. Most already supported OpenID Connect (OIDC) and were open to adding a new Identity Provider (IdP) that supported the workflow. While we encourage everyone to consider and prefer direct authentication where users can just connect a wallet and sign a message (no IdP required), we also had to meet Web2 where it is today.

One of the first steps we've taken toward this is the creation of an open-source OIDC IdP in rust that was information minimizing and could be run with Cloudflare Workers. Additionally, we've created an initial integration into Auth0's marketplace utilizing this infrastructure:

The Path to Decentralization

IdP workflows today require centralized hosting, which at first glance seems counter to the idea of moving towards direct authentication methods without intermediaries. However, the incentives of these intermediaries and users are typically not aligned. We believe that there's a way that we can have a credibly-neutral IdP, hosted by a values-aligned organizational structure such as a DAO.

Decentralization operations on a sliding scale - we think there’s a middle ground that would work as a stepping stone towards it. One of the core questions we needed to ask throughout this process was - how do we decentralize the underlying infrastructure?

As previously mentioned, the IdP is implemented to run with Cloudflare Workers, so it can run with minimal IT operations overhead, requiring only a Cloudflare account and no server provisioning. Cloudflare’s platform also allows for different grades of account access, allowing an entity to own the account with third parties performing maintenance or auditing deployments. The IdP server can also be run as a binary executable, which eliminates any fears of lock-in as well.

This level of access control and transparency enables a core base for credible neutrality. The proposed infrastructure is open-ended enough to enable third parties to obtain limited maintenance and viewing privileges if approved by the community. Additionally, this gives any onlookers transparency on the implementation, active deployments, and demonstrable adherence to data retention policies.

A Proposal for a Community Run SIWE IdP

We believed that the ENS DAO would be the best credibly-neutral organization to be the host of this infrastructure. A community subgroup could be created in order to maintain the authorizations and access to the server, and contract one or multiple entities to maintain it. Additionally, ENS and its community would benefit from increased adoption of Sign-In with Ethereum due to the enablement of organizations to use ENS as a core touchpoint for a user’s basic identity and information (via ENS profiles).

After doing an initial temperature check with the DAO, the full proposal was represented as [EP10] which outlined the following:

• A subgroup in the ENS Ecosystem Working Group is to be established in order to provide onboarding materials, training, and pay for the administration and maintenance of the server.
• A budget for retroactive rewards related to the Subgroup, for any development and evangelism efforts around Sign-In with Ethereum.

As part of the administration and maintenance of the server, Spruce would serve as a contractor in this role. If the DAO votes to end the contract, funding will be returned against the remaining days of the year and there would be sufficient training for administrators to transfer those duties to a new organization.

After passing an initial off-chain vote on Snapshot, the vote moved to Tally for a final on-chain decision, which succeeded as of block 14484613.

The Next Steps For Us

In the next 60 days, we anticipate having the first version of the server ready and the subgroup established. The included work involves:

• Reporting on the current architecture of the OIDC IdP hosted on Auth0, and how it can be migrated over to the new setup.
• Setting up the new OIDC IdP on a managed account, and ensuring that the deployment goes smoothly.
• Fully outlining what Cloudflare offers in terms of managed access to the setup, and options on how a multi-administrator configuration could work.
• Form the Community-Managed IdP subgroup under the Ecosystem Working Group, and work on the initial onboarding and maintenance materials.
• Outline and propose a process that will determine eligibility for retroactive grants, and how that budget is spent.

Alongside this, we will still be working on ensuring Sign-In with Ethereum has broad support across languages, frameworks, and plugins. The work doesn't stop here - and will never stop until every service offers users the chance to retain control over their identifiers.

If you're interested in integrating Sign-In with Ethereum into your dapp, app, or service, we are more than happy to help and provide any support we can. As we continue our work supporting 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 us.

If you are interested in being involved, please join our Discord server: