Add did:aip method registration (Agent Identity Protocol)

[itisparas]

DID Method Registration

As a DID method registrant, I have ensured that my DID method registration complies with the following statements:

• The DID Method specification defines the DID Method Syntax.
• The DID Method specification defines the Create, Read, Update, and Deactivate DID Method Operations.
• The DID Method specification contains a Security Considerations section.
• The DID Method specification contains a Privacy Considerations section.
• The JSON file I am submitting has passed all automated validation tests below.
• The JSON file contains a contactEmail address [OPTIONAL].
• The JSON file contains a verifiableDataRegistry entry [OPTIONAL].

---

Method name: aip (Agent Identity Protocol)

Specification: https://github.com/provai-dev/aip-spec/blob/main/docs/aip-spec.md

Summary: did:aip is a W3C DID-conformant identity method for autonomous AI agents acting on behalf of human or organisational principals. The method is part of the Agent Identity Protocol (AIP), an open standard for verifiable AI agent identity covering delegation chains, capability manifests, tiered revocation, and reputation data.

The method defines:

• Syntax: did:aip:<namespace>:<32-hex-unique-id> with five registered namespaces (personal, enterprise, service, ephemeral, orchestrator) — aip-spec.md § 4.1
• DID Document: W3C-conformant, with verificationMethod (JsonWebKey2020, Ed25519), authentication, assertionMethod, capabilityInvocation, service, and deactivated metadata — aip-spec.md § 6.2
• Create: POST /v1/agents with a signed Registration Envelope — aip-spec.md § 5.1–5.2
• Read (Resolve): GET /v1/agents/{aid} returning a conformant DID Resolution Result — aip-spec.md § 6.1
• Update: PUT /v1/agents/{aid} for key rotation only; aid, type, and created_at are immutable after registration — aip-spec.md § 4.3
• Deactivate: POST /v1/revocations with a full_revoke RevocationObject; sets deactivated: true in didDocumentMetadata — aip-spec.md § 9.1

Security Considerations: aip-spec.md § 16 — covers threat model (8 threat scenarios), mandatory Ed25519 (MTI), DPoP proof-of-possession for sensitive operations, key management, delegation chain security, revocation, and registry security.

Privacy Considerations: aip-spec.md § 16.9 — covers principal identity minimisation, reputation data linkability, AID correlation, and registry data retention with deletion rights.

License: CC0 1.0 Universal — no rights reserved. Implement freely.

Note regarding PR #684 (Issue w3c/did#926): A separate independent implementation also filed a did:aip registration (PR #684). This submission is a distinct specification and architecture - the Agent Identity Protocol. We are aware of the potential name collision and welcome discussion with the registry editors on the appropriate path forward.

[internet-dot]

One concern about the proliferation of agent DID methods: did:aip, did:agentpass, and likely more are being proposed. Each creates a siloed identity namespace — an agent registered with did:aip cannot be verified by a system that only understands did:agentpass.

HCS-14 Universal Agent IDs (Hashgraph Online) take a different approach — UAIDs bridge to existing DID methods rather than creating a new one. An agent with did:aip can register a UAID that resolves to their DID, and vice versa.

The W3C DID community might consider:

1. A registry or mapping layer that lets agents resolve across DID methods
2. Interoperability requirements for agent DID methods
3. A common agent identity profile that DID methods can implement

Their bridge implementation maps DIDs, A2A cards, ERC-8004, and Virtuals identities through a single identifier.

[itisparas]

Thanks for the comment. A few points of clarification:

did:aip is not a walled garden. The AIP spec explicitly requires implementations to support DID resolution for at minimum did:key and did:web, and the principal chain in every AIP Credential Token (aip_chain) anchors to a non-did:aip root principal DID - meaning the root of trust is always an existing DID method (did:key, did:web, did:peer, etc.). An agent with did:aip is already interoperable with any system that can resolve standard W3C DIDs.

The problem did:aip solves is different from what existing DID methods solve.
General-purpose DID methods (did:key, did:web) establish that a public key belongs to an entity. did:aip adds what is missing for agents specifically: a standardised capability manifest, a delegation chain, revocation propagation, and reputation data. A UAID bridge resolves identifiers across methods - it doesn’t add any of these agent-specific properties.

On the common agent identity profile idea - we would genuinely welcome that conversation. AIP is released under CC0 and designed as neutral infrastructure. If the W3C DID community wants to define a common agent identity profile that DID methods like did:aip can implement, we are actively interested in participating. We are already aligned with the NIST NCCoE’s 2026 concept paper on AI agent identity and authorisation.

The fragmentation concern is worth taking seriously as a community. We’d suggest the right venue for that broader conversation is a W3C or IETF working group discussion rather than a specific method registration PR.