ensloginspecsnapshot14102019.md

eip	title	author	discussions-to	status	type	category	created	requires
	ENSLogin	Hadrien Croubois <hc@iex.ec>	https://ethereum-magicians.org/t/discussion-ens-login/3569	Draft	Standards Track	ERC	xx/10/2019	137 634 1193 2304

1. Abstract

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.

2. Motivation

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.

3. Description

3.1. Overview

The ENSLogin works as follow:

• Request an ENS domain from the user
• Resolve the ENS domain to retrieve (see EIP 137)
  • An address (see EIP 137)
  • A text entry (see EIP 634)
• Interpret the text entry and download the file it points to
• Evaluate the content of the downloaded file
• Return the corresponding object to the Dapp

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.

3.2. Details

• Text entry resolution: A pointer to the code needed to instanciate the wallet-provider is recorded using the ENS support for text entries (see EIP 634). The corresponding key is web3-provider (subject to change). If no value is associated with the key web3-provider at the targeted domain, we fallback to metadata store on the parent's node with the key web3-provider-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"), 'web3-provider')
  • resolver.at(ens.owner(nodehash("domain.eth"))).text(nodehash("domain.eth"), 'web3-provider-default')

• Provider link: Code for instantiating the wallet-provider must be pointed to in a standardized manner. This is yet not specified. The multicodec format, already used by ENS's contentHash (see EIP 1577) might be part of the solution. The current prototype uses a human-readable format scheme://path such as:

  • ipfs://Qm12345678901234567890123456789012345678901234
  • https://server.com/file.extension#fragment?query=args

• Provider instantiation: The file containing the wallet-provider's code should inject a function 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:

  • A body (common to all provider) that specify details like the targeted chain / the address of a blockchain node.
  • Wallet provider-specific fields (optional, starting with one underscore _) can be added to pass additional, wallet-provider specific, parameters/debugging flags.
  • SDK specific fields (optional, starting with two underscores __) can be used to pass additional arguments.

  Minimal configuration:

   {
   	provider: {
   		network: 'ropsten'
   	}
   }
  

  Example of advanced configuration object:

   {
   	provider: {
   		network: 'ropsten'
   	},
   	ipfs: {
   		host: 'ipfs.infura.io',
   		port: 5001,
   		protocol: 'https'
   	},
   	_authereum: {...},
   	_portis: {...},
   	_universallogin: {...},
   	_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}`);
   		}
   	}
   }
  

3.3. Decentralization

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/swarm/...) 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.

3.5. Incentives

We believe ENSLogin's biggest strength is the fact that it aligns the incentives of Dapp developers and wallet-providers to follow this standard.

• A wallet-provider that implements the required file and make them available will ensure the compatibility of its wallet with all Dapps using ENSLogin. This will remove the burden of asking all Dapps to integrate their solutions, which Dapps are unlikely to do until the wallet as strong userbase. Consequently, ENSLogin will improve the competition between wallet-providers and encourage innovation in that space
• A Dapp that uses ENSLogin protocol, either by including the ENSLogin's SDK or by implementing compatible behaviour, will make itself available to all the users of all the compatible wallet. At some point, being compatible with ENSLogin will be the easiest to reach a large user-base.
• ENSLogin should be mostly transparent for the users. Most wallet provider will set up the necessary entries without requiring any effort from the user. Advanced users can take control over the wallet resolution process, which will be simple once the right tooling is available.

3.6. Drawbacks

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

4. Prototype

5. Support by the community

5.1. Adoption

Name	Live	Module	Assigns ENS names	support by default
Argent	yes	no	yes	no
Authereum	no	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
Torus	yes	yes	no	no
Trezor	yes	no	no	no
UniversalLogin	no	no	yes	no

*use the metamask module

6. Possible evolutions

6.1. Multichain support

7. FAQ

7.1. Can anyone connect with my login? Where are my private keys stored?

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.

7.2. How do I get an ENS Login?

Signing up for [ToDo: Chris will write this tomorrow]