SADAR Documentation — Security
Draft — April 2026
This document covers the cryptographic, authentication, and isolation properties that establish a SADAR registry as a trustworthy discovery component. It complements the Registry Overview page (which covers the registry's architectural shape and operational scope) by focusing specifically on the security mechanisms — manifest signing, JWKS endpoints, channel security, identity-bound usage keys, and cryptographic parity — that conformant registry implementations enforce.
The normative content lives across three sections of the Scope specification: §5.1.8 (Identity, Authentication, and Trust), §5.1.12 (Registry Isolation), and §5.1.17 (Cryptographic Parity). This page treats them as a cohesive whole.
Audience: enterprise architects, security architects, and operations teams responsible for deploying or evaluating a SADAR-conformant registry.
Every security property a SADAR registry exhibits depends on one foundational principle: the registry holds only what manifest owners submit. It does not hold credentials, API keys, usage tokens, or any other sensitive operational data. It does not issue authentication tokens for invocations — those are issued by the target service's authentication endpoint, declared in the target's manifest. After discovery completes, runtime interactions do not depend on registry availability.
This narrow scope is the reason a SADAR registry is safe to operate as multi-tenant infrastructure, including in federated topologies that span organizational and jurisdictional boundaries. A compromised registry cannot impersonate a target, mint tokens, or replay invocations, because it never holds the material that would let it do so. Federation does not change this — even when registries forward queries or replicate content to peers, the registry's role remains discovery-time only.
The Registry Overview page covers isolation in its architectural framing. This page treats isolation as the security ground state — the property every other security mechanism on this page builds on or preserves.
Every manifest registered with a SADAR-conformant registry is publisher-signed using JSON Web Signature with ES256 as the default algorithm; other algorithms are permitted under the §5.1.8.1 authentication baseline. The registry validates signatures on ingestion. Manifests that fail signature verification are rejected with a structured error in the urn:sadar:error:v1:nfr_schema:* namespace; the registry does not silently accept or quarantine invalid manifests.
Manifests are immutable by design. Any change to a manifest's content requires producing a new versioned manifest with a new signature; the registry rejects in-place modification attempts. This immutability is the property that makes the manifest a trustworthy source of truth — a downstream consumer that retrieves a manifest can trust that what it receives is what the publisher signed, and can verify that property cryptographically.
Each entity, agent, tool, and registry publishes a JWKS endpoint exposing its public key material. The JWKS endpoint may be referenced from the manifest by URL, or the relevant keys may be inlined in the manifest as JWK objects. Either form satisfies the baseline; large operations typically prefer the JWKS endpoint for the rotation properties below.
Two key uses are required at minimum:
Additional keys may be present — for example, distinct keys for distinct operational purposes, or keys representing past credentials still validating signatures issued before rotation.
Key rotation is a JWKS-endpoint operation. An entity rotates by publishing the new key (or new JWKS document) at the same JWKS endpoint URL. The manifest does not need to be republished; the key reference in the manifest points at the JWKS endpoint, and the JWKS document at that endpoint is the source of truth for current key material. During a rotation window, the JWKS document typically contains both outgoing and incoming keys with the incoming one marked as the current signing key. Counterparties verifying a recently-issued signature continue to use the outgoing key until their JWKS cache refreshes; new signatures use the incoming key.
Decoupling key rotation from manifest republication matters operationally. Republishing a manifest is a versioned event — new version, new signature, propagation through registry validation and federation. Rotation should not require this overhead, because rotation happens far more often than capability change.
Channel Security and Identity-Bound Usage Keys
All communications between registries and agents — and between agents and other agents — use mutually-authenticated TLS. TLS 1.2 minimum; TLS 1.3 is preferred and SHOULD be negotiated where peer support exists. Both sides present X.509 client certificates; both sides verify the other's certificate against their own trust configuration. mTLS provides channel-level authentication and channel binding — the entity that obtained an access token through a specific mTLS channel is the entity entitled to use that token over that channel.
Certificate issuance, validation, and rotation are operational concerns out of normative scope. Organizations use whatever certificate authority infrastructure already supports their environment — public CAs, internal PKIs, SPIFFE/SPIRE, service mesh issuers, or others. The minimum-version and channel-binding requirements travel through the manifest as Operational NFRs subject to bilateral matching at discovery.
When a target service issues a usage key to a requester, the key is delivered as a JSON Web Encryption (JWE) claim encrypted to the requester's public key from the requester's JWKS. Because the JWE is decrypted only by the holder of the corresponding private key, and because the JWE is issued during an authenticated OIDC exchange that already verified the requester's identity, the resulting usage key is cryptographically bound to that specific requester.
This binding has three operational consequences. The target can attribute every subsequent invocation under the usage key to a specific entity, enabling billing, rate limiting, and audit. The requester cannot share the usage key with another party in a way that survives — the recipient would need the requester's private key to decrypt and present it. And the registry, which never sees the JWE-encrypted usage key, cannot impersonate the requester or replay the key, even if the registry were compromised.
SADAR carries certain values across multiple propagation layers — OTel baggage, span attributes, SCT claims, and Telemetry Record fields. The Cryptographic Parity requirement of §5.1.17 normatively states that any value appearing in multiple layers SHALL be consistent at every point of observation. Parity violations are reported with structured error in the urn:sadar:error:v1 namespace; they are never silently tolerated.
Parity instances normatively include the following:
Cryptographic parity is the foundation for tamper-evident audit reconstruction across trust boundaries. Without parity, an investigator reconstructing a flow from spans, audit records, and SCT chains would have no way to verify that the artifacts agree on the basic facts of the flow — what business process it served, which trust model governed it, what its accumulated risk was at each handoff. Parity makes those facts checkable across artifacts, and inconsistencies become structural error conditions rather than unresolvable ambiguities.
A registry is itself a registered entity in the SADAR ecosystem. Each authorized registry has its own signed manifest in the Directory of Authorized Registries, signed using JWS with ES256 by default. The registry's manifest carries the same top-level fields any other entry carries — manifest URN, endpoint URN, manifest version, schema version, lifecycle state, signature — plus the registry-specific declarations the protocol requires (authentication endpoint, supported NFRs, and the registry's own owning_entity attribution).
Every authorized registry is attributed to one and only one owning entity, represented within the registry's entity hierarchy and matching the owning_entity attribute in the registry's manifest. This attribution is the chain of accountability for the registry's operation: every claim a registry makes — what entries it holds, what queries it forwards, what NFRs it enforces — traces back to a legally accountable root entity. The Directory of Authorized Registries enforces this match at registration time.
That a registry is itself subject to manifest signing, JWKS publication, and bilateral discoverability rules is what lets registries participate in federation as peer entities. A registry calling another registry to forward a query is functionally indistinguishable from any other agent-to-agent invocation: the same authentication baseline, the same manifest verification, the same SCT semantics.
Registry security is one slice of the SADAR security architecture. Several adjacent concerns are deliberately out of scope here and live in dedicated pages:
• Security Overview — orientation to the security layers and how they compose.
• Registry Overview — the architectural framing, what the registry does and doesn't do, registry types and operational modes.
• Authentication Baseline — OIDC Client Credentials over mTLS, JWKS endpoints, key rotation; the mechanism every SADAR entity uses.
• SADAR Context Token — JWS-inside-JWE structure, five chain operations, general SCT validation.
• Trust Models — direct_auth, asserted, impersonation, deputy.
• Authentication Scopes — urn:sadar:scope:v1 namespace and the six initial scopes.
• 2. Scope §5.1.8 — Identity, Authentication, and Trust umbrella.
• 2. Scope §5.1.12 — Registry Isolation: the normative constraints establishing the registry as a discovery-time component only.
• 2. Scope §5.1.17 — Cryptographic Parity: the normative parity requirement.
• 9_SCT Operations — full SCT cryptographic semantics, including the Chain Crypto Suite system.