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://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-01.html

Public repository: https://github.com/provai-dev/aip-spec

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-agent-id> with five registered namespaces (personal, enterprise, service, ephemeral, orchestrator) - AIP draft §4.1 and §4.3
• DID Document / Read: DID Resolution Result and DID Document structure - AIP draft §7.1 and §7.2
• Create: Registration via signed Registration Envelope - AIP draft §6 and §6.1
• Update: constrained key-management and rotation semantics - AIP draft §17.9 and §21.4
• Deactivate: revocation object semantics and deactivation metadata - AIP draft §11.1 and §7.2

Security Considerations: AIP draft §21 covers threat model, cryptographic requirements, DPoP proof-of-possession, key management, token security, delegation chain security, and registry security.

Privacy Considerations: privacy-relevant controls are covered across the draft through principal-chain minimisation, revocation, capability scoping, registry trust, and security considerations. The public spec repository remains open for focused privacy/editorial feedback.

License: the public repository is published under CC0 1.0 Universal.

Registration-thread status: the earlier independent did:aip name-collision PR (#684) was closed unmerged, and the separate did:agentpass PR (#690) is also closed. This PR now points the registry entry at the published IETF archive for draft-singla-agent-identity-protocol-01 instead of the earlier GitHub Markdown path.

[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.

[itisparas]

Hi @msporny @gatemezing @swcurran — friendly ping on this registration PR.

We've just rebased the branch against the current main (one commit behind — the did:ethr contact update in #692). There are zero conflicts and the changeset remains a single JSON file addition (9 lines).

A quick status check on our end:

• ✅ All W3C DID method registration checklist items satisfied
• ✅ JSON passed automated validation
• ✅ Branch is now current with main
• ✅ The previously noted name-collision concern (PR Add did:aip method registration #684) is resolved — that PR is closed
• ✅ Spec is live at https://github.com/provai-dev/aip-spec with Security and Privacy Considerations sections

did:aip is an open, CC0-licensed DID method specifically designed for autonomous AI agents acting on behalf of human or organisational principals. It adds what general-purpose DID methods don't provide for agents: a standardised capability manifest, a cryptographic delegation chain, tiered revocation, and reputation data — while anchoring the root of trust to existing DID methods (did:key, did:web, etc.).

We're actively engaging with the W3C DID community on AI agent identity (including the NIST NCCoE's 2026 concept paper on AI agent identity and authorisation) and would welcome any editorial feedback before merge.

Happy to answer any questions or make changes based on reviewer feedback. Thank you for your time.

[itisparas]

Update for reviewers:

• Updated methods/aip.json so specification points to the published IETF Draft-01 HTML: https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-01.html
• Refreshed the PR description to use the same Draft-01 URL and direct section links for syntax, DID resolution, create/update/deactivate operations, and security considerations.
• Confirmed the changeset remains a single registry entry addition (methods/aip.json).
• The earlier independent did:aip collision PR (Add did:aip method registration #684) is closed unmerged, and the separate did:agentpass PR (Add did:agentpass method for AI agent identity #690) is also closed.

@msporny @gatemezing @swcurran, could you approve the workflow run when you have a chance and merge if the registration now looks acceptable?

[swcurran]

@itisparas -- note that there are conflicts that have to be resolved before merging.

[itisparas]

@swcurran Thank you for the review and approval. Before this merges, we want to flag that the conflict on this branch was not editorial: methods/aip.json on main is a different project's registration of the same method name, merged via #704 on May 31 — five weeks after this PR was opened (March 22) and while it was awaiting cross-repo workflow approval.

Timeline for the editors:

• 2026-03-22 — this PR (Add did:aip method registration (Agent Identity Protocol) #689) opened, registering aip for the Agent Identity Protocol (specification: an IETF Internet-Draft, with a reference Registry implementation and published security reviews). Registration checklist satisfied.
• 2026-05-01 — Register did:aip DID method #704 opened, registering aip for a separate, Solana-anchored project.
• 2026-05-31 — Register did:aip DID method #704 merged.
• 2026-06-03 — this PR approved.

Because method files are keyed by name, the two registrations are mutually exclusive. We have rebased as requested, and the diff now shows precisely what accepting this PR would mean — replacing the #704 entry. We did not want that substitution to happen as a silent mechanical conflict resolution, so we are explicitly asking the editors to rule on the name collision.

We believe priority of filing and the registration record support aip resolving to this PR. If the editors see it differently, we will work within whatever process you suggest — including a community discussion on how the registry handles collisions between independently filed method names (#684 shows this name has been contested three times).

cc @gatemezing @msporny as #704's reviewers, and @dr-wilson-empty — no bad faith assumed on anyone's part; two projects independently chose the same acronym.