# Sign in With Ethereum Community Call #3
### Date: 2021/10/15
### Agenda:

- [General] Updates
- [General] Introductions
- [Spec Review] New Items
- [General] Open Concerns
- [Spec Review] Continued Discussion Re: EIP-191 & EIP-712

### Reader Notes
- Next week's call is canceled
- Draft spec published as an [EIP-4361](https://github.com/spruceid/EIPs/blob/eip-4361/EIPS/eip-4361.md)
- [Login.xyz](https://login.xyz/) content has been published and is often updated
- If you're interested in being listed as a supporter, message Spruce (Rocco in particular, if possible) in the Discord chat.

### Additional Introductions
- [Hadrien #2] Co-founder at Sismo, want to contribute to the discussion and working on a way to manage identities through creating ZKPs of things that happened on private addresses.
- [Ronan] - Works on different things in the Ethereum ecosystem -- tools, games, etc. Into the UX for a long time. Proposed several EIPs, and wants to share comments.
- [garypalmerjr.eth] - Evangelist of ENS, and a big fan of Web3. Background in Web2 html/web design and SEO, a lot of experience with startups, and here to help push SIWE forward.
- [Jared] - Long background in finance and law for a long time and startups. Read about ENS - and becoming obsessed with crypto and SIWE seems like a cool project.
- [Jin] - Co-founder of Rainbow Wallet, and here to listen in to the community.
- [Lukas Schor] - Gnosis Safe. Main objective to make sure smart contract accounts are not penalized - but very glad to see EIP-1271 being considered so far.
- [Nathan] - Working with Hadrien on Sismo.

### Agenda
- [Rocco] Want to start with recent items added to the specification. Namely security concerns, and we're also starting to talk to wallets.
- [Wayne] Updates from last time, we had good suggestions to:
- Add a version in order to have an upgrade path in the future to make iterations and improvements once the first version is out. The field is mandatory and must be '1'.
- Making the ChainID required and normative (and you can only specify 1) - we originally specified multiple and now it's a single value.
- We're continuing work on the ABNF RegEx, and the SDK libraries.
- [Rocco] Want to review what Oliver was mentioning in the Discord about the resources.

#### Oliver's topics on Discord since last meeting
- [Oliver] I was thinking about the security of the specification and how it could be improved. The current specification is built on `personal_sign` which brings some challenges and limitations. The spec assumes that the wallet doesn't need to change anything for a user to use it, which is great because it'll increase adoption. However, the relying party doesn't have any mechanism to detect whether or not certain security controls were implemented by the wallet.
- I proposed changes to the specification which will improve security a little bit to **enable a relying party to detect if a wallet has implemented** those additional requirements that are specified in the spec that improve security.
- Why is this important? Because relying parties might be fine with taking a higher risk - but others might want to ensure that those security requirements were implemented by the wallets.
- [Juan in chat] Division of labor and incentives between RPs and wallets are complicated!
- It's not easy for a relying party (dApp) or service provider to know what version of the wallet they're dealing with and if there's proper support for the statements. I proposed something - not sure if it's the best approach, but in general, I want to know if people believe this is a problem.
- [Wayne] To summarize - it's a discovery mechanism so the relying party can figure out what level of security the wallet has?
- [Oliver] They can verify the wallet has support for a **particular spec**.
- Since this is from a JSON RPC interface, my assumption is that they would use `personal_sign` - but just to convert request formats - it will still be `personal_sign`.
- A wallet that doesn't have support for these validation rules or, for example, the domain verification, such a wallet would still be able to take care of the request and send the response back. In that case, this is important, because a relying party carries the risk for what they can't know the wallet didn't do to secure the request. In that case, end-users get access they're not supposed to have - it's a problem. It's less a problem for wallet providers because they can just say "yeah, this is `personal_sign`, it's your problem." I was never okay with you using this signing format for this sign-in spec - and I just want to provide a tool for relying parties to verify and detect whether a wallet implemented the login spec fully, including the security check. this reduces the risk incurred by the relying party by giving them insight into the wallet's security practices.
- [Wayne] This makes sense and I would add - you said that the RP holds the risk, and I agree that that's true, but the user also assumes the risk if they're the victim of a forward attack or other attacks here.
- [Oliver] The user might not know if it's not a tech savvy user.
- [Rouven] For less identity-experts or RPs -- what I was asking in the first call, if we are more explicit in the requirements there would be more reasonable tradeoffs.
- i.e., if you log into OpenSea and you give them your email address, you can change something but there are a lot of bad things that can happen because you have your key to sign a transaction - it's a very different security need then when you log into your email with your Ethereum key.
- The service provider should better understand what the user has proved, what security is done - does the user know they could be the victim of a phishing attack? What if the token is hijacked and used to log into a different service. Let's say we accept these constraints, these tradeoffs need to be noted relative to priorities and requirements. We need to make the tradeoffs more explicit for the process.
- [Hadrien C] I don't think we should make security tradeoffs. It's better to say 'this is the requirement that we want' but the wallet can still do what they want and the user can move to a wallet that does it better.
- [Rouven] Last week we spoke about `personal_sign` vs EIP 712, and my impression was that the majority of the call decided on 712 - how did we reach consensus around these things? Let's make it more secure and do the right things.
- [Oliver] To mitigate that attack, I proposed something based on a response parameter that a compliant wallet would include and something like -- 'domain check done' and then the content of the property would be a signature over the nonce plus something else so the response (personal sign response) would contain an outer signature and an inner signature as an additional property that the wallet implemented certain things.
- This obviously **assumes** that the user trusts the wallet and that the wallet doesn't have any incentive to make an invalid claim about the implementation section.
- [Wayne] These are great suggestions and important security mechanisms - another one is somehow making the **server** sign the nonce so it's locked to them [editor's note-- this was discussed on Discord the preceding week relative to replay attacks] but that would require [the server to have] a key. Kyle DH mentioned this in a separate discussion [on Discord].
- [Joel] - I don't see how the server signing the nonce would help.
- [Wayne] In the spec we write right now, maybe there's a nonce that can just use a recent blockhash - using something not related to the server means you don't have any authenticity guarantee that the request came from the server, but even if you had a signature, how do you associate the server to a key? There's complexities to the workflow.
- [Joel] We have that security - it's called https.
- [Wayne] That's true and you're trusting the CA. As long as the user trusts it, it's not necessary I guess.
- [Oliver] What I proposed would solve that because the second signature can only be provided by the wallet (not MITM). I'm not saying it's the best option, but it's a solution to the problem.
- [Wayne] Okay - I think those are great considerations. We need to strike the balance with simplicity but if they're optional, and they're absent because the wallet didn't implement it, I think that's a clever way to keep it usable and add security.
- [Joel] Only concern with the proposal, which I think it makes sense, if you're doing a [EIP] 1271 [multisig] and there's 3 ECDSA signatures, then that's a bunch of data and there's additional data that includes all of them -- if you're doing a multisig, then you first have to sign the nonce, and then you have to do another round signing over the signature. But that's the only concern.
- [Oliver] The question here is the scope of SIWE - the primary use case is to sign a user into an app. Do you really use contract signatures? I do understand why they're needed.
- [Wayne] So while contract based accounts are a new trend, it's not our job to decide whether or not it's a good trend. I think it would be implementable, and Joel you're right - if we were to require this, then you would multiply the work by the number of signatures. So these are good considerations.
- It has been here for a long time but due to some adoption of Argent and increased adoption of Gnosis Safe it's a popular paradigm.
---
#### Q&A
- [Ronin] [Q] Wanted to make general comments before diving in. I read the spec, and I have some ideas I want to bring to move it into a different direction:
- EIP-1102 - it's already something we have which is the first pop up when you want to use a Web3 website. Currently it doesn't do any checks - it just gives you the address you're connected to. I made a proposal to improve it by having it sign a message as well that the application provides a nonce. The benefit is that you only have one popup. The issue I see is that you have this 1102 popup, but then you have another one. I really like the design goals of the specification (human-friendly), and I completely agree and think we could do better.
- Maybe there's a case where you want an additional popup, but I think we can re-use 1102 so the only thing the user has is at the beginning where the application wants to access your address and it will remove an interaction.
- Other issue: there is a lot of parameters which don't make a lot of sense to a user, such as the nonce. It's not something a wallet has a plan for: to show a nonce to a user. It's for the backend to decode, not something for the user to see. All these extra fields are backend considerations.
- The wallets just want to protect the user and some of these requirements aren't enforceable.
- One thing about the ENS name is that when we want to talk about security, the wallet should not **approve** the ENS name - but for maximum security, it should approve the **content hash** that ENS points to. Maybe the user wants to trust the instance of that website then the ENS owner changes the content hash to something else.
- Lastly, for EIP-1102, an alternative is we can leave it and if someone approves 1102, then any further signature can be auto-generated.
- [Wayne] Thanks for your input Ronin. A lot of the fields are for security requirements and letting the user **set** (not just **see**) the expiry date period. I agree that it's not great to have an ISO date or UNIX timestamp, but it's important that they're able to sign over that.
- There was a comment in the Zoom to the effect that if we are to **standardize** this, then it becomes a good way for wallets to **display** it cleanly to the user [down the road, because everyone is encoding these strings to be signed one way, so they can be converted to something more human-friendly on that assumption if there is enough convergence to enforce that assumption].
- [Ronin] But I think it's a false sense of security because the backend has the final decision on whether or not to use something.
- [Joel] You can use this for other things that aren't back-end inputs, like an object capability. That date-value will have meaning that invalidates that capability. [editor's note - object-oriented capabilities are portable/interoperable authorization primitives used by [Ceramic](https://ceramic.network), [Kepler](https://github.com/spruceid/kepler/), and many other distributed storage solutions-- see our EIP review whitepaper for an introduction and links to background reading.]
- [Ronin] But the user cannot know if it will be used for that purpose. That's a separate concern. I don't mind the message being signed through that, but that should be an extension. It's a concern for the application.
- [SU] As a user I would not like to give a forever-permission to use my data, because that signature could leak and that party could abuse that signed payload and signature. This is of crucial importance to evaluate this.
- I'll select the wallet that shows me that [expiry information over the one that doesn't].
- [Ronin] As long as the domain is checked, then you don't need this expiry.
- [Joel] You're putting an extra requirement on the backend to keep a mapping of all the sign-in signatures that it ever observed or it can't know how long it has been used for.
- [Ronin] It could be part of the message - the user has no control. Of course we can have that to have an app let a user know they won't use it after a specific time.
- [Ronin] But the wallet can't know about how the app is using it. The wallet can't protect over the use of these fields - I don't see it being part of what the wallet displays.
- [Wayne] If you look towards the bottom of the spec towards the wallet implementers, it **does** state some terms that are required. These are the most important ones for the user - but the other ones must be exposed, and it can be part of an extension, in my view. We have to strike the balance between what the user sees that's nice and what can help with security properties.
- [Ronin] We need to be careful of the false sense of security.
- [Wayne] Got it - I think that the request can be fully generated by the wallet. Yes the server can present it, another way is the wallet or the frontend dapp can build the signing request.
- [Ronin] In that case you can trust the frontend.
- [Rouven] [Q] I was taking my hand down because I didn't want to disrupt. It feels based on the draft spec, we are reverse-engineering what requirements we have. (lists requirements) - it's a bit hard to define what's the right spec or technical thing if we have different use cases. We don't have a core set of requirements and [use cases, so it's hard to see the] tradeoffs.
- I'd like it if we could Be more explicit about what we're trying to achieve here in a V1, 2, or 3 depending on which can solve which needs for a specific problem. Wayne, you made a comment earlier about taking something into consideration - but who is making the decision?
- [Wayne] To clarify the roles, as Spruce we drive it forward and host the calls, but it's also our responsibility to present it to the community and seeing what's objectionable. So we'll take care of the heavy lifting of writing the changes in. These calls have been really informative.
- [Brantly] If I can speak on this - you said this in a previous call Wayne, the goal here is rough consensus. We need to talk it out and come to some conclusion - at the end of the day is literally what's written in the spec. Our goal is that we reach rough consensus.

#### Resources - What do they mean?
- [Oliver] [Q] - I had a separate topic. I had some security concerns, the next one is related to what Ronin mentioned. I believe you should standardize expiry and nonce, but I also believe a lot of those message properties don't make any sense to the user. I appreciate that the spec says it should be shown to the user which is good, but I think the resources array for example is something that I don't understand yet. Why is it needed to include those URIs? The resources usually don't make any sense to the user - the list can get long and nobody prevents the RP from adding 20-30 of these. What does it really mean? Why do we need to sign these?
- [Wayne] Got it. The thinking behind it is that adding additional claims to authentication if the user wanted to set preferences, applications would have space to use it towards that. I see what you're saying if there's 20 of them that's still compliant [with the current draft] and the user wouldn't have the chance to read every single one of them because users have short attention spans.
- [Oliver] Yeah but what does it really mean? If the user signs that request, what did the user provide consent to? The user doesn't know anything by looking at the message. [URIs often aren't human-readable or meaningful]
- [Ronin] It's nothing - signing the message does nothing -- it's the application that provides that service. Resources doesn't make sense, it's a[nother] false sense of security.
- [Oliver] If you don't manage to provide...in OAuth [for comparison,] you have [string] scopes, but maybe we can add something similar? Maybe what you want to CRUD on the [listed] resources? It might not make sense for all the resources. Even with HTTPS we can have CIDs that look like blobs of data and users don't know what it is. It's dangerous to use the signature over those URIs to make auth decisions.
- [editor's note, kyle den hartog wrote up some examples of more-opaque URI types on Discord this week]
- [SU] Right now we're trying to standardize on a payload that is 1.) understandable for a user, and 2.) can be machine readable. We are trying to achieve that using the least common denominator that is `personal_sign` so we're limited to the new string. So what the intent is here is providing the user with meaningful information from the wallet to present it. It's necessary and extensible **enough** to add **some** read/write or whatever [else] we need to do at a later point in time.
- [Oliver] Sure but my point is that it's just dangerous to use the signed message to get access to any of those URIs - the user doesn't know what it really means and nobody tells the user "for this [resource] you just gave [the relying party] consent to delete it" or something like that.
- [SU] If the wallet is advanced enough then it can parse that URI, and [deduce? display?] what it actually means. It's up to the wallet and in my opinion up to a different specification.
- [Oliver] I think it's too large for this meeting today but we should definitely revisit authorization policies.
- [Ronin] It feels to me that there are two specs - one to sign things, and one that is application specific. We should separate the two and focus on the two instead of trying everything in one specification.
- [Wayne] Totally agree that authentication and authorization should be handled with focus for each of them and not a side job. **We don't want to go into authorization land deeply**.
- [Juan] I actually was going to agree with Sergey. I'm wondering about the resources - what the relying party needs and what the wallet needs. If the RP wants resources to be part of the single signature and the wallet would have every incentive to do what Sergey is saying, and whichever wallet is first to enable parsing and displaying those URIs meaningfully would be the better wallet here.
- I keep saying this - it might help if the **scope section** of the spec said what isn't this spec's problem. It's a spec for RPs and maybe the wallet that wants to support this has some v2 or extension spec that makes all of this more secure or more end-user-friendly. This spec is defining what has to be in the payload and **the wallets that do this better will have an advantage**. Making that explicit might make this easier to design and less controversial among us.
- [Wayne] I second that and will translate it as a call for an **out of scope section**.
- [Joel] There's actually a nice in-between thing optionally by using the statement which can provide a URI to some website or tool which you can visit to parse the entire consent message and the site can interpret it for you now and give you more information before there's support for it. That would provide us for a middle path for security -- telling the user exactly what they're signing.
- [Oliver] That's a nice proposal I would like to explore.
- [Wayne] I love that idea - especially if we can build it quickly as part of this project; sure, your specific application might have a signing explainer specific to your SIWE string, but if we had a** community tool** that could parse and help the end-user understand **ANY** SIWE string, it would give people a place to inspect what everyone is doing.
- If wallet vendors want to **improve their interface**, this could be a foundation for them to work off of.
- I also wanted to point out that this is new territory at least to my knowledge in that I don't know if too many experts have an answer on how to consent with a private key. I know that this was under consideration by the European Commission as part of the broader conversation around eIDAS and its consent requirements [editor's note-- this work largely happens in CEN, the European equivalent of NIST, but a helpful guide to these conversations that doesn't require membership in CEN is INATBA, which holds regular meetings and releases publications for the curious]. The US was also thinking about it at one time, but I haven't seen a proliferation of interfaces rushing to standardize on this yet.

#### Parting
- [Oliver] I want to make a comment - you should make an assumption that users [editor's note-- implementers? end-user?] don't read the specification.
- [Wayne] We might be able to write a requirement into the spec that somehow/somewhere, a statement be made explicitly, mentioning what the resources is being authorized for.
- [Rocco] We're about to reach the noon mark - the call recording and minutes will be posted publicly. We will be canceling next week due to ETHLisbon and conference travel but will be picking it up the week after and playing with the schedule. That will be communicated in advance so keep an eye on our Discord. Get in touch if you would like to be added to the supporters list.
- Lastly, you can always join the Discord to chat at any time on this!