On-Chain Identity: What a Web3 Passport Could Do

TLDR

A wallet can help someone sign in without creating another password. That proves control of a key, not necessarily a legal identity or a unique person. Web3 identity systems add credentials or attestations for claims that a wallet connection cannot establish on its own.

What users are used to in Web2

For most users, this is still the default experience.

Open a service.
Create an account.
Set a password.
Confirm email.
Upload documents.
Wait…

This repeats everywhere.

Different services.
Same steps.
Same risks.

Why this approach breaks for users

Each new service creates a separate version of you.

You end up with:

• multiple accounts

• duplicated personal data

• no visibility into where your data lives

One breach is enough to cause damage across everything.

The problem is not users.
The problem is the model.

The first improvement users already experienced

Then wallets entered the flow.

Instead of creating accounts, users started doing this:

Open a service.
Connect wallet.
Approve connection.
Use the service.

No password.
No email.
No new profile.

This already removed a lot of friction.

What wallet connections actually solved

When a wallet is connected, a service may learn the selected public addresses and networks. Authenticating control requires a separate verified signing flow.

A connection exposes selected account information.
A valid sign-in signature can authenticate control of an account.
Neither proves that its controller is a unique human.

What the service does not receive:

Password
Email
Personal documents

This can reduce:

• some account-creation friction

• password reuse

• endless registrations

Without users thinking about identity at all.

Where today’s wallet connections stop

Today, wallet connections mostly answer one question.

// Example sign-in question, not a transaction:
// Can you sign a challenge for this service and session?
// The service checks the signature, domain and nonce.
// This authenticates account control, not a unique person.

A verified signing flow can authenticate an account. It does not by itself establish a person’s identity or eligibility.

But real services often need more context.

What services still need to understand

In practice, many services need answers like:

Is the user allowed to access this?
Does this user meet basic requirements?
Is this interaction safe?

Today, this usually breaks the flow.

Wallet connected.
Please fill the form.
Please upload documents.
Please wait…

Which feels like going back to Web2.

The natural extension of the same flow

Instead of adding new steps, the existing flow can be extended.

// Possible credential flow; not a current Unitywallet feature:
// Connect wallet -> review a credential request
// Present only the required supported evidence
// Service verifies the evidence -> allow or deny access
// Exact steps and privacy depend on the implementation.

Some credential designs can limit repeated document sharing.
The actual data collected and disclosed depends on the implementation.

Same interaction model.
More useful decisions.

This is the key shift.

The Web3 passport model in simple terms

A Web3 passport is not a document.

It is the wallet acting as a decision layer.

Not everything about you.
Only what is required.

A service could ask for a specific credential.
The wallet or credential provider would need to support that request.

Only the required information should be requested, but privacy is not automatic. Public addresses and transaction histories can still be linked.

How WalletConnect fits into this picture

WalletConnect already provides the communication layer.

Service ↔ WalletConnect ↔ Wallet

WalletConnect carries supported requests between apps and wallets.
An eligibility flow needs additional supported methods, credential verification and user consent; connectivity alone does not provide them.

For the user, the flow stays familiar.

Connect.
Review.
Approve.

Only the meaning of the request evolves.

Where Unitywallet fits

Any identity feature in a wallet needs a defined scope: what claim is checked, which party attests to it and what information is disclosed.

Its role is different.

Unitywallet already provides a wallet interface. Identity-gateway features discussed here are a possible future direction, not a claim that document or uniqueness checks are currently available.

• a wallet users already control

• a place where future identity and security logic can live

• a neutral interface between users and services

As the ecosystem moves from actions to permissions,
wallets like Unitywallet become the natural place for this logic.

Not by forcing new flows.
By extending existing ones.

Why this is useful for users

For users, this evolution means:

Less repetition.
Less data exposure.
Less friction.

And more:

Control.
Clarity.
Predictability.

Identity checks could involve credentials presented through a wallet.
That still requires a defined verification system, consent and privacy safeguards.

Final takeaway

Wallet-based sign-in can simplify access, while credentials can support particular identity or eligibility checks. The trade-offs concern privacy, public address history, trust in issuers and recovery when access is lost.