Sign in With Ethereum Community Call #9

# Sign in With Ethereum Community Call #9 ### Date: 2022/01/13 ### Agenda: - [General] Reader Notes & Updates - [General] Introductions - [Show & Tell] SIWE Updates (Rust, Elixir, Python, Ruby, OIDC, Discourse, PHP) - [General] Q&A ## Reader Notes and 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. - Documentation: if you're about to embark, let us know what you think would be best to include! All feedback is welcome. ## Introductions - [Jeff Steinmetz] - CTO on this app. We're merging events, chatting, DeFi and more into one platform and we have a classic OAuth situation, and we've been keeping an eye on this. - [Seth Bloomberg] - Works at Messari in a research group - been following for a bit and excited to see it across apps. - [Christian] - Lead US Research for Celsius Network and excited to offer users a crypto-native way to own their login credentials. Excited about it in general. ## SIWE Updates - [Wayne] - we have a bunch of libraries that we're working on and community contributors. There has been progress on Python, Elixir, Rust and a bunch of others. I'll be running through some of those. - We have a live instance of an OIDC server, so - a lot of stuff uses something called Open ID Connect which you can outsource an identity provider to servers other than yours. We wanted to make sure that was an option for people that wanted to integrate it that way. - You can use direct authentication which makes sure the message format was signed correctly. If the user is able to demonstrate key possession, then the user can be authenticated. Another option is to use an OIDC Server and add some centralization. We add centralization because some systems will have a hard time supporting direct authentication. - We have it working in a lightweight form, it's different than others. There needs to be trust in the OIDC server - so it needs to be run by a trusted entity, but we see it as a transition state because we'd like to move to direct authentication everywhere. - The server is almost stateless - we try to store the tokens with the services that rely on it. We just store the registrations of the clients. We can encrypt things and store it elsewhere - we're coding it extremely defensively. - There are some broader questions about identifier re-use, but we're looking for the right home to host this, stand it up, and have it go. - [Wayne] - Other updates: we have a rust implementation and we've made recent changes to it. Because Rust has great cryptography libraries, we've been able to package Rust inside of Elixir. - We're having challenges making a gem for Ruby on Rails - because we prefer direct authentication. If you have Ruby experience and you're interested in talking about this. We have the author of the Elixir library here. - [Kelsey] - (Presentation of the `siwe-ex` library) - [Wayne] - Speaking of external contributions - we have Payton here who single-handedly built out the python repo. - [Payton] - I had a need to use a Python implementation to help people adopt the format including myself, and I wanted to introduce this authentication format for. I overrode the Django authentication backend and now I use this format for signing messages. In terms of implementation, it's pretty barebones Python implementation. For ABNF parsing, we depend on an external library. It essentially matches the functionality of the base TypeScript SIWE library, and Simon at Spruce has been helping. - [Wayne] - Impressive work. I'm really happy to be surrounded by people who get excited about standards. One of the spec goals was to be simple to implement, so we're happy how it's turning out so far. Fortunately, a lot of developers have been reading the source code, finding the dependencies, and implementing it. - [Greg] - (Quick updates on login.xyz and the developer portal). ## Q&A - [Jeff] - I've been going through the spec and we're using OIDC. Since SIWE is working with your cryptography locally, what is it that we can use on the backend to authenticate that the client actually passed all the authentication checks through your wallet. - [Wayne] - The question was - how do we authenticate the integrity of the message and make sure the signature is verified on the backend. We're implementing support to make it easy to slot into different stacks. - [Jeff] - We use TypeScript on the backend and JWTs. It comes from Cognito -> JWT is of course signed and then we take the JWT and Apollo on the backend confirms it. - [Wayne] - That makes a lot of sense. In terms of SIWE support: it's really inspired by JWTs. (Shows off the grammar). We would add a different workflow for the library on your backend, take the message, ingest it, and check the signature against the address it's authenticating as. - [Jeff] - So the backend server is checking the signature. - [Wayne] - We have different language support for the different backends. - [Wayne] - With respect to the WordPress, it was a side project for someone to add Ethereum authentication, see your activity, and grant you a role. What's interesting about the WordPress work, is that if we are able to SIWE and based on DAO membership or NFT holdings, assign a role in WordPress, you can then provide things for DAOs like you can decide "hey I like that DAO, I'm going to make a website for it". - Today, if you sign in with Google, good luck getting them to add another claim as the sign-in response. - [Greg] - That's brilliant because we've been seeing discontent from NFT artists due to centralization issues with OpenSea. Just had some conversations with some of the folks that aren't necessarily technical and getting to that place where open source software can help them learn what they need to build their own site.