Spec Proposal: Federation Governance Metadata — Provenance, Mutual Trust & Execution Contract

[ejoaquin]

Problem

ai-catalog defines a publishing format with identity verification (trustManifest), source lineage (provenance[]), legal terms (termsOfServiceUrl, privacyPolicyUrl), and structural federation via nested catalogs (Design Goal #5: Scalable Federation). The recent proposals for dependencies (#63), deployment metadata (#64), and lifecycle (#65) fill additional gaps for single-registry use.

But structural federation (catalog A links to catalog B) has no governance layer. When catalogs get consumed by other registries — federated, mirrored, or aggregated across org boundaries — three governance gaps remain:

1. No residency semantics. provenance[].relation tracks build lineage ("publishedFrom", "derivedFrom") but has no vocabulary for registry-level residency: is this entry owned here, federated from elsewhere, or an unverified mirror?
2. No bilateral consent. trustManifest.trustSchema defines a trust framework but doesn't model bilateral consent between registries — publisher A approving registry B to federate their entries, with scoping and revocation.
3. No structured execution terms. termsOfServiceUrl and privacyPolicyUrl point to legal documents but provide no machine-readable policy for runtime enforcement — quota limits, data residency requirements, SLA targets.

These gaps are acute in B2B scenarios — e.g., a SaaS provider's agents federated into a customer's enterprise registry. Neither MCP nor A2A address cross-registry governance at the protocol level.

Suggested Direction

Building on existing Trust Manifest primitives:

Extend Provenance Link vocabulary for federation residency:

• New relation values: "federatedFrom", "mirroredFrom"
• New optional field: residency enum (owned / federated / mirrored)
• New optional field: lastSynced (datetime — when this copy was last reconciled with source)

mutualTrust — bilateral consent state machine (distinct from trustSchema):

• trustSchema = what framework governs an artifact. mutualTrust = who has agreed to federate it.
• State machine: unverified → one_way → mutual → revoked
• Negotiation via .well-known endpoints (DNS) or DID Document service endpoints (decentralized)

executionContract — structured complement to existing termsOfServiceUrl:

• Machine-readable runtime policy: quota limits, data handling rules, SLA targets
• termsOfServiceUrl remains the human-readable legal doc; executionContract is the machine-parseable counterpart

Interoperability Impact

• Additive and optional — existing catalogs remain conformant.
• Extends, doesn't replace — Provenance Link gains new relation types; termsOfServiceUrl is complemented, not superseded; Trust Schema is untouched.
• Composes with Spec Proposal: Dependencies manifest #63-Spec Proposal: No Lifecycle or Deprecation Model #65 — dependencies (Spec Proposal: Dependencies manifest #63) may point across registries (need trust context); deployment metadata (Spec Proposal: Deployment metadata #64) distinguishes instances, provenance extensions distinguish copies; lifecycle (Spec Proposal: No Lifecycle or Deprecation Model #65) needs cross-registry propagation.

Related Work

• Registry Federation Interoperability — Mutual Trust & Cross-Registry Provenance ards-project/ard-spec#63 — registry federation interoperability (ARD-layer protocol that consumes these fields)
• Spec Proposal: Discovery-Time Access & Monetization Signaling #83 — discovery-time access/monetization signaling (accessModel). Distinct: Spec Proposal: Discovery-Time Access & Monetization Signaling #83 signals pricing tier for selection; executionContract covers operational terms post-selection (quota, SLA, data residency).
• MCP Gateway Registry (Open-source reference implementation: MCP Gateway Registry (Apache-2.0) — both Catalog Publisher and Registry ards-project/ard-spec#40) — open-source implementation already doing peer federation with canonical source tracking

Next Steps

Happy to draft spec text + examples in a follow-up PR once directional alignment is confirmed.