SADAR Trust Models — Addendum: Authentication and Delegation at Invocation

Design specification — Draft, June 2026

Companion to the SADAR Trust Models. This addendum addresses how authentication credentials are selected and carried when SAI invokes a component (agent, tool, or resource), and how that relates to the authority on which an action is permitted. It states the current default behavior and records the intended direction for finer-grained, per-step selection.

1. Scope

When SAI invokes a component, an authentication credential must be presented at that component's endpoint. This addendum specifies:

The default credential model SADAR applies at invocation;
The separation between the credential presented (authority to attempt an action) and the determination of whether an action is appropriate (authority to perform it);
The division of responsibility between the deploying organization, SADAR, and an enforcement layer; and
The intended future direction — per-step selection of delegation models — recorded here as intent, with mechanics to be specified in a later revision.

This addendum does not define organizational authorization policy, role design, or access-control lists. Those are the deploying organization's responsibility and are out of scope (§4).

2. The Default Credential Model

At invocation, SADAR's default behavior is to present the application (platform) credentials, while the originator's verified identity and the originator's scope of authority (SoA) are carried within the SCT.

Concretely:

The application/platform credential authenticates the calling platform to the target component — establishing that this platform may invoke this component.
The originator's verified identity (originating_user) and the functional scope of authority (the RFC 9396 / RAR authority claim) are carried inside the SCT, propagated faithfully across the chain.
The target component, and any enforcement layer associated with it, reads who the work is for and under what functional authority from the SCT — not from the credential.

This model is chosen because it is the most broadly workable default for agentic flows: it does not require every originator (user) to hold a standing credential in every component a flow might reach, and it does not require per-agent provisioning at each target. The originator's identity and authority are still present and attributable at every hop — carried by the substrate rather than by the credential.

Why the application credential is sufficient as a default. The instant a flow invokes its first agent, the flow is no longer a fixed, fully-predetermined sequence — the agent may act in ways not statically enumerable in advance. From that point, the credential's role is to establish standing to attempt actions within the calling context, not to enumerate or gate the specific actions that will occur. The determination of whether a specific action is appropriate is made elsewhere (§3). Presenting the application credential, with the originator and SoA carried in the SCT, gives every downstream component and enforcement layer exactly the information it needs to make that determination, without over-burdening the credential layer with a job it cannot do in an emergent agentic flow.

3. Authority to Attempt vs. Authority to Perform

A foundational premise of SADAR is that authentication and authorization, as traditionally implemented, are not sufficient to govern actions in agentic flows. The appropriateness of an action is frequently contextual — dependent on the specific data, the moment, and the surrounding flow — in ways that static, pre-issued credentials and entitlements cannot express.

SADAR therefore distinguishes two questions that traditional access control tends to conflate:

Authority to attempt. The credential presented at a component establishes standing: this caller is entitled to reach this component and attempt action within a bounded surface. Organizations scope this surface through their existing identity and access management — for example, by defining domain- and role-centric agents (a payroll-operator agent versus a payroll-user agent), each carrying the role-appropriate standing. This keeps standing bounded, legible, and auditable in familiar terms.
Authority to perform. Whether a specific action, on specific data, at this moment, within that standing, is appropriate — is a contextual determination. Within a legitimately-held role surface there remain actions the role could perform but should not in a given context. Catching that residue is the job of a runtime enforcement layer, which evaluates the action against the context the SCT carries (originator, SoA, the action, the chain).

The credential is authority to attempt; the enforcement layer's contextual decision is authority to perform. SADAR's role is to carry the information both layers need — faithfully and across trust boundaries — not to make the access decision itself.

Important deployment condition. Because the credential layer in this model establishes standing rather than gating each action, the model depends on a runtime enforcement layer being present in the action path. Where no enforcement layer is present, deployments should treat credentials in the traditional manner (as gating authority) and scope standing accordingly. Role-scoped standing (above) provides a bounded fail-safe: absent an enforcement layer, the reachable surface is still bounded by the role the credential carries, not unbounded.

4. Division of Responsibility

Concern	Owner
Defining scopes of authorization for agents and tools (roles, entitlements)	The deploying organization (its IAM). Resources are typically governed by ACLs applied at the tools that access them.
Performing that scoping competently	The deploying organization. SADAR relies on this having been done; it is out of SADAR's scope.
Carrying originator identity, SoA, and chain-of-custody faithfully across the flow	SADAR (the informational substrate for transparency, discovery, and enforcement).
Deciding whether a specific action is appropriate in context	An enforcement layer (outside SADAR).

SADAR's sole responsibility is the informational substrate supporting transparency, discovery, and enforcement. It defines neither the organization's authorization scopes nor the enforcement decision. (Registry-based discovery may reasonably be regarded as adjacent to the pure substrate role; this addendum does not take a purist position on that boundary.)

5. Current Behavior (Normative for this Revision)

For the current revision of the specification:

A conformant SADAR implementation SHALL, by default, present the application (platform) credential at component invocation and carry the verified originator identity (originating_user) and the functional scope of authority (RAR authority claim) within the SCT.
The originator identity and SoA carried in the SCT SHALL propagate faithfully across trust boundaries, so that any component or enforcement layer in the chain can read them (subject to the SCT's confidentiality model).
SADAR SHALL NOT be relied upon to make the access decision; the determination of an action's appropriateness is the enforcement layer's concern.

This default is intentionally simple. It is sufficient for the common case and provides every downstream layer with the originator and authority context required for enforcement.

6. Intended Direction (Non-Normative)

SADAR is the layer that handles authentication at invocation, so it requires a default behavior and, in time, a means for a flow to request a particular delegation model. This revision specifies only the default (§5). A future revision is intended to add per-step selection of delegation models, in which:

Multiple delegation models (for example: application-credential-with-attribution, direct user delegation, on-behalf-of / impersonation, and constrained delegation) are expressible;
The requester and the server each expose the delegation models they support, as ordered, set-valued capabilities, matched bilaterally in the same manner as other non-functional requirements;
A SADAR Process Definition may additionally prescribe, per step, the set of delegation models the flow's design permits — introducing a third, narrowing criterion, so that selection becomes the matched intersection of requester, server, and process-prescribed sets.

These mechanics — the model vocabulary, the matching and intersection semantics, the per-step prescription field, and the handling of an empty intersection — will be specified in a later revision. They are recorded here as intent so that the current default (§5) is understood as the first model of several, not the only model SADAR will support.

Until that revision, the default model of §5 applies.

Terminology note: "authority to attempt" denotes the standing established by a presented credential; "authority to perform" denotes the contextual determination, made by an enforcement layer, that a specific action is appropriate. SADAR carries the information both rely upon; it makes neither determination itself.

‍