This document introduces SADAR's four trust models — the normative patterns by which an originator's identity propagates through a multi-agent flow — and describes how a model is declared, negotiated, recorded in the SCT, and (for the asserted model) validated by the receiving server. It covers both Part I (definitions and negotiation) and Part II (asserted-model SCT validation) of the 5. Trust Models companion document at the architectural level.
Without a normative taxonomy, agent-to-agent invocations have no shared vocabulary for "in what sense is this caller acting on behalf of whom." Servers cannot reliably enforce policy, because the enforcement rules differ depending on whether the caller is the originator, an asserter making a claim about an originator, the originator under a set uid pattern, or a delegate carrying the originator's authority while retaining its own identity. Each pattern has different security properties, different audit implications, and different fits with downstream policy decisions. The four trust models give organizations a precise way to express the answer.
Audience: enterprise architects,security architects, and implementers building SADAR-conformant providers(which validate incoming SCTs) or requesters (which negotiate trust models atdiscovery and operate under the negotiated model).
SADAR defines exactly four trust models. The model identifiers are case-sensitive lowercase and appear in this exact form in SCT claims and manifest NFR arrays.
Each invocation operates under exactly one model. The model is fixed at chain Open and persists through all subsequent segments via the originating_user_trust SCT claim. A flow that needs a different model partway through closes the existing chain and opens a new one— cryptographic linkage between chains is preserved through the chain-of-chains mechanism in 4. SCT Operations.
The originator's identity is established through direct authentication with an IdP in the current session. The SCT carries authentication evidence — typically the IdP's ID token or a derived assertion. The originator and the calling agent are either the same identity (originator-driven) or the agent acts under the originator's session authority (session-bound).
Use cases: user-initiated agent flows where the user directly logs in and the agent operates within the user's session. Familiar from web application architectures.
Server policy implications: the server typically applies user-level policy — authorization based on the originator's roles and permissions — and audit attribution is to the originator.
The calling application authenticates with its own service credentials (typically OAuth Client Credentials) and asserts a claim about the originator: "originator X is performing this action under role Y." The originator does not authenticate to the receiving service in this session. The SCT carries the asserter's identity and the asserter's claim about the originator's identity, plus a Role claim drawn from the server's declared supported_roles.
Use cases: back-office batch processing where system-of-record services initiate operations on behalf of historical originators; service-to-service calls where the originator is logically present but not authenticatable in this session; ETL pipelines processing user-attributed records.
Server policy implications: the server validates the assertion and applies role-based policy per the Role claim. Audit attribution names both the asserter and the asserted originator. The server-side validation algorithm is described later in this page.
The agent presents the originator's identity (not the agent's) at downstream services. set uid-style —the agent steps into the originator's shoes. The SCT carries the originator's identity in the position normally occupied by the caller, and may include an indication of which agent is impersonating.
Use cases: where downstream services apply policy based exclusively on the originator's identity and the agent is essentially a stand-in. Legacy integration where downstream services have no notion of agents and only understand users.
Operational considerations: impersonation loses agent attribution at the immediate hop — the downstream service sees the originator, not the agent. This makes operational forensics harder when agent-specific behavior is at issue. Logging at the impersonating agent SHOULD preserve the agent's identity locally even though it does not appear in the SCT forwarded downstream. impersonation typically has the highest operational risk among the four models because it allows agents to act as users with the users' full authority. Where deputy is sufficient, deputy should be preferred.
The agent presents both its own identity AND the originator's identity. The SCT carries both. The agent operates with the originator's authority but downstream services see the agent as the actor — a constrained delegation pattern.
Use cases: agent-driven flows where preserving attribution at every hop is important; multi-step business processes where an agent reads from one system on behalf of a user and writes to another; audit-rich environments.
Server policy implications: the server may apply policy based on either identity or both. Common patterns include originator-based authorization with agent identity logged for audit; both-identity authorization where the operation requires both the originator's authority and the agent being on a trusted-agent allowlist; and agent-bounded scope where the originator may have broad authority but operations under the deputy SCT are constrained to a subset appropriate to the agent.
Every SCT chain link carries an originating_user_trust claim identifying the trust model under which the chain was opened. The value is one of the four lowercase identifiers above. Once set at the Open operation, the value persists through Continue, Hold, Authoritative Carry, and Close operations. The chain's trust model is fixed at Open and SHALL NOT change mid-chain.
Manifests declare which trust models the entity supports for each capability. The value is an array of trust model identifiers; the array order is significant — it expresses the declaring entity's preference ordering, used in the negotiation algorithm. In the requester section, the array indicates which models the requester is willing to operate under when calling other capabilities. In the server section, the array indicates which models the server accepts for incoming invocations of this capability. Manifests SHALL declare at least one trust model; an empty array is malformed and rejected at registry-side validation.
At discovery time, the requester's and server's supported_trust_models arrays are evaluated to select the trust model used for the invocation. The algorithm:
• Step 1. Compute the intersection of the two arrays.
• Step 2. If the intersection is empty, the candidate is NO_MATCH on this dimension and is excluded from results.
• Step 3. If the intersection has exactly one element, that is the negotiated trust model.
• Step 4. If the intersection has multiple elements, compute combined preference rank for each candidate model: rank =(requester's position) + (server's position) where position 0 is most-preferred. Lower combined rank wins.
• Step 5. If multiple models tie on combined rank, prefer deputy over other models. If deputy is not in the tied set, the resolver receives the tied candidates and selects per its policy.
Why deputy wins ties. deputy is the more constrained pattern — it preserves agent identity downstream, enabling fuller audit and per-hop policy. Where multiple models would work, the more-attributable choice is preferred. The negotiated model is encoded in the discovery result so the requester knows which model to operate under, and SAI invokes the target with an SCT chain Opened under the negotiated model.
Across the four trust models, originator identifiers appear in different forms in the SCT. SADAR defines a normative namespacing pattern that handles all four uniformly:
In the asserted model, there is no IdP for the originator in this session. The asserter is making a claim about an originator whose identity exists in the asserter's domain — employee ID, customer ID, account number, etc. Namespacing under the asserter prevents collision when multiple asserters use the same local identifiers:asserter-A:emp_123 and asserter-B:emp_123 are distinct originators. The complete originator URN is of the formurn:sadar:originator:<naming_authority>:<originator_id>.
The asserted model carries inherent risks not present in direct_auth: the originator's identity is asserter-asserted, not directly verified. SADAR addresses this through two mechanisms — a role declaration model that lets servers express what asserters can claim, and a server-side validation algorithm that fails closed on any irregularity.
Servers supporting the asserted trust model declare the roles they recognize via the supported_roles ProtocolNFR. Each role declaration carries a role_id, a human-readable description, an array of permission objects (operation, resource, scope), an optional process_authority constraint, an optional audit_template, and an optionalis_default boolean.
At most one role per manifest may declare is_default=true. Registry-side validation rejects manifests with multiple defaults. The default role applies when an incoming SCT carries no explicit Role claim — see Server-Side Validation below.
When a server receives an invocation under the asserted trust model, it applies the four-step validation algorithm below. Validation is fail-closed: any uncertainty rejects rather than passes. Servers that do not validate, or validate incorrectly, are not conformant.
Step 4 includes default-role handling for SCTs that arrive without an explicit Role claim. The four cases:
Case C is the operational expectation. A server supporting asserted invocations from systems that may not always include explicit Role claims declares a default role (e.g.,"claim_processor" with is_default=true) so invocations without explicit role assignment still receive meaningful policy-applicable role context. Case B is the strict-policy alternative — every invocation must specify a role explicitly.
On successful validation, the validated context for policy purposes comprises the asserter identity, the namespaced originator identity, the validated role_id, and the role's permission objects. How the server then evaluates and enforces policy on this context is server-internal and out of SADAR's normative scope.
Trust models address how an originator's identity propagates through a flow. Several adjacent concerns are deliberately out of scope here: