did:key is a W3C-registered DID method specified by the W3C Decentralized Identifier Working Group. The DID string itself encodes the public key as a multibase-encoded multikey, so resolution is purely local and requires no network lookup, no blockchain, and no centralised registry.

Why Ed25519 for agent passports?

Ed25519 is an Edwards-curve digital signature algorithm specified in RFC 8032. Signatures are 64 bytes, public keys are 32 bytes, signing is deterministic, verification is fast, and the algorithm is widely supported across Rust, Python, Node, Go, and Apple/Android platform crypto. It is the default signature suite for did:key in the W3C registry.

What is the W3C Verifiable Credentials Data Model?

VCDM 2.0 is a W3C Recommendation that defines the JSON-LD structure of a verifiable credential: issuer, subject, claims, proof. The agent passport pattern wraps an agent identity in a VCDM credential signed by the operating organisation.

Does did:key require a blockchain?

No. did:key is deliberately ledger-free. The DID is the public key in multibase encoding. Anyone with the DID can verify a signature locally.

What is an agent passport? did:key, Ed25519, and the W3C VC path

Cryptographic identity for an autonomous agent, explained from first principles. No ledger, no central authority, no API call.

The Problem Before The Solution

An autonomous agent calls an API on behalf of a user, or hands a task to another agent, or signs a transaction in a marketplace. The receiving system needs to answer two questions: which agent is this, and can the agent prove it. An API key answers neither. The key identifies the holder of the key, which may or may not still be the agent that was issued the key, and it cannot be presented to a third party as evidence.

The agent-passport pattern answers both questions with cryptography rather than with shared secrets. The agent has a keypair. The agent's identifier is the public key. A signature on a request is a signature anyone can verify, by anyone, offline.

did:key: A DID That Carries Its Own Key

The W3C Decentralized Identifier Working Group registered a family of DID methods. Most of them — did:web, did:ion, did:ebsi — require network resolution. did:key does not. The DID string itself is the multibase-encoded multikey of the public key.

An Ed25519 did:key looks like this:

did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH

The z prefix is the multibase base58btc tag. The bytes that follow decode to a multicodec prefix (0xed01 for Ed25519 public key) plus the 32-byte raw public key. Resolution is a function call, not a network call. Anyone with the DID can verify a signature without contacting any server.

The trade-off is rotation: a did:key cannot be rotated without becoming a different did:key. For long-lived organisational identity that is a problem. For per-agent identity issued by a parent organisation it is a feature: rotation means revocation, and revocation means issuing a new passport.

Ed25519: Why This Curve

Ed25519 is the Edwards-curve variant of the EdDSA signature scheme specified in RFC 8032. It has properties that matter for agent identity:

Deterministic signatures. The same message signed with the same key produces the same signature. No nonce-reuse failure mode (the class that broke the Sony PS3 ECDSA implementation in 2010).
Small footprint. 32-byte public key, 64-byte signature. An agent passport with a signature fits comfortably in a JWT header.
Fast verification. On commodity x86_64 hardware, Ed25519 verification is in the tens of microseconds. A gateway can verify every request without becoming the bottleneck.
Wide language support. First-class support in Rust (ed25519-dalek), Python (pynacl, cryptography), Node (built-in crypto), Go (crypto/ed25519), and Apple Secure Enclave / Android Keystore on recent OS versions.

The one caveat: on iOS the Secure Enclave hardware is P-256 only, not Ed25519. Apple-platform agents that need hardware-bound keys use P-256 with a separate DID method (did:key with multicodec 0x1200), and the verifier negotiates suite.

The W3C VC Wrapper

A bare did:key proves "someone holding this private key signed this thing". It does not prove "this agent was issued by ACME Corp on 2026-05-25 for purpose X with valid-from / valid-until dates". That is what the W3C Verifiable Credentials Data Model 2.0 wrapper adds.

A minimal agent passport as a VCDM 2.0 credential:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "AgentPassport"],
  "issuer": "did:web:acme.example",
  "validFrom": "2026-05-25T00:00:00Z",
  "validUntil": "2026-08-25T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
    "agentName": "acme-research-agent-12",
    "purpose": "literature-review"
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-jcs-2022", ... }
}

Three identities are in play. The issuer (the organisation) signs a credential whose subject (the agent) holds a separate keypair. At runtime the agent presents the credential plus a fresh signature over the request payload. The verifier checks: issuer signature valid, validity window open, subject signature valid, claim about purpose satisfied. Four checks, all offline.

Why This Is The Path, Not An Option

The agent-identity space in 2026 has three live patterns: API keys (the legacy default), OAuth client credentials (a transitional pattern), and DID + VC (the standards-based destination). The first two cannot satisfy Article 26 paragraph 4 (monitoring + traceable input) or paragraph 11 (cooperation with authorities) once the deployment scales beyond a single tenant, because neither produces an artefact a third party can verify offline.

did:key + Ed25519 + VCDM 2.0 is the only stack today where every component is a stable W3C standard, every signature can be verified by a regulator without a back-channel to the issuer, and the operational footprint is small enough to embed in a serverless function. It is the path the AiEGIS Identity layer ships by default.

Try It

The full machine-readable Agent Passport schema is at /.well-known/agent-passport-schema.json. The issuance walkthrough — from cargo install to first signed credential — is in how to issue an agent passport. The full identity layer documentation is at /identity.