There’s some awesome work happening in WP1 to bring to life the concept of identity management in Status. As part of this, Andrei will also explore new onboarding flows, some of which will incorporate ENS registration.
Before going too deep, I think we should consider EIP1078 universal login. This proposal would allow users to access any compatible DApp with a single username (and no seed phrase!).
The gist of it is…
User creates a new account by registering an ENS name.
A proxy contract is created for them; the ENS name points to this contract.
User’s device generates a private key to control the contract locally.
User does not need a seed phrase or password to access the account.
Instead, they authorize additional logins using their ENS name and verifying with their device, similar to 2fa.
The private keys only sign messages; it’s the contract that holds the user’s funds.
User controls the level of privilege for each DApp they log in to.
Backup phrases can be generated for recovery.
You can watch Alex van de Sande demo this in action here.
From a UX perspective, this would mean that a new user either connects an existing account or creates one by registering an ENS name on the spot.
It eliminates the need for seed phrases and instead lets the user access their wallet with their ENS name and device. It encourages ENS registration, which is in many ways a plus.
It’s the strongest proposal for a simplified log in pattern that I’m aware of, and if we have any desire to implement this EIP, we should probably design further login/onboarding and identity work with it in mind.
That said, I’d love to hear a discussion of the pros and cons.
How can existing users be onboarded to this standard?
Can existing stateofus.eth names be made compatible with this?
Does a user have to create an ENS name to join Status if we adopt this? There are concerns about requiring a user to register a digital identity which we might be expected to track in certain countries.
+ Many other technical and security considerations I’m not touching on
First of all, awesome post I am in favour of Universal logins, but maybe as one among many options…
The top question that comes to mind is: how can we (if at all) make this work with keycard? The key point there being that the device is kinda always an adversarial environment, and chips are bad etc etc, and we can’t control that. Hence, we have the private key never touch the device at all, we decouple what other keys we can, and I can see how that fits neatly into the work on identity that Andrei is doing. Would it be possible to use Universal Logins, but have the key generated on the card while touched to the phone during registration? That would be interesting but likely not too easy… Plus, how would you complete the “2fa” on other devices like desktop etc with your card? Hence why I suggest maybe as one among many options?
I’m also unclear on whether stateofus.eth (isn’t it statusnet.eth?) would work if we went with this and would like more clarity there.
Also, if it were one among many options, then that’d give real meaning to working on it as the first few components for something like Lorikeet (i.e. just the log in flow, that then feeds into each project’s platform with their own styles and all Andrei’s work, in our case), so that Aragon, Bounties Network and Status could all implement it at the same time using the same components, and then we get the best of both worlds. Just a thought…
I don’t think it completely removes the seed phrase as the Management Key might be want to be saved by users, but Friends Recovery would mitigate the problem of locking yourself out of the Identity.
ENS Usernames is launched and in active development, Gas Abstraction is in active development and will be installed in Ropsten in next few days.
Identity contracts are the most complicated part, because we need to provide a model is interoperable with future Dapps and that will not need to be updated in future, or that will be able to be upgraded on demand. Also they are fairly big and medium complex contracts which would need extensive audit before Mainnet release.
Regarding the ens domains, statusnet.eth domain is used for official Status Network Dapps, while stateofus.ethis used for user profiles, the difference is purposed to avoid scams on user arbitrary names - imagine that someone could register coolfeature.statusnet.eth is more scammy then coolfeature.stateofus.eth, and allows Status to better understand if user is browsing a trusted dapp (statusnet.eth domain) or a user arbitrary Dapp/profile (stateofus.eth). Also the list of reserved names in ENS Usernames are specifically to mitigate scams, and they can be changed by upgrading the contract (even to erase bad usernames or to release wrongly reserved names).
This Identity Contracts would be “optional” for using the Dapp, and users would be incentivized to buy SNT and enhance the UX and Security.
This Identity Contracts don’t solve Privacy, they have same privacy as regular addresses, and as regular addresses, users should be able to have as many Identities as they want to.
Additional use cases of Identity for Status can come with “Claims”, e.g. Status GmbH could issue a Claim for all it’s core-devs and:
the Public Chats could filter messages from Identity that have certain Claims, users could enable to “bold” this Identity’s messages, hide them, or only show with particular claims.
Tribute-to-talk could be not required for users containing certain claims.
Opinion Voting could be analyzed on claims instead of balance. .
Pros are the features it enable
Cons are the aggregated learning curve and embedded cost of install the Identity (~ 100.000 gas for a conversion, payable in SNT or ETH).
Thanks for the excellent write up explaining the gist of Universal Login @rachel.
My early impression:
I am definitely excited about the promise of Universal Logins. Not sure if we are ready though. Should Friends recovery and alternative authentication (fingerprint) come first?
ENS names in onboarding could boost connections; not sure if we need universal login for this though. My theory is that anyshareable identity included in onboarding could boost connections. I would not say we need people to create an ENS user name to achieve this.
What does Universal Login mean for logging into different applications? Would I be able to use the same ENS name for Status, Metamask, Toshi in other words: can an ENS name on one app approve a request of another or is this limited to the same application on different devices?
I do find that the name Universal login sets, seemingly inaccurate, expectations for me.
e.g. I would expect a one-tap login into all DApps. But I don’t think this is what it would support. As it is there are still quite a few DApps for which I need to create an account after or before sharing my public key. At least some also don’t seem to recognize that they are used within Status (e.g. Oasis Direct refers to the Status download link).
Thanks for the feedback guys! I heard there was some early exploration for universal login components happening in the Lorikeet project, @cryptowanderer. True?
Good to know that we can offer identity contracts for users who have already registered stateofus names, and there are many potential privileges that come with having one.
I joined a call with Hester, Corey and Alex Van de Sande to talk more about it today. Corey took great notes.
Apart from key card compatibility issues, our biggest concern is Ricardo’s point that these contracts have the same privacy as regular addresses. An identity contract would expose information about your wallet (and so would the ENS name).
We also want to see other teams’ interpretations of this work. Coming out of the call, we decided to put universal login on the design team radar as something to explore in the next few months, in tandem with another team so that we can collaborate on user testing.
The idea is, since if i understand it correctly, there’s no password in this scenario, we might add a 6-digit passcode + face/touch id. Also it might be nice to provide alternative methods for signup, such as our current method – just a regular account with a password.
Not sure about other types of accounts in this scenario. Would appreciate help with creating a list of all possible account types we would like to support in the closest future
Super cool Andrei! I left a few comments. Our biggest challenge for ENS registration during onboarding will be that stateofus.eth names cost 10 SNT. I’m not sure what the best solution would be, as new users don’t have SNT, but left some thoughts. I expect other apps might offer usernames for free.
Account types in this scenario:
recovered existing account tied to a private key - the account I have today
new account tied to a private key - password sign-up option
universal login account generated by other apps
universal login account generated on Status
Main difference between 3 & 4 on the front end would be the user’s ENS domain (otherapp.eth vs. stateofus.eth).
Just to be clear, Ricardo did alot of the early work of ‘universal logins’ before it was called universal logins, and large portions of it already exists within our repos, as Ricardo pointed out in his post
@petty he is listed in the swarms because Status and Mist become interoperable and work for all dapps, and invited me to talk in gas abstraction round table, which I explained why and what Status plans to do regarding the Gas Abstraction.
Universal Logins is a self sovereign account service for DApps, the base is the account contract (Identity.sol/ERC725).
Gas abstraction is fundamental for Universal Logins, because it enable keys without any funds to interact with blockchain.
This is possible through a network of “gas relayers”, which either are accounts funded with ETH or block validators (a.k.a. miners), willing to include this signatures inside a call to the correct smart contract, because is incentivized by this contract paying this “gas relayer” a value it can predict.
The gas abstraction could be improved in term of overhead cost if EVM allowed chaper calls which don’t check msg.signer (but cannot use it), and can only be called by block validator (having only the block.coinbase).
The main advantage for Universal Logins is the capability of a Desktop Browser request signature to a Mobile Status, without having prior configuration then entering your ens username into the browser.
This could be used even inside the mobile browser, making possible to deprecate the need of a browser inside Status (depends on ens domain resolution supported in that browser).
and instead lets the user access their wallet with their ENS name and device. It encourages ENS registration, which is in many ways a plus.
I am in favour of Universal logins, but maybe as one among many options…
but likely not too easy… Plus, how would you complete the “2fa” on other devices like desktop etc with your card? Hence why I suggest maybe as one among many options?