Why Universal Login isn’t working — this might

Once people started exploring non-financial uses for the blockchain, the idea of identity in Web3 became a frequent topic of discussion.

It naturally lent its way to be used on the web as a form of “Universal Login”, where one identity lets you access all websites. This article will break down why this is a bad idea. A hint: the bad part of Universal Login is not the “universal” aspect, nor doing away with the passwords, but rather, the “login” aspect.

Update: UniLogin, one of the key proponents of Universal Login has just announced they will be closing doors. Gas prices and DeFi gentrification, alongside ongoing changes in browser privacy, meant reduced utility of browser local storage. Read more in their blog.

In Sydney, and back when COVID-19 was not that global health concern/crisis that it is now, Bokky operated a “bring-your-own-beer” blockchain workshop where they would explain the cryptography behind the blockchain. I remember the surprise on the workshop participants’ faces when, on one occasion, a lecturer concluded that any cryptographic signing can be used for two-party authentication, such as logging in to a website.

‘So, could we just log in with our Ethereum address, instead of typing a password?’ one participant asked.

‘Yes,’ the lecturer replied. ‘Or, you could derive a key from your Ethereum key, to hide your real address from a website. And if you derive all the keys from one source, you’ll get a “universal login” — one key that opens all doors.’

Upon hearing this from the lecturer, the workshop’s participants fidgeted with excitement. I can only imagine what similar eye-opening experiences occurred in other cities and similar settings throughout the world.

The rising tide of crypto authentication

As the lecturer correctly stated, the mechanism at work behind “Universal Login” is cryptographic authentication. It’s an idea that has been tried every decade since the Web began.

Today, people hail W3’s Web Authentication API — a 2020 specification on the use of this technology for logging in — as a pioneer, but it’s not new. W3’s first crack on it was called “WebCrypto API”, released in 2014. It remains relatively unknown.

The little-known <keygen> HTML form element has existed since 2008 for the same public-key web login purpose… but saw no website using it. It came to the show as part of HTML5. As of today, most major browsers have disabled that element in their spring cleaning of unused features. A grand birth, followed by a quiet death.

Cryptography has enamored me since childhood, and I can’t help but be amazed at people getting excited over different iterations of the same cryptographic technology, hoping that this time it will be different.

It sure would be a miracle if that technology worked this time. Unless…

…What if there are new use-cases? Like in early 2008, where Web2.0 use-cases elevated AJAX technology that lay dormant for years?

New-use of the old cryptographic authentication

You might think, is there a new use case for web login at all? Before we delve into that, we should ask: Why must web authentication be about login?

It may seem like a silly question. Well, consider this: what’s the difference, really? Authentication is log in; logging in is authentication. They’re one and the same.

That’s not the case with Web3, though.

Today, blockchain users tend to believe that Web3 is going to become a Tokenised Web, where the user holds tokens from various decentralized components called Smart Contracts, doing away with today’s megacorps’ grip of the Web.

Let me show you the new use cases. Suppose we’ve already made this technological advancement. Suppose you have several tokens in your browser wallet. You visit an online store for video games.

You use proof of age — which is a function of an Identity Token — to access restricted games. As a result, the shop listings change. It’s already magical.

Then you use another token: Bundle Discount Token. It’s a subscription token developed by AAVE that grants discounts to many games. Deposit ◈100 DAI, and AAVE gives you 100 “Bundle-Tokens” that are slowly spent during your subscription. The online store recognizes these Tokens and instantly discounts many games.

You browse and decide on Animal Crossing, a popular Japanese game. You can pay with DAI, but the store knows you have some SUSHI tokens, and gives you an incentive: Pay with the value equivalent of SUSHI and get yourself a special fishing rod in-game item to get started on your adventure.

Paying grants you the Game Owner Token, which allows you to play your purchased video game on the platform(s) on which they’re available, such as Steam and Xbox.

This is all quite simple. There are no login gateways with passwords to input. There’s no “date of birth” form to fill. There are no restrictions on where you can purchase the video game. (For example, Humble Bundle ‌requires its users to purchase video games from their website. Users can also make subscriptions.)

But which step is the login step?

The answer is none. There is no login step. Traditionally, activities like getting a refund or a DLC would require an account, but that can be coded in the Game Owner’s token. Of course, the website still wants to use some loyalty mechanism. So, the website’s owners may decide to add a login option, and they may integrate that option through a token too (such as a brand-specific loyalty token).

But login is not necessary. I repeat: login is not necessary. The Token already elevated the trust relationship to go beyond the user-website pair.

But is Token a replacement of cryptographic authentication technology, zero-knowledge proof, and Universal Login?

When a user uses a token, what works under the hood is technologies like cryptographic authentication, zero-knowledge cryptography (e.g. for proof of age without leaking identity), proof of membership (e.g. when using the Bundle Discount subscription token). All these methods count as forms of authentication.

Tokens can be used across a range of accepting websites, so it’s already “Universal”.

Will websites willingly give up the login?

They don’t need to, and the success of tokens will not depend on sites owners’ willingness to do away with login. I merely point out that login doesn’t have to be the focus of Web3 evolution.

Let’s say you are behind the AAVE team creating the Bundle Discount subscription token. You do not need the game stores to give up their login, only that they accept your token to work on their website. The same crypto magic behind “Universal Login” or “Web Authentication” is still at work when the user uses the bundle token on such websites.

How do we get there?

The mechanism at work is the negotiation between the website and the user, on the use of tokens. For lack of a better term, I refer to this process as “Token Negotiation”.

“Token Negotiation” is the name we gave for the corresponding TokenScript technology. If you’ve never heard of it before, allow me to introduce it — TokenScript is a technology that supports Web3. In other words, it allows you to use tokens on websites, doing the necessary cryptography and blockchain magic in the background. Though it’s a work in progress, many parts of it already allow one to develop tokens for use in users’ wallets.

A brief introduction can be found on the TokenScript website and example code/projects are in the making.

To participate in this work in progress:

• TokenScript Forum
• Participate in the weekly design meeting every Friday at 7 pm Sydney time.
• Browse the TokenScript project website which contains links to the Github repos.
• A TokenNegotiation test case is still in a pull-request — will update this post when it’s approved.
• An example for Devcon Tickets.