Federated Registries

The Registry Federation Model is a directory-of-registries architecture that allows authorized registries to interoperate through query forwarding and controlled content replication. In the larger context of the SADAR Core Architecture, federation prevents global fragmentation of the agentic ecosystem while allowing individual registries to maintain sovereign control over their operational boundaries and access policies.

The federation model integrates into the core architecture through several key mechanisms:

1. The Registry of Registries (RoR) as the Trust Anchor At the center of the federation architecture is the Registry of Registries (RoR), which is operated by a neutral standards body. The RoR functions for registries exactly as a local registry functions for individual agents: it issues registry identities (URNs), holds operator-signed registry manifests, and acts as the authoritative source for registry discovery. Crucially, the RoR only holds registry descriptors, not agent entries. It remains out of the runtime data path; once two registries authenticate, they communicate directly.

2. Distribution and Replication Patterns Thearchitecture supports flexible configurations for how registries acquirecontent from or delegate queries to one another:

• Full Subscription: A registry periodically pulls and stores all entries from a source registry locally.
• Partial Subscription: A registry pulls only a subset of entries constrained by hierarchical gates, such as specific Provider lists, NAICS industry codes, or APQC PCF process nodes.
• Query Forwarding: A real-time distribution pattern where a registry forwards unresolved portions of a discovery query to designated external registries, aggregating the results for the caller.

3. Multi-Hop Forwarding and Identity Coherence When a query propagates across multiple registries (multi-hop forwarding), the architecture enforces strict identity and trust rules:

• Independent Authentication: Each registry in the chain must authenticate independently using a token issued by the RoR. A registry cannot simply pass along the originating registry's token.
• Scope Propagation: The scope declared by the originating entity's manifest is carried through the forwarding payload. This allows any intermediate or terminal registry to enforce its own access policies or built-in     right-of-refusal against the originating entity.
• Mandatory Per-Hop Deduplication: Because registries often interconnect in complex graphs (creating a "diamond problem"), the architecture mandates that every registry deduplicate its aggregated results using the     composite key of Entity UUID + Entry UUID before passing the results back down the chain.

4. Architectural Isolation for Private Registries The core architecture explicitly supports Internal Proprietary Registries for enterprise-owned, confidential agents. This registry type is categorically excluded from the federation protocol at the network boundary; it does not register with the RoR, has no OIDC endpoint for inter-registry authentication, and never participates in any external replication or forwarding chains.

5. Commercial and Access Controls Just as service providers can enforce controls on consuming agents, providing registries can enforce strict controls on registries requesting to pull their content. Registries can apply rate limits, payload size restrictions, and allow/blocklists. Furthermore, the architecture natively supports charging for forwarding and replication services, using standard settlement methods(e.g., Stripe, X.402 networks) defined in the registry's signed manifest.

Registry of Registries

Within the SADAR Core Architecture, the Registry of Registries (RoR) functions as the definitive trust anchor and discovery mechanism for the entire federated ecosystem. While local or provider registries facilitate the discovery of specific agents and tools, the RoR is a specialized architectural tier designed exclusively for the discovery of other registries.

Architectural Symmetry and Trust Anchoring The core design principle of the RoR is architectural symmetry: it plays the exact same trust-anchor role for registry operators that a local registry plays for individual agents. Instead of holding agent entries, the RoR exclusively holds registry descriptors—structured metadata and digitally signed registry manifests.

When a new registry instance joins the federation, its operator must register with the RoR, which assigns a globally unique registry URN. The operator uploads a registry manifest signed with their private key (JWS/ES256), which declares the registry's scope, operational limits (NFRs), licensing terms, and OpenID Connect (OIDC) endpoint.

Identity Issuance and Registry-to-Registry Authentication The RoR is the centralized identity bridge that allows distributed registries to trust one another without prior bilateral configuration. When one registry needs to pull replicated content or forward a query to another, it authenticates to the RoR’s OIDC endpoint using mutual TLS (mTLS). The RoR issues a short-lived, signed JSON Web Token (JWT) asserting the requesting registry's identity and granted scopes, which is then presented directly to the providing registry. The providing registry validates this token locally against the RoR's public key (JWKS).

Strict Architectural Isolation (Blast Radius) To prevent the RoR from becoming a performance bottleneck or a single point of compromise, its architecture enforces strict isolation. The RoR's "blast radius" is limited entirely to identity issuance and manifest storage. It never holds the private keys of the registry operators. Furthermore, it is never a runtime participant in the replication or forwarding data flows; once two registries have used the RoR to authenticate, all subsequent data exchange occurs directly between them.

Role in the Forwarding Protocol In a multi-hop forwarding scenario, the RoR participates in a restricted capacity. Because it does not store agent entries, it cannot answer discovery queries with agent candidates. Instead, it responds to forwarded queries with discovery metadata—specifically, the registry descriptors of member registries that fall within the queried domain or scope. The originating registry then uses this metadata to issue targeted queries directly to those peer registries.

‍