This EIP links one or more signing wallets via Ethereum Name Service Specification (EIP-137) to prove control and asset ownership of a main wallet.
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:
In all the above examples, one interacts with the dApp or smart contract using the wallet itself, which may be
Instead, one should be able to approve multiple wallets to authenticate on behalf of a given wallet.
Unfortunately, we've seen many cases where users have accidentally signed a malicious payload. The result is almost always a significant loss of assets associated with the signing address.
In addition to this, many users keep significant portions of their assets in 'cold storage'. With the increased security from 'cold storage' solutions, we usually see decreased accessibility because users naturally increase the barriers required to access these wallets.
Some solutions propose dedicated registry smart contracts to create this link, or new protocols to be supported. This is problematic from an adoption standpoint, and there have not been any standards created for them.
Rather than 're-invent the wheel', this proposal aims to use the widely adopted Ethereum Name Service in conjunction with the ENS Text Records feature (EIP-634) in order to achieve a safer and more convenient way to sign and authenticate, and provide 'read only' access to a main wallet via one or more secondary wallets.
From there, the benefits are twofold. This EIP gives users increased security via outsourcing potentially malicious signing operations to wallets that are more accessible (hot wallets), while being able to maintain the intended security assumptions of wallets that are not frequently used for signing operations.
Many dApps requires one to prove control of a wallet to gain access. At the moment, this means that you must interact with the dApp using the wallet itself. This is a security issue, as malicious dApps or phishing sites can lead to the assets of the wallet being compromised by having them sign malicious payloads.
However, this risk would be mitigated if one were to use a secondary wallet for these interactions. Malicious interactions would be isolated to the assets held in the secondary wallet, which can be set up to contain little to nothing of value.
In order for a non-hardware wallet to be used on multiple devices, you must import the seed phrase to each device. Each time a seed phrase is entered on a new device, the risk of the wallet being compromised increases as you are increasing the surface area of devices that have knowledge of the seed phrase.
Instead, each device can have its own unique wallet that is an authorized secondary wallet of the main wallet. If a device specific wallet was ever compromised or lost, you could simply remove the authorization to authenticate.
Further, wallet authentication can be chained so that a secondary wallet could itself authorize one or many tertiary wallets, which then have signing rights for both the secondary address as well as the root main address. This, can allow teams to each have their own signer while the main wallet can easily invalidate an entire tree, just by revoking rights from the root stem.
Many invididuals use hardware wallets for maximum security. However, this is often inconvenient, since many do not want to carry their hardware wallet with them at all times.
Instead, if you approve a non-hardware wallet for authentication activities (such as a mobile device), you would be able to use most dApps without the need to have your hardware wallet on hand.
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 prove asset ownership for.mainENS represent the reverse lookup ENS string for mainAddress.authAddress represent the address we want to use for signing in lieu of mainAddress.authENS represent the reverse lookup ENS string for authAddress.authKey represents a string in the format [0-9A-Za-z]+.Control of mainAddress and ownership of mainAddress assets by authAddress is proven if all the following conditions are met:
mainAddress has an ENS resolver record and a reverse record set to mainENS.authAddress has an ENS resolver record and a reverse record set to authENS.authENS has an ENS TEXT record eip5131:vault in the format <authKey>:<mainAddress>.mainENS has an ENS TEXT record eip5131:<authKey>.authAddress records on a single ENS domainThe mainAddress MUST have an ENS resolver record and reverse record configured.
In order to automatically discover the linked account, the authAddress SHOULD have an ENS resolver record and reverse record configured.
<authKey>. This can be any string in the format [0-0A-Za-z]+.eip5131:<authKey> on mainENS, with the value set to the desired authAddress.eip5131:vault on authENS, with the value set to the <authKey>:mainAddress.Currently this EIP does not enforce an upper-bound on the number of authAddress entries you can include. Users can repeat this process with as many address as they like.
mainAddress via authAddressControl of mainAddress and ownership of mainAddress assets is proven if any associated authAddress is the msg.sender or has signed the message.
Practically, this would work by performing the following operations:
authENSeip5131:vault TEXT record of authENS<authKey>:<mainAddress> to determine the authKey and mainAddress.mainAddress and verify that it matches <mainENS>.
mainAddress and authenticate via those.eip5131:<authKey> TEXT record of mainENS and ensure it matches authAddress.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.
authAddressTo revoke permission of authAddress, delete the eip5131:<authKey> TEXT record of mainENS or update it to point to a new authAddress.
The proposed specification makes use of EIP-137 rather than introduce another registry paradigm. The reason for this is due to the existing wide adoption of EIP-137 and ENS.
However, the drawback to EIP-137 is that any linked authAddress must contain some ETH in order to set the authENS reverse record as well as the eip5131:vault TEXT record. This can be solved by a separate reverse lookup registry that enables mainAddress to set the reverse record and TEXT record with a message signed by authAddress.
With the advent of L2s and ENS Layer 2 functionalities, off chain verification of linked addresses is possible even with domains managed across different chains.
This proposed specification allows for a one (mainAddress) to many (authAddress) authentication relationship. i.e. one mainAddress can authorize many authAddress to authenticate, but an authAddress can only authenticate itself or a single mainAddress.
The reason for this design choice is to allow for simplicity of authentication via client and smart contract code. You can determine which mainAddress the authAddress is signing for without any additional user input.
Further, you can design UX without any user interaction necessary to 'pick' the interacting address by display assets owned by authAddress and mainAddress and use the appropriate address dependent on the asset the user is attempting to authenticate with.
In typescript, the validation function, using ethers.js would be as follows:
If your application operates a secure backend server, you could run the client/server code above, then use the result in conjunction with specs like EIP-1271 : Standard Signature Validation Method for Contracts for a cheap and secure way to validate that the message signer is indeed authenticated for the main address.
Provided is a reference implementation for an internal function to verify that the message sender has an authentication link to the main address.
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 and related rights waived via CC0.