Following discussion from this twitter thread:
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.
- 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 authentication wallets to verify control and asset ownership of a main wallet.
Functionally, this would work as follows (assuming the main wallet has an ENS domain and resolver record set).
- Create subomain record on the main ENS domain, starting with auth[0-9]*
- Set that record to the new authentication wallet
- Set the reverse record of the authentication wallet to auth[0-9]*.
Then, on a web client, you determine the linked main wallet whenever the authentication wallet performs an action by:
- Do a reverse lookup of the authentication wallet to get the ENS name
- Parse out the main ENS
- Lookup the address the main ENS resolves to, and that is the wallet you are authenticating for.
Effectively, this is a mechanism to do ‘read only’ authentication. Note: Steps 1-3 can be performed client side, and the results passed to a smart contract for cheap validation (rather than doing string operations on a smart contract).
Q: Why subdomains vs. TXT records?
A: Subdomains allow us to do the reverse resolution strategy outlined above, meaning that it doesn’t require a user to input the address they are trying to authenticate for. It makes it much easier from a userflow perspective. If we were using TXT records, you would need another field to input the wallet you are attempting to authenticate as.