A Credibly-Neutral Sign-In with Ethereum Identity Provider Server

Hey all - this is Rocco from the Spruce team, leading efforts on pushing Sign-In with Ethereum forward. We wanted to bring forward this possible proposal to the ENS community to kick off a discussion around it, and figure out if there’s interest and a path forward for it:

A Credibly-Neutral Identity Provider Server

In our research, we found that many services wanted to integrate the Sign-In with Ethereum (SIWE) workflow but did not have the ability to add new passwordless authentication methods to their installations. However, most already supported OpenID Connect (OIDC) and were open to adding a new Identity Provider (IdP) that supported the SIWE workflow. While we encourage everyone to consider and prefer direct authentication with SIWE, we also have to meet services where they are today.

IdP workflows today require centralized hosting, which at first glance seems counter to the idea of moving towards direct authentication methods without intermediaries. Intermediaries are often problematic because they have agendas that do not always align with their users. We think there’s a middle ground that would work as a stepping stone towards fuller decentralization.

We believe that a community server could be governed by a credibly neutral party that Ethereum users accept as an intermediary. We think a non-profit or DAO are the right structures to help govern such a server, which is why we would like to collaborate with the ENS DAO on hosting and maintenance. This would be the world’s first DAO-hosted, transparent identity server.

The ENS service and 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).

General Points

A Credibly Neutral Identity Provider Server

For traditional companies, an OIDC service reduces management overhead while also mitigating security risks for larger customers that have many services for their users to access within their product ecosystem. We have built an open source Identity Provider (IdP) server in Rust towards this goal as part of our previous work with the Ethereum Foundation and ENS, which began from our proposal acceptance in the open RFP bidding process.

Low maintenance costs and high transparency

The IdP server is implemented to run with Cloudflare Workers, so it can run via a reliable infrastructure provider 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 the ENS entity to own the account with third parties performing maintenance or auditing deployments. Alternatively, the IdP server can also be run as a binary executable, ensuring no lock-in to a specific platform.

This level of access control and transparency allows 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. For example, the DAO could hire a third-party auditor to perform an investigation and write a public report about the live deployment and actual data flows. We want to give the ecosystem transparency on the implementation, active deployments, and demonstrable adherence to data retention policies.

Information minimization

The implementation was made from scratch to be information-minimized, optimized to store as little information as possible. Where possible, it forwards claims data instead of storing them. Logs will be stripped of identifiable information to the fullest extent while remaining viably useful for troubleshooting. If any information is required to be stored, it will have an extremely short shelf life (likely measured in days) depending on the case for debugging or auditing purposes.

OpenID Certification

The current siwe-oidc implementation already passes relevant tests in the OpenID Certification program, and the formal certification process will be initiated shortly.

Migration of Responsibility

We wish to ensure that at any point the current maintainer can in good faith hand over maintenance responsibilities and access to other vendors at the discretion of the community. Other vendors should be able to co-maintain the infrastructure or cutover service provision entirely for the IdP. The administrative privileges would reside with leadership from the ENS DAO, and it would be their decision to perform a vendor migration.

As Spruce, we would be awarded an initial contract to set up and maintain the server. As part of this, Spruce will train anyone involved to understand the proper administration of the account, but Spruce will still conduct technical maintenance duties throughout the process. All of this is to ensure that the selected stewards can see all the possible levers of control that they possess.

Fit Within the ENS Community

ENS has continually proven to be an incredibly effective identity service to the Ethereum community. We wish to continue to work with the ENS community specifically on this next significant milestone for Sign-In with Ethereum.

As part of this, we would like to establish a subgroup in the Ecosystem WG:

Subgroup Name: Community Managed Identity Server

Purpose of Subgroup: This Subgroup will support the administration and maintenance of a DAO-run Identity Server for Sign-In with Ethereum. Additionally, we would specifically also like to establish this subgroup to serve as a great support system to help onboard organizations, and evangelize Sign-In with Ethereum to allow users to control their identifiers and use ENS profiles as a base identity.

I would be happy to serve as the subgroup lead to coordinate between interested parties, adding additional community members to the group for good governance as is appropriate. I welcome anyone else to play a key role here if they’d like to, and are qualified (especially if they have familiarity with digital identity systems).

Asks and Next Steps

We are seeking the following:

  • Administration from representatives of the DAO of the cloud account hosting the Identity Provider Server, with maintenance rights granted to Spruce.
  • $200,000 (a combination of USDC & ENS - possibly 50:50 but open for discussion!) for a 12-month maintenance contract with Spruce for the continuous monitoring, maintaining, and improving of the Identity Server.


  • The server is expected to be live within 60 days of this proposal being accepted, assuming that access to the necessary systems and people is provided on a timely basis. The 1-year contract begins when this proposal is accepted, and there will not be additional setup fees even if there are increased coordination costs to get the service running.
  • If at any time the DAO wishes to end this contract with Spruce, we will return any funding against the remaining days of the year Spruce isn’t working for the DAO, and ensure that there is sufficient training for the administrators to transfer those duties to a new organization.

I want to thank anyone again for reading all of this, and we would love to open the discussion with the community to address any concerns and review this idea. We look forward to any future collaboration.


Thank you for putting this proposal forward. I’m excited to see this starting to come to fruition.

Are you able to expand a little on what the longer-term maintenance costs would be if the DAO continued contracting Spruce to maintain the server? $200k for the first year of the first deployment of a new service looks quite different from $200k per year indefinitely.

Also, who would pay the hosting and bandwith costs - Spruce, or the DAO?


Could this proposal also include hosting a gateway server for CCIP layer 2s?

This is fantastic work! :star_struck: :boom: In the short term, having a DAO-managed OIDC-equivalent for SIWE - or what some may call a bridge to OIDC - is very useful.

Having said that, since the server is binary executable, why not encourage the community to host the nodes on their machines instead of running on a centralised server in the longer run? I am talking about BOINC infrastructure integrated with SIWE/DID. In plain english, the centralised DAO-managed server can eventually be decentralised into BOINC + SIWE/DID hosts who manage the IdP. Have people at Spruce looked into this yet? BOINC has over 200,000 active hosts for SETI@home and Einstein@Home networks and is designed for platform-independent execution.

Genuinely asking, will the community be interested in such an endeavour? All parts of the puzzle exist apart from BOINC-DID integration, which is a “trivial” task since BOINC uses an authentication scheme similar to a hybrid version of OAuth + RSA. @rocco, I am open to a DM if you and/or your team at Spruce happen to look into it. There is room for collaboration for a future decentralised IdP version.


Would/Should the DAO commit to a multi-year contract with a centralised IdP? I am doubtful

$200k for the first year of deployment. We don’t know what it would look like after, and I would consider this an experiment, with a mandatory community reevaluation at certain junctures. With this budget, we’d be able to make quick responses, iterate on the codebase, and provide reasonable SLA to the community.

For the hosting and bandwidth costs, this depends on the usage, but we think this number should have room to absorb up to $10k of the hosting costs. If it goes past that, we may need to have another discussion.


Potentially! We want to keep it out of scope for now, but if the DAO can run infrastructure in an incentive-compatible way with the community, I would love to see more applications take root here instead of consolidating validation and data availability activities on a few centralized entities.

Thanks for your kind words here! Indeed, I don’t think we should ask the DAO to commit to a multi-year contract until we figure out how the first year plays out. I think we are excited for the SIOPv2 specification and would want to add support as it reaches maturity, in a way compatible with SIWE.

As per your question, could a distributed host model work for IdPs? That’s a great question and something we’d be able to explore further as it relates to the SIWE evolution. We’ll reach out over DM! Let’s minimize trust however we can.


I do not think there is any way to do this securely (eg, in a manner that the individual service providers can’t cheat). Sites have to trust the OAuth IDP to accurately respond to authentication requests.

Ideally, eash site would host their own IDP, but the purpose of this service will be to make it very easy for anyone to add SIWE support to their existing platform without having to do that.

The proposal is for a single year, with the DAO able to cancel it pro-rata at any point.


There are absolutely many ways to do it securely. Einstein@Home and SETI@Home both have their own validation schemes such as consensus checks and so on. It is misconception to think that it cannot be done securely, but yes, it will need an L2 secure layer customised to the needs of ENS. You could even nominate DAO-elected validators to run N ~ 100-1000 number of nodes to reduce a lot of overhead as well. I am proposing a scenario where the DAO votes to adopt either a fully-decentralised network, or a validator scheme, or a fully centralised setup - in the long term. I am keen to hear from Spruce team in any case, and I’ll explore it in person as well. I like this a lot

1 Like

this seems to me a push in the right direction. i worry it will slow progress ultimately, but maybe less progress without it. and meeting them where they are makes sense to me, so im for this.

1 Like

These systems rely on random sampling, which is all very well if the consequence of discovering misbehaviour is throwing away a few work units, but an entirely different proposition if it means someone can impersonate other people for an unknown period of time.

Yes, correct. Currently, they run only bi- or tri-factor random sampling which is far from ideal for authentication systems. This is exactly what separates them in architecture from blockchains or DAGs. However, there are simple consensus layers that can solve this issue as you can probably guess. I didn’t mean to imply that the current architecture of BOINC can be ported out of the box; there will have to be some work done for it to be compatible with our needs. I guess only a small working example will convince you :stuck_out_tongue:

Blockchains: Synchronised Hosting + Global Consensus
BOINC: Unsynchronised Hosting/Processing + Minimal Consensus Check
My proposal (dIdP): Unsynchronised Hosting + Sufficient Consensus

It is somewhere halfway between the two extremes within distributed systems that are blockchains and BOINC.

My point is more that there’s no way to do this safely with random sampling, and I’m not aware of another way to do it.

1 Like

I will bring unto thou thee a new way that doesn’t use random sampling :slightly_smiling_face:

1 Like

Please note this proposal progressed to Draft Proposal 5 days ago. View the post here.