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.

[github-actions]

🤖 AI Preliminary Specification Review

This is an advisory, automated review of the DID Method specification(s) referenced in this pull request, checked against the registration checklist. It does not replace review by the registry editors.

✅ All reviewed submissions passed the preliminary checklist review. A registry editor will still perform the final review.

methods/aip.json — method did:aip

Specification: https://www.ietf.org/archive/id/draft-singla-agent-identity-protocol-01.html

Preliminary verdict: ✅ PASS

The AIP Internet-Draft is a substantive, recognizable DID Method specification defining did:aip with clear syntax, operations, and security/privacy sections. All MUST criteria are satisfied, though privacy and IP posture generate minor advisory warnings.

	Item	Level	Status	Notes
✅	M1. Specification is reachable and is a DID Method specification	MUST	pass
✅	M2. DID Method Syntax is defined	MUST	pass
✅	M3. CRUD operations are defined	MUST	pass
✅	M4. Security Considerations section present and substantive	MUST	pass
⚠️	M5. Privacy Considerations section present and substantive	MUST	warn	A Privacy Considerations subsection exists (Section 21.10) but its prose was not present in the truncated text, so its substance could not be directly verified; treated as a warning rather than a block per the guidance to prefer warn when uncertain.
✅	M6. Method name is indicative and non-generic	MUST	pass
✅	M7. No unreasonable legal, security, moral, or privacy harms	MUST	pass
✅	M8. Human-readable description of the addition	MUST	pass
✅	S1. contactEmail present	OPTIONAL	pass
⚠️	S2. verifiableDataRegistry present	OPTIONAL	warn	A verifiableDataRegistry field is present but its value ('AIP - the AI Agent Identity Protocol') is a descriptive label rather than a clear statement of where DIDs are anchored (the spec describes a Registry Interface); consider clarifying.
⚠️	S3. Intellectual-property posture is clear	SHOULD	warn	The spec states it is released under CC0 (Section 1.2) but the IETF boilerplate applies BCP 78/79 and Revised BSD License; this mixed posture is a minor unresolved point worth an editor's attention, not a clear violation.

[ottomorac]

Hi @itisparas ,

I hear you out, and I think the naming conflict is unfortunate. However the DID working group is much too busy right now trying to deliver the DID Resolution spec to candidate recommendation status. I anticipate we will not be able to have a working group discussion about the naming collision for quite a few weeks (if not months).

Would you be willing to register your did method under a new acronym instead? I know this is not probably the answer that you want to hear, but as DID working group co-chair I have to be honest about our limited time and resources.

If you still want to register under did:aip let me know and I will put this on the list of things that the working group will need to address.

Regards,

Otto

[itisparas]

Hi @ottomorac — thank you for the candid update. We understand the Working Group’s current priorities.

Yes, we would like to continue seeking registration under did:aip. Renaming now would be a protocol-wide compatibility change across the published IETF draft and existing implementations, so we would prefer to have the naming collision considered by the Working Group.

Please add it to the list of matters the Working Group will address. We’re comfortable waiting and are happy to provide a concise factual timeline or participate in the discussion when useful.

Thank you.