This document is the cross-cutting summary of SADAR security: the set of primitives that every conformant implementation — registry, agent, tool, or invocation service — must implement uniformly. It is the orientation page that ties the deeper specifications together and provides the conformance checklist a reviewer or implementer can work against.
Core Security and Registry Security are sibling L1 pages. Core Security covers what every SADAR entity does. Registry Security covers what registries specifically do as discovery components. The two pages share the same authentication baseline; the registry page focuses on how isolation, ingestion validation, and federation security follow from that baseline.
The normative basis lives acrossthe Scope specification: §5.1.8 (Identity, Authentication, and Trust) is theumbrella, with cross-references to §5.1.12 (Registry Isolation), §5.1.17(Cryptographic Parity), and the 4. SCT Operations companion document.This page treats those sections as a cohesive whole and indexes them againstthe six primitives below.
Audience: enterprise architects, security architects, and implementation teams using this page either to scope a SADAR implementation or to verify that an existing implementation is conformant.
A SADAR implementation is conformant when it correctly implements six interlocking primitives. They are not independent: each primitive depends on or feeds into the others, and an implementation that gets five right but the sixth wrong is not conformant — the chain of trust breaks at the weak link.
1. Manifest signing (JWS) — everything an entity asserts about itself or its capabilities is signed.
2. Public key publication (JWKS) — the keys other entities use to verify those signatures and to encrypt content to this entity.
3. Channel security (mTLS) — the transport on which all inter-entity communication occurs.
4. Encryption (JWE) — for usage key delivery andfor SCT inner content where confidentiality is required.
5. SADAR Context Token (SCT) — the per-invocation authorization and audit context that travels with each call.
6. Authentication scopes — the granularity at which tokens are scoped, drawn from the urn:sadar:scope:v1 namespace.
Each is treated below at a level of detail sufficient for orientation. The deeper sibling pages cover individual mechanisms in full normative depth.
Every manifest in the ecosystem— for entities, agents, tools, registries, and invocation services — is publisher-signed using JSON Web Signature with ES256 as the default algorithm. Other algorithms are permitted under the §5.1.8 baseline, declared in the manifest itself.
Recipients verify the signature against the publisher's JWKS-published signing key before relying on any manifest content. Registries validate signatures on ingestion, rejecting non-conforming manifests with structured error. Agents and tools validate signatures on retrieval, with the same expectation: a manifest whose signature does not verify is treated as untrusted and not consumed.
Manifests are immutable per version. A change to manifest content requires producing a new versioned manifest with a new signature and propagating that version through the discovery layer. This immutability is the property that makes signed manifests a trustworthy source of truth across an arbitrarily long discovery chain — a downstream consumer can trust that what it received is what the publisher signed, and can verify that property cryptographically without needing live contact with the publisher.
Each entity publishes a JWKS endpoint exposing its public key material. The manifest references the JWKS endpoint by URL, or in lines the relevant JWK objects directly. Either form satisfies the baseline; large operations typically prefer the JWKS endpoint forthe rotation properties below.
Two key uses are required at minimum:
• use: sig— the signing key, used by counter parties to verify manifest signatures and SCT inner-payload signatures originating from this entity.
• use: enc— the encryption key, used by issuers to encrypt usage keys delivered as JWE to this entity, and by SCT issuers to encrypt inner content addressed to this entity.
Key rotation is performed by updating the JWKS endpoint, not by republishing the manifest. The manifest's reference points at the JWKS endpoint URL; the JWKS document at that endpoint is the source of truth for current key material. During rotation, the JWKS document typically contains both outgoing and incoming keys; counterparties verifying recently-issued signatures continue to use the outgoing key until their cache refreshes. Decoupling rotation from manifest republication matters because rotation happens far more frequently than capability change.
All communications between SADAR entities 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 two properties the rest of the security architecture relies on. First, channel authentication —every byte exchanged between two entities is attributable to the entity that authenticated to that channel. Second, channel binding — when a target service issues a usage token through a specific mTLS channel, that token is entitled tobe used only over that channel. An attacker who exfiltrates a token cannot replay it from a different 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 manifests as Operational NFRs subject to bilateral matching at discovery: a requester whose channel-binding requirements cannot be satisfied by a target will not match against that target.
JSON Web Encryption appears in two principal places in SADAR. First, when a target service issues a usage key to a requester, the key is delivered as a JWE claim encrypted to the requester's encryption key from 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. The target can attribute every subsequent invocation to that requester for billing, rate limiting, and audit; the requester cannot share the key in a way that lets a third party present it; and the registry, which never sees the JWE, cannot impersonate the requester.
Second, the SCT itself is structured as JWS-inside-JWE — the inner authorization claims are signed by the issuing entity, and the outer envelope is encrypted to the recipient or recipients entitled to read those claims. Where SCT inner content carries information that some downstream parties should not see (for example, the originating user's identity might be visible only to authorized auditors but not to intermediate agents), it MUST be encrypted in JWE form to the keys of just those entitled recipients. Audit paths follow the same pattern: an authorized auditor's encryption key is included in the JWE recipient set when the issuer wants the audit channel to be able to read the link.
The SCT is the per-invocation authorization and audit context. It travels with every call and represents, at the trust boundary, the authorization basis for that specific call. Structurally, an SCT is JWS-inside-JWE — the inner JWS is signed by the issuing entity, and the JWE envelope is encrypted to the recipient. A recipient verifies the JWE recipient claim, decrypts to get the inner JWS, and verifies the JWS signature against the issuer's JWKS-published signing key.
SCTs form chains. Each link in a chain represents one trust boundary crossing in the call sequence. The chain backbone is the (jti, parent_jti) pairing: each new link's parent_jti points at the inbound link's jti, producing a singly-linked list that an auditor can walk end-to-end. The chain root jti is propagated as cryptographic-parity content in OTel baggage and Telemetry Records, so the chain remains correlatable across the audit fabric even when an auditor cannot decrypt every individual link.
Each link records the trust model under which it was issued — direct_auth, asserted, impersonation, or deputy — pinning the trust regime to the link rather than to the chain as a whole. A chain may legitimately mix trust models across its length (for example, direct_auth at the originating boundary, asserted at an intermediate framework boundary), and the link-level trust model claim is the artifact that lets an auditor see exactly which model governed which boundary.
On any onward invocation, the calling entity MUST issue a new chain link signed by itself, encrypted to the next recipient, with parent_jtiset to the inbound link's jti and the trust model claim set to whichever model governs the new boundary. Failing to issue a new link, or issuing one whose chain or signature does not validate, breaks conformance for that invocation.
SADAR uses the urn:sadar:scope:v1 namespace for authentication scopes. The §5.1.8 baseline defines six initial scopes covering the core lifecycle operations the protocol requires. Implementations declare the scopes they require for each operation in their manifests; tokens carry the scopes they confer; and recipients validate that the scope set on the token covers the operation being attempted.
Two principles govern how scopes interact with token issuance. First, target-as-issuer: each target entity issues its own usage tokens with its own scope content. The registry is not the issuer of invocation-time tokens — it is a discovery component only, with no runtime role in token minting. This decoupling is what makes the registry safely operable as multi-tenant and federated infrastructure (covered in detail in Registry Security).
Second, lazy refresh and TTL bounds: scopes have well-defined TTL behavior, with presenters expected to rely on lazy-refresh semantics rather than tracking exact expiry. A presenter that hits an expired-token error refreshes and retries; a presenter that pre-refreshes on a fixed schedule is implementing a non-conformant pattern.
The urn:sadar:scope:v1 namespace permits proprietary extensions registered through the registry's extension mechanism, but the core six scopes are the conformance-defining set. An implementation that issues tokens with scope content outside the namespace, or that fails to honor the core six, is not conformant regardless of any extensions it supports.
The table below is the working conformance checklist — what every SADAR implementation must implement. Each row maps a single requirement to the section of the specification where its full normative form lives. An implementation that satisfies every MUST in this table, and the SHOULD requirements where applicable, is conformant against the §5.1.8 baseline.
This checklist is intentionally not exhaustive of the full specification — it covers the security baseline. Discovery semantics, NFR matching, manifest schema, federation rules, and other domains have their own conformance content in their respective sections.
Core Security is the cross-cutting summary. Several adjacent topics are intentionally out of scope here and live in dedicated pages:
• Registry Security — registry isolation, manifest validation on ingestion, federation security, registry ownership and accountability.
• Authentication Baseline — full normative content for OIDC Client Credentials over mTLS, JWKS endpoints, and key rotation.
• SADAR Context Token — the SCT structure, chain operations, and validation semantics at orientation depth (deeper still in 4.SCT Operations).
• Trust Models — direct_auth, asserted, impersonation, and deputy in detail; which credentials each requires and how each is recorded.
• Authentication Scopes — full enumeration of the six initial scopes in the urn:sadar:scope:v1 namespace, with TTL bounds and lazy-refresh semantics.
• 2. Scope §5.1.8 — Identity, Authentication, and Trust umbrella; the normative source for everything on this page.
• 2. Scope §5.1.12 — Registry Isolation; the normative constraints on the registry as a discovery-time-only component.
• 2. Scope §5.1.17 — Cryptographic Parity; the normative requirement that multi-layer values agree.
• 4. SCT Operations — full SCT cryptographic semantics, including Chain Crypto Suite and the five chain operations (issue, extend, validate, audit-decrypt, terminate).
• 7. searchAndInvoke — the invocation orchestrator; first-use provisioning with DPoP per RFC 9449, and RFC 7523Private Key JWT for assertion patterns.