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:
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).
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.
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.
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.
siwe-oidc implementation already passes relevant tests in the OpenID Certification program, and the formal certification process will be initiated shortly.
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.
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).
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.