# Sign in With Ethereum Community Call #2
### Date: 2021/10/08
### Agenda:

- [General] - additional introductions for newcomers.
- [General] - reviewing the draft specification for the day.

### Additional Introductions
- [Gabe Cohen] - At Ceramic
- [Robert Neal] - Software engineer at Mem
- [Greg Lang] - Founder at Rivet.cloud and here because I love the idea and also because co-founder worked on some of the early technology behind cryptographically signed login before it was mutilated by Google and Facebook.

### General
- "One bit difference makes a big difference" when it comes to cryptographic hashing acceptance.

### Specification Review
- Today we are reviewing the specification as an EIP and go through each section to review progress.
- [Specification Link](https://hackmd.io/@MzEJ65DuRe2yCL6kPM5KBw/rkWKBFBfY)
- We use a lot of prior work including EIPs for signing.
- Sign in With Ethereum (ETHN) defines how accounts authenticate with services.
- Goals around consent management, services, and ease of use.
- Typically today, users use centralized identity providers with incentive misalignment, and ETHN offers an alternative to this.
- This work is sponsored by ENS and EF, and is being developed in the open via public repositories and community calls.
- How it works:
- Server presents user with a plaintext message.
- The signature is checked by the server to see if it matches the content, with additional fields included as well that are incorporated for session authentication.
- Example [in the spec]
- [Brantly] Q: Why specify an ENS name and not just use reverse resolution?
- This gives a mechanism if there's multiple names associated with one account.
- [Brantly]: but ENS already has a way to specify which of your names is tied: reverse lookup does this.
- If the user does want to use a name they didn't register on the reverse lookup, or even a different one than the one they registered on reverse lookup, should we allow this? But if we're always interested in using their primary name then we don't have to do it.
- [Brantly]: There's reverse resolution that solves this.
- Even if you don't specify an ENS name, any service can provide reverse resolution without this term.
- What was presented is an informal template-- subject to change, of course.
- More items: statements should be limited to prevent services from misleading users.
- `Domain` is the RFC4501 / doesn't lock you to HTTPS
- `Address` is the Ethereum address performing the signing.
- The `ENS` name is the ENS name (see above).
- `Statement` can be something like the Terms of Service string, without newline characters
- [Greg] Q: There could be a situation where statements point to statutes where there's legal meaning in whitespace. Is that something that has been considered yet? Example comes from SEC compliance as a signed message that included an affirmation. I can imagine one where it can be relevant for somebody.
- Yeah - it's a great point that people will want the user to accept messages. It's outside of this spec, because we want to make sure we're doing a great job with login. If they want users to agree to additional terms, that can be handled.
- We can add this to the considerations section where we summarize discussions like this.
- [Haardik] Q: Curious to understand - what was the reason to use EIP-191 instead of 712?
- We'll review that section later but the big reason is support. If you look at Rainbow wallet for example, this is what you get today but we're trying to get something working before the end of the year. We're skeptical that wallets will have good interfaces for this before the end of the year.
- [Haardik] So it's about compatibility now.
- We can have a forward-compatibility route including 712.
- [Rouven] Can you show me the section where you compare the two signings [on the screenshare] ? The one on the left [i.e., the screengrab from today's EIP191-based OpenSea log-in --ed.] would look a bit different after you have the data string in there with all the data you're presenting-- it would be too long to display on one modal and chose what to show and what not to show. Wallets need to do something if we want to make this secure [for the end-user].
- I disagree that it's abstract, in the next section I can talk about the ABNF formal grammar explicitly constraining the possible messages being signed. It's human readable but it's not 'sign whatever' - we have a specification that's more rigid than JWT.
- [Rouven] We need to agree that wallets need to do something to display it differently.
- Yes, and ultimately I want wallets to display complex signing requests nicely.
- [Joel T] I was talking to the founder of MetaMask the other day and he said there's 5 different versions of 712. If we go that route, it's going to be way more difficult.
- [Oliver T] The 712 route? To Rouven's point, you define here an ABNF rule and to enforce those rules wallets need to implement something.
- [Greg] It also seems that folks are getting into this for the right reasons. The strict standard is going to help with the rails, but you kind of expect a degree of buy-in if they're even thinking about this.
- [Joel] It will work in wallets without any change (this approach) and in this case wallets will be incentivized.
- [Oliver] It's the same with 712?
- [Joel] It's way less supported and there's more uncertainty.
- [Rouven] We could do this here and say for 712 this is the subtype, and this group could help in picking out what 712 subtype is there instead of going back and introducing a new structure.
- [Joel] You would need to go to all the hardware wallets and first tell them to have 712 support.
- [Rouven] How do you show them the data structure which is proposed.
- If I remove the comments it would be around 20 lines of specification and ABNF has been around for 30 years. There's a lot of library support across different languages.
- [Rouven] But hardware wallets - what will my trezor show me.
- [Joel] It will be compatible.
- [Rouven] I'm talking about security. That's why 712 exists: because it makes it more structured as to what people are signing.
- We are still waiting for Trezor to merge in 712 support. We would have to wait for them to support this.
- [Hadrien] Wallets have had years to work on 712, and for them to say that is ridiculous. Using something different than that, we standardize a string that can be decoded. This is basically using an existing non-structured signature system to design a new structured signature system.
- [Oliver] Agree.
- [Sergey] This isn't a new signature type. We don't require anything from wallet providers.
- [Hadrien] If you want something unreadable, it's the right way to do it.
- [Sergey] 712 is much better and as a person who wrote the first implementation of it, I agree. It really has worse support from hardware wallets and we're in a catch22: to do ETHN, we have to convince the wallets but we know they are slow so they have to be convinced. We have to provide them as a proof point that their effort is important. For this, we have to wait for them.
- [Joel] If you think about what the wallets would need to do - it would already be quite readable. Wallets would just need to do a MITM check against the domain and then it would be the most secure sign-in system.
- [Rouven] They need to understand what's in the string and not just something else similar to what browsers do. I question to what extent hardware wallets could do this [ i.e., support the current proposal]. I think we are arguing about what's most important. What are the requirements: do we value better validation requirements? If we validate this higher than how it looks - it's back to what do we think people will mainly use it for. Is it on your mobile phone or your hardware wallet? You can't really optimize for everyhting - so what are the tradeoffs.
- [Oliver] I also assume people don't really use hardware wallets on a day-to-day basis.
- [Joel] Who supports 712 outside of MetaMask. [answers in chat]
- I think getting the wallet support for 712 is very constructive for this. I will also note that structured signing is good and I think that there is a semantic equivalent to these fields that you can specify in EIP-712 and you would be able to type it with Sign-in With Ethereum. If it's interesting, that's something we can look at as well.
- Whether or not it makes it into this version, there is a forward-compatibility approach that could be developed if people want to switch to that signing at some point in the future. For me, it comes down to support. Rouven made a great point - what's the target audience, and if it's people interacting with Web2.5, not many people use this. Having a really good scope here is also important.
- [Greg] - Seeing majority of users and use cases there is important. Maybe what we'll find is that the bulk of the user base will be best served by something that prioritizes simplicity...
- (Back to the review)
- (Review of the additional fields in the scheme)
- Some of the design is JWT inspired.
- Resources:
- A list of URIs that are prefixed by a YAML-style list (dash space)
- Should be added to security considerations: implementers should limit terms as necessary, less is more for both privacy and security engineering
- Nonce should be at least 8 characters.
- Implementers should decide on these points (the limits on each term for security reasons)
- Should there be other comments as part of the resources? We're erring on the side of simplicity with recommendations.
- Server verifications (EIP-191) for users, and (EIP-1271) will be used for multi-sigs. The thing about 1271 and let me know if I have a misunderstanding: the signing can actually change because you literally just implement an interface. If it relies on blockchain state that can change the validity of inputs, then this should be taken into consideration.
- Let's say you have a multisig and replace one of the parties. In 1271 it might require some kind of signing from those keys. If you change the multi-sig and change the accepted signing keys, it can change the state of it. Services should be weary of that.
- Similar mutability/transferability concerns for verification of ENS names and I will include the resolution step that Brantly mentioned.
- Same thing about blockchain state being changed. ENS names can be transferred at any time, so implementers should rely on security mechanisms so session state relys on current status of the ENS name.
- We're not opinionated about the resources as long as they're URIs.
- For wallet implementers, domain verification is crucial - they need to make sure the domain matches the actual requester.
- For ETHN interfaces, if you want to make a nicer interface for the user, you can interpret the terms for ABNF and make it your custom sign-in UX.
- There's a semantic equivalent for this in EIP-712. You would put it in a custom signing interface to show the user that they're signing in with their Ethereum account.
- Multi-lingual support: we expect the wallet layer to translate to the user's native language. That's how internationalization will be changed - we don't like the idea of multiple valid signing strings. Cryptographic flexibility at the message signing layer is harmful-- one message, one signature is more secure.
- Rationale:
- Human friendly, simple to implement, secure, machine readable, and extensible.
- We need more data on wallet support and others.
- Concern: Why not use JWT?
- Same reason why we're not using 712. Wallets won't issue JWTs.
- K1 now is JOSE.
- Concern: Why not YAML?
- We use something close but stricter. We don't want field re-ordering, but only optionality.
- Concern: Why is chain-ID optional?
- The default would be to assume all the EVMs.
- Backwards Compatibility:
- EIP-191 seems to be broadly supported.
- Forwards Compatibility:
- Decentralized Identifiers
- SIOPv2
- EIP-712
- **We want to ensure that these are included in community calls. Does anyone have questions about these topics or other categories to consider here?**
- Security Considerations
- Identifier Re-use: The goal is towards perfect privacy where you construct uncorrelated identifiers. However, we see it as a difficult problem and we won't get there with this spec. Making sure it's extensible is the goal. Some user demographics want to re-use their identifiers to be known as the same identity. Those are likely the early adopters of this spec. As there's a broader base, we need to continue having discussions about this such as HD wallets, sign delegations, and ZKPs to delegate permissions without disclosing the true source.
- You already see sophisticated users of Ethereum who understand some of this but there needs to be additonal considerations for varied populations.
- [Rouven] How do we expect the Web2 type of services to use that? Do they tie emails to identifiers? Do they just want to see the signature but internally don't use this as the mechanism to identify yourself? This is just a question on how this will be used and maybe nobody does that, but at least guiding the Web2 services to follow the best practices will be a helpful addition to that.
- Thinking of canonical ways of resolving additional resources is constructive.
- [Brantly] I mean the current practice is that you're just identified as your public key. Even if you change your ENS name in your reverse record, that doesn't change the root of your identity. In terms of if you want to have an email address - there's two ways that can be achieved, you can store it in ENS records or Web2 services can make that as part of the flow. If there's non specified information you can do that.
- [Rouven] Not suggesting anything is wrong, we need to at least note the best practice. Whatever this ends up as, we just need to make sure this is all noted in the specification. Explaining these tradeoffs would be great.
- [Brantly] Agreed. The root of the identity is the public / private key.
- [Greg] Makes sense to me. You end up having a retread of worst practices of Web2 recreated by folks in a new form if we don't encourage that.
- [Brantly] That's straightforward.
- Great - moving onto the next section - Key Management.
- This is a market change, it's actually very convienient for Forgot Password buttons to exist. If the user self-custodies, it's difficult. Fortunately early adopters are already adept at key management so this will become increasingly relevant with mainstream adoption.
- Certain wallets can use multisigs for enhanced user experience.
- The answer here is user-choice and selecting people who are incentive-compatible here if a multisig handles it. More user-choice is aligned with values.
- Preventing Replay Attacks
- Nonce should be selected carefully.
- Domain Verification
- May get more granular if you are in the browser window or a walletconnect request.
- Session Invalidation
- Up to implementers to make sure it works.
- This was a productive conversation - the floor is open.
- [Greg] Maybe this putting the cart before the horse, but it might be useful to mention future governance of the specification. It might just be useful to put a blurb in there for a governance structure of the specification. But it's nonetheless on the table because a good spec has good governance.
- At this stage we aspire to achieve rough consensus which is the process.
- [Oliver] What are the next steps from your end?
- We're implementing the reference SDK to do the parsing.
- We added items to our laundry list - can we talk about EIP712 support.
- [Rocco] login.xyz website goes live very soon
- [Oliver] There was a lot of conversation on personal sign vs EIP-712. The spec you currently propose uses personal-sign with your proprietary format-- is that decided, or are you going to include the feedback from this call in your spec?
- I would push back and say that this is not a proprietary format-- it's a community draft of a format that anyone can interpret transparently from this spec. In terms of what we're going with - the draft is personal signing. I hope that we can agree and spend some time on the next call on this, on what are the metrics we're thinking about in terms of user experience, wallet support, application willingness, and we should use those terms to base the decision. We took on the work of making this initial draft but we will continue to talk about it.