Your keys are not your SSO

Web3 is still looking for its prominent use case, but in the fever of the last two years, people in this area claimed that it solves a lot of existing problems.

One problem claimed to be solved by web3 tech is single sign-on and broader authentication on the Internet.

The enthusiastic point of view is that we can use web3 wallets and use them as a universal "identity" to access applications.

"Identity" is a much broader topic; I will not focus on it here. Still, I want to cover the usage of wallets as a solution to SSO/authentication problem.

My point of view is:

• Crypto wallets do not bring anything new to the table in this area
• web3 approach replicates the same issues and problems we had before
• With the same problems, it seeks solutions, which were already provided, re-creating existing technology pieces.

The biggest thing is that in doing those things, the work done before on open authentication and identity-related standards was often ignored or rejected by not being "decentralized."

In the last few months, the last piece has improved as with money heat being a bit cooled down, people started to focus on the tech, not the "floors." Probably they found out that not only "blockchain" shines.

It isn't an "anti web3" piece.

Over the years, my experience in the industry proved that the solutions are based on open, cross-platform protocols and primitives, which can then be re-used by the players in the tech.
It also showed that work on such is long, challenging, requires a lot of coordination, and doesn't provide quick solutions which can be monetized in the short run.

Yet, it is rewarding.

In this area, we will also land on something like this.

Disclaimer
I might and likely be mistaken on many points. Writing it down here, to have a point of reference in discussions and revisit it and update it every time I learn something new in this area.

It is technical opinion piece. I don't provide here deep technical discussion into those topics and I know, some people are "shortcuts."

Meet the wallet

No. Not Metmask or Ledger. Let's look at the underlying primitives.

web3 credentials are nothing else than asymmetric keys. You have the public and private keys, where the private key is what you need to protect.

This tech is well known, has worked for years, and is proven. Good that we are building on it.

Keys need to be stored somewhere and protected. That was always an issue with keys, even in a physical space.

Here comes the "wallet." What you see below is a smart card. A smart card is what you call in web3, and crypto-currencies tech is a "hardware wallet".

Smart card:

• Stored the private key(s)
• Protects access to it (hardware + knowledge element like PIN)
• Allows some crypto operations to be performed using the private key without this key leaving the device. Those operations are, for example, signatures.

Smart cards are well known. People use them for dozens of years. Every operating system, such as Windows, Mac OS, Linux, and Unix, knows how to handle one.

Every browser will allow you to use a smart card to access a website.

Smart cards don't have to be a card. I use the USB "smart card" for my official, government-issued "keys" for signatures.

Those are USB dongle that hold a SIM card, which stores the keys.

Yes! You carry a smart card on your phone. There were country-wide rollouts of keys where mobile phones were used as 'wallets.'

Software or hardware wallets you use for cryptwallets are in a nutshell smart cards. Different implementation and build to interact with ledgers, but the tech and purpose is the same.

The keys and "identity."

The key is not your "identity."

In technical terms, keys generated for your wallet are credentials. Credentials are something you present to the party to prove that you "own" the credentials which were earlier registered as the ones belonging to you.

It actually says nothing about the "identity." It proves that the person making an action has control over "credentials."

That's it.

If someone else takes over your keys, it doesn't mean it becomes you, but it can operate with your keys in places where you have registered them as credentials.

Common language, aka protocol

To use the keys, you need a lock. The lock needs some mechanism to know your key. It is how it works in the physical realm.

In the digital realm, we use protocols to make it work between the involved parties. The protocol is a definition of communication between the parties (flow, messages, elements, data, responses), allowing me to talk and be understood in a certain way.

The protocol ensures that parties can build things independently, yet it will work if they follow the protocol.

That's like IT industry 101.

In the authentication and authorization (more on those two later) context, we (as an industry) have worked hard to make it complicated and then simplify again.

Agreeing between vendors and providers on something people perceive as so sensitive (credentials, how those are verified, and how the proof of it flows across the Internet) is hard.

People always tended to "hack" some existing things to "use them" as protocols. The best examples from the past are LDAP and OAuth.

LDAP is a directory query protocol that was and still is abused for authentication purposes.
OAuth is resources access authorization protocol, which, with the advent of web 2.0, was (and still is) used for authentication.

Why abused?

None of those is an authentication protocol and doesn't have a way of telling you anything useful about the user or the way it has proven its credentials.

You can assume some things from how the protocol works, but it is your assumption, and it doesn't have to be correct.

In the world outside of Web 3.0 over a long time, work got us to the OpenID Connect protocol and work on standards like WebAuhN to ensure proper authentication flow over the web.

OpenID Connect (OIDC), as an example, allows different credentials to be used, so you can use your wallet keys as credentials and later follow the OIDC flow.

It works! Examples like cryptoauth.io prove that OIDC can work this way with cryptocurrency wallets.

web 3.0 goes OAuth way

For some unknown reason, web 3.0 decided to repeat mistakes made with OAuth and called it "Sign with Ethereum."

Why mistakes?

It uses some behaviors and mistakes it for the protocol.

Yes, you can sign the transaction with your keys.
Yes, it proves that you have access to those keys.

The content of the transaction can be crafted by a site to tell it something about the user (in the end, they need a wallet address).

The thing that each side decides is that this sign-in transaction has a bit different message in it (yes, it can be standardized), that you don't know what and how the user did the authentication piece ... it all repeats mistakes from OAuth in the early days of web 2.0.

That's the least disturbing thing (yet, I think it will bite people later).

Authentication is hard; authorization is even harder

Accessing resources, you have two processes happening.

Authentication proves that you have the necessary credentials and can use them either to register with a site or that you have registered (or someone did it) with this site before.

Authorization is the process of determining and confirming that you can perform given action.

In the case of using the wallet to sign in to the app or site, both are mixed: to connect the wallet to the site, you are signing a transaction with some specific messages.

Why does it not have to be right? Is it a problem?

Promoting wrong behavior!** User gets in a habit of signing the transactions with the wallet without thinking about it (yet another site I want to try).

Space for abuse! Because it is a transaction, it grants access and confirms some operation. If an app or actor is malicious, they can trick you with it to sign the transaction to transfer your funds or grant some permissions you would not want to give them.

It isn't necessary! The moment you access a site, it isn't required to bind your keys to it. There are phases of your interaction. You sign in with some proof of possession of the keys, and then when you want to transact with it, you use your wallet and the keys to sign the transaction.
This pattern is used every day. Think about Amazon - you can browse it, add titles to the wish list, and you are not asked about your credentials.

The moment you want to purchase something or manage your device, you will be prompted to confirm that you are the one who owns the needed credentials to authorize the such transaction.

And ...

Privacy and common sense

Last but not least - it grants the website or app access to the user's state of possession. Transactions and everything connected with this wallet.

Think about it! If you were asked to provide your complete bank and credit card statement and log in to the site with pictures of cats, what would you think about it?

Be honest with yourself?

Would you generate those card statements and upload them to the website? Together with everything they can use to track also your future transactions?

Yet it is precisely what every web 3.0 user does when connecting to the website. The fact touching the wallet gives the app access to all transactions and related information associated with this wallet.

What is worse, you can't revoke this access. Once your wallet address is known to this site, the site can query and mine your transactions on their whim.

It would help if you also kept your identity separate from the wallet. When you connect your "true" self with this digital wallet address, your personal transactions are getting known to anyone.

I bet every web 3.0 user asked if they want to give to the world all their bank and credit card statements connected to their identity would say a big "NO."

OK, so what's the point of all of it

Because of all the reasons above, I don't think solutions like "Sign with Ethereum" are viable solutions to the single sign-on and "identity" problems of the Internet.

Technically, it isn't a protocol; it is connected to the specific platform or requires complex infrastructure to work across the platforms.

From an authentication and authorization point of view, it mixes them together and pushes wrong behavior patterns on users.

It is terrible for privacy and hard for personal operations security (persona OpSec). Suppose you want to keep the separation between sites and your activities. In that case, you must manage multiple addresses and ensure separation is maintained.

It is HARD!

It will eventually lead to the equivalent of password managers for wallets (ideas are already showing up).

At the moment, because it is hard, it leads to multiple cases of phishing and lost money through rouge transactions being put in front of the user or sites aiming to steal user keys.

That's the way forward?

The proper way forward is forging ahead of us as we speak, but here are a few of my ideas on where the focus should be.

Leverage existing tech and build on it

The reason it took 15yrs or more to develop things like OIDC is not that people were slow. It is hard to make it right and agree for people to work together on it.

Yet, it was done, and as it isn't the most shining thing on the Internet, it has an impact.

My idea is that we should build on top of it. Think about the flows needed and how to combine existing flows of OIDC and WebAuthN to work with crypto-wallets keys. Tech is there; it is more about the attitude of builders.

MetaMask, one of the leading wallets, could be an OIDC provider in a truly distributed way. web3 sites could adopt OIDC or WebAuthN as an authentication method and separate it from the transactions and authorization part.

Relay on authentication protocol using credentials for sign-in, then do a step-up auth for authorization if needed.

WebAuthN and a similar set of tech are addressing the phishing problem. Why not leverage it? How it could be adapted to the transaction level?

That's the way to move forward.

Focus on user experience and UX

User needs to know what they are doing. If the site requires authorization for the transaction, the user needs to visually see what they are signing up for.

There is a reason why every label on the planet uses similar signs to describe how you should wash your clothes.

The industry should work on a common visual language to describe the level of permissions granted to the site or in a specific transaction.

One of the lessons learned from the past is that UX matters greatly regarding the adoption, behaviors, and level of safety in authentication and authorization transactions.

The important thing - is the design for the three people at the table. The UX should be built with three actors in mind:

• Site
• User
• Mailcious actor.

The user must know he is interacting with a good site and actor. That's why the effort on passwordless auth and tech like FIDO2/WebAuthN was and is so important.

Design for interop and off/on-chain

Design for the scenarios which are on/off-chain. I want to use my credentials with apps working on-chain and off-chain. I want to store my credentials and present them for applications of a different sort.

It is a game of ecosystems; I get it. Designing for a single ecosystem to win is planning for failure.

Why was HTTP so successful? Because it wasn't HTTP for Mozilla Server and HTTP for Apache server but a standard. A protocol everyone could adopt and use it.

The moment you require one ecosystem to be a major one, to solve a problem in every ecosystem, you design for a failure in the long term or complicated infrastructure of bridges, patches, and glue-n-tape solutions.

Those are my conclusions.

Some of them are probably wrong. Getting out of my own bubble is always a problem (for all of us). Yet I'm trying to be open and explore various options.

The situation is getting in a better direction. After the initial "Sign with Ethereum solves identity problem on the Internet," I see more reasonable voices and work on the interop between the standards.

That's good.

Yet, the biggest obstacle to the proper solution is tribalism and the desire for the single ecosystem to win.

That's a topic for a separate write-up.