Agent Identity on Blockchain: DIDs and Verifiable Credentials

As AI agents become central to enterprise workflows, the question of agent identity shifts from theoretical to urgent. How do you cryptographically prove an agent is what it claims to be? How do you revoke its authority without centralized infrastructure? How do you port its identity across vendors without losing trust history?

Traditional identity systems—API keys, OAuth tokens, mutual TLS certificates—all assume a trusted issuer and a centralized revocation mechanism. They break down when agents operate across organizational boundaries or when you need to prove identity without revealing the infrastructure that issued it.

Decentralized identifiers (DIDs) and verifiable credentials (VCs) offer a different model: cryptographic proof of identity that's portable, composable, and revocable without gatekeepers.

Why Agents Need Decentralized Identity

Consider a typical agent deployment: a system reads email, extracts structured data, triggers downstream workflows. In a traditional model:

• Identity is tied to a single identity provider (Okta, Auth0, Cognito).
• The agent's capabilities are defined by its role within that provider.
• Portable to another company? Start over with new credentials.
• Revoke the agent? Delete the account; hope nothing breaks before the revocation propagates.

Now scale to a network of agents spanning multiple organizations—each with their own identity providers, approval workflows, and audit requirements. The coordination cost explodes.

DIDs solve this differently. Instead of "Agent ABC works for Company X," you have "This agent proves ownership of DID:z1A2B3...C4D5E6." The identity itself is a cryptographic object, independent of any single organization. Credentials issued to that DID can be verified by anyone holding the DID's public key, without contacting the issuer.

The DID and Verifiable Credential Stack

A DID is a globally unique identifier that resolves to a cryptographic public key and metadata. Unlike DNS names or URLs, a DID doesn't require a centralized registry—it can be anchored to a blockchain, a distributed ledger, or even a public/private key pair.

Common DID methods:

• did:key: Public key embedded directly in the identifier. No blockchain needed, no resolution latency.
• did:web: Resolved via HTTPS from a domain you control. Familiar to web developers; revocation is simple.
• did:ethr: Anchored to Ethereum. Immutable on-chain; suited for high-stakes identity or cross-organization trust.
• did:ion: Built on Bitcoin via a sidechain. Balances decentralization with transaction cost.

A verifiable credential is a cryptographically signed statement about an agent: "Agent with DID:z1A2... is authorized to submit orders up to $10,000 USD." The issuer signs it with their private key; anyone can verify it by resolving the issuer's DID and checking the signature.

The power emerges when you chain credentials. An agent might hold:

1. A credential from a legal incorporation body proving the company exists.
2. A credential from a compliance officer proving the company is SOC 2 certified.
3. A credential from your infrastructure team authorizing that specific agent to call the payments API.

A downstream service can verify all three without calling the issuer, and can revoke each independently.

Building a DID-Based Agent Authority System

Here's a rough architecture:

// Agent generates a keypair and derives a DID
import { randomBytes } from 'crypto';
import * as ed25519 from '@noble/ed25519';

const agentPrivateKey = randomBytes(32);
const agentPublicKey = await ed25519.getPublicKey(agentPrivateKey);
const agentDid = `did:key:z1${Buffer.from(agentPublicKey).toString('base64url')}`;

// Identity issuer (your org) creates a credential
const credentialPayload = {
  '@context': 'https://www.w3.org/2018/credentials/v1',
  'type': ['VerifiableCredential', 'AgentPermissionCredential'],
  'issuer': 'did:web:your-domain.com',
  'issuanceDate': new Date().toISOString(),
  'credentialSubject': {
    'id': agentDid,
    'permissions': ['read:customer-data', 'write:orders'],
    'expirationDate': new Date(Date.now() + 365 * 24 * 60 * 60 * 1000).toISOString()
  }
};

// Sign it with issuer's private key
const signature = await ed25519.sign(
  JSON.stringify(credentialPayload),
  issuerPrivateKey
);
credentialPayload.proof = {
  type: 'Ed25519Signature2018',
  signatureValue: Buffer.from(signature).toString('base64url')
};

// Agent now carries this credential in its auth header
// Verifier can validate without contacting the issuer

Revocation Without a Gatekeeper

Revocation is where DIDs shine. With traditional tokens, you need a revocation list or a real-time oracle. With DIDs anchored to blockchain:

• Revoke by publishing a revocation entry to the chain.
• Verifiers cache the DID document and recheck revocation status periodically.
• No single point of failure; no centralized revocation service required.

For lower-stakes scenarios, publish revocation lists at a stable URL in your DID document:

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:web:your-domain.com#agent-issuer",
  "publicKey": [...],
  "revocation": "https://your-domain.com/.well-known/revocation-list.json"
}

The list maps credential IDs to revocation timestamps. Verifiers fetch it periodically and reject any credential whose ID appears with an earlier issuance date.

Interoperability and Standards Compliance

DIDs are standardized under W3C specifications (DIDs 1.0, Verifiable Credentials Data Model 1.0). Build to the spec:

• Use standard @context URIs so verifiers recognize your credential types.
• Implement W3C-compatible proof formats (Ed25519Signature2018, EcdsaSecp256k1RecoverySignature2020).
• Test with reference implementations from platforms like Veramo or Hyperledger Indy.

This matters for portability. An agent identity issued by Company A should be verifiable by a workflow orchestrator at Company B without custom integration code.

Practical Deployment Considerations

Performance: Blockchain-anchored DIDs incur transaction latency. For agent identity, async resolution is acceptable—resolve the DID document once per session, cache it, and re-fetch on revocation check (hourly or on demand). Key-based DIDs are instant.

Compliance: Anchoring agent identity to a public blockchain creates an immutable audit trail—good for compliance, potentially problematic if the DID format itself is sensitive. Mitigation: use a did:key for the agent's technical identity, and issue a compliance credential linking it to a legal entity (which can be anchored to blockchain for regulatory purposes).

Interoperability cost: Not all your infrastructure supports VC verification out of the box. Plan a gradual rollout: proxy layer that converts VCs to OAuth tokens for legacy systems, deprecate those tokens as services migrate to native VC support.

Where This Wins

DIDs excel in:

• Multi-org agent networks: Agents from different companies verifying each other without a shared identity provider.
• Regulatory compliance: Immutable identity history, independent revocation, portable audit trail.
• Self-sovereign agent credentials: An agent "owns" its identity cryptographically; no organization can lock it away.

Avoid DIDs if:

• Your agents all operate within a single organizational boundary and you have mature Okta/Keycloak infrastructure. The overhead isn't worth it.
• You require synchronous identity validation in sub-millisecond SLAs. (Blockchain methods are not viable; key-based DIDs work fine.)

Conclusion

Decentralized identity standards give AI agents cryptographic autonomy and portable trust. Combined with verifiable credentials, they enable agent-to-agent interaction without centralized gatekeepers, audit trails that survive organizational changes, and revocation that's both instant (locally) and verifiable (globally).

Start with did:key for low-friction prototyping. Graduate to did:web for production deployments with domain control. Anchor to blockchain only when the immutability and regulatory compliance value justify the transaction cost.

The identity layer that works for humans shouldn't be forced onto agents. Build one that works for both.