Mission-Bound Authorization for OAuth 2.0

Mission-Bound Authorization for OAuth 2.0 Independent

public@karlmcguinness.com

Web Authorization Protocol oauth mission agent authorization rar par OAuth 2.0 has authorization grants and access tokens but no standard object that binds an approved task, such as one an AI agent performs on a user's behalf, to the authority approved for it and governs the tokens later issued under that authority. This document defines that object for OAuth 2.0: a Mission. A client submits, through Pushed Authorization Requests, a Mission Intent describing the task it will perform. The authorization server derives Rich Authorization Requests authorization details from it, binds the approved task and that authority to the Approver's consent through integrity anchors, and records a durable Mission. Every access token issued under the Mission carries a subset of the approved authority and a "mission" claim, and every issuance is gated on the Mission's lifecycle state. Revoking a Mission stops further issuance; it does not recall tokens already issued, which a resource server that enforces from the token alone can continue to honor until they expire. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. Runtime enforcement of each action is a separate, optional layer. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document defines a Mission: a durable authorization object that binds a disclosed task to an explicitly approved Authority Set and governs the lifecycle of the authority derived from that approval. Agent-identity work such as establishes how an AI agent authenticates and how a user delegates authority to it. It leaves out of scope how the agent's task is translated into authorization, how the user's approval of that task is captured, and how later token issuance stays bound to that approval. OAuth itself defines no task record that links approval of a task to the grants obtained for it: an authorization_details entry () expresses authority, but not the task it serves or a lifecycle of its own, so withdrawing approval of a task need not stop issuance under its grants. A Mission fills that gap. A client submits a Mission Intent describing the task, the authorization server (AS) derives the Authority Set the task needs, and an Approver consents to that Authority Set. The AS records the Mission and binds the resulting grant to it. It then issues tokens under the Mission only while the Mission is active, each bounded by the approved Authority Set, and resource servers enforce the resulting tokens. Revoking or expiring a Mission stops further issuance and refresh, but does not by itself invalidate an already-issued access token (). shows the protocol flow and an example. The sections follow this flow. and define what a client submits and what the AS derives from it; the approval, the record, and the grant binding; issuance on every path; , an optional capability, delegation within a Mission; enforcement and introspection; and the Mission's state and its termination. , , , and are reference sections; defines the conformance roles; and lists what a deployment decides and how each party learns it.

Applicability This document targets OAuth deployments where authority serves a durable, approved task that spans more than one token, request, or audience: an agent pursuing a multi-step objective on a user's behalf, or a workflow whose audit must join activity across hops on a shared task. This document is not intended for single-request user flows and short-lived authorizations where the credential's lifetime is the task's lifetime, ordinary machine-to-machine service credentials among them; those use OAuth unchanged. The boundary is that lifetime equality, not the absence of a human: a workload's durable multi-step task is in scope as a service-owned Mission (). Without its optional capabilities (), an implementation of this document needs nothing beyond its normative references and one AS-supported authorization_details type (). It turns an Approver's consent to a task's derived Authority Set into a Mission at approval and binds the Mission to the authorization code it issues (). Every token derived from that grant carries the Mission, every issuance is gated on its state and bounded by its Authority Set, every credential the Mission Issuer derives expires no later than the Mission, and the Mission Issuer accepts revocation by mission_id from a party its policy authorizes, independent of possession of any token (). Resource servers enforce the carried entries, or a scope projected from them (); a runtime layer that evaluates each consequential action against the Mission is out of scope (). The direct realization creates each Mission at an approval interaction on the authorization endpoint, and a Mission is intended to cover one concrete task, not an agent's whole lifetime. Other creation paths are extensions (); describes deployment patterns, including Mission sizing (Section "Mission Deployment Patterns").

Overview

Protocol Flow The following figure shows the protocol flow between the agent (the OAuth client) and the Mission Issuer (the AS); defines the Subject, the Approver, and the other terms: | derive authority |<----------- request_uri ------------| (authz_details) | | | 2. authorization request ---------->| Approver consents | | -> authority_hash |<-------------- code ----------------| -> Mission active | | (bound to the grant) | | | 3. token request ------------------>| gate: active? |<----------- access token -----------| + authz_details | | + mission claim v ]]>

Submit. The client pushes a Mission Intent describing the task, optionally with proposed authorization_details (). The AS derives the Authority Set, the concrete authority the task needs ().
Approve and commit. The Approver consents to that Authority Set itself, not to the task description alone (). The AS records the active Mission, commits the Intent as intent_hash and the approved Authority Set as authority_hash (), and binds the grant the approval produces to the Mission server-side. Any grant lineage bound to a Mission resolves to exactly that Mission, and no client input chooses it ().
Issue. At each token request the AS checks that the Mission is active and derives authority no broader than the approved Authority Set (, ). The access token carries the derived authorization details and a mission claim identifying the Mission (), and a resource server enforces statelessly from the token ().

Each later issuance from that grant lineage, such as a refresh, is a derivation under the same checks, and a token derived by Token Exchange carries the same mission claim (, ). Revoking or expiring the Mission stops further issuance and refresh, including from any grant lineage bound to it (). An already-issued access token can still be honored on a stateless enforcement path until it expires (). A user thus approves a task's authority once, and that approval bounds every token the agent derives. walks through these steps with concrete values.

Introductory Example In the examples in this document, each service's operation contract identifies the service's own identifier, such as https://erp.example.com, as the operation target (). Actions and constraints determine the permitted operations within that service. The following example shows a registered client reading invoices from one ERP resource for Alice, who is both the Subject and the Approver; the authority source is user-delegated. The AS and ERP support the mission_resource_access type defined by . The example uses a direct approval, a JWT access token, no delegated token, and no submission evidence (the AS's admission policy requires none). All times are UTC on the same day.

Submit. The client pushes a Mission Intent naming https://erp.example.com and requesting expiry at 13:00, with a proposed authorization_details entry of type mission_resource_access for that resource and the action invoices.read. It follows the PAR request_uri into the authorization interaction ().
Approve and commit. At 12:00 the AS authenticates Alice, verifies the authority source and proposed read authority, and renders that authority and the effective 13:00 expiry for her approval. On approval it atomically creates the active Mission, records its commitments, and binds the authorization code to it (, ).
Issue. Still at 12:00, the client redeems the code. The AS resolves and checks the Mission and returns a sender-constrained ERP token that expires at 12:05, with the read authority and a mission reference. The response also carries the granted authority (), mission_id, and mission_expires_at; the access token's five-minute lifetime is distinct from the Mission's one-hour lifetime ().
Use. The ERP is a Mission-aware Resource Server: it enforces the mission_resource_access entry itself, work a plain resource server does not do (). It validates the token and proof of possession and permits the authorized read; the token grants no write authority. The resource request involves no Mission-state lookup or complete-set retrieval ().
Stop further issuance. At 12:02 an authorized revocation makes the Mission non-active. A subsequent refresh, if the AS issued a refresh token, is refused with the invalid_grant error code (). The already-issued access token can still be honored on this stateless path until 12:05; revocation does not undo a completed read ().

An ERP that instead introspects on every request stops honoring the token on its next request after revocation, through the composite active result (). The later message examples use the end-to-end example's separate Q3 reconciliation Mission (), whose approved authority includes invoice reads and bounded journal writes. Its identifiers and timeline differ from this introductory example.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative. An example line too long for the page is folded with the single backslash strategy of .

Terminology

Agent (Client):: The OAuth client acting for the Mission's Subject, identified by client_id. Agent identity is established per or ordinary OAuth client authentication.
Subject:: The user, workload, or organizational principal on whose behalf the Mission is approved (), identified by an (iss, sub) pair and carried in derived tokens' sub claim.
Approver:: The single accountable principal who approves the Mission: at its direct approval event or, under a standing-consent basis, through the earlier standing consent (). Equal to the Subject for self-approval; different for administrator or delegated approval. Multi-party approval and the provenance of delegated approval authority are out of scope ().
Mission Issuer (authorization server):: The OAuth AS that validates a Mission Intent, runs the approval event, records the Mission, and derives tokens. It is the Mission's issuer; this document also calls it the "issuer AS" or the "AS".
Mission Client:: The client conformance role, defined in .
Mission-governed client:: A client that the deployment registers as Mission-governed ("a client registered as Mission-governed"); states the rule that registration triggers.
Mission-aware Resource Server:: The resource server conformance role, defined in .
Resource AS:: An authorization server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources; it is never the Mission Issuer.
Mission Intent:: The structured description of the task the client submits ().
Mission Intent Submission (Submission envelope):: The object a client submits as the mission_intent parameter value: the Mission Intent under intent, and Intent Submission Evidence under evidence where any is presented ().
Intent Submission Evidence:: Typed artifacts a client presents in support of claims about a submitted Mission Intent (): authenticated policy input, not authority. The term names only inbound, client-presented material, not the issuer- or runtime-produced evidence this document and companion profiles emit and record (a consent-evidence artifact, an audit evidence base).
Authority Proposal:: The authorization_details array a client submits alongside a Mission Intent, a proposal for Authority Set derivation and not authority ().
Authority Set:: The set of authorization_details entries the AS derives from a Mission Intent and the Approver approves ().
Authority Set derivation:: Computing the Authority Set from a Mission Intent and any authority proposal, in narrowing or configured-mapping mode ().
Derivation:: One issuance operation the issuer AS performs for a single request (): the initial authorization-code exchange, a refresh, a Token Exchange, or the redemption of a profile-defined grant. Distinct from Authority Set derivation, which some section titles and fixed phrases, such as "derivation policy", also call derivation.
Mission:: The durable authorization object that binds a disclosed task (its Mission Intent) to an explicitly approved Authority Set and governs the lifecycle of the authority derived from that approval. It is the record created at the approval event (), immutable except for its state and termination members, identified by a Mission Identifier () and, globally, by the pair (issuer, id). A Mission is independent of any OAuth grant (). "The approved task" is shorthand for this binding: the Approver approves the Authority Set, and the task is disclosed and committed beside it.
Mission grant binding (grant binding):: The AS-controlled, functional mapping from one persistent, redeemable grant lineage to exactly one Mission (). Distinct from a Derived token's own mission claim, which every Derived token carries without itself creating a grant binding.
Mission-referenced token:: A token that carries a Mission reference (for example, a mission_id or a descriptor a companion profile defines) without Mission-derived authority or any gating guarantee. An access token of this class does not carry the mission claim ().
Derived token (Mission-derived token):: An access token issued under a Mission, carrying its Mission-derived authority (the full Authority Set or a narrowed subset) as authorization_details and a mission claim ().
Mission-bound token:: A Mission-derived access token or refresh token whose issuance and refresh are gated on the Mission's active state and bounded by the subset rule (with refresh tokens bound server-side). Only this class carries the gating guarantee of this document; a token that only references or carries Mission data without the gates is not Mission-bound ().
Applicable entry:: An authorization_details entry that applies, under the entry's type, to a request to a resource server: where the type defines a resource, the request's operation target matches it under that type (). governs an entry whose type the resource server does not implement, or whose type-defined enforcement it cannot complete.
Delegate:: A sub-agent, service, or tool, itself an OAuth client authenticated as a distinct actor, that obtains a delegated token by Token Exchange ().
Delegating party:: The holder of a Mission-bound access token that obtains a designation for a delegate: the Mission's approved agent, or a delegate delegating further ().
Designation:: The delegating party's authorization, obtained by Token Exchange, for one delegate to obtain delegated tokens ().
Delegated exchange (delegated token):: The Token Exchange in which a delegate redeems a designation naming it for a delegated token, whose act claim names that delegate as the current actor ().
Self-exchange (no-actor exchange):: A Token Exchange with no actor in which an agent presents its own Mission-bound access token to obtain a narrowed one; it delegates nothing ().

Principal Model This document maps principals onto native OAuth constructs:

The Agent is the OAuth client, referenced by client_id; its identity and credentialing are out of scope ().
The Subject and Approver are each an (iss, sub) pair, matching the access token sub model of . The Approver is the accountable consent principal whose approval created the Mission, always equal to approval_basis.consent_principal. Under a standing-consent basis, the Approver remains the human whose consent roots the Mission ().

On a derived token, the iss claim is the AS and the sub claim is the AS-local sub to which the AS maps the Subject under the injective mapping of ; adopting the external sub verbatim is the common case. Within the issuing AS's namespace, this (iss, sub) pair is the AS-local subject principal, authoritative for the Subject, and resource servers authorize against it. The Mission separately records the Subject's home issuer and identifier as subject.iss and subject.sub: the external subject identity, carried as provenance for audit and not on the token. This document defines no runtime lookup of it. The record's (subject.iss, subject.sub) and the token's (AS iss, sub) identify the same Subject in two issuer namespaces. Issuer roles obey two invariants: a Mission has exactly one Mission Issuer, its issuer, and a Resource AS never creates or alters a Mission. Principals are recorded at the approval event and are immutable. Two principals are equal when their iss and sub are byte-equal, so the test compares principals only within one issuer namespace and never compares the external subject identity with the AS-local subject principal. Dynamic delegation (the actors an agent delegates to during execution) is carried on derived tokens in the act chain (), not on the Mission Record. This document uses only (iss, sub) pairs, not the subject identifier formats of .

Mission Intent A Mission Intent is a JSON object describing the task. The client submits it as the intent member of the Submission envelope (), in place of scope or alongside a narrowed scope. Before the approval event (), only the Mission Intent exists, as untrusted client input (); after it, only the Mission is authoritative. A Mission Intent therefore has no protocol identifier of its own: two submissions of the same Intent produce two distinct pending requests, and a Mission acquires its Mission Identifier () only at activation. The approved Intent carries no authority members. The task, the proposed authority, and the granted authority are committed separately ():

intent_hash commits the approved Intent, which is recorded on the Mission;
proposal_hash commits any authority proposal, which the client submits separately, on the standard authorization_details parameter (); and
authority_hash commits the granted authority, the derived Authority Set ().

The client writes every Intent member; how it produces them, for example through a Mission Shaper working from a natural-language instruction, is out of scope (). The prose members (goal, task_bounds) bound authority only through disclosure: the Approver refuses authority the words do not support (). An AS that makes no use of an optional member still accepts it and records it with the Intent (). The smallest Intent carries only the three required members, as in the Submission envelope example (). The following summary is informative; the member definitions after it are authoritative.

Intent Members Mission Intent members at a glance

Member	Required	What the AS does with it
`goal`	yes	Records it and renders it to the Approver as inert text; never interprets it
`goal_lang`	no	Checks the language tag and uses it when rendering
`target_resources`	yes	Bounds the resources a derived entry can name; can key a configured mapping
`task_bounds`	no	Records it and renders it to the Approver as inert text; never interprets it
`purpose`	no	Records it; can key a configured mapping; in any other decision can only lead to a refusal or stricter treatment
`expires_at`	yes	Caps the Mission's effective expiry; refuses a malformed or past value

The Mission Intent members are:

goal:

REQUIRED. A string. A human-readable statement of the task, for rendering to the Approver. Maximum 4096 characters.

It can describe the outcomes that show the task is complete; like the rest of the prose, that description carries no machine semantics ().
Prose here persists on the record and can carry personal data about third parties ().

goal_lang:

OPTIONAL. A string. A BCP 47 language tag declaring the language of the Intent's human-readable members (goal, task_bounds).

It is disclosure metadata for rendering, committed by intent_hash like every Intent member, and carries no machine semantics ().
At submission acceptance, the AS MUST refuse a goal_lang that is not a well-formed language tag with invalid_request ().

target_resources:

REQUIRED. An array of strings. A client-requested Intent ceiling on the task's target resources, each an absolute URI identifying a protected resource (an OAuth resource per -style indicators or a protected resource per ).

It bounds which resources a derived Authority Set entry may name () and serves as a configured-mapping lookup key (); like purpose, the key alone grants no authority.
It is not RFC 8707 resource carriage: a client separately requests the audience of a given token with the standard resource parameter ().

task_bounds:

OPTIONAL. An array of strings. Human-readable bounds on the task (for example, "read only invoices from 2026"). They are disclosure and audit context, rendered to the Approver beside the derived Authority Set (), and carry no machine semantics (); a machine-enforceable bound enters as structure instead.

purpose:

OPTIONAL. A string. A URI identifying the purpose of the task, recorded for disclosure and audit. Its semantics are deployment- or registry-defined and opaque to this document.

purpose is an opaque lookup key: a configured mapping can key on it to select candidate entries, which the Intent, policy, and the approval event bound as in any Authority Set derivation (); the key alone grants no authority.
In any other decision, purpose MAY contribute only to a refusal or to stricter treatment: its value, its absence, or a substituted value MUST NOT supply, widen, relax, or refresh authority, or replace a check that applies independently of it.
After approval, the purpose consulted is the approved Mission's, or a validated projection of it.

expires_at:

REQUIRED. A string. An RFC 3339 date-time: the client's requested not-after ceiling for the Mission's lifetime.

The submitted Intent is recorded verbatim.
The granted lifetime is the Mission Record's effective expires_at, which the AS establishes at Mission creation and which is no later than this value (, ).
At submission acceptance, the AS MUST refuse a malformed or already-past value with invalid_request.
Acceptance does not freeze time: Mission creation re-checks the effective expiry atomically at the commit ().
A request that resolves to an already-committed operation is recovery, not a new submission, and returns the stored outcome under the applicable idempotency rules even when the ceiling has since passed (, ).

The Approver's authentication strength for the approval event is requested with the standard acr_values and max_age authorization-request parameters, not on the Intent (). The Mission Intent's top level is closed to the members above and to those a companion profile the AS implements defines (, ). The following is an example of a Mission Intent:

Submitting a Mission Intent A client submits a Mission Intent, with any Intent Submission Evidence, in a Submission envelope () sent as mission_intent. On the authorization-code path, the envelope travels through a Pushed Authorization Request (); a companion profile can define another, back-channel carriage (). A Mission Intent, and any authority proposal submitted alongside it (), is untrusted client input; trust enters only when the AS validates it and the Approver consents to the rendered result. The AS derives and bounds authority by its own policy, whatever the client submitted ().

The Submission Envelope The Submission envelope is a JSON object with exactly these members:

intent:: REQUIRED. The Mission Intent object ().
evidence:: OPTIONAL. A non-empty array of Intent Submission Evidence entries (); the AS refuses an empty array with the invalid_request error code.

The intent_hash anchor commits exactly the intent object, not the Submission envelope or its evidence array (). The following rules govern a submission:

Structural validity. An AS that cannot parse mission_intent as a JSON object, or that parses it but finds the Submission envelope or the Intent structurally invalid against this document's member definitions, MUST refuse the request with the invalid_request error code.
Closed top levels. The AS MUST refuse a submission with the invalid_request error code if the Submission envelope contains a top-level member other than intent and evidence, or if the intent contains a top-level member that neither this document nor a companion profile the AS implements defines (). A bare Mission Intent submitted as the parameter value fails this rule, since its goal and sibling members are unknown envelope members.
Bounded size. The AS MUST bound the Submission envelope's total size, the Intent's total size and the lengths of its arrays, and the count and per-entry sizes of evidence entries, refusing a submission that exceeds the deployment-defined limits with invalid_request.

The following is an example of a Submission envelope carrying a compact Intent and one evidence entry of an illustrative, deployment-defined type:

Carriage Through PAR On the authorization-code path (), a client MUST submit a Mission Intent through a Pushed Authorization Request using the mission_intent request parameter. The parameter value is the UTF-8 JSON serialization of the Submission envelope, form-encoded in the application/x-www-form-urlencoded PAR request body like any other OAuth parameter. On the authorization-code path, the AS accepts the Intent in one of two forms:

the form-encoded mission_intent parameter of the PAR request body; or
a mission_intent claim inside a signed Request Object () that is itself pushed through PAR. The claim's value is the Submission envelope itself, a JSON object, not its serialization; the AS MUST refuse with invalid_request a claim whose value is a string or any other value that is not a JSON object.

When the pushed request carries a Request Object (a request parameter value), that object is authoritative: a mission_intent submitted outside the Request Object in the same push MUST be refused with invalid_request, strengthening , under which the AS would only ignore such a value. A client proposes concrete authority on the standard authorization_details parameter in the same push (). A client can also push scope and resource () values; the AS treats them as a requested subset of the authority the Mission Intent yields (). The AS returns a request_uri as usual, which the client uses to start authorization. Pushed parameters are authoritative: on the front-channel request that redeems the request_uri, the AS MUST ignore any mission_intent, authorization_details, scope, or resource presented. The AS MUST refuse with invalid_request a mission_intent presented on a front-channel authorization request that does not use a PAR-issued request_uri. A client MUST NOT send mission_intent as a plaintext front-channel authorization-request parameter, whether or not a Request Object is also present.

Other Carriages A Mission Intent travels on no other request unless a companion profile explicitly defines that request as a back-channel carriage of the Submission envelope. Support for a grant type or endpoint never establishes such a carriage on its own. A profile that defines such a carriage carries the envelope and any authority proposal in one request that never traverses a user agent, and preserves:

the envelope and proposal rules of ;
the processing order ();
Authority Set derivation ();
the approval-event rules for the Mission's approval basis (, , with a direct approval relocated only as permits); and
the grant binding ().

Authority Proposal A client MAY propose concrete authority for the task by submitting the standard authorization_details request parameter, a JSON array of authorization_details objects, alongside mission_intent in the same pushed request (). The carriage rules of apply to the proposal. The submitted authorization_details is a proposal, not authority (); the AS derives and bounds the Authority Set from it ().

Validating Proposed Entries The AS validates each submitted entry per . It refuses a request carrying an entry of a type it does not support (, ), or one that fails its type's documented definition, with the invalid_authorization_details error code. It never repairs a failure by omitting the entry. Where a machine-readable JSON Schema for the type is advertised () or established out of band, the entry MUST also validate against that schema, and the AS MUST refuse a request carrying an entry that fails it with the invalid_authorization_details error code. Each proposed entry that carries a resource member MUST have it among the Intent's target_resources, compared as states; the AS refuses a request violating this with the invalid_request error code.

Deriving From a Proposal When a proposal is present, the AS MUST derive each Authority Set entry as a subset () of some proposed entry of the same type: narrowed under that type's own subset rule where the AS has declared narrowing for the type, or carried through unchanged otherwise (). With a proposal present, goal and task_bounds serve as rendering and review context for the proposed authority. Policy narrowing is distinct from validation (). During Authority Set derivation the AS MAY omit a syntactically valid entry that policy cannot accept, or narrow it where the AS has declared narrowing for its type (, ). The granted authorization_details in the token response reflects every narrowing and omission (). The AS records the proposed array on the Mission exactly as submitted and commits it by proposal_hash (, ), separately from the task (intent_hash) and the approved Authority Set (authority_hash), so a narrowed approved Authority Set can be audited against the proposal that sought it. The following is an example of an authority proposal submitted alongside the example Intent of : Under a declared narrowing capability, Authority Set derivation narrows invoices.* to invoices.read. It keeps the proposed Q3 issuance window and write ceiling, which the Intent's task bounds support, and carries the proposed delegation policy through unchanged. The result is the example Authority Set of .

Mission-Governed Resources and Clients Submitting authorization_details without mission_intent is an ordinary request that this document does not govern. Two AS-side rules keep a governed task from being downgraded to such a request ( states the client-side rules and the threat):

Where a resource is Mission-governed, its AS MUST NOT issue a token for that resource outside a Mission, on any grant type.
If a client registered as Mission-governed sends an authorization request, through PAR or at the authorization endpoint, that carries authorization_details but no mission_intent, the AS MUST refuse the request with the invalid_request error code, so the client cannot drop the Intent from a request that still carries authorization_details.

A resource is Mission-governed (a Mission-governed resource) when the deployment classifies it so, or when protected resource metadata the AS has authenticated () declares mission_bound_authorization_required as true (). Metadata that omits the member or sets it to false does not clear a deployment's classification, and a less restrictive local classification does not override metadata that declares the requirement. This document defines no exception to the first rule; an exception requires a concrete scope that a separate specification defines, and none applies to a resource whose metadata declares the requirement. Under the first rule, a token is issued outside a Mission when the request has no qualifying Mission binding: no grant bound to a Mission (), or to a companion profile's equivalent binding, from which the issuance derives under . The rule applies to every audience the token would carry, including one the AS infers or applies by default when the request names no resource: the AS MUST refuse the request if any of them is Mission-governed, and MUST NOT issue the token for the others. The AS refuses a token request the first rule forbids with the invalid_target error code () once the request is otherwise processable. On a refresh, the AS MUST decide this refusal before it consumes or rotates the refresh token. Other failures keep their own errors:

authentication, syntax, and grant-validation failures keep their errors and precedence;
an invalid or expired grant keeps its error; and
a request under a grant bound to a Mission that is not active keeps the refusal of .

Until that request completes, including when the AS resumes it after an interaction, the second rule applies to a Mission-governed client's authorization request that carries authorization_details but no mission_intent. A request carrying neither authorization_details nor mission_intent is an ordinary request that the second rule does not reach; the first rule, for a Mission-governed resource, is what keeps that resource's tokens inside a Mission. A token request under an existing Mission-bound grant, such as a narrowing refresh or a self-exchange (), needs no mission_intent under the second rule. This exception opens no Mission submission carriage, and every other check still applies to the request:

Issuance Gating ();
the subset rule ();
the first rule above; and
the grant's binding to its Mission, client and sender.

Intent Submission Evidence The Submission envelope's evidence array carries Intent Submission Evidence: typed artifacts the client presents in support of claims about the submitted Intent, such as its originator, an admission or consent decision that applies to it, or the presenter authorized to submit it. Each entry is a JSON object whose type member names its evidence type. Processing is governed by the following rules:

Refuse, do not ignore. An entry that is not a JSON object, or that lacks type, is structurally invalid and refused with the invalid_request error code at step 1 of the processing order (). The AS MUST refuse an entry whose type it does not support, and an entry that fails its type's validation or verification, with the invalid_mission_intent_evidence error code (). A submission is accepted only when every presented entry verifies.
Policy input, not authority. A verified entry is not copied into the Authority Set and does not stand in for the approval event (), the sole activation of authority. Verified evidence can serve as authenticated input to admission and derivation policy; AS policy decides whether the verified claims are acceptable for this request.

Supporting an evidence type is optional, but these rules are not: an AS that supports none still applies them and refuses every presented entry (). The record's submission_evidence member () is provenance, not enforcement input, and is not carried on the mission claim (). Recorded facts, such as a verified consent reference, are provenance and policy input only; a resource domain validates them under its own current policy (). No integrity anchor commits submission_evidence: its digests are only as trustworthy as the Mission Record that holds them and do not independently prove which artifacts were presented at admission. A profile whose threat model requires that proof commits normalized provenance under its own anchor typ (, ). Mission Intent Submission Evidence for OAuth 2.0 () specifies the evidence framework, including required-evidence resolution and the binding of evidence to one Intent and its presenter.

Submission Processing Order The AS processes a submission in the following order. Steps 1 to 6 run when the submission arrives; step 7 can run provisionally then and is complete before the approval rendering (); step 8 belongs to the approval event, and step 9 to activation. states how JSON destined for commitment is parsed, including the rejection of duplicate member names.

Parse the Submission envelope, enforce both closed top levels and the size bounds (), and check that each evidence entry is a JSON object with a type member ().
Validate the intent object against the Mission Intent member definitions ().
Validate any authority proposal: refuse an entry of a type the AS does not support, or one that fails its type's definition or a schema advertised for it or established out of band, with invalid_authorization_details, and a proposed entry that carries a resource member whose value is not among the Intent's target_resources, with invalid_request ().
Compute the provisional intent_hash over the intent object ().
Apply any submission checks that configured admission policy or adopted profiles require before evidence verification, including when no evidence member is present. For example, the Submission Evidence companion resolves required evidence here and refuses a missing required type (, Section "Required Evidence Is Resolved Before Derivation").
Dispatch each presented entry on its type, and validate and verify it under that type's rules ().
Apply admission policy and derive the Authority Set independently (), including the target_resources membership of each entry that carries a resource member () and, where a proposal was submitted, that each derived entry is a same-type subset of a proposed entry ().
Render the Intent, the Authority Set, and the material verified provenance for approval; a change to any of them before the decision is re-rendered and approved over the changed context ().
At activation, record the approved intent, the Authority Set, and the verified evidence facts as submission_evidence ().

The AS MUST refuse a submission that fails more than one check with the error of the earliest failing step in this order. For example:

a malformed proposal together with a missing required evidence type is refused at step 3, with invalid_authorization_details;
a proposed entry outside target_resources together with a presented evidence entry that fails verification is refused at step 3, with invalid_request;
an intent object that fails validation together with a malformed proposal is refused at step 2, with invalid_request; and
a structurally invalid evidence entry together with a malformed proposal is refused at step 1, with invalid_request.

The material verified provenance of step 8 is part of the approval surface. Where a deployment commits the rendered approval surface, that commitment MUST cover the normalized provenance facts, at least as a digest of their canonical submission_evidence representation (). That commitment MAY omit each element's verified_at, which the AS generates at each verification, and no other member: type, artifact_hash, and facts, including any timestamp within facts, stay covered.

Mission Authority From the Mission Intent, and from the authority proposal where one was submitted (), the AS derives the Authority Set: one or more authorization_details entries of an AS-supported type ().

Derivation Modes Derivation is governed by local policy: different authorization servers can derive different Authority Sets from the same Mission Intent, and interoperability begins at the derived Authority Set and its integrity anchors (). Authority Set derivation is mechanical: one procedure whose candidate entries depend on whether an authority proposal was submitted:

Narrowing mode (preferred where the client can author authorization_details): the client submitted an authority proposal (), and the Authority Set is the proposal narrowed to policy. Each derived entry is a same-type subset of a proposed entry ().
Configured-mapping mode: no authority proposal was submitted, and a deployment-configured mapping, keyed on the Intent's purpose or target_resources, or on the requested scope values for a scope-only target (), yields the candidate entries, which are then narrowed to policy. The mapping is a lookup, not synthesis, and no key grants authority by itself. Because no authorization_details object was submitted, the AS refuses an Intent that matches no configured mapping, or whose mapped candidates policy narrows to nothing, with access_denied (). Its error_description can say whether no mapping matched or policy narrowed the candidates to nothing. Either mode is conforming. A deployment publishes its mapping space as deployment documentation. Eligibility can be scoped per Subject and client, and a mapping keyed on Subject attributes resolves at the approval event, where the Subject is established (), so a refusal at PAR time is best-effort over what is checkable without the Subject. Every Mission this mode yields takes its own fresh approval; activation under standing consent () is not this mode.

In either mode, narrowing a candidate entry needs a declared narrowing capability for its type; without one, the entry is retained unchanged or omitted (). Authority Set derivation can run provisionally during submission processing, where the inputs it needs are available (). The candidate Authority Set is complete before the approval rendering (), and a change that covers is recomputed and approved over the changed context. The approved Authority Set is fixed when the Mission Record is created, atomically with the approval decision (), under the derivation policy in force at the approval event. In both modes the AS bounds every Authority Set entry by the Mission Intent: each entry that carries a resource member MUST have it among the Intent's target_resources values, by exact string equality. This membership check applies to the Authority Set, and to a proposal at submission (). A later token issuance is bounded by the subset rule against the Authority Set (), not by the target list again. A type whose subset relation admits a narrower resource can yield a token entry that target_resources does not name, and a candidate outside every Authority Set entry fails that rule. Where recorded, the Mission's policy_version names the policy version in force (). Generative Authority Set derivation is not one of this document's modes. As a local-policy extension, a model's output can be a recorded input to the AS's deterministic derivation policy, together with the model's identifier and version. That input can cause refusal or further narrow the candidate authority the selected mode and policy otherwise permit. The AS MUST NOT let it supply or widen authority. Each type's subset rule (), the Intent bounds, and the prose boundary below still apply. A target_resources entry the deployment does not recognize is, by deployment policy, either omitted from the Authority Set or refused with the access_denied error code (). When an omission or a narrowing leaves the Authority Set short of what was proposed (), Authority Set derivation is partial. The token response states what was granted ().

Consented Authority Set The derived Authority Set, not the Mission Intent, is the authority the Approver consents to: the AS renders the Authority Set for approval and commits it as authority_hash (). The Intent's members describe and bound the task but grant no authority by themselves (): its structured members constrain what the AS can derive mechanically, its prose members bound through disclosure, and none widens. The goal and task_bounds members are human-readable disclosure and audit context. The AS MUST derive the same Authority Set, under the same policy, for two submissions that differ only in goal, goal_lang, or task_bounds, and MUST NOT gate issuance on those members, whether in Authority Set derivation, in an adjudicating policy, or through a model input to either; translating a user's words into structure is the shaper's job, before admission and outside the trust boundary (). A client-proposed constraint on an individual Authority Set entry enters through the authorization_details proposal: constraints a supported type's specification defines, and the collision-resistant deployment extensions the AS understands (). Authority is further bounded by:

the Intent's structured members (target_resources, expires_at);
the configured mapping, a lookup over structured values, not an interpretation of prose; and
local policy and eligibility.

The approval surface renders the prose beside the derived Authority Set () as the human check that the structure matches the words, not as a machine enforcement mechanism.

Authority Set Example The following is an example of an Authority Set. The read entry is delegable to depth 2 and bounded to a Q3 issuance window by the resource_issued_after and resource_issued_before Common Constraints (); the write entry carries no delegation and so is non-delegable, because delegation is per entry:

Subset Rule A derived authorization_details entry is a subset of a reference entry when it is no broader under the subset relation the entry's own type defines; states the general rule and each supported type defines its own relation. The AS MUST refuse to derive an entry that is not a subset, under its type's relation, of some Mission Authority Set entry. The AS MUST refuse a request that would widen authority under a Mission after the approval event on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation); broader authority requires a fresh approval event and a new Mission. The comparison is representational, not semantic. A candidate that compares as no broader can still permit effects the parent's purpose never contemplated; semantic narrowing is not a property this rule can provide. Where the comparison relation cannot decide (an unrecognized member, an incomparable value), the posture is conservative refusal, as each consuming rule of this document states. At the token endpoint, where the comparison cannot establish that a requested authorization_details entry is a subset, the AS MUST refuse the request with the invalid_authorization_details error code, as for an entry that exceeds the grant (). An entry equal to its reference entry, byte-identical under the canonical form of , is a subset of it for every type. This is the one case the subset rule decides without the type's own relation, and it is how an AS that has not declared narrowing for a type establishes a subset ().

Authorization Details Types The Authority Set MAY include any AS-supported authorization_details type an audience consumes; this document defines no type itself. "Supported" here means the AS recognizes and documents the type: it appears in authorization_details_types_supported or, where the AS advertises the schema endpoint, as a key in its authorization_details_types_metadata_endpoint response, which is then the source of truth for the supported set (). The Mission apparatus is type-agnostic toward every supported type:

an entry is committed by authority_hash and gated on Mission state the same way regardless of type;
narrowing and delegation use the subset and delegation semantics the type defines (, ), under the transformation capabilities the AS declares for the type (below); and
evaluating the entry against a concrete request is the responsibility of the resource server, under the entry's type (), or of a composing runtime layer (), not the AS's.

Declared Transformation Capabilities The subset rule is fully defined only for a type whose specification defines it. For every supported type, the AS declares three independent transformation capabilities; understanding one establishes none of the others:

narrowing: the AS understands the type's subset relation;
delegation: the AS understands the type's delegation semantics; and
projection: the AS establishes a safe scope projection for the type ().

The AS MUST NOT narrow, delegate, or project to scope an entry of a type for which it has not declared the corresponding capability; on an undeclared capability the entry is carried as approved. The narrowing capability also governs Authority Set derivation, and approval does not waive the subset proof. Without narrowing for its type, the AS retains a valid candidate entry, whether proposed () or yielded by a configured mapping (), unchanged, or omits it where this document permits omission; it never modifies the entry under a claimed subset relation. A malformed entry is refused as states. The following rules govern an entry's original approved audience:

The AS relates each entry to the audiences that consume it through a trusted entry-to-audience mapping, such as authenticated configuration or protected resource metadata (). An entry's original approved audience is the audience or audiences that mapping assigned the entry when the Mission was approved. An entry's resource value is not by itself an audience ().
The AS MUST retain that association with the Mission; a later change to the mapping does not redefine it.
A Mission created from earlier authority, such as one created from an existing Mission's authority () or under a standing consent (), does not reassign the original approved audience of an entry it inherits: the entry keeps that of the authority it derives from. Only a fresh approval of the entry, or a transformation under a declared capability, establishes a different one.
Where the AS cannot establish an entry's original approved audience, the entry has none; the current mapping MUST NOT stand in for it.

Issuing an entry to an audience other than its original approved audience, including audience projection to a Resource AS (), counts as narrowing and needs narrowing, not projection. Without narrowing, the AS MUST NOT issue an entry to any audience other than its original approved audience, or, except as scope under a declared projection, in any form other than exactly as approved, since it cannot prove that a transformed copy is still a subset of what was approved. and state how these rules apply to a delegated token and to a designation. The AS declares the capabilities through these carriers, in order of preference:

a mission_transformation_capabilities member in the type's entry in the authorization_details_types_metadata_endpoint response, where the AS advertises that endpoint ();
an equivalently shaped member of its supported-type documentation; or
deployment documentation naming the type as supported ().

Deployment documentation is always a sufficient carrier; a machine-readable carrier is optional, and the first declaring carrier governs. A mission_transformation_capabilities value is a JSON object with three OPTIONAL boolean members, narrowing, delegation, and projection; an absent member leaves that capability undeclared by this carrier, falling through to the next carrier in the order above. A type's specification MAY define another value for one of these members; a carrier declaring such a value declares that capability as the type's specification defines it, and a reader that does not understand the value, or cannot validate it as that specification requires, treats the carrier as declaring the capability false. For each capability, the first carrier in that order that declares the member governs, whether it declares true or false; a later carrier does not override it. A declared capability permits a transformation without requiring it, and waives no check this document requires and no local policy under which the AS refuses one.

Mission Creation Approval creates a Mission. This section defines the direct creation path: the approval event and its steps (), the record the AS keeps (), the commitments to its approved content (), and how the grant the AS issues is bound to the Mission (). A companion profile can modify that path. A standing-consent basis activates Mission instances under an accountable human's earlier approval (), and a profile can relocate the approval event or carry the submission over a back channel (). An AS that implements such a profile also meets the sections that profile relies on.

Mission Approval An approval event is the atomic transition that creates a Mission. Every Mission is created at its own approval event, which the record's approval_event_id identifies. The approval basis (approval_basis, ) and its adjudication, not the event alone, determine whether a human decides at that event or an earlier standing consent authorizes the instance:

A direct approval event includes the Approver's contemporaneous consent: it is a human approval event.
Under a standing-consent basis (), the instance is decided under an accountable human's earlier approval, with no fresh human approval.

Direct Approval Steps At a direct approval event the AS MUST perform steps 1 to 7, in order, as one procedure: steps 1 to 5 prepare the approval (), and steps 6 and 7, which continue the same procedure, commit the Mission (). The steps of this section define the direct approval basis (approval_basis, ); a companion profile that relocates a direct approval keeps them unchanged (). states the rule that keeps consent reuse, for an authorization request that carries no mission_intent, from selecting a grant bound to a Mission. Refusals follow .

Preparing the Approval

Authenticate the Approver, subject to the approval-authentication floor and any client-requested strength ().
Establish the Subject: the principal the task is for, recorded as the Mission's subject and mapped to the sub of every derived token (), under the rules of .
Establish the authority source: whose authority the approval draws on, recorded as the Mission's authority_source (), and check the Approver and the derived Authority Set against it, under the rules of .
Establish the effective Mission expiry: the requested intent.expires_at ceiling narrowed by applicable AS policy and any ceiling an applicable Mission-creating profile defines. The value is bounded as expires_at requires () and is rechecked at the creation commit (step 7). Shortening under applicable AS policy, or under an already-approved parent, predecessor, or standing-consent bound a Mission-creating profile defines, is ordinary narrowing of the granted lifetime, not Authority Set derivation; for direct creation under this document the only additional ceiling is applicable AS policy.
Render for consent the derived Authority Set in human-meaningful terms, with the goal, task_bounds, and the effective expires_at (and, when it differs, the requested intent.expires_at, so the Approver sees the narrowing) as context, under the rules of .

Committing the Mission The same procedure continues from step 5:

Compute the integrity anchors (): authority_hash over the consented Authority Set, intent_hash over the approved Mission Intent, and, when an authority proposal was submitted (), proposal_hash over the submitted authorization_details array. The AS computes them here whether or not the record carries them; an artifact bound at the approval event that carries one of these anchors carries the value computed here.
Create the Mission Record () in the active state atomically with the approval decision and issuance of the authorization code, or, under a back-channel carriage profile (), with establishment of the Mission grant binding and activation of the profile-defined grant for redemption. The commit MUST verify atomically that the effective expiry is strictly later than the creation instant: acceptance of the submission does not freeze time, and where the requested ceiling passed while the approval was pending, completion creates no Mission. Where a direct approval fails this check, the AS MUST refuse the request with access_denied (), issuing no authorization code or profile-defined grant. A deferred or relocated approval flow () inherits this check at its own creation commit, with the completion error each flow defines.

The authority_hash is the authority commitment: it commits, by cryptographic digest, exactly the authority the Approver approved. states how the AS deduplicates a retried or duplicate delivery of the same approval decision on approval_event_id.

Approver Authentication Strength Step 1 of the direct approval steps () authenticates the Approver. The AS MUST NOT take the Approver's identity or achieved authentication context from unauthenticated client input; the authenticated surface that resolved the approval establishes both. A deployment MUST publish a statement declaring the minimum approval-authentication strength (the approval-authentication floor) it enforces for Missions whose derived Authority Set carries high-risk authority, and the deployment scope it applies to. This document requires no particular serialization. High-risk authority means irreversible, external-commitment, or privileged-administration actions under the deployment's classification, or a cumulative consumption bound (). The authentication actually achieved for the approval event (acr, amr, and auth_time, in the sense and define them) is approval-time provenance, not requested Intent. This document never records it as a Mission Intent member, and an AS MUST NOT read it back from a Mission Intent member. This document defines no Mission Record member for the achieved values.

Requested Strength For the direct flow, a client MAY additionally request an approval-authentication strength on the authorization request using the acr_values and max_age parameters defined in Section 3.1.2.1 of . In a Mission approval interaction, these parameters describe the requested authentication of the Approver, not of the token's Subject, who can be a different principal (). Requesting them implies nothing about the authentication claims of an issued token: those claims describe the token's Subject, not the Approver (). When the Approver is the Subject, one authentication event can back both. The Approver's authentication satisfies acr_values when it matches any one listed value under the deployment's own policy mapping. This document defines no global ordering of acr values. The max_age parameter bounds the elapsed time since that authentication. Approval authentication for a high-risk Mission MUST satisfy both the published floor and, where the client requested one, the acr_values/max_age carriage above; the floor is never relaxed by a narrower or absent client request.

OpenID Connect Requests This document does not require an AS to support OpenID Connect . An authorization request whose scope includes openid asks for an ID Token about the End-User the approval interaction authenticates, who is the Approver. When the Approver is not the Subject established at step 2 of , the AS MUST refuse such a request, without creating the Mission, with the invalid_scope error code (). When the Approver is not the Subject, whether or not openid was requested, the AS MUST NOT issue an ID Token, serve UserInfo, or establish an authentication session for the Subject solely as a result of the Approver's authentication or approval. When the Approver is the Subject, the openid scope value and the acr_values and max_age parameters keep their meaning, which then describes the same authentication this document requires. In every approval interaction, the prompt, login_hint, and id_token_hint parameters concern the Approver.

Subject Establishment These rules apply at step 2 of the direct approval steps (). The Subject can be a workload or organizational principal, established and mapped the same way; which principal a service-owned or organizational Mission records as its Subject is stated for every Mission in .

Self-approval. When the Approver is the Subject, the Subject is the authenticated Approver.
Approval for another principal. When the Approver is a different principal (for example, an administrator approving on a user's behalf), the AS MUST NOT take the Subject from unauthenticated client input, and MUST authorize the Approver to approve for that Subject under local policy. This document defines no wire parameter for the Subject; how the AS establishes it (administrative selection, a directory, an authenticated reference) is a deployment matter.
External Subject. When the Subject's home issuer (subject.iss) differs from the AS, the AS MUST map the external (subject.iss, subject.sub) pair to an AS-local sub under an injective mapping (no two distinct external Subjects map to the same local sub). A derived token's (iss, sub) pair then denotes exactly one Subject. Adopting the external sub verbatim is valid only where it collides with no other principal's sub.

Authority Sources A Mission draws its authority from one of three sources:

user-delegated: a delegating person's own authority;
service-owned: a workload's own provisioned authority; or
organizational: explicitly governed organizational policy with a named accountable owner.

The source names whose authority the approval draws on, recorded immutably as the Mission's authority_source; approval_basis records how drawing on it was activated (). The two compose: any source may activate under the direct basis or a standing-consent basis a companion defines. Approval activates only authority the source already holds: the AS establishes the source and verifies the derived Authority Set against it before approval (, ). At step 3 of the direct approval steps, the AS establishes the authority source. The AS MUST establish it from trusted configuration or authenticated governance state, never from client assertion. The AS then makes two checks:

The AS MUST verify the Approver is authorized under local policy to activate the established source.
The AS MUST verify the derived Authority Set lies within that source's authority (for organizational, within the governed policy identified by authority_source.policy).

These are distinct checks: an organizational owner may be authorized to activate policy without personally holding every operational permission. The AS MUST refuse when either relationship cannot be established. An AS MUST NOT approve a Mission whose authority source it does not recognize. An organizational Mission's authority_source.policy reference () commits to the governed policy through its digest:

digest is a prefixed commitment () whose exact committed input and construction the policy's format specifies: its species and, for an envelope anchor, its typ, iss, and value.
The party that produces the reference computes digest; a consumer holding the policy can reproduce it, and one that does not compares it as an opaque value.

The subject-representation discipline is the same in every source:

The accountable principal is the record's approval_basis.consent_principal in every source; it MUST NOT be inferred from the token sub.
sub carries a delegating person only in the user-delegated source. A service-owned or organizational Mission MUST record the workload or organizational principal as subject and MUST NOT record a human principal in its place. The injective mapping of applies unchanged: that principal receives its own AS-local sub, denotes itself, and impersonates nobody. It MUST be an authorization subject the AS recognizes as a resource owner in its own right (the sub model of ), not only the task's beneficiary.
The actor model does not vary by source: the Mission Record's client_id names the Agent, a token's client_id names the client that requested it (), and delegates are carried in the act chain ().

Consent Rendering These rules apply at step 5 of the direct approval steps (). The consent object is the derived Authority Set: what the agent may do. It is not the goal or Mission Intent, because Authority Set derivation is local policy and nothing commits that the derived authority reflects the goal the Approver read. An approval surface that renders only the goal or Mission Intent does not conform. These requirements apply to the rendering:

The rendering MUST identify the OAuth client that receives the authority, the Agent, from client identity information the AS trusts, such as its own registration of the client; display text the client supplies does not by itself identify it.
When the Approver is not the Subject, the rendering MUST identify the Subject the authority is granted for.
The rendering MUST identify the authority source and, for organizational, the governed policy it draws on (authority_source.policy).
When the client submitted an authority proposal (), the rendering MUST distinguish the entries the client proposed from any narrowing or restructuring the AS applied.

The consent rendering is hardened against client text:

Client-supplied strings (goal, task_bounds) MUST be rendered as inert text and MUST NOT be interpreted as markup.
The AS SHOULD mitigate Unicode direction-override and confusable-character presentation in them.
The rendering MUST visually distinguish the AS-derived Authority Set from client-supplied text and attribute that text to the client, identified from client identity information the AS trusts (above), so crafted client text cannot pass as derived authority or as a statement of the AS.

The rendering presents goal and task_bounds as recorded, without truncation: the Intent is recorded verbatim and committed by intent_hash (), so a truncated rendering would show the Approver less than the record holds. Rendering a bound is not the same as enforcing it: a deployment MUST NOT present a rendered bound as enforced when no party enforces it. Which party enforces each bound, and what holds when that party is absent, follows from Enforcement Requirements () and, for a resource server that enforces only scope, from Scope Projection (). An AS SHOULD make clear to the Approver which rendered bounds its deployment actually enforces, so consent is not given to a limit that binds nowhere.

Changes Before the Decision If any of the following changes between approval rendering and the approval decision, the AS MUST recompute the affected values and the integrity anchors, and MUST NOT create the Mission without the Approver's consent to the changed context:

the task or the authority proposal;
the derived Authority Set;
the established authority source ();
the effective expires_at; or
a policy input establishing any of them.

Each anchor (intent_hash, authority_hash, and proposal_hash where a proposal was submitted) is computed over the approved context. Because the proposal is committed separately, a proposal swapped between rendering and decision changes proposal_hash even where intent_hash is unchanged.

Authorization Code Protection The direct realization runs as an OAuth 2.0 authorization-code flow initiated from the PAR-issued request_uri (). Because the authorization code is the artifact the Mission grant binds to () and it passes through the front channel, the AS MUST bind the code to the requesting client with PKCE (, S256 challenge method) or, equivalently, issue a DPoP-bound authorization code (). Redemption is then verified as or specifies. This prevents authorization-code injection from yielding the Mission grant. Issuance at the code's redemption applies the issuance procedure of as it states for code redemption. The AS SHOULD include the iss authorization-response parameter () on the authorization response, so the client can detect a mix-up attack on the consent-bearing redirect leg ().

Single Accountable Approver This document records exactly one accountable principal, approval_basis.consent_principal: the principal who approved the Mission. Two richer patterns are out of scope:

Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers does not change the authority commitment: principals approving the same rendered Authority Set produce the same authority_hash and the same derived tokens. A deployment requiring dual control records one accountable Approver; this document does not represent the co-approvers.
Approval-authority provenance: the standing behind a delegate's authority to approve for another principal (for example, whether an administrator was entitled to approve on a user's behalf). This is governance state about the delegate, not the standing-consent basis that approval_basis records ().

Mission Record A Mission is the durable record created at the approval event; a Mission Identifier () identifies it. Its members MUST NOT be changed after creation, except state and the termination member written once when the Mission terminates (). The record is a logical object: this document constrains its members and their values and requires no storage form. Where a surface or profile exchanges or signs the record, the record's JSON form, with the members this section defines, governs. Record member names omit the mission prefix, which marks surfaces that reference a Mission from outside it, such as the mission_id response parameter. They are spelled out (issuer, expires_at, created_at) and spelled identically on every surface; the compact JWT names (iss, exp, iat) belong to a signed artifact's own envelope or to an {iss, sub} party object, not the Mission. Like the mission claim (), the record is open (): a companion profile of this document MAY record additional members set at creation using short names coordinated with it (for example, a lineage member linking the Mission to a predecessor or parent); any other extension MUST use collision-resistant names. A consumer does not interpret a member it does not recognize, and does not remove it from a record it retains or commits. The following subsections define the record's members. The record's required members are its invariants: id, issuer, state, intent, authority_set, subject, approval_basis and authority_source with the members each requires, client_id, approval_event_id, created_at, and expires_at, and, under the condition each states, termination, proposed_authority, submission_evidence, and policy_version. The integrity anchors intent_hash, authority_hash, and proposal_hash are implied members (). Every other member is optional or defined by the profile that uses it.

Identity and Lifecycle Members

id:: REQUIRED. A string. The canonical Mission Identifier ().
issuer:: REQUIRED. A string. The issuer URL of the Mission Issuer that approved the Mission. Equals the iss of tokens that AS derives ().
state:: REQUIRED. A string. The current lifecycle state: active or terminated in this document, or an additional state defined by a companion profile, subject to the forward-compatibility rule of .
termination:: CONDITIONAL. An object, present exactly when state is terminated: the reason and instant the Mission terminated ().

Approved Content and Commitments

intent:

REQUIRED. An object. The approved Mission Intent.

proposed_authority:

REQUIRED when the client submitted an authority proposal (), absent otherwise. An array: the submitted authorization_details array, recorded exactly as submitted. A Mission derived in configured-mapping mode () records none.

authority_set:

REQUIRED. An array. The consented Authority Set.

authority_hash:

OPTIONAL. A string. The authority commitment over the Authority Set (); its implied value is that anchor over the record's authority_set. It is not carried on the baseline mission claim ().

intent_hash:

OPTIONAL. A string. The integrity commitment over the approved Mission Intent (); its implied value is that anchor over the record's intent.

proposal_hash:

OPTIONAL when proposed_authority is present, absent otherwise. A string. The integrity commitment over the recorded proposed_authority (); its implied value is that anchor over the record's proposed_authority. It is approval-time provenance, not enforcement input, and is not carried on the mission claim ().

submission_evidence:

REQUIRED when the approved submission carried evidence, absent otherwise. An array. The verified Intent Submission Evidence facts (), one element per verified entry, in the submission's evidence order so the array has one canonical form (). Each element carries exactly these members:

type:: The entry's evidence type.
artifact_hash:: An integrity anchor () with typ mission-intent-evidence over the entry exactly as presented.
verified_at:: An RFC 3339 timestamp of verification.
facts:: An object holding the verified output facts the type's specification selects for recording, nested so type-owned facts cannot collide with the common members.

The three anchors are implied members, as the direct approval basis's members are (): an omitted anchor has its implied value, a reader does not insert it into a record before hashing or committing the record, and an issuer does not remove an anchor a record carries. A recorded anchor MUST equal its implied value. A party that finds one that differs MUST refuse the operation that relies on it and MUST NOT substitute the implied value.

Principals and Approval Basis

subject:

REQUIRED. An object. The Subject, an object with iss and sub.

approval_basis:

REQUIRED. An object. The approved authorization basis this Mission is rooted in, fixed at the approval event and immutable thereafter, like subject. This document defines the direct basis in full; a companion profile can define a standing-consent basis (). The members below apply to every approval basis, with the presence each one states. Three of these members answer the questions an approval raises: who consented (consent_principal), who triggered this instance (activation_actor), and what mechanism decided it (adjudication).

type:: REQUIRED. A string: direct, or a standing-consent value that a companion profile defines ().
consent_principal:: REQUIRED. An object with iss and sub. The accountable human (or human-accountable principal) who consented. MAY equal subject.
activation:: OPTIONAL for direct. What activated this Mission instance; its implied value for direct is an object whose approval_event_id is the record's own approval_event_id (below).
activation_actor:: OPTIONAL for direct. Who or what triggered this instance; its implied value for direct is consent_principal: the Approver triggers their own approval.
root_commitment:: OPTIONAL for direct. The commitment to the consented root; its implied value for direct is this Mission's own authority_hash, recorded or implied.

When present for direct, activation, activation_actor, and root_commitment MUST each match its implied value. The implied values are semantic defaults: an omitted member has its implied value, and a reader does not insert it into a record before hashing or committing the record. For a standing-consent basis, the activating issuer records all three (): activation is an object in the shape the basis's defining profile specifies, activation_actor is an object with iss and sub, and root_commitment is a string that identifies the exact consented root.

adjudication:

OPTIONAL. A discriminated object naming the decision mechanism that adjudicated this instance: distinct from activation_actor (who triggered it) and consent_principal (who is accountable for it). Present when a Mission-creating profile or deployment chooses to make the mechanism explicit; where absent, the mechanism is still fixed by type and the construction rules of this document or a companion profile (below). Members, where present:

kind:: REQUIRED. A string: human or policy, naming a decision mechanism, not a storage location for supporting evidence; a companion profile MUST NOT define a kind value that names a record, an evidence store, or the requesting or dispatching party.

A companion profile can define further members of adjudication; Approval Governance defines governance_record (). For kind: human: no additional kind-specific members; the deciding human is consent_principal. For kind: policy: the kind-specific members that the profile defining the standing-consent basis specifies.

approved_at:

Absent for direct, whose approval event carries its own instant (). For a standing-consent basis, the activating issuer records it (): an RFC 3339 date-time, the instant the accountable human approved the exact consented root that root_commitment identifies, not the instant this instance was activated.

The following rules apply to approval_basis:

Where adjudication is present for direct, kind MUST be human, with or without governance_record: a policy decides an instance only under a standing-consent basis ().
For direct, activation.approval_event_id MUST identify a human approval event ().
approval_basis is provenance: none of the record's integrity anchors, such as intent_hash, authority_hash or proposal_hash, covers it (); a profile that commits the Mission Record itself covers it under that profile's own anchor.
Its disclosure through introspection follows .
It is not carried on the baseline mission claim (), and it MUST NOT be relied on to grant or widen authority wherever it does appear.

authority_source:

REQUIRED. An object. The source of the authority the approval draws on (), established at the approval event () and immutable thereafter, like approval_basis. Members:

type:: REQUIRED. A string: user_delegated, service_owned, or organizational.
policy:: REQUIRED for organizational, absent otherwise. An object with id, version, and digest: the stable reference to, and commitment over, the governed organizational policy the Mission draws on.

The authority_source member is provenance like approval_basis: recorded alongside it, folded into neither intent_hash nor authority_hash, and not carried on access tokens; resource servers enforce authorization_details and do not consult it.

client_id:

REQUIRED. A string. The Agent (OAuth client) that submitted the Mission Intent.

An unrecognized approval_basis.type, adjudication.kind, or authority_source.type value is preserved unchanged as opaque provenance on an otherwise valid record: a consumer MUST NOT infer or fabricate the human, policy, or Approval Governance Record standing behind it, and MUST refuse only a profile operation that itself requires recognized adjudication semantics to proceed (for example, evaluating a policy-approval recency ceiling); for authority_source.type, the operation refused is any operation, of this document or a profile, that itself requires recognized source semantics (for example, applying the source's authority ceiling or its governed policy). Unlike an unrecognized lifecycle state (), such a value does not by itself invalidate or deactivate the Mission.

Provenance and Expiry

policy_version:: OPTIONAL. A string. An opaque audit correlator naming the derivation policy version in effect at the approval event; the policy itself does not travel. It is REQUIRED where a feature or profile the deployment uses depends on versioned derivation-policy identification. A deployment using such a feature records it from creation and never supplies a replacement value later.
approval_event_id:: REQUIRED. A string. A unique identifier of the approval event, used as the approval idempotency key: one approval event creates at most one Mission (). The identifier names the approval event that creates this Mission (); under a standing-consent basis (), it identifies this instance's creation, not the earlier standing approval.
created_at:: REQUIRED. A string. RFC 3339 timestamp of creation: the instant of the atomic creation commit ().
expires_at:: REQUIRED. A string. An RFC 3339 date-time: the AS-established effective Mission expiry (, ). It MUST be later than created_at and MUST NOT be later than intent.expires_at, the requested ceiling ().

Mission Identifier Format A Mission Identifier is an opaque URL-safe ASCII string of [A-Za-z0-9_-] characters, with at least 128 bits of entropy, carrying no semantic content. The AS MUST NOT reuse a Mission Identifier. The record and the mission claim carry it as id; a surface that references a Mission from outside carries it as mission_id, as in the token-response parameter ().

Mission Record Example The following is an example of a Mission Record: The following example shows an excerpt, other members omitted, of a Mission for an agent acting for its own workload principal: subject is the workload principal, client_id is the agent, and consent_principal is the administrator who approved it under the service_owned source. The first example's anchors are computed over its displayed intent, proposed_authority and authority_set (); the excerpt's root_commitment is illustrative. A companion that extends this example either reproduces the recorded objects byte-exactly or states that its example diverges and its anchors differ.

Integrity and Commitments This section defines how the anchors the Approver consents to at the approval event () are constructed, canonicalized, and bound. The Mission Record () records them, and the test vectors () pin the construction byte-for-byte. classifies these anchors and states the contract for commitments other specifications define.

Integrity Anchors Every anchor is computed the same way over a domain-separated, issuer-bound envelope:

Construct the envelope, where typ selects the committed object and value is that object: ", "iss": "", "value": } ]]> Each anchor sets typ and value as follows:
- For intent_hash, typ is mission-intent and value is the approved Mission Intent object: the Submission envelope's intent member, not the envelope or its evidence ().
- For proposal_hash, typ is mission-proposed-authority and value is the submitted authorization_details array exactly as recorded (); the anchor is defined exactly when a proposal was submitted.
- For authority_hash, typ is mission-authority-set and value is the Authority Set as a JSON array of entries.
Canonicalize the envelope with JCS .
Compute SHA-256 over the canonical bytes.
Encode as sha-256: followed by the base64url, no-padding encoding of the digest.

The typ field domain-separates the anchors so a digest of one object cannot be mistaken for another's. The iss binding prevents a committed object from being transplanted across authorization servers. The sha-256: prefix is the algorithm-agility mechanism (). An implied anchor () is this section's sha-256 construction over the retained record: the record's intent, authority_set, or proposed_authority, each array in its recorded order, with iss the record's issuer, whatever algorithm the issuer uses for new commitments. Once a Mission exists, an issuer that emits or verifies its intent_hash, authority_hash, or proposal_hash MUST resolve the anchor, recorded or implied, from the Mission's retained record, never from a token's carried subset, a projection or response it serves, or authority a companion narrows after approval. This governs only those anchors of an existing Mission: a computation before the Mission exists, such as the provisional intent_hash () or step 6 (), and a commitment whose inputs a companion defines keep their own inputs. The anchors this section lists, and the Authority Set entry commitment (), bind the AS issuer. The digest of an authority_source.policy reference () is not one of them: it uses the issuer the policy's format defines, for a governed organizational policy its governing authority. That binding keeps the policy's commitment from being transplanted across policy authorities, and the same policy commits identically at every AS that records it. The intent_hash and authority_hash anchors are independent commitments to independent objects. That the approved task bounds the derived authority is a governance assertion, made by derivation policy and auditable through policy_version where the Mission records it (), not a cryptographic relation between the anchors: neither anchor proves anything about the other's object. The typ value space is an extension point (): additional committed objects use this same envelope with a new typ and the canonicalization below. The authority_hash anchor commits an Authority Set, not a Mission: two Missions that approve byte-identical authority share it, and a consumer MUST NOT use it as a Mission Identifier or as a replay or idempotency key for a Mission.

Canonicalization Rules JCS alone does not make two implementations agree on every byte. The following rules close the remaining gaps; they apply to computing an anchor and to comparing committed values:

The committed value is exactly the object the AS recorded on the Mission: the approved intent for intent_hash, the recorded proposed_authority for proposal_hash, and the authority_set for authority_hash. An auditor reproduces a digest from the record alone.
Duplicate member names are rejected at parse time ().
JCS does not reorder array elements, and this document defines no element sorting, so array order is significant. The AS MUST present each committed array in its recorded order wherever it emits the committed object; that order is part of the canonical form.
URI-valued members are compared byte-for-byte, with no normalization (), unless a member's own type definition specifies a normalization. Where a type defines one, it applies only to the comparison the type defines it for: the default resource equality test remains an exact match, and anchor computation is always byte-exact over the recorded values.

Digest Input and Algorithm Every committed JSON value and its envelope are I-JSON data, as requires. Strengthening , which adapts input to I-JSON, the party computing or verifying a commitment MUST reject non-conformant input before canonicalization rather than adapt it: externally received JSON destined for commitment is parsed by a duplicate-detecting parser, and an object carrying duplicate member names is rejected at parse time, before the parsed data model exists. The commitment is over the parsed I-JSON data value, not the source text: JCS does not preserve a source lexeme's spelling or excess precision. A profile whose values need exact decimal or large-integer semantics carries them as strings, as recommends, or defines a stricter numeric domain. The security considerations of apply to every JCS computation. The algorithm prefix is the agility mechanism. The sha-256 algorithm is mandatory to implement and the only algorithm this document defines. A new algorithm enters only through a new prefix defined by a referencing specification, its name drawn from the Named Information Hash Algorithm Registry (); this document defines no negotiation. A verifier MUST reject a digest whose algorithm prefix it does not recognize, so an algorithm added later cannot be exploited as a downgrade.

Binding the Mission to the Grant A Mission is independent of any OAuth grant: it is identified globally by the pair (issuer, id) (), and it can be approved, tracked, and terminated with no OAuth grant at all. Where this document derives a Mission through OAuth, it relates the Mission to OAuth in two distinct ways: the Mission grant binding, defined below, and the mission claim a derived token carries as its own Mission reference (). The Mission grant binding is an AS-controlled, functional mapping from one persistent, redeemable grant lineage to exactly one Mission. The AS alone establishes a binding and resolves it from the grant itself; a client never supplies or negotiates one, and no client input determines its Mission. A grant lineage is state the AS can resolve again on a later request, either:

the authorization code issued at approval and, where its redemption emits one, the refresh-token family that follows it; or
another profile-defined reusable grant, such as a refresh-token family a Token Exchange establishes later for the same Mission ().

Establishing and Resolving a Binding At a direct approval event the AS binds the Mission to the authorization code it issues, or, under a back-channel carriage profile, to the grant artifact that profile defines (). The binding is server-side, and it resolves the Mission for operations using that binding; a profile-defined grant can instead resolve it through its authenticated mission reference. An authorization request that carries no mission_intent proposes no Mission. An AS that answers such a request through consent reuse, such as with a grant an authentication session holds for the client, MUST NOT select a grant bound to a Mission: the request would otherwise acquire an earlier Mission's binding with no submission or approval of its own. This rule governs grant selection for a new authorization request. It neither prohibits ordinary consent nor changes how a derivation resolves an existing binding. The code itself carries no refresh-token family; only a successful redemption produces one. A refresh-token family so produced inherits the code's binding atomically with its issuance, extending the same Mission grant binding rather than starting a second one. At each subsequent derivation the AS resolves the Mission from the grant the client presents:

the authorization code at the token endpoint;
the refresh token on refresh;
the Mission-bound subject_token on Token Exchange (a delegate is identified by its client authentication, ); or
a profile-defined grant, through the authenticated mission reference it carries.

It then applies the gating of . A Mission MAY carry zero or more grant bindings. Beyond any authorization-code lineage established at approval, a refresh-token family a Token Exchange establishes later (above) is a further binding, or the Mission's first where it has none, rooted in the Mission its own subject_token resolved to. The AS MUST resolve a bound grant lineage to the same Mission on every derivation performed against it: the mapping is fixed for the lineage's lifetime and is never reassigned to a different Mission. An AS that finds a lineage resolving to more than one Mission fails closed on that lineage. Where a profile-defined operation lets a client present a Mission Identifier alongside a credential, the identifier is a non-authoritative cross-check: the AS MUST verify it against the Mission the credential resolves to and refuse a mismatch with the invalid_grant error code. Because the grant, not the identifier, determines the Mission, a client does not supply mission_id to obtain a derivation, and an AS MUST NOT derive Mission-bound authority from a client-supplied mission_id.

Grant Bindings and Related Mechanisms The grant binding relates to other mechanisms as follows:

Issuance under an existing binding. A Token Exchange derivation () that returns only an access token establishes no new grant lineage: ordinary in-Mission delegation () and self-exchange down-scoping () both work this way, and the issued token is a derived token () whose mission claim identifies the one Mission its subject_token resolved to. Where the subject_token was issued under a grant lineage, the issued token retains that grant provenance, and a later redemption of a designation derived from it validates all applicable backing-grant state (). A Token Exchange that creates another Mission, or that returns a grant for a Resource AS to consume, falls under the third or fourth item instead.
Establishing a new binding. A Token Exchange that establishes a redeemable grant lineage, such as by issuing a refresh token, creates a new grant binding, rooted in the Mission its subject_token resolved to.
Creating another Mission. Missions created from an existing Mission's authority are new Missions. Any grant binding or derived token they carry is their own under the same rules, not an extension of the origin Mission's binding. They relate to their origin only by lineage, a record member their specification defines ().
Transient exchange artifacts. A grant the Mission issuer returns for a Resource AS to consume establishes no destination-side grant binding. The Resource AS consumes it, and the local access token it mints there is a derived token: it identifies the one originating Mission (mission.id, mission.issuer) but is not backed by a persistent local lineage. A Resource AS holds a destination-side grant binding only where it separately establishes a redeemable grant lineage mapped to the Mission, such as a refresh-token family.
Runtime joins. A decision-time runtime join, in which a policy decision point joins an ordinary OAuth credential to a Mission per request, is not a Mission grant binding: it does not make the joined OAuth grant Mission-bound, and it rests on its own authenticated inputs and evidence, never on a Mission grant binding.

Mission State Across Bindings Non-active state gates every future derivation across every Mission grant binding (). It does not itself revoke an OAuth grant the same client or subject holds outside any Mission binding, and it does not recall an access token already issued before its exp absent a runtime state check the token's consumer performs (, ). When the authorization code expires unredeemed, no derivation is possible under the Mission regardless of which lifecycle outcome follows. The deployment either revokes the Mission or lets it expire at expires_at, and applies one choice consistently; both outcomes terminate it (), so reprocessing the same timeout changes nothing.

Mission-Bound Token Issuance An access token issued under a Mission takes one of two forms:

a self-contained JWT per , which a resource server can enforce from the token alone () and which this document's token-carried enforcement assumes; or
an opaque Mission-bound token, profiled only under the introspected consumption mode (), where introspection or issuer-local resolution carries its claims, with the same enforcement obligations.

states the issuance procedure for every path. The sections that follow state the token's claims (), its audience and the token response (), refresh (), self-exchange (), authentication claims and lifetime (), scope projection (), and the mission claim ().

Issuance Gating A derivation is one issuance operation the issuer AS performs for a single request: the initial authorization-code exchange, a refresh, a Token Exchange, or the redemption of a profile-defined grant. This document defines five issuance paths:

code redemption, the token response that redeems a newly created Mission's authorization code ();
a refresh ();
a designation ();
a delegated exchange (); and
a self-exchange ().

Designation and the delegated exchange belong to the optional Delegation capability, and self-exchange is optional too (). Each of these paths passes every check below. Each check is stated in the sections it cites, with any difference by path, and a path's own section states its further rules. Any other derivation, such as one a companion profile defines, passes at least checks 1, 3, 5, and 7, the exp bound of check 8, and check 10. The numbering is presentation order only: it imposes no execution order and no error precedence ( gives the error codes). An order that a rule states still applies, including these:

The Mission-governed refusal applies only to an otherwise processable request. On a refresh, it is decided before the refresh token is consumed or rotated ().
A refresh establishes any scope projection before the refresh token is consumed or rotated, or within the same atomic issuance ().
A delegated exchange authenticates the client before it refuses an actor_token ().
The revocation refusal applies at the AS's final decision to release the result (check 10).
A companion profile that sequences a check within a path keeps that sequence.

The checks are:

Mission resolution from the presented grant (): the code, the refresh token, or the subject_token, which on a delegated exchange is the designation.
Client and sender binding, as the path's section states for the code (), the refresh token (), the token a designation request presents (), the delegate (), and the self-exchanging agent ().
Mission state: the Mission is active (, ). A delegated exchange evaluates each redemption afresh ().
Mission-governed resources (). A refresh, a self-exchange, or a designation request needs no mission_intent.
Subset (): against the Mission Authority Set, and also against the presented refresh grant on a refresh, the presented token on a designation or a self-exchange, and the designation on a delegated exchange; on a designation or a delegated exchange, only as permits. An entry is narrowed, issued to another audience, delegated, or projected only under a declared capability ().
Audience (, , ): by each entry's original approved audience. For a designation, the check uses the resource audiences of its entries, not the client its aud names. For a delegated token, the audience is also one that processes the act chain ().
Scope projection (), wherever scope is emitted, requested, or the only form the target consumes. On a refresh, it applies with that section's protection of the refresh token.
Claims and lifetime (, , , ). Each token's exp does not exceed the Mission's expires_at. A designation, a delegated exchange, and a self-exchange keep the presented token's mission claim, with the differences and state.
Response members: the response echoes the granted authorization_details () and carries mission_id and mission_expires_at as states.
Release: the revocation refusal () applies at the AS's final decision to release the result.

Refusing a Derivation Unless the referenced Mission is active, the AS MUST refuse a request to derive a token at the token endpoint: a Token Exchange () with the invalid_request error code (), and any other grant, refresh included, with the invalid_grant error code. The AS MUST refuse a derivation request it answers after it has acknowledged a revocation of the Mission, with the same error code. A Token Exchange takes invalid_request because a presented token whose Mission is not active is unacceptable for the exchange, a case assigns to that code. The AS answers a request when it makes its final decision to release the result, not when network delivery of the response completes. A result prepared before the acknowledgment and released after it is therefore refused. The AS acknowledges a revocation when it commits the Mission's termination with reason revoked (), whether a revocation request or the deployment's policy caused it (). Receiving or queuing a revocation request does not acknowledge it, and acknowledgment does not wait for an HTTP response to complete or an event to be delivered. The refusal at release re-checks only an acknowledged revocation; it is not a general re-check of Mission state. Where a profile of a Token Exchange that the AS implements assigns its own error code to either refusal, such as a continuation profile's code for an ended chain, the AS uses that profile's code instead; the refusal itself, and the mission_error member (), still apply.

Mission Error Member The error code alone does not tell a client which gate refused. On a refusal under , the AS SHOULD include, alongside error, the mission_error token-error-response member () with one of the values revoked, expired, or superseded (where a companion defines supersession), the Mission's termination reason (). These values are termination reasons. A companion profile that defines either of the following defines any mission_error value for it:

another Mission state (), which also refuses; or
a further refusal at issuance.

A Mission in a state from which it can return to active MUST NOT be reported with a termination reason. The mission_error member is diagnostic only and optional, whichever document defines its value:

it grants nothing;
an unrecognized value is ignored and is not authoritative about the Mission's state; and
it is returned only to the authenticated client presenting the Mission's grant.

Each mission_error value this section names reports a terminated Mission (): no retry under the same grant cures the refusal. Further work needs a new approval or, for superseded, the Mission that superseded it. A new approval is a fresh approval event, not an automatic consequence of the refusal. A credential held outside the Mission is no fallback for its task (). The refusal gives no assurance that the refresh token remains usable. This reading is keyed on the value, not on the error code, because the same refusal covers a Mission in a non-terminal state that a companion profile registers (), whose meaning that profile defines.

Derived Token Lifetime Derived tokens SHOULD be short-lived so that a transition to terminated takes effect promptly without per-request revocation checks. A resource server that does not check Mission state per request can accept a derived token until its exp. At such a resource server, the token's lifetime is therefore the termination latency (). Short-lived means within the termination latency the deployment accepts. This document sets no numerical bound; a deployment profile can. The cap at the Mission's expires_at () does not by itself make a token short-lived.

Token Claims fixes the JWT's required claims (including jti), the typ header parameter value at+jwt, and resource server validation (, , ). A token whose format a companion profile explicitly defines, with its own typ and verification rules, follows that profile instead. JWT access-token validation remains governed by , including acceptance of at+jwt or application/at+jwt. A companion-format token is consumed only under that companion's verification rules. In addition to what requires, a derived token:

carries the token's Mission-derived authority as authorization_details (); this MAY be the full Authority Set or a narrowed subset ();
carries a mission claim ();
sets sub to the AS-local sub the AS maps the Mission's Subject to ();
carries client_id with its ordinary meaning (, ): the client that requested this particular token;
MUST set aud to identify the resource server(s) authorized to consume the carried authorization_details, and MUST NOT include an audience unrelated to that carried authority (), except that a token the AS issues only for presentation back to itself at a Token Exchange, such as a designation (), names in aud the client that presents it;
MAY carry an act claim when the agent has delegated execution ();
MAY carry a scope claim, subject to ; and
can be sender-constrained, as recommends, via a cnf claim : DPoP (cnf.jkt) or mTLS (cnf.x5t#S256).

A Mission-bound access token that is not a delegated token may be a bearer token, preserving compatibility with bearer-only resource servers while retaining 's recommendation; the cost is the stolen-token exposure (). A delegated token is sender-constrained to the delegate's own key (), and the Cross-Domain capability sender-constrains every credential that crosses a trust domain (). An AS that issues Mission-bound JWT access tokens for resource servers to consume MUST publish its token verification keys (for example, at its jwks_uri, as recommends); rotation retires a key from signing, never from resolvability while tokens signed under it remain valid. A token the AS issues only for presentation back to itself, such as a designation (), creates no publication duty by itself.

Audience and Token Response The AS audience-restricts the token per and ; aud names resource server(s), APIs, or security domains, not necessarily the entries' resource values. The client obtains a single-audience token () with the resource parameter, and can narrow it further with scope; the AS narrows the Authority Set under to the requested resource(s) and sets aud accordingly. A token-endpoint resource value outside the Authority Set is an invalid resource value in the sense of . Three identifiers stay distinct. An entry's resource, where its type defines one, names the protected resource its authority covers, and a resource server matches each request's operation target against it under the entry's type. A token request's resource parameter () selects the audience the client asks for. The token's aud names the recipients that accept the token, and the AS relates an entry to them through the entry's original approved audience (). A token issued for an audience carries only the entries whose original approved audience includes that audience; an entry approved for another audience is not carried, unless a declared narrowing capability permits issuing it there. A token whose aud names several audiences is issued only where the same entries are approved for each of them; where they differ, the AS refuses the request with invalid_target, and the client requests a separate token for each audience. The AS also refuses with invalid_target a request whose audience is approved for none of the entries the token would carry, and one whose authorization_details () names an entry not approved for its audience. states how these rules apply to a designation and to the delegated token issued at its redemption. The AS returns the granted authorization_details in every token response, including refresh and Token Exchange responses (). Strengthening , the AS MUST NOT omit values from it: the response states exactly the (possibly narrowed) set assigned to the issued token, and it is the authoritative statement of what was granted, which the client compares with its proposal (). A client MUST NOT assume authority absent from the granted set. An entry the echo narrows grants the narrower authority it states, and a client need not reject a grant narrower than its proposal. The mission_id and mission_expires_at response parameters carry the Mission reference and expiry beside it (). The following is an example of a refresh request that narrows the canonical ERP Mission (the worked example of ) to a read-only token with the resource parameter and the authorization_details parameter (). The ERP consumes authorization_details, so a resource scope for it would be refused (). Extra line breaks are for display purposes only: The authorization_details value, before form encoding, requests the Mission's read entry alone: The issuance is a derivation, gated on the Mission being active (). The following example shows the token response. It carries no scope member because none was requested or granted, and it echoes the narrowed grant and the mission_id reference (). The emitted entry is a subset () of the Mission's read entry, its constraints carried intact:

Mission Identifier and Expiry in Responses This document defines mission_id as a token-endpoint response parameter: a string carrying the Mission Identifier, returned alongside the issued token. It is an informational reference only: presenting it authorizes nothing (), and a client MUST NOT derive authority from it. Alongside it, this document defines mission_expires_at: the exact RFC 3339 string recorded as the Mission Record's effective expires_at (), the common member of every Mission-creating success response, whatever surface completes the creation. The expires_in parameter describes the access token's lifetime, not the Mission's, and the effective expiry can be shorter than the requested intent.expires_at. A client learns both values from these members, not from the access token, which it treats as opaque (). The AS returns them as follows:

The success response that first delivers a newly created Mission's identifier or credential MUST carry both. On the authorization-code path, the authorization response carrying only the code is not that response; the token response redeeming the code is.
A delegated exchange response carries both as requires.
Any other Mission-bound token response, including a refresh, designation (), or self-exchange () response, SHOULD carry both.
A creation replay deduplicated under the applicable operation identifier (approval_event_id for direct approval (), or the identifier a Mission-creating profile defines) returns the committed effective value unchanged.

On OAuth token responses mission_expires_at is additionally registered as a token-endpoint response parameter (). It is informational in the same way: presenting it authorizes nothing.

Refresh Tokens Issuance on a refresh applies the issuance procedure of as it states for a refresh. states a refresh's exemption from mission_intent and, for a Mission-governed resource, the refusal's precedence and its timing relative to consuming or rotating the refresh token. A Mission-bound refresh token is bound to the client it was issued to. For a confidential client, client authentication supplies the binding: on refresh, the AS authenticates the client and verifies that the refresh token was issued to it (), so the token need not also be bound to the DPoP proof key (). A public client's refresh token MUST be sender-constrained or use refresh token rotation (). The AS can rotate either client type's refresh token; rotation detects replay of a consumed refresh token () and is not a cryptographic binding. A refresh request can carry authorization_details to narrow the issued token (). The AS MUST refuse such a request with the invalid_authorization_details error code when a requested entry exceeds the presented refresh grant or the Mission Authority Set (), and MUST NOT instead issue a narrower set than the one requested.

Self-Exchange Down-Scoping An agent MAY present its own Mission-bound access token as the subject_token of a Token Exchange () with no actor, to obtain a narrowed token (for example, a single-audience one). Because it names no actor, such an exchange does not delegate: it re-scopes the agent's own authority downward. A designation () names a delegate, so it is not a self-exchange, and these rules do not apply to it. An exchange whose subject_token is a designation is a delegated exchange (), not a no-actor exchange, even when it carries no actor_token. Issuance applies the issuance procedure of as it states for a self-exchange. states a self-exchange request's exemption from mission_intent and the checks that still apply to it. A no-actor exchange is subject to the following:

The AS MUST refuse a no-actor exchange with the invalid_request error code () unless the authenticated client is the Mission's approved agent (the Mission Record's client_id, ). A delegate narrows only through a delegated exchange that names it in the act chain.
The result MUST be a subset () of the presented token's authority; it carries the same mission claim () and adds no act chain.

Self-exchange is an optional capability (). An AS that does not support it refuses a no-actor exchange: with unsupported_grant_type () if it does not support the Token Exchange grant type, and otherwise with invalid_request, as for a presented token it does not accept for the exchange (). Any other error that applies still applies, such as invalid_client for a client that fails authentication.

Authentication Claims and Lifetime A derived token's authority comes from the Mission, not from a fresh authentication. Authentication claims (acr, amr, auth_time) on a derived access token follow : they describe the token's Subject and keep the values of the authentication event behind the grant, so derivation does not refresh them. An AS MUST NOT use the authentication of an Approver who is not the token's Subject as authentication information about that Subject. These claims neither establish approval nor expand Mission authority; the Approver's approval-time authentication remains provenance (). Where no authentication of the Subject applies, as when a human approves a Mission for another principal or for a workload, the claims are absent, and their absence is not an authentication downgrade. The authorization_details claim is the authoritative expression of a Mission-bound token's authority; a scope claim () is a compatibility projection that cannot carry per-entry constraints. A credential the Mission Issuer derives MUST have an exp that does not exceed the Mission's expires_at, so that no credential outlives the approved Mission. Within that bound, a derived token's lifetime is the AS's policy, which recommends keeping short. Token Exchange does not tightly couple an issued token's lifetime to its subject_token's (); states how this applies to a designation and to the delegated token issued from it.

Scope Projection This section applies to every issuance that emits scope on a Mission-bound token or whose request names a scope value, and to issuance for a target that consumes only scope: such a target receives a safe projection or a refusal (projection step 5 below).

Subset Condition For every target audience, the AS MUST establish that the effective rights the target's enforcement path grants from the projected scope, together with every independently mandatory control on that path, are a subset of the rights the token's applicable authorization_details grant. This is a semantic condition, not a structural one. Exactly as it fails for a relaxed constraint, it fails for a constraints-free entry whose scope:

aggregates a broader action;
spans more resource instances or paths than the entry;
carries rights the target's local scope interpretation implies; or
arises from the union of several entries.

Per-Audience Condition For a multi-audience token, the AS establishes the condition independently for each audience; a single-audience token () remains preferred.

Projection Steps To emit scope for an entry, the AS:

determines the target resource server or audience for the token;
resolves a trusted, versioned scope-projection mapping for that target, established through the target's protected resource metadata () or authenticated out-of-band configuration;
establishes, under the subset condition above, that the complete effective authorization the projected scope grants at that target is no broader than the applicable carried entries;
omits scope for an entry where the target's enforcement path consumes authorization_details instead; and
MUST refuse issuance to a target that is scope-only when no safe projection exists for the applicable entries: an issued token no enforcement path can safely evaluate is not a usable credential.

Unknown scope semantics, unknown resource server enforcement behavior, or an ambiguous or stale mapping all fail closed under step 5 (). A changed mapping is not by itself stale: the AS evaluates each issuance, refresh included, against the target's current trusted mapping, and a mapping is stale only when the AS cannot establish that it is the current trusted mapping for that target. This rule applies to every issuance path that can emit scope on a Mission-bound token: initial issuance, refresh, Token Exchange, and any other derived-token path. This is the type-agnostic form of the rule; a type's own specification states when the mapping in step 3 is safe for that type's entries.

Requested Scope Values Scope projection does not change OAuth response semantics and does not make access-token inspection a client requirement. requires the token response to carry scope whenever the granted scope differs from the requested scope, and its grammar defines no empty scope, so an issuance cannot report an ungranted requested value by omission. The AS MUST refuse, with invalid_scope (), a request that explicitly names a scope value the issuance cannot grant: a value the target's trusted mapping names but no carried entry makes safe (step 3), or any scope value the AS associates with a target that consumes authorization_details (step 4). An unknown, ambiguous, or stale mapping fails projection step 5 and yields the invalid_target error code even when the request also names a scope value; invalid_scope applies only under a mapping the AS trusts. Where the AS emits a projected scope, a requested scope narrows it to the requested values, and the token response reports the values granted (). A Mission-creating client does not request a resource scope for a target that consumes authorization_details; for a scope-only target, a requested scope selects among the values the projection can grant. Scope values with their own semantics, such as openid (), are unaffected and combine with authorization_details as permits.

Scope-Only Targets For a scope-only target, the trusted mapping also relates a requested scope value back to authority, so a deployment's existing scope values can request a Mission in configured-mapping mode (), combining scope with the Mission's authorization_details as leaves to the AS.

Each requested value stands for the entries that the type's specification derives from the mapping.
The Authority Set is those entries narrowed to policy, and the token for that target carries their projection under the steps above.
A requested value the target's trusted mapping does not name cannot be granted, and is refused with invalid_scope ().

Refresh Token Protection A refusal caused solely by failure to establish a safe scope projection MUST NOT invalidate an otherwise-valid refresh token or its authorization grant. Independent expiration, revocation, and replay-detection rules continue to apply. An AS meets this by establishing the projection before it consumes or rotates the refresh token, or within the same atomic issuance, not by disabling rotation or restoring a consumed token.

Mission Claim The mission claim is a JSON object:

id:: REQUIRED. A string. The Mission Identifier ().
issuer:: REQUIRED. A string. The Mission's issuer (). A credential's iss names the party that minted it; mission.issuer names the party that approved and serves the Mission, and the two differ for tokens minted in another trust domain ().

The id and issuer members identify the Mission and carry no authority of their own; the token's own signature authenticates the pair, and the carried authorization_details remains the token's concrete authority.

expires_at:: OPTIONAL. A string. The Mission's expires_at (), in RFC 3339 date-time form. It commits a lifetime bound, not current state: a validator can check that the token's exp does not exceed it, but that check does not establish that the Mission is still active, the only state that permits reliance ().

A consumer that relies only on the presented token's own validity needs nothing further: the token's exp already bounds it. A profile that mints a further credential downstream of this one, or that verifies a Mission's remaining lifetime from retained state rather than a live token, MUST require expires_at and MUST treat its absence as an error. The token's own exp bounds only that one credential, not every credential the Mission may still yield. The baseline mission claim carries neither authority_hash nor approval_basis. Neither is an enforcement input a narrowed-token resource server can exercise: authority_hash commits the complete Authority Set, which such a resource server does not hold (); approval_basis.type is provenance, not authority (). An authorized introspection caller can receive authority_hash and approval_basis.type (). The mission claim is an open object (): additional members MAY appear alongside the members above. This document defines no registry of mission members. A companion profile of this document MAY use short member names coordinated with it; any other extension member MUST use a collision-resistant name (for example, a name in a namespace the extension controls, per the Collision-Resistant Name guidance of ) and is defined by the profile that introduces it. A consumer MUST ignore members it does not understand and MUST NOT use any additional member to grant or widen authority; the members above remain authoritative. The following is an example of a decoded Mission-bound token payload:

Claim Reservation The mission claim of an access token, and the mission member that introspection returns for an access token (), are reserved for issuance that conforms to a Mission-binding profile. An AS MUST NOT issue an access token carrying the mission claim unless the token's issuance or derivation conforms to one: this document's issuance gating () and subset rule () for a token the Mission's issuer derives, or a companion profile that defines another issuance or derivation path, including a token that a Resource AS or a consuming AS issues and a token a holder derives under an attenuation profile. A profile that defines such a path MUST identify:

the authenticated grant or parent chain that connects the token's authority to the Mission;
the authority bound the path enforces, and the comparison or projection by which it enforces it;
where Mission state is checked, by which party, and the freshness or lifetime bound within which that check is relied on; and
any check a consumer of the token performs.

A mission claim means that the token's issuance or derivation conformed to its profile. It does not mean that the party that minted the token queried the Mission's current state, and it attests issuance, not the Mission's state afterward: a later suspension or revocation does not change what the claim attests (, ). The claim establishes no trust by its presence; a resource server's issuer authorization and claim validation () still apply. This reservation concerns access tokens and their introspection representation. An evidence or control artifact that embeds a mission descriptor () is not an access token, and this section does not change its meaning.

Delegation Within a Mission Delegation is an optional capability (). An agent may delegate execution to downstream actors (a sub-agent, service, or tool that is itself an OAuth client) within a Mission. Delegation is represented with the OAuth Actor Profile , which profiles the act (actor) claim of . An intermediary in the agent's own trust domain that presents the agent's own tokens, such as a gateway holding the agent's credentials, acts as part of the agent and is not a delegate; acting as the agent, it can also narrow by self-exchange (), which does not delegate. An intermediary authenticated as a distinct actor that obtains a delegated token by Token Exchange is a delegate. Delegation takes two kinds of Token Exchange, in this order:

The delegating party obtains a designation that names the delegate ().
The delegate redeems that designation for a delegated token ().

| | |<------ designation ------| | |---------------------- designation ------------------->| | |<------ Token Exchange: | | | subject_token = | | | designation | | |------- delegated token --->| ]]>

Designation A designation is the delegating party's authorization for one delegate to obtain delegated tokens. The holder of a Mission-bound access token obtains it by Token Exchange (): it presents that token as the subject_token, proves possession of the token's confirmation key, and names another client's identifier as audience, with requested_token_type urn:ietf:params:oauth:token-type:access_token. Only a sender-constrained token can therefore be designated. The holder is the Mission's approved agent for a token that carries no act claim, and otherwise the delegate that the AS's accounting records as the token's outermost actor (). Issuing a designation applies the issuance procedure of as it states for a designation. A designation request is a token request under an existing Mission-bound grant (): it needs no mission_intent, and every other check that section names still applies to it. A designation the AS issues:

carries a subset () of the presented token's authority, and the same mission claim ();
has aud equal to the designated client's identifier, and a may_act claim () whose sub is that identifier;
carries no cnf and no act claim: like an authorization code, it is bound to the client that redeems it, which authenticates and proves its own key in the delegated exchange (), and the delegated token's act renders the AS's accounting (); and
MUST expire shortly after it is issued, and no later than the presented token or the Mission's expires_at.

A designation's aud names its redeemer and reassigns no entry's original approved audience (). For a designation, the audience rules of test the resource audiences associated with the entries it carries, never the designated client its aud names (). A designation carries only a permitted subset of the presented token's entries (, ), each keeping its original approved audience (). An entry without an original approved audience is not carried, and a designation that would carry no entry is refused with invalid_target. Its redemption issues an entry only as and permit, including their narrowing condition. The delegated token issued at its redemption is subject to every rule of unchanged. A designation names a delegate and adds none. Whether one may be redeemed more than once within its lifetime is the AS's policy; each redemption is a delegated exchange of its own (). Its expiry bounds when it can be redeemed, not the lifetime of a delegated token issued from it (). That delegated token can outlive both the designation and the credential the designation was derived from. Revoking the grant state backing that credential still refuses every later redemption (). A designation authorizes no resource access. A designated client's identifier MUST NOT be an audience that any resource server accepts for this AS's access tokens, throughout the designation's lifetime. That includes an alias a resource server accepts but the AS never issues as an audience. The AS MUST refuse, with invalid_target (), a designation request naming a client for which it cannot establish that separation. A resource server that validates a JWT access token's audience () therefore rejects a designation, and at introspection () the AS MUST return active: false for one, with no mission member.

Delegated Exchange A delegate obtains a delegated token by Token Exchange (), presenting a designation that the delegating party obtained for it (). Issuance applies the issuance procedure of as it states for a delegated exchange. The AS issues the delegated token subject to all of the following:

The exchange is explicit. The subject_token is a designation this AS issued naming the authenticated requesting client (), with subject_token_type urn:ietf:params:oauth:token-type:access_token, and the requested_token_type is urn:ietf:params:oauth:token-type:access_token. The AS MUST refuse any other subject_token with invalid_request (); an access token issued for resource access is never sufficient. The delegate is identified by its own client authentication, and the AS asserts the actor itself ().
The delegate authenticates. The AS MUST authenticate the requesting client, whether or not the request carries an actor_token, by a method it relies on to identify the client (), and MUST refuse a client it does not so authenticate with invalid_client (), issuing no token. Once it has so authenticated the client, the AS MUST refuse a request that carries an actor_token with invalid_request (), issuing no token. A claimed client_id, possession of the designation, or proof of an independently chosen key, such as a DPoP key, does not authenticate a client. This document does not support a public client as a delegate: lets an AS establish a client authentication method with a public client but not rely on it to identify the client. Only an extension that defines an explicit binding of a designation to its delegate admits one; deployment policy alone does not.
Subject is stable. sub remains the Mission's Subject. The delegate is an actor, not the Subject.
client_id keeps its ordinary meaning. It names the client that requested the token (); the originally-approved agent stays in the Mission Record ().
The act chain identifies the delegates. The delegated token carries an act claim per and the Actor Profile : the outermost act is the current delegate, and each earlier delegate is nested in the previous actor's act member. Each actor object carries the members that profile defines (for example, sub, iss, and the sub_profile actor-type classification, such as ai_agent).
The audience processes the chain. The AS issues the delegated token only for an audience that meets the issuance rule of , and refuses any other with invalid_target.
Authority only narrows. The delegated token's authorization_details MUST be a subset () of the designation's authority, hence of the delegating token's and of the Mission Authority Set. A type that declares delegation without narrowing () is delegable only unchanged: the AS MUST NOT include an entry of such a type in a delegated token unless it is equal () to an entry of the presented delegating token, it keeps that entry's approved audience, and the type's delegation policy permits the delegate (). The reference is the presented token, not the Mission Authority Set, so equality never restores an entry, or any part of one, that the presented token omits.
The mission claim is unchanged. The delegated token carries the delegating token's mission claim () unchanged, so every actor in the chain operates under the one consented authority.
Each delegate is bound to its own key. The delegated token MUST be sender-constrained () to the delegate's own key: its cnf is the delegate's DPoP or mTLS key, not the delegating party's, and the delegate proves possession of that key in the Token Exchange. Compromise of a delegate's key therefore does not enable use of tokens bound to the agent's or another delegate's key.
Each redemption is gated. Issuing a delegated token is a derivation, refused unless the Mission is active (). The AS MUST evaluate every redemption of a designation afresh, as a derivation of its own: the credential the designation was derived from, and all applicable grant state backing that credential, are still valid; the Mission is active; and the delegation policy () and the Mission's current authority admit the result. An earlier redemption establishes none of these. Where that credential was issued under a grant lineage, the backing grant state includes that lineage, kept through any exchange that established no new grant lineage (). A credential issued under none has no lineage to validate; that never excuses dropping or ignoring a lineage that does exist. The Mission's active state never substitutes for backing grant state.

A delegated exchange response MUST carry mission_id and mission_expires_at (), because the delegate did not receive the response that created the Mission. The act chain nests (act.act) for as long as, and only while, authority continues under the same approved Mission. A new approval basis, such as a Mission created from an existing Mission's authority (), begins its own delegation basis and chain, and no organizational, network, or deployment boundary by itself restarts or extends a chain. The chain is attribution, not authority:

An act entry names who acted, for audit.
The input to the eligibility matching of is the delegate the AS authenticates and asserts at the exchange, not an entry read from the chain.
An asserted actor identity grants nothing.
The authorization_details subset relations (), not the chain, show that authority narrowed.

Instance Context in Delegated Tokens Where a deployment authenticates client instances (, with attesters a client endorses under ), the delegate named by the outermost act can be an actor that an authenticated instance represents. Instance evidence does not establish that actor (), so the AS establishes the delegate's actor identity, and that actor's trusted association with the instance, separately. Because a delegated token is sender-constrained to the delegate's own key (), and the Actor Profile makes the top-level cnf the current presenter's key (), that cnf is a key the instance possesses. A deployment MAY convey client_instance in delegated tokens under . This composition selects the authenticated presenting instance for output context. The instance specification owns attestation validation, instance-to-key association, audience-scoped mapping, and Context Consumer validation; this section supplies the Mission-specific authorization and context selection. Deployments configure its use and whether instance attribution is required.

When issuing context under this composition, the AS MUST use the presenting instance validated under , establish its trusted association with the separately authenticated delegate, and bind the output token to an instance-unique key whose possession it verified in that exchange. Context is mapped from that validated instance into the output audience's Consumer Scope under . The AS MUST NOT use context copied or remapped from an input token as a substitute for the presenting instance's evidence. For example, when instance B is authorized to continue work from instance A, output context names B; A's context does not become B's identity by remapping it.
The actor authentication, delegation eligibility, subset, and lifecycle checks of and still authorize the exchange; instance evidence satisfies none of them by itself.
Where deployment policy requires instance attribution, the AS MUST refuse the exchange if the required instance evidence or its association with the delegate and output key cannot be established. gives the error codes for these refusals.
If the exchange issues a refresh token, and so establishes a redeemable grant lineage (), the grant-continuity rules of apply alongside ; instance continuity alone does not authorize replacement of the recorded instance or key rebinding.
Consumers establish presenter attribution under Sections 7.3 and 7.5 of . A consumer requiring attribution rejects unestablished associations under .
This composition does not add provenance to client_instance: a consumer can use the direct-attestation trust configuration only when the issuer meets that configuration's restriction against upstream context.
An issuer also conveying upstream context needs a separately specified, authenticated provenance mechanism before its context can support presenter attribution.

Delegation Constraints What may be delegated, how far, and to whom is governed per Authority Set entry by a type-defined delegation policy (). For mission_resource_access, the policy is the delegation member, whose concrete depth and matcher conditions the Mission Resource Access Profile defines (). Because the policy lives in the entry, authority_hash commits it with the rest of the Authority Set. Delegation depth. The delegation depth of a token is the number of delegations between the approved agent and the token's current actor: the agent's own non-delegated token is depth 0, the first delegate is depth 1, and each further delegate adds 1. The depth checked against max_depth is that of the token being issued, computed after appending the new outermost actor, not the depth of the delegating token. Depth accounting. The AS MUST establish delegation depth from accounting it maintains for the tokens it issues under the Mission and associates with the credential it validates (for example, recorded at issuance against the token), not from the nesting of a presented act claim. The act chain is attribution (): it renders the accounted chain and is not the source of the count. Over the exchanges this document defines, the accounting is complete:

each delegated exchange adds exactly one delegate; and
a designation () and a self-exchange () add none.

A profile that issues Mission-bound tokens by another path specifies how it preserves or reconstructs this accounting and any reset it defines. Where the AS cannot establish the depth of the token being issued, no entry's delegation policy can be evaluated at that depth, so every entry narrows out under the per-entry rule below and the exchange is refused as an empty result. A resource server bases no authorization decision on a prior actor (). Per-entry enforcement. When the AS issues a token to a delegate (the actor that becomes the outermost act) at delegation depth d, it includes a Mission Authority Set entry in the delegated token's authorization_details only if both of the following hold:

The entry's type defines a delegation policy for the entry. An entry carrying no type-defined delegation policy is non-delegable, the default.
That policy, evaluated at depth d, permits this delegate. The AS applies the policy's own eligibility test at every exchange; where the policy leaves a matcher unstated, the AS's delegation-authorization policy decides, and absence is never a blanket grant.

An entry failing either condition narrows out of the delegated token, consistent with the subset rule (). The delegation policy is not part of the subset comparison itself, and a surviving entry carries it intact so the next hop is evaluated the same way. Empty result. If narrowing leaves no entries for the delegate, the AS MUST refuse the exchange with the invalid_target error code () rather than issue a token with empty authority. The requested delegation has no authority to carry, while the subject grant itself remains valid for other exchanges. The resource server enforces none of this. The AS applies delegation constraints at issuance; a resource server sees only the already-narrowed authorization_details and enforces those as usual ().

Delegated Token Example In this example, the Mission's Authority Set has two entries on the ERP: invoices.read, delegable to ai_agent actors through depth 2; and journal-entries.write, which carries no delegation member and is therefore non-delegable. The approved agent s6BhdRkqt3 designates sub-agent tool-runner-7, an ai_agent, which redeems the designation at depth 1. The read entry is permitted (depth 1 <= 2, ai_agent allowed) and the write entry narrows out. The following is an example of the decoded delegated access token: The sub claim is still the user. The client_id claim is tool-runner-7, the delegate that authenticated the Token Exchange and requested this token (); it matches the outermost act only because tool-runner-7 authenticated the exchange itself. The client_id claim does not name s6BhdRkqt3, the originally-approved agent, whose identity remains recoverable from the Mission Record via mission_id (). The cnf is tool-runner-7's own key, not the agent's, so this token cannot be replayed as the agent. The non-delegable write entry was dropped; the read entry survives, carrying its delegation member so a further hop can be evaluated: a depth-3 delegate, or a non-ai_agent one, would narrow it out too. The mission claim is unchanged.

Token Consumption states how a resource server enforces a Mission-bound token, and how the issuer reports a token's Mission state through token introspection.

Resource Server Enforcement A resource server enforces a JWT Mission-bound token from the token alone; no call to the AS is required. It validates the token per , and any sender-constraint binding (cnf) per or , locally, even when it introspects (). An opaque Mission-bound token is enforced from its active introspection response or issuer-local resolution instead, under the same rules ().

Enforcement Requirements A resource server:

MUST treat authorization_details as the authoritative expression of authority and enforce each applicable entry according to that entry's own type specification. Where more than one carried entry applies, entries are alternative grants of authority, not conjunctive filters, unless the entry's type states otherwise.
MUST treat as providing no authority any applicable entry whose type it does not implement, or whose type-defined enforcement it cannot complete (an unrecognized member, an unenforceable constraint, or an unrecognized matching mode). It MUST challenge with insufficient_scope (), or with the RAR-remediation challenge as states, unless another applicable entry that it can fully enforce authorizes the whole request on its own, and MUST NOT combine parts of several entries to authorize one request. A failure of the token's own validation (above) rejects the token whatever its entries carry.
MUST NOT, when a token also carries scope, grant on the basis of a scope value any access broader than the corresponding authorization_details entry permits, including access that bypasses a constraint carried only in authorization_details.
MUST NOT infer the Mission's originally-approved agent from client_id, which names the client that requested this token, on a delegated token or otherwise (, ); the approved agent is recorded only in the Mission Record () at the issuer.
MUST, when configured to require the mission claim for a Mission-governed resource, challenge with the invalid_token error code a request whose token lacks it. The issuance-side duty that pairs with this challenge is stated in , the downgrade it prevents in , and the metadata that advertises the requirement in .
MUST accept a mission claim only from an issuer it explicitly trusts to issue Mission-bound authorization for the resource; trusting the issuer's ordinary access tokens is not enough. It MUST require mission.issuer to equal the token's iss, unless a Mission-binding profile it has adopted (), such as , explicitly establishes the permitted relationship between the two. It MUST challenge with the invalid_token error code a request whose token fails either check. For an opaque token, the issuer is the AS whose introspection response or issuer-local resolution the resource server relies on, and the same checks apply to that response's mission member ().

Other sections state how a resource server treats a reported Mission state (), mission claim members (), an entry's resource against a request's target (), and a designation presented to it (). A resource server can also:

require that a token carry an act chain and record it, while authorizing only the token's current actor ();
log the mission claim's id and the token's jti claim with each served request, so its access logs join to Mission evidence; or
where the AS offers it, introspect the token () to observe Mission state per request.

Mission-Unaware Resource Servers A resource server that receives no delegated token need not be Mission-aware. One that authorizes only from scope operates within the Mission only to the extent the AS established a safe projection for it at issuance (); constrained authority that no safe projection carries is enforced only where a resource server, or a runtime layer, evaluates authorization_details. Two parties keep a delegated Mission-bound token, one carrying an act claim, from consumers that do not process the act chain:

The AS, at issuance. The AS MUST refuse, with invalid_target (), a request for a delegated Mission-bound token whose audience it has not established as a Mission-aware Resource Server () that also processes the act chain, authorizing and logging the caller from the chain rather than from client_id alone. That the audience parses act does not establish this.
The deployment, after issuance. A deployment MUST NOT route a delegated Mission-bound token to a Mission-unaware resource server, or to logging or audit infrastructure, that authorizes or logs the caller on client_id without processing the act chain. The AS cannot verify where a token travels beyond its audience or which pipelines log its use, so that routing and logging remain the deployment's.

A Mission-unaware resource server reads client_id as the immediate client, which is accurate for that single token. It cannot see the delegation lineage in the act chain or look up the originally-approved agent in the Mission Record, so it cannot recognize the current actor as a delegate, record that lineage, or join a delegate's action to the Mission's approval in its audit records. A resource that requires Mission-bound tokens can advertise that through the mission_bound_authorization_required protected resource metadata member (); a resource server that serves such a resource is, by that requirement, Mission-aware. That requirement does not by itself establish that the resource server processes the act chain.

Carried Authority An entry whose type-defined enforcement a resource server cannot complete fails closed because a type-defined constraint narrows authority: treating an unenforceable key or member as absent, or reducing it to disclosure-only, would widen the grant. The baseline token carries no authority_hash (). Where a deployment discloses it to a resource server (through introspection's disclosure privilege, , or a companion profile that carries its own copy), it is an audit correlator, not an enforcement input, and not a cryptographic proof that the carried entries are a subset of the approved set. That subset relationship is an assertion by the AS, authenticated by the token signature. Mission Approved-Set Verification () defines an independent check for a resource server that needs more than that assertion.

Denial Responses A resource server denial falls into one of four cases, each using the OAuth challenge for its own failure class ( gives the codes):

Weak or stale Subject authentication. Where the deployment conveys the authentication of the token's Subject, through the claims of or introspection (), and that authentication does not meet the resource's requirement, the resource server challenges with insufficient_user_authentication and the acr_values or max_age parameters (). Where no Subject authentication applies, the token carries no such claims and the challenge offers no remediation, so the resource server does not use it. The Subject's authentication is a distinct fact from the Approver's approval-time authentication; a requirement on the Approver is an approval floor (), not a resource server challenge.
Sender-constraint or key-binding failure. The token's proof of possession is missing or invalid: the resource server challenges with invalid_token, in the DPoP scheme for a DPoP-bound token (, with use_dpop_nonce per ) and in the Bearer scheme for a certificate-bound token (). This is not a step-up: no fresh user authentication repairs a missing or wrong key.
Insufficient carried authority. The action is outside the token's carried authority: the resource server challenges with insufficient_scope (), or with the RAR-remediation challenge where is deployed ().
Unenforceable constraint. An applicable entry carries a type-defined member or constraint the resource server cannot enforce, and the resource server challenges with the same base error as case 3.

Cases 3 and 4 are identical 403 responses to a client, which cannot tell from them whether a new approval would help. A Mission-aware Resource Server SHOULD therefore indicate which of the two cases applies by including, alongside error (), the mission_denial attribute that this document defines for the WWW-Authenticate response header field, with one of two values:

insufficient_authority:: The action is outside the token's carried authority; more requires a new approval.
constraint_unrecognized:: An applicable entry carries a type-defined member or constraint the resource server cannot enforce. A client MUST NOT treat this value as inviting retry, step-up, or fresh approval: none of those makes a resource server enforce a constraint it does not implement.

A value the client does not recognize is treated as insufficient_authority. A resource server SHOULD include the attribute only in a response to a validly signed, audience-correct token whose holder its deployment permits to learn the distinction ().

Remediation Grains A denial can carry independent remediation grains: separate remediation mechanisms, each naming a next step without granting anything. There are three: the mission_denial attribute of the WWW-Authenticate challenge (); the insufficient_authorization error code with the authorization_remediation parameter (), which names what mission_denial: insufficient_authority only points at; and the requestable denial of , profiled by , which routes the same denial into a governed access request rather than a fresh derivation. Each grain keeps the wire shape and response status its defining document gives it. A client that decodes authorization_remediation can request the carried entries on the standard authorization_details parameter of a refresh request (), where they derive under this document's ordinary rules (): of an advertised, schema-valid type (), narrowed same-type (, ) like any other request. The AS issues only what both the presented refresh grant () and the Authority Set contain, and refuses a request beyond either (), so a refresh-token family narrower than the Mission does not obtain the Mission's wider authority. For entries outside the Authority Set, more authority requires a new approval, proposed as for a new Mission (). A client holding no refresh grant that covers the entries proposes them as for a new Mission. The three grains compose: a deployment can offer any subset, and none widens authority beyond what derives from the same proposal unremediated.

Mission State via Token Introspection A resource server consults the issuer about a Mission-bound token in one of three cases, with different obligations:

JWT state observation. A resource server that observes Mission state per request introspects the JWT Mission-bound token it holds, instead of waiting for the token to expire.
Opaque-token consumption. For an opaque Mission-bound token, introspection is the claims carriage: an active response carries what the JWT would ().
Issuer-local resolution. In place of introspection for an opaque Mission-bound token, an AS can serve a qualifying resource server by a direct read of the AS's authoritative committed token and grant state ().

The cases separate token representation from state freshness. Representation is where a resource server reads the token's authority: the JWT itself or, for an opaque token, its active introspection response or issuer-local resolution. Freshness is how recent its view of Mission state is: a JWT read alone shows only that the Mission was active when the token was issued; an introspection response reports the token and its Mission for one decision; and a state-distribution companion reports the Mission's state, not a token's, with its own freshness. In every case the authority a resource server enforces is the one the token carries (). An AS MAY support OAuth 2.0 Token Introspection for Mission-bound access tokens. When it does, an active: true response for such a token, to a caller authorized to receive Mission data (), MUST carry, in addition to the standard members, a mission member: a JSON object with the following members:

id and issuer: as in the mission claim ().
state: the Mission's current lifecycle state (string). Its value space, including a state a deployed companion profile defines, and the consumer's forward-compatibility rule are those of .
termination: when state is terminated, the Mission's termination () (object).
proposal_hash: when the Mission records an authority proposal, the Mission's proposal_hash () (string).
authority_hash: the Mission's Authority Set commitment () (string).
approval_basis: the Mission's approval_basis (), carrying type only.
authority_source: the Mission's authority_source (), carrying type and, for organizational, policy with id and version only, never the policy digest.

Only the Mission issuer reports state, termination, proposal_hash, authority_hash, approval_basis, and authority_source (). The last four are audit and correlation signals, not enforcement inputs (); each is disclosed only as permits. For a malformed, unknown, individually expired, or otherwise unresolvable token, the AS responds per (active: false) with no mission member; it does not reveal Mission state for a token it cannot bind to a Mission. The AS discloses a mission member only for a token it has established was issued on a path that conforms to ; a token it cannot establish so is unresolvable in this sense. How the AS establishes this is its own; a record of its own issuance is one means. The composite-active rule () and the mission member apply equally when a Mission-bound refresh token is introspected. Freshness is per use. Strengthening , which permits a protected resource to cache the response, this document defines no caching semantics for the mission member: a resource server that relies on introspection for Mission state treats each response as an observation for that decision, not as a cacheable state assertion. A deployment that needs bounded-staleness caching adopts the Mission Status companion, whose signed responses carry explicit freshness ().

Caller Authorization and Minimization Strengthening , which requires some form of authorization to access the introspection endpoint, the AS:

MUST authenticate the calling party.
MUST return Mission data only to a caller authorized to receive it, in particular a resource server that is an audience of the token.
MUST audience-filter the response, returning the authorization_details entries and Mission data relevant to the caller's audience and not disclosing entries addressed to other audiences ().

These rules apply equally to the mission member of an active: false response (). Disclosure is member-scoped as well as caller-scoped. The proposal_hash, authority_hash, approval_basis, and authority_source members serve audit and correlation consumers, not resource server enforcement, and the AS MUST disclose each only to a caller the deployment has granted that member's disclosure privilege. By default, an audience-authorized resource server receives the audience-filtered enforcement projection above, without them. A mission member that a companion profile defines for disclosure here follows the same member-scoped rule and is not an enforcement input.

Composite Active State The introspection active member reflects the composite authorization, not the token in isolation. Strengthening , the AS MUST return active: true only when the access token passes that section's checks (valid signature, unexpired, and not individually revoked) and the Mission is active. A designation, which authorizes no resource access, is reported inactive with no mission member, as states. The AS does not verify the token's sender-constraint (cnf) at introspection; the resource server checks proof of possession when the token is presented, so active: true is not by itself evidence that the caller holds the bound key. When the token is otherwise valid but the Mission is terminated, the AS MUST return active: false and include mission.state and mission.termination, whose reason gives the cause, so a resource server can distinguish a dead Mission from a bad token. A Mission transition does not by itself revoke the token as an individual credential; introspection reports the composite authorization as inactive. An otherwise valid token is one that passes those checks and that the AS has established was issued on a conforming path (). Reporting the mission member, mission.state included, for an inactive token deviates from the SHOULD NOT of Sections 2.2 and 4 of against including additional information about an inactive token. The caller authorization and minimization rules () govern that deviation.

Issuer-Only Members An AS MUST NOT include mission.state, mission.termination, proposal_hash, authority_hash, approval_basis, or authority_source in an introspection response unless it holds the Mission, that is, unless it is the Mission issuer. Introspection at a non-issuer Resource AS, which returns only the claim-shape members, is specified by the cross-domain companion ().

Introspected Token Consumption The RFC 9068 JWT of is this document's self-contained carriage. An AS MAY instead issue a Mission-bound access token as an opaque reference token, under this mode and only under it; an opaque Mission-bound token outside this mode is not profiled.

In this mode, an AS issuing opaque Mission-bound tokens MUST offer introspection for them with the members this mode names, unless every resource server that consumes them uses issuer-local resolution (below).
An active (active: true) response for such a token MUST carry, as introspection response members, the audience-filtered granted authorization_details (), the mission member above, aud, cnf where the token is sender-constrained (, ), and act where execution was delegated (): everything requires the JWT to carry, sourced from the same issuance state.
The granted authorization_details and any act chain appear only on an active response. An inactive response carries active: false and the mission state facts (), never the authority itself.
A resource server consuming an opaque Mission-bound token:
- MUST resolve it through introspection or issuer-local resolution (below) before service;
- MUST verify active is true, its own identity in aud, and the sender-constraint binding cnf names; and
- MUST enforce the response's authorization_details under the same rules as the token-carried form (), the fail-closed duties included.
A resource server whose introspection response for an opaque Mission-bound token is active: false, or whose issuer-local resolution resolves it as inactive, MUST refuse the request with the invalid_token error code (), in the DPoP scheme for a DPoP-bound token ().
A resource server that cannot obtain a valid introspection response or issuer-local resolution for an opaque Mission-bound token MUST refuse the request rather than serve it from any cached or out-of-band belief about the token's authority. The failure establishes nothing about the token: the resource server MUST respond with HTTP status code 503 (Service Unavailable) (), adding a Retry-After header field where a retry time is meaningful, and MUST NOT report the token as invalid, such as with the invalid_token error code.

The per-use freshness rule of covers the whole response in this mode: each response is one observation of the token's claims and Mission state, not a cacheable authority record. An AS MAY serve a resource server through issuer-local resolution: a direct read of the AS's authoritative committed token and grant state, not a call to an introspection endpoint. introspection keeps its meaning as a network protocol. A resource server qualifies only when it is inside the issuer's trusted implementation boundary and the AS authorizes it to read that state; common ownership or a shared network does not by itself qualify it. For each resolution, the AS:

MUST resolve the presented token to that token's own issuer-qualified issuance or grant record, and establish from that record the token's expiry, revocation and grant validity, its intended audience, the composite active state (), and the token's own authority;
MUST authorize the resource server and minimize disclosure to it as requires for an introspection caller; and
MUST yield, when the token is active, only what an active response for that token carries in this mode, audience-filtered for that resource server and with act and cnf as that response carries them, and never the Mission's Authority Set or other authority the token does not carry.

Mission state alone, or a lookup by Mission Identifier, never establishes a token's validity or authority. An unknown, invalid, expired or revoked token, or a Mission that is not active, resolves as inactive and yields no authority; missing or unavailable state yields no valid resolution. In the resource server duties above, the resolution stands in for the introspection response, possession proof and fail-closed refusal included, and each resolution is one per-use observation, not a cacheable assertion.

Introspection Response Examples The following is an example of an introspection response for the canonical ERP token () while the Mission is active. The issuer AS returns the standard members and the mission member to a caller holding the deployment's audit-and-correlation disclosure privilege, so authority_hash and proposal_hash appear; the default audience-filtered enforcement projection omits them. The following is an example of the response, after the Mission is revoked, for an unexpired token the AS issued on refresh before the revocation ():

Mission Lifecycle A Mission is in one of two states:

active: the only state in which the AS derives tokens.
terminated: a terminal state; the Mission has ended. Its termination member () gives the reason: revoked when it was revoked (), or expired when its expires_at passed.

The transitions are: Mission lifecycle transitions

From	Event	To	Reason
(none)	approval event	`active`
`active`	revoke	`terminated`	`revoked`
`active`	`expires_at` reached	`terminated`	`expired`

The Mission Lifecycle States registry () holds these states, and the Mission Termination Reasons registry () holds the reasons. A companion profile MAY register an additional state for a lifecycle it introduces (for example, a paused state). A companion profile that defines a further way for a Mission to end registers a termination reason, not a state. Wherever a Mission state is reported, including the Mission Record and the introspection mission member, a consumer MUST treat only the exact value active as permitting derivation or continued reliance, and MUST treat every other value, including one it does not recognize, as non-active and non-deriving (the forward-compatibility rule). For every state-dependent decision this document defines, the AS MUST treat a Mission as active only when its stored state is active and the decision time is strictly before expires_at. From expires_at, a Mission whose stored state is still active is terminated with reason expired for every such decision, whether or not that transition is persisted, including when persisting it fails. Persisting that transition, and emitting any lifecycle event a state-distribution companion defines, can happen after the decision that observed the boundary; persisting it never replaces a termination already recorded.

Mission Termination A Mission whose state is terminated carries a termination object, in the Mission Record and wherever its state is reported with it; a Mission in any other state carries none. Its members are:

reason:: REQUIRED. A string, a value of the Mission Termination Reasons registry (): revoked or expired in this document, or a reason a companion profile registers.
terminated_at:: REQUIRED, except as described below. A string. An RFC 3339 date-time: the instant the termination took effect. For expired, it is the Mission's expires_at.

A companion profile that registers a reason defines that reason's further members. A profile that maintains a state version for the Mission adds the version of the transition that committed the termination as its audit reference. The issuer writes termination once, atomically with the transition to terminated, and MUST NOT change it: an expiry, or any later event, does not replace the reason or references of a Mission already terminated. A termination carries every member its reason requires, except as follows. A termination need not carry a member its reason requires when it was recorded before its reason defined that member, or derived from such a termination: such a termination exposes only the facts its record retained and omits a member it has no retained value for, terminated_at included, rather than inventing one. For expired, the retained terminated_at is the Mission's expires_at; for another reason, a retained commit time is its terminated_at only where that commit was the termination's effect. A consumer that receives such a termination, or a reason it does not recognize, still treats the Mission as terminated: it stops work governed by the Mission, follows no absent reference, and infers no cause-specific action.

Revocation A Mission is revoked when the AS receives a revocation for it from a party the deployment's policy authorizes to revoke it, or when that policy itself terminates the Mission; either way, its termination reason is revoked. The Subject, the Approver, and an administrator are parties that policy can authorize; none is authorized by its role alone. A Mission Issuer MUST accept, through an authenticated means independent of possession of any token, a revocation by mission_id from a party the deployment's policy authorizes (so a Mission can be stopped even when no refresh token is held). The wire shape of that revocation is out of scope for this document. A deployment-defined surface that authenticates the revoking party independent of possession of any token satisfies this requirement. When the AS establishes that the principal identified by a Mission's recorded subject () has been deprovisioned, it SHOULD terminate that Mission with termination reason revoked. The rule reaches every Mission not yet terminated, including one a companion profile has suspended, and identifies the Subject by its recorded iss and sub. Temporary disablement, a source outage, or an unavailable lookup does not by itself establish deprovisioning. The departure or disablement of an Approver, an accountable owner, or a client triggers the rule only when that principal is the recorded Subject; an organizational Mission records the organizational principal as its Subject (), so an approving officer's departure does not terminate it under this rule. A deployment that does not follow this rule documents why; that exception cannot bypass a continuing dependency the deployment requires or rewrite the recorded Subject. Termination stops further issuance () but does not itself recall tokens already issued; an earlier execution cutoff depends on the deployment's enforcement mechanism. Revoking a token does not by itself revoke a Mission. lets an authorization server's revocation policy extend a token's revocation to related tokens and the underlying grant; a deployment's revocation policy can likewise treat revoking a Mission's refresh token as revoking the Mission; a deployment that couples token revocation to Mission revocation documents that behavior. Token validity and Mission validity are distinct: a consumer that enforces from the token alone can honor an issued access token until it expires (), and one that checks Mission state refuses it when that check reports a non-active state, under the mechanism's freshness rules. A deployment whose consumers rely on Mission state beyond a token's lifetime offers token introspection () or Mission Status (), so they read current state rather than infer it from token validity.

Error and Challenge Mapping This document reuses standard OAuth errors and challenges, selected by parameter ownership and processing stage. The following tables are the normative statement of the base OAuth error for each failure they list. Every rule elsewhere in this document that names one of these codes applies this mapping. An AS that performs an applicable check early, at PAR, responds with the same error class the check would yield at the authorization or token endpoint. permits an authorization-request error at PAR, and returning it there does not change which row applies. Where a token request fails more than one check, this document defines no general precedence among the resulting errors; as under , which defines none, the AS returns any applicable one. The orders this document does state still apply: a submission's processing order (), and the Mission-governed refusal, which applies only to an otherwise processable request (). The choice relaxes neither client authentication nor any rule that limits who receives a detail, such as mission_error (). The tables are grouped by surface. The first table holds each failure whose rule is not confined to the surface of one of the other three tables (PAR and the authorization endpoint, Token Exchange, or a protected resource); each failure appears once. Token Exchange is a token-endpoint operation: a row of the first table that names the token endpoint or a token request covers an exchange, alongside the exchange rows of the third table. Failures not confined to one surface

Surface / failing input	Base OAuth error and optional detail
PAR, or a companion's token-endpoint submission: a presented evidence entry of an unsupported type, or failing its type's validation or verification (), or a required evidence type absent ()	`invalid_mission_intent_evidence` (). Detail: safe `error_description`
Authorization or token request: invalid, unknown, or malformed actual RFC 8707 `resource` parameter, or a token-endpoint `resource` outside the Mission's Authority Set ()	`invalid_target` (). Detail: safe `error_description`
Token request: the requested audience is approved for none of the entries the token would carry, the request's `authorization_details` names an entry not approved for its audience, or the audiences it names are approved for different entries ()	`invalid_target` (). Detail: safe `error_description`
Authorization or token request: the target's scope-projection mapping is unknown, ambiguous, or stale, whether or not the request names a `scope` value, or the target is `scope`-only and no safe projection exists for the applicable entries when the request names no `scope` value (); or the AS has not established a delegated Mission-bound token's audience as a Mission-aware Resource Server that also processes the `act` chain ()	`invalid_target` (). Detail: safe `error_description`
Authorization or token request: an explicitly requested `scope` value the issuance cannot grant under a scope-projection mapping the AS trusts ()	`invalid_scope` (, ). Detail: safe `error_description`
Profile-defined operation that lets a client present a Mission Identifier alongside a credential (): the identifier does not match the Mission the credential resolves to	`invalid_grant` (). Detail: safe `error_description`
Token endpoint: the Mission is `terminated` (revoked, expired, superseded, or another termination reason), or in another state that is not `active`, such as one a companion profile defines	`invalid_request` on a Token Exchange (), `invalid_grant` () on any other grant, or the code a Token Exchange profile assigns (). Detail: `mission_error` (), or a value the companion profile defines for its state ()
Token endpoint (, ): the requested RAR subset exceeds the Mission's granted authority, or, on refresh, the presented refresh grant	`invalid_authorization_details` (). Detail: safe `error_description`
Token endpoint (): the comparison cannot establish that a requested RAR entry is a subset (an unrecognized member, an incomparable value)	`invalid_authorization_details` (). Detail: safe `error_description`

PAR and authorization endpoint failures

Surface / failing input	Base OAuth error and optional detail
PAR: malformed Submission envelope or Intent (schema, unknown member, invalid value), including a structurally invalid evidence entry (, )	`invalid_request` (). Detail: safe `error_description`
PAR or authorization: malformed or unsupported actual RAR object (an entry of a submitted `authorization_details` proposal) ()	`invalid_authorization_details` (). Detail: RAR-defined detail
PAR: a proposed entry, valid for its type, whose `resource` is not among the Intent's `target_resources` ()	`invalid_request` (). Detail: safe `error_description`
PAR or authorization request from a client registered as Mission-governed: `authorization_details` without `mission_intent` ()	`invalid_request` (, ). Detail: safe `error_description`
Token request, any grant type: an audience the token would carry, named or inferred, is a Mission-governed resource, and the request has no qualifying Mission binding ()	`invalid_target` (). Detail: safe `error_description`
Authorization request: `scope` includes `openid` and the Approver is not the Subject ()	`invalid_scope` (). Detail: safe `error_description`
Authorization decision (, , , ): the Approver declines, approval authentication fails the floor or a requested `acr_values` or `max_age`, a well-formed request (including configured-mapping mode) is refused by AS policy, or the commit finds the effective expiry not later than the creation instant	`access_denied` (). Detail: for a configured-mapping refusal, a safe `error_description` can say whether no mapping matched or policy narrowed the candidates to nothing; for an expiry at the commit, a safe `error_description` can say that the requested expiry has passed; otherwise none unless a defined extension applies

Token Exchange failures

Surface / failing input	Base OAuth error and optional detail
Token exchange: a `subject_token` or `actor_token` that is invalid, whose sender constraint is not proven, or that is unacceptable for the exchange	`invalid_request` (), unless a Token Exchange profile assigns the failure its own code. Detail: safe `error_description`
Token exchange: a required DPoP proof that is missing, or a DPoP proof that fails its own validation	`invalid_dpop_proof` (): the failure is not an unproven sender constraint, so the row above does not apply. Detail: safe `error_description`
Token exchange: a DPoP proof lacking the current DPoP nonce, where the authorization server requires one	`use_dpop_nonce` with a `DPoP-Nonce` header (), not `invalid_dpop_proof`. Detail: safe `error_description`
Token exchange with no actor (): the authenticated client is not the Mission's approved agent	`invalid_request` (). Detail: safe `error_description`
Token exchange with no actor () at an AS that does not support self-exchange	`unsupported_grant_type` () if the AS does not support the Token Exchange grant type; otherwise `invalid_request` ()
Delegated token exchange (): the AS does not authenticate the requesting client by a method it relies on to identify the client, which no public client meets	`invalid_client` (). Detail: safe `error_description`
Delegated token exchange (): the AS has authenticated the requesting client, and the request carries an `actor_token`	`invalid_request` (). Detail: safe `error_description`
Delegated token exchange (): the `subject_token` is not a designation this AS issued naming the authenticated requesting client	`invalid_request` (). Detail: safe `error_description`
Designation (): the AS cannot establish that no resource server accepts the named client's identifier as an audience for its access tokens, including an alias it never issues	`invalid_target` (). Detail: safe `error_description`
Delegated token exchange (): narrowing leaves no entries for the delegate	`invalid_target` (). Detail: safe `error_description`
Token exchange using : required Client Attestation fails validation	`invalid_client_attestation`. Detail: no instance-identity disclosure
Token exchange using : required instance-to-delegate or output-key association cannot be established	`invalid_request` (). Detail: no instance-identity disclosure

Protected resource challenges

Surface / failing input	Base OAuth error and optional detail
Protected resource: a token lacking the `mission` claim, where the resource requires it ()	`invalid_token` (). Detail: none
Protected resource: weak or stale authentication of the token's Subject, where the deployment conveys it ()	`insufficient_user_authentication` (). Detail: `acr_values` or `max_age`
Protected resource: DPoP proof missing, invalid, or mismatched ()	`DPoP` `invalid_token` challenge (). Detail: none
Protected resource: DPoP nonce required, missing, or stale ()	`DPoP` `use_dpop_nonce` challenge (). Detail: fresh nonce
Protected resource: certificate-bound token's presented certificate mismatch ()	Bearer `invalid_token` challenge (, per ). Detail: none
Protected resource: an opaque Mission-bound token that its introspection response or issuer-local resolution reports inactive ()	`invalid_token` (), in the `DPoP` scheme for a DPoP-bound token (). Detail: none
Protected resource: introspection or issuer-local resolution of an opaque Mission-bound token cannot be completed ()	No error code reporting the token invalid: HTTP 503 (), with `Retry-After` where a retry time is meaningful. Detail: none
Protected resource: insufficient carried authority, or an unenforceable constraint ()	`insufficient_scope` () or the RAR-remediation challenge (). Detail: `mission_denial` (), minimized

In these tables, invalid_client_attestation is the error code that specifies.

Authorization Server Metadata This document defines the following authorization server metadata parameter :

mission_bound_authorization_supported:: OPTIONAL boolean. When true, the AS supports the core Mission Issuer surfaces of this document (): the mission_intent authorization request parameter through PAR (), Authority Set derivation yielding authorization_details entries of its supported types (, ), Mission-bound access tokens (), and the mission JWT claim (). It asserts Mission Issuer support only; it makes no claim about any resource server or about the optional capabilities, whose discovery is described below. If omitted, the default value is false.

A deployment can instead arrange Mission-bound authorization, including its supported types and schemas, out of band. A client holding a Mission Intent MUST NOT submit the same authority as bare scope or authorization_details to an AS whose Mission support is neither advertised nor otherwise established; it surfaces the inability instead (). A client performing a task under a Mission MUST NOT present, for that task, a credential that is not Mission-bound, such as an ordinary access token it already holds, unless a deployment-defined, trusted enforcement path establishes that Mission for the request and applies the Mission's authority and lifecycle controls to it. Neither a Mission Identifier the client supplies nor documentation alone establishes the Mission for a request, and the path confers no authority beyond the Mission's. The rule does not restrict the client's workflows unrelated to the Mission (). An AS that advertises support for this document MUST include at least one AS-supported type in its authorization_details_types_supported metadata (). Where mission_resource_access is among them, the Mission Resource Access Profile (), not out-of-band documentation, is that type's normative definition. An AS that advertises mission_bound_authorization_supported: true MUST also publish pushed_authorization_request_endpoint (), since the authorization-code path accepts a Mission Intent only through PAR (). An AS that advertises mission_bound_authorization_supported: true SHOULD also advertise authorization_details_types_metadata_endpoint where it implements that endpoint. Implementing that endpoint is optional, and the rules below bind only an AS that advertises it:

its response's key set is the source of truth for which types the AS supports;
authorization_details_types_supported mirrors those keys and MUST NOT list a type absent from them; and
the AS MUST publish, within that response, an entry for every supported type whose schema validates that type's documented object shape.

The optional capabilities are discovered first through existing OAuth metadata (): introspection_endpoint for introspection, and grant_types_supported containing urn:ietf:params:oauth:grant-type:token-exchange for self-exchange, for delegation, and for the companion's cross-domain grant issuance. Advertising that grant type does not by itself establish support for every exchange variant, such as self-exchange or delegation. Absent such a signal, a capability is discovered out of band or by attempt: a Token Exchange, a cross-domain grant issuance, or an introspection request fails if the issuer does not support it.

Protected Resource Metadata This document defines the following protected resource metadata parameter :

mission_bound_authorization_required:: OPTIONAL boolean. When true, the protected resource accepts only Mission-bound tokens: a token that lacks the mission claim () is rejected (). If omitted, the default value is false. An AS that has authenticated this metadata treats a true value as making the resource Mission-governed (); false or omission does not clear a deployment's classification.

A type-defined authorization_details member may define its own constraint-discovery surface. A protected resource can list the authorization_details types it accepts in the authorization_details_types_supported parameter (), so a client can propose entries of a type its target accepts.

Extensibility Other specifications can extend this document. Extensions build alongside the stable interface below; they MUST NOT redefine it. The following remain stable across revisions of this document:

the mission claim members id and issuer ();
the authorization_details carriage and its type-agnostic subset discipline (, ); and
the act delegation chain ().

Each extension point states what its specification supplies and what an AS without the extension does. The requirements of and bind a specification that uses them and each party that implements it.

Extension Points This document's extension points are:

Authority types. The Authority Set is open to any AS-supported authorization_details type (); the Mission apparatus (commitment, gating, delegation) is type-agnostic, subject to the delegation and projection limits in , and an entry of a type the AS does not support is refused (). A type's specification supplies what the apparatus relies on for its entries:
- the definition a proposed entry is validated against, alongside any schema advertised for the type or established out of band ();
- the enforcement semantics a resource server applies to an entry ();
- the subset relation, which the AS applies only where it declares narrowing for the type; otherwise an entry is carried as approved (, );
- the delegation policy, which the AS applies only where it declares delegation; an entry with no type-defined policy is non-delegable ();
- when a scope-projection mapping is safe for the type's entries, which the AS relies on only where it declares projection (); and
- any normalization a comparison of its members uses; without one, URI-valued members compare byte for byte ().
Intent Submission Evidence types. The evidence array of the Submission envelope is open to evidence types defined by companion profiles: each type is a collision-resistant name whose owning specification defines the entry's closed schema, verification, and verified output facts (), and an AS refuses an entry of a type it does not support rather than ignoring it. A verified entry is policy input, never authority ().
Mission Intent members. The Mission Intent's top level () is open to members a companion profile defines, under a short name it registers in the Mission Intent Members registry () before use, or under a collision-resistant name. The owning specification defines, produces, and enforces each such member, and a recognized member never grants or widens authority beyond what that specification states. Closed-top-level validation () refuses any top-level member that neither this document nor an implemented companion profile defines, and the AS ignores none it recognizes. Registration settles which specification owns a short name, not whether an AS implements, recognizes, or trusts any member.
Integrity anchors. Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (, ). A profile that commits an evidence or disclosure object MUST commit it with this envelope and a typ that meets and , not by hashing the bare object, so the domain separation and issuer binding hold uniformly. A mission descriptor embedded in such an object uses the mission claim shape (), optionally extended with collision-resistantly named members, and is never authority-bearing on its own. An AS without such a profile produces and verifies none of its commitments.
The mission claim. It is an open object: additional, collision-resistantly named members can be carried in it, under the consumer rules of .
Mission Record members. The Mission Record is open to additional members set at creation, under short names a companion profile coordinates with this document or under collision-resistant names, as states.
Lifecycle state and termination reason. The lifecycle state space () is open to additional states that companion profiles register in the Mission Lifecycle States registry () for lifecycles they introduce. The termination reasons () are likewise open to reasons that companion profiles register in the Mission Termination Reasons registry (). Under the forward-compatibility rule of , only active permits issuance. A companion interface changing Mission state leaves in force; a terminated Mission stays terminal.
Approval bases. The approval_basis.type value space () is open to standing-consent bases that companion profiles define under .
Approval-event sequencing. The approval-event steps, their order, and the atomicity of record creation with the approval decision are fixed by ; the coupling of that decision to authorization-code issuance belongs to the direct flow. A companion profile MAY relocate the approval event relative to code issuance (for example, deferring the decision beyond the authorization response, as does), and a back-channel carriage profile () MAY instead couple the approval decision to establishing the Mission grant binding and activating for redemption a grant the profile defines, the Mission then binding to that profile-defined reusable grant (), provided in either case the steps and their atomicity with the approval decision hold unchanged and no Mission reference exists before the record is active.
Grants and issuance paths. A companion profile can define a further grant lineage or a profile-defined grant. Its specification states when the AS establishes the binding and how it resolves the Mission, and every derivation through the grant passes (). Neither a returned access token nor a per-request runtime join is a grant lineage (). Without such a profile, the AS resolves a Mission only from the authorization-code lineage and a Mission-bound subject_token.

This document defines no capability-negotiation mechanism or profile-version field; an extension declares its own identifiers and, where it needs discovery, its own metadata. states the general rule these extension points follow.

Namespace Taxonomy This document's extensible namespaces follow one of three postures:

Registry-backed. A namespace whose values determine fail-closed behavior and span multiple documents is backed by an IANA registry. This document creates the Mission Lifecycle States (), Mission Termination Reasons (), and Mission Intent Members () registries and seeds each with the values it defines; every further document that defines a value requests that value's registration, carrying any Internet-Draft reference as a publication dependency under the registry's policy.
Specification-defined. A namespace with a defined fail-safe for unknown values and no registry, such as the mission claim members (), the Mission Record members () and the approval_basis.type values (), is specification-defined: the defining documents are its value space.
Collision-resistant. Deployment-defined names are collision-resistant names () and are never registered.

A typ inside a JCS commitment envelope () names a hash domain, not a representation crossing a protocol boundary, and is not a media type.

Mission-Creating Paths The direct path of is the one this document defines in full. A companion profile creates Missions on another path in one of two ways, which stay distinct:

Relocating the direct ceremony. A profile that defers the approval decision, or carries the submission over a back channel, keeps the direct approval: the basis stays direct, and Approval-event sequencing () states what the relocation keeps unchanged.
Activating under standing consent. A profile can define a named standing-consent basis, under which a template or policy activates Mission instances against an accountable human's earlier approval, with no fresh human approval per instance; each instance is still created at its own approval event (). A companion profile that defines a standing-consent basis MUST specify its approval_basis.type value and its activation semantics: what activates an instance, and the shape of the instance's activation. An issuer that activates a Mission under such a basis MUST record the instance's activation, activation_actor, root_commitment, and approved_at, as defines them for a standing-consent basis. Neither requirement binds a deployment that creates Missions only on the direct path. The basis's approval_basis.type values form a specification-defined namespace with no registry ().

When a human approves a standing consent's consented root (the template version, the ceiling, or the activation policy), the issuer that records that approval MUST:

authenticate the consenting principal (step 1 of );
establish that principal's authorization over the root's permitted Subjects and authority sources (steps 2 and 3);
obtain that principal's consent to the root's authority, its limits, and its activation policy (step 5); and
record that principal as the consent_principal of every instance the root activates.

A future instance's Subject need not be known when the root is approved; each instance falls within what the root authorized. An already approved parent's delegation authority can supply the root, with no fresh human ceremony for each activation. Each instance's creation still meets the rules of this document that bind it: the Subject is never taken from unauthenticated client input and is mapped injectively (step 2, ); the authority source and its ceiling (); the effective expiry and its creation-commit check (steps 4 and 7); the integrity anchors (step 6); and atomic creation, deduplicated as states. An unrecognized type or adjudication.kind is handled as states for every record consumer. The companion profiles that define standing-consent bases for this document adopt the Approval Basis Contract of ; a profile defined elsewhere can meet this section's requirements by another mechanism.

Commitment Mechanisms This document's default prefixed construction commits to bytes in three forms, called species, and a specification defining a prefixed commitment classifies it as one of them:

Envelope anchor: the domain-separated, issuer-bound envelope of (intent_hash, proposal_hash, authority_hash, and commitments produced with companion-defined typ values).
Canonical-object digest: sha-256: over the JCS serialization of a normalized JSON object without the envelope, where protocol context already fixes what is committed.
Raw-octet digest: sha-256: over an exact, specification-defined octet sequence, with no canonicalization: a whole artifact as exchanged, or the UTF-8 encoding of a defined scalar value.

The prefix and agility rules of bind all three species. Its I-JSON rule binds the two JSON species. The envelope and typ discipline of , with the typ naming rule below, binds envelope anchors alone. The rules of bind a prefixed digest of any species when its defining specification classifies it under this taxonomy and imports this section normatively; this document so classifies every anchor it defines. This document's anchors and digest rules (, ), with this taxonomy, instantiate the default commitment construction of . A commitment outside this construction (a native content address, a member-named digest whose member name fixes the algorithm) is permitted; its defining specification states its own algorithm identification and agility behavior. This document defines no registry of typ values; each committing specification defines its own and relies on the typ domain separation. To keep that domain separation safe without a registry, a new typ value MUST be a collision-resistant name (for example, a short name prefixed within a namespace the defining profile controls, following the Collision-Resistant Name guidance of ). Values with the mission- prefix, used by this document and the profiles that extend it, form a namespace coordinated through this document's change controller. This document defines no transition mechanism: every commitment a current carrier defines is a single prefixed string, and no carrier defines a location for a second one. A specification that introduces a new prefix MUST define:

the carrier and schema of any parallel commitment;
the binding that proves the old and new values commit to the same object;
producer behavior during the transition;
verifier selection and downgrade behavior when recognition sets differ; and
the transition procedure itself.

Such a specification MUST NOT change a commitment already made, including the implied value of an anchor a Mission Record omits, which stays the sha-256 construction of .

Authority Set Entry Commitment This document also defines the Authority Set entry commitment, the envelope of with typ mission-authority-entry, iss the Mission issuer, and value a single Authority Set entry object exactly as recorded (). A companion that cites an entry by digest (a decision record naming the entry it evaluated, containment or completion state keyed to an entry) computes it this way. Entries whose canonical commitment envelopes are identical produce the same digest, and within one Mission Record every recorded entry resolving to the same digest forms one selector equivalence class; the class is defined by the canonical bytes, not by pre-canonical source text the record does not preserve. The commitment is not a globally unique entry identifier: the envelope binds the issuer, not the Mission, so a protocol that uses it to select or cite an entry MUST bind it to the Mission issuer and Mission Identifier whose recorded Authority Set is searched, directly or through an enclosing object whose integrity protection binds them.

Conformance The smallest useful conforming deployment is a Mission Issuer that:

derives in narrowing mode from the client's authority proposal ();
supports one AS-supported authorization_details type and emits only that type's specification-defined vocabulary; and
implements none of the optional capabilities.

A Mission Issuer can instead start from configured-mapping mode (), which is equally conforming. Neither starting point is a conformance class, and neither removes a surface: the Mission Issuer still implements every surface its role lists (), the evidence dispatch and refusal rules included even when it supports no evidence type.

Conformance Roles An implementation conforms in one of three roles. A Mission Issuer (the authorization server) implements the core issuance surfaces:

submission of a Mission Intent, in the Submission envelope, via PAR (), with the Intent Submission Evidence dispatch and refusal rules ();
Authority Set derivation yielding authorization_details entries of its supported types (, );
the approval event with its integrity anchors and its recorded approval_basis and authority_source (, );
issuance of Mission-bound access tokens carrying the mission claim (), as the RFC 9068 JWT or as an opaque reference token under the introspected consumption mode ();
the subset rule ();
gating of issuance on Mission state (); and
acceptance of a revocation by mission_id through an authenticated means independent of possession of any token ().

An AS can conform as a Mission Issuer without supporting any Intent Submission Evidence type. Such an AS refuses every presented entry under the dispatch and refusal rules (): a structurally invalid entry with the invalid_request error code, and any other entry, as an unsupported type, with the invalid_mission_intent_evidence error code. A Mission-aware Resource Server implements resource server enforcement (). It enforces a JWT from the token's own claims, needing no Mission-state store and no call to the AS. Under the introspected consumption mode, it instead enforces the token from the token-specific inputs of its active introspection response or issuer-local resolution (). In either form, it enforces each applicable entry its tokens carry under that entry's type, work a plain resource server does not do. Conformance in this role implies support for no particular type: an entry of a type the resource server does not implement provides no authority there (), so interoperable enforcement needs a type that both the AS and the resource server implement. A Mission Client implements the client surfaces:

submission of the Mission Intent via PAR on the authorization-code path (), proposing concrete authority, where it does, on the authorization_details parameter pushed alongside mission_intent ();
reading its granted authority from the token-response authorization_details echo, and assuming none absent from it (); and
obtaining mission_id from the mission_id token-response parameter (), never from the access token, treating it as a reference, not a credential.

Optional Capabilities Beyond these mandatory roles, an implementation can additionally claim four OPTIONAL capabilities. Each is independent, and an implementation that supports none of them is still conformant:

Delegation (): issuing designations () and the derived tokens that carry the act delegation chain, and consuming those tokens. Only a sender-constrained token can be designated, so Delegation requires sender-constrained non-delegated Mission-bound access tokens.
Self-Exchange (): narrowing an agent's own Mission-bound token by a Token Exchange that names no actor. Supporting Delegation does not require Self-Exchange, and supporting Self-Exchange does not require Delegation.
Introspection (): reporting Mission state through the mission token introspection response member. Required where the AS issues opaque Mission-bound tokens to a resource server that does not use issuer-local resolution (). Issuer-local resolution does not by itself support a claim of this capability.
Cross-Domain: projecting a Mission so it is honored by an authorization server in another trust domain. An implementation claiming this capability preserves, across the hop:
1. the Mission reference (mission.id, mission.issuer) and the authority_hash the projection carries, intact;
2. authority that only narrows ();
3. projection performed only by, or under the authorization of, the Mission issuer, gated on the Mission's active state (, );
4. projected credential lifetimes capped by the Mission's expires_at ();
5. projected credentials sender-constrained to their presenter (), never bearer credentials, each recipient verifying the proof of possession and refusing a credential whose binding is absent or invalid (); and
6. renewal only through the Mission issuer: a projected grant is redeemable once, and the other trust domain issues no renewal authority on it, so a further credential there needs a new projection.
This bar is self-contained in this document. The companion Mission Cross-Domain Projection profile () specifies the interoperable mechanism that satisfies it.

Claiming Conformance A conforming implementation names the optional capabilities it supports (for example, "Mission Issuer with Delegation and Cross-Domain"); each capability's defining section or document states its detailed requirements. Emitting the mission claim is not, by itself, conformance: the claim is reserved for conforming issuance (). Conformance as a Mission Issuer requires the gates: authority derived from the approved Intent and committed by the anchors (), issuance bounded by the subset rule (), and derivation gated on Mission state (). An implementation that carries Mission metadata without these gates conforms to no role in this document and does not implement it: in particular, it MUST NOT advertise mission_bound_authorization_supported as true (), the machine-checkable form of that claim. The Mission Binding Properties vector of names what these gates supply as its credential-mission-bound property, informatively; these gates remain authoritative for conformance to this document regardless. This document makes no Mission Substrate conformance claim and takes no requirement from the substrate contract (), which is informative.

Implementation Considerations This section states two requirements, approval idempotency and the retention of the Mission Record, and how an issuer locates a Mission's grant bindings.

Approval Idempotency The record's approval_event_id () is the approval idempotency key: a retried or duplicate delivery of the same approval decision (a replayed callback, a double-submitted consent form, a retried standing-consent activation) MUST NOT create a second Mission, and the AS deduplicates on this identifier. Each creation path answers such a delivery in its own way, with the committed Mission, a denial or a credential delivery; none creates a second Mission. The AS MUST allocate approval_event_id, unique among its Missions, and MUST NOT derive it from a value that a client supplies and can reuse. At a direct approval event the AS MUST allocate it before the decision commits and bind it to the authorization interaction, never to a request_uri or another client-supplied value. The identifier is immutable and is retained with the record (). Each decision is bound to the interaction, deferral or activation that it decides, which has its own lifetime. A delivery of the decision after that lifetime MUST NOT create a Mission, and the AS MUST retain the identifier for at least that lifetime, so a retired record never turns an old delivery into fresh authorization. Some creation paths recognize a retry by a request key that the client supplies. The profile defining such a key MUST state its retention contract: when the retry horizon starts and ends; that a reservation whose operation is still pending when the horizon ends is retained until that operation ends; that a published horizon is never shortened for a key already recorded; and that a reuse of the key after its reservation has expired under that contract, never while its operation is pending, is a new operation, which meets every check a new request meets, including authorization, policy, ceiling, expiry and accounting, and receives a new approval_event_id. Expiry of a key never lets an earlier decision create another Mission.

Audit Horizon The audit horizon is the deployment-declared retention window for the Mission Record and its evidence: at least the Mission's lifetime plus a declared post-expiry period. A deployment retains a terminated Mission's record for its audit horizon.

Binding Index An issuer that needs to cascade a lifecycle operation, or to enumerate a Mission's bound grant lineages and credentials, maintains its own issuer-side index from the Mission to each binding.

Security Considerations The security considerations of OAuth 2.0 (), the OAuth 2.0 Security Best Current Practice , Rich Authorization Requests (), Pushed Authorization Requests (), and JWT access tokens () apply to this document. Those of Token Exchange () apply to delegation, and those of DPoP () and mutual TLS () apply where a token is sender-constrained.

Commitment and Consent Integrity

Consent Binding The security goal of this document is that a user's approval of a task bounds every token derived for it. The Mission's authority_hash commits the exact Authority Set the Approver consented to (). The goal rests on the AS deriving only subsets of that set and signing every token accordingly, and on the resource server verifying the AS's token signature and enforcing the carried authority, not on every token carrying the commitment (). A derived token can carry a narrowed subset, so a resource server cannot in general recompute authority_hash from the token, and the hash supplies no subset proof. A resource server that does not verify against the complete set relies on the signed token as the AS's assertion that the carried authority was correctly projected (). A deployment that needs assurance independent of the token signature verifies the carried authority against the complete approved set. What that verification provides depends on when the issuer is compromised. Retrieving the complete set under the same trust root as the token adds nothing against an issuer malicious at approval time: that issuer can approve and commit arbitrary authority, and no containment mechanism changes that. The same checks do defend against projection implementation errors, against corruption of the record after an independently anchored approval commitment, and against post-approval signing-key compromise where the original commitment is pinned outside the issuer. The intent_hash anchor extends the same protection to the task: it commits the approved Mission Intent, so an auditor holding a value captured at approval can detect a later alteration of the recorded task. No anchor substitutes for another. Recording an anchor is optional (). A recorded anchor lets a verifier detect a later change to the retained intent, authority_set, or proposed_authority against the record itself, which detects only partial corruption: whoever can change the record can change both. An omitted anchor gives up that check, and detection rests on a value captured outside the record before the change, such as a pinned commitment, a signed carrier, or an audit record. Recomputing both sides from the changed record detects nothing. The authority_hash anchor is computed over the Authority Set alone (), what a resource server enforces and a cross-domain projection carries, so it can be checked without the Intent. The intent_hash anchor stays tamper-evident audit material even where the authority is projected without the Intent. The anchors do not commit the rendered consent disclosure: none binds the locale, disclosure-template version, or material notices the Approver was shown. A buggy or malicious rendering layer could therefore show a narrower or different task than the committed Authority Set without a committed trace. The approval event commits the Mission Intent and Authority Set the AS records as approved. Those commitments establish neither that the AS rendered them faithfully nor that the Approver understood them. Step 5 of requires human-meaningful rendering; comprehension cannot be inferred from an approval or its integrity anchors. A deployment whose Missions carry high-risk authority can retain presentation-level audit evidence from which the disclosure shown can be reconstructed and audited, such as a commitment over a structured consent-disclosure object (). Such a commitment binds the structured disclosure the AS records, not the presentation itself; it narrows this gap for audit but does not close it. The anchors do not commit the approval basis either: who consented, who activated the Mission, and under which basis (). The record's immutability protects it, and only the AS enforces that. A deployment that needs the approval basis checkable outside the AS can commit it under a profile's own anchor typ (, ) in a signed or externally registered artifact.

Downgrade by Omission A token bearing equivalent authorization_details but no mission claim is governed by no Mission state, revocation, or consent commitment. , , and address this downgrade at issuance, at the client, and at enforcement. A held ordinary credential needs no request to the AS, and neither an AS nor a resource server can generally tell that a request made with one serves a Mission. An unmediated ordinary workflow at a resource that is not Mission-governed therefore remains a residual that only the client's own conformance closes; the Mission Security Model () analyzes that path and where mediation closes it. The integrity of the mission_bound_authorization_supported () and mission_bound_authorization_required () metadata rests on the retrieval protections of and , whose security considerations apply.

Compromised or Over-Broad Derivation The AS is trusted to derive authority no broader than the Mission Intent. Both Authority Set derivation modes (), a proposal narrowed to policy and a configured mapping, are mechanical rather than free-form inference. Where recorded, policy_version makes each Authority Set derivation auditable by naming the policy it ran under.

Agent-Specific Threats

Prompt Injection and Data Exfiltration This document assumes that an agent reading attacker-influenceable content can be prompt-injected. Authority is fixed at the approval event, so injected text cannot expand an approved Mission. The purpose member supplies candidate authority only as a lookup key of the pre-approval Authority Set derivation whose result the Approver reads and consents to, and otherwise can only refuse or tighten; goal and task_bounds bound it only through that disclosure (, ). Within an approved Authority Set, an injected agent can still read what the Mission permits and write to a sink the Mission permits: a Mission governs actions, not the content that flows within an authorized action. The Mission Security Model () analyzes that residual; constraining it is the runtime layer's role (), and even there it is bounded, not closed: preventing misuse of data within the authorized scope needs an information-flow layer this document does not define.

Authority and Propagated Information Issuance gating bounds escalation by token acquisition (, ), and the same bound holds for information: an agent can inherit another agent's knowledge, but not its authority. A work product of one Mission is input, not authority, to an agent under another Mission, which acts on it only under its own Authority Set. Independent Missions communicating through shared state can still compose individually acceptable actions into behavior no single Mission authorized; the Mission Security Model () analyzes that coordination.

Enforcement Boundaries

Issuance Scope and Runtime Enforcement This document governs Authority Set derivation and the issuance of authority: it bounds what authority a Mission yields, binds it to the Approver's consent, and gates every issuance on Mission state. It does not evaluate individual runtime actions. In particular, it does not:

evaluate a request's parameters against the Mission at the point of use;
produce runtime enforcement evidence for each consequential action;
bind tool or function identities to the Mission; or
re-evaluate at execution time to close the approval-to-execution (time-of-check to time-of-use) gap.

Within a token's lifetime, an active Mission can therefore become ambient authority for individual consequential actions. Short token lifetimes and narrow authority bound this exposure but do not eliminate it. A deployment can use Missions for issuance alone. A runtime layer (), out of scope for this document, evaluates each consequential action against the Mission, with parameter binding, and records evidence for the actions it covers. A deployment adds one for an action class that needs any of the following, which issuance-time bounds alone do not provide:

per-action evaluation or evidence;
approval bound to a single action; or
a bound the receiving resource server cannot enforce.

Where the resource server or a composing runtime layer matches an operation target against a prefix entry, the Resource Boundary Canonicalization analysis of the Mission Resource Access Profile () gives the single-normalization rule for that match, for a deployment that supports that type. Short-lived access tokens are this document's issuance-only recommendation: with no runtime layer, token lifetime is the revocation-latency bound at unmodified resource servers. Where a runtime layer covers the high-consequence classes with an active freshness source, the point-of-use decision is the revocation cutoff, and lifetimes can be sized by action class without losing that cutoff (). An extended lifetime is appropriate only for a token whose carried entries are all on runtime-gated paths. Classes attach to entries while exp attaches to the token, so a single ungated entry takes the extended lifetime as its revocation latency. Narrowed, single-audience tokens () keep gated and ungated authority from sharing one long-lived token.

Denial Detail Disclosure The mission_denial attribute and the insufficient_user_authentication challenge () each tell a caller which path a denial leads into, and so reveal authorization shape. An insufficient_user_authentication challenge confirms to the presenting party that the authority exists and only the Subject's authentication is weak or stale, while mission_denial: insufficient_authority denies that the authority exists. Introspection guards the same class of fact behind caller authorization (), and limits the attribute to a token holder that the deployment permits to learn the distinction. Of the two values, insufficient_authority reveals least, and omitting the attribute reveals nothing.

Revocation Authority A deployment's policy can authorize no party to request a Mission's revocation (). Under such a policy no external party can request revocation, so containing a Mission depends on its expiry and on any termination the deployment's policy drives. No role, such as the Subject, the Approver, or an administrator, gains revocation authority by default, and the policy's choice does not remove the Mission Issuer's token-independent revocation means.

Credentials and Delegation

Token Theft Derived tokens are sender-constrained (DPoP or mTLS ) where and require it. A designation () carries no confirmation key: like an authorization code issued to a client that authenticates, it is bound to the client that redeems it, which authenticates to do so (), and it authorizes no resource access. A stolen designation is therefore useless without that client's credentials. A stolen token is bounded by the Authority Set and the Mission lifetime regardless, but sender-constraint prevents replay by a different party.

Delegation and Chain Compromise Delegation () widens the set of parties holding Mission-derived authority. Because authority only narrows down the chain, a compromised actor can act only within its narrowed authorization_details, for the lifetime of the token it holds. The following limit this exposure:

The per-entry delegation constraints (delegability, max_depth, and allowed_delegates, ) bound it at approval time. The max_depth constraint bounds the length of a delegation chain, not its breadth: only allowed_delegates bounds fan-out to many distinct depth-1 delegates.
Binding each delegated token to the delegate's own key () confines a compromised delegate to its own credential.
Short derived-token lifetimes (), and marking delegable only the entries that need delegation, keep it small.

Audience replay into the exchange is a distinct path: a Mission-bound token obtained by or issued to one party, presented as a subject_token, could be exchanged for a fresh delegated credential bound to the presenter. The following gates bound it:

the exchange is a derivation gated on Mission state;
the AS applies delegation-authorization policy at every exchange ();
the result is bound to the authenticated delegate's own key and narrowed by the subset rule; and
a no-actor exchange is accepted only from the Mission's approved agent ().

Designation () closes the remaining gap: a delegated exchange accepts only a designation naming the authenticated requesting client, which only the token's holder obtains, by proving possession of the token's key, so a token obtained from an audience is refused there. Sender-constraining a non-delegated Mission-bound access token () likewise keeps a stolen token from being designated or self-exchanged.

Composition and the Effective Ceiling Delegation depth () resets at each cross-domain hop () and in each Mission created from an existing Mission's authority (), so the authority a Mission's descendants can reach can exceed what a single approval appears to bound at consent time. Where that apparent bound must hold in practice, a deployment can impose a global cap out of band; the Mission Security Model () analyzes the composition.

Client Attribution and Delegation Lineage Because this document keeps the ordinary meaning of the client_id claim (), a generic resource server, or a logging, SIEM, or audit pipeline, that keys attribution on client_id attributes a Mission-derived token, delegated or not, to the correct requesting client. Such a component cannot see the delegation lineage in the act chain () or the Mission's originally-approved agent, which is recorded in the Mission Record (), not in client_id. An existing component that authorizes or logs solely from client_id needs review for this gap before it receives delegated Mission-bound tokens; states what a resource server may not infer or route on client_id.

Signing and Key Rotation The mission claim and authorization_details are covered by the AS's signature on the JWT, so their integrity reduces to the AS's signing key, whose publication and rotation specifies. Verification for audit outlives validity: keeping a key resolvable for the audit horizon () of every Mission whose tokens it signed lets an auditor verify those tokens later. A companion that anchors a longer-lived artifact to the same keys states its own retention bound. Revocation for a known or suspected compromise is distinct from routine retirement: the issuer publishes the compromised key as revoked, or marks it with a compromise time, rather than only rotating it out. A compromised issuer signing key voids every guarantee the signature carries. Holding issuer signing keys in non-exportable, HSM- or KMS-grade custody with dual-controlled generation reduces that risk. Segmenting keys by artifact class under distinct kid values within the one jwks_uri lets high-value, low-volume signing (long-lived evidence and portable artifacts) sit under stricter custody than high-volume token signing. Verification is kid-indexed, so this needs no wire change.

Privacy Considerations The privacy considerations of , , and apply to this document, as do those of for introspection and for delegation. A Mission Identifier is a correlation handle. A deployment limits exposure by:

giving stable Mission Identifiers only to parties that enforce, audit, or observe that Mission;
preferring audience-scoped projections of authority where possible; and
minimizing status and introspection disclosures to authorized callers ().

Mission Identifier Correlation This document carries a single canonical Mission Identifier on every derived token. Any party that observes credentials for the same Mission, whether a resource server, a Resource AS, or an auditor spanning audiences, can correlate that activity by the Mission Identifier, and mission.issuer further identifies the issuing AS. That stable anchor lets a resource server, a cross-domain Resource AS, and an auditor bind credentials and evidence to one approved Mission. This document does not provide cross-audience unlinkability (). Audience-pairwise (or request-pairwise) Mission references, in which the issuer projects a distinct opaque identifier per audience and resolves them server-side, are the fuller mechanism for unlinkability; they work against the stable anchor, and this document does not define them. A deployment that carries the canonical Mission Identifier on the wire accepts this correlation.

Token Payload Disclosure The carried constraints and a multi-resource Authority Set disclose the shape of the task and its business bounds (for example, an amount ceiling) to every holder and every audience of a derived token. Single-audience tokens, one per resource server, minimize this: each carries only the entries the consuming resource server needs, as recommends ().

Intent Retention and Anchor Disclosure The Mission Record's Intent members (goal, task_bounds) are personal-data sinks: they carry whatever task description the user supplied, and their retention and erasure follow . The integrity anchors are unsalted commitments: a party holding a candidate Intent can confirm it against intent_hash, and a candidate proposal against proposal_hash. Over low-entropy or guessable content each anchor is therefore a disclosure channel, and deployments treat it as one when the Intent itself is sensitive.

Third-Party Data Subjects A task can be about a person who holds no Mission role: in a background check, the employer's agent queries a registrar about a candidate who is neither Subject nor Approver nor resource owner. Mission approval records the accountable Approver's authorization of the undertaking (). It is not, by itself, evidence of such a person's consent to disclosure or of any other legal basis a disclosure requires. Whether a basis is required, and what satisfies it, is deployment and legal policy out of scope for this document. Where the resource domain requires data-subject consent or another basis, that domain's own lane (the resource server, a gateway, a policy decision point, or an authorization server acting for the domain) evaluates it through its own mechanisms, such as claims gathering or a resource-domain consent artifact. That lane refuses access while required evidence is absent or invalid, and Mission authority does not override the refusal. Mission authority is not the data subject's consent either. A Mission Record can retain a verified consent reference or facts as submission_evidence (); those facts are provenance and policy input only, which the resource domain validates independently under its current disclosure policy. Third-party personal data can enter through any Intent, proposal, authority, or recorded-evidence member:

the prose members (goal, task_bounds) and purpose;
target_resources and any explicit member a companion profile defines;
any type-owned member of a proposed entry, and the derived Authority Set entries that reach tokens (); and
submission_evidence facts, including a consent reference.

Whatever the member, it:

persists on the Mission Record for its audit horizon ();
concentrates at the AS with the record (); and
if committed, is confirmable through the unsalted anchors by any party holding a candidate value ().

Referencing a third party through resource-scoped or pseudonymous identifiers, rather than identifying prose, minimizes this exposure. An opaque identifier is minimization, not anonymity, and personal-data obligations follow it.

Mission Record and Evidence Access The Mission Record concentrates the task, its authority, and its principals at the AS. Every evidence artifact joins on the Mission Identifier, so the join is a correlation surface equal to the identifier itself. Tokens carry references and authority, not the record: this document puts no goal, task_bounds, or other Intent content in a credential. An Intent Submission Evidence artifact can carry personal data (an originator identity, a consent reference); PAR keeps it off the front channel, and the record retains the verified facts selected for recording under the same access governance as the rest of the Mission's evidence. Access to the record and to Mission evidence is policy-governed and auditable: reading a Mission's evidence is a privileged operation, not a byproduct of holding a Mission reference. Retention and erasure are deployment policy, bounded below by the audit horizon ().

Internationalization Considerations Mission Intent prose (goal, task_bounds) is human-readable disclosure. The goal_lang member () declares the language of that prose as a BCP 47 language tag , so an approval surface can render, translate, or route it without guessing the language. Three rules apply to the declaration:

goal_lang is a syntactic declaration: the AS checks only its well-formedness (), not that the prose is in the declared language, so the tag is not a verified property of the text.
Rendering to the Approver follows the rendering rules of unchanged: client prose stays inert text in any language and any script, including bidirectional text. Where the approval surface presents a translation, the rendered disclosure is what the deployment's consent evidence records; goal_lang declares the source's language and is not a record of what was rendered.
Authority Set entries carry machine-facing identifiers (URIs, action strings, structured constraints), not prose, and this document adds no language-tagged display fields to them. Localizing how authority is explained is the approval surface's duty under , not a property of the committed set.

IANA Considerations

OAuth Parameters Registration This document requests registration of the following in the "OAuth Parameters" registry:

Parameter name: mission_intent
Parameter usage location: authorization request
Change controller: IETF
Specification document(s): this document,
Parameter name: mission_id
Parameter usage location: token response
Change controller: IETF
Specification document(s): this document,
Parameter name: mission_error
Parameter usage location: token response
Change controller: IETF
Specification document(s): this document,
Parameter name: mission_expires_at
Parameter usage location: token response
Change controller: IETF
Specification document(s): this document,

PAR carries authorization-request parameters without a distinct usage location, so the pushed submission of mission_intent needs no separate registration. The mission_error member is carried in the token-endpoint error response, for which "token response" is the registry's applicable usage location. It uses the error response's JSON extensibility rather than defining a new error code. The mission_denial attribute uses the extensible auth-param space of the WWW-Authenticate scheme (, ), for which no IANA registry exists; no action is required for it.

OAuth Extensions Error Registration This document requests registration of the following in the "OAuth Extensions Error" registry :

Error name: invalid_mission_intent_evidence
Error usage location: authorization code grant error response, token error response
Related protocol extension: Intent Submission Evidence ()
Change controller: IETF
Specification document(s): this document,

A code distinct from invalid_request lets a client tell a malformed submission from missing or untrusted evidence, and remedy each differently.

JSON Web Token Claims Registration This document requests registration of the following in the "JSON Web Token Claims" registry:

Claim Name: mission
Claim Description: Reference to the Mission a token was derived under.
Change Controller: IETF
Specification Document(s): this document,

The mission claim () references a Mission, the authorization object this document defines. It is distinct from AAuth's mission_s256 claim (), the SHA-256 digest that identifies an AAuth mission, and from the agent's mission that names, the purpose this document translates into authorization. The two claim names do not collide in that registry.

OAuth Token Introspection Response Registration This document requests registration of the following in the "OAuth Token Introspection Response" registry ():

Name: mission
Description: The Mission a token was derived under, with its current lifecycle state when returned by the Mission's issuer ().
Change Controller: IETF
Specification Document(s): this document,

OAuth Authorization Server Metadata Registration This document requests registration of the following in the "OAuth Authorization Server Metadata" registry ():

Metadata Name: mission_bound_authorization_supported
Metadata Description: Boolean indicating that the authorization server supports the Mission Issuer core surfaces of this document.
Change Controller: IETF
Specification Document(s): this document,

OAuth Protected Resource Metadata Registration This document requests registration of the following in the "OAuth Protected Resource Metadata" registry ():

Metadata Name: mission_bound_authorization_required
Metadata Description: Boolean indicating that the protected resource accepts only Mission-bound tokens.
Change Controller: IETF
Specification Document(s): this document,

Mission Lifecycle States Registry IANA is requested to create the "Mission Lifecycle States" registry. The registration policy is Specification Required . A Designated Expert reviews a submission for the discipline requires:

a Value matching ^[a-z][a-z0-9_]*$ not already registered;
a Terminal value of no, consistent with the transitions the registrant's specification defines (a no state admits a further transition; terminated is the one terminal state, and a further way for a Mission to end is a termination reason, ); and
a Semantics sentence precise enough to distinguish the state from every registered state.

Whether a Mission in any state is available for reliance is fixed by the governing rule below, never per row. Only the exact value active permits token derivation or continued reliance; a consumer treats every other value, including one it does not recognize, as non-active and never widens on it (). A Designated Expert MUST reject a registration whose governing specification attempts to redefine this interaction rather than adding a new value bound by it. Each registration records:

Value: the lifecycle state's string value.
Terminal: yes if the state admits no further transition, no otherwise.
Semantics: one sentence stating what the state means and, for a non-terminal state, what a Mission in that state cannot do.
Change Controller: IETF, or the registrant for any other registration.
Reference: the specification defining the state.

This document seeds the registry with the states it defines: Mission Lifecycle States registry: initial contents

Value	Terminal	Semantics	Change Controller	Reference
`active`	no	The only state from which tokens are derived.	IETF	this document,
`terminated`	yes	The Mission has ended; its `termination` gives the reason.	IETF	this document, ,

Each further document that defines a lifecycle state requests that state's registration in its own IANA considerations. A Designated Expert MUST reject a further state registered as terminal: a further way for a Mission to end is a termination reason ().

Mission Termination Reasons Registry IANA is requested to create the "Mission Termination Reasons" registry. The registration policy is Specification Required . A Designated Expert reviews a submission for:

a Value matching ^[a-z][a-z0-9_]*$ not already registered;
a Semantics sentence precise enough to distinguish the reason from every registered reason; and
a Members list naming each further termination member the reason defines () with its presence (REQUIRED, CONDITIONAL, or OPTIONAL).

A reason never makes a Mission available for reliance: every terminated Mission is non-active, whatever its reason (). Each registration records:

Value: the termination reason's string value.
Semantics: one sentence stating how the Mission ended.
Members: the further termination members, or "none".
Change Controller: IETF, or the registrant for any other registration.
Reference: the specification defining the reason.

This document seeds the registry with the reasons it defines: Mission Termination Reasons registry: initial contents

Value	Semantics	Members	Change Controller	Reference
`revoked`	An authorized party revoked the Mission, or the deployment's policy terminated it ().	none	IETF	this document,
`expired`	The Mission's `expires_at` passed; `terminated_at` equals it.	none	IETF	this document,

Each further document that defines a termination reason requests that reason's registration in its own IANA considerations.

Mission Intent Members Registry IANA is requested to create the "Mission Intent Members" registry. The registration policy is Specification Required . A Designated Expert reviews a submission for:

a Name not already registered by a different owning specification; and
a Semantics sentence naming what the member means and which specification defines its schema, production, and enforcement in full.

The registry resolves ownership of a short top-level name, so that two independently implemented specifications cannot assign it incompatible schemas. Registration defines no member semantics and confers no authority (). A companion profile can instead use a collision-resistant name without registering it. Each registration records:

Name: the member's top-level key in the Mission Intent.
Status: stable or experimental. An experimental entry's owning specification has not completed that specification's own promotion criteria for the member. A Designated Expert MUST NOT register a member as stable without confirming that its owning specification's promotion criteria are met, and MUST NOT treat registration itself as a promotion event for an experimental member.
Semantics: one sentence stating what the member means and pointing to the section that fully defines it.
Change Controller: IETF, or the registrant for any other registration.
Reference: the specification defining the member.

This document seeds the registry with the members it defines itself: Core-defined Mission Intent members

Name	Status	Semantics	Change Controller	Reference
`goal`	stable	The Mission's plain-language objective.	IETF	this document,
`goal_lang`	stable	BCP 47 language tag for `goal`.	IETF	this document,
`target_resources`	stable	Client-requested derivation ceiling and configured-mapping lookup key.	IETF	this document,
`task_bounds`	stable	Non-machine-readable prose bounds on the task.	IETF	this document,
`purpose`	stable	URI identifying the task's purpose.	IETF	this document,
`expires_at`	stable	Requested Mission expiry ceiling.	IETF	this document,

Each further document that defines a Mission Intent member requests that member's registration in its own IANA considerations.

References Normative References OAuth 2.0 Client Instance Identifiers Independent This specification defines an optional claims profile of OAuth 2.0 Attestation-Based Client Authentication. When selected, the profile requires an attester-assigned client instance identifier, scoped by default to the server that validates it, that remains stable across verified key changes, and adds continuity and privacy rules for that identifier. Conveying instance context in tokens and introspection responses remains optional within the profile. Authentication and proof methods follow the base specification. OAuth 2.0 RAR Metadata and Error Remediation Raiffeisen Bank International OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. OAuth Actor Profile for Delegation Independent This document defines a common representation of delegated actors in OAuth JSON Web Token (JWT) assertion grants, JWT access tokens, and Transaction Tokens. It profiles the act claim defined by OAuth 2.0 Token Exchange, requires issuer-scoped actor identifiers, and uses the sub_profile claim to classify actor entity types. It specifies token processing, delegation-chain propagation, sender-constraint handling, and discovery metadata, so that issuers and resource servers in different trust domains interpret delegated actors consistently. Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Tags for Identifying Languages This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Federal Information Processing Standard, FIPS Naming Things with Hashes This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. The I-JSON Message Format I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework: Bearer Token Usage This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] Proof Key for Code Exchange by OAuth Public Clients OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. OAuth 2.0 Token Exchange This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. JSON Canonicalization Scheme (JCS) Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Resource Indicators for OAuth 2.0 This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. OAuth 2.0 Pushed Authorization Requests This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. OAuth 2.0 Authorization Server Issuer Identification This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". OAuth 2.0 Rich Authorization Requests This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. OAuth 2.0 Demonstrating Proof of Possession (DPoP) This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. OAuth 2.0 Step Up Authentication Challenge Protocol It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. Best Current Practice for OAuth 2.0 Security This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. OAuth 2.0 Token Introspection This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. OAuth 2.0 Authorization Server Metadata This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. OAuth 2.0 Protected Resource Metadata This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. OpenID Connect Core 1.0 incorporating errata set 2 OpenID Foundation Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Workload Identity in a Multi System Environment (WIMSE) Architecture Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. OAuth 2.0 Token Revocation This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. Subject Identifiers for Security Event Tokens Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. OpenID AuthZEN Access Request and Approval Profile 1.0 OpenID Foundation AI Identity Management System Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. AAuth Protocol OAuth 2.0 Client Attester Endorsement Independent OAuth 2.0 Attestation-Based Client Authentication requires an authorization server to trust the attester that makes statements about a client instance, but does not define how a client identifies the attesters authorized to attest for it. This specification defines a client metadata parameter, usable by registered clients and in Client ID Metadata Documents, that names the endorsed attesters and the locations of their verification keys. It defines how an authorization server validates endorsements and processes their withdrawal while retaining control over whether to trust them. It introduces no new credential or client authentication method. Mission Status and Lifecycle for OAuth 2.0 Mission Cross-Domain Projection for OAuth 2.0 Mission Approval Governance An Architecture for Mission-Bound Authorization Mission Substrate Requirements Mission-Bound Runtime Enforcement Mission Security Model Mission-Bound Runtime Enforcement: AuthZEN Profile Mission Consumption Metering Mission Intent Submission Evidence for OAuth 2.0 Mission Approved-Set Verification for OAuth 2.0 Mission Intent Shaping Mission Deferred Approval for OAuth 2.0 Mission Resource Access Profile for OAuth 2.0

End-to-End Example This appendix follows one Mission in a single trust domain through Mission creation, token issuance, resource server enforcement, a refusal, and revocation. It is illustrative and adds no requirements. The OAuth steps follow this document. Identifiers are illustrative; the hash values are computed over the displayed objects (). The OAuth flow of Stages 1 to 4, and the revocation in Stage 5, use only this document and the mission_resource_access type (): the baseline issuance path, with enforcement from the token alone, bounded by token lifetime. Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in the home ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-.

Stage 1: Mission Creation The following example shows the Submission envelope the agent pushes through PAR (), carrying the Mission Intent and no evidence: In the same push, the agent proposes concrete authority on the authorization_details parameter (): Both are parameters of one pushed authorization request (), with PKCE (); client authentication is omitted, and extra line breaks are for display purposes only: The AS returns a request_uri: and the agent sends alice's user agent to the authorization endpoint with it: The AS (as.example.com) validates both, derives this Authority Set under a declared narrowing capability (each entry a same-type subset of a proposed entry, , ), and renders it for alice's consent: The user alice approves at 08:00:00 UTC on 2026-11-02, and the AS records Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- in the active state with authority_hash sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM, intent_hash sha-256:6T-7s_f-mNW9UpfrrZh3r0HRJmU4My_EsNAf1C1U4r0, and proposal_hash sha-256:p-s-EzdNQTn6RoPHXESkwVtGdk8yL1PxryNyMwroKGo.

Stage 2: Mission-Bound Token Issuance At 08:00:05 the agent redeems the authorization code with its PKCE verifier and a DPoP proof (): The AS resolves the Mission from the grant (), checks that it is active (), and issues a Mission-bound access token for the ERP and a refresh token. The token response carries the granted authorization_details echo () and the mission_id and mission_expires_at response parameters (): The following is an example of the decoded access token payload: The token's authorization_details claim carries the same two entries as the token response's echo. The token carries everything enforcement needs: the audience, the sender constraint (the cnf claim), the authority with its constraints, and the mission claim naming the Mission it was derived under. Its 300-second lifetime ends well before the Mission's expires_at. Revoking the Mission stops further derivation, but this token remains valid until its own exp ().

Stage 3: Resource Server Enforcement The agent calls the ERP resource server (erp.example.com) with that token. The resource server:

validates the JWT and verifies the request's DPoP proof against the key identified by the token's cnf claim;
enforces the authorization_details entries whose resource matches the operation target, https://erp.example.com, permitting invoices.read within the Q3 issuance window and journal-entries.write up to the max_amount ceiling of 500.00 USD (); and
treats the mission claim as audit and correlation context, making no call to the AS.

With enforcement from the token alone, the consequential journal-entries.write is bounded only by token lifetime and the carried constraints. At 08:14:00 the agent refreshes for a write-only token, narrowed to the journal-entries.write entry, as the refresh example in narrows to the read entry.

Stage 4: Resource Server Refusal The agent then asks the ERP to post a 780.00 USD adjustment with the same write-only token. The amount exceeds the entry's max_amount of 500.00 USD, so the ERP refuses it from the token alone as outside the carried authority (). This deployment accepts the agent learning that more authority needs a new approval or an expansion (), so the challenge carries mission_denial: A fresh token from the same Mission does not help: every token it derives is a subset of the same Authority Set ().

Stage 5: Revocation At 08:50:00 the agent refreshes for the read-only token of the refresh example in , which expires at 08:55:00. At 08:53:20 the Mission is revoked, and the AS commits terminated with reason revoked. Revocation stops the Mission at the issuer (). A later refresh is refused with the mission_error diagnostic (): Introspection reports the 08:50:00 token inactive with the Mission's termination, although the token has not expired (, ). Revocation does not recall the token already issued. The ERP, enforcing from the token alone, can honor the read-only token until its exp at 08:55:00. A resource server that introspects at the issuer on every request stops honoring it on its next request.

Deployment Choices The following table lists the choices this document leaves to a deployment, who makes each, and, for each party that needs to learn it, the existing signal, if any, from which that party learns it. A signal serves only the party entitled to read it: a client treats an access token as opaque (), so a token's header and claims are resource-server signals. Where no signal exists, the table says so, and the party relies on the deployment's documentation or configuration. The cited sections govern. Deployment choices and how each party learns them

Choice point	Decided by	Who learns it, and how
Access-token format: JWT or opaque reference token ()	AS	Resource server: a JWT's `typ` header parameter value `at+jwt` (, ); no in-band signal marks an opaque token, which it resolves as its deployment arranges (). Client: none; it treats every access token as opaque
Introspection, and issuer-local resolution of an opaque token (, )	AS	Resource server: the `introspection_endpoint` AS metadata (); for issuer-local resolution, none, since the AS authorizes each reader inside its trusted implementation boundary
Sender constraint: bearer, DPoP, or mTLS ()	AS, on the client's proof, if any	Resource server: the token's `cnf` claim, or the `cnf` member of an active introspection response (, ). Client: for DPoP, the binding applied to the issued token, from `token_type` `DPoP` in the token response (); for mTLS, the AS's mTLS metadata () states only that the AS supports certificate-bound tokens, and no token-response member says a given token is bound. A resource's DPoP requirement or mTLS support comes from its protected resource metadata (), which also states support, not the binding of a given token. Settled for delegation: a designation is requested with a sender-constrained token, and a delegated token is bound to the delegate's own key (, )
Authorization-code binding: PKCE `S256` or a DPoP-bound code ()	Client, among the methods the AS accepts	AS: the request's `code_challenge` (), or its `dpop_jkt` parameter or DPoP proof (). Client: the `code_challenge_methods_supported` () and `dpop_signing_alg_values_supported` () AS metadata
Refresh-token binding: client authentication, sender constraint, or rotation ()	AS	Client: under rotation, a new refresh token in each refresh response (); for a DPoP binding, none beyond its own proof when it obtained the refresh token ()
Mission support ()	AS	Client: the `mission_bound_authorization_supported` AS metadata; otherwise, out of band
Supported types and their schemas ()	AS; each resource server, for the types it accepts	Client: the AS's `authorization_details_types_supported` metadata () and, where advertised, its types metadata endpoint (); a resource server's `authorization_details_types_supported` metadata ()
Derivation mode: authority proposal or configured mapping ()	Client, by proposing or not; deployment, by configuring mappings	Client: no metadata signal; the deployment publishes its mapping space as deployment documentation
Transformation capabilities per type: `narrowing`, `delegation`, `projection` ()	AS operator, per type	Client, in order of preference: a `mission_transformation_capabilities` member in the type's entry at the types metadata endpoint, an equivalently shaped member of supported-type documentation, or deployment documentation. Resource server: none needed; it enforces entries as carried (). Settled: the first carrier that declares a member governs, and a declared `narrowing` also governs Authority Set derivation
Each entry's audience ()	Deployment	AS: a trusted entry-to-audience mapping, such as authenticated configuration or protected resource metadata (). Client: none; it requests an audience with `resource` and reads the granted entries from the token response ()
Scope projection for a target ()	Deployment, per target	AS: the target's protected resource metadata () or authenticated out-of-band configuration
Mission-governed resources ()	Deployment, or the resource through its metadata	AS and client: the `mission_bound_authorization_required` protected resource metadata (), which the AS authenticates; a deployment's own classification has no signal, and `false` or omission does not clear it. Resource server: its own configuration ()
Delegation support ()	AS	Delegating party and delegate: `grant_types_supported` listing the Token Exchange grant type (); otherwise, out of band or by attempt. Settled: a delegate is identified by its client authentication, an `actor_token` is refused, and a public client is not a delegate ()
Audiences that process the `act` chain ()	Deployment	AS: no protocol signal; neither parsing `act` nor `mission_bound_authorization_required` establishes it, and the AS establishes it by deployment means, for example its configuration
Designated-client separation ()	Deployment	AS: no protocol signal; the AS establishes by deployment means, for example its configuration, that no resource server accepts the client's identifier as an audience
Designation redemption count ()	AS	Delegate: no protocol signal; the AS's policy governs, and deployment documentation may describe it. An attempt reveals only its own outcome, not the permitted count
Subject-authentication conveyance ()	Deployment	Resource server: the `acr`, `amr`, and `auth_time` claims (), or introspection (); where no Subject authentication applies, they are absent
Revocation means ()	Mission Issuer, for the means; the deployment's policy, for who may revoke	A party authorized to revoke: none in this document; a deployment-defined surface

Design Context and Boundaries This appendix records what this document leaves to other work and explains one design choice: how a delegated token identifies its client.

Scope This document is self-contained: it binds Missions to OAuth 2.0 and depends normatively only on the specifications listed as its normative references. Its reference to the OAuth Actor Profile (), for the act chain shape the optional Delegation capability uses, is normative and binds only a deployment that claims Delegation, so the mandatory single-domain core does not depend on it. The companion Mission Cross-Domain Projection profile specifies cross-domain projection, a single hop that lets an authorization server in another trust domain honor a Mission, and carries the identity-chaining and Identity Assertion JWT Authorization Grant (ID-JAG) dependencies. The Cross-Domain capability's conformance bar is self-contained in this document (), so that companion is not a normative dependency. This document defines no mechanism that pins a Mission to an approved agent deployment class or version, and reserves no Intent member for one. Such a pin needs two objects, not one Intent member: a committed approval-context pin, and presenter-instance evidence checked at every derivation (for example, using and ). A profile that defines the pin also defines:

its request carriage and resolution to an approved deployment identifier;
its Mission Record extension and approval rendering; and
its fail-closed behavior when the client cannot prove the pin.

This document defines no cumulative consumption bounds (for example, a budget, call-count, or activity-duration cap). An experimental companion () defines them as explicit Mission Intent extension members, together with the runtime metering that enforces them.

Non-Goals The following are out of scope for this document:

Semantic / intent verification. This document does not evaluate whether a runtime action serves the Mission's purpose beyond matching the approved authorization_details and constraints; per-action evaluation is the runtime layer's role (). Verifying an agent's declared reasoning against the task is a further attestation problem outside both layers.
Joint outcome and cross-resource effects. Whether the actions taken under a Mission jointly accomplish its task is out of scope, as are the ordering, timing, atomicity, and compensation of their effects across resource servers. The mission claim joins requests to an approval for issuance and audit; it does not identify a business transaction.
Approval-free authorization upgrade. The Authority Set is committed at approval, and this document defines no mid-stream widening that bypasses consent. Widening requires a new approval ().
Lifecycle event distribution. A resource server learns Mission state from the token lifetime or optional introspection (); this document defines no push-based notification of Mission state changes.
Human-in-the-loop suspension. The base lifecycle is active and terminated (). A pending-human-approval state and a holding-token pause-and-resume protocol are future lifecycle work.
Multi-hop cross-domain projection. Re-projecting a Mission from one Resource AS into a further domain is future work.
Decentralized agent identity. Agent identity and credentialing are out of scope ( and the WIMSE architecture, ); this document governs the approved-task artifact those identities act within, not the identities themselves.
Cross-audience unlinkability. A single canonical Mission Identifier lets any party holding a token correlate a Mission's activity across audiences and resources. The authority_hash anchor is not part of that baseline correlation surface: it stays on the Mission Record and the audit and profile surfaces that carry it by disclosure privilege (, ), not on every token by default. Pairwise or unlinkable presentation of Mission-bound authority works against the identifier and is therefore future work ().

Client Identification in Delegated Tokens This document keeps the registered meaning of the client_id claim, stated normatively in and enforced in : the OAuth client that requested the token, on every issued or derived token, a delegated one included. Downstream delegates are named in the act chain (), and the Mission's originally-approved agent remains recorded in the Mission Record (). The alternative, fixing client_id to the approved agent on every derived token, would lead a generic resource server or logging pipeline to misattribute a delegate's action to the approved agent, with no error to surface the mismatch. It would be safe only where every resource server already processes the act chain, and Mission awareness alone does not establish that (). The routing rule of does not depend on this choice. The mission claim's presence signals that a token may carry an act chain a consumer needs to process. A Mission-unaware resource server cannot opt into that processing, so routing a delegated token to one is forbidden.

Integrity Anchor Test Vectors These non-normative vectors let an implementation verify its anchor computation (, ) byte for byte. All use the issuer https://as.example.com. Each canonical-bytes block is the exact JCS output: a single line of UTF-8 with no whitespace outside string values. It is wrapped here for layout only; removing the line breaks, and adding no characters, recovers the canonical form. JCS sorts object member names and preserves array order. In these vectors, iss precedes typ precedes value; within an entry, actions precedes constraints precedes resource precedes type; and within max_amount, amount precedes currency. intent_hash, over this Mission Intent as the envelope value with typ mission-intent: Canonical bytes of the envelope: authority_hash, over this Authority Set as the envelope value with typ mission-authority-set: Canonical bytes of the envelope: The next two vectors exercise an additional flat Intent member beyond target_resources, and an Authority Set entry whose delegation.allowed_delegates is an array of matcher objects. JCS preserves the array's order, so the sub_profile matcher stays before the sub matcher. intent_hash, over this Mission Intent as the envelope value with typ mission-intent: Canonical bytes of the envelope: authority_hash, over this Authority Set as the envelope value with typ mission-authority-set: Canonical bytes of the envelope: The next vector exercises the third anchor: proposal_hash, over this submitted authorization_details proposal as the envelope value with typ mission-proposed-authority (): Canonical bytes of the envelope: The last vector is the entry commitment (), computed over one immutable Mission-record Authority Set entry, not an issued or narrowed token projection. The entry commitment, over this entry as the envelope value with typ mission-authority-entry: Canonical bytes of the envelope: An implementation that canonicalizes the same value under the same typ and iss, computes SHA-256, and encodes as sha-256: followed by base64url with no padding () reproduces these anchors exactly. A divergence indicates a JCS or encoding difference to resolve before interoperating.

Document History [[ To be removed from the final specification ]] -02 Behavior changes

The legacy Mission-state reading is removed: revoked, expired, completed, superseded, and cascaded are no longer read as a state (#1504).
An intentional normative relaxation: the -01 standing-consent requirements (approved_at, policy adjudication, Activation Policy Commitment, Standing-Consent Recency) move to Approval Governance, which the profiles defining standing-consent bases adopt; Mission-Creating Paths keeps the basis type, activation semantics and recorded activation members (#1915, #1967).
Mission Record: its required members are named, policy_version and the direct activation members become optional, and an omitted integrity anchor is implied from the retained record (#1912, #1917).
Approval: the AS allocates approval_event_id (#1915); a commit past the effective expiry is refused with access_denied (#1721); the rendering attributes client text to the client (#1532).
Issuance: no token outside a Mission for a Mission-governed resource, and only entries whose approved audience includes the token's, each refused with invalid_target (#1503); transformation-capability precedence and validation (#1377, #1720); mission_id and mission_expires_at on a new Mission's first response and on a delegated exchange response (#1719).
Delegation: client authentication by a method the AS relies on, refusing others with invalid_client and an actor_token from an authenticated client with invalid_request (#1718); delegated tokens only to resource servers that process act (#1503); unsupported self-exchange refused (#1892).
Token consumption: the mission claim is reserved to Mission-binding profiles; a JWT access token follows RFC 9068 unless a profile defines its format (#1760); an unenforceable entry is refused only with insufficient_scope or the RAR remediation challenge (#1721).
Revocation: by mission_id, from a party the deployment's policy authorizes, independent of possession of any token; a Mission whose recorded Subject is deprovisioned should be terminated (#830, #1892, #1895).

Structure. Sections follow processing order, with Mission Creation, Mission-Bound Token Issuance, Delegation Within a Mission, Token Consumption, and Mission Lifecycle as chapters (#1723, #1793). Applicability states the baseline. Restated rules become pointers, and existing obligations carry BCP 14 keywords, with no new requirement (#1892). Family material moves to the Architecture, the security analysis to the Mission Security Model, and companion mechanics to their profiles; companion pointers remain only at the hooks they explain (#1794, #2009). References. RFC 9110 is added as normative and the AAuth protocol as informative. No longer cited: FAPI Grant Management, the Cedar RAR draft, SPIFFE client authentication, Transaction Tokens, GNAP, the Attenuating Agent Tokens draft, RFC 8628, RFC 8935, and the Audit, Capability Binding, Child Delegation, Consent Evidence, Containment, Continuation, Cross-Organizational Delegation, Derivation Limits, Device Authorization, Expansion, Management, Mission Authority Server, Progressive, Signals, Template, and Work Products companions. -01 Breaking wire changes

mission_intent carries the Mission Intent Submission envelope, intent plus an optional typed evidence array; a bare Intent is refused, and unsupported, invalid, or missing required evidence is refused with the new invalid_mission_intent_evidence error code. PAR carries it on the authorization-code path; other grants need a companion (#1202). The authority proposal moves from the removed Intent member proposed_authority to the authorization_details parameter, committed by the new proposal_hash.
Inside a signed Request Object pushed through PAR, the mission_intent claim is the Submission envelope as a JSON object, not its serialization; any other value is refused with invalid_request (#1503).
Intent members, with no aliases (#636, #706, #117): resources is renamed target_resources and constraints task_bounds; controls is removed, its acr replaced by the acr_values and max_age parameters and its max_derivations by Derivation Limits' requested_derivation_limit. success_criteria is removed, and earlier Missions keep their recorded Intent. goal_lang is new (#534). The top level admits only defined members, a Mission Intent Members registry assigns short names, and test vectors are regenerated.
The baseline mission claim carries id, issuer, and an optional expires_at; authority_hash leaves the claim, and introspection can disclose it (#702). The Mission Record replaces approver with approval_basis.consent_principal (#705) and adds approval_basis, authority_source (#316), termination, proposed_authority, proposal_hash, and submission_evidence.
The lifecycle states are active and terminated; the -00 states revoked and expired become termination reasons, and a consumer can read a legacy state that way during a transition (#705). New registries hold lifecycle states, any further one non-terminal (#170), and termination reasons.
The token endpoint adds mission_expires_at, the effective expiry, which can precede the requested intent.expires_at, and the mission_error diagnostic; mission_id is recommended. Authorization details type metadata can declare mission_transformation_capabilities, and entry commitments use mission-authority-entry. Resource server challenges add mission_denial and use RFC 9470 insufficient_user_authentication.
A Token Exchange refuses an inactive Mission (#1154) and an invalid, unproven, or unacceptable subject or actor token (#1178) with invalid_request, unless its profile assigns a code; other grants keep invalid_grant, and DPoP proof failures use invalid_dpop_proof and use_dpop_nonce. access_denied replaces invalid_authorization_details where no authorization_details was submitted; invalid_target covers scope-projection and routing failures; and invalid_scope covers an ungrantable scope and an openid request whose Approver is not the Subject (#826).
Delegation by designation (#1268): the delegate's subject_token is a designation, which only the holder of a sender-constrained token obtains, by Token Exchange naming the delegate as audience.
Instance context no longer identifies the instance through act.sub or act.cnf: the delegate's actor identity is established separately, the top-level cnf binds the presenting key, and a deployment can convey optional client_instance context under . The instance-delegate matcher example uses the ai_agent actor type instead of the retired client_instance actor type.

Model changes. Approval separates consent_principal, activation_actor, and optional adjudication (#701): direct approval is human (#1185), approval activates only authority its source holds (#316), and standing-consent bases activate instances at their own approval events (#1078). Derivation is mechanical. purpose selects configured mappings; its other uses, and model output, only refuse or narrow (#1102). Each grant lineage binds to one Mission, never through consent reuse (#700, #1259). Authority is type-agnostic, with scope projection; opaque tokens use introspection or issuer-local resolution (#1203). Submission processing checks a proposal before evidence, refuses with the earliest failing step's error, and completes Authority Set derivation before the rendering (#1411); the Mission-governed client rule reaches only authorization requests (#1448); delegation policy crosses a cross-domain projection where that profile's provenance rule keeps it (#1374). An unrecognized authority_source.type stays opaque provenance and does not deactivate the Mission, though no Mission is approved from a source the AS does not recognize, and an authority_source.policy digest follows the construction and issuer its policy format defines (#1503). Moved to companions. Resource Access (the mission_resource_access type, Common Constraints, tool modeling, and mission_constraints_supported; #637, #645, #698); Intent Submission Evidence (the verification framework; evidence stays); Approved-Set Verification; Derivation Limits (with derivations_remaining); Metering's Intent members; and Approval Governance's assertion rules. Security and privacy. Delegation hardening and no authority from an entry a resource server cannot fully enforce (#1258); Approver authentication kept off derived tokens and out of OpenID Connect results for another Subject (#826); task credentials that are Mission-bound or covered by a trusted enforcement path (#1205); refresh tokens bound per client type (#1204); issuer-checked Mission resolution (#725); third-party data subjects (#344); key retention to the audit horizon; a resource server accepts a mission claim only from an issuer it trusts for Mission-bound authorization, with mission.issuer equal to iss outside an adopted cross-domain profile; the approval rendering identifies the receiving client from information the AS trusts; a refresh request beyond its grant is refused, never trimmed (#1503); and the approval basis named as outside the integrity anchors, with the profiles that commit it (#1518). Editorial and structure. The reading path (#910, #1379); readability, placement and consolidation passes (#876, #1409, #1447, #1472, #1479, #1483, #1490, #1501, #1526), with the issuance rules gathered under Mission-Bound Access Tokens, "Mission Lifecycle and Gating" retitled "Mission Lifecycle", resource classification named "Mission-governed resource" (#1503), and one Standing-Consent Bases section; the error-table detail for a configured-mapping refusal aligned with Derivation Modes (#1495); subsections, tables and IANA templates fitted to the text rendering (#1380, #1382, #1401, #1404, #1410, #1418); canonical-Mission examples (#1176); and the Mapping Assessment, moved from the substrate (#708). References. The WIMSE AIMS draft, the RAR metadata remediation draft, and Client Instance ID with Client Attesters replace draft-klrc-aiagent-auth, draft-zehavi-oauth-rar-metadata, and draft-mcguinness-oauth-client-instance-assertion; MCP, ISO 4217, RFC 3986, and draft-mcguinness-oauth-ai-agent-instance are removed; RFC 6750, RFC 9700, Client Instance ID, OpenID Connect Core, the RAR metadata remediation draft and, for Delegation, the OAuth Actor Profile are normative. -00

Initial individual draft.

Acknowledgments This work builds on the OAuth 2.0 Rich Authorization Requests, Pushed Authorization Requests, and JWT access token specifications, and is intended to complement agent-identity work including .