Integration with Existing Standards
May 1, 2026

Purpose

SADAR is deliberately additive. It does not redefine, replace, or fork the standards it composes with — it adds the discovery, attribution, governance, and observability semantics those standards do not provide, and it adds them in ways that leave the existing standards' surface area untouched. This document maps SADAR against the five standards it most directly composes with — OIDC and OAuth, JWS and JWE, OpenTelemetry, the Model Context Protocol (MCP), and Agent-to-Agent (A2A) —showing for each what the standard already provides, what SADAR adds on top, and what SADAR explicitly does not change.

The intended reader is an architect or technical lead familiar with the standards in question, evaluating how SADAR plugs into an existing technology stack.

The Composition Principle

SADAR's architectural posture is straightforward: standards do what standards already do well; SADAR adds the missing pieces between them. OIDC and OAuth handle authentication and token issuance. JWS and JWE handle signing and encryption. OpenTelemetry handles observability instrumentation. MCP and A2A handle agent-tool and agent-agent communication. None of these standards address agent discovery, capability semantics, bilateral authorization context, cumulative in-flight risk, or governed cross-organizational observability. SADAR addresses those — and only those.

Two consequences follow. First, organizations adopting SADAR do not retire their existing identity providers, signing libraries, or telemetry pipelines; they continue using them and add SADAR-conformant components alongside. Second, where a standard already specifies a behavior, SADAR adopts it normatively rather than redefining it. The table below — and the per-standard sections that follow — make the boundary precise.

Per-Standard Interface Mapping

OIDC and OAuth

Authentication for SADAR interactions and token issuance for invocations rest entirely on OIDC and OAuth. SADAR adopts the Client Credentials grant over mTLS as its baseline and adds a small set of constraints suited to agent-to-agent flows.

SADAR — OIDC and OAuth integration
What it provides What SADAR adds on top What SADAR doesn’t change
OIDC ID token semantics; OAuth grant types (Authorization Code with PKCE, Client Credentials, Refresh Token); Bearer-token semantics; .well-known discovery; DPoP (RFC 9449). OIDC Client Credentials over mTLS as the SADAR authentication baseline. The urn:sadar:scope:v1 scope namespace with six initial scopes (search, resolve_manifest, list_registries, health, telemetry repatriation, target invocation). Service-sovereign token issuance — each target issues its own usage tokens; the registry is never the issuer. Usage key delivered as a JWE claim encrypted to the requester’s public key, cryptographically binding the key to the requester’s identity. TTL bounds (60s minimum, 24h maximum, 15min recommended) and lazy refresh. Grant type mechanics. Token format (JWT continues to apply). The IdP infrastructure an organization already operates. .well-known discovery semantics.

JWS and JWE

All SADAR-attested artifacts —manifests, the SCT, the usage key — are JWS and JWE constructions. SADAR specifies how they are composed but does not redefine the underlying formats.

SADAR — JWS and JWE integration
What it provides What SADAR adds on top What SADAR doesn’t change
JWS digital signatures (RFC 7515). JWE encryption (RFC 7516). Standard algorithm registry, JWA (RFC 7518). Key representation, JWK (RFC 7517). JWKS endpoints. Manifests signed with JWS (ES256 default; other algorithms permitted under the §5.1.8.1 baseline). The Signed Context Token format: JWS-inside-JWE — signed claims wrapped in encryption. The five SCT chain operations (Open, Continue, Hold, Authoritative Carry, Close) defining how authorization context propagates, suspends, and terminates across multi-agent flows. Usage keys delivered as JWE encrypted to the requester’s public key. JWKS endpoints required at every entity, agent, tool, and registry, exposing at minimum one signing key and one encryption key. Cryptographic parity requirement across baggage, span attributes, SCT claims, and Telemetry Record fields. JWS / JWE wire formats. Algorithm choices (ES256 is a default, not a fork). Key representation. Key rotation mechanics — handled by JWKS endpoint update without manifest republication.

OpenTelemetry

OTel is the substrate for SADR observability. SADAR makes OTel instrumentation a normative requirement and extends it with a small set of attributes, baggage fields, and a separate persistent audit artifact (the Telemetry Record). The OTel API and transport are unchanged.

SADAR — OpenTelemetry integration
What it provides What SADAR adds on top What SADAR doesn’t change
Spans, traces, baggage, metrics, logs. W3C Trace Context propagation. OTLP transport. SDK API for instrumentation. Sampling, batching, exporters. Normative OTel instrumentation across conformant SADAR implementations. Required span attribute telemetry.origin.environment carrying entity_urn:agent_urn:environment_id, with both ends of every interaction emitting attributed spans for tamper-evident reconstruction. Normative baggage fields including the live Risk Score Adjustment list under urn:sadar:baggage:v1:risk_adjustments and the business process identifier. The per-invocation Telemetry Record — a separate persistent audit artifact populated through the Helper API, with phase-immutability across Search, Selection, Invocation, and Outcome phases. The Repatriation protocol for governed cross-trust-boundary observability, triggered on span close when bilateral applicability is satisfied. OTel SDK API. OTLP transport. W3C Trace Context. Sampling, batching, exporter configuration. The choice of telemetry storage backend.

Model Context Protocol (MCP)

MCP is one of the canonical delivery mechanisms for the SADAR Discovery Tool. The tool is registered through MCP like any other tool; behind it sits the full SADAR discovery and governance stack.

SADAR — Model Context Protocol integration
What it provides What SADAR adds on top What SADAR doesn’t change
Model-tool communication protocol. Tool, resource, and prompt primitives. JSON-RPC over various transports. Tool definitions exposed to the model. The SADAR Discovery Tool, exposed through MCP as a registered tool that the model can invoke. The tool itself is a SADAR registry entry, subject to the same manifest and signing requirements as any other registry entry. Framework adapters translate the canonical SADAR discovery tool definition into MCP-specific registration formats. Behind the tool, SADAR adds bilateral matching, NFR-driven candidate filtering, trust model negotiation, and governance signals — concerns MCP does not address. The on-demand semantic discovery pattern (load tool definitions only when needed) parallels MCP’s recent shift in the same direction. MCP protocol mechanics. How models invoke MCP tools. MCP transport choices. Tool, resource, and prompt registration semantics.

Agent-to-Agent (A2A)

A2A specifies how agents communicate once they have found each other. SADAR's searchAndInvoke completes the trajectory by adding the agent selection step that A2A leaves out, and provides the cross-organizational authorization and observability context A2Adoes not define.

SADAR — Agent-to-Agent integration
What it provides What SADAR adds on top What SADAR doesn’t change
Agent-to-agent communication protocol. Agent capability advertisement via Agent Cards or .well-known/agent.json. Task lifecycle. Streaming and async invocation patterns. The agent selection layer A2A leaves out. A2A specifies how agents talk once they have found each other; prior agent selection is hardcoded, configured, or delegated to model reasoning. searchAndInvoke completes the trajectory: bilateral match against the registry, resolver-mediated selection, trust model negotiation, then handoff to A2A for the actual call. SCT chain semantics travel with A2A invocations, anchoring authorization context across agent boundaries. The Telemetry Record and Repatriation protocol provide cross-organizational observability A2A does not define. A2A’s message format and task lifecycle. A2A’s transport. Agent Card / .well-known/agent.json semantics.

Composite Invocation Trace

The following trace illustratesa single SADAR-mediated invocation, showing where each standard is exercised. The exact sequence varies with trust model, federation topology, transport choice, and whether the invocation extends an existing SCT chain or opens a new one.

SADAR — Composite invocation trace
# Action Standards exercised
1 SAI calls the registry with discovery criteria. SADAR registry protocol; mTLS; OIDC Client Credentials with urn:sadar:scope:v1:search.
2 Registry runs bilateral match across NFR categories, business process, and data fields. SADAR bilateral match algorithm (no external standard at this layer).
3 Registry returns the classified candidate set with FULL_MATCH / PARTIAL_MATCH manifests. JWS manifest signatures (RFC 7515) verified as part of result handling.
4 Consumer-supplied resolver selects exactly one candidate. SADAR Resolver Contract.
5 SAI authenticates to the selected target’s authentication endpoint. OIDC Client Credentials; mTLS; urn:sadar:scope:v1:invoke (or scope appropriate to the operation).
6 Target issues a usage key bound to the requester’s identity. OAuth token issuance; JWE (RFC 7516) — key encrypted to the requester’s JWK.
7 SAI dispatches the invocation, attaching an SCT. SCT (JWS-inside-JWE); transport is MCP, A2A, HTTP, or gRPC at implementer choice.
8 Both ends emit OTel spans carrying provenance attribution. OpenTelemetry; SADAR span-attribute schema (telemetry.origin.environment, telemetry.repatriated).
9 Components emit Risk Score Adjustments; the live list propagates in OTel Baggage; an accumulated scalar is embedded in the SCT chain. OTel Baggage; SADAR Risk Score schema (urn:sadar:baggage:v1:risk_adjustments).
10 Repatriation triggers on span close where bilateral applicability is satisfied. SADAR Repatriation protocol; OTel span lifecycle.
11 SAI finalizes and persists the Telemetry Record. SADAR Helper API; SADAR Telemetry Record schema.

Where SADAR Is Intentionally Silent

Several concerns are out of normative scope by design. In each case, SADAR defers to the standard or implementation choice that already addresses the concern.

•       Identity provider implementation. SADAR uses whatever IdP an organization operates. There is no SADAR IdP; there is no SADAR identity broker.

•       Cryptographic primitives. Algorithm choices follow the JWS / JWE algorithm registry. ES256 is a default for manifest signing, not a fork.

•       Telemetry transport. SADAR specifies what is in the spans and what is in the Telemetry Record; OTLP, gRPC, HTTP, and exporter configuration remain implementer choice.

•       Agent invocation transport. Whether an invocation rides over MCP, A2A, plain HTTP, or gRPC is implementer choice. The SCT, span attributes, and Telemetry Record apply uniformly across transports.

•       Telemetry Record storage. The persistent backend (object store, log pipeline, audit warehouse) is implementer choice; SADAR specifies the artifact, not where it lives.

•       Risk Score accumulation algorithm. Implementers select the algorithm appropriate to their domain — weighted sum, exponential moving average, Bayesian, predictive ML, or hybrid — within the implementer-obligation constraints.

•       Resolver business logic. Selection from the bilateral-match candidate set is consumer-supplied code, constrained but not specified.

Where to Learn More

•       Architecture Overview — components, premises, and the end-to-end flow at the architecture level.

•       Layered Model — Discovery, Identity & Trust, Invocation, Observability, and Risk treated as discrete architectural layers.

•       2. Scope — the umbrella specification; defines what is and is not in normative scope.

•       4. SCT Operations — SCT structure, claims, and the five chain operations as JWS-inside-JWE constructions.

•       6. Telemetry Record and Repatriation — Telemetry Record schema, the OTel span structure with provenance attribution, and the repatriation protocol.

•       7. searchAndInvoke Telemetry and Authentication— Helper API, repatriation trigger, OIDC scope namespace, and initial scope set.

‍