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 operationalscope) 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 livesacross 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 orevaluating 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, includingin 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.1authentication 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 bydesign. 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 maybe in lined 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:
• use: sig— the signing key. Used by counterparties to verify the entity's manifest signatures.
• use: enc— the encryption key. Used by issuers (e.g., a target's authentication endpoint) to encrypt usage keys delivered as JWE to this entity.
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 frommanifest republication matters operationally. Republishing a manifest is aversioned event — new version, new signature, propagation through registryvalidation and federation. Rotation should not require this overhead, becauserotation happens far more often than capability change.
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 normativelyinclude 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 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 sliceof the SADAR security architecture. Several adjacent concerns are deliberatelyout of scope here and live in dedicated pages:
• Security Overview — orientation to the securitylayers 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 ClientCredentials over mTLS, JWKS endpoints, key rotation; the mechanism every SADARentity 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:v1namespace and the six initial scopes.
• 2. Scope §5.1.8 — Identity, Authentication, andTrust umbrella.
• 2. Scope §5.1.12 — Registry Isolation: thenormative constraints establishing the registry as a discovery-time componentonly.
• 2. Scope §5.1.17 — Cryptographic Parity: thenormative parity requirement.
• 4. SCT Operations — full SCT cryptographicsemantics, including the Chain Crypto Suite system.