Add EIP-5131: ENS Subdomain Authentication

EIPS/eip-603.md

@@ -0,0 +1,85 @@
+---
+eip: 603
+title: ENS Auth Linking
+description: Use ENS to link hot wallets as approved signers for a root ENS address.
+author: Wilkins Chung (@wwhchung)
+discussions-to: https://ethereum-magicians.org/t/eip-603-ens-authentication-link/9458
+status: Draft
+type: Standards Track
+category: Interface
+created: 2022-06-03
+requires: 137
+--- 
+
+## Abstract
+At current, web2 and contracts validate asset ownership and wallet control by requiring you to sign a message or transaction with the wallet that owns the asset. 
+
+Examples:
+ - In order for you to edit your profile on OpenSea, you must sign a message with your wallet address.
+ - In order to access NFT gated content, you must sign a message with the wallet containing the NFT
+ - In order to claim an airdrop, you must interact with the smart contract with the qualifying wallet address.
+
+This method of validation is problematic from a security standpoint (interacting with a malicious site or contract can compromise your wallet's assets) and a convenience standpoint (e.g. if your assets are on a hardware wallet that is not easily accessible).
+
+This EIP proposes a solution which uses the Ethereum Name Service Specification (EIP-137) as a way to link one or more signing wallets (presumably less secure) to authenticate a main wallet.
+
+## Motivation
+As explained in the abstract, the current method of using a person's main wallet for authentication of control and asset ownership is both insecure and inconvenient.  It is as if, in order to authenticate, you must give an application root access to your wallet.  This proposal provides an easy way to do 'read only' access to a wallet by leveraging existing infrastructure.
+
+Some solutions propose dedicated registry smart contracts to create this link, or new protocols to be supported.  Rather than 're-invent the wheel', this proposal aims to use the widely adopted Ethereum Name Service in order to bootstrap a safer and more convenient way to sign and authenticate.
+
+
+## Specification
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
+
+
+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`
+ - `authENS` represent the reverse lookup ENS string for `authAddress`.  It must be in the format `auth[0-9]*.<mainENS>`.
+
+### Setting up one or many `authAddress` records
+The pre-requisite assumes that the `mainAddress` has an ENS ETH resolver record configured.
+
+1. Using your `mainAddress` wallet, sign into ens.domains and create a subdomain record for `mainENS` called `auth[0-9]*`.  This becomes the `authENS`
+2. Set the ETH resolver record for this `auth[0-9]*` subdomain to the `authAddress`
+3. Using `authAddress`, sign into ens.domains and set the ENS reverse record to `authENS`
+
+Repeat this process with as many addresses as you would like.
+
+### Authenticating `mainAddress` via `authAddress`
+Control of `mainAddress` and ownership of `mainAddress` assets is proven if any one of associated `authAddress` is the msg.sender or has signed the message.
+
+Practically, this would work by performing the following operations:
+1. Get the reverse ENS record for `authAddress`
+2. Parse `auth[0-9]*.<mainENS>` to determine the linked ENS
+3. Do a lookup on the linked ENS record to determine the linked `mainAddress`
+
+
+## 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).
+
+### Example:
+I need to own an NFT to get into an event. I have my phone (hot wallet linked to auth.wilkins.eth), but not my ledger (wilkins.eth) If I sign with my phone, this verifies I own the main wallet and the NFTs in the ledger, letting me into the event safely.
+
+Further, I have multiple devices:
+ - My iPhone has mobile metamask hot wallet, and I can add it as an auth account by setting auth1.wilkins.eth to that wallet (and the corresponding reverse record). 
+ - My iPad has the same and can be set to auth2.wilkins.eth, etc. 
+
+Lost my device? No problem, just delete the record.  No need to import/reimport seed phrases.
+
+
+## Reference Implementation
+Reference typescript client side libraries can be found here:
+https://github.com/manifoldxyz/ens-auth-ethers
+
+Reference solidity libraries can be found here:
+https://github.com/manifoldxyz/ens-auth-solidity
+
+
+## Security Considerations
+The core purpose of this EIP is to enhance security and promote a safer way to authenticate wallet control and asset ownership when the main wallet is not needed and assets held by the main wallet do not need to be moved.  Consider it a way to do 'read only' authentication.
+
+## Copyright
+Copyright and related rights waived via [CC0](../LICENSE.md).