Will dApps trigger the evolution of internet logins?
The crucial next steps if dApps & blockchain identities are to take hold
If I got an XRP every time I’d read ‘what will blockchain’s first killer dApp be?’ I’d still not surpass Chris Larsen’s pocket money. There’s no shortage of talent working in this space, great entrepreneurs and engineers but the closest we’ve come to the killer dApp is digital cats. Some are scratching their heads, some are looking into their Oracles. Why we can’t get anyone to use these dApps? This was supposed to be the new internet, where are the new email’s, Sims, Netscape’s and AOL’s of Web3?
My unsophisticated analysis is that we have many problems that revolve around access. Not unlike the internet early days with personal computers, dial-up, load-times etc. Arguably we’ve now got bigger barriers to clamber-up…
- It’s too complicated to purchase and hold crypto assets.
- It’s too complicated to manage public/private key, especially backups.
- We must overhaul the terminology into non technical talk.
- We must allow users to pay with credit cards on sites.
- We must allow users to access the same account from multiple devices.
- We must abstract the gas complexity and costs away from users.
- We can’t expose users to hexadecimal addresses.
The barriers above create frictions at Logins and payments which stop the average user accessing dApps.
These are two frictions (logins and payments) that we’ve been wrestling with for a while @ZINC, and issues we’ve been thinking about deeply. I’m going to explain our vision for the future of logins. DApps currently fall into 3 camps; firstly the fake dApp with old centralised email and password login. Secondly a true dApp with a key abstraction tool (Metamask or Mist etc required) or thirdly a mobile only dApp (Toshi or Cipher required). To have a desktop browser only dApp really complicates things. We’ve been theorising a solution at ZINC and Alex Van De San presented a more baked version of this same vision at Unconf. So thanks to Alex for solidifying these ideas and kudus to Ricardo Schmidt who’s been talking about this concept too. See the new EIP Alex has submitted — EIP 1078 which we support. I’m going to share our solution to the login problem by walking you through the ZINC first time desktop web login journey as a example use case for EIP 1078…
Step 1: The user Alice lands on ZINC.work and decides she wants to build a work identity so clicks on the dApp login page.
Step 2: Alice is requested to enter 1 field “username”, she enters AliceID and clicks sign-up.
Step 3: Alice is asked to take ownership of this account by scanning a QR code on her preferred DID mobile wallet (uPort, Civic, Boson.me, ZINC).
What’s going on behind the scenes?
~ When Alice enters a username and selects “Login or Signup” if she has an account Alice skips steps 2 & 3. This key is not sensitive and just a signing key so can be held in locally for instant login. If it’s a first time login an ENS subdomain to ZINC.eth (username) is created in steps 2 & 3.
~ When Alice enters her username a ENS subdomain is created AliceID.ZINC.eth with a simple Web3 call.
~ A new app specific set of keys are created to control this ENS name (username). It’s useful to think of these as signing keys not transactional/wallet keys.
We want to make this key pair the only one you’ll ever need. To make it accessible and useable we need it to be accessed across multiple devices, used for other dApps and able to attach data to it. Enter your identity contract >>
~ A identity contract is created (ERC725/1056) to attach the ENS name to and the keys that control the ENS name held in this contract.
~ We need a secure device to take over management of this identity contract. So when logged into uPort and the QR code is scanned the master keys in the mobile DID wallet take over management of the identity (ERC725) contract. You can relay funds from this secure wallet into the contract that can used to pay for services in the dApp. You can also pass work claims back through the identity contract then present attestations in other dApps from your mobile DID.
The Step 3 complexity is only presented by using web apps. We could skip this step using a mobile only dApp. However there is an added security benefit by having multiple keys and devices that could potentially recover the identity contract.
But is this better than the Web2.0 login systems?
- More secure? Yes.
- More flexible? Equally
- More convenient? Not yet.
- Easier to setup? From 2nd time login onwards ~ yes.
Email Vs Cryptographic Key Login
As it’s been well documented, we missed the identity layer off the last version of the web. Which has meant that we’ve shoehorned the humble old email into the public identity role for using applications. Strangely email was one of the first killer apps to take the web mainstream and it seems we’ve just settled for the first identity solution that was available. The problem with this is that email is good for sending large chunks or text and images. It’s not particularly secure, it’s very easy to spoof or hack. Hence we’ve only recently insisted on anchoring emails to slightly more secure devices in phone numbers. We can confidently say that cryptographic key pairs are a safer option, they are the option of choice to secure identity in well known secure government grade database systems such as Amazon IAM.
We get to solve the gas problem with some more ConsenSys magic. The application specific keys don’t have to hold any funds so they can be low security keys, even left unlocked locally. They are held in your identity contract so they can relay funds (tokens or Ether) from the identity contract. This means that when you need to send data and pay a fee you can essentially sign for an ‘I owe you’ with your identity contract as collateral. Alternatively the application itself can pick up the tab for the gas costs on certain actions and just ask the user to sign. The application specific keys can then just be used to sign messages for intent. Your application signing keys.
The user can enter or share the human readable and memorable ENS username anywhere to access cryptographic key pair account. Thanks to Nick Johnson for ENS and for solving the horrible hexadecimal address problem. This makes your keys as flexible and easy to share as an email address. Storing the keys locally in the browser means they equally as easy to access as emails. Signing up for a new dApp by scanning a QR code vs going to your email account to confirm your email is a similar level of work for the user. We don’t have to worry about losing our private keys anymore either. Since if we lose the ZINC specific app keys then we can generate new ones using the management keys in the ERC725 contract.
In my opinion we should not be using email as a secure login identity. Emails should be used as they were originally intended, as a communication medium. It should be the users choice if they wish to hand over a communication medium when using a dApp and not a necessity.
The primary differentiator then, is the extra security we get from cryptographic keys. So yes, this is a better login system. This is the bar we must aim for. This is the only way in which Web3 will take hold when the benefits to the user clearly outweigh the legacy Web2 alternatives.