Agent Identity — Beyond DNS

The Identity Problem

When a human visits a website, a TLS certificate is enough. The padlock icon says: "This server controls example.com." But when an autonomous agent selects another agent to delegate a financial analysis task, it needs answers to fundamentally different questions:

• What can you do? — Capabilities, supported input/output modalities, latency budgets
• Who vouches for you? — Certifications, audit trails, trust scores backed by usage evidence
• How do I verify all of this without trusting any central authority?

DNS answers none of these. W3C Decentralized Identifiers (DIDs) solve the who; Verifiable Credentials (VCs) solve the what. The NANDA ecosystem weaves both into a unified identity layer through the AgentFacts format.

The Three-Layer Architecture

The NANDA Index resolves agent identity through three tiers, each designed for a different performance profile:

The resolution flow is: AgentName → NANDA Index → AgentAddr → AgentFacts → Agent Endpoint. By separating static identity from dynamic metadata and live routing, each layer can scale independently — the Index handles billions of lookups per second while AgentFacts documents update in real time without touching the core Index.

The AgentFacts Format

AgentFacts is an open JSON schema that extends the basic A2A Agent Card concept with the fields agents actually need for trust, discovery, and commerce. Every AgentFacts document contains:

• Identity — Unique ID, URN-based agent name, human-readable label, version, and jurisdiction
• Provider — Organisation details with optional DID-based verification
• Endpoints — Static API URLs plus adaptive resolver configuration with geo/load/threat-shield policies
• Capabilities — Supported modalities (text, audio, video, image), authentication methods, streaming and batch support
• Skills — Fine-grained skill definitions with input/output modes, language support, token limits, and latency budgets
• Evaluations — Performance scores, availability stats, audit trails stored on immutable infrastructure (e.g. IPFS), and third-party auditor IDs
• Telemetry — Real-time metrics: p95 latency, throughput, error rate, with configurable retention and sampling
• Certification — Trust level (self-declared, verified, audited), issuer, and validity period

The format is designed for progressive disclosure. A minimal AgentFacts document requires only identity, provider, endpoints, capabilities, and skills — the eight required fields from the JSON schema. Advanced fields like evaluations, telemetry, and certification are optional but become critical as agents participate in higher-stakes interactions.

DIDs and Verifiable Credentials

AgentFacts provides the what — rich capability metadata. But how do you know the metadata is authentic? This is where Decentralized Identifiers and Verifiable Credentials complete the picture.

A DID like did:web:knowyourmodel.ai:agents:abc123 is a globally resolvable identifier that any system on the internet can verify without trusting a central authority. The agent's provider controls the DID document, which contains the public keys needed to verify signatures on the agent's credentials.

Trust authorities like KnowYourModel then issue W3C Verifiable Credentials that attest to specific claims about the agent — its capabilities, its trust score, its compliance status. Each VC is signed with the EdDSA cryptographic suite (eddsa-rdfc-2022) and includes Bitstring Status List revocation, meaning any credential can be invalidated instantly without waiting for a certificate to expire.

Why This Matters

The combination of AgentFacts + DIDs + VCs creates an identity system with properties that no prior web architecture provides:

In Part 3, we'll explore how these identities compose into trust networks through the Quilt architecture — the federated registry model that lets trust scale across organisational boundaries without a central authority.