Federated Registries

The Registry Federation Model is adirectory-of-registries architecture that allows authorized registries tointeroperate through query forwarding and controlled content replication. Inthe larger context of the SADAR Core Architecture, federation prevents globalfragmentation of the agentic ecosystem while allowing individual registries tomaintain sovereign control over their operational boundaries and accesspolicies.

The federation model integrates into the core architecturethrough several key mechanisms:

1. The Registry of Registries (RoR) as the Trust AnchorAt the center of the federation architecture is the Registry of Registries(RoR), which is operated by a neutral standards body. The RoR functions forregistries exactly as a local registry functions for individual agents: itissues registry identities (URNs), holds operator-signed registry manifests,and acts as the authoritative source for registry discovery. Crucially, the RoRonly holds registry descriptors, not agent entries. It remains out of theruntime 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 aquery propagates across multiple registries (multi-hop forwarding), thearchitecture 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 Thecore architecture explicitly supports Internal Proprietary Registriesfor enterprise-owned, confidential agents. This registry type is categoricallyexcluded from the federation protocol at the network boundary; it does notregister 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 serviceproviders can enforce controls on consuming agents, providing registries canenforce 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 forforwarding 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 ofRegistries (RoR) functions as the definitive trust anchor and discoverymechanism for the entire federated ecosystem. While local or providerregistries facilitate the discovery of specific agents and tools, the RoR is aspecialized architectural tier designed exclusively for the discovery of otherregistries.

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

When a new registry instance joins the federation, itsoperator must register with the RoR, which assigns a globally unique registryURN. 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 AuthenticationThe RoR is the centralized identity bridge that allows distributed registriesto trust one another without prior bilateral configuration. When one registryneeds to pull replicated content or forward a query to another, itauthenticates to the RoR’s OIDC endpoint using mutual TLS (mTLS). The RoRissues a short-lived, signed JSON Web Token (JWT) asserting the requestingregistry's identity and granted scopes, which is then presented directly to theproviding registry. The providing registry validates this token locally againstthe RoR's public key (JWKS).

Strict Architectural Isolation (Blast Radius) Toprevent the RoR from becoming a performance bottleneck or a single point ofcompromise, its architecture enforces strict isolation. The RoR's "blastradius" is limited entirely to identity issuance and manifest storage. Itnever holds the private keys of the registry operators. Furthermore, it isnever a runtime participant in the replication or forwarding data flows; oncetwo registries have used the RoR to authenticate, all subsequent data exchangeoccurs directly between them.

Role in the Forwarding Protocol In a multi-hopforwarding scenario, the RoR participates in a restricted capacity. Because itdoes not store agent entries, it cannot answer discovery queries with agentcandidates. Instead, it responds to forwarded queries with discoverymetadata—specifically, the registry descriptors of member registries that fallwithin the queried domain or scope. The originating registry then uses thismetadata to issue targeted queries directly to those peer registries.

‍