Overview

Federation in SADAR is the operational mechanism by which registries enter into bilateral relationships permitting cross-registry discovery and content replication. Federation is bilateral, non-transitive, admin-driven, and authorization-validated. This page introduces the federation architecture: how registries discover candidates through the Directory of Authorized Registries, evaluate compatibility, enter into bilateral agreements, and administer per-registry policy. The full treatment lives in the linked SADAR Federation Establishment and Policy document.

Four Architectural Principles

Bilateral. Each federation entry is between exactly two registries. Multilateral federations do not exist. A registry may have multiple federation entries each subject to bilateral agreement.
‍Non-transitive. If A federates with B, and B federates with C, no rights extend from A to C. Each replication link is its own decision, evaluated and consented-to bilaterally.
Admin-driven. Federation establishment is an administrative act between organizations, not a runtime decision. Federation discovery is human-initiated; runtime invocation discovery within a federation is machine-initiated.
Authorization-validated. Serving as a home registry for content flowing to public-federation peers requires Authorizing Body authorization. Non-authorized registries may consume from authorized registries but cannot host federated content.

Federation Eligibility by Operational Mode

Operational mode	Consume from authorized registries	Serve as home registry	Listable in Directory
Internal-only (private)	Yes — subject to authorized peer's policy	No	No
Authorized non-federated	Yes — same as Internal-only	No	No
Authorized federated	Yes — standard bilateral federation	Yes	Yes

Cross-mode federation produces a clean directed-graph property: content flows from authorized to non-authorized; non-authorized registries cannot inject content back into the public federation. The asymmetry preserves the institutional-trust path while allowing private deployments to participate as consumers without taking on the certification burden. The federation assertion captures the directional roles explicitly.

The Directory and RoR Architecture

The Directory of Authorized Registries is the canonical Registry of Registries for the SADAR public federation, operated by OpenSemantics.org. It lists authorized registries and serves as the institutional-trust signal admins rely on. The Directory replicates across multiple operational instances for high availability — registries configure primary, secondary, and tertiary RoRs much as DNS clients configure name servers. Inter-RoR replication uses the standard SADAR registry federation contract; the recursive architectural pattern holds at this layer as it does at the registry layer.

Federation Establishment

A registry admin seeking to establish federation typically begins from the Directory: looking up a known partner or automated match dimensions.

Federation requires bilateral agreement. Both parties evaluate each other; both sign federation assertions in their own names; the assertions are exchanged through the standard SADAR push channel. The assertion captures the directional roles, the federation scope, the TTL, and the push endpoints.

Layer	Decides	Enforced at
Federation membership	Which home registries flow content into and out of this registry; the bilateral agreements in force.	Registry admin console; bilateral assertions exchanged through push.
Per-entity / per-entry / per-criteria ACLs	Which entries participate in which federations, in either direction.	Registry serving layer; admin-configured ACLs evaluated at discovery time.
Requester-specific authentication	Which specific principals can authenticate to specific endpoints.	IAM at the authentication call; before the request reaches the registry.

Registries SHOULD implement ACLs determining inbound and outbound rules per federated registry, including per-entry, per-entity, and per-manifest-criteria rules. Block lists for specific home registries support operational issues, voluntary exclusion, and pre-deauthorization isolation. Requester-specific blocking is handled at the IAM layer rather than the federation layer, separating federation membership from principal-level permissions.

Read the Full Document

SADAR Federation Establishment and Policy — the full normative draft. Covers the four architectural principles in detail, the eligibility-by-operational-mode treatment with the directional asymmetry, the Directory and RoR architecture with descriptor schema, the federation establishment protocol, NFR-dominated federation compatibility matching, the three-layer admin policy architecture, the federation lifecycle, and the complete normative requirements (R-FED,R-ELIG, R-EST, R-ROR, R-MATCH, R-POL).