This document defines the SADAR authentication baseline — the minimum required authentication mechanism every SADAR-conformant interaction must satisfy. The baseline is normatively specified in 2. Scope §5.1.8.1 and is the foundation on which the rest of the SADAR security architecture sits: the Signed Context Token, the four trust models, authentication scopes, and provider-side validation all assume the baseline is in place beneath them.
Audience: implementers building SADAR-conformant components, security architects evaluating SADAR for adoption, and operations teams planning the certificate, key, and OIDC infrastructure SADAR-conformant deployments require.
OIDC Client Credentials over mTLS, with TLS 1.2 minimum, manifests signed using JWS, and JWKS endpoints exposed at every entity, agent, tool, and registry.
This is the floor. SADAR-conformant deployments may operate above the floor — TLS 1.3, stronger key sizes, additional authentication factors, additional grant types for non-baseline tiers — but every authenticated SADAR interaction must satisfy the baseline.
The baseline is intentionally close to existing standards. SADAR does not define new cryptographic primitives, new token formats, or new identity mechanisms. It selects existing standards, fixes a small set of constraints, and requires the resulting combination be present at every SADAR-conformant deployment. Implementers can use the OIDC IdPs, certificate authorities, and key-management systems they already operate.
The baseline applies to every authenticated SADAR interaction. Three categories of interaction are explicitly in scope per §5.1.8.1:
Two interaction categories are out of scope of the baseline because they layer additional patterns on top of it: human-initiated flows (Authorization Code with PKCE) and first-use invocation provisioning (DPoP per RFC 9449). These tiers compose with the baseline rather than replace it; the baseline still applies to the agent-to-agent or agent-to-registry interactions involved.
Four components compose the baseline. Each is a normative requirement; satisfying three of four does not satisfy the baseline.
OAuth 2.0 Client Credentials grant, run as defined by OIDC. Each authenticating entity is an OAuth client to the entity it authenticates against. The token issuer is the target — the entity being called — not the registry and not a central SADAR-defined service. Federated registries follow the same pattern: a registry calling a peer registry runs the Client Credentials flow against the peer's authentication endpoint.
Client Credentials suits agent-to-agent and registry-to-registry interactions because there is no human present in the session and no human session token to forward. Where a human originator's authority needs to travel through the flow, that propagation is the SCT's job, not the authentication baseline's.
The Client Credentials exchange runs over mutually-authenticated TLS. 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, servicemesh issuers, or others.
TLS 1.2 is the floor. SADAR-conformant entities may negotiate TLS 1.3 and SHOULD where peer support is available. TLS 1.0 and 1.1 are not conformant. Each entity declares its minimum supported TLS version in its manifest; mismatches are a discovery-time bilateral concern resolved through the bilateral match algorithm.
The algorithm used for signing and encryption is explicitly declared in the manifest, not inferred from the JWK presented at the JWKS endpoint. Minimum key strength is 256-bit encryption.ES256 is the default signing algorithm for manifests; other algorithms permitted under §5.1.8.1 may be used where bilateral support exists. Algorithm and key strength values appear in the manifest as Operational NFRs subject to the same bilateral matching as any other NFR.
Every SADAR 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 in lined in the manifest as JWK objects. Either form satisfies the baseline; large operations typically prefer the JWKS endpoint for the rotation properties described below.
Two key uses are required at minimum:
Additional keys MAY be present in the JWKS — for example, distinct keys for distinct operational purposes, or keys representing past credentials still validating signatures issued before rotation. The minimum is one signing key and one encryption key; ceiling is implementer choice.
The following fields are required in every manifest as part of baseline conformance. The complete manifest schema is defined in 3. NFR Schema; the table below is the authentication-specific subset.
Key rotation is a JWKS-endpoint operation. An entity rotates its keys by publishing the new key (or the 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.
This separation matters operationally. Manifest republication is a versioned event — a new manifest version, a new signature, propagation through registry validation and federation. Key rotation should not require this overhead. By keeping the key material at the JWKS endpoint and the manifest pointing at the endpoint, rotation becomes a deployment operation rather than a registry operation.
During a rotation window, an entity's JWKS document typically contains both the outgoing and incoming keys, with the incoming key marked as the current signing key. Counterparties who have cached the JWKS continue to verify with the outgoing key until their cache refreshes, after which they verify with the incoming key. The exact overlap window and refresh cadence are operational choices outside the baseline.
The baseline is the floor for authentication, not for SADAR security as a whole. Several adjacent concerns are explicitly out of scope here and live in dedicated sibling pages or companion documents:
• Security Overview — orientation to all sixs ecurity layers and how they compose.
• SADAR Context Token — JWS-inside-JWE structure, five chain operations, audit substrate.
• Trust Models — direct_auth, asserted, impersonation, deputy; bilateral negotiation; deputy-preferred-in-ties.
• SCT Validation — provider-side asserted-model validation algorithm.
• Authentication Scopes — urn:sadar:scope:v1 namespace; six initial scopes; TTL bounds.
• Registry Security — registry isolation, manifest signing, mTLS, usage key, cryptographic parity.
• 2. Scope §5.1.8.1 — the normative authentication baseline (the source for this page).
• 2. Scope §5.1.8 — Identity, Authentication, and Trust umbrella section.
• 2. Scope §5.1.9 — Controlled First-Use Authorization (the layer above the baseline for first-use invocation).