Updates on EP10 - Community Run Identity Server (November)

Greetings - as always just want to drop in for some SIWE updates!

General Updates

As mentioned in the previous update, we began looking into using the community server for the Auth0 marketplace. Unfortunately, it’s a bit tricky, so we’re still trying to figure out if there are any workarounds to replacing the server currently being used for the workflow without things going awry. However, the community server is still available for any developer to take off the shelf and use for their app or service alongside the existing libraries for those that want direct authentication flows!

Additionally, we’ve now restarted our community calls for Sign-In with Ethereum as Twitter spaces! The first one from last month can be found here, and the latest one featuring some of the folks over from WalletConnect working on some awesome Sign-In with Ethereum related technology can be found here. We hold these towards the beginning of each month and hope you’re able to join us for the next one.

We’ve recently fixed an error on the OIDC IdP affecting setups where users logged in from any network and ran into an issue during the server’s ENS resolution step. The root cause was addressed, and now users coming in from any network can use the OIDC IdP without further hiccups.

Additional development updates and updates on multisig login

We are happy to always announce our continued work on making SIWE easier to integrate, and with that, would love to introduce SSX - which is the easiest way to currently integrate native Sign-In with Ethereum support. We’ve also added native ENS support in SSX, ensuring that any site leveraging Sign-In with Ethereum can easily leverage ENS names users use across the web. Also as part of SSX, we’ve announced that our workflow and collaboration with Gnosis Safe for logging in on behalf of a multisig is now available.

In this workflow, a multisig can delegate login access to an account via a Gnosis Safe app, and when prompted, the user can sign in on behalf of themselves or the multisig. The next item we’re working on is how it translates to different scopes and spaces, specifically in a case where a user is delegated to log in to a particular site or service. This implementation is open-source and free for anyone to use. For more information on this, check out this guide.

If you’re curious about our work with wallets or generally about Sign-In with Ethereum, get in touch! For those looking to build using the community-run OIDC server, please remember to check out the documentation here, and feel free to always ask any questions wherever needed - we’re here for any additional support.

Grants, Community, and Budget

As always, if you have a Sign-In with Ethereum & ENS related project or development work in that direction, please reach out! We would love to support this work wherever possible.

  • Enhancements of existing open-source libraries
  • Additional features on existing plugins
  • New application plugin opportunities to embed Sign-In with Ethereum and ENS
  • Tutorials and builders guides on working with Sign-In with Ethereum and ENS

Anything to further SIWE + ENS is a great service to the ecosystem and we would love to support it wherever possible.

As always - if anyone has any questions, I’m always around to answer them!


Excellent work krew and rocco cheers to the pioneers, one step closer to a safer social recovery wallet system for those whom are plagued by forgetting thier keys! I count myself among them!
This will wake the way for on boarding the future users of crypto for GENERATIONS TO COME. If ens only ever did this one thing it would transform the entire future of crypto in profound ways… no more lost coins no more hacked wallets no more signing malicious contracts unawares… for example
a scammers transaction that possibly will grant access to hijack a users wallet will hit a “fireWall” if the new system is “smart” and can detect it prior BEFORE YOU SIGN A MALICIOUS S.C !! Imagine that a malicious user wishes to steal your $ via a s.c sig…a new a.i trained s.c auditor has detected by a s.c sniffer that the user is granting highly sus access
via xyz in the s.c code and is prompted saying "this s.c is possibly malicious here is the part of the code were sus of do you still want to continue :thinking: with the authorization…