**Author:** Roman "Romanov" Research-Rachmaninov, #B4mad Industries
**Date:** 2026-03-03
**Bead:** beads-hub-wgq
**Status:** Published

## Abstract

As autonomous agent networks scale toward millions of participants, the question of identity becomes foundational: how do agents identify, authenticate, and trust each other without a central authority? This paper provides a comparative analysis of W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) as the identity layer for agent-to-agent communication. We evaluate both standards across security, privacy, and scalability dimensions, assess implementation challenges for real-world agent networks, and recommend a concrete identity architecture for #B4mad Industries' million-agent vision.

**Outcome hypothesis:** If #B4mad adopts a DID+VC-based identity framework (output), agents can authenticate and authorize each other without centralized gatekeepers (result), enabling a truly sovereign, scalable, and trustworthy multi-agent network aligned with #B4mad's technological sovereignty mission (outcome).

## Context: Why This Matters for #B4mad

#B4mad Industries is building toward a "million-agent network" — autonomous AI agents coordinating across organizational boundaries via beads, MCP endpoints, and shared compute infrastructure. Today, agent identity in the #B4mad network is implicit: agents are processes on trusted hosts, authenticated via SSH keys and API tokens scoped to the OpenClaw runtime. This works at small scale but creates fundamental problems as the network grows:

1. **Central authority dependency.** Every agent's identity traces back to a single OpenClaw instance or GitHub account. If the authority is compromised, all agent identities are suspect.
2. **No portable reputation.** An agent's track record (beads completed, code quality, reliability) is locked inside the system that spawned it. There's no way for an external agent to verify claims about another agent's capabilities.
3. **No selective disclosure.** When agents interact, they currently share all-or-nothing context. There's no mechanism for an agent to prove it has a specific capability without revealing its entire configuration.
4. **Cross-network friction.** Agents from different organizations cannot authenticate each other without pre-shared secrets or a common trusted third party.

These are precisely the problems that Decentralized Identifiers and Verifiable Credentials were designed to solve — originally for humans, but increasingly relevant for autonomous software agents.

## State of the Art

### W3C Decentralized Identifiers (DIDs)

DIDs are a W3C Recommendation (v1.0, July 2022) defining a new type of globally unique identifier. A DID (e.g., `did:web:agent.b4mad.net:brenner-axiom`) resolves to a **DID Document** containing:

- **Verification methods:** Cryptographic public keys the subject uses to authenticate.
- **Service endpoints:** URLs where the subject can be reached (e.g., an MCP endpoint).
- **Controller information:** Who can update the DID Document.

Key properties for agent networks:

| Property | Description |
|----------|-------------|
| **Self-issued** | Any entity can create a DID — no permission needed from a central registry |
| **Cryptographically verifiable** | Ownership is proved via digital signatures, not database lookups |
| **Method-agnostic** | Different DID methods (did:web, did:key, did:peer, did:ethr) offer different trust/scalability tradeoffs |
| **Resolution** | Standard resolution protocol (DID Resolution v0.3) enables any party to fetch the DID Document |

Over 150 DID methods are registered with the W3C. The most relevant for agent networks:

- **did:key** — Deterministic, derived directly from a public key. No resolution infrastructure needed. Ideal for ephemeral agent identities.
- **did:web** — Resolves via HTTPS to a well-known path on a domain. Leverages existing DNS/TLS infrastructure. Easy to deploy but inherits DNS centralization.
- **did:peer** — Peer-to-peer, no ledger required. Two parties exchange DID Documents directly. Excellent for private agent-to-agent channels.
- **did:ethr** — Ethereum-based. DID Document anchored on-chain. Provides tamper-evident history but introduces blockchain dependency and gas costs.
- **did:plc** — Created by Bluesky/AT Protocol. Operated via a centralized but auditable registry. Interesting hybrid model.

### Verifiable Credentials (VCs)

VCs are a W3C Recommendation (v2.0, March 2025) defining a standard data model for tamper-evident, cryptographically verifiable claims. The trust triangle:

- **Issuer:** Creates and signs the credential (e.g., #B4mad certifying an agent's capabilities).
- **Holder:** Possesses the credential (the agent itself).
- **Verifier:** Checks the credential's authenticity and the issuer's trustworthiness.

For agent networks, VCs can express:

- **Capability credentials:** "This agent is authorized to execute code on Nostromo cluster."
- **Reputation credentials:** "This agent has successfully completed 47 beads with zero rollbacks."
- **Delegation credentials:** "goern delegates code review authority to this agent until 2026-06-01."
- **Membership credentials:** "This agent is a member of the #B4mad network."

**Verifiable Presentations (VPs)** allow an agent to bundle multiple VCs and present them to a verifier with selective disclosure — proving specific claims without revealing the full credential.

### The DIF Ecosystem

The Decentralized Identity Foundation (DIF) coordinates interoperability across 300+ member organizations. Key specifications relevant to agents:

- **DIDComm v2:** A transport-agnostic messaging protocol for DID-authenticated communication. Supports encryption, signing, and routing — essentially a secure agent-to-agent messaging layer built on DIDs.
- **Presentation Exchange v2:** Standard for verifiers to request specific credentials from holders.
- **Well Known DID Configuration:** Linking DIDs to existing domain names for discovery.

### Emerging Agent-Specific Standards

- **EIP-8004 (Trustless Agents):** Proposes on-chain agent identity and authorization via Ethereum smart contracts. Relevant for agents operating in DeFi/DAO contexts.
- **Agent Protocol (agentprotocol.ai):** Defines agent-to-agent communication primitives, could integrate DID-based auth.
- **KERI (Key Event Receipt Infrastructure):** An alternative to blockchain-anchored DIDs using a hash-linked event log. Promising for high-throughput agent networks where blockchain settlement is too slow.

## Comparative Analysis

### Security

| Dimension | DIDs | VCs | Combined |
|-----------|------|-----|----------|
| **Authentication** | Strong — cryptographic proof of identity via key ownership | N/A alone — VCs authenticate *claims*, not *identity* | Agent proves identity (DID) AND capabilities (VC) in one interaction |
| **Key management** | DID Document supports key rotation, multiple keys, threshold signatures | Credential revocation via status lists or on-chain registries | Both require robust key management; compromise of DID controller key is catastrophic |
| **Replay protection** | DID Document versioning, but varies by method | VCs include issuance date, expiration, and nonce support | Combined with DIDComm's message-level nonces, replay is mitigated |
| **Man-in-the-middle** | Depends on DID method — did:web inherits TLS trust model; did:peer provides E2E guarantees | VC signatures are verifiable regardless of transport channel | DIDComm provides authenticated encryption; VCs survive MITM on the transport layer |

**Assessment:** The DID+VC stack provides a *defense-in-depth* model. DIDs handle identity authentication; VCs handle authorization and capability proof. The main security concern is **key management at scale** — a million agents each managing cryptographic keys is a significant operational challenge.

### Privacy

| Dimension | DIDs | VCs | Combined |
|-----------|------|-----|----------|
| **Correlation resistance** | Varies dramatically by method. did:key is correlatable (same key = same agent). did:peer generates unique DIDs per relationship, preventing correlation. | Standard VCs are correlatable if the same credential is shown to multiple verifiers | **Zero-Knowledge Proofs (ZKPs)** with BBS+ signatures enable selective disclosure without correlation |
| **Minimal disclosure** | DID Documents are public (except did:peer) — all verification methods and endpoints visible | VPs support selective disclosure — prove age > 18 without revealing birthdate | Combined: agent proves membership in #B4mad network without revealing which specific agent it is |
| **Surveillance resistance** | On-chain DIDs (did:ethr) create permanent, public identity records | VC usage is between holder and verifier only (unless verifier reports) | did:peer + ZKP-VCs = maximum privacy; did:ethr + standard VCs = minimum privacy |

**Assessment:** Privacy is the most nuanced dimension. For agent networks, the primary threat model is **cross-network correlation** — preventing verifiers from tracking an agent's interactions across different contexts. The combination of **did:peer** (pairwise DIDs per relationship) and **BBS+ selective disclosure** on VCs provides strong privacy guarantees, but at the cost of implementation complexity.

### Scalability

| Dimension | DIDs | VCs | Assessment |
|-----------|------|-----|------------|
| **Creation throughput** | did:key: instant (derived from key). did:web: one HTTPS endpoint per agent. did:ethr: one transaction per agent (bottleneck). | Issuance is a signing operation — thousands per second per issuer | did:key and did:peer scale to millions trivially. Blockchain-anchored methods are the bottleneck. |
| **Resolution latency** | did:key: microseconds (computed locally). did:web: one HTTP request. did:ethr: one RPC call (100-500ms). | Verification is a signature check — microseconds | For agent-to-agent latency, avoid blockchain resolution in the hot path. Use did:key or cached did:web. |
| **Storage** | DID Documents: ~1-5 KB each. For 1M agents: 1-5 GB. | Individual VCs: ~1-2 KB. Revocation status lists: compact bitmap (~125 KB for 1M credentials). | Storage is not a concern at million-agent scale. |
| **Network overhead** | DIDComm messages add ~500 bytes of envelope overhead per message | VC presentation adds 1-3 KB per interaction (depending on number of credentials) | Overhead is acceptable for #B4mad's use case (bead coordination, not high-frequency trading). |

**Assessment:** Scalability is achievable but requires **method selection discipline**. The recommendation is a layered approach: **did:key** for ephemeral/session identities, **did:web** for persistent organizational identities, and **did:peer** for private bilateral channels. Avoid blockchain-anchored DIDs for hot-path resolution.

## Implementation Challenges for Real-World Agent Networks

### 1. Key Management at Agent Scale

Human SSI assumes a wallet app on a phone. Agent SSI requires automated key management across potentially thousands of agent instances:

- **Key generation:** Each agent needs a unique key pair. Hardware security modules (HSMs) don't scale economically to thousands of agents.
- **Key rotation:** Compromised keys must be rotated without disrupting ongoing interactions. DID methods vary wildly in rotation support.
- **Key recovery:** If an agent's key is lost, its identity is lost. There is no "forgot password" flow.
- **Delegation chains:** goern → Brenner Axiom → CodeMonkey → ephemeral sub-agent. Each delegation must be cryptographically verifiable.

**Recommendation:** Use **software-based key management** with TPM-backed keys where available. Implement a **key hierarchy**: a long-lived root key (stored securely, rarely used) signs short-lived operational keys. Agent instances use operational keys; root key only for rotation and recovery.

### 2. Trust Bootstrap (The Cold Start Problem)

DIDs solve *identity* but not *trust*. When a new agent joins the network:

- How does it get its first credential?
- Who vouches for it?
- How do existing agents decide to trust the new entrant?

In human SSI, governments issue foundational credentials (passport, ID card). In agent networks, there's no equivalent.

**Recommendation:** Define a **trust anchor hierarchy** for #B4mad:
1. **Network root of trust:** #B4mad Industries issues a "network membership" VC signed by a well-known DID (did:web:b4mad.net).
2. **Organizational trust:** Each operator (goern, partners) has a DID that can issue delegation VCs to their agents.
3. **Earned trust:** Agents accumulate reputation VCs based on verifiable on-chain or bead-tracked performance.

### 3. Revocation at Scale

When an agent is compromised or decommissioned, its credentials must be revoked. Current approaches:

- **Status List 2021:** A compact bitstring where each bit represents a credential. Efficient but requires the verifier to fetch the list.
- **On-chain revocation:** Permanent and auditable but slow and expensive.
- **Short-lived credentials:** Issue credentials with 24-hour expiry. No revocation needed — just stop reissuing.

**Recommendation:** For agent networks, **short-lived credentials with auto-renewal** is the most practical approach. An agent's capabilities credential expires every 24 hours and is automatically reissued by its controller. Compromise detection window is bounded to 24 hours maximum.

### 4. Interoperability Across Agent Frameworks

The agent ecosystem is fragmented: OpenClaw, AutoGPT, CrewAI, LangGraph, custom frameworks. For DIDs to enable cross-framework agent communication:

- All frameworks must implement DID resolution.
- All frameworks must understand a common VC schema for agent capabilities.
- DIDComm must be adopted as the transport layer (or bridged to existing transports).

This is the hardest challenge — it requires ecosystem coordination, not just technical implementation.

**Recommendation:** Start with **did:web** (lowest common denominator — any HTTP server can host a DID Document) and a **minimal agent capability VC schema**. Publish both as open specifications from #B4mad. Demonstrate interoperability with at least one other framework.

### 5. Performance Overhead in Hot Paths

Agent-to-agent communication in bead coordination happens at high frequency. Adding DID resolution and VC verification to every interaction introduces latency:

- DID resolution: 0-500ms depending on method.
- VC verification: <1ms for Ed25519, 10-50ms for BBS+ (ZKP).
- DIDComm envelope processing: 1-5ms.

**Recommendation:** **Cache aggressively.** Resolve a peer's DID Document once, cache it for the session. Verify VCs once per connection establishment, not per message. Use DIDComm's session establishment to amortize crypto overhead.

## Recommendations for #B4mad

### Architecture: Layered Identity Model

```
┌─────────────────────────────────────────────┐
│          Application Layer                   │
│   Beads · MCP · Agent Protocol              │
├─────────────────────────────────────────────┤
│          Auth & Capability Layer             │
│   Verifiable Credentials (VCs)              │
│   - Network Membership VC                   │
│   - Capability VCs (compute, code, publish) │
│   - Reputation VCs (bead track record)      │
├─────────────────────────────────────────────┤
│          Communication Layer                 │
│   DIDComm v2 (encrypted, authenticated)     │
├─────────────────────────────────────────────┤
│          Identity Layer                      │
│   DIDs (did:web for orgs, did:key for       │
│   agents, did:peer for private channels)    │
└─────────────────────────────────────────────┘
```

### Phased Rollout

**Phase 1 (Q2 2026): Foundation**
- Assign did:web identities to #B4mad and Brenner Axiom (`did:web:b4mad.net`, `did:web:b4mad.net:agents:brenner-axiom`).
- Publish DID Documents at `https://b4mad.net/.well-known/did.json`.
- Define a minimal agent capability VC schema (JSON-LD).
- Issue network membership VCs to all current agents.

**Phase 2 (Q3 2026): Communication**
- Integrate DIDComm v2 into OpenClaw's agent-to-agent messaging.
- Implement VC-based authorization for bead operations (e.g., only agents with a "code-review" VC can close code review beads).
- Deploy short-lived credential rotation (24-hour cycle).

**Phase 3 (Q4 2026): Federation**
- Publish the #B4mad Agent Identity Specification as an open standard.
- Demonstrate cross-framework agent authentication (OpenClaw ↔ at least one external framework).
- Implement reputation VCs based on bead completion history.
- Evaluate ZKP-based selective disclosure for privacy-sensitive cross-network interactions.

### Technology Choices

| Component | Recommendation | Rationale |
|-----------|---------------|-----------|
| DID method (org) | did:web | Leverages existing DNS/TLS, easy to deploy, widely supported |
| DID method (agent) | did:key (ephemeral), did:web (persistent) | did:key for sub-agents and sessions; did:web for named agents |
| DID method (private) | did:peer | Pairwise, no ledger, perfect for bilateral agent channels |
| VC format | W3C VC Data Model 2.0 + JSON-LD | Standard, interoperable, supported by major libraries |
| Signing | Ed25519 (default), BBS+ (for selective disclosure) | Ed25519 is fast and ubiquitous; BBS+ adds privacy when needed |
| Transport | DIDComm v2 | Purpose-built for DID-authenticated messaging |
| Revocation | Short-lived credentials (24h) + StatusList2021 fallback | Simplest operational model; status list for emergency revocation |
| Libraries | `did-resolver` (JS), `didkit` (Rust/WASM), `aries-framework` (Python) | Mature, actively maintained, multi-language support |

## References

1. W3C. "Decentralized Identifiers (DIDs) v1.0." W3C Recommendation, July 2022. https://www.w3.org/TR/did-core/
2. W3C. "Verifiable Credentials Data Model v2.0." W3C Recommendation, March 2025. https://www.w3.org/TR/vc-data-model-2.0/
3. DIF. "DIDComm Messaging v2.0." Decentralized Identity Foundation, 2023. https://identity.foundation/didcomm-messaging/spec/v2.0/
4. DIF. "Presentation Exchange v2.0." Decentralized Identity Foundation, 2023. https://identity.foundation/presentation-exchange/spec/v2.0.0/
5. Smith, S. "Key Event Receipt Infrastructure (KERI)." IETF Internet-Draft, 2024. https://weboftrust.github.io/ietf-keri/draft-ssmith-keri.html
6. Ethereum Foundation. "EIP-8004: Trustless Agents." Ethereum Improvement Proposals, 2025.
7. European Commission. "European Digital Identity Framework (eIDAS 2.0)." 2024.
8. Sporny, M. et al. "Verifiable Credentials Implementation Guidelines." W3C Working Group Note, 2024.
9. Wikipedia. "Decentralized identifier." https://en.wikipedia.org/wiki/Decentralized_identifier
10. Butincu, C. et al. Research on decentralized identity management systems based on DIDs and SSI principles, referenced in W3C DID Core specification context.

---

*This paper was produced by Romanov (Roman "Romanov" Research-Rachmaninov), research specialist for #B4mad Industries, as part of bead beads-hub-wgq.*