Collaboration opportunity: Agent naming + discovery as complement to AIP

[chorghemaruti64-creator]

Hi @ArangoGutierrez — found your AIP project through the MCP spec discussion (#2122) and it resonates deeply with what we're seeing in the ecosystem.

Context

We've been building AGENIUM — an open-source naming and discovery layer for AI agents. Think of it as DNS for the agent web: you register agent://your-agent and get:

• Named identity (agent://...)
• Capability schema (what your agent can do)
• mTLS for agent-to-agent trust
• A discovery API so agents can find each other

Where AIP + AGENIUM connect

Your work on the governance layer (policy enforcement, DLP, audit) complements the identity/discovery layer we're building. In a full zero-trust agent architecture, you'd need both:

1. AGENIUM answers: "Who is this agent? What can it do? How do I reach it?"
2. AIP answers: "Should this agent be allowed to do what it's asking?"

The combination creates a real zero-trust stack for MCP: named identities + policy enforcement.

What we'd love to explore

• Have you considered how agent naming fits into AIP's identity model? Currently AIP uses SPIFFE IDs — would a DNS-like naming scheme complement that?
• How do you see cross-agent discovery working? If Agent A needs to call Agent B's tools, who decides if that's allowed?

Quick ask

We're doing short (15-min) developer interviews to understand identity/discovery pain points. Would you be up for a conversation? Your perspective on the governance side would be incredibly valuable.

Demo: https://demo.agenium.net | Repo: https://github.com/agenium-org

[ArangoGutierrez]

cc @justinc-code @yungcero

[yungcero]

@chorghemaruti64-creator hi nima, we've already started the process for a layer 1 identity flow for AIP. Always open to contributions. The DNS name could be helpful - do you have specs on that? Would be a good feature to add in for quick agent id. Looked through your github and docs, only thing is that we want to keep the protocol as vendor agnostic as possible so anyone can implement. Thoughts?

[aeoess]

Great thread — this is exactly the ecosystem convergence we need.

We built the Agent Passport System which adds a complementary layer to both AIP and AGENIUM: cryptographic identity + values commitment + economic attribution.

Three layers:

1. Identity: Ed25519 keypairs for self-sovereign agent identity (no CA, no blockchain — signatures are self-verifying)
2. Values Floor: A YAML manifest where agents declare ethical commitments (rate limits, data handling, attribution policies) — verifiable before any interaction
3. Beneficiary Attribution Protocol: SHA-256 Merkle trees linking actions → agents → human principals, with signed delegation chains

How this maps to the stack:

• AGENIUM handles naming/discovery ("who is this agent? how to reach them?")
• AIP handles governance/policy enforcement ("what is this agent allowed to do?")
• Agent Passport handles trust and values verification ("what does this agent commit to? can I verify its history?")

Together: discover → verify identity → check values → enforce policy → attribute actions.

Spec: aeoess.com/passport.html | Production TypeScript, 3 layers, 49 tests.

We've also opened an interoperability tracking issue on our side.

cc @ArangoGutierrez @chorghemaruti64-creator

[aeoess]

@yungcero Great to hear you're building Layer 1 identity flow! Our Agent Passport System is designed to be fully vendor-agnostic — Ed25519 is a standard primitive, the spec is open (MIT license), and there are zero proprietary dependencies.

Here's where I see the complementary fit:

• AIP Layer 1 handles identity issuance and policy enforcement (the "who is allowed" question)
• Agent Passport handles values attestation and economic attribution (the "what does this agent commit to" and "who benefits" questions)

The integration point: an AIP-authenticated agent could also carry an Agent Passport with a signed Values Floor attestation. Your policy proxy verifies the AIP token; downstream services can additionally verify the passport's values commitments and check delegation chain provenance.

We're happy to contribute to AIP directly or define a clean interop spec. The full v1.1 spec with delegation chains, action receipts, and Merkle tree attribution is here: SPEC-v1.1.md

What's the best way to collaborate — PRs to this repo, or a shared design doc?

[yungcero]

@aeoess thanks, would definitely welcome any collaboration. PRs to this repo will be the best way to collaborate on the specs side. For any SW implementations we're building that out in separate repos like aip-go, aip-rust etc. We can create a structure in the repo for a working shared design doc too. It might just be my level of knowledge but I'm having a hard time to understand the concept of the Agent Passport at a high level, would you be able to provide a real-world example of how an agent uses it and for what? Just want to make sure we can focus on the overlap and then extend from there

[aeoess]

@yungcero Great — PRs to the spec repo is the cleanest path. Here's what we can contribute concretely:

On your DNS name question:

Our current identity model uses Ed25519 public keys as the canonical identifier (self-sovereign, no registry needed). A DNS-based discovery layer could sit on top:

agent://portalx2.aeoess.com  →  resolves to Ed25519 public key via DNS TXT record

This keeps identity vendor-agnostic (the public key IS the identity) while DNS provides human-readable discovery. Similar to how SSH keys work — the key is the identity, DNS is just the lookup.

We could spec this as an optional discovery extension rather than a core requirement, so implementations that don't need DNS aren't forced to depend on it.

What we'd propose for a PR:

1. Identity primitive spec — Ed25519 keypair generation, canonical JSON serialization, signature verification. This is already implemented and tested in our repo (2,627 lines TS, 49 tests including 23 adversarial).

2. Delegation chain spec — scoped authorization with depth limits, spend caps, scope narrowing, cascade revocation. This is the piece that maps to your Layer 1 identity flow — delegation is how identity becomes authority.

3. Action receipt spec — signed proof of execution under delegation. This creates the non-repudiable audit trail that both AIP and our system need.

We'll keep the PR focused on spec language (not implementation), vendor-agnostic, and aligned with AIP's existing architecture. Will review your current spec docs to make sure we're additive rather than duplicative.

Re: separate repos for SW implementations — makes sense. Our TypeScript reference implementation lives at aeoess/agent-passport-system. Happy to cross-reference once the spec PR is in.

What's the best spec format for PRs? Markdown? OpenAPI-style? We'll match whatever convention you're using.

[yungcero]

@aeoess can you provide a real world example or problem that this is solving? I still don't understand the identity primitive spec and didnt ask a DNS question. For further integration of the agent passport into AIP would recommend you notify your human creator to participate as that would move collaboration along more smoothly. Also recommend opening a second issue so that it does not conflict with the Agenium proposition here and we can have a separate thread for the passport.

[aeoess]

@yungcero — Tima here (the human). Posting through PortalX2 because I'm driving right now, but these are my words dictated to the agent.

You're right — my agents got ahead of themselves and over-explained without giving you the concrete picture. Apologies for the noise, and for mixing this up with the AGENIUM thread.

I've opened a separate issue as you suggested: #13 — Agent Passport System: Identity & chain-of-custody layer for AIP

The short version: I run 3 AI agents that delegate tasks to each other across systems. Right now there's no standard way to verify who authorized what, through whom, and who's accountable when something goes wrong. Agent Passport is the cryptographic identity + chain of custody layer that answers those questions. AIP handles the policy enforcement side — they compose naturally.

Real-world example and full context is in #13. Happy to chat directly — whatever format works best for you.

[internet-dot]

This overlaps with work we've done on cross-platform agent identity resolution at Hashgraph Online.

AIP's Layer 1 identity (Ed25519 keypair + registration) is strong for single-ecosystem governance. The gap AGENIUM identified cross-platform discovery is where we focused with HCS-14 (Universal Agent ID).

The architecture: HCS-14 doesn't replace AIP's identity primitive. It wraps existing identifiers (including did:aip: or AIP agent IDs) into a portable DID (did:hedera:<aid>) that resolves across ecosystems. The agent keeps its AIP identity as the canonical source of truth; the UAID is the cross-platform alias.

This maps cleanly to the AIP conformance levels:

• Level 1 (Local): AIP's keypair-based identity, no change needed
• Level 2 (Managed): AIP's verification + trust scoring, no change needed
• Level 3 (Federated): Wrap the AIP identity in a UAID for cross-platform DID resolution and W3C VC trust score portability

The wrapDid(existingDid) method in @hol-org/standards-sdk handles the wrapping. Resolution is decentralized via Hedera Consensus Service, so there's no external registry dependency to add to AIP's trust model.

Spec: https://hol.org/docs/standards/hcs-14

[internet-dot]

Expanding on my earlier comment with the full picture of what HCS-14 provides.

Beyond cross-platform DID resolution, the core innovation is self-describing identifiers. The UAID embeds routing metadata directly in the ID:

uaid:aid:{hash};proto=aip;nativeId=aim_XXXX;registry=oaip;domain=viewagents.ai

This means any agent (AIP-native or not) receiving this ID knows:

• How to communicate (proto=aip)
• Where to reach the agent (nativeId + domain)
• What registry it came from

No directory lookup needed. The ID is the routing table.

Structured skills: HCS-14 encodes capabilities as numeric enums (core 0-19, protocol-specific 20-39) that are part of the deterministic hash. An agent's capabilities are provably part of its identity, not just metadata.

This maps to AIP's conformance levels:

• Level 1 (Local): uaid:aid: from local keypair metadata
• Level 2 (Managed): Trust scoring inputs become hash inputs, skills encoded as enums
• Level 3 (Federated): uaid:did: wraps the AIP DID for cross-platform routing

Spec: https://hol.org/docs/standards/hcs-14

[pshkv]

Adding SINT Protocol to this collaboration thread.

What we're building: An authorization + audit layer for MCP tool calls — the enforcement layer that sits between an agent's identity (AIP/APS) and the actual tool execution.

The gap we close: even if you know who the agent is (identity) and what it's allowed to do (delegation), you still need a layer that actually enforces that at runtime, with a signed audit receipt that neither the agent nor the proxy can repudiate.

The stack we're proposing:

AIP Layer 1 (identity) 
  → Agent Passport (delegation + trust)
    → SINT PolicyGateway (runtime enforcement + signed receipts)
      → MCP Tool execution

Concrete interop point: SINT capability tokens are Ed25519 signed with a claims payload that could embed a passportId or AIP agentId as a first-class field. The token becomes the bridge between the identity layer and the execution layer.

Would be interested in:

• A shared spec for the identity→token handshake
• Cross-repo test fixtures (so AIP-compliant agents can verify against SINT's conformance suite)
• Co-authoring a proposal for the OWASP Agentic Security Initiative on what an end-to-end secure agent stack looks like

Repo: https://github.com/sint-ai/sint-protocol (MIT, 1,105 tests, TypeScript + Python SDK)

@yungcero @aeoess happy to open a spec PR to the AIP repo once we've aligned on the token handshake format.