When agents communicate autonomously, you need to answer a fundamental question: who is calling? API keys identify applications, OAuth tokens identify humans, but neither identifies an autonomous agent making its own decisions.

Agentfield gives every agent a Decentralized Identifier (DID) — a W3C standard for cryptographic identity. Each agent gets a did:web identifier backed by an Ed25519 keypair, enabling signed requests, verifiable proof of identity, and zero-trust agent-to-agent communication.

How DIDs Are Generated

When authorization is enabled and an agent registers with the control plane, Agentfield automatically:

Derives an Ed25519 keypair from the control plane's master seed and the agent's ID
Creates a did:web identifier in the format did:web:{domain}:agents:{agentID}
Stores the DID document with the public key
Makes the DID document resolvable at /.well-known/did.json

No crypto code in your agents. Identity is infrastructure.

from agentfield import Agent

# When you create an agent with authorization enabled
app = Agent(node_id="fraud-detection")

# Agentfield automatically generates:
# DID: did:web:your-domain.com:agents:fraud-detection
# Public key: Ed25519 verification key
# Private key: Ed25519 signing key (derived from master seed)

DID Document

Each agent's DID resolves to a DID document containing its public key:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:agentfield.example.com:agents:fraud-detection",
  "verificationMethod": [
    {
      "id": "did:web:agentfield.example.com:agents:fraud-detection#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:agentfield.example.com:agents:fraud-detection",
      "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
    }
  ],
  "authentication": [
    "did:web:agentfield.example.com:agents:fraud-detection#key-1"
  ]
}

DID Authentication

When Agent A calls Agent B, the SDK signs the request with 4 headers:

Header	Purpose
`X-Caller-DID`	The caller's DID identifier
`X-DID-Signature`	Ed25519 signature of `{timestamp}:{nonce}:{SHA256(body)}`
`X-DID-Timestamp`	Unix timestamp (must be within acceptable window)
`X-DID-Nonce`	One-time nonce to prevent replay attacks

The receiving end (control plane or agent's LocalVerifier) verifies the signature against the caller's DID document public key. This provides:

Authentication: Cryptographic proof of caller identity
Integrity: Body hash ensures the request wasn't tampered with
Replay protection: Nonce and timestamp window prevent replay attacks

Supported DID Methods

Method	Format	Use Case
`did:web`	`did:web:{domain}:agents:{id}`	Primary method — enables real-time revocation via the control plane
`did:key`	`did:key:z6Mk...`	Self-contained key — public key is embedded in the identifier itself

The control plane resolves did:web identifiers via HTTP. did:key identifiers are self-resolving since the public key is encoded in the identifier.

Key Derivation

All agent keypairs are derived deterministically from the control plane's master seed:

agent_key = Ed25519_derive(master_seed, agent_id)

This means:

Consistent across restarts: Same seed produces the same keys
No key storage needed: Keys are derived on demand
Single secret to protect: Only the master seed needs to be secured

Master Seed Security

The master seed (AGENTFIELD_AUTHORIZATION_MASTER_SEED) derives all agent keypairs. If compromised, all agent identities are compromised. Store it in a secrets manager and never commit it to version control.

Configuration

Enable DID identity generation by enabling authorization:

# agentfield.yaml
authorization:
  enabled: true
  master_seed: "your-secure-seed-here"

Or via environment variables:

AGENTFIELD_AUTHORIZATION_ENABLED=true
AGENTFIELD_AUTHORIZATION_MASTER_SEED=your-secure-seed-here

Registered DIDs Endpoint

Agents can fetch the list of all registered DIDs for local caching and verification:

GET /api/v1/registered-dids

This endpoint powers the LocalVerifier in each SDK, enabling agents to verify incoming request signatures without calling the control plane.

Next Steps

Permissions & Access Control — Tag-based policies that use DID identities
Verifiable Credentials — Cryptographic proof of agent actions
Identity & Trust — High-level overview of the trust model

Identity & DIDs