Sign in With Ethereum Community Call #4

# Sign in With Ethereum Community Call #4 ### Date: 2021/10/28 ### Agenda: - [General] Reader Notes & Updates - [General] Introductions - [Spec Review] New Spec Items - [Demo] login.xyz Example - [General] Q&A ### Reader Notes - Still experimenting with time slots - may switch to twice-monthly schedule. - As always, if you plan on supporting SIWE, we would love to have your logo on the supporters list. - We're always available to chat in our discord. ### Introductions - [Ripley Jene] - in the bay area, worked with apple and now works on a non-profit called Generous-AF. The goal is to support initiatives that build equity with local communities. - [Alec Wantoch] - Alec from Valist.io - building web3 native software distribution, and comes from a security background. - [Nick Johnson] - Creator of ENS and here because SIWE is awesome. ### Spec Review - [Wayne] - One of the reasons we've done this more sparsely is because we've achieved a great amount of alignment. The supporters list is continuing to grow on login.xyz and there's plenty of conversations taking place. Basically that has resulted in revisions and we're roughly there, and we're going into build-mode. - With respect to the specification, I can talk about the changes made since that time. - Main changes: - Minor corrections to the ABNF message format. We found some characters that should be moved around, and the message format can literally be run by an ABNF interpreter. Tons of languages have support for this and we've also implemented a regex. - We've also added an out-of-scope section, one of the great things that came out of the discussions is making sure things are noted to be out of scope: (Additional authentication not based on Ethereum addresses, authorization to server resources, interpretation of the URIs in the resources, specific mechanisms to ensure domain binding, mechanisms to generate nonces, protocols for use without TLS connections). - We also talked a lot to mobile wallets and WalletConnect, and we're excited for WCv2, especially for security improvements. - One of the limitations of WCv1, is that after you scan the QR code and broker a connection, within the session, it's difficult to verify who you're talking to. The wallet can say "make sure the website matches the domain and maybe there's an indicator of TLS" so we've added clarification. - There are a few WIP sections that don't affect the spec, but are important to consider. There are hiccups in the CI build that we'll address as well. We're ahead of schedule and I think we should have something to show pretty soon. Open for questions. #### Q&A - [GaryPalmerJr.eth] - What can we expect from a general perspective in terms of timelines and expectations on milestones. - [Wayne] - We're going to talk about that next - just wanted to talk about the specifics on the specification. - [Rouven] - Is there a commitment to work on v2? - [Wayne] - We would love to. What has developed from the last community call, we've been talking about how it's important to help users understand signing messages. There have been separate efforts to make that easier - it has shed a lot of light on important things wrt to SIWE. - [Rouven] - We have a lot of security concerns and was this effort aligned - it's good to continue to find resources and continue funding this effort. - [Wayne] - We would love if we could collaborate even more with people. If everyone's agreed with what's going on here, we can start work on the future versions on these calls as well. ### New Items and Milestones - [[Demo of login.xyz SIWE example]] - [Wayne] - Additionally we have the SIWE NPM package. Trying to hit our targets at the end of the month and we have to test it extensively across 6+ wallets to make sure it's all working. - [Nathan] - Would love to test. - [Wayne] - We're going to send an email out to gauge if anyone is ready to test. What to expect from the code side: - The ABNF grammar is abridged, and we had to fill in a lot of the definitions. Happy to say that we're parsing it in TypeScript and that's what's being used to parse it. - Other updates: we have talked to WalletConnect and in v2, there's a possibility to bind values to a server if you're brokering a connection with a server. The server might be able to sign a message containing a nonce that it wants back so you can authenticate a request. When you're in WalletConnect v1, it's hard to know where you are and you don't know what domain sent you there in the first place and you need to build the trust up beforehand. If the user goes to a phishing site, it would be good to know for the user if they're connecting to the wrong domain. - To note: we recommend that if you can make a more privacy preserving way to get a nonce, then you should do that to avoid phoning to a server. - One of the very annoying things when using a deeplink or QR code-based session, you have to switch back and forth twice (picking the account and then signing). We're hearing that in some versions of the protocols, you can select an address and sign a message so it's in one easy switch. --- Floor is open --- ### Q&A - [Naval G] - [Question about gas fees] - [Wayne] - Sign-In with Ethereum costs no gas because you're signing a personal sign message. Another misnomer is that you need an ENS name to do this - but you can use any ethereum address you want. If you like an ENS name you can buy it and you can resolve it. - [Joel] - Unless you use 1271. - [Hadrien C] - *might* because most 1271s don't require sending a transaction. - [Wayne] - EIP-1271 is last-call which means it's near final. It's already in production - if you have what's called externally owned accounts (EOA) - it means you have a public/private keypair and the user is custodying a private key. What if you wanted a more sophisticated wallet that can be a multisig? A smart contract is straightforward and proven. Gnosis Safe and Argent use these. They both implement 1271, and it basically has a function called `isValidSignature` which allows a contract to act as a wallet that can verify if a message was correctly signed. - The flexibility of it is up to the contract to define what's a valid signature so you would just pass a hash of the message, and it tells you - basically that's it. There's no prescription around what needs to happen and as Joel pointed it out, there might need to be additional on-chain magic tricks. - If you want a large number of folks in a DAO signing, it's possible to implement that with 1271. But we need to figure out the UX. - [Naval G] - Looks promising that all transactions will be verified by the server. - [Wayne] - What if you can use your Ethereum address for other aspects that are aligned with the philosophy of Sign-In with Ethereum. After establishing a session, what else can you do and be able to have control over in your digital life? - Key management is hard and we like forgot password buttons, but with solutions like 1271 it's very optimistic in terms of the UX we can provide to users. What if a multisig made it easier if you lost your key? There's more key recovery possible these days. - Anything else? - [Nathan] - Can you talk more on privacy considerations? - [Wayne] - We have a section here (pulls up spec). The goal we can agree on, is that for every new interaction you have an uncorrelated identifier. From there, you can selectively disclose enough information for the interaction and in that case you have great control over it. - Getting to there - we won't be able to tackle all the considerations but we can make the path towards it. We also want to minimize wallet and server interactions to prevent predatory dapps. Right now we use HTTPS or TLS, and there could be a future where we can do key-exchange with Ethereum accounts and there are some projects working on that. Those are some considerations. - [Nathan] - It's a hard problem to tackle and I want to see the first implementations of that like selecting to disclose specific information about yourself? - [Wayne] - I think some possibilities for that could be the resources URI. There could be other steps to authorize the retrieval of information about you. Those are out of scope and we're excited to see extension specs and we know of one or two. One model is using a capabilities-based permissioning model - the request could be a capability to access information. Another one is just managing an access list - if your URI has authorization, you can use the one on the server for host binding for access. We just need to see more experiments and directions with it. - [Seth F] - Capabilities working group would be awesome. - [Wayne] - Agreed. - [Nathan] - Would love to participate as well. - [Wayne] - I also want to highlight [Brave's experiment](https://brave.com/research-paper-privacy-and-security-issues-in-web-3-0/) that would let you connect to dapps and generate a new identifier for you every time. The difficulty is making the UX reflect the pricing, and balancing and they used some hacks to do that. - [Joel] - One thing to raise on capabilities: we as in people building Ceramic are thinking about this and are designing a thing where you can use SIWE to provide a capability to get write access to a P2P database. We're going to post this in the CASA group as a suggestion there. That would be a good place to coordinate that work. ----- END OF CALL -----