This document defines the Registry of Registries (RoR) — the federation-layer component that resolves cross-registry discovery — and describes the operational shape readers can expect a SADAR-conformant RoR to exhibit. It covers what an RoR holds, how it differs from a conventional SADAR registry, the canonical Directory of Authorized Registries maintained by OpenSemantics.org, and how RoRs participate in private and sovereign federations alongside the public Directory.
The normative content lives across two sections of the Scope specification: §5.1.6 (Registry Protocol) covers descriptor manifest validation and immutability, and §5.1.11 (Registry Topology, Federation, and Directory) establishes the federation model and Directory semantics. This page treats the Registry of Registries as a coherent topic across both.
Audience: enterprise architects, security architects, federation operators, and standards practitioners evaluating cross-registry discovery models or planning private RoR deployments alongside the public Directory.
A Registry of Registries is a SADAR registry that holds registry descriptors only — never agent, tool, business function, business process, or entity entries. Its role is to resolve cross-registry discovery: given a consumer asking which registries are eligible to participate in a federated query, the RoR returns a set of signed descriptors pointing at those registries, and the consumer (or the consumer’s home registry) takes itfrom there.
Architecturally, an RoR is not a specialprivileged construct. It is a registry like any other — same conformanceregime, same Registry Isolation property, same manifest signing baseline, same JWKS-based key model, same bilateral matching at query time. The “ofregistries” qualifier describes what the RoR holds, not how it behaves. A consumer querying an RoR uses the same protocol semantics as a consumer querying any other SADAR registry; the matching dimensions are simply at the registry level (jurisdiction, supported NFRs, authentication baseline, declared scopes) rather than at the agent level.
Descriptors are immutable. Any change — a new endpoint, an additional supported NFR, a TTL adjustment — produces a new versioned descriptor with a new signature, in the same way any other SADAR manifest evolves. The RoR rejects in-place modification attempts; the life cycleof a descriptor proceeds through versioned state changes only.
The RoR’s query-time behavior follows the standard SADAR registry protocol, with descriptors as the entries. A consumer(or its home registry) submits a query specifying the federation properties it requires — relevant NFRs, jurisdictional constraints, supported scopes — and the RoR returns a classified candidate set of registry descriptors. The consumer-supplied resolver then makes the final selection of which downstream registries to query directly.
Two flows are typical:
• Home-registry-mediated — The consumer queries its home registry. The home registry, if unable to fully satisfy locally, queries the RoR for eligible peer registries, then forwards the original queryto selected peers within their declared terms of service. Match results aggregate back through the home registry to the consumer.
• Consumer-mediated — The consumer queries the RoR directly to enumerate eligible registries, then queries each selected registry independently. This pattern is common where consumers want explicit controlover which registries they engage rather than delegating that decision to the home registry.
In both flows, the RoR’s role is bounded: it returns descriptors, not candidate agents. Selection of downstream registries —like the resolver step in agent discovery — is a consumer concern that the RoR cannot perform.
Registry descriptors propagate under TTL semantics, with refresh handled as periodic re-fetch by counterparties whose caches have expired. Descriptor TTLs are typically longer than agent-entryTTLs, because registries change less often than the entries they hold; specific bounds are governed by the descriptor’s declared NFRs.
Where multiple RoRs exist — for example, asovereign or industry-specific RoR running alongside the public Directory of Authorized Registries — replication between RoRs follows the same federation contract any registry uses: subject to the receiving RoR’s declared terms of service, signature-validated on ingestion, and bounded by the replicated descriptors’ own TTLs. There is no privileged inter-RoR protocol; RoRs federate using the same mechanisms ordinary registries do.
Lifecycle changes propagate through the same channel. A descriptor moving from active to deprecated, or from deprecated torevoked, is published as a new version; counterparties learn of the change at the next refresh. Within the active descriptor’s TTL, counterparties may continue to rely on it; revocation only takes effect at the cache-refreshboundary, which is why TTL bounds matter to operational risk modeling.
Because an RoR is structurally just a registry, it inherits Registry Isolation in full. An RoR holds only the descriptors its owners submit. It does not hold credentials, API keys, usage tokens, or any operational data belonging to the registries it lists. It does not issue authentication tokens for invocations against any of those registries. A compromised RoR cannot impersonate a listed registry, cannot mint federation credentials, and cannot replay queries, because the material that would allow those actions never enters the RoR.
The Directory of Authorized Registries operates under the same isolation guarantee. OpenSemantics.org’s stewardship of the Directory is editorial — listing decisions, certification administration, lifecycle governance — not custodial of any operational secrets belonging to listed registries.
This property is what makes private and sovereign RoRs a first-class deployment pattern. An organization or jurisdiction can operate its own RoR for a private federation — a healthcare consortium, a national infrastructure community, a regulated industry with cross-border data constraints — without those decisions cascading into a dependency on any cloud provider, model provider, or hosting environment. The RoR holds descriptors; it does not hold the keys to the kingdom.
The two columns below summarize the operational scope of a SADAR-conformant Registry of Registries — what a conformant RoR is required to do, and what it is required not to do or is not asked to do.
Several concerns adjacent to the Registry of Registries live in dedicated pages:
• Registry Overview — the architectural framing for registries, including the six registry types and three operational modes.
• Registry Security — manifest signing, JWKS, mTLS, identity-bound usage keys, and cryptographic parity.
• Federation — independent vs federated registries, federation security details, and the rejection rules that govern unauthorized peers.
• Discovery — multi-level matching, TTL semantics, the resolver, and match classification.
• Entity Model — the organizational accountability model and the six discoverability levels.
• Conformance Specification — the certification criteria a registry must meet for Directory listing.
• 2. Scope §5.1.6 — Registry Protocol: registration, validation, immutability, error responses.
• 2. Scope §5.1.11 — Registry Topology, Federation, and Directory.
• 2. Scope §5.1.12 — Registry Isolation: the normative constraints establishing the registry as a discovery-time component only.