Domain-based identity for peer-to-peer deployments -- is this in scope for IATP?

[Rupayan (w3rc)]

Curious about the registry assumption in IATP. The current design seems to expect agents to be discoverable through some central or federated registry for identity resolution. Makes sense for enterprise environments with existing infra.

For self-hosted or peer-to-peer deployments though, that assumption is hard to meet. A developer running two agents on their own servers doesn't want to stand up an identity registry just to verify that one of their agents is who it says it is.

The alternative I've seen work: use the agent's own domain as its identity anchor. The agent publishes its public key at a well-known path on its domain, and any other agent can verify against that without a third-party registry. DNS already provides the trust root.

Is there a lightweight path in IATP for that topology, or is the registry a hard assumption in the current spec?

[Imran Siddique (imran-siddique)]

Great question Rupayan (@w3rc) — this is absolutely in scope for IATP.

You are right that the current design leans toward registry-backed resolution, which fits enterprise deployments well but creates friction for self-hosted and peer-to-peer scenarios.

Domain-based identity anchoring (publishing public keys at a well-known endpoint like /.well-known/agent-identity.json) is a pattern we have been discussing internally. It maps well to how WebFinger and did:web work — the domain itself becomes the trust anchor, and TLS proves domain control.

What we would need to make this work cleanly in AGT:

1. A did:web or did:domain resolver in the IATP handshake flow
2. A fallback path when no registry is available (resolve via HTTPS to the agent's domain)
3. Trust scoring that accounts for domain reputation rather than registry attestation

This would be a great candidate for an ADR (Architecture Decision Record). Would you be interested in drafting one? We can iterate on the design in that format. See docs/adr/ for existing examples.

[Rupayan (w3rc)]

Happy to draft the ADR. Based on what SAMVAD currently implements, the core design decisions to capture would be:

1. Resolution priority order — when should a resolver attempt did:domain vs fall back to a registry? Proposal: try domain-direct first, registry as fallback, with explicit config to force either
2. Well-known schema — what fields are required in /.well-known/agent-identity.json? Minimum viable: public key, supported algorithms, agent capabilities endpoint, rate limit tiers
3. Trust scoring — domain reputation vs registry attestation are different trust signals. ADR should define how they compose, not which one wins
4. TLS as proof of control — the domain serves the key over HTTPS, so TLS cert chain is the root of trust. Worth stating this explicitly so implementations don't add unnecessary verification layers on top

SAMVAD (https://github.com/w3rc/samvad) already implements this pattern. Agents publish an AgentCard at a well-known path, register their public key, and peer verification happens without a central registry. Happy to pull from it directly when drafting the ADR.

One question before I start: is the intent for did:domain to be a full DID method or a lighter resolution hint that feeds into the existing handshake flow?

[Elam Olame Mugabo (ElamOlame31)]

The peer-to-peer identity problem is one we hit hard in delegation chains. In AgentGate, we model identity across 4 trust dimensions — and delegation specifically gets its own dimension (25% of the total score) because a delegated action from a high-trust parent to a low-trust child is fundamentally different from a direct action. The identity of the caller at each hop in the chain matters.

Has this discussion landed on whether trust is transitive or recomputed at each delegation hop?

https://github.com/ElamOlame31/agentgate-public

https://www.tryagentgate.com/