Skip to main content

From Passwords to Portable Proofs: A 2025 Builder’s Guide to Web3 Identity

· 10 min read
Dora Noda
Dora Noda
Software Engineer

Most apps still anchor identity to usernames, passwords, and centralized databases. That model is fragile (breaches), leaky (data resale), and clunky (endless KYC repeats). The new stack emerging around decentralized identifiers (DIDs), verifiable credentials (VCs), and attestations points to a different future: users carry cryptographic proof of facts about themselves and reveal only what’s needed—no more, no less.

This post distills the landscape and offers a practical blueprint you can ship with today.

The Shift: From Accounts to Credentials​

The core of this new identity stack is built on two foundational W3C standards that fundamentally change how we handle user data.

  • Decentralized Identifiers (DIDs): These are user-controlled identifiers that don’t require a central registry like a domain name system. Think of a DID as a permanent, self-owned address for identity. A DID resolves to a signed “DID document” containing public keys and service endpoints, allowing for secure, decentralized authentication. The v1.0 standard became an official W3C Recommendation on July 19, 2022, marking a major milestone for the ecosystem.
  • Verifiable Credentials (VCs): This is a tamper-evident, digital format for expressing claims, like "age is over 18," "holds a diploma from University X," or "has passed a KYC check." The VC Data Model 2.0 became a W3C Recommendation on May 15, 2025, locking in a modern foundation for how these credentials are issued and verified.

What changes for developers? The shift is profound. Instead of storing sensitive personally identifiable information (PII) in your database, you verify cryptographic proofs supplied by the user’s wallet. You can request only the specific piece of information you need (e.g., residency in a specific country) without seeing the underlying document, thanks to powerful primitives like selective disclosure.

Where It Meets the Logins You Already Use​

This new world doesn't require abandoning familiar login experiences. Instead, it complements them.

  • Passkeys / WebAuthn: This is your go-to for phishing-resistant authentication. Passkeys are FIDO credentials bound to a device or biometric (like Face ID or a fingerprint), and they are now widely supported across all major browsers and operating systems. They offer a seamless, passwordless login experience for your app or wallet.
  • Sign-In with Ethereum (SIWE / EIP-4361): This standard lets a user prove control of a blockchain address and link it to an application session. It works via a simple, signed, nonce-based message, creating a clean bridge between traditional Web2 sessions and Web3 control.

The best practice is to use them together: implement passkeys for mainstream, everyday sign-in and offer SIWE for wallet-linked flows where a user needs to authorize a crypto-native action.

The Rails for Issuing and Checking Credentials​

For credentials to be useful, we need standardized ways to issue them to users and for users to present them to apps. The OpenID Foundation provides the two key protocols for this.

  • Issuance: OpenID for Verifiable Credential Issuance (OID4VCI) defines an OAuth-protected API for getting credentials from issuers (like a government agency or a KYC provider) into a user's digital wallet. It’s designed to be flexible, supporting multiple credential formats.
  • Presentation: OpenID for Verifiable Presentations (OID4VP) standardizes how your application makes a "proof request" and how a user's wallet responds to it. This can happen over classic OAuth redirects or through modern browser APIs.

When building, you’ll encounter a few key credential formats designed for different ecosystems and use cases:

  • W3C VC with Data Integrity Suites (JSON-LD): Often paired with BBS+ cryptography to enable powerful selective disclosure.
  • VC-JOSE-COSE and SD-JWT VC (IETF): These formats are built for JWT and CBOR-based ecosystems, also featuring strong selective disclosure capabilities.

Fortunately, interoperability is improving rapidly. Profiles like OpenID4VC High Assurance are helping to narrow the technical options, making cross-vendor integrations much saner for developers.

DID Methods: Picking the Right Address Scheme​

A DID is just an identifier; a "DID method" specifies how it's anchored to a root of trust. You’ll want to support a couple of common ones.

  • did:web: This method backs a DID with a domain you control. It’s incredibly easy to deploy and is a fantastic choice for enterprises, issuers, and organizations who want to leverage their existing web infrastructure as a trust anchor.
  • did:pkh: This method derives a DID directly from a blockchain address (e.g., an Ethereum address). This is highly useful when your user base already has crypto wallets and you want to link their identity to on-chain assets.

Rule of thumb: Support at least two methods—did:web for organizations and did:pkh for individual users. Use a standard DID resolver library to handle the lookup, and consult official registries to evaluate the security, persistence, and governance of any new method you consider adding.

Useful Building Blocks You Can Plug In​

Beyond the core standards, several tools can enhance your identity stack.

  • ENS (Ethereum Name Service): Provides human-readable names (yourname.eth) that can map to blockchain addresses and DIDs. This is an invaluable tool for improving user experience, reducing errors, and providing a simple profile layer.
  • Attestations: These are flexible, verifiable "facts about anything" that can be recorded on-chain or off-chain. The Ethereum Attestation Service (EAS), for example, provides a robust substrate for building reputation and trust graphs without ever storing PII on a public ledger.

Compliance Tailwinds You Should Track​

Regulation is often seen as a hurdle, but in this space, it’s a massive accelerator. The EU Digital Identity Framework (eIDAS 2.0), officially adopted as Regulation EU 2024/1183 on May 20, 2024, is the most significant development. It mandates that all EU Member States offer citizens a free EU Digital Identity Wallet (EUDI). With implementing regulations published on May 7, 2025, this is a powerful signal for the adoption of wallet-based credentials across both public and private services in Europe.

Even if you don't operate in the EU, expect the EUDI Wallet and its underlying protocols to shape user expectations and drive wallet adoption globally.

Design Patterns That Work in Production (2025)​

  • Passwordless First, Wallets Optional: Default to passkeys for sign-in. It's secure, simple, and familiar. Only introduce SIWE when users need to perform a crypto-linked action like minting an NFT or receiving a payout.
  • Ask for Proofs, Not Documents: Replace clunky document uploads with a crisp VC proof request using OID4VP. Instead of asking for a driver's license, ask for a proof of "age over 18" or "country of residence is X." Accept credentials that support selective disclosure, like those using BBS+ or SD-JWT.
  • Keep PII Off Your Servers: When a user proves something, record an attestation or a short-lived verification result, not the raw credential itself. On-chain attestations are a powerful way to create an auditable record—"User Y passed KYC with Issuer Z on date D"—without storing any personal data.
  • Let Orgs Be Issuers with did:web: Businesses, universities, and other organizations already control their domains. Let them sign credentials as issuers using did:web, allowing them to manage their cryptographic keys under their existing web governance models.
  • Use ENS for Names, Not Identity: Treat ENS as a user-friendly handle and profile pointer. It's great for UX, but keep the authoritative identity claims within credentials and attestations.

A Starter Architecture​

Here’s a blueprint for a modern, credential-based identity system:

  • Authentication
    • Default Login: Passkeys (FIDO/WebAuthn).
    • Crypto-Linked Sessions: Sign-In with Ethereum (SIWE) for wallet-based actions.
  • Credentials
    • Issuance: Integrate with OID4VCI endpoints from your chosen issuers (e.g., a KYC provider, a university).
    • Presentation: Trigger OID4VP proof requests from your web or native app. Be prepared to accept both W3C VCs (with BBS+) and SD-JWT VCs.
  • Resolution & Trust
    • DID Resolver: Use a library that supports at least did:web and did:pkh. Maintain an allowlist of trusted issuer DIDs to prevent spoofing.
  • Attestations & Reputation
    • Durable Records: When you need an auditable signal of a verification, mint an attestation containing a hash, the issuer's DID, and a timestamp, rather than storing the claim itself.
  • Storage & Privacy
    • Minimalism: Drastically minimize the PII you store server-side. Encrypt everything at rest and set strict time-to-live (TTL) policies. Prefer ephemeral proofs and lean heavily on zero-knowledge or selective disclosure.

UX Lessons Learned​

  • Start Invisible: For most users, the best wallet is the one they don’t have to think about. Use passkeys to handle sign-in seamlessly and only surface wallet interactions contextually when they are absolutely necessary.
  • Progressive Disclosure: Don't ask for everything at once. Request the smallest possible proof that unblocks the user's immediate goal. With selective disclosure, you don't need their full document to verify one fact.
  • Key Recovery Matters: A credential bound to a single device key is a liability. Plan for re-issuance and cross-device portability from day one. This is a key reason modern profiles are adopting formats like SD-JWT VC and claims-based holder binding.
  • Human-Readable Handles Help: An ENS name is far less intimidating than a long hexadecimal address. It reduces user error and adds a layer of recognizable context, even if the true authority lives in the underlying credentials.

What to Ship Next Quarter: A Pragmatic Roadmap​

  • Weeks 1–2:
    • Add passkeys for your primary sign-in flow.
    • Gate all crypto-native actions behind a SIWE check.
  • Weeks 3–6:
    • Pilot a simple age or region gate using an OID4VP request.
    • Accept VC 2.0 credentials with selective disclosure (BBS+ or SD-JWT VC).
    • Start creating attestations for "verification passed" events instead of logging PII.
  • Weeks 7–10:
    • Onboard a partner issuer (e.g., your KYC provider) using did:web and implement a DID allowlist.
    • Offer ENS name linking in user profiles to improve address UX.
  • Weeks 11–12:
    • Threat-model your presentation and revocation flows. Add telemetry for common failure modes (expired credential, untrusted issuer).
    • Publish a clear privacy posture explaining exactly what you ask for, why, how long you retain it, and how users can audit it.

What’s Changing Fast (Keep an Eye on This)​

  • EU EUDI Wallet Rollouts: The implementation and conformance testing of these wallets will massively shape capabilities and verification UX across the globe.
  • OpenID4VC Profiles: Interoperability between issuers, wallets, and verifiers is constantly improving thanks to new profiles and test suites.
  • Selective Disclosure Cryptosuites: Libraries and developer guidance for both BBS+ and SD-JWT VC are rapidly maturing, making them easier to implement.

Principles to Build By​

  • Prove, Don’t Store: Default to verifying claims over storing raw PII.
  • Interoperate by Default: Support multiple credential formats and DID methods from day one to future-proof your stack.
  • Minimize & Disclose: Ask for the smallest possible claim. Be transparent with users about what you are checking and why.
  • Make Recovery Boring: Plan for device loss and issuer rotation. Avoid brittle key-binding that strands users.

If you’re building fintech, social, or creator platforms, credential-first identity isn’t a future bet anymore—it’s the shortest path to lower risk, smoother onboarding, and global interoperability.

Share on Twitter