Decentralized Identity (DID): Architecture, Cryptography, Authentication, Implementation, and the Next Layer of Digital Identity.

Most online identities are rented rather than owned.

A username belongs to a platform. An email address is controlled by a provider. A social account depends on the continued existence of a company. An OAuth identity is usually represented through a centralized identity provider. Even when the underlying cryptography is strong, the identity layer is often tied to an organization that controls registration, authentication, recovery, and account state.

Decentralized Identifiers, or DIDs, approach the problem from a different direction.

Instead of making a platform the permanent authority over an identifier, a DID can bind an identifier to cryptographic material controlled by its subject or controller. A DID can be resolved to a DID document containing verification methods, cryptographic keys, and optionally service endpoints.

The important distinction is that a DID is not a complete identity system by itself.

A DID gives an entity a persistent, verifiable identifier and a way to establish control of that identifier. Verifiable Credentials can then attach claims to that identity, and zero-knowledge proofs can add another layer by allowing those claims to be demonstrated without necessarily exposing the underlying information. W3C's Verifiable Credentials Data Model 2.0 became a Recommendation in May 2025. ()

That makes DID particularly interesting as a continuation of the zero-knowledge architecture discussed in the previous article.

The progression looks roughly like this:

Cryptographic Keys
│
▼
DID
│
▼
DID Document / Resolution
│
▼
Verifiable Credentials
│
▼
Verifiable Presentations
│
▼
Zero-Knowledge Proofs
│
▼
Privacy-preserving applications

This article breaks down that architecture from the protocol level to implementation details and then applies it to a real system: DecastID, an open-source decentralized identity manager built for the Decast ecosystem.

1. What Is a DID?

A Decentralized Identifier is a URI designed to identify a subject without requiring that identifier to be issued by a centralized identity provider. The subject can be a person, organization, device, software agent, object, or other entity.

A DID generally has this form:

did:<method>:<method-specific-id>

For example:

did:example:123456789abcdefghi

The important component is the method.

did: defines the general DID scheme, while a method defines how identifiers are created, resolved, updated, and deactivated. W3C explicitly treats the method as the mechanism that specifies those operations.

Conceptually:

did:decast:abc123
│ │ │
│ │ └── method-specific identifier
│ │
│ └───────── DID method
│
└────────────── DID scheme

A DID therefore does not mean:

It means something closer to:

That distinction is fundamental.

2. DID Is Not the Same Thing as Identity Data

One of the easiest mistakes when learning DID architecture is to think the DID itself contains all the identity information.

It usually should not.

Consider:

did:decast:abc123

That does not inherently tell a verifier:

Name: Anish Jha
Age: 27
Location: Delhi
Email:

Instead, the DID can resolve to a DID document containing information needed to verify control of the identifier.

A simplified DID document might look like:

{
"id": "did:example:123456789abcdefghi",
"verificationMethod": [
{
"id": "did:example:123456789abcdefghi#key-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "..."
}
],
"authentication": [
"did:example:123456789abcdefghi#key-1"
]
}

The W3C data model defines verification methods as mechanisms such as public keys that can be used to authenticate or authorize interactions involving the DID subject.

The separation is useful:

DID
│
├── Identifier
│
├── Verification methods
│
├── Authentication relationships
│
└── Optional services

Identity claims sit above that layer:

DID
│
└── Credentials
│
├── age
├── degree
├── employment
├── membership
└── ownership

This separation is what makes the architecture composable.

3. The Four Core Components

A practical DID system can be understood through four major components.

3.1 Identifier

The identifier itself:

did:decast:abc123

It needs to be unique according to its method rules.

3.2 DID Document

The DID document exposes the cryptographic and service information needed to interact with the identity.

Typical properties include:

id
controller
verificationMethod
authentication
assertionMethod
keyAgreement
service

The exact available properties depend on the DID Core model and extensions.

3.3 Private Key

The private key is what actually gives someone control.

This is the part that must remain secret.

DID
│
▼
Public Key
▲
│
mathematically
related to
│
▼
Private Key

A verifier does not need the private key.

It only needs the public key and a valid cryptographic proof that the requester controls the corresponding private key.

3.4 Resolver

A DID resolver converts:

did:decast:abc123

into a representation of its DID document plus resolution metadata.

W3C defines DID resolution as the process of taking a DID and resolution options and returning a DID document representation and metadata.

So:

Application
│
│ resolve DID
▼
Resolver
│
▼
DID Document
│
▼
Public Key / Services

The resolver is therefore an infrastructure component, not the identity itself.

4. Decentralized Does Not Mean Serverless

This distinction is important enough to state explicitly.

A DID system can still have servers.

Decentralization does not mean:

no servers

It means the identity model can be separated from dependence on a single centralized authority.

A DID method may use:

• a distributed ledger
• a content-addressed system
• DNS or HTTPS
• a registry
• a specialized network
• a method-specific service
• locally derived identifiers

Different methods make different tradeoffs.

The W3C specification intentionally defines a common DID data model rather than dictating a single storage or consensus mechanism. DID methods define their own creation, resolution, update, and deactivation operations.

This is why:

DID
≠
Blockchain

and:

Decentralized Identity
≠
Cryptocurrency wallet

Those systems can overlap, but they are not the same abstraction.

5. DID Methods

The word "DID" describes the common architecture.

The method determines how that architecture actually works.

Some commonly discussed methods include:

did:key
did:web
did:ion
did:pkh
...

The method controls questions such as:

How is a DID generated?
How is it resolved?
Where is its document stored?
Can the document change?
How are changes authorized?
How is the DID deactivated?
How is recovery performed?

This means a DID-compatible application still needs to understand the methods it intends to support.

A resolver is therefore usually method-specific or composed from multiple method implementations.

6. The Cryptographic Foundation

DID systems ultimately depend on a very simple principle:

Private key → produces signature
Public key → verifies signature

Suppose a verifier sends:

nonce = "8f2c9a..."

The holder signs:

signature = Sign(privateKey, nonce)

The verifier resolves the DID, obtains the public key, and checks:

Verify(publicKey, nonce, signature)

If verification succeeds, the verifier has cryptographic evidence that whoever produced the signature controls the private key associated with that DID.

This is much stronger than:

username + password

for certain use cases because the secret used for signing does not need to be sent to the verifier.

7. Why Nonces Matter

Never simply ask a user to sign the same static message repeatedly.

A signature over a static message can potentially be replayed.

Instead, use a challenge-response protocol.

For example:

Verifier
│
│ generate nonce
▼
Nonce
│
│ request signing
▼
Wallet / Extension
│
│ user confirms
▼
Signature
│
▼
Verifier

The nonce should be:

• unpredictable
• time-limited
• tied to the intended operation
• associated with the requester
• rejected after use

For example:

{
"nonce": "baf2d5...",
"audience": "https://decast.live",
"issuedAt": "2026-10-01T10:00:00Z",
"expiresAt": "2026-10-01T10:02:00Z"
}

The signer then signs a canonical representation of that challenge.

This pattern is also the basis of the authentication flow implemented by DecastID.

8. DID Authentication Architecture

A DID login can be modeled like this:

┌─────────────────────┐
│ Web App │
│ Verifier │
└─────────┬───────────┘
│
│ 1. Request login
▼
┌─────────────────────┐
│ DID Wallet / │
│ Browser Extension │
└─────────┬───────────┘
│
│ 2. User selects DID
│ 3. User confirms
│ 4. Private key signs
▼
Signature
│
▼
┌─────────────────────┐
│ Web App │
│ │
│ resolve DID │
│ retrieve public key │
│ verify signature │
└─────────────────────┘

Notice what is missing:

Private key → server

The private key should never need to leave the user's controlled environment.

9. DID Documents

A DID document is essentially a machine-readable description of how a DID can be verified and interacted with.

A simplified structure is:

{
"id": "did:example:123",
"controller": "did:example:123",

"verificationMethod": [
{
"id": "did:example:123#auth-key",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123",
"publicKeyMultibase": "..."
}
],

"authentication": [
"did:example:123#auth-key"
],

"service": [
{
"id": "did:example:123#profile",
"type": "ProfileService",
"serviceEndpoint": "https://example.com/profile/123"
}
]
}

The exact verification material and services depend on the chosen method and registered verification method types.

The important conceptual separation is:

DID document
│
├── Who controls this identifier?
│
├── Which keys can authenticate?
│
├── Which keys can perform particular proofs?
│
└── Where can related services be discovered?

A DID document should not become an unrestricted public database of personal information. W3C explicitly discusses privacy concerns around correlation, service metadata, and placing personal data into DID documents.

10. Verification Methods vs Authentication

These concepts are related but different.

A DID document might contain:

"verificationMethod": [...]

and then indicate how a particular key is used:

"authentication": [
"did:example:123#key-1"
]

One key might be appropriate for authentication.

Another might be used for assertion of credentials.

Another might be intended for key agreement.

This lets an identity system use different keys or authorization relationships for different operations.

That becomes increasingly important in larger systems because one compromised key should not necessarily imply compromise of every identity function.

11. DID + Verifiable Credentials

This is where DIDs become much more interesting.

Suppose a university issues a credential:

Student:
Anish Jha

Degree:
Computer Science

Graduation:
2027

The university can issue a digitally verifiable credential.

In the W3C model, the ecosystem is organized around three roles:

Issuer
│
│ issues credential
▼
Holder
│
│ presents credential
▼
Verifier

W3C's Verifiable Credentials Data Model 2.0 explicitly models issuers, holders, and verifiers and provides a machine-verifiable way to represent claims. ()

The holder can then present the credential to another service.

So instead of saying:

the system can ask:

That changes the trust model.

12. DID + Verifiable Credentials + Zero Knowledge

This is where the previous ZKP article connects directly.

Imagine a service requires the following condition:

Age >= 18

A normal identity system may ask for:

Date of birth:
15 March 1998

A verifiable credential improves authenticity:

Government-issued age credential

A zero-knowledge proof can take the architecture further:

Credential
│
▼
Private data
│
▼
ZK proof
│
▼
"Age >= 18" = true

The verifier learns:

valid = true

without necessarily learning:

exact date of birth

This is why DID, VC, and ZKP are complementary rather than competing systems.

DID
│
├── establishes identifier + key control
│
▼
Verifiable Credential
│
├── establishes an issuer-backed claim
│
▼
ZKP
│
└── proves a property without exposing unnecessary data

The Verifiable Credentials specification itself discusses privacy concerns created by persistent digital data and includes examples involving privacy-enhancing technologies such as zero-knowledge proofs.

13. Architecture of a Production DID System

A production implementation can be broken into several layers.

APPLICATION
│
┌──────────┴──────────┐
│ │
Login Credential Proof
│ │
▼ ▼
Authentication Presentation
│ │
└──────────┬──────────┘
│
▼
DID / VC LAYER
│
┌──────────┴──────────┐
│ │
DID Resolver Credential Store
│ │
▼ ▼
DID Document VC Data
│
▼
Verification Methods
│
▼
Cryptographic Keys
│
▼
Wallet / Extension

Around this you usually need:

Key storage
Backup / recovery
Rotation
Revocation / status
Resolver infrastructure
Audit logs
Origin binding
Session management
Threat detection

The DID specification itself dedicates substantial security and privacy consideration to key rotation, revocation, recovery, persistence, correlation, and DID document changes.

14. Local Key Custody

The hardest part of decentralized identity is often not creating the DID.

It's protecting the key.

A simplistic implementation might do:

localStorage.setItem("privateKey", privateKey);

That is not an appropriate design for production identity custody.

Instead, private material should be protected with a dedicated storage and encryption strategy.

A common conceptual architecture is:

User password
│
▼
Key derivation
│
▼
Encryption key
│
▼
Encrypted private key
│
▼
Local persistent storage

The password itself should not be stored as plaintext.

When a signing operation occurs:

Encrypted private key
│
▼
Decrypt in memory
│
▼
Sign nonce
│
▼
Clear sensitive material

This is one of the reasons a browser extension can be useful as a DID wallet.

The web application does not need direct access to the private key.

15. Browser Extension as a Wallet

A browser extension provides a natural security boundary.

The application says:

I want this DID to sign this challenge.

The extension decides:

Which DID?
Which key?
Which website?
What exactly is being signed?

The user gets a confirmation interface.

This is conceptually similar to how cryptocurrency wallet extensions protect signing operations, except the underlying identity model does not have to be tied to a blockchain.

A secure signing flow should therefore resemble:

Website
│
│ signing request
▼
Extension
│
├── validate requesting origin
├── identify DID
├── display challenge
├── ask for confirmation
│
▼
Private key
│
▼
Signature
│
▼
Extension
│
▼
Website

16. DecastID

This architecture is what makes the DecastID project interesting as a concrete implementation.

Decast is a decentralized live-casting and content-publishing platform with a broader architecture that supports decentralized storage and self-hosted deployment. The DID work provides an identity layer alongside that infrastructure.

The open-source repository contains a DID resolver, a DID manager browser extension, and a web application for identity management and verification. The repository describes did:decast as a custom DID method with Ed25519-based cryptographic key association, public verification methods, authentication support, and optional service endpoints. ()

The repository is available here:

The browser extension itself is published as Decast ID Manager in the Chrome Web Store. ()

17. DecastID Architecture

The repository describes three major pieces:

packages/
│
├── did-web
│
├── did-manager
│
└── decast-did-resolver

The DID manager is the browser-side identity wallet.

The resolver handles did:decast resolution.

The web application provides DID management and verification functionality. ()

The resulting architecture is:

Decast.live
│
│ login request
▼
┌───────────────┐
│ DecastID │
│ Chrome Wallet │
└───────┬───────┘
│
encrypted keys
│
▼
Local Storage
│
▼
Ed25519 signing
│
▼
Signature
│
▼
Decast.live verifies
│
▼
Authenticated

18. Ed25519

DecastID uses Ed25519-based identities according to the project documentation. ()

Ed25519 is an Edwards-curve digital signature system designed around the EdDSA signature algorithm.

At a conceptual level:

GenerateKeyPair()
│
├── Private Key
│
└── Public Key

Signing:

signature = Sign(privateKey, message)

Verification:

Verify(publicKey, message, signature)

The critical rule remains:

Private key stays with user.
Public key may be distributed.

That makes Ed25519 a practical choice for browser-side identity signing because the key representation is compact and the verification operation is straightforward.

19. DecastID Login Flow

Decast authentication flow works through a nonce-signing challenge. ()

The flow is:

1. User clicks "Login with DID"
│
▼
2. Extension opens
│
▼
3. User enters password
│
▼
4. User selects DID
│
▼
5. Decast provides nonce
│
▼
6. Extension asks for confirmation
│
▼
7. Private key signs nonce
│
▼
8. Signature returned
│
▼
9. Decast verifies signature
│
▼
10. Authentication complete

The extension returns the signature, nonce, and associated DID to the requesting origin after approval. ()

An important nuance here is that the extension itself does not need a separate cloud key-management service, and its architecture keeps the identity material under user control. However, the surrounding login flow still involves communication between the Decast website and its verifier/backend - for example, obtaining the authentication nonce.

That is different from saying that the entire authentication system requires no network communication.

20. Why the Signing Prompt Matters

A browser extension should not silently sign arbitrary messages.

Imagine a malicious site requesting:

Sign:
"Approve transfer of all assets"

If the wallet silently signs whatever arrives, the cryptography is technically correct but the system is still insecure.

The user must understand what operation is being authorized.

That is why DecastID explicitly uses a confirmation step before signing. The project's documentation identifies explicit user confirmation as a security measure for sensitive signing operations. ()

A stronger future design could display:

REQUEST TO SIGN

Origin:
decast.live

DID:
did:decast:...

Purpose:
Authentication

Nonce:
9f4a...

Expires:
60 seconds

[ Cancel ] [ Sign ]

The security boundary is not just cryptographic.

It is also human-readable authorization.

21. Encryption at Rest

DecastID documents encrypted private-key storage using a password selected by the user. ()

Conceptually:

Private Key
│
▼
Encrypt
▲
│
Password-derived key
│
▼
Encrypted identity

The extension documentation also states that the password itself is not stored or transmitted and that backups should be treated like wallet seed phrases. ()

That leads to an important operational rule:

DID ≠ secret
Private key = secret

A leaked DID is generally not equivalent to a leaked private key.

A leaked private key is much more serious because it can enable impersonation of the identity.

22. Backups and Recovery

A decentralized identity system creates a new responsibility:

What happens when the user loses the device?

Traditional authentication systems can often say:

Forgot password?
→ email reset

A self-controlled cryptographic identity requires a different model.

Possible recovery systems include:

Encrypted backup
Seed phrase
Recovery key
Social recovery
Multi-signature recovery
Hardware-backed recovery
Guardian keys
Delegated recovery

There is no universal solution.

The correct architecture depends on how much autonomy, usability, and recoverability the system requires.

This is one of the central design tradeoffs of decentralized identity.

23. Key Rotation

A robust identity system should assume that keys eventually need to change.

Reasons include:

device loss
suspected compromise
employee departure
hardware migration
security upgrades
algorithm changes
credential lifecycle

Suppose:

DID
│
└── Key A

becomes compromised.

The system should ideally allow:

DID
│
└── Key B

while preserving continuity of the identity.

W3C explicitly includes verification-method rotation and revocation, as well as DID recovery, among the security considerations of the specification. ()

This is an area where simplistic DID implementations often become fragile.

24. DID Documents Should Not Become Profile Databases

It is tempting to put everything inside a DID document:

{
"name": "Anish",
"email": "...",
"phone": "...",
"location": "...",
"age": 26
}

That is usually a bad architectural direction.

A DID document should primarily describe:

cryptographic control
verification methods
authentication relationships
services

rather than becoming a public identity profile.

Why?

Because public identity data is easily correlated.

W3C explicitly discusses DID correlation and DID-document correlation as privacy risks.

A better architecture is:

DID
│
├── Public cryptographic material
│
└── service references
│
▼
Credentials
│
▼
Selective presentation

25. Human-Friendly Names Are a Different Layer

A DID such as:

did:decast:4f9a12c7...

is useful to software.

It is not a particularly useful human-facing name.

This creates a familiar problem:

Machine identifier
vs
Human identifier

DNS has the same distinction:

example.com
↓
IP address

A DID can similarly have human-readable aliases or service-layer names.

But those names should not become confused with the cryptographic identity.

A nickname can change.

A domain can expire.

A handle can be reassigned.

Cryptographic control should be treated as a separate primitive.

W3C explicitly includes human-friendly identifiers among the security and architectural considerations around DIDs.

26. DID and OAuth Are Not Direct Replacements

DID is sometimes described as:

That is too simplistic.

OAuth solves delegated authorization.

DID solves an identifier and cryptographic-control problem.

They can work together.

For example:

OAuth
│
├── application authorization
│
▼
DID
│
├── cryptographic identity
│
▼
VC
│
└── verifiable claims

A real-world system may therefore contain:

OAuth
WebAuthn
DID
VC
ZKP
Session tokens

all at different layers.

A practical identity stack should use the simplest component that actually solves the problem.

27. DID + WebAuthn + Passkeys

Another important comparison is with passkeys.

Passkeys provide strong public-key authentication with excellent browser and platform integration.

DIDs solve a somewhat different problem:

Passkey
→ authenticate to a service

DID
→ establish a portable cryptographic identity

A future identity wallet could potentially combine these ideas.

For example:

Device authentication
│
▼
Platform authenticator
│
▼
Wallet unlock
│
▼
DID signing key
│
▼
Portable identity

The point is not that DID makes every existing authentication technology obsolete.

Its value is that it gives the cryptographic identity another level of portability and interoperability.

28. DID-Linked Storage

DIDs become particularly interesting in decentralized applications when identity and data ownership need to coexist.

Consider a decentralized publishing system.

Instead of:

User
│
└── Platform account
│
└── Files

you can model:

DID
│
├── identity
│
├── signing keys
│
└── service references
│
▼
decentralized storage

The Decast repository describes DID-linked storage intended to cryptographically associate content and storage with the user's identity. ()

This becomes particularly useful for platforms that support:

self-hosting
decentralized storage
content portability
multi-service identity
portable credentials
cryptographic authorization

The identity stops being merely a login mechanism and starts becoming an application-layer control primitive.

29. DID for Content Ownership

Consider a creator publishing a video.

A traditional architecture might look like:

Creator account
│
▼
Platform database
│
▼
Video

A DID-oriented architecture might instead look like:

Creator DID
│
├── signing key
│
▼
Content metadata
│
├── content hash
├── creation metadata
└── signature
│
▼
decentralized storage

Now another service can verify:

Does this DID control the signing key?
Was this metadata signed by that key?
Does the content hash match?

That enables cross-platform verification without requiring every service to share one user database.

30. DID for Creator Infrastructure

This is especially relevant to decentralized media systems.

Imagine a creator operating:

Streaming server
Storage node
Publishing service
Analytics service
Social identity
Archive

Instead of creating a different identity relationship with every service:

Platform A account
Platform B account
Platform C account
Platform D account

the creator can establish relationships around one or more DIDs.

The individual services can then decide:

Which keys are authorized?
Which claims are required?
Which credentials are valid?
Which operations require user approval?

That does not eliminate platform-specific policies.

It changes how identity and authorization can be represented.

31. DID for Organizations

DIDs are not limited to individuals.

An organization can have a DID:

did:example:company123

and use it to establish:

signing authority
service endpoints
credential issuance
software identity
domain relationships
organization-level signatures

A service could therefore verify that:

Organization X

signed a statement or issued a credential without depending exclusively on a centralized social-account provider.

This is potentially useful for:

supply chains
software publishers
AI agents
enterprise APIs
legal entities
content publishers
device fleets

32. DID for Machines and AI Agents

This is one of the more interesting future applications.

As autonomous software becomes more common, an AI agent may need a persistent identity.

For example:

Agent DID
│
├── public keys
├── capabilities
├── service endpoints
└── credential relationships

An agent could prove:

I am agent X.
I am controlled by organization Y.
I possess credential Z.
I am authorized to perform operation Q.

A DID does not magically make an AI agent trustworthy.

But it can provide a cryptographic identity layer on top of which authorization and provenance can be built.

That distinction is important.

Identity
≠
Trustworthiness

A malicious actor can also have cryptographic keys.

The rest of the trust system still matters.

33. DID for Devices

IoT systems have the same fundamental problem.

Millions of devices need identifiers.

Instead of:

Manufacturer server
│
└── device database

a device can have cryptographic identity material:

Device DID
│
├── authentication key
├── device credential
└── service endpoints

Another system could then verify:

This request came from device X.

without requiring every system to maintain an identical identity database.

34. DID for Credentials

Credentials are where the architecture becomes significantly more useful.

A credential could represent:

University degree
Employment
Professional license
Age range
Membership
Government verification
Device certification
Organization role

The issuer signs the credential.

The holder stores it.

The verifier checks it.

This creates:

Issuer
│
│ signed credential
▼
Holder
│
│ selective presentation
▼
Verifier

The DID layer helps establish the cryptographic identities involved.

The VC layer carries the claims.

35. Status, Revocation, and Expiration

A credential cannot simply be valid forever.

Consider:

Professional license

If the license is revoked, the verifier needs to know.

There are several architectural approaches.

A status mechanism can say:

credential = valid
credential = suspended
credential = revoked

W3C's VC 2.0 family includes the Bitstring Status List 1.0 as a standard mechanism for publishing credential status information in a privacy-preserving and efficient manner.

A mature identity architecture therefore needs to model:

Issuance
↓
Storage
↓
Presentation
↓
Verification
↓
Status
↓
Expiration / Revocation

not simply issuance.

36. DID Resolution

Resolver architecture is an important part of the system.

Suppose an application receives:

did:decast:abc123

It needs to determine:

What DID document corresponds to this DID?

Conceptually:

resolve("did:decast:abc123")
│
▼
DID method resolver
│
▼
Registry / storage / network
│
▼
DID document

A resolver should validate the method-specific rules rather than blindly returning arbitrary JSON.

That means a resolver implementation is part of the trust architecture.

37. Building a DID Method

If you want to implement your own DID method, the method specification has to define much more than how to generate a string.

At minimum, you need answers to:

How is a DID created?
How is uniqueness achieved?
How is the DID resolved?
Where is the DID document stored?
Can it be updated?
How are updates authorized?
Can it be deactivated?
How are updates propagated?
How does recovery work?
What cryptographic suites are supported?
What are the privacy properties?

W3C defines the DID method concept specifically around creation, resolution, update, and deactivation operations. ()

38. A Simplified DID Creation Flow

Imagine creating a Decast-style DID.

const keyPair = await generateEd25519KeyPair();

const did = createDidFromPublicKey(
keyPair.publicKey
);

const document = {
id: did,
verificationMethod: [
{
id: `${did}#key-1`,
type: "Ed25519VerificationKey2020",
controller: did,
publicKeyMultibase: encode(
keyPair.publicKey
)
}
],
authentication: [
`${did}#key-1`
]
};

Conceptually:

Generate keys
│
▼
Extract public key
│
▼
Create DID
│
▼
Construct DID document
│
▼
Publish / register according to DID method

The exact representation and encoding depend on the chosen DID method.

39. Implementing Challenge-Response Authentication

The server:

const nonce = crypto.randomUUID();

storeNonce({
nonce,
did,
expiresAt,
});

The extension receives:

{
"did": "did:decast:...",
"nonce": "...",
"origin": "https://decast.live"
}

The user confirms.

The extension signs:

const signature = await sign(
privateKey,
nonce
);

The extension returns:

{
"did": "did:decast:...",
"nonce": "...",
"signature": "..."
}

The verifier then:

const didDocument = await resolve(did);

const publicKey = extractAuthenticationKey(
didDocument
);

const valid = verify(
publicKey,
nonce,
signature
);

If:

valid === true

the application establishes its authenticated session.

The session itself might still use an ordinary server-side session or token.

DID authentication and application sessions are separate layers.

40. Why This Is Better Than Sending Private Keys

A badly designed identity system could do:

Client
│
└── send private key → server

That destroys much of the point of public-key identity.

Instead:

Client
│
└── sign challenge
│
▼
server

The server sees:

DID
Public Key
Nonce
Signature

but not:

Private Key

The cryptographic boundary remains clear.

41. DID and Sessions

After successful verification, the application can establish a conventional session:

DID Authentication
│
▼
Signature verified
│
▼
Session created
│
▼
Cookie / token

There is no requirement that every API request be individually signed.

That would often be unnecessary.

Instead, DID authentication can establish:

authenticated session

while stronger operations may require another explicit signature.

For example:

Login
→ DID signature

Publish content
→ DID signature

Delete content
→ DID signature

Change recovery key
→ DID signature

The authentication policy becomes operation-specific.

42. Origin Binding

Browser-based DID systems need to think carefully about origins.

Suppose a signing request comes from:

The extension should know that this is the site the user intended to authorize.

A malicious website should not simply impersonate the same workflow.

A robust protocol therefore associates the request with:

origin
audience
nonce
timestamp
operation

For example:

{
"type": "DIDAuthenticationRequest",
"origin": "https://decast.live",
"audience": "decast.live",
"nonce": "...",
"issuedAt": "...",
"expiresAt": "..."
}

This makes the signed message specific to the intended service.

43. Threat Model

A professional DID implementation should explicitly model its threats.

Private-key theft

If the attacker gets the private key:

Attacker
│
▼
Can sign as DID

Mitigation:

encryption
hardware security
strong password
secure storage
key rotation
recovery procedures

Replay attacks

Attacker captures:

nonce + signature

and reuses it.

Mitigation:

unique nonce
short expiration
single-use challenge
audience binding

Phishing

A malicious site requests a valid signature.

Mitigation:

origin verification
clear user prompts
human-readable signing requests
strict extension permissions

Resolver compromise

A malicious resolver could return incorrect identity metadata.

Mitigation:

method-specific verification
trusted resolution paths
content integrity
independent verification

Correlation

The same DID is used everywhere.

Now multiple services can correlate activity.

Mitigation:

multiple DIDs
pairwise identifiers
selective disclosure
ZKP
minimal public metadata

44. DID Correlation Is a Real Privacy Problem

One of the biggest misunderstandings around decentralized identity is:

It does not.

A globally reused DID can actually increase correlation.

Suppose:

did:example:abc

is used for:

Bank
University
Social Network
Healthcare
Government

A common identifier can become a correlation handle.

The system is cryptographically decentralized but potentially socially very centralized.

This is why privacy-preserving identity often involves:

multiple identifiers
+
selective disclosure
+
minimal data sharing
+
zero-knowledge proofs

W3C's DID security and privacy sections explicitly identify DID and DID-document correlation as risks. ()

45. Multiple DIDs Can Be Better

A user might therefore have:

DID A → professional identity
DID B → personal identity
DID C → financial identity
DID D → anonymous community identity

The underlying user controls all four.

But external services do not automatically know they belong to the same person.

This creates a more privacy-aware architecture.

User
│
┌─────────┼─────────┐
│ │ │
DID A DID B DID C
│ │ │
Work Personal Private

This is more complicated operationally, but the tradeoff can be valuable.

46. Where ZK Fits

Zero-knowledge proofs provide another mechanism against over-sharing.

Suppose a credential states:

Date of birth:
1998-03-15

The verifier only asks:

Age >= 18

The holder can prove the predicate:

1998-03-15 satisfies Age >= 18

without exposing the underlying value.

The combined architecture becomes:

DID
│
│ identity/control
▼
Credential
│
│ signed claim
▼
ZK Circuit
│
│ proof
▼
Verifier
│
└── learns only required fact

This is a very different model from submitting a complete identity record.

47. DID + ZKP as a Larger Trust Architecture

The previous article focused on proving computation.

DID systems provide the identity side of that equation.

Together:

DID
"What identity controls this key?"

VC
"What trusted issuer made this claim?"

ZKP
"Can this claim be proven without revealing unnecessary information?"

Verifier
"Do I accept this proof under my policy?"

This gives applications four distinct questions rather than collapsing everything into one login form.

48. Use Cases

DID systems can support a wide range of applications.

Authentication

Login without passwords
Cross-platform authentication
Portable account identity

Professional identity

Employment credentials
Professional certifications
Licenses
Organization membership

Education

Degree credentials
Student identity
Academic records
Certificate verification

Finance

KYC credentials
Accreditation
Account ownership
Transaction authorization

Healthcare

Medical credentials
Provider verification
Selective disclosure
Patient-controlled records

Creator platforms

Content ownership
Cross-platform identity
Signed publishing metadata
Portable reputation

IoT

Device identity
Firmware verification
Authorization
Machine-to-machine authentication

AI agents

Agent identity
Organization-issued credentials
Capability delegation
Machine authorization

Decentralized storage

Identity-linked content
Signed metadata
Portable ownership records
Self-hosted infrastructure

49. Where DID Does Not Solve Everything

DID is not a replacement for every identity problem.

A DID does not automatically tell you:

Whether someone is trustworthy
Whether a credential issuer is trustworthy
Whether a website is legitimate
Whether a user is a real human
Whether a claim is true
Whether a transaction should be authorized

It provides cryptographic primitives around identity and control.

Trust remains contextual.

For example:

DID says:
"This key controls DID X."

Credential issuer says:
"X has credential Y."

Application policy says:
"Credential Y is sufficient for this action."

Each layer has a different responsibility.

50. Human Verification Still Matters

Some identity systems require real-world verification.

For example:

"This person is over 18."

A DID cannot infer that from mathematics.

An issuer must establish the fact.

The issuer may use:

government ID
biometric verification
institutional record
email verification
physical document
financial records

and then issue a credential.

DID makes the resulting relationship cryptographically portable.

It does not eliminate the original verification process.

51. Decast Verification Architecture

The Decast project extends this model with multiple verification services.

Its repository documents integrations involving:

Apple account verification
Google account verification
Facebook account verification
Email verification
MetaMask ownership
Liveness checks

and describes these services as ways of associating identity claims with DID-based identities. ()

That creates a layered model:

External identity
│
▼
Verification service
│
▼
Credential
│
▼
DID
│
▼
Portable identity

The DID therefore becomes the place where different verified relationships can converge without requiring each verifier to become the permanent owner of the identity.

52. DID and Liveness

A particularly interesting example is liveness.

A liveness system may establish:

Someone was physically present

but that does not automatically mean:

This DID belongs to that person forever.

The correct architecture is:

Liveness process
│
▼
Verification result
│
▼
Credential
│
▼
Holder's DID

Then another service can verify the credential without repeating the entire verification process, subject to the credential's policy and status.

This is an example of why identity architectures work better as layers.

53. Building a DID Wallet

A minimal DID wallet needs:

Identity creation
Identity import
Identity deletion
Private-key storage
Encryption
Backup
Restore
Signing
DID selection
Confirmation UI

DecastID already implements the core of this wallet model, including DID generation, identity restoration, identity removal, private-key export, and support for multiple DID profiles. ()

The architecture is essentially:

┌─────────────────────────┐
│ DID Manager │
├─────────────────────────┤
│ Identity 1 │
│ Identity 2 │
│ Identity 3 │
├─────────────────────────┤
│ Backup │
│ Restore │
│ Sign │
│ Delete │
└─────────────────────────┘

The browser becomes the user's identity boundary.

54. Multi-Identity Support

Multiple identities matter because a user may not want a single identifier attached to everything they do.

A wallet can therefore contain:

DID 1
DID 2
DID 3

and the user chooses which one is used for a particular interaction.

This is closer to having multiple cryptographic personas than having a single universal account.

That can be useful for:

work
personal
anonymous participation
testing
organizations
projects

55. A Practical Implementation Stack

A practical DID project could use a stack like:

Frontend
React / Next.js / Vue / Nuxt

Wallet
Browser extension
Mobile wallet
Hardware wallet

Cryptography
Ed25519
Web Crypto / audited crypto libraries

Identity
DID Core
DID method implementation

Resolution
DID resolver
Method registry / network

Credentials
W3C Verifiable Credentials

Proofs
DID-JWT / Data Integrity
Zero-knowledge systems where required

Storage
IndexedDB
Encrypted local storage
decentralized storage

Backend
REST
GraphQL
WebSocket
verifier services

Deployment
Docker
self-hosted services

The exact technologies depend on the application.

56. A Better Browser Architecture

For a browser extension, a reasonable separation is:

WEBSITE
│
signing request
│
▼
CONTENT SCRIPT
│
▼
BACKGROUND
SERVICE WORKER
│
▼
KEY MANAGER
│
▼
ENCRYPTED STORE

The popup UI should not itself become the permanent security boundary.

Instead, the background/service-worker layer can coordinate:

request validation
origin validation
key access
signing
response routing

That architecture is easier to reason about as the extension grows.

57. Self-Hosted Identity Infrastructure

One advantage of decentralized architecture is the possibility of self-hosting.

A platform might offer:

Hosted deployment
OR
Self-hosted deployment

The identity layer can remain interoperable provided the implementation follows the relevant DID method rules.

This is particularly relevant to Decast because the platform is designed around decentralized infrastructure and self-hosted deployment.

A user could conceptually operate:

Own server
│
├── Decast
├── storage
├── resolver
└── identity services

while users retain control of the corresponding keys.

That changes the architecture from:

platform owns identity

to:

platform provides infrastructure
user controls credentials and keys

There are still trust relationships, but they are more explicit.

58. Operational Challenges

DID systems create new engineering responsibilities.

Key lifecycle

You need:

creation
rotation
backup
recovery
revocation

Resolution reliability

A DID is not useful if resolvers cannot reliably retrieve the corresponding document.

Interoperability

Supporting one DID method does not automatically mean the system interoperates with every DID method.

User experience

Users understand:

Login with Google

much more readily than:

Select verification method
Select DID
Approve signature

Wallet UX remains an important part of adoption.

Recovery

Users are not accustomed to losing access permanently because of lost cryptographic material.

Privacy

A permanent identifier can become a correlation handle.

These are not minor implementation details.

They are core architecture problems.

59. Why DID Could Become Important

The strongest argument for DIDs is not:

It is a more general argument about identity architecture.

The modern Internet has a fragmented identity model:

Google identity
Apple identity
Meta identity
Microsoft identity
GitHub identity
Bank identity
University identity
Government identity

Each system creates its own account boundary.

A portable cryptographic identity offers another model:

User
│
▼
DID
┌────────┼────────┐
▼ ▼ ▼
Service A Service B Service C
│ │ │
└──── credentials ────┘

That does not eliminate the services.

It potentially separates identity control from service ownership.

That distinction becomes more valuable as users move between:

platforms
organizations
devices
applications
AI systems
decentralized infrastructure

W3C's work around DIDs and the 2025 standardization of Verifiable Credentials provide evidence that decentralized identity is being formalized as part of the broader web standards ecosystem rather than remaining solely a niche cryptography concept. ()

60. The Likely Evolution of the Identity Stack

A useful way to think about the progression is:

Generation 1 — Account identity

username
password

Generation 2 — Federated identity

Google
Apple
Microsoft
OAuth
OpenID

Generation 3 — Cryptographic identity

DID
public/private keys
wallets

Generation 4 — Verifiable identity

DID
+
Verifiable Credentials

Generation 5 — Privacy-preserving identity

DID
+
VC
+
ZKP

The fifth generation is particularly interesting because it changes the question from:

to:

That is a more fundamental shift than simply replacing passwords with signatures.

61. DID + ZKP + Decentralized Storage

Taken together, the technologies form a particularly powerful architecture:

USER
│
▼
DID
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
Keys VC data Storage
│ │ │
│ ▼ │
│ ZKP │
│ │ │
└─────► Application ◄─┘

Now the system can establish:

Who controls the identity?
↓
What claims exist?
↓
What can be proven?
↓
Where is the data stored?
↓
Who is allowed to access or modify it?

Each layer has a distinct job.

That separation is what makes the architecture scalable.

62. What DecastID Demonstrates

The DecastID project is a practical example of that architecture rather than simply a theoretical implementation.

Its repository currently combines:

did:decast method
DID resolver
browser-based DID manager
encrypted key storage
Ed25519 identities
nonce-based authentication
credential verification flows
DID-JWT proof generation

and the manager is distributed as a Chrome extension. ()

The project is also open source under the MIT license. ()

That makes it useful not just as a component of Decast, but as a concrete reference for developers interested in experimenting with browser-managed decentralized identity.

You can inspect and run the project here:

And the extension:

63. A Minimal End-to-End Architecture

Putting everything together:

┌───────────────┐
│ User │
└───────┬───────┘
│
controls keys
│
▼
┌──────────────────┐
│ DID │
└────────┬─────────┘
│
resolves to
│
▼
┌──────────────────┐
│ DID Document │
├──────────────────┤
│ verification key │
│ authentication │
│ services │
└────────┬─────────┘
│
▼
┌───────────────┐
│ Credential │
│ │
│ issued by │
│ trusted issuer│
└───────┬───────┘
│
user proves
│
▼
┌───────────────┐
│ ZK / VC proof │
└───────┬───────┘
│
▼
┌───────────────┐
│ Verifier │
└───────────────┘

This is the larger system:

Identity
+
Credentials
+
Cryptographic Proof
+
Privacy
+
Application Authorization

64. What a Production Implementation Should Prioritize

A useful implementation roadmap is:

Phase 1 — Cryptographic identity

Implement:

Ed25519 key generation
DID creation
DID document
signature verification

Phase 2 — Resolver

Implement:

DID resolution
document retrieval
method validation

Phase 3 — Wallet

Implement:

encrypted key storage
identity creation
restore
backup
multiple identities

Phase 4 — Authentication

Implement:

challenge generation
nonce signing
origin binding
expiration
session establishment

Phase 5 — Credentials

Implement:

credential issuance
credential storage
credential presentation
verification
status

Phase 6 — Privacy

Add:

pairwise DIDs
selective disclosure
ZK proofs
minimal metadata
correlation resistance

Phase 7 — Recovery

Add:

key rotation
recovery
delegation
social recovery
hardware keys

That is much closer to a production identity platform than simply generating a did: string.

65. The Security Model in One Diagram

The entire security model can be summarized like this:

┌───────────────────┐
│ DID │
│ public identifier │
└─────────┬─────────┘
│
resolves to
│
▼
┌───────────────────┐
│ DID Document │
│ public metadata │
└─────────┬─────────┘
│
contains
│
▼
┌───────────────────┐
│ Public Key │
└─────────┬─────────┘
▲
│
mathematically linked
│
▼
┌───────────────────┐
│ Private Key │
│ SECRET / LOCAL │
└─────────┬─────────┘
│
signs
│
▼
┌───────────────────┐
│ Nonce │
│ Challenge │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ Signature │
└─────────┬─────────┘
│
verified
│
▼
┌───────────────────┐
│ Application │
└───────────────────┘

Then add credentials:

Issuer → Credential → Holder → Verifier

and ZKP:

Private credential → ZK proof → minimal disclosure

The result is an identity architecture where each primitive does one thing well.

66. Final Perspective

The interesting part of decentralized identity is not the acronym.

It is the change in where the trust boundary sits.

Traditional identity frequently looks like:

Platform
│
├── owns account
├── owns identity record
├── authenticates user
├── stores credentials
└── controls recovery

A decentralized model can instead look like:

User
│
├── controls cryptographic keys
│
├── controls one or more DIDs
│
├── holds credentials
│
└── decides when to sign or present
│
▼
Services

The services still matter.

Issuers still matter.

Resolvers still matter.

Policies still matter.

But the identity itself can become portable.

That is the real idea behind DID.

And when DIDs are combined with Verifiable Credentials, the system gains portable claims. When zero-knowledge proofs are added, the holder can potentially prove the required property without disclosing everything behind it. When decentralized storage is added, data and identity can be separated from any one hosting provider.

That creates a stack that looks less like a collection of accounts and more like infrastructure:

DECENTRALIZED APPLICATION
│
┌─────────┴─────────┐
│ │
Authorization Data/Content
│ │
▼ ▼
DID Decentralized Storage
│
▼
Verifiable Credentials
│
▼
Zero-Knowledge Proofs
│
▼
Privacy-preserving trust

It is too early to say that DID will replace the identity systems used across the web. Conventional account systems remain simpler for many applications, and the ecosystem still has substantial interoperability, usability, recovery, privacy, and deployment challenges.

But the underlying direction is significant: the web now has standardized building blocks for identifiers and verifiable credentials, and implementations such as DecastID demonstrate that these ideas can be turned into working software rather than remaining purely theoretical. ()

The most important shift may therefore not be "decentralized identity replaces login."

It may be:

identity becomes a cryptographic primitive that applications can build on rather than a record permanently owned by the application itself.

That is where DID becomes much more interesting than another authentication mechanism.