This presents a method to improve a universal method of login to the ethereum blockchain, leveraging the metadata storage provided by the ENS. We consider a user to be logged in when we have an EIP-1193 provider that can sign transaction and messages on his behalf. This method is inspired by Alex Van de Sande's work and Web3Connect. In the future, the approach described here-after should be extended to work with any blockchain.
Multiple wallet solutions can be used to interact with the Ethereum blockchain. Some (metamask, gnosis, ...) are compatible as they inject a standardized wallet object in the browser without requiring any effort from the Dapp developers, but they require an effort on the user side (user has to install the plugin). Other solutions (Portis, Authereum, Torus, Universal Login, ...) propose a more seamless flow to non-crypto-aware users but require an integration effort from the Dapp developers. Hardware wallet (ledger, trezor, keepkey, ...) also require integration effort from the Dapp developers.
When Dapps integrate login with multiple solutions, they rely on the user choosing the correct wallet-provider. This could prove increasingly difficult as the number of wallet-provider increases, particularly for novice users. Additionally, if decentralized applications pick and choose only a handful of wallets to support, the current incumbent wallets will have a distinct advantage and new wallets will struggle to find adoption. This will create a less competitive environment and stifle innovation. Rather than relying on the user choosing which wallet-provider to connect with (as does Web3Connect), ENSLogin proposes to use user-owned ENS domain as entry points. Metadata attached to these ENS domains is used to detect which wallet-provider if used by the corresponding account.
That way, ENSLogin would allow any user to connect to any Dapp with any wallet, using a simple domain as a login.
The ENSLogin works as follow:
At this point, the app should process like with any web3 provider. Calling the enable() functions should ask the users for wallet specific credentials is needed.
This workflow is to be implemented by an SDK that Dapp could easily import. The SDK would contain the resolution mechanism and support for both centralized and decentralized storage solution. Wallet-provider specific code should NOT be part of SDK. Wallet-provider specific code should only be present in the external file used to generate the web3 provider.
Text entry resolution: A pointer to the code needed to instantiate the wallet-provider is recorded using the ENS support for text entries (see EIP-634). The corresponding key is enslogin (subject to change). If no value is associated with the key enslogin at the targeted domain, we fallback to metadata store on the parent's node with the key enslogin-default (subject to change).
Example: for the ens domain username.domain.eth, the resolution would look for (in order):
resolver.at(ens.owner(nodehash("username.domain.eth"))).text(nodehash("username.domain.eth"), 'enslogin')resolver.at(ens.owner(nodehash("domain.eth"))).text(nodehash("domain.eth"), 'enslogin-default')Provider link: Code for instantiating the wallet-provider must be pointed to in a standardized manner. This is yet not specified. The current approach uses a human-readable format scheme://path such as:
ipfs://Qm12345678901234567890123456789012345678901234https://server.com/enslogin-module-someproviderAnd adds a suffix depending on the targeted blockchain type (see SLIP 44) and language. Canonical case is a webapp using ethereum so the target would be:
ipfs://Qm12345678901234567890123456789012345678901234/60/jshttps://server.com/enslogin-module-someprovider/60/jsNote that this suffix mechanism is compatible with http/https as well as IPFS. It is a constraint on the storage layer as some may not be able to do this kind of resolution.
Provider instantiation:
global.provider: (config) => Promise<web3provider> that returns a promise to a standardized provider object. For EVM blockchains, the object should follow EIP-1193.Configuration object: In addition to the username (ENS domain), the Dapp should have the ability to pass a configuration object that could be used by the wallet-provider instantiating function. This configuration should include:
_) can be added to pass additional, wallet-provider specific, parameters / debugging flags.__) can be used to pass additional arguments.Minimal configuration:
{
provider: {
network: 'goerli'
}
}
Example of advanced configuration object:
{
provider: {
network: 'goerli',
ens: '0x112234455c3a32fd11230c42e7bccd4a84e02010'
},
ipfs: {
host: 'ipfs.infura.io',
port: 5001,
protocol: 'https'
},
_authereum: {...},
_portis: {...},
_unilogin: {...},
_torus: {...},
__callbacks: {
resolved: (username, addr, descr) => {
console.log(`[CALLBACKS] resolved: ${username} ${addr} ${descr}`);
},
loading: (protocol, path) => {
console.log(`[CALLBACKS] loading: ${protocol} ${path}`);
},
loaded: (protocol, path) => {
console.log(`[CALLBACKS] loaded: ${protocol} ${path}`);
}
}
}
TODO (maybe move that part to section 6.1):
Add SLIP 44 compliant blockchain description to the config for better multichain support. This will require a additional field ENS network to know which ethereum network to use for resolution when the targeted blockchain/network is not ethereum (could also be used for cross chain resolution on ethereum, for example xDAI login with metadata stored on mainnet)
Unlike solution like Web3Connect, ENSLogin proposes a modular approach that is decentralized by nature. The code needed for a Dapp to use ENSLogin (hereafter referred to as the SDK) only contains lookup mechanism for the ethereum blockchain and the data storages solutions. The solution is limited by the protocols (https / ipfs / ...) that the SDK can interact with. Beyond that, any wallet-provider that follows the expected structure and that is available through one of the supported protocol is automatically compatible with all the Dapps proposing ENSLogin support. There is no need to go through a centralized approval process. Furthermore, deployed SDK do not need to be upgraded to benefit from the latest wallet updates. The only permissioned part of the protocol is in the ENS control of the users over the metadata that describes their wallet-provider implementation. Users could also rely on the fallback mechanism to have the wallet-provider update it for them.
We believe ENSLogin's biggest strength is the fact that it aligns the incentives of Dapp developers and wallet-providers to follow this standard.
While ENSLogin allows dapps to support any wallet for logging in, dapps still must choose which wallets they suggest to users for registration. This can be done through a component like Web3Connect or BlockNative's
TODO
| Name | Live | Module | Assigns ENS names | support by default |
|---|---|---|---|---|
| Argent | yes | no | yes | no |
| Authereum | yes | yes | yes | no |
| Fortmatic | yes | no | no | no |
| Gnosis Safe | yes | yes* | no | no |
| Ledger | yes | beta | no | no |
| KeepKey | yes | no | no | no |
| Metamask | yes | yes | no | no |
| Opera | yes | yes* | no | no |
| Portis | yes | yes | no | no |
| SquareLink | yes | no | no | no |
| Shipl | no | no | no | no |
| Torus | yes | yes | no | no |
| Trezor | yes | no | no | no |
| UniLogin | beta | beta | yes | no |
*use the metamask module
TODO
ENSLogin only has access to what is recorded on the ENS, namely your address and the provider you use. Private key management is a is handled by the provider and is outside ENSLogin's scope. Some might store the key on disk. Other might rely on custodial keys stored on a remote (hopefully secure) server. Others might use a dedicated hardware component to handle signature and never directly have access to the private key.
TODO (this might need a separate ERC)