In our research, we found that many services wanted to integrate the Sign-In with Ethereum workflow but did not have the ability to add new passwordless authentication methods to their installations.
We also learned that most services already support OpenID Connect, and were open to adding a new Identity Provider that supported the SIWE workflow. By meeting those services where they are today, we can provide a pragmatic stepping stone towards true decentralization, with an upgrade path to direct authentication.
To ensure adherence to the vision, it’s critical that we collaborate with the ENS DAO on hosting and maintenance of this identity server, ensuring the identity server’s governance ultimately resides with the community, whom we believe will always put users first. This would be the world’s first DAO-hosted, transparent identity server.
Rationale
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).
Additionally, 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.
Specification and Proposal Request
Establish a Subgroup in the Ecosystem Working Group: Community Managed Identity Server
$250,000 allocated from the DAO to the Ecosystem WG to fund this Subgroup.
$75,000 from the allocated budget will be in place for community contributions related to the Subgroup, including grants for development, evangelism, and retroactive rewards for SIWE-related efforts.
$175,000 from the allocated budget will go towards Spruce’s maintenance contract (see below). Paid 25% upon execution, and then an additional 25% every 3 months.
This Subgroup will support the administration and maintenance of a DAO-run Identity Server for Sign-In with Ethereum. This subgroup will also serve as a 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.
An important part of duties this group will include creating training, onboarding, and maintenance materials for managing the server on a specified cloud account.
Additionally, the group will be responsible for providing updates to the broader community on the health of the server.
Initial lead: Rocco from Spruce, while continuing to add interested parties to the group for good governance.
A 12-month maintenance contract awarded to Spruce for the continuous monitoring, maintaining, and improving of the deployed Identity Server.
Spruce will help host a siwe-oidc implementation in a lightweight fashion, using a well-known infrastructure provider ultimately administered by the Subgroup.
Spruce will also be responsible for the deployment, and continuous monitoring, maintenance, and improvements on the server throughout the duration of the contract.
If the DAO votes to end the contract funding will be returned against the remaining days of the year and we will provide sufficient training for administrators to transfer those duties to a new organization.
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.
I agree with this, and think it’s important that ENS DAO financially support ENS-focused SIWE tools (either through this proposal, or otherwise).
Would you be willing to share this research with us?
How many services, and in what industries?
Approximately how many users use those services?
What other sign in mechanisms do those services currently use?
Do you have any specific retroactive rewards in mind?
What role does Spruce have in recruiting new services to adopt OIDC/SIWE? Or would the bulk of that work fall on ENS?
What does the current development roadmap look like for siwe-oidc? Which parts of the OIDC protocol will be built next?
Can you provide any performance metrics (requests/s, logins/s)?
The “Temp Check” thread included a $10k server budget. How was this number reached?
Does the “cloudflare worker” deployment also require a redis cluster? (if not, how is global state stored and accessed?)
How many human work hours (either dev work, ops work, management, etc) would this include?
Could you be more specific on the concrete deliverables you’re willing to commit to during the 12 month contract?
Does Spruce provide an SLA?
Does this include on-call support?
Some additional questions:
Are there any branding guidelines/regulations on client login pages? Would Spruce/ENS branding be a part of the user login experience?
Are you aware of any other OIDC/SIWE deployments (either currently live, or in the works)? Or will ENS provide the only one?
Will running this server open up ENS to any GDPR/CCPA/other regulatory requirements?
Are you able to discuss details of Sign-in with Ethereum RFP - HackMD? Has the engagement concluded successfully?
Spruce appears to be a VC backed, “for profit” company. What’s the business model? Would Spruce be making or losing money on this contract? (In other words, would Spruce be operating this contract at a loss, or is it priced to add bottom line income?)
Thanks for putting together this proposal. Look forward to seeing how it progresses.
Hi @royalfork, thanks so much for your review and questions. It’s exciting you took time to read through the proposal and are helping to figure out how it could work for the community.
You can see services we’ve been talking to on https://login.xyz. With respect to services that specifically need an IdP, we are focused on providing support for projects and products that can serve as distribution channels like the Auth0 marketplace, Passport.js, etc.
Through the distribution channels, there are countless services across many industries. For example, Auth0 has over 35k customers across a diverse set of industries, and there are likely to be installations in the thousands for the other projects.
Based on the above, millions, but I’m not sure anyone has the exact numbers here as much of those data are likely proprietary.
Google, Facebook, Username/Password, other forms of social auth namely.
Not particularly, we hope to add more members to the subcommittee to determine this in fairness. There were some community implementations of SIWE, contributions to the spec, and other supporters who we think should definitely be considered. We would prefer to focus on code contributions, security reviews, and adoption levers as a starting point.
We actively engage in outreach, education, and a reasonable amount of free support for adopters. We consider this under the scope of the grant, and also the renewal is likely contingent on how useful OIDC/SIWE is to the world–so we have incentive to push it in the right direction.
This really depends on community feedback–we’re pretty against building features unless we do the proper user research first, and ask the kinds of questions you’re asking now. We hope that people who use or will consider using the IdP will be vocal about their concerns on the ENS forums, and we will encourage them to do so. Intuitively, we should probably implement additional OIDC claims that allow for resolution of ENS data (such as the entire profile) from the IdP, and also potentially forwarding the original signing request to provide an upgrade path towards direct authentication.
We believe the serverless architecture should have no issue handling horizontally scaled infrastructure to handle oncoming traffic. This, along with ease of maintenance, was one of the key reasons we chose Cloudflare Workers for a targeted deployment platform. This means there’s no server infrastructure to maintain with the benefits of scalability. We haven’t done the performance tests, but we can provide results of conformance to the relevant OIDC certification tests (see the repo), and some napkin math would have me believe we can serve thousands of requests per second. This is also an experiment, so definitely one of the measurements we will want to track.
$10k is about the cost of an enterprise Cloudflare plan, as far as we can tell (it’s call-in pricing). We may need to add additional controls to the account, and those may only come with the enterprise package, but could perhaps get away with their Business plan too. This is likely to cover the traffic served, and if it’s a lot more adopted than expected, we have trust with the DAO that we can revisit this. Maybe Cloudflare would even cut the DAO a break!
On Cloudflare Workers, we would use either or both KV store and Durable Objects to preclude the hosting of a Redis database, keeping the cloud governance simple as well.
Unfortunately this is hard to answer exactly right now. I think there would be 1 FTE equivalent split across ops (55%?), dev (25%?), and management (20%?). Not part of this, because it is hard to measure, we will contribute active community involvement across our team with respect to the identity server (training, outreach, technical explanations, etc.) even if they’re not assigned to this particular contract. Writing regular updates and being highly engaged with the community is a priority for us. I think there is as much justification for firing us for being bad communicators as there is for firing us for being bad technologists.
Fixes for reported bugs, vulnerability patching, and code improvements, including review and commenting on reasonable community merge requests.
On-call support for technical issues, outages, and community questions. We will target a 2 day business response on all community requests, but will likely be shorter in practice.
Involvement in discussions and community responses with respect to technical architecture, resourcing, and data regulation as it relates to the identity server.
SLA, explained below.
Yes. We need to figure out what this ultimately means for an IdP, and looking at the existing ones there are no great guidelines. People have horrible experiences with large tech giants who have not scaled their customer support efforts as effectively as their server infrastructure. While we cannot promise on this budget Amazon.com-level support agents, we can promise target uptimes (90-95%, given this is a pilot? We do not want to be chasing 9s right now when it’s still an experiment, though this could change).
Yes.
We haven’t thought of this extensively, and I think it would be a subcommittee decision. I think we should include ENS branding to indicate the contribution from the DAO to make this possible, and especially as IdP evolves to serve ENS data as claim types on top of the identity tokens. For Spruce, we think it could benefit users to let them know which vendor is currently maintaining the service and further providing a means for them to contact us directly if they have any questions not covered in the DAO forums or docs.
We have one live here, but would like to transfer it to live under ENS. We’re aware that Auth0 Labs has an experiment going too!
In our implementation, we engage in aggressive information minimization, erasing just about all information shortly after they are no longer necessary. We will continue to maintain this to mitigate compliance risks, so we do not think these requirements will be difficult to comply with at all. As part of our responsibilities, we will be active in these discussions as they arise. You can see the Terms of Service and Privacy Policy at the live demo for a starting point on how we approach these issues, and welcome the community to use them as a starting point. We engaged professional counsel at our own cost to produce the first turns of these documents, and feel comfortable enough with them as an organization.
Yes, it was completed in full and accepted by the Ethereum Foundation and ENS.
Yes, this is true. This is also why we think Spruce is not the right entity to host this community identity server, and we hope to keep the governance transparent with the community, under the Ecosystem WG as a subcommittee as proposed here.
Our business model is to sell complementary goods and services that assume a world where users can control their digital interactions directly using their keys instead of through a central intermediary. SIWE’s success is therefore aligned with ours, so we want to see it succeed, even if it’s at cost to us.
In so far as margins, I frankly don’t know where this hits our bottom line exactly, but the best case will be breaking even in my estimates. While we want it to exist, we don’t want to set a DAO funding precedence to exclude vendors who don’t enjoy the same level resourcing as Spruce, so we picked a number that we felt could possibly break even, on the stingier side even. It’s not an apples-to-apples comparison by any means, but for very rough reference, this state government IAM contract totals to around ~$700k for the first year of doing something rote, whilst we’re doing something totally new and unexplored for far cheaper at $250k, with $75k (30%) of that total budget already allocated for additional community participation.
Thanks so much for your comments, they were really thoughtful and put the community first. I hope the answers are satisfactory, but please let me know if I can add more details or answer new ones! I really appreciate your consideration.
Is the dev/integration work for these distribution channels done by Spruce? Or is that something the DAO WG would need to manage?
By “grant”, are you referring to the $75k budget item?
Without strong outreach/support (mostly to sign up new services), it’s hard to imagine how OIDC/SIWE would gain adoption. Just so we’re clear, is this outreach/support work ultimately led by the proposed “Community Managed Identity Server” ENS DAO working group, chaired by Rocco? Or will Spruce internally take the lead on this, only working with the DAO WG when appropriate?
My understanding is that the serverless deployment provides a “set and forget” installation, with very little ops overhead after the initial (simple) setup. But you’re saying ops would take roughly 1/2 a year of FTE work? What am I missing?
If this is a big part of the effort on Spruce’s side, it might make sense renaming “maintenance contract” to something which more accurately describes the scope of the work.
Lol, I don’t think anyone here wants to emulate the government procurement process. In my experience, $175k/yr is well within the normal range of similar “enterprise priced” software maintenance contracts.
Spruce will continue doing the dev/integration work, but of course the community is welcome to contribute as well. For example, we have already gone through the process of the Auth0 submission, and will cutover to the community-hosted edition should this proposal move forward.
No, the $75k should go to other non-Spruce community members to encourage diverse participation and the building of a real collaborative effort.
The subcommittee will be accountable for driving the effort forward, but I believe Spruce will assume much of the responsibility of outreach/support work as we have already been doing. There is nothing stopping any other groups to pursue outreach/support work as well, and we would encourage this. Rocco/Spruce may not be the only chair here, and we also expect there to be plenty of collaboration with the DAO WG as a result. We are indeed looking to add members to the subcommittee–please let us know us know if you would recommend anyone for this.
I’m also hoping it’ll be a “set and forget” installation, but we won’t know for sure until we start it up. I bet a lot of companies go into serverless deployments hoping that’s the outcome, but accepting risks that it’s not. We still need to set up policies, procedures, pagerduty, monitoring systems, etc. for when things don’t go right. The ops expense covers on-call availability as mentioned in our answer on the SLA above, which unfortunately, like a vigilant fire department with trucks and staff at the ready, isn’t sustainable for us on a pay-per-call basis. If the ops workload is especially light, we will likely focus the resourcing into dev efforts in good faith, but we’re not interested in splitting hairs on this right now, to your point about not emulating a government procurement process. Trust from the community helps this process a lot, and we would do our best to safeguard any of it extended to Spruce.
That’s a good point, I’ll ask @rocco to edit the OP and include this more clearly. Thank you!
Really appreciate you explaining your reasoning. I think it’s important for the community to understand incentives when working with individuals or entities. To be extra clear, Sign-In with Ethereum (EIP-4361) is a Creative Commons (CC) licensed work and will be free for the community forever, meaning no one can charge any fees for sign-in requests through commercial licensing. Further, the open source libraries, OIDC server source code included, are free to fork and iterate upon, dual-licensed as Apache 2.0 and MIT.
We believe that all further product and network usage opportunities will be around what user-controlled actions that happen after users Sign-In with Ethereum, such as resolving ENS profiles, managing public metadata layers, accessing private storage, and much more–but ultimately it’s up to the user and applications what they want to use after. All this is only possible with the success of SIWE.
Completely agreed! If anything, we have an opportunity to reinvent the procurement process to actually work to benefit the communities footing the bill. Thanks for adding your insights here, looking forward to continuing the conversation.
Thanks again for the replies. This all sounds reasonable to me.
A couple additional thoughts:
Like you said, this is an experiment. Do you have any ideas on success/failure criteria to decide whether we should continue investment into this IdP effort after, say, 6 months?
Would it make sense to broaden the scope of the Ecosystem subgroup from “Community Managed Identity Server” to “Sign in with Ethereum”?
Should we try and find launch partners before public release?
I don’t know if @nick would want to operate this from within TNL, but I’d volunteer to help with any ops work required from the DAO side (I have software eng background, never used Cloudflare workers before, but have played around with AWS Lambda and have moderate experience with devops for internet-facing app servers).
The Community Managed Identity Server and Sign In with Ethereum are two distinct subgroups within the ENS Ecosystem subgroup. While the projects are related, it is in the best interests of the DAO to keep them separate to more efficiently manage funding requests and for clarity when onboarding contributors beyond the Spruce team.
This isn’t a TNL project. It has been proposed by the Spruce team and will be maintained by them for the duration stated in the proposal (12 months), if the proposal is approved.
We can agree that the hosting costs are covered up to $10k from the $175k budget to make things simpler, and if it seems that we will run over the limit, we can let the DAO know as far in advance as possible.
The scope of identity is limited to establishing sessions using Ethereum address-based identifiers and any public on-chain transaction data associated.
Why would it? Also, no. SIWE is a sessions-based workflow and Spruce is offering a standardised Identity Protocol on top of it for sessions management. You will need to dig a bit into OAuth and OIDC to get this. I had to many moons ago. It is very similar to Connect Wallet but with added authorities. Consider it a fancy Connect Wallet. So you will sign a message to authenticate but never share any sensitive information
In that case, we can jump right into it. The correspondence with OAuth2 is that in SIWE workflow your DID becomes your username and private key becomes your password. But the authentication part happens on the front-end which passes a token that can be used to access a standard OpenID Connect-like IdP protocol which provides the basic user-profile data. Spruce is offering to manage the IdP server on behalf of ENS DAO. At no point, no exchange of private keys takes place since the authentication happens on the front-end and the back-end only manages the token. I guess this has certain implications on how the sessions are managed and this is where Spruce comes in. Really looking forward to this honestly
No but really though, it kinda just looks like we would be putting a web2 service inside of a web3 container. Where is the sign in with ethereum come to play?
What I see is two authentication paths . One path being passed to the web3 provider/dApp and then another authentication cookie pointed towards the OIDC and then a JWT.
So the successful authentication of the web3 container (wrapping the web 2 service) towards the web3 provider/daapp (which gives your wallet access via your browser) then > authorizes the OIDC authentication cookie packet to be sent through OAuth via whatever Auth0 tools chosen to verify the authentication for access to provide the “settings” or other data needed in that correlates with the original dapp/web3 provider.
Why expose data with an JWT going back and forth when we could be issued a one time permanent token or a token that needs to be renewed but kept directly in the wallet; that stores data, and that would otherwise be transacted back and forth
The rationale they provided in their previous proposal that has been amended is that many web2 services would like to integrate SIWE in their workflow but they lack the infrastructure to deal with a JWT; they are however more than happy to integrate a new identity provider that bridges SIWE to their usual OAuth2 framework. This IdP layer is to onboard those web2 services into web3 easily, and then eventually remove the IdP layer and turn them into full web3 degens. It’s like a sneak attack on web2
That’s what I thought at first…but funny that you happen to mention sneak attack–cause that’s how it appears from my perspective–just the opposite. call me naive, but at least my eyes are open. Essentially ENS is the magnet at the small end of a cone while the rest of the cone contains the www and retains control by proxy. oof. ieee, icann and w3c are going to have their hands full. Im exhausted, I’ve been up reading about this all night, refreshing and piecing this together as well as brainstorming other ideads.