-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP-5131: ENS Subdomain Authentication #5131
Conversation
All tests passed; auto-merging...(pass) eip-5131.md
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the time right now to look at the content (I will later), but here are a few changes that need to be made.
Thanks. I have made the suggested edits. |
FYI - I've left a comment on your discussion thread. |
Saw that and responded, thanks! Look forward to continuing the discussion there! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got a few more suggestions (primarily changing read only to reversible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving edit suggestions.
Thanks for the suggestion @Pandapip1 commited. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great, I've given it a first pass.
EIPS/eip-5131.md
Outdated
Let: | ||
- `mainAddress` represent the wallet address we are trying to authenticate or very asset ownership for | ||
- `mainENS` represent the reverse lookup ENS string for `mainAddress` | ||
- `authAddress` represent the address we want to sign with in lieu of `mainAddress` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to add any requirement on this being an EOA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say not (for both authAddress
and mainAddress
) because we wouldn't gain anything from such a restriction, would we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, we shouldn't be restricting it because a smart contract address could be used pretty easily with the right setup.
@wwhchung I'm in favor of having some screenshots included to demonstrate the configuration of |
Co-authored-by: lightclient <[email protected]>
Co-authored-by: lightclient <[email protected]>
Co-authored-by: lightclient <[email protected]>
Co-authored-by: lightclient <[email protected]>
Thanks. I didn't see the other EIP when I was looking, and circulating it around the other groups I'm part of (NFT Security Group, ENS, etc.) they haven't encountered it either. What would the next steps here be? Looking forward to having it merged in |
Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
EIPS/eip-5131.md
Outdated
Note that this specification allows for both contract level and client/server side validation of signatures. It is not limited to smart contracts, which is why there is no proposed external interface definition. | ||
|
||
## Rationale | ||
The proposed specification allows one to link multiple addresses as 'authentication addresses' to a core main address. This is beneficial from a security standpoint (if the authentication address is compromised, the assets held by the main address is not), and convenience (if the authentication address is a simple MetaMask wallet but the main address is a hardware wallet). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think this section is reading more like motivation than rationale. I think you should consider moving a fair bit of this content above and focus on answering why certain design decisions were chosen over other decisions here.
Co-authored-by: lightclient <[email protected]>
## Motivation | ||
Proving ownership of an asset to a third party application in the Ethereum ecosystem is common. Users frequently sign payloads of data to authenticate themselves before gaining access to perform some operation. However, this method--akin to giving the third party root access to one's main wallet--is both insecure and inconvenient. | ||
|
||
*** Examples: *** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This EIP seems highly useful given these examples. At the moment there is a real pain point of holding assets securely while still being able to prove ownership via a hot wallet especially in mobile settings. I'd be excited to see this proposal go through
Thanks
…On Wed, 6 Jul 2022, 2:40 am Alexander, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In EIPS/eip-5131.md
<#5131 (comment)>:
> +author: Wilkins Chung ***@***.***)
+discussions-to: https://ethereum-magicians.org/t/eip-5131-ens-subdomain-authentication/9458
+status: Draft
+type: Standards Track
+category: ERC
+created: 2022-06-03
+requires: 137
+---
+
+## Abstract
+This EIP links one or more signing wallets via Ethereum Name Service Specification ([EIP-137](./eip-137.md)) to prove control and asset ownership of a main wallet.
+
+## Motivation
+Proving ownership of an asset to a third party application in the Ethereum ecosystem is common. Users frequently sign payloads of data to authenticate themselves before gaining access to perform some operation. However, this method--akin to giving the third party root access to one's main wallet--is both insecure and inconvenient.
+
+*** Examples: ***
This EIP seems highly useful given these examples. At the moment there is
a real pain point of holding assets securely while still being able to
prove ownership via a hot wallet especially in mobile settings. I'd be
excited to see this proposal go through
—
Reply to this email directly, view it on GitHub
<#5131 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUWDI4LLUZJKBIJPXLAQYZDVSR6TTANCNFSM5XXGMIPQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit
Co-authored-by: Pandapip1 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what is failing Travis CI. As soon as this is fixed, this can be merged!
Head branch was pushed to by a user without write access
Co-authored-by: Pandapip1 <[email protected]>
* Add EIP-603: ENS Auth Linking * rename eip-603 to eip-5131 and remove external links * changing to an ERC * additional context * add refrence implementations * rename * edits as per suggestions * further content edits * grammar fix * short description change * update discussion link * update ref implementation * update with new reference code * format edits * update reference implementation * Update eip-5131.md * add additional code for sample implementation * clean up Abstract and move contents into Motivation * Update eip-5131.md * Update EIPS/eip-5131.md Co-authored-by: Sam Wilson <[email protected]> * edits * Update EIPS/eip-5131.md Co-authored-by: Daniel Tedesco <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: Daniel Tedesco <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: Sam Wilson <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: Sam Wilson <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: lightclient <[email protected]> * update Specification for EIP-5131 * update Rationale section * improve Motivation section * Update EIPS/eip-5131.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5131.md Co-authored-by: Pandapip1 <[email protected]> Co-authored-by: Sam Wilson <[email protected]> Co-authored-by: Daniel Tedesco <[email protected]> Co-authored-by: lightclient <[email protected]> Co-authored-by: Pandapip1 <[email protected]>
@wwhchung curious to know the state of this EIP, is it still relevent or deprecated? |
When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: