---
# System prepended metadata

title: 'Sign in With Ethereum Community Call #8'

---

# Sign in With Ethereum Community Call #8
### Date: 2021/12/16
### Agenda:

- [General] Reader Notes & Updates
- [General] Introductions 
- [Show & Tell] SIWE Updates
- [Show & Tell] Roadmap Updates
- [General] Q&A

## Reader Notes & Updates
- SIWE library is out and can be found [here](https://github.com/spruceid/siwe).
- The [Discord](http://discord.gg/WjvuYqvm5Y) server is always open for questions and those that wish to participate.
- We're working on support for different languages and plugins, please reach out if you're interested in a SIWE integration.

## Introductions
- [Ulises G] - Looking to integrate SIWE. With a team and working on communications and decentralization. I'm a developer.
- [Michael Haley] - Product person working on Tally. Getting into the loop and spent the last three years in Bitcoin.
- [Arvil Nagpal] - Worked at Okta previously. Been following along and interested in understanding what may happen in IAM especially with respect to SIWE. 
- [Afri S] - From Berlin, just read about login.xyz, and really excited. I'm currently working at Chainsafe, and maintain a couple of libraries in Ruby and one of the things i've been working on is login with Ruby on Rails. I'm also maintaining some of the Ethereum gems in the Ruby ecosystem. 
    - [Wayne] - Would love to figure out collaborations.
## SIWE Updates
- [Wayne] - We have a demo talking about Open ID Connect Support and first I'll go through the blog post about recent updates. 
    - What's actively in progress is support for additional languages. We're also working on Ruby (rails and sinatra), working on Rust for security-oriented use-cases, Python, Java, C#, and also Elixir. 
    - One of the finer points of integrating with existing applications is sometimes they expect an email. So how do you reconcile this? You would have to make the determination on an ad-hoc basis. In this case you would make a new column for an ethereum address and a column with a boolean to see if someone's verified or not. 
    - We've shipped the first version of the OIDC server, and we'll have a demo of that shortly. We tried to make it as stateless as possible. Why OIDC? Many relying parties or folks that allow you to sign in with Google support OIDC. For people that want to configure their existing software, this would be possible.
    - One thing we need to decide as a community is where the server lives. It would likely need to be neutral. You can be credibly neutral and have users trust it. We prefer direct approaches but need to make sure we cover options for every level. 
- [Brantly] - We were trying to think about this and approached the Ethereum Foundation. Another option is the non-profit that the ENS core team uses. That may be a neutral thing, but I'm curious - do people have other ideas on how we could run something like this? 
- [Wayne] - and that's really interesting because it's who would service or run the thing. I think we can imagine a world where we hire an auditor that we all trust to check the integrity of the service. Nobody has tried this at-scale, but how do we create a community owned-server that resides with a central entity like AWS, Azure, or other cloud providers.
- [Brantly] - This is important to me and I would love to do something sooner rather than later. 
- [Wayne] - Maybe a good next step is to make a proposal to ENS to see if there's interest in governing or hosting this IdP. 
- [Greg from Rivet] - It's probably more of a matter of how it's executed rather than who executes it. I don't have any specific objections to the groups, but how transparent it's done is the key. 
- [Wanye] - Centralized exchanges back in the day would have a credible auditor to evaluate their cold-storage sources. We need an IdP sooner and we're working on the Auth0 marketplace integration which requires this. They assume you have a third-party IdP that you can redirect or request. These are some decisions that we need to make as an ecosystem.

[OIDC Demo]

## Q&A
- [Afri S] - Why would you put this on a server? I wanted to put this in a bigger open source project in Rails but they were providing an IdP as well. We should sync about decentralized login - can you explain why you want an identity server. I don't think it's a good idea to put Ethereum identity on a server. 
- [Wayne] - We're skeptical too - we share the same end goal. Ideally we all support direct authentication and there's no intermediary. But after talking to a lot of applications in the Web2 world, we found a lot of interest in _not_ supporting a direct authentication method and instead adding one line in a configuration file. We also need to figure out a bunch of different ways for people to do it across a spectrum of decentralization and centralization. We can build these servers to be information minimizing - so there are different considerations and levers here. 
    - One really good use-case that I've heard of - think about companies that are pretty complex that have many different properties and they want to centralize how users log into their ecosystem. Adobe is one example with Photoshop or Behance, same thing with Microsoft and Live and you want to log into Excel or Word. You're still put through the Microsoft IdP - so it really depends on how you want to use it. We just wanted to provide it as an option.
    - Web3 companies aren't interested in this workflow and we prefer it that way. 
- [Afri S] - Thank you. I mean I think we're all on the same page. My fears are people opting into this old way of doing this that people would not use this better feature. We should not fully discuss this today. If we have both in parallel, then it's probably fine.
- [Wayne] - One more thing I'll add - OIDC has a profile call SIOP (self-issued OIDC provider) - and they're allowing users to become their own IdPs. It's co-authored by Microsoft, Matter, and others. There's a draft specification where instead of going to a server, you ask the device you're on for the information for the session. They use decentralized identifiers as well. There's movement on that too. If you look at the meeting notes from the OIDC foundation, they wanted a bunch of IdPs everywhere, but that's how the market evolved. 
- [Pablo] - Were you planning on doing something similar like aggregating data from the blockchain like in the Auth0 workflow? 
- [Wayne] - That's definitely in our plans. You'll see in the example that if you have an ENS name, it will just show up! If you look at the ENS documentation there's plenty of things that can also be pulled from that user. 
    - I can go over a little bit about how we information minimize the implementation of SIWE OIDC. It's written in rust, open sourced, and you can inspect it. We try to pass the information and not store too much of it on the server. That's how we're running it - there are ways to have info minimized IdPs. It's also a lot easier to secure if you do it like that - but the code is available. It's a full IdP server that implements the SIWE login method. 
- [Yoni Goldberg] - Just a quick question - why did you decide to pick to build the server from scratch? 
- [Wayne] - It was to information minimize and reduce attack vectors. Keycloak is a lot of lines of Java that you're pulling into your infrastructure. We just decided to make something that was a few hundred lines and it's a ll there in its entirety. We are messing with the OIDC auto-framework - we're moving towards that. They made it easier after they automated that. 