Replication is the operational mechanism by which content published through one registry becomes available through other registries the home registry has federated with. SADAR's model satisfies two simultaneous properties: manifests are byte-identical wherever they appear (so the publisher's signature verifies regardless of which registry serves the content), and registries cryptographically attest “this manifest was published through me” in a way independently verifiable wherever the manifest travels.
This page introduces the replication architecture: how the home-registry binding works, what flows through the push channel, and how consumers verify replicated content as both cryptographically authentic and institutionally trust worthy. The full treatment, including the binding object schema, the verification chain, and the complete normative requirements, lives in the linked SADAR Replication and Manifest Provenance document.
The model separates three cryptographic roles, each anchored in its own keypair:
Manifests are byte-identical wherever they appear. Peer registries do not modify, re-sign, or annotate the content they serve. Editorial authority is bounded by the key seach party holds.
The home-registry binding is a separate signed artifact attached to the manifest, not a field within it. It is a JWS-signed binding object referencing the manifest by SHA-256 hash over the JCS-canonicalized manifest content, identifying the home registry by URN, declaring the signing key by kid, and carrying issuance and valid_until timestamps.
Replicated content consists of three artifacts traveling together: the publisher-signed manifest, the home-registry binding, and the home registry's own manifest (which contains the verification key needed to validate the binding). All three must be available for downstream verification to succeed.
Federation isbilateral and non-transitive. If A federates with B, and B federates with C,this does not extend A's content to C. A registry can only expose or forwardentries for which it is the home, plus entries replicated from a registry withwhich it has a current direct federation agreement. Non-transitivity matchesreal-world organizational trust, preserves the home registry's control overdistribution, and contains the blast radius of any single compromised peer.
Conformant registries MUST expose a push endpoint. Push delivers operational responsiveness for replication updates, revocation propagation, and federation lifecycle messaging. A registry that does not implement push cannot be certified, and consequently cannot be authorized for participation in public federation. Push endpoints use mTLS and signature-verifiable messages, applying the universal SADAR authentication model rather than a special-purpose mechanism.
A consumer retrieving a manifest from a peer registry performs five checks, all of which MUST succeed: verify the publisher's signature on the manifest; compute the JCS-canonicalized SHA-256 hash; verify the home-registry binding (hash match, valid_until, JWS signature);verify the home registry's manifest signature; and confirm institutional trust by verifying that the home registry is currently authorized in the Directory. Certification alone is not sufficient; current authorization is required. The institutional-trust step structurally enforces that home-registry attribution flows only from registries the Authorizing Body has institutionally vouched for.
Case A applies when the entry itself is no longer valid — the publisher signals revocation through the standard lifecycle, propagated through push. Case B applies when the entry remains valid but a specific peer should not have replicated or served it; the home registry issues the registry-replica revocation through the push channel. Enforcement at the consumer side composes from federation-configuration filtering at the registry admin level and the SCT discovery-registry attribution at the receiving service — mechanisms that do not depend on the deauthorized peer's compliance.
SADAR Replication and Manifest Provenance — the full draft. Covers the binding object schema with field-level descriptions, JCS canonicalization, JWS signature format, the complete five-step verification chain, the push channel authentication protocol, the two-case revocation model, the architectural properties table, and the complete normative requirements (R-PUB, R-HR, R-PR,R-PUSH, R-CV, R-SCT).
SADAR Governance and Conformance — the conformance / certification /authorization ladder that produces authorized registries; SADAR Federation Establishment and Policy — how registries enter into the bilateral federation agreements that gate replication; Registry of Registries —the canonical Directory used in the institutional-trust check; SADAR Context Token — the chain-of-custody token carrying the discovery-registry attribution.