EIP-4361: Sign-In with Ethereum

Discussion for EIP-4361.

You can find the latest updates on this work including recorded community calls with notes and links to the chat at login.xyz.


Ferrying some discussions over from the GitHub thread.


axic asked

Why is it preferable to have a new invented language and not some binary format, which is easier to parse (CBOR or even ERC-712)?

Is the only reason because the signed message will be “readily” displayed in wallets without implementing support for it? If so, I think hardware wallets may be a big exception to that where some other more easily parsable format is more likely to gain support.

wyc responded

Hi axic, thanks for your concern. That is indeed the main reason, so that applications may adopt this specification without full buy-in from wallet vendors or significant degradation of their user experiences today. In our proposal response to the RFP, we actually specified EIP-712 as the signing format, but found the user experience across many wallets to be much worse than using EIP-191. Formats like CBOR, EIP-712, protobuf, etc. indeed specify structuring for data, but hardware wallets have spotty support for presentation of EIP-712 requests to the users already (please see ongoing issues Ledger/Trezor). We believe that if adoption of this specification relies on all wallet vendors upgrading how they do signing first, it is far less likely to see success. While pure technical merit is important to consider, adoption depends far more on talking to downstream users and understanding their concerns, what they are likely to truly adopt, etc. We have completed over 30 interviews towards this conclusion. We welcome anyone to let us know of any further user research in support or incongruent with this claim. Hope that helps!


awoie asked

Since this is still a draft, it is feels a bit weird that folks have already approved this. wyc Is this going to be merged once all issues in the community calls get addressed?

wyc responded

awoie the PR is indeed in draft state, and therefore can’t be merged right now. I appreciate everyone who signaled their support for it so far! We will discuss pretty important matters in the public community calls and attempt full resolution of any concerns prior to merge, but also we are on a timeline for delivery so this must be balanced too.

Full details: login.xyz


The mentioned link doesn’t work for me. The correct link would be Create EIP-4361: Sign-In with Ethereum by wyc · Pull Request #4361 · ethereum/EIPs · GitHub

1 Like

hardware wallets have spotty support for presentation of EIP-712 requests

I don’t see how not using EIP-712 improves the situation for hardware wallets. Wouldn’t it make more sense to specify 1 specific EIP-712 struct that is expected? In this case hardware could optimize for this one. The issue for hardware wallets with EIP-712 is that it is fully dynamic and therefore quite complex to implement with limited resources. But if you pick one specific domain+struct it is trivial to implement. This would also allow easy support on contracts (as EIP-712 was designed with smart contract in mind).

TL;DR: Private Key != Identity. Contract == Identity.

I am pretty strongly opposed to this proposal because it doesn’t support contract wallets. Attaching an identity to a private key means users cannot rotate their private keys, something broadly considered a good security practice. In general, we should try to minimize the number of situations where a user’s private keys are tightly coupled with some feature.

Instead, we should have a standard for a contract that has a method like, isAuthorizedTo(signature, permission_set). Then a user would sign something (exactly what is up to the contract wallet they are using and not something that needs to be standardized) and the website could then ask the contract wallet associated with the user’s identity if the supplied signature is one that is authorized to do the thing the user is doing (like sign-in to social media accounts with read access).

This system also would support on-demand permission checking. You could prompt the user for a signature, and then the website could ask the contract “does the signer have permission to do X” each time the user tries to do some new action. You would probably want some standardized contract method for adding/removing access to a particular private key, but I think that could be in a separate standard (or many standards).

Note: If one does implement a contract-friendly system as outlined above, then a registry like EIP-1820 should be used so that any contract that supports arbitrary method calls can work with it and it doesn’t require every contract wallet to natively support it.

If a user wants to roll their keys, they would only need to update their contract wallet with the new keys and they would not need to roll their keys with every single service they interact with.

1 Like

Hi Micah, thanks for your thoughts! I’m happy to report that the spec does indeed support smart contract wallets via EIP-1271. Please see the section titled “Signing and Verifying with Ethereum Accounts”. Hope this helps, please feel free to add anything further.

1 Like