Skip to content
This repository has been archived by the owner on Jun 3, 2022. It is now read-only.

Add new method eth_signTerms #7

Closed
danfinlay opened this issue Oct 27, 2016 · 5 comments
Closed

Add new method eth_signTerms #7

danfinlay opened this issue Oct 27, 2016 · 5 comments

Comments

@danfinlay
Copy link

I've seen an increasing number of Dapp developers asking how they can allow web3-enabled visitors to authenticate by signing a terms of service to register.

This would allow a site to verify account ownership, without costing any gas fee, and allowing off-chain relationships to continue.

The reason this is different than the other current sign methods, is that it would be implied that the contents to be signed are human-readable text, (maybe styled, like markdown) so that web3 browsers and wallets can display the site's terms with the specified encoding, before hashing, prefixing, and signing as usual.

Anyone else interested in such a method?

@danfinlay
Copy link
Author

This got +1's but never actual maintainer momentum, so I've opened an EIP:
ethereum/EIPs#185

@gavofyork
Copy link

With eth_sign, Parity already checks the content of the data whose hash is to be signed and displays it to the user in a sensible fashion. What additional functionality would this bring?

@danfinlay
Copy link
Author

This may be fine to implement as hoc like this. In the EIP, it was pointed out that recognizing email like mime headers could allow Ðapps to specify their terms render strategy.

This could be non destructively added though, so it doesn't need agreement, it can just be added and supported.

That said, if I say MetaMask adds something like markdown terms when given a mime header specifying it, and Ðapps adopt this format, other clients might want to add support, and maybe wish they'd chimed in on what that format looks like.

But even then, I agree, this could be a sort of additional functionality on the normal eth_sign.

@danfinlay
Copy link
Author

In that linked EIP it was actually you who already convinced me no new method was needed, mine types could be added. If we agree on that format tentatively, I would call that the current proposal of this issue.

Maybe I should reopen with that topic?

@danfinlay
Copy link
Author

Closing this, because I consider it basically solved by personal_sign.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants