Continuity Is Not One Thing

Systems built around OAuth have a continuity problem. A traditional flow crosses a reassuringly small number of boundaries: a client sends a user to an authorization server, the user authorizes something, the client receives a token and calls a resource. Delegated and agentic systems stretch that transaction in several directions at once. A request may traverse brokers before reaching the authorization server. Work may continue after the user leaves. An agent may call a service in another authorization domain, where the original identity still matters but the original authorization does not apply. And a credential may remain valid after the work that justified it has ended.

These can all be described as preserving context across boundaries, which makes the proposals addressing them look like competing versions of one mechanism. In fact, they answer four different questions:

Alice, an employee at Acme, asks the company’s AI assistant to analyze the Q3 Salesforce pipeline and prepare a report. The assistant delegates the analysis to a sales agent, which reads Salesforce opportunities and correlates them with Acme’s internal customer risk service. Alice approves the application’s participation, closes her laptop, and the work continues without her. Alice initiates the undertaking; Acme, as resource owner, supplies the policy authority over enterprise data; each authorization server decides what authority to issue; each resource decides the concrete action; and an Acme-designated lifecycle authority owns the state of the work itself.

That workflow surfaces all four questions at different boundaries, times, and deciders. Continuity does not mean preserving one claim unchanged. It means carrying enough authenticated evidence for the next authority to establish the facts it needs without inheriting another authority’s conclusion.

Four Questions, Separate Authorities

The tempting alternative is one artifact carrying user, client, actor chain, authorization, resource, delegation path, purpose, task, and constraints. It stays simple only until different parts of the system need different facts, establish them at different times, and trust different authorities to assert them. The problem is not one envelope but one undifferentiated authority: an audience-specific package may carry independently signed components from several authorities, so long as their semantics, validation, and lifecycles remain separate.

Nor does the separation imply four tokens or four network calls. Evidence can be embedded, referenced, or retrieved live according to its risk and lifecycle. The architectural requirement is that packaging must not erase who asserted each fact, what it means, how fresh it must be, or who can end it.

The separation is structural rather than nominal: each question has its own fact family, authoritative sources, decider, and lifecycle, which is why the four cannot collapse into one another:

One word does three jobs in this field, so this post separates them: authority is permission to act, an authoritative source is the party trusted to assert a fact, and a decision authority is the party entitled to decide for a target context.

The test is non-entailment under separate governance: no question’s answer can stand in for another’s. A subject remaining the same implies nothing about what may be done in her name downstream. Valid authority implies nothing about whether the work behind it survived the night. A verified request path implies nothing about actions taken after the decision it informed. The unit of separation is the question rather than an atomic fact; identity continuity alone may consume subject attribution, actor identity, authentication context, and the asserted relationship among them.

Three clocks tick inside every row: the state of the fact, the freshness of evidence about it, and the applicability of a decision made from that evidence. Alice’s identity does not expire because an assertion does, and a work record can remain active while a cached decision about it goes stale.

The set is not closed by decree. A separate continuity question is justified when a recurring decision requires independently governed evidence that must survive or be re-established across boundaries and cannot be inferred from the other answers. Presenter binding is instead a precondition on using evidence, and transaction context is a carrier of facts serving several questions. Work state is an authorization input, as posture and risk are, but it plays a different semantic role: posture and risk are conditions evaluated while deciding an action; work is the normative referent the action serves, an undertaking with an owner entitled to end it. Work continuity becomes separate exactly when that undertaking must outlive, or be governed independently of, its session and grants.

Evidence production and decision-making are increasingly distributed among specialized authorities. Their effects converge at the action boundary, which is why the composition rules below are written for the boundary taking the action rather than for any one issuer.

Single-issuer systems did not answer all four questions so much as hide many seams: grant, token, introspection, and revocation state often shared one governance root, while the other questions rarely arose. Multi-issuer estates and work that outlives sessions expose what colocation concealed.

Question 1: Request Continuity

The assistant needs Salesforce access first, but it is not registered there. Acme operates an authorization broker that is, so the request reaches Salesforce through the broker.

At the Salesforce boundary, the immediately visible OAuth client is the broker, and that is not the whole transaction Alice is being asked to approve. The request originated with an AI application and traversed the broker, and the authorization server may need to know that path to make the right authorization and consent decision. The question at this boundary is one of provenance:

How did this authorization request get here?

The proposed OAuth Authorization Request Delegation Chain addresses this directly. Each intermediary signs a hash-linked node attesting to the client it directly knows, allowing the Salesforce authorization server to verify the path from the assistant through the broker rather than seeing only its immediate peer. Each node needs an authoritative signer, and who vouches for the originating client is the decisive trust decision: a broker entitled to assert that origin could also invent one.

The path must be bound to the client, redirect, resource, and authorization details in the actual request, composing with JAR and PAR where they carry it. It can then be committed to the consent record. The draft still has to harden truncation, downgrade resistance, and signaling that a chain was required; the enduring requirement is authenticated, non-truncatable provenance bound to the request. Even then, a consent record proves what the server recorded, not what Alice understood: you approve what you were shown remains the harder half.

This evidence is presented at the authorization endpoint and consumed before token issuance. It serves the authorization server deciding what Alice sees and what it will issue; it says nothing about later actions.

Question 2: Identity Continuity

Alice approves, the assistant begins working, and it delegates the analysis rather than handing over its token: the sales agent obtains its own credentials from Acme’s authorization server. When it later calls the customer risk service, Alice is absent, but the service may still need to attribute the activity to her.

Authenticating the agent does not answer that. Client authentication establishes an OAuth registration; workload identity in the style of SPIFFE attests the process beneath it; actor evidence identifies the current actor. Work such as WIMSE and the SPIFFE client-authentication profile connects some of those layers, but a deployment may still need more than one. A profile must define how the evidence is reconciled: Token Exchange relates an actor token to the act claim it issues but does not bind either to the authenticated client. The system may separately need the subject to whom the activity is attributed:

Whose identity remains applicable across this boundary?

The Identity Continuation Assertion targets this question with explicit evidence that an upstream identity continues across the next boundary. The Identity Assertion JWT Authorization Grant carries enterprise identity toward a resource’s authorization server, which still decides locally; the proposed OpenID Authentication Token instead continues evidence of the authentication event. These mechanisms establish different identity facts at later boundaries. They may identify the subject and actor, or say who asserts their relationship, but they do not by themselves authorize the actor to act for the subject.

That last distinction is easy to lose in claims such as act, which identifies the delegated actor inside an issuer’s authorization statement: it does not independently define permission, establish the token’s validity, or prove that the current presenter is that actor. The attribution relationship belongs in the evidence presented to authorization; it is not authorization by another name.

Question 3: Authorization Continuity

At the same hop, identity evidence can give the customer risk service well-founded confidence that the subject is Alice. It establishes nothing about whether Alice, or an agent acting for her, may read that service’s records. Salesforce authority was scoped to Salesforce; carrying Alice’s identity to a resource governed by another authority cannot silently convert it into permission there:

What authority legitimately survives, or is re-established, across this boundary?

An existing grant may already cover the downstream resource. When it does not, what crosses the boundary has one of three semantic effects:

These are semantic effects, not wire operations: preservation may involve minting a new representation, and attenuation names a parent-child relationship whoever derives the child. A Transaction Token can carry short-lived identity and authorization context without becoming an OAuth access token or adding a fifth continuity question. It also demonstrates that mechanism does not fix effect: the token service chooses the internal subject and scope semantics, so one issuance may preserve applicable context, attenuate it, or make a new trust-domain assertion, and only the profile’s proof makes it preservation.

Preserve when applicability can be proved; attenuate when non-amplification can be proved; otherwise decide anew or deny.

The proof obligation, not the issuer’s involvement, distinguishes attenuation from deciding anew. A child whose validity is solely derived from a demonstrable non-amplifying relationship to its parent is attenuation. A child resting on a fresh authoritative decision, however narrow, was decided anew. Preservation is stricter than forwarding: the verifier must establish that the same fact remains applicable under the same vocabulary and policy authority. A new audience, issuer, trust root, or authorization semantics usually requires a new decision however similar the claims look.

Crossing a boundary must not silently manufacture authority, and authorization continuity must never be inferred from identity continuity.

Attenuation’s discipline is comparison. The child must be no broader on every authority-bearing dimension at once, so narrowing scope while extending lifetime may still amplify authority, and selective disclosure is not by itself attenuation.

Comparison has three outcomes: narrower, equivalent, or incomparable. Inside one vocabulary, a profile can define a partial order, as Macaroons do with appended caveats and Biscuit does with a defined algebra. Across vocabularies the order may not exist: expenses.submit and charges.create are strings, not proof that one contains the other. Incomparability is a safe result, routing the request to an authority that can decide, potentially through an OAuth challenge carrying the denial and a way to ask again, down to a single transaction.

Translation is not a fourth outcome. A representation change that preserves the same authoritative fact remains preservation; a translation that creates a target-local permission is a new decision. A denial carries nothing across the boundary, while an OAuth challenge can describe what evidence or authority a new request would need.

Attenuation therefore stops at the boundaries owned by the other questions. It cannot observe that Alice’s identity mapping changed or that the work was canceled overnight. Offline attenuation can operate inside a revocable work envelope, but attenuation itself only narrows; it never extends, re-subjects, or re-justifies.

Presenter binding and presenter transition are different contracts. Binding establishes that the current presenter may use an artifact by composing possession of its bound key, the identity of the client or workload controlling it, and, where required, assurance about the runtime. Transition establishes that a successor presenter is entitled to take over; where the artifact carries authority, that is itself an authorization-continuity event. Time, device posture, workload state, and session risk remain dynamic inputs to the resulting decision rather than new continuity questions.

Bounded continuation after the user leaves also remains an authorization concern. Delegated Refresh Tokens return delegated refresh-token families whose issuer reevaluates each redemption and constrains rotation, and the draft is candid about where the questions split: the client must keep a one-to-one association between a family and one asynchronous task, and promptly revoke the family at the task’s terminal state, while the task identifier deliberately never reaches the authorization server. Question 3 is standardized at the issuer, Question 4 stays a client-local obligation, and what is missing is work identity and lifecycle evidence another issuer or enforcement point could verify. UMA 2.0 likewise demonstrates party-absent authorization without supplying a cross-issuer work lifecycle.

The customer risk service now holds identity evidence for Alice, actor evidence for the sales agent, and read authority issued by its own authorization server under Acme policy. Salesforce authority never reached it. This hop requires a fresh local decision; a Transaction Token would preserve context only if the receiving service accepted the same trust-domain authorization semantics. Keeping identity and authorization separate leaves policy free to accept attribution while refusing upstream permission, require a new decision, or attenuate comparable authority.

Question 4: Work Continuity

Let the agent keep working. The next morning it still holds a technically valid credential. Should it continue reading customer records?

Identity continuity does not answer that; the subject may still be Alice. The grant and credential may also remain valid after the report finished, Alice withdrew the request, an administrator ended the operation, or its budget ran out. The separation test is a counterfactual: if identity and authorization remain valid, can the action become impermissible solely because the work ended? If so, the undertaking has a lifecycle of its own. This question concerns justification rather than credential validity:

Does the approved work still justify this action now?

One proposed realization, Mission-Bound Authorization, with draft-mcguinness-oauth-mission as its core, uses a Mission: a durable, revocable record of the approved work. The question stands whether or not an estate uses that realization. In the steel thread, the record might contain:

The work is attributable to Alice as initiator, while permission to read enterprise systems flows from Acme as resource owner rather than from a personally transferable right of hers. Approval, status reporting, and termination may likewise belong to different Acme authorities under the same non-collapse rule; the example’s single designated authority stands for that set, whose references stay distinct in the record even when one platform implements them. A consequential action can require acceptable identity evidence, sufficient target-local authorization, and active approved work. End the work and the action is denied while the other facts remain true. What disappeared is the continuing justification for using them together.

If a resource denies an action when the Mission is inactive, is Mission simply another authorization input? At decision time, yes: enforcement remains authorization. What stays separate is the input’s governance and lifecycle. Its authority need not be the token issuer, authorization server, or resource, just as Token Introspection already supplies live state to a resource decision.

Introspection, revocation, and grant management remain issuer-local. Workflow engines, purpose-based access control, and approval systems already govern durable work inside individual systems. What has no standard form is a contract for correlating and terminating work state across grants, clients, issuers, and enforcement points that no one authorization server mediates. A Mission proposes one root record with target-local children where another domain requires its own lifecycle. Root termination withdraws the warrant for new actions as each participating boundary observes it; it is not retroactive erasure or an instantaneous global kill.

An estate can approximate this today: a workflow engine holds the status, introspection exposes work-related state, and Shared Signals distributes changes. The approximation breaks at organizational and issuer boundaries because identifiers, association policy, and termination remain silo-specific. The interoperability gap is not the ability to store a job status; it is the contract connecting that status to independently issued authority and enforcement.

No separate work lifecycle is required when work and grant deliberately co-terminate. The fourth question becomes necessary exactly when work can end or change while its grant and credential remain valid.

Active status is not enough: the action must also fall inside the work’s approved envelope. That envelope is purpose-limitation policy, the principle privacy regimes have long required without an authorization-side enforcement point, and a deployment could put the same constraints in a grant. The additional property is independent governance and correlation across issuers. A work record does not prove Alice authenticated or supply target-local permission; it supplies purpose and lifecycle state that target authorization may require.

Work enforcement therefore asks two questions: does the undertaking still stand, and does this concrete action fall inside its approved envelope? The second comparison has the same three outcomes as attenuation: inside, outside, or incomparable. The target decides locally when vocabularies do not permit a proof.

The Boundary Contract

Composition has a failure mode of its own. If each boundary verifies its fact in isolation, nothing yet proves that the facts belong to the same decision context: identity evidence from one exchange, authority minted for another, and a Mission approved for a third could each verify perfectly and still be spliced into a plausible whole. Separation without correlation is an invitation to substitution.

Here, a boundary is a point where a change in intermediary, namespace, audience, policy authority, presenter, or lifecycle authority means an earlier conclusion can no longer be assumed. A deployment implements only the continuity questions its boundaries reopen. A brokered login may need request provenance alone; a cross-domain agent call needs identity and authorization continuity; work continuity becomes relevant when the undertaking can outlive or diverge from its grants.

At every such boundary, a continuity profile must define one contract:

The companion kit turns this contract into a detailed evaluation rubric. Three of its conditions exist to prevent substitution: authorized presentation, authorized correlation, and target-recognized authority.

Presenter binding establishes that evidence is usable only by an entitled presenter. A cnf claim or other sender constraint proves possession of a bound key; workload identity and runtime assurance establish who controls it and under what conditions. No one of those conclusions supplies the others.

Context correlation establishes that independently valid evidence belongs to the same decision context: a work instance where work continuity applies, otherwise a transaction, grant, or protected exchange. A carried identifier is never enough by itself. A fact’s authoritative source can commit its own assertion to a context when entitled to do so. Otherwise a scoped joining authority must validate the facts independently and apply an association policy before committing their relationship. A nonce can prove freshness of that act, not legitimacy of the association.

One realization commits a digest of an immutable approved definition into an issued artifact while retrieving mutable lifecycle state fresh. Another associates generic evidence at the receiving boundary after proving the same authenticated initiator, protected exchange, and absence of a conflicting prior binding. The profile must say which proof is sufficient; matching strings or timestamps are correlation hints, not authorization to join.

Authority to join must name the fact types, targets, association proof, lifetime, and revocation rules it covers. Without that scope, the joiner becomes the omniscient intermediary the model is meant to avoid. Join keys should also be pairwise or aliased across domains rather than becoming ecosystem-wide correlation handles.

Target-recognized authority completes the composition: permissions come from an issuer the target accepts under policy it governs, with audience and resource binding on what that issuer produces. A resource need not re-verify every upstream artifact; it may rely on a scoped attestation from a trusted decision point that performed the verification. It must not treat evidence for one question as evidence for another.

That reliance should be visible in the audit: the downstream resource records the attestation and decision it relied on rather than pretending it independently verified the original chain. This preserves the provenance of conclusions without forcing every enforcement point to implement every upstream protocol.

An unmet mandatory property is a terminal protocol error, never a downgrade to bearer semantics, a widened grant, or a substituted issuer. But “fail closed” is not an operations plan. Every live authority becomes an enforcement dependency, so profiles need risk-tiered staleness bounds, caching rules, and declared behavior when an authority is unreachable.

The same contract must minimize disclosure. Continuity is a requirement to carry enough evidence, not permission to copy every identity, actor, purpose, and policy claim through the path. Pairwise identifiers, audience restriction, selective disclosure, and short-lived composite evidence limit how a security join becomes an ecosystem-wide tracking join. Substitution and surveillance are both unauthorized joins of independently valid evidence, so the anti-substitution conditions above are also the anti-tracking conditions, and the continuity evidence itself is sensitive: delegation chains, actor mappings, and purpose records compose into a who-acts-for-whom graph.

A Cross-Domain Stress Test

The separations earn their keep when work leaves the administrative domain entirely. Suppose Alice’s agent needs a shipping quote from LogisticsCo. Acme can know Alice extremely well without becoming an authority for what happens there. LogisticsCo may trust Acme for Alice’s identity while deciding for itself what she, and the agent acting for her, may do with the quote API. Re-subjecting is a mint, not an attenuation: no caveat on Acme’s artifacts can create LogisticsCo’s authoritative facts.

Alice’s identity lands as LogisticsCo’s local subject, log-4a17; only identity, actor, presenter, and approved-work evidence cross, while LogisticsCo derives permission from local policy. Every issuer and namespace it accepts must be explicitly authorized, and whether an issuer is trusted for the namespace it asserts remains a target-local decision. The boundary contract can now be filled in:

Association and action remain separate conclusions: the joining authority may validly associate Alice, the agent, and mis-7c02, and LogisticsCo may still deny create_quote; the audit records both. Acme’s Mission crosses as evidence about approved work, not as target-local permission or target-local lifecycle state. LogisticsCo decides whether to recognize it and may create a Child Mission with a lifecycle of its own. Acme canceling the parent ends the child’s warrant for new discretionary actions when LogisticsCo next observes it; it cannot reverse completed actions or override local legal, settlement, or retention obligations. Anything stronger would rebuild the globally trusted object this post rejects.

The boundary just crossed is the far end of a spectrum the whole workflow has been walking:

Failure, Revocation, and Audit

Each unanswered question leaves a characteristic failure:

The authorization failure is why the Model Context Protocol security guidance says a server must not accept a token that was not issued to it: passthrough lets the intermediary inherit an upstream conclusion instead of forcing a target-recognized decision.

In August 2025, attackers stole OAuth tokens held by Salesloft’s Drift agent for customers’ Salesforce integrations and used them for bulk queries across hundreds of organizations. Read through the framework, the incident is selective. Request continuity was not implicated. Per-call human identity may legitimately have been absent, though stronger workload attribution would have helped. The immediate failures were presenter binding, since possession of a bearer token sufficed, and standing authority broad enough to support machine-speed bulk access.

Sender-constrained tokens under the OAuth Security BCP reduce replay value, provided the bound key is protected independently; DPoP proves possession of that key rather than authenticating the client by itself. A work check would have created a separate decision point for asking whether each bulk action still served approved work, but it would not guarantee denial: a Mission as broad as “support the customer integration” might still answer yes. The public account describes no live, bounded work-justification check. The incident therefore illustrates the fourth question without proving that a particular work-lifecycle mechanism would have prevented it.

The reflex after such an incident is a richer token, but a richer bearer token would have been stolen with the rest. Context can travel in artifacts; consequential decisions still have to live at boundaries.

Revocation exposes the same separation. Requests shaped as stop this work are often answered with the third question’s tools: find and invalidate every credential the work touched. Each fact ends with different reach and timing:

The reaches never add up to one switch. A self-contained token keeps verifying until expiry unless the boundary checks introspection or status. Token and grant revocation from RFC 7009 through OpenID’s Grant Management API remains issuer-local. Revocation also runs down a derivation axis no issuer’s table necessarily sees: canceling a parent says nothing to an offline-attenuated child, and a Token Status List does not automatically reach descendants. Work termination reaches only participating boundaries that consult work state. The framework therefore makes a deployment name which fact it intends to end and how observers learn that it ended.

Audit must preserve the same separation. At the decision boundary, record the request-provenance reference where relevant; subject and actor with issuer context; resource and action; authorization issuance or exchange; work identifier and lineage; evidence and policy versions; and the decision and outcome. An issuer-asserted act history, an actor-signed Actor Proof, and an issuer Actor Receipt establish different facts. Joined deliberately, these anchors let a reviewer ask who did what, on whose behalf, under which authority and approved work rather than infer purpose from token logs alone. Retention and privacy controls remain profile obligations.

What Current Work Covers, and What It Does Not

The four questions are not new; the separation is. Request continuity sits beside request provenance, broker chains, and consent integrity. Identity continuity includes principal propagation and on-behalf-of attribution. Authorization continuity covers token exchange, downscoping, audience restriction, and local authorization. Work continuity is adjacent to purpose limitation, workflow authorization, continuous authorization, and job lifecycle.

Seen through that separation, current proposals mostly occupy distinct roles rather than competing for one delegation slot:

The table identifies the role relevant to this argument, not the whole protocol. A proposal can answer more than one question, and a profile can compose several proposals, without either fact collapsing the questions.

Several proposals span more than one question without proving the questions equivalent. A Transaction Token carries short-lived context for one call chain; a Mission is independently governed lifecycle state spanning calls, grants, and potentially domains. Shared Signals can transport changes to that state without becoming the record itself. The Identity Continuation Assertion, Mission-Bound Authorization, Actor Profile, Actor Proofs, and presenter-transition sketches cited here include my own work; the taxonomy is fairly tested only against proposals I do not control. Draft status, a fuller mechanism map, and the evaluation rubric belong in the companion kit, where volatile tracking can remain dated.

What remains is a shorter architectural work list:

The Questions Differ. The Invariants Repeat.

Calling the four questions themselves a waist would claim too much. Request continuity is protocol-phase provenance, identity and authorization continuity are security semantics, and work continuity is lifecycle state consumed by policy. Approved work may exist before an OAuth request, while identity and authorization decisions recur at successive boundaries. They are non-substitutable decision questions, not a stack.

What repeats is the boundary contract rather than one artifact: every fact has an authoritative source; evidence is bound to its presenter, relying party, and intended context; association is made by a party entitled to make it; freshness, replay, and termination semantics are explicit; the target decides under its own policy; and missing, stale, unknown, or incomparable mandatory evidence follows declared failure behavior. What colocation once let systems assume silently, the contract makes them state explicitly.

Proposals keep rebuilding smaller pieces of that contract: who may become the next presenter, how a verifier proves authority did not expand, how subject and actor remain distinguishable, and when a trusted authority must decide again. A real narrow waist, if one emerges, will factor those validation rules so profiles reuse them instead of respecifying them. The decomposition is the map, not yet interoperability; profiles still need mandatory claims, validators, error semantics, and conformance tests.

Each question should resist becoming a container for the others. A request chain need not become a universal representation of identity. An identity assertion need not become an access token. An authorization artifact need not become the permanent record of why work exists. A Mission need not become a credential. The common discipline is:

Carry the minimum evidence necessary for the next boundary to establish the facts its decision requires.

What This Post Leaves Open

This framework takes admission and roots of trust as prerequisites: protected-resource discovery, identity without registration, issuer trust, and admission policy remain separate problems. Real workflows also have fan-out, retries, joins, multiple principals, approvers, and separation of duties; the subject-and-actor pair is deliberately too narrow for all of them. Finally, these controls govern whether an action may occur, not what happens to data afterward. Identity evidence buys attribution, not accountability, and exfiltration, output misuse, and prompt injection need their own controls.

From Ceremonies to Continuing Authority

Deployed OAuth practice has kept its center of gravity at the authorization ceremony and the token it issues. Agentic systems make the periods between ceremonies just as important: approvals become history, users leave, and credentials can detach from the work that justified them.

When delegated work crosses a boundary, the receiver must know which facts remain applicable, which authority can be narrowed, which facts require a new decision, who may correlate them, and which lifecycle state can still end the undertaking. The four questions become a diagnostic instrument: ask which one had no answerer at the boundary where damage occurred.

The practical unit of adoption is one coordination domain or class of boundary, not an entire delegation path: a profile needs agreement only among the authorities and verifiers at one class of boundary, while a universal artifact needs compatible semantics across much more of the path. The post’s bet is checkable: watch whether a universal artifact, translated at vendor gateways, reaches interoperable deployment across independent vendors before these narrower contracts do. The stronger path is profiles adopted one boundary at a time, letting evidence cross without silently broadening authority.

Carry evidence, not inherited conclusions: accept each fact only from an authority trusted for it, join facts only through a decision point authorized to join them, and decide locally what may continue. The goal is not one chain carrying everything. It is enough continuity at each boundary to decide safely.