This document introduces the SADAR Context Token (SCT) — SADAR's mechanism for propagating authorization context across trust boundaries — and describes the SCT chain, the five chain operations, and the validation properties every receiver applies to incoming SCTs. It stays at the architectural level; the full normative specification lives in 4. SCT Operations companion document (chain operations and the four abstract operations any conformant implementation must support) and in 5. Trust Models companion document Part II (asserted-model-specific validation).
Audience: enterprise architects, security architects, and implementers responsible for SCT-conformant authorization context propagation.
The SADAR Context Token is a JWS-inside-JWE— a digitally signed claim set wrapped in encryption — that travels with each invocation across a SADAR-mediated multi-agent flow. It carries authorization context attested at every trust boundary crossing: the originator's identity and authentication, the trust model under which the flow operates, the business process the call participates in, the accumulated Risk Score scalar, and the cryptographic linkage to the prior segment in the chain.
The choice of JWS-inside-JWE is deliberate. The signature provides tamper-evidence: any modification to a segment's content invalidates the signature and is detected on validation. The encryption provides confidentiality: the segment's claims are visible only to the JWE recipient. The two properties are independent — a party that cannot decrypt a segment can still verify its signature and its place in the chain. This independence is what lets an SCT chain be auditable end-to-end while preserving per-segment confidentiality across organizational boundaries.
The SCT is not an authentication token. It does not authorize the caller to make the call; the authentication baseline (OIDC Client Credentials over mTLS) does that. The SCT carries the authorization context for the operation, attested at each handoff so that downstream parties can reason about who originated the flow and under what authority.
As a flow traverses multiple agents, services, or organizational boundaries, each crossing produces a new SCT segment cryptographically chained to the prior one. The full chain — the linked list of segments from Open to Close — is the cryptographically attested record of how authorization context evolved through the flow.
The chain is the canonical audit substrate. Where retrospective reconstruction of "who authorized what, when, on whose behalf" is required — regulatory inquiry, incident investigation, compliance audit — the SCT chain is ground truth. Each segment's signature is verifiable against its issuer's published key material in the registry; each parent-child binding is verifiable against the prior segment's jti. Tampering anywhere in the chain is detectable from the chain alone, ithout external state.
Chains are structurally immutable. Adding a segment produces a new chain that includes the prior segments unchanged; modifying a prior segment invalidates that segment's signature and any downstream binding that depends on it. This is a property of the format, not a runtime constraint — implementations cannot conformantly mutate prior segments because the result would fail integrity verification by anyone with access to the issuers' public keys.
Each segment in an SCT chain represents one of five operation types, identifying the segment's role in authorization context propagation. The operation type is fixed at issuance and recorded in the segment's claims.
These five operations are the vocabulary by which a chain expresses its authorization narrative. A flow that runs cleanly typically begins with Open, threads through one or more Continue or Authoritative Carry segments, and ends with Close. Asynchronous flows insert Hold-Resume pairs at the suspension points. The mid-chain trust model (the originating_user_trust claim) is fixed at Open and persists through all subsequent segments; a flow needing a different trust model partway through closes the existing chain and opens a new one, with cryptographic linkage preserved through the chain-of-chains mechanism.
Every SADAR-conformant receiver of an SCT applies the validation checks below before honoring the chain. These are the trust-model-agnostic properties — they apply to every chain, regardless of whether the originator was direct-authenticated, asserted, impersonated, or operating under deputy.
Validation is fail-closed. A receiver that cannot complete a check — for any reason — rejects the invocation rather than proceeding under reduced trust. Structured errors use the urn:sadar:error:v1 namespace; the specific error category depends on which check failed (signature, chain integrity, parity, replay, suite acceptance).
Trust-model-specific validation runs after these checks pass. The asserted model has its own additional validation algorithm — asserter identity verification, originator namespacing, Role claim handling — covered in the Trust Models page and in 5. Trust Models companion document Part II. Other trust models apply additional validation at provider discretion within the constraints of §5.1.8 and §5.1.15.
Every SCT chain declares a Chain Crypto Suite at the chain header level, identifying the signature, encryption, key wrap, and hash algorithms in use. The assertion is chain-wide: all segments in a chain use the same primitives. Mixed-primitive chains are not conformant.
Receivers inspect the asserted Chain Crypto Suite before any cryptographic operation and reject chains whose suite is not on the receiver's accepted-suite list. Acceptance-list policy is a deployment configuration concern. The suite assertion itself is covered by the JWS signature so it cannot be altered without invalidating the chain.
Post-quantum migration is documented in 4. SCT Operations §B.8.6. The migration path includes ML-DSA (FIPS 204) for signatures and ML-KEM (FIPS 203) for key encapsulation, with hybrid suites combining classical and post-quantum primitives during the transition. Specific suite identifiers will be added once IETF JOSE finalizes the corresponding JWS/JWE algorithm registrations.
Conformant SCT implementations support four abstract operations defined in 4. SCT Operations companion document. The operations are abstract — implementations expose them through any interface idiom appropriate to their language or runtime, provided the defined behavior is preserved.
Most production callers use Extract Claims as their primary entry point — it provides validation and claim retrieval in a single call. Validate exists for preflight checks where a caller wants to confirm chain validity without retrieving claims (e.g., before deciding whether to proceed with a more expensive operation). Verify Chain Integrity is the operation an audit consumer uses when it has access to the issuers' public keys but may not be able to decrypt every segment — chain coherence is verifiable end-to-end on cleartext metadata alone.
The SCT and its chain are onelayer of the SADAR security architecture. Several adjacent concerns are out of scope here and live in dedicated sibling pages or companion documents:
• Security Overview — orientation to the security layers and how they compose.
• Authentication Baseline — how entities authenticate to one another beneath the SCT.
• Trust Models — the four originator trust models, bilateral negotiation, and the asserted-model validation algorithm.
• Authentication Scopes — urn:sadar:scope:v1 namespace and the six initial scopes.
• Registry Security — registry isolation, manifest signing, and cryptographic parity.
• Telemetry Record — the per-invocation persistent audit artifact that references the SCT chain.
• 4. SCT Operations — the full normative specification of the SCT format, the four abstract operations, the error contract, the Chain Crypto Suite system, and post-quantum migration.
• 5. Trust Models, Part II — asserted-model SCT validation algorithm, four rejection conditions, default-role handling, and structured error codes.
• 2. Scope §5.1.8.2 — the umbrella SCT requirement and the five chain operations.
• 2. Scope §5.1.17 — Cryptographic Parity, the foundation for tamper-evident audit reconstruction.