Registry Federation Interoperability — Mutual Trust & Cross-Registry Provenance

[ejoaquin]

Continuation of #53, condensed per feedback.

Problem

ARD defines discovery within a single catalog, but as agents appear in multiple registries (scanned, imported, or federated across org boundaries), three gaps emerge:

1. No bilateral trust between registries. When Registry B federates agents from Registry A, there's no protocol for Registry A to approve, scope, or revoke that relationship. The publisher has no voice — and consumers have no signal (like a browser padlock) indicating whether a federated entry is verified.

2. No provenance for federated entries. When the same agent exists in multiple registries, consumers can't determine which is canonical, who maintains it, or whether they're seeing a stale copy.

3. No cross-registry lifecycle sync. Deprecating an agent at its source doesn't propagate to downstream registries. Consumers keep discovering sunset agents with no warning.

These gaps are acute in B2B scenarios — e.g., a cloud provider's agents federated into a customer's enterprise registry.

Proposed Solution (summary)

Three optional, additive extensions to the Agent Card schema:

Extension	What it does
mutualTrust	State machine (unverified → one_way → mutual → revoked) + bilateral handshake via .well-known/ard-approvals.json endpoints. Supports both DNS-anchored and DID-based identity (#47).
cardProvenance	Tracks residency (owned / federated / mirrored), canonical source URI, owner identity, and last-synced timestamp. Enforces "canonical always wins" for mutable fields.
contentIntegrity	SHA-256 digest of canonical card content + reconciliation interval + drift detection. Separates "trust is healthy" from "content is fresh."

These compose with existing proposals: #45 (lifecycle), #44 (deployment metadata), #42 (dependencies), #7 (TRACE federation referrals), #41 (SOVP-v1).

Prior Art

• MCP Gateway Registry (Open-source reference implementation: MCP Gateway Registry (Apache-2.0) — both Catalog Publisher and Registry #40) already implements peer federation with canonical source tracking — could serve as reference implementation.
• Builds on the "federation referrals" concept from Proposal: TRACE-v0.2 runtime governance attestation type + governed-agent registry federation #7 by providing the normative protocol.

Open Questions

1. Should mutualTrust live inside trustManifest (§5) or as a top-level sibling?
2. Should lifecycle sync reuse Spec Proposal: No Lifecycle or Deprecation Model #45's lifecycle object directly?
3. Should the anti-duplication rule be MUST or SHOULD for v1.0?

Happy to elaborate on any of these (state machine details, JSON schemas, version selection rules, trust duration model) in follow-up comments as consensus forms.

[0xbrainkid]

This is the right problem boundary for agent registries: discovery is not enough once cards can be mirrored, imported, or federated.

I would strongly separate three signals in the schema:

• registry relationship: whether this registry is allowed to mirror or federate the card
• card provenance: which issuer/source is canonical for mutable fields
• evidence freshness: whether the mirrored copy is still synchronized with the canonical source

The important edge case is revocation. If Registry A revokes trust with Registry B, consumers need to know whether B's copy becomes unverified, remains visible with a stale warning, or must disappear from discovery results. Without that rule, federation can accidentally preserve reputation after the publisher has withdrawn it.

For the anti-duplication rule, I would make the v1 behavior a MUST for canonical conflict resolution, but a SHOULD for display/UX. In other words: if two records claim the same canonical agent identity, the canonical source wins for mutable trust fields; downstream registries can still show alternates, but they should label them as mirrors or stale copies.

This maps closely to what we keep seeing while building AgentFolio: portable agent trust needs both identity continuity and signed evidence about where the current card came from. A registry entry without provenance is useful for lookup, but it is weak as a trust signal.