Hi @accessor.eth if you prefer video recordings of the discussions, you can find them on https://login.xyz/. Please let me know if you have specific questions about the design–we touch on all the concerns you bring up within those public community calls that happened over months, and if you still have some questions after that feel free to start a new thread. You are also free to review the implementation here to see how information minimizing it is compared to other IdPs. I would like to focus this thread on the proposal discussion at hand and not derail things by revisiting technical design decisions that were considered nearly a year ago in the RFP. Your interest is much appreciated, and there is indeed a lot of background across the prior community discussions.
This is now open for voting on Snapshot.
I would like clarification on the “retroactive rewards” part of this $75,000 earmark before I vote, please. I didn’t see a clear answer so far as to who would receive how much of this as a “reward,” and why, and/or for which SIWE-related efforts?
Thank you.
There are no answers for the questions you are asking imo. The beauty of retroactive rewards is that people have to do work that creates value, then funds can be directed to them. This isn’t an instance of specifying ahead of time the form that such value creation will take.
For the DAO to have a level of comfort over the fact that those funds will be allocated appropriately, the funds will stay in the community IDP subgroup multisig. Requests for distributions will be communicated through the governance forum. Distributions will need to be approved by a majority of Ecosystem stewards before they are paid out.
Excellent, thank you. I just wanted to know that there would be some type of discretion since it wasn’t really specified. $75,000 is a lot of money, but it’s good to know it will be in a multisig and will need approval before payments are made.
I had quite a few questions about this proposal and when I went through the thread I saw that @royalfork essentially covered almost all of them. So thanks for that!
I can now vote for this proposal as I find it would be useful for adaption of ENS.
I have some worst-case-scenario questions which will probably be relevant in some time once the subgroup starts to form around the IdP “server”. In any case, I’ll leave them here to ponder:
Any reflections or preemptive thoughts on threats from possible compromise of the IdP server? After all, it is still a centralised service and there are no active controls to gauge if/when the server is compromised. There will definitely be a time lag by the time a hack is detected and the service is shutdown. During the course of the hack, phishing identities could be routed through the IdP server, likely with a plethora of consequences. Is there an estimate of the attack surface and/or proactive damage assessment in such a scenario?
[compromise == unauthorised root access by a bad actor due to unspecified lapse in opsec]
Good. Server live in 60 days. Coming together.
Sorry for coming in so late to this discussion but I’d nonetheless like to express some concerns:
-
This feels a little like a Trojan horse. Yes, this will make it easier for existing services to accept web3 login. But on the other hand, this nullifies decentralization. For a start, it encourages a single point of failure by which all accounts using the login service can be compromised on all sites. And just as importantly, this is a point of censorship whereby users can be excluded. And this second point is apparently not just theoretical since to my great annoyance, I have already been completely unable to connect to the example login page provided further up by @wayne (https://oidc.login.xyz/) using Tor (probably due to cloudflare).
Although Tor and VPNs being blocked as a side-effect of DOS-mitigating measures are not my only concern. Governments around the world have, especially in recent times, become quite happy to impose “sanctions” which extend to speech. See the EU recently imposing a ban on publishing anything coming from RT for instance. Or maybe the service is based in the US which truly guarantees the right to free speech. But then you would have to contend with secret court orders to permit access to individuals’ accounts, which you could neither disclose nor refuse to comply with. This last part is in my opinion enough to reject this proposal altogether. -
How hard is it really for websites to implement native web3 authentication? Wouldn’t the money be better spent supporting the development of web3 auth plugins and adding web3 support to open source software?
-
Not so much a criticism of the service being proposed, but of how it has been handled. I feel like there has not been enough (any?) negotiations around pricing. And in order to properly negotiate pricing, I think the negotiations should be required to be held with representatives of the ENS DAO before any price is published. The negotiations could be held privately but I think records should be published once concluded. My current impression is that the price could have been negotiated down and has not been fully justified, but I won’t claim to be an expert in the matter of pricing such services.
So what advantage is left to providing this service? We (or at least those not using Tor) will be able to log in to some websites using our web3 identifiers and flaunt our ENS addresses.
But on the flip side, this might delay actual web3 auth adoption, the US government will be able to spy on the activities of anyone in the world using this authentication method, even if the targeted website is outside US jurisdiction, those who care enough about privacy to use Tor get screwed over as usual, and we could be spending all this money on encouraging and developing for direct web3 auth adoption.
As such, it is my opinion that the costs outweigh the benefits and I will be voting against this proposal.
OAuth is widely used for federated authentication all over the web. The SIWE team have already developed an OAuth provider that anyone can host in order to add SIWE support to their application in a decentralised fashion; this proposal is simply to host an instance as a “public good” that anyone can use in order to further reduce the overhead of adding SIWE support to a legacy app. In that context it makes sense that it be hosted by as impartial a group as possible. If it’s found to be malicious or unreliable, providers can migrate over to another service or to their own hosted version without affecting existing users’ account.
@mizu thanks for sharing your thoughts here. In general, I think your point of view admirably espouses perfection and complete decentralization, but at the risk of progress. If you oppose all forms of centralization, then there are quite a lot of things you should take issue with today.
Someone will eventually submit this to the Auth0 marketplace, and would you rather that IdP be governed by the community or a private company? By moving first, I think we can guarantee that it’s community-hosted. This code is open source and can be re-homed to a different host at will by the community, supporting Tor or Onion can be added as a requirement if the WG decides to.
We have implemented support for Discourse, Rails, a plethora of languages, and have other platform support on the way. It’s really hard, and easy to underestimate. Most systems are implemented with the assumption of email in mind, and you don’t even get that with direct key-based authentication. WebAuthn has been around since 2016 and still it is not the way we log in today because these assumptions break a lot of popular software. This is simply another option for people who prefer it. Why not pursue options at once? That’s already what’s happening.
You are free to go through the proposal process like the rest of us to suggest how this would work to the DAO. We proposed pricing that would probably not even cover our costs in good faith, so I hope you can understand how it might be a bit insulting that you are assuming that “the price could have been negotiated down” without reading the discussion above. If negotiations become part of the DAO’s process, then we will abide.
In short, I invite you to participate in the Subgroup if/when it becomes active, and would look forward to continuing these discussions in full then. The Sign-In with Ethereum calls (login.xyz) are another place to engage in discussion in real time. Thanks again for your comments.
This proposal has passed on Snapshot.
EP10 is an Executable Proposal and is now awaiting an onchain vote, which will take place in the coming days.
Follow ENS_DAO on Twitter to stay up to date with proposal announcements.
This is now up for vote here in combination with EP8 and EP9.
Please vote against this proposal onchain; there is an issue with the deployment of the pricing oracle for EP9. A new vote will be submitted shortly.
Details here: [EP9][Executable] Change to Exponential Premium Price Oracle - #12 by alisha.eth
The updated vote is now live here.
That’s certainly a good point.
I wasn’t very clear, but I simply meant to point out what seemed to me like a deficiency in the DAO’s process when reviewing costly integration proposals and did not mean to blame your team which acted totally within reason in submitting this proposal.
Overall, I’m still not fully convinced that this initiative will be a net benefit but since it’s been voted, I wish it the all the best. Speaking of which, what would it take to make it Tor-friendly? Or now that I think of it, is it possible that I was mistaken and that nothing is supposed to happen after signing the “oidc.login.xyz wants you to sign in with your Ethereum account” message? If so, I apologize, but I would also recommend providing an example where successful login is confirmed in some way.
As you mentioned, the oidc site is related to services using it (going to it alone won’t have a flow). For something a bit more complete, https://login.xyz has a basic direct authentication example that shows a session and saves a poll result to demonstrate it.
Aha. I missed that on the main page the first time, and I’m pleased to say it does work with Tor.
This has now been executed.
Is the community server on road to being implemented (i.e. come online) within 60 days of the proposal being executed? 60 days pass on June 2.