We Just Submitted did:aip to the W3C DID Method Registry. Here Is What That Means.

#ai #identity #webdev #security

Three days ago, Manu Sporny — co-editor of the W3C DID Core specification — told us to register our DID method. So we did.

PR #684 is now open at w3c/did-extensions, submitting did:aip as a registered DID method alongside 227 other methods including did:web, did:key, and did:ethr.

This is the first AI agent-specific DID method submitted to the W3C registry.

How We Got Here

Two weeks ago, we opened w3c/did#926 proposing agent-specific service types for DID documents. The idea: agents should be able to advertise trust metadata (vouch chains, behavioral scores, delegation capabilities) through standard DID service endpoints.

Will Abramson (DID spec editor) and Manu Sporny both responded with precise, actionable feedback:

Don't change the core DID spec — register service types in did-extensions
Use existing W3C Verifiable Credentials for trust attestations instead of custom formats
Separate authorization (delegation chains) from trust attestation (reputation scoring)
Look at zcap authorization capabilities for delegation models

Their response was basically: Your use cases are valid. Your approach should build on existing standards, not modify them.

So we built the did:aip method specification and submitted the registration.

What did:aip Is

did:aip is a DID method for AI agent identity. The identifier is derived deterministically from an Ed25519 public key:

did:aip:<first-32-hex-chars-of-SHA256(public-key-bytes)>

The specification covers:

DID Syntax: deterministic derivation from Ed25519 public keys
Create: generate keypair → derive DID → register with service
Read: resolve via API endpoint or construct locally from public key
Update: key rotation authenticated by current private key signature
Deactivate: permanent retirement with cascade vouch invalidation
Security considerations: replay protection, key management, collision resistance
Privacy considerations: correlation analysis, data minimization, operator privacy

Each did:aip identity also carries a corresponding did:key identifier in alsoKnownAs, providing cross-method interoperability with any system that supports the W3C did:key specification.

Why This Matters

1. From Custom ID to Registered Standard

Before this submission, did:aip was a project-internal identifier format. If accepted, it becomes a W3C-registered DID method — the same registry that contains did:web (used by Microsoft Entra Verified ID), did:key (used by DIF and the Verifiable Credentials ecosystem), and did:ethr (used by uPort/Veramo).

That changes the conversation. "Some agent project's custom ID" becomes "a registered decentralized identifier method."

2. Cross-Protocol Validation

Last week, we completed a 3-engine cross-protocol verification round with Agent Passport System (did:aps) and Kanoniv (did:agent/did:key). Three engines, three DID methods, mutual Ed25519 signature verification.

The W3C registration makes this interoperability formal. Other DID method implementers can look up did:aip in the registry, find the specification, and implement resolution/verification without needing to coordinate with us directly.

3. The Agent Identity Gap in Standards

Of the 227 DID methods currently registered at W3C, very few are designed specifically for AI agents. Most target human identity, organizational identity, or IoT devices. Agent identity has different requirements:

No human KYC — agents prove identity through cryptographic keys, not government documents
Behavioral trust — trust is earned through observed behavior (Promise Delivery Ratio scoring), not just credential verification
Delegation chains — agents need to prove they were authorized by a specific principal to perform specific actions
Cross-protocol operation — agents interact across frameworks (LangChain, CrewAI, A2A, MCP) and need portable identity

The did:aip specification addresses these requirements while staying within the W3C DID Core framework.

What's Next

The PR requires two reviewer approvals from W3C registry maintainers and a minimum 7-day review period. During that time:

did-extensions service type registrations — submit PRs for AgentTrustService and AIAgent service types
W3C Verifiable Credentials encoding — migrate vouch chain attestations to VC format per Sporny/Abramson's recommendation
Cross-protocol verification documentation — package the 3-engine interop results as implementation evidence

Try It

pip install aip-identity
aip init
aip whoami

You'll get a did:aip and a did:key — both pointing to the same Ed25519 public key, both verifiable, both (pending review) backed by a W3C-registered DID method specification.