How to bridge the identity of Web2 users to Web3?

Reposted from official account: old yuppie

This article explores the question of how Web2 transitions into the Web3 ecosystem, and how identity plays an important role in this.

I think Web3 is here to stay for a while. By Web3 I mean philosophies, concepts and technologies that prioritize user choice and ownership and can be used to build decentralized services. Blockchains (e.g. Ethereum , Solana), tokens, protocols (e.g. IPFS, TheGraph, Lit), services (e.g. ENS, Filecoin), dApps and users’ keys make up Web3 (I didn’t list a single one here exhaustive list).

I don't know how successful it will be, and I don't think anything would be the case today. But I think it will work. I believe it has been successful in some ways.

I also think that Web3 is not the "only" web that exists. It will coexist with Web2, at least for several years (decades). I'm not the only one who thinks so.

After that, maybe another paradigm will emerge. As a developer, especially one who builds products for other developers, I spend a lot of time thinking about what this means. I thought it might be fun to share my thoughts in writing.

This article is mainly for:

• Developers who build Web2 applications that talk to Web3 services

• Developers building Web3 services intended to be consumed by Web2 applications

In this post, I link to the documentation and concepts of Ethereum because I am most familiar with these and it is the largest developer platform today. Similar things apply to many other chains.

Web2 applications using Web3 architecture

Web2 applications can enhance the user's experience through Web3 constructs.

——Shopify is diving into "tokengated commerce" to customize the shopping experience based on users' NFTs. Here's a very clear, in-depth article on the subject. Tokenized commerce is a wonderful idea. What you have says a lot about what you like. Customizing the shopping experience based on your NFTs feels natural. (
https://help.shopify.com/en-US/manual/products/digital-service-product/nfts)

— Twitter and Stripe are teaming up to allow cryptocurrency payments, making it easy for content creators to get paid in cryptocurrency. (
https://stripe.com/blog/expanding-global-payouts-with-crypto)

- Reddit is building its community points system on top of the blockchain. (
https://www.reddit.com/community-points/)

These are large consumer-facing platforms. They are not becoming dApps, but they are dabbling in Web 3.

What does this mean for developers?

Developers will need to figure out how to integrate the Web2 and Web3 worlds. We're already starting to see this play out in different ways, but companies creating developer tools and infrastructure are exploring and implementing Web3 integration.

• Stripe is building a Web3 payment infrastructure (https://stripe.com/use-cases/crypto)

• Auth0 announced support for Ethereum login (https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/)

• Google Cloud is building a Web3 team

Patterns: These large companies that built the Web2 development infrastructure are now creating components that allow Web2 app developers to easily integrate with Web3 concepts (NFTs, cryptocurrencies, ENS, etc.) dApps).

They are building a bridge between the Web2 and Web3 worlds. Their bridge is about allowing Web2 developers to interact with the Web3 fabric, which is the focus of this post.

Another aspect of bridging is making Web2 data available to Web3 developers. If this article gets developers interested, I might write another blog post on it.

Web3's Trust Model

The idea of Web3 is decentralization. Every user owns their data, their $tokens, etc.

Web3's trust model relies on asymmetric cryptography, where the source of trust is the user's private key.

While there are some use cases for delegation, the user will not typically choose a third party as a trusted representative, and delegation will be the user's choice.

For a bridge between Web2 and Web3 to exist, trust regarding ownership of user addresses must flow in both directions.

Identity is the structure of the bridge

At the end of the day, in the context of Web3, a user's address is their "identity". This represents who they are. So, they may have many identities of one kind or another, each a separate "identity" that they present in different contexts.

Bridging the Web2 and Web3 worlds means resolving identities on both sides of the bridge and enabling developers to easily build on top of it.

Of course, the principles of Web 3 should not be compromised when building bridges. We may need to adjust the Web3 identity protocol (like OIDC:
https://openid.net/connect/, OAuth 2: https://oauth.net/2/) and standard working methods to adapt to the needs and concepts of Web 3.

Everything starts with the address

A Web3 address has an associated private and public key.

The number of addresses is growing rapidly:

Ethereum Addresses (https://etherscan.io/chart/address)

But the number of active addresses grew more slowly:

Active Ethereum address https://etherscan.io/chart/active-address

From the graph above, we can deduce that the percentage of internet users actively using Ethereum addresses is low. Metamask said two months ago that they had 30 million monthly active users. But what about users who don't own addresses?

For Web3 to achieve mass user long-term adoption, there must be a paved path for mass user adoption. Not everyone is interested in the crypto world. A method that allows users to continue using the patterns they are used to (login with Facebook, Google, Twitter, etc.) and only realize later when they want to know about the blockchain (and keys) is extremely valuable .

While the number of addresses is growing extremely fast, a relatively small group of all internet users owns their private keys: either by creating key pairs offline, or via hardware wallets. Most of them exist in the form of "custodial wallets", and the keys are managed by service organizations. Centralized exchanges like Binance or Coinbase are the most common examples.

While this may not be "pure" from a Web3/decentralization perspective, it is very positive. It brings some of the ideas of Web 3 to the masses.

From a developer perspective, bridging the Web2 and Web3 worlds means hosting services must associate blockchain addresses with user accounts, securely manage keys, and provide controls (at least to other internal development teams) to manage Wallet interaction.

Services like magic.link, bitski, and venly are helping Web2 connect to the Web3 world, creating key pairs for typical Web2 login mechanisms, and providing APIs and UIs for developers to manage these private keys.

Once the user controls a private key, this is where the fun begins :)

log in with my private key

Let's take a look at a relatively simple scenario and see how it works in Web2 and Web3 applications. user:

• Recognized on one app.

• Change their avatar to {input A} and save.

• Realized they made a mistake in #2.

• Change their avatar to {input B} and save.

A Web3 application (dApp) allows users to "connect" one of their addresses. This operation essentially provides the browser with the user's blockchain address. There is no "backend" other than the blockchain and other decentralized services. Typically, operations that require authenticating a user on a Web3 component require signed information from the user's private key.

The Case for Web 3

With the Web2 protocol, users don't have to take action to prove their identity every time they operate. A user typically only needs to log in once, and the client/browser stores a credential and sends it to the backend on subsequent requests, which uses it to authenticate the user.

The Web 2 Case

The diagram above is oversimplified for the sake of point

The user experience of Web2 is better. Bridging the Web2 world and the Web3 world requires maintaining a Web2-like user experience, proving that the user controls the private key and intends to perform each specific action when calling the blockchain (or any other Web3-native service).

How do developers associate addresses with user accounts as part of a Web2 application?

The services mentioned in the previous section already associate private keys with user accounts. But what about the services that don't? What if the user uses Metamask, Argent, Trezor, or any other type of wallet?

This is the problem solved with Ethereum login (
https://eips.ethereum.org/EIPS/eip-4361). It allows a user to establish a session (in the Web2 sense) with a service, using their private key as a credential proving ownership of an address.

Image source: https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/

If this sounds interesting, you should follow @signinwitheth and @SpruceID.

And once a Web2 application knows that a user's blockchain address is a fact, it opens up a world of possibilities.

potential use cases

Once the user's Web3 identity is known, Web2 developers will naturally want to go further. This would mean:

• Read/write publicly available data related to addresses (such as on-chain data) and use it for business logic. We refer to these as "operations that do not require user authentication".

• Read/write data that requires authentication (such as a user's private video stored in decentralized storage or conducting on-chain transactions). Let's call these "operations that require user authentication".

Let's look at each in detail to understand how it works.

Operations that do not require user authentication

This is the simplest case. Developers will be able to call any API that requires an address and does not require authentication. Some use cases that come to mind are:

• Reads ENS (https://ens.domains/) or Unstoppable Domains (https://unstoppabledomains.com/) for profile data and displays it, which will be the "Global Public Username and Configuration" if the user chooses to have it File Picture" opens the possibility.

• Token access control is achieved by obtaining the user's POAPs and restricting access to resources based on these POAPs (https://poap.xyz/).

• Transfer assets to a user's on-chain address.

• Next step, if they go mainstream, use a service like Proof of Humanity to avoid fake user accounts.

Note that there are other ways to achieve some of these goals with digitally verifiable certificates, and these do not require public data. But that's a story for another article...

Operations requiring user authentication

Oh, things are starting to get tricky :) We're all used to dialogs like this.

If you want a Web2 app to access your Gmail data, you log in with Google and get a dialog to agree to the resources in the account you want the Web2 app to access.

How should this operate for Web 3 services? If your Web2 application wants to read data that exists in two different Web3 services.

• Should you "log in" them all at the same time?

• Or just agree to grant app permissions to both of them?

• What is the user experience like in each case?

In the context of a Web2 application, a token issued by an authentication server (Google in the previous example) is used to access Gmail's API (Gmail is the "resource server"). The web 2 application sends this token when it makes multiple calls to the API on behalf of the user. How should this operate in the case of Web3 services?

• Should users sign an agreement for every interaction with a Web3 service? It's not the best user experience...

• Should they delegate permissions to the application? How to entrust?

• How do Web3 services need to fit into these authorization situations?

The developers at Spruce have already started thinking about how to solve this challenge. I think it's a positive step forward. We need to understand use cases and real-world scenarios to generalize these cases into repeatable patterns/guidelines for all developers.

I think that's a big part of the challenge going forward.

Summarize

I'd be interested to know what you think about this as I'm actively thinking and trying to figure this stuff out. As part of my team's work at Auth0Lab, we are exploring how we can bridge the Web2 and Web3 worlds, not just in the context of one application, but in the context of providing tools for all developers.