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. The authorization server (AS) issues tokens under a Mission only while it is active, each bounded by the approved Authority Set, and resource servers enforce the resulting credentials. Revoking or expiring a Mission stops further issuance and refresh but does not, by itself, invalidate an already-issued access token, which remains valid until it expires (). Agent-identity work such as establishes how an AI agent authenticates and how a user delegates authority to it. The agent is an OAuth 2.0 client identified by client_id, the delegating user is the access token sub, and the agent obtains tokens for the resources its task requires. That work leaves out of scope:

how an agent's task (its "mission") is translated into authorization;
how a user's approval of that task is captured as a durable artifact; and
how later token issuance stays bound to what the user approved.

OAuth does not define a task record that links approval of a task to every grant obtained for it. Without that linkage, withdrawing task approval need not stop issuance under those grants. No existing OAuth object fills that role (); an authorization_details entry (), for example, expresses authority but not the task it serves or a lifecycle of its own. A Mission, held by the AS beside the grant, does. It commits the disclosed task with its approved authority and has an identifier and a lifecycle independent of any grant. It can be revoked by that identifier through an authenticated means, independent of possession of any token (), and a token derived from it by Token Exchange identifies the same Mission (). A Mission is created and used in a single chain:

Submit. The client submits a structured Mission Intent describing the task (goal, target resources, task bounds) instead of requesting raw scopes, optionally proposing concrete authority alongside it as standard authorization_details.
Derive authority. The AS derives authorization details (), the Authority Set: the concrete authority the task needs.
Approve. At an approval event, the approval rendering shows the Intent's task, and the Approver consents to the derived Authority Set itself, not to the task description alone (). The AS commits the Mission Intent as intent_hash and the approved Authority Set as authority_hash (). It records a durable Mission whose record associates the disclosed task, the approved authority, and the approval basis ().
Bind the grant. The AS binds the OAuth grant the approval produces to that Mission, server-side (). Each later issuance operation from that grant lineage, such as a refresh, is a derivation () and resolves to exactly this Mission; the client never selects or reassigns it. Under a profile, the AS can bind a further grant lineage to the same Mission; each lineage resolves to exactly one Mission.
Issue and enforce. Every derived authority is no broader than the approved Authority Set (). Every access token the agent obtains under the Mission carries the derived authorization details and a mission claim identifying that Mission (id, issuer). A resource server enforces statelessly from the token.
Stop issuance. Token issuance and refresh are gated on Mission state: a Mission that is not active yields no further derivation (), including from any grant lineage bound to it (). Revoking or expiring the Mission therefore stops the agent from obtaining further authority.

Steps 3 to 6 state the properties this document provides; states the requirements that realize them. A user thus approves the authority for a task once, and that approval, not a per-request scope grant, bounds and outlives every token the agent derives. The Mission Record commits the consented authority once, as authority_hash; a party holding the complete Authority Set can recompute the commitment and compare the result with authority_hash (). Mission Approved-Set Verification () defines how a token that carries only a narrowed subset is checked against the complete set. This chain is the first of two enforcement layers, and a deployment can run it alone: a resource server need not be Mission-aware unless it receives delegated tokens (). A Mission-unaware resource server that authorizes only from scope operates within the Mission only where the AS establishes that its scope projection and the resource's independent controls cannot over-grant (). The chain provides task-bound issuance, auditability, and a revocation gate over future derivation. The chain does not evaluate individual actions, so token lifetime and narrow authority bound the exposure between issuance and use. The second layer, a separately specified runtime layer (), adds a per-action check for the action classes whose consequence needs one.

Implementation Map The starting path is one client, one authorization server, direct approval, and a single resource audience, with no runtime profile, delegated token, or cross-domain projection; states the complete roles and optional capabilities. The worked flow () follows one Mission along this path with concrete times. Each implementer's duties on the starting path, with the sections that define them:

Mission Client:

Submits an Intent through PAR (), optionally proposes authority (), completes the authorization-code flow, and reads the granted authority and Mission references from the response (, ). Authorization Server Metadata () holds the metadata the client reads before it submits, and the client's rules for an AS whose Mission support is not established and for a credential that is not Mission-bound.

Mission Issuer (AS):

Its duties on the starting path:

validate the submission and derive bounded authority (, );
obtain approval, commit the Mission, and bind the grant to it (, , );
gate every issuance and refresh on the Mission's state, its Authority Set, its expiry, and any emitted scope value's projection (); and
terminate the Mission on an authorized revocation ().

Mission-aware Resource Server:

Validates the credential and any sender constraint, enforces the carried authority, and applies any configured Mission requirement (, ).

This document defines no authorization_details type (). Each Authority Set entry is of a type the AS supports, such as mission_resource_access (), and a Mission-aware Resource Server enforces each applicable entry its tokens carry under that entry's type (). The following table summarizes which surfaces apply, to whom, and when; the cited sections govern. Ordinary JWT consumption does not require retrieving the Mission Record or recomputing the complete approved Authority Set. Applicability of this document's surfaces

Surface (role)	Applies	Defined in
Mission Intent via PAR (client, AS)	Mission-creating requests on the authorization-code path; companion-defined back-channel carriage follows its profile
Direct approval (AS); the Mission Record (AS)	Every direct approval event; the Mission Record at every approval event	,
Evidence dispatch and refusal (AS)	Implemented by every AS, even one that supports no evidence type; applied to each presented entry
Authority proposal (client, AS)	Optional for the client; the AS checks one that is submitted
Grant binding (AS)	Authorization-code lineages and other profile-defined reusable grants, including their refresh-token families
Issuance gating (AS)	Every derivation, refresh and Token Exchange included
Scope projection (AS)	Every issuance that emits `scope` or whose request names a `scope` value; a `scope`-only target gets a safe projection or a refusal
Sender constraint, primary and refresh tokens (AS)	Recommended for the access token, which may be a bearer token; a public client's refresh token is sender-constrained or rotated	,
Sender constraint, delegation and cross-domain (AS, RS)	The token presented for a designation is sender-constrained, and the designation carries no `cnf`; a delegated token is bound to the delegate's own key; across trust domains, as the cross-domain companion requires	, ,
Revocation means (deployment)	An authenticated revocation by `mission_id`, independent of any token
Enforcement (Mission-aware RS)	Every request the resource server serves
Introspection (AS, RS)	Optional; required for opaque tokens served without issuer-local resolution	,
Delegation, Cross-Domain (AS, client, RS)	Optional capabilities	,
Standing consent (AS)	Only under a companion profile's standing-consent basis

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 (). The direct realization creates each Mission at an approval interaction on the authorization endpoint. (Section "Mission Creation Paths") maps the paths where an administrator, or a policy a human consented to, decides without one. A Mission is intended to cover one concrete task, not an agent's whole lifetime. Narrow Missions, each separately approved and revocable, are preferred over one broad standing Mission that accumulates authority across unrelated tasks. This preference has a consent cost: many narrow Missions can create approval fatigue, and combining unrelated authority into one broad Mission can make approval difficult to evaluate. A useful boundary is a task whose purpose, authority, and bounds the Approver can evaluate together (). Optional companions can reduce repeated approvals through standing consent (): for example, a template, an authority ceiling, or a policy that a human approved once governs later Missions. The template, ceiling, or policy still needs a meaningful human approval, and no such mechanism removes its profile's human-approval requirement for high-consequence authority. The unit of governance is the action, not the content. A Mission bounds where an agent may act (resources, actions) and how much (constraints and, where metered, cumulative bounds). It does not inspect the content that flows within an authorized action: an approved egress channel carries a status update or an exfiltrated payload with equal authority. Content-level controls (data loss prevention, redaction) are complementary; under mediated execution they fit at the mediating enforcement component ().

Overview

Protocol Flow Besides the agent (the OAuth client) and the Mission Issuer (the AS), the flow involves two principals: the Subject, on whose behalf the Mission is approved, and the Approver, who approves it. defines these and the other terms. The following figure shows the protocol flow between the agent and the Mission Issuer: | 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 ]]> After token issuance, resource access and lifecycle management proceed as follows: (4) The agent calls the resource server with the token. The resource server enforces the authorization_details statelessly and can check the mission claim (), with no callback to the AS required. (5) An authorized revocation (), or expires_at passing, moves the Mission to terminated, with reason revoked or expired, after which the AS refuses further issuance and refresh. A deployment can also treat revocation of the refresh token as revoking the Mission (). The end-to-end example () walks this flow with concrete messages.

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-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. The companion Mission Cross-Domain Projection profile specifies cross-domain projection ().
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 a cross-domain grant issuance. 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 issued credential carries without itself creating a grant binding.
Mission-referenced token:: A token that carries a Mission reference (the mission claim or a mission_id) without Mission-derived authority or any gating guarantee.
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 ().

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. Across trust domains, the cross-domain companion conveys Subject identity through its own subject-resolution claims, not a Mission lookup, and a token minted in another domain preserves the mission claim unchanged (). 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. It can describe the outcomes that show the task is complete; like the rest of the prose, that description carries no machine semantics (). Maximum 4096 characters. 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. 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:

Submission via 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. 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.

intent_hash commits exactly the intent object, not the Submission envelope or its evidence array (). The AS returns a request_uri as usual, which the client uses to start authorization. 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. Submission is governed by the following rules:

Closed top levels. The AS MUST reject 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.
Carriage through PAR. On the authorization-code path, the AS accepts the Intent in one of two forms:
1. the form-encoded mission_intent parameter of the PAR request body; or
2. 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 reject with invalid_request a claim whose value is a string or any other value that is not a JSON object.
The AS MUST reject 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. 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 rejected with invalid_request, strengthening , under which the AS would only ignore such a value.
Alternative back-channel profiles. 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. Such a profile carries the envelope and any authority proposal in one request that never traverses a user agent, and preserves:
- this section's envelope and proposal rules;
- 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 ().
Support for a grant type or endpoint never establishes such a carriage on its own. The experimental Mission Device Authorization profile () defines one for a client that cannot complete the authorization-code path, on the device authorization grant .
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 verification-cost bound of accompanies these.
Concrete authority is proposed via authorization_details. 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 ().
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.
A proposal, not authority. 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 following is an example of a Submission envelope carrying a compact Intent and one evidence entry of an illustrative, deployment-defined type:

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 submitted authorization_details is a proposal, not authority (); the AS derives and bounds the Authority Set from it (). 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, and 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. Policy narrowing is distinct. During Authority Set derivation the AS MAY narrow or omit a syntactically valid entry that policy cannot accept (). The granted authorization_details in the token response reflects every narrowing and omission (). 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 it defines one, or carried through unchanged where it defines none (). goal and task_bounds then serve as rendering and bounding context over the proposed authority. 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. The carriage rules of apply to the proposal. The AS records the 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. 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 deployment classifies a resource as Mission-governed (a Mission-governed resource), its AS MUST NOT issue a token for that resource outside a Mission, except under documented policy exceptions.
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 reject the request with the invalid_request error code, so the client cannot drop the Intent from a request that still carries authorization_details. The rule applies to that request until it completes, including when the AS resumes it after an interaction. A request carrying neither is an ordinary request that this 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, a self-exchange () or an exchange for a delegation designation (), 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. The following is an example of an authority proposal submitted alongside the example Intent of . Authority Set derivation narrows invoices.* to invoices.read, 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 example Authority Set of ):

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:

Reject, 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. 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 (). Mission Intent Submission Evidence for OAuth 2.0 () specifies:

the entry convention;
required-evidence resolution;
the binding of evidence to one Intent and to the presenter;
the verification-cost bound;
where the error is returned; and
evidence on idempotent creation surfaces.

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.

Parse the Submission envelope and enforce both closed top levels ().
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").
Apply the evidence dispatch and refusal rules, verifying every presented entry under its 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, intent_hash, 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; and
an intent object that fails validation together with a malformed proposal is refused at step 2, 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 (). For example, the consent-evidence companion binds them with a submission_provenance_hash inside its committed disclosure ().

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 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, yields the candidate entries, which are then narrowed to policy. The mapping is a lookup, not synthesis. 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; standing consent to a pre-approved ceiling is the separate, experimental Mission Template profile (), not this mode.

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 (for mission_resource_access, a descendant of a prefix entry) can yield a token entry that target_resources does not name, and a candidate outside every Authority Set entry fails that rule. The Mission records the policy version in force as policy_version (). 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 (for example, the Common Constraints that defines for mission_resource_access), 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.

Derivation Policy and Open-Ended Tasks Authority Set derivation is governed by local policy and is not a portable algorithm: different authorization servers can derive different Authority Sets from the same Mission Intent, as they can grant different authority for the same request or the same scope. Interoperability begins at the derived Authority Set, whose structure and vocabulary each supported type defines (), and at its integrity anchors (). A consumer enforces the derived Authority Set, not the Intent. Audit establishes what was derived, against intent_hash and policy_version, not whether the Authority Set derivation was the right reading of the task. A deployment whose partners reason about its Authority Set derivations can publish a derivation policy identifier and test fixtures that pin Intent-to-Authority-Set outcomes. For an open-ended task whose concrete objects cannot be enumerated at approval (for example, "reconcile this customer's ledger," where the individual invoices are not yet known), the derived authority is better bounded by constraints that hold as invariants over those objects than by an exhaustive resource enumeration. Such invariants include the owning customer, the tenant, an amount ceiling, read-only except named write actions, and a validity window. The runtime layer () checks each concrete object against the constraint at the point of use. mission_resource_access is defined by the Mission Resource Access Profile (); the Authority Set carries it on the same type-agnostic terms as any supported type (). 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 (for mission_resource_access, ). 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, either a new Mission or a successor (). 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. 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, 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 runtime layer's responsibility (), 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. 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. 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 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 additive. 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.

Policy-Language Types Type-agnosticism lets policy-language profiles compose without this document defining them: for example, an entry carrying a Cedar policy set (), or an analogous AuthZEN policy entry, for an audience that evaluates it, alongside a general-purpose type such as mission_resource_access (). The AS derives such an entry from the Mission Intent and bounds it by the Intent like any other, but does not interpret the carried policy beyond its type's declared capabilities; the resource server or policy decision point (PDP) evaluates it at request time. The following is an example of an Authority Set with a Cedar policy entry for a finance audience that consumes Cedar, alongside a mission_resource_access entry for a calendar audience that does not. The Cedar policySet is abbreviated: Both entries are committed by the one authority_hash and bound to the Mission. The Cedar entry is evaluated by the finance audience's PDP; the mission_resource_access entry is enforced as in . Because the Cedar profile defines no subset or delegation rule over policy sets, the AS carries the Cedar entry as approved, so it does not appear in a delegated token or cross-domain grant. Delegation controls on other entries, such as the mission_resource_access entry, apply to those entries only. Invoking a Model Context Protocol tool or a function call is modeled as a mission_resource_access entry with no separate type; the mapping is specified in .

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.

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. 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 ().

Direct Approval Steps Steps 1 to 3 establish the Approver, the Subject and the authority source, and check the derived Authority Set against that source. Step 4 establishes the effective expiry. Step 5 renders the derived Authority Set for consent, and covers a change before the decision. Steps 6 and 7 compute the integrity anchors over the approved context and create the Mission atomically with the decision. 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 (). Refusals follow .

Preparing the Approval

Authenticate the Approver, subject to the approval-authentication floor and any client-requested strength (). 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.
Establish the Subject: the principal the task is for, recorded as the Mission's subject and mapped to the sub of every derived token (). The Subject can be a workload or organizational principal (), established and mapped the same way.
- Self-approval. When the Approver is the Subject, the Subject is the authenticated Approver.
- Another principal or an external Subject. The rules of apply at this step.
Establish the authority source: whose authority the approval draws on, recorded as the Mission's authority_source (, ). The AS MUST establish it from trusted configuration or authenticated governance state, never from client assertion. The AS MUST verify the Approver is authorized under local policy to activate the established source, and 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.
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).
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:
- The consent object is the derived Authority Set, what the agent may do, not the goal or Mission Intent: 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.
- 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.
- Mission Capability Binding () states what the rendering presents about the source binding of a catalog-sourced action.

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.
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. 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. The Mission Record is what approval leaves behind: the approved content and its commitments (the approved Mission Intent, the Authority Set, and the integrity anchors over them); the principals (the Subject, the approved agent's client_id, and the approval_basis naming who consented and how); the authority source; the issuer's provenance (the policy version and the approval event's identifier); and the Mission's expiry and lifecycle state. defines each member and when it is present.

Subject Establishment These rules apply at step 2 of the direct approval steps ().

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.

Rendering Safeguards 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, so crafted client text cannot pass as derived authority.

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. The enforcement table () summarizes which party enforces each bound and what holds when that enforcer is absent. 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 anchors the Mission records, 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.

Approval Comprehension 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 short task can legitimately have a large or varied Authority Set: an erasure request whose proposal or configured lookup () yields dozens of delete entries across resources. The consent object remains the complete derived Authority Set. The following non-normative practices can help make it reviewable:

Group entries by resource and action, so the Approver reviews kinds of authority rather than a list of entries, while keeping material differences in constraints visible: a group of identical actions still shows an entry whose resource range or consumption bound is much broader than the rest.
Summarize with drill-down: a summary covering every resource, action, and bound, with each complete entry one interaction away. A summary is a view of the set, never a substitute for it.
Surface high-risk entries: make the irreversible, external-commitment, privileged-administration, and consumption-bounded authority of prominent in the initial view, distinguishing materially different risks and bounds.
Split rather than approve: when the set is too large or varied for one decision, narrower Missions can keep each approval meaningful ().

Mission Consent Evidence () defines layered rendering of a committed disclosure, including what its first layer carries, and lets the Approver ask the basis for an entry before deciding.

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 (, ). 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 is never 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: client_id names the Agent, and delegates are carried in the act chain ().

Approver Authentication Strength A deployment publishes 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. High-risk authority means irreversible, external-commitment, or privileged-administration actions under the deployment's classification, or a consumption bound (). This document requires no particular serialization. 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 these parameters implies nothing about the authentication claims of an issued token, which 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); max_age 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. 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. 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, and an AS MUST NOT read it back from, a Mission Intent member. Where a deployment records Consent Evidence, the achieved values belong in its authentication_context member (); this document defines no Mission Record member for them.

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 ().

Where a deployment needs either, the Approval Governance Record () records it, and Consent Evidence can carry a partial presentation of that record through co_approvals and its approval-governance members (). The adjudication.governance_record member () marks an approval such a record backs, and shows how each scenario assigns the three approval_basis roles.

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 the Subject, Approver, or policy terminated it, 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); only active permits issuance. 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 never changes 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. For a transition period, a consumer of a report that still carries revoked, expired, completed, superseded, or cascaded as a Mission's state MAY read it as terminated with that reason (cascaded as parent_terminated) and the facts the report retained; an emitter never reports those values as a state. That reading is local: the consumer never re-emits or re-signs it, and it verifies a signed artifact over its original bytes, which it retains, before reading it this way.

Revocation A Mission is revoked when the AS receives an authorized revocation for it. A deployment MUST provide an authenticated means for the Subject, the Approver, or an administrator to revoke a Mission by mission_id, independent of possession of any token (so a Mission can be stopped even when no refresh token is held). The wire shape of that operation is out of scope for this document. A deployment-defined authenticated surface satisfies this requirement; Mission Status () defines an interoperable revoke operation, authorized under its own lifecycle authorization policy, which a deployment can serve alone under that document's revoke-only conformance class. As permits, a deployment's revocation policy can 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: an already-issued access token remains valid until it expires (), so a token can outlive a transition of its Mission by at most the token lifetime. Token introspection () is a state-observable overlay that lets a resource server see Mission state per request and refuse a revoked Mission's token before the token expires; Mission Status specifies another, a status surface keyed by mission_id with signed responses. A deployment whose consumers rely on Mission state beyond a token's lifetime offers one of these, so they read current state rather than infer it from token validity.

Mission-Bound Access Tokens 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.

A deployment whose AS can issue neither deploys a Mission Authority Server (), which governs ordinary tokens at the enforcement layer. The first four subsections follow one issuance: resolving the Mission from the presented grant (), the checks every issuance passes (), and the token () and its response ().

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 continuation transport 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 is what "the referenced Mission" in refers to. 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; or
the Mission-bound subject_token on Token Exchange (the actor_token identifies the delegate, ).

It then applies the gating of . A Mission MAY carry zero or more grant bindings. Beyond the authorization-code lineage established at approval, a refresh-token family a continuation transport establishes later (above) is a further binding, 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. The predecessor parameter of is an example: it selects the Mission a successor is created from and does not reassign an existing binding. 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:

Token Exchange. 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's binding resolved to. A Token Exchange that instead establishes reusable authorization state, such as the continuation profile's delegation-family-creating exchange (), creates a new grant binding, rooted in that same Mission.
Cross-domain projection. A cross-domain projection () establishes no destination-side grant binding. The cross-domain grant a Resource AS consumes is single-use and confers no standing authority in the partner domain, 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 that needs the projected Mission again is presented a fresh cross-domain grant.
Child Missions and successors. A Child Mission () and an expansion successor () 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 (the child's parent member, the successor's predecessor member).
Continuation handles. A continuation handle and a refresh-token family () are credential machinery rooted in one Mission, not the Mission itself: they confer no authority of their own, and a live derivation re-resolves the reference they carry against the Mission's current state.

A grant binding is also distinct from a decision-time runtime join, such as the Mission Join of , in which a policy decision point joins an ordinary OAuth credential to a Mission per request. The same credential can be joined to different Missions across separate requests where its subject and client are eligible for more than one. Such a join 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 (, ). 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; a Mission Management companion () can standardize that index's wire surface. 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 Identifier and Expiry in Responses A client learns its mission_id from the mission claim's id on each issued token () or from the token response. This document defines mission_id as a token-endpoint response parameter: a string carrying the Mission Identifier, returned alongside the issued token. An AS SHOULD return it, because a client need not parse the access token and cannot read the mission claim of a token that is encrypted or opaque to it. 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 success response that first delivers a newly created Mission's identifier or credential MUST carry it, and a Mission-bound token response SHOULD carry it beside mission_id: expires_in describes the access token's lifetime, not the Mission's, and the effective expiry can be shorter than the requested intent.expires_at. 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 the member is additionally registered as a token-endpoint response parameter (). It is informational in the same way: presenting it authorizes nothing.

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 a cross-domain grant issuance (). A companion profile bounds the number of derivations under a Mission (). A derivation passes these checks, each stated where cited:

the Mission resolves from the presented grant ();
the Mission is active (, and below);
each emitted entry is a subset of a Mission Authority Set entry ();
any emitted scope meets ; and
each token's exp does not exceed the Mission's expires_at ().

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. 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 below, still apply. The error code alone does not tell a client which gate refused. On a refusal under this section 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 (). The mission_error member is diagnostic only: it grants nothing, an unrecognized value is ignored, and it is returned only to the authenticated client presenting the Mission's grant. Derived tokens SHOULD be short-lived so that a transition to terminated takes effect promptly without per-request revocation checks.

Token Claims fixes the JWT's required claims (including jti), the typ header parameter value at+jwt, and resource server validation (, , ). In addition to what that profile 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).

The primary access 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 (); the cross-domain companion requires sender-constraint for credentials that cross a trust domain (). An AS 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. Every emitted authorization_details entry is a subset of a Mission Authority Set entry ().

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 (for mission_resource_access, ). A token request's resource parameter () selects the audience the client asks for. The token's aud names the recipients that accept the token. 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 (). The mission_id response parameter carries the Mission reference 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:

Refresh Tokens 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.

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. The cross-domain companion () specifies how this bound extends transitively to tokens minted in another trust domain.

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 (step 5 below). 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.

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;
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; and
for a multi-audience token, establishes the condition independently for each audience; a single-audience token () remains preferred.

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. 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 is a step 5 failure 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. 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. 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 (for mission_resource_access, ). The runtime profile's enforcement-scope declarations () can reference the same mapping for the paths it covers; this rule does not depend on that profile.

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:

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 (for mission_resource_access, ). 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 refuse the request (for example, a 403 with the insufficient_scope error code , or the deployment's usual insufficient-authority error) 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, reject a token that lacks it with the invalid_token error code. The issuance-side duty that pairs with this rejection 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 cross-domain profile it has adopted () explicitly establishes the permitted relationship between the two. It MUST reject a token that fails either check with the invalid_token error code. 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 ().

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 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. 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. A Mission-unaware resource server 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.

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 request fails closed under 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 or an expansion where that companion is deployed.
constraint_unrecognized:: An applicable entry carries a type-defined member or constraint the resource server cannot enforce, and the request fails closed. 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 ().

Enforcement Responsibilities Every bound this document defines is enforced by a party this document names. The following table summarizes which party enforces each bound a Mission carries and what holds when that enforcer is absent. Where a row names a type specification, it is the one for mission_resource_access (): Enforcement of an entry's resource, actions, and constraints

Bound	Enforced by	When that enforcer is absent
`resource` and `actions`	any resource server that enforces `mission_resource_access` per its type specification ()	a scope-only resource server is served only where the AS established a safe scope projection (); the AS refuses issuance to it otherwise
per-entry `constraints`	a resource server that understands and enforces the key, per that type's specification ()	a Mission-aware Resource Server fails closed; a scope-only resource server is served only where the projection independently accounts for the constraint ()

Remediation Grains A denial can carry independent remediation grains: separate remediation mechanisms, each naming a next step without granting anything. The three remediation grains are:

mission_denial:

Carriage: WWW-Authenticate attribute
Defined by: This document ()

insufficient_authorization with authorization_remediation:

Carriage: WWW-Authenticate error code and parameter
Defined by:

Requestable denial:

Carriage: AuthZEN denial response: context.access_request with next_action: request
Defined by: , profiled by

A resource server can also respond with the insufficient_authorization error code and the authorization_remediation parameter (), which names what mission_denial: insufficient_authority only points at. 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 (), or an expansion where that companion is deployed (). A client holding no refresh grant that covers the entries proposes them as for a new Mission. A third grain, the requestable denial of , profiled by , routes the same denial into a governed access request rather than a fresh derivation. The three grains compose: a deployment can offer any subset, and none widens authority beyond what derives from the same proposal unremediated.

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. 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`
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, where the AS applies 's delegated-token routing rule at issuance, the delegated token's target is not known to be Mission-aware	`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)	`invalid_request` on a Token Exchange (), `invalid_grant` () on any other grant, or the code a Token Exchange profile assigns (). Detail: `mission_error` ()
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`

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) ()	`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`
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`, or a well-formed request (including configured-mapping mode) is refused by AS policy	`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; 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`
Delegated token exchange (): the `subject_token` is not a designation this AS issued naming the 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: insufficient carried authority, or an unenforceable constraint ()	`insufficient_scope` () or the RAR-remediation challenge (). Detail: `mission_denial` (), minimized

In these tables, which evidence types are required follows , and invalid_client_attestation is the error code that specifies.

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 Mission-state-aware resource server holding a JWT Mission-bound token introspects it to observe the Mission's current state per request 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 ().

An AS MAY support OAuth 2.0 Token Introspection for Mission-bound access tokens. When it does, the response for such a token carries, 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 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. proposal_hash, authority_hash, approval_basis, and authority_source 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 () authorizes no resource access: the AS MUST return active: false for one, with no mission member. 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. 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 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 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 ():

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 (). 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 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 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 (). 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 the AS reports one inactive at introspection ().

Delegated Exchange A delegate obtains a delegated token by Token Exchange (), presenting a designation that the delegating party obtained for it (). 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 an actor_token or by its own client authentication, and the AS asserts the actor itself ().
Subject is stable. sub remains the Mission's Subject. The delegate is an actor, not the Subject.
client_id keeps its ordinary meaning. A delegated token's client_id is the OAuth client that requested it (, ). The originally-approved agent remains recorded 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).
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.
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 that credential's grant, 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.

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 Child Mission () or an expansion successor (), 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, 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.

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. 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.
The exchange is a derivation, gated on the Mission being active ().

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, and it is carried with the entries wherever they go, including across a cross-domain projection where that profile's provenance rule keeps it (). 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. A credential projected across a trust domain carries no act chain and enters the target domain at depth 0 (). 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;
a designation () and a self-exchange () add none; and
a cross-domain projection is the one defined reset.

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: sub is still the user. client_id 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. client_id 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.

Standing-Consent Bases A companion profile can generalize approval to a named standing-consent basis. Under it, 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 (). The following approval_basis.type values () are such bases:

template (): bounded instances of a recurring task;
policy_drawdown (): Child Missions that a parent agent requests and a policy adjudicates with no human interaction, rooted in the Parent Mission's accountable human;
ceiling_drawdown (): successor Missions within a previously approved authority ceiling as a task evolves; and
governed_policy (): an agent's own proposals, decided by a policy version that a human approved.

For a standing-consent type, activation takes the shape that its companion profile defines, and activation_actor names a dispatching or requesting party distinct from the consenting human. An unrecognized type or adjudication.kind is handled as states for every record consumer. A companion profile defining a standing-consent type MUST make its consent_principal and root_commitment trace to an accountable human's approval of the named standing consent, with no fresh human approval per instance, MUST carry that approval's instant as approved_at, and MUST state what the record's approval_event_id carries for an instance it activates. That value identifies this instance's approval event, never the standing approval, so a retried activation deduplicates and each distinct activation creates its own Mission.

approved_at:: REQUIRED for every standing-consent type. An RFC 3339 date-time: the instant the accountable human approved the exact consented root that root_commitment commits (the template version, the drawdown policy version), not the instant this Mission instance was activated. The activating issuer MUST verify approved_at against its retained, authenticated record of that standing consent for that exact version; it MUST NOT accept the value as the activating request's own uncorroborated assertion.

The adjudication member (), where present, follows the basis. Where a companion profile defining a standing-consent type populates adjudication, kind MUST be policy, naming the identity and version of the policy or workflow that adjudicated the instance. A companion profile MUST NOT flatten a policy's or an Approval Governance Record's assertion set into a single principal member.

Standing-Consent Instances Under a standing-consent basis (), the standing consent and the instance's adjudication supply the human decision that a direct approval event makes in : the Approver's authentication (step 1), the Approver's authorization for the Subject and the authority source (steps 2 and 3), and the consent rendering (step 5). The other creation rules still bind the instance's approval event wherever they apply:

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 on approval_event_id ().

Activation Policy Commitment Where a standing-consent basis lets a separate policy artifact adjudicate activation (a dispatch, drawdown, or child-creation policy, rather than the consented object itself), the object the accountable human consented to MUST carry that policy as an activation policy reference: an object of id (a string), version (a string), and digest. The digest is an integrity anchor () whose typ is mission-activation-policy, whose iss is the activating issuer, and whose value is an object of content_type, the media type of the policy snapshot, and content, the base64url, no-padding encoding of the snapshot's exact bytes. Before each activation, the activating issuer MUST compute digest over the exact snapshot it evaluates, and MUST NOT activate the instance under that policy when the result differs; the companion profile fixes what follows, as it does for an activation the policy does not authorize. The issuer MUST retain each snapshot's bytes and media type for the audit horizon () of every Mission it activates under that snapshot, so an auditor can reproduce the digest. Where no separate policy artifact exists, as when child creation is adjudicated against the approved delegation entry itself, this rule does not apply.

Standing-Consent Recency A deployment can declare a maximum standing-consent age (a recency ceiling), overall or per consequence class. Where a declared ceiling applies, the activating issuer MUST refuse to activate an instance whose approved_at is older than the ceiling. Where ceilings are declared:

The evaluation instant is the atomic Mission-creation commit (), including the creation commit of a deferred or relocated flow. Recency is issuance-time eligibility only: a later change to a ceiling, or the passage of time past one, does not terminate an active Mission ().
The activating issuer MUST refuse an approved_at later than the evaluation instant by more than the deployment's declared, bounded clock-skew allowance.
Where ceilings are declared per consequence class, the issuer MUST classify the committed Mission from the derived Authority Set and from any consumption bound the Mission Intent carries (for example, ), and MUST apply the strictest ceiling across every class present.
The ceilings and the skew allowance belong to the versioned policy that policy_version identifies, or to a separately versioned declaration retained with it, so an auditor can reproduce the eligibility decision.

Mission Record A Mission is the durable record created at the approval event; a Mission Identifier () identifies it. Its members are immutable after creation, except state and the termination member written once when the Mission terminates (). Record member names omit the mission prefix because the record is the Mission. Prefixed names, such as the mission_intent request parameter and the mission_id response parameter, belong to surfaces that reference a Mission from outside it. Member names are spelled out (issuer, expires_at, created_at) and spelled identically on every surface. The compact JWT names (iss, exp, iat) describe a signed artifact's own envelope, or identify a party in an {iss, sub} 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. The following subsections define the record's members.

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; for cross-domain tokens it remains the issuer AS that approved the Mission even though the issuing iss differs ().
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:

REQUIRED. A string. The authority commitment over the Authority Set (). It is not carried on the baseline mission claim ().

intent_hash:

REQUIRED. A string. The integrity commitment over the approved Mission Intent (), making the recorded task tamper-evident.

proposal_hash:

REQUIRED when proposed_authority is present, absent otherwise. A string. The integrity commitment over the recorded 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.

submission_evidence 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 (, ).

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 ().

An unrecognized type, and likewise an unrecognized adjudication.kind (), 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). Unlike an unrecognized lifecycle state (), an unrecognized value here does not by itself invalidate or deactivate the Mission.

consent_principal:

REQUIRED. An object with iss and sub. The accountable human (or human-accountable principal) who consented. MAY equal subject.

activation:

REQUIRED. An object naming what activated this Mission instance, shaped by type. For direct: approval_event_id, mirroring the record's own approval_event_id (below).

activation_actor:

REQUIRED. An object with iss and sub. Who or what triggered this instance. For direct it equals consent_principal: the Approver triggers their own approval.

root_commitment:

REQUIRED. A string. The commitment to the consented root: an integrity anchor where the root is a committed object, otherwise the committed reference that identifies it. For direct, this Mission's own authority_hash.

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 and ). 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. An unrecognized value is handled under the same rule as approval_basis.type ().
governance_record:: OPTIONAL. A boolean. true when an Approval Governance Record is recorded for this approval event (), joined by this Mission's own approval_event_id. It never changes kind, which follows the basis (below and ). Approval Governance aligns the record's accountable assertion, where it carries one, with that kind: a governed decision still names its mechanism, and the record supplies the fuller assertion set behind it, including any multi-assertion set, never flattened into it.

For kind: human: no additional kind-specific members; the deciding human is consent_principal. For kind: policy: policy, a REQUIRED object with id and version identifying the deciding policy or workflow. It decides deterministically over recorded inputs, so re-evaluating that version over them re-checks the decision. A model's output can be one such input, recorded with the model's identifier and version: it can refuse an activation or narrow the authority it activates, and the AS MUST NOT let it supply or widen authority. A model is never itself the deciding policy or workflow. 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 ().

approved_at:

Absent for direct, whose approval event carries its own instant (); a standing-consent basis carries it ().

For direct, activation.approval_event_id MUST identify a human approval event (). Approval Governance states how a record backing a direct approval keeps that human decision as its accountable assertion (). 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. Two optional profiles commit it (). Mission Audit Transparency's approval-event registration () covers the record at creation except its state and termination. Approval Governance's Approval Context Commitment () covers a closed manifest of creation facts that includes approval_basis. 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. An unrecognized value is handled under the same rule as an unrecognized approval_basis.type (): it is preserved unchanged as opaque provenance and does not by itself invalidate or deactivate the Mission, and only an operation that itself requires recognized source semantics refuses (for example, applying the source's authority ceiling or its governed policy). An AS MUST NOT approve a Mission whose authority source it does not recognize.
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. 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.

authority_source 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.

Provenance and Expiry

policy_version:: REQUIRED. A string. An opaque audit correlator naming the derivation policy version in effect at the approval event; the policy itself does not travel.
approval_event_id:: REQUIRED. A string. A unique identifier of the approval event, used as the approval idempotency key: a retried or duplicate delivery of the same approval decision (a replayed callback, a double-submitted consent form) MUST NOT create a second Mission, and the AS deduplicates on this identifier.
created_at:: REQUIRED. A string. RFC 3339 timestamp of creation.
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 (). 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.

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.

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.

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 present 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.
- For an activation policy reference's digest, typ is mission-activation-policy and value is the policy snapshot object that defines.
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 (). The anchors this section lists, and the Authority Set entry commitment below, 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. intent_hash and authority_hash 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 (), 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. 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 ). mission- prefixed values, used by this document and the profiles that extend it, form a namespace coordinated through this document's change controller. This document also defines the Authority Set entry commitment, the envelope above 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. authority_hash likewise 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, as mission_resource_access does for its prefix-match resource containment test (), it applies to that comparison alone: the default resource equality test remains an exact match, and anchor computation is always byte-exact over the recorded values.

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, an activation policy reference's digest, 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 (for example, a runtime parameter digest).
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 (for example, a work-product artifact digest).

The prefix and agility rules below bind all three species. The I-JSON rule binds the two JSON species. The envelope and typ discipline of binds envelope anchors alone. This section instantiates 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. 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, as the Mission Resource Access Profile's Common Constraints do for constraint values (). The security considerations of apply to every JCS computation. The algorithm prefix is the agility mechanism. sha-256 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. These rules 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 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.

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 ().

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 .
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 ().
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; it does not make an AS implement, recognize, or trust any member.
Integrity anchors. Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (). A consent-disclosure commitment, an instruction-text attestation, or a delegation receipt can be committed this way without changing this document. A profile that commits an evidence or disclosure object MUST commit it with this envelope and a typ that meets , 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 (for example, an intent_hash for audit), and is never authority-bearing on its own.
The mission claim. It is an open object: additional, collision-resistantly named members can be carried in it (for example, a runtime decision reference, a delegation receipt, or an attestation reference), 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.
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), provided the steps and their atomicity hold unchanged and no Mission reference exists before the record is active; the Mission Deferred Approval companion is such a profile (). 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, such as a device code issued while the request was pending, provided the steps and their atomicity with the approval decision hold unchanged and no Mission reference exists before the record is active; the Mission then binds to that profile-defined reusable grant ().

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 () and the Mission Record members (), 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.

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 (). Where the deployment's AS cannot change, the standalone Mission Authority Server () is the governed alternative. 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 (): the approved-set commitment a Mission-aware client relies on. 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. For mission_resource_access, that shape, including the Common Constraints structure, is the Mission Resource Access Profile's ().

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 delegation and for the companion's cross-domain grant issuance. 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.

A type-defined authorization_details member may define its own constraint-discovery surface; mission_resource_access's is defined by the Mission Resource Access Profile (). 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.

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 scope-only resource server is served only where the AS established a safe scope projection for it (). 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, and the deployment still provides the authenticated revocation means of .

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 (); and
gating of issuance on Mission state ().

An AS can conform as a Mission Issuer without supporting any Intent Submission Evidence type. Such an AS refuses every presented entry as an unsupported type under the dispatch and refusal rules (), with the invalid_mission_intent_evidence error code. It need not implement the evidence framework of for this configuration. The companion defines conformance for ASs supporting an evidence type, whether its evidence is optional or required. 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, which for mission_resource_access is work a plain resource server does not do. 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
obtaining mission_id from the mission_id token-response parameter or the mission claim's id (), treating it as a reference, not a credential.

Optional Capabilities Beyond these mandatory roles, an implementation can additionally claim three 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 primary tokens.
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 (, ); and
4. projected credential lifetimes capped by the Mission's expires_at ().
This bar is self-contained in this document. The companion Mission Cross-Domain Projection profile () specifies the interoperable mechanism that satisfies it, and implementations that interoperate across the hop implement that companion.

Mission Approved-Set Verification () defines an independent check, by a resource server or policy decision point, that a token's carried authority is a subset of the complete approved Authority Set; conformance to this document does not require 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. A token carrying a mission claim is not, by itself, Mission-bound authorization. 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 publishes a Mapping Assessment of how the surfaces above realize the Mission Substrate contract's kernel and capabilities (). It is not this document's conformance result: this document makes no substrate-conformance claim, takes no requirement from the substrate, and remains self-contained; its reference to the substrate contract () is informative.

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 records authority_hash, which 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. intent_hash extends the same protection to the task: it commits the approved Mission Intent, so an auditor can detect any later alteration of the recorded task. No anchor substitutes for another. authority_hash 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. intent_hash 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. A deployment whose Missions carry high-risk authority can retain presentation-level audit evidence from which the disclosure shown can be reconstructed and audited. Mission Consent Evidence binds a consent_rendering_hash over a structured consent-disclosure object on the wire; an AS that does not implement it can record equivalent evidence out of band. 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 register the approval event under Mission Audit Transparency , whose registration covers the record at creation except its state and termination, or carry the Approval Context Commitment of , whose closed manifest includes the approval basis, in a signed artifact.

Downgrade by Omission A token bearing equivalent authorization_details but no mission claim is governed by no Mission state, revocation, or consent commitment. A deployment can classify a resource as Mission-governed (a Mission-governed resource) or register a client as Mission-governed. Rules on three sides address this downgrade:

Issuance. The rules of keep such a resource's tokens inside a Mission and refuse such a client's authorization request that carries authorization_details but omits the Intent.
Client. A client holding a Mission Intent does not fall back to an ordinary request where Mission support is not established, and a client performing a Mission's task does not present an ordinary credential it already holds for that task ().
Enforcement. A resource server for such a resource rejects a token lacking the mission claim and can advertise that requirement (, ).

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:

Classifying a resource as Mission-governed closes this path at that resource.
Mandatory mediation closes it where the client's requests must pass through a runtime layer that holds custody of the client's credentials ().
A decision-time join of an ordinary credential to the Mission, such as the Mission Join of , is one realization of the enforcement path that permits.
An unmediated ordinary workflow at a resource that is not Mission-governed remains a residual that only the client's own conformance closes.

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.

Agent-Specific Threats

Prompt Injection and Data Exfiltration This document assumes that an agent reading attacker-influenceable content can be prompt-injected, and does not try to make the agent immune. Injection is dangerous when one agent combines access to private data, exposure to untrusted content, and the ability to communicate externally; the Mission Security Model () analyzes that combination and its architectural defenses. This document constrains the data-access leg: a Mission narrows authority from everything the agent's standing credentials allow to the resources the approved task needs, and per-task Missions () further limit the effect of a compromise. Against the untrusted-content leg, authority is fixed at the approval event, so injected text cannot expand an approved Mission. purpose 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 (, ). This document does not constrain the external-communication leg. It models authority over resources and actions, not how an agent uses authority it holds: within an approved Authority Set, an injected agent can read what the Mission permits and write to a sink the Mission permits. Constraining exfiltration by a compromised agent is the runtime layer's role (), and even there it is bounded, not closed (). Preventing misuse of data within the authorized scope needs a taint or information-flow layer this document does not define.

Authority and Propagated Information Issuance gating bounds escalation by token acquisition (, ): an agent cannot exceed the approved Authority Set by acquiring additional tokens. The same bound holds for information: an agent can inherit another agent's knowledge, but not its authority. A work product of one Mission (a file, message, memory entry, queue event, or other durable shared artifact) is input, not authority, to an agent under another Mission that reads it. The receiving Mission determines what can be done with the information under its own Authority Set (); the producing Mission's authority does not transfer through the artifact by copying, referencing, embedding, or communicating it. An agent that needs authority to act on what it read acquires it only through an authorized derivation or delegation bounded by the Mission (), not from the artifact. The threat is emergent authority through coordination: independent Missions communicating through shared state, so that individually acceptable actions compose into behavior no single Mission authorized (). Mission Work Products specifies the mechanism that upholds the invariant across such a carrier (work-product provenance and a non-transitive Mission-to-Mission handoff); this document takes no normative dependency on it.

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 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.

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, it is bound to the client that redeems it, and it authorizes no resource access. 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. max_depth 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 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 the primary token () likewise keeps a stolen token from being designated or self-exchanged.

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 (a status assertion, a Mandate, registered evidence) 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.

Composition and Residual Authority

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. The recorded policy_version makes each Authority Set derivation auditable by naming the policy it ran under.

Authority Hash and Mission Identity authority_hash commits the approved Authority Set, not the Mission. Two Missions that approve byte-identical authority (a successor that re-approves the same Authority Set, or an unrelated Mission with the same derived authority) share it while differing in intent_hash, approval_basis.consent_principal, and id. therefore forbids its use as a Mission Identifier or as a replay or idempotency key. A consumer that needs to bind to or correlate a specific Mission uses the Mission Identifier. Where a deployment discloses authority_hash to a resource server, it is an audit correlator, not an enforcement input, and not proof that the carried entries are a subset of the approved set.

Composition and the Effective Ceiling Delegation depth () resets to 0 at each cross-domain hop () and, where a deployment runs the child-delegation profile, at each child generation (). The aggregate surface that a Mission's descendants can reach (the product of delegation depth, the number of trust domains projected into, and the number of child generations, each bounded independently) can therefore exceed what a single approval appears to bound at consent time. Child Delegation's max_children and max_child_depth limit the descendant Missions live at once, not those created over the root's lifetime: a child that terminates frees its slot (; works an example). Cross-domain projection composes separately: a projected grant preserves the Mission's lineage rather than rooting a new one, and the Resource AS's local issuance under it is bounded by that grant's own lifetime and local policy. At the consent surface, a deployment can disclose the subtree's figures, not only the immediate Mission's, as distinct values rather than one composed total (). Where a single approval's apparent bound must hold in practice, it can impose a global cap out of band. Bounding aggregate consumption (calls, spend, or activity over the life of a Mission and its descendants) is the metering profile's role ().

Authority Materialized Before Containment Where a deployment runs the Mission Containment profile (), containment narrows the authority available from an entry for later derivations; the approved Authority Set and its commitments remain unchanged. Containment also propagates to Child Missions justified by that entry. Containment does not reach authority materialized before the containment transition. A cross-domain grant already redeemed at a Resource AS (), or an offline attenuation root already minted and attenuating outside the issuer's reach, operates for its own remaining lifetime, the same residual bound that revocation carries (). Where containment needs to take effect quickly against already-materialized authority, short cross-domain grant and offline attenuation root lifetimes keep that residual window to one the next lease or re-mint closes.

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, and cross-domain projection () carries it across trust domains unchanged. 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 (for example, the metering companion's consumption bounds, );
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 (). Where approval-event evidence was registered under the audit transparency profile (), its erasure record and data-subject-request basis are the transparency-side mechanism. That mechanism records an erasure but neither performs one nor overrides retention law, and it leaves the operational Mission Record and its audit-horizon retention floor untouched.

Internationalization Considerations Mission Intent prose (goal, task_bounds) is human-readable disclosure. goal_lang () 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 (Mission Consent Evidence binds one locale, one disclosure, one hash, ); 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,

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`	The Subject, Approver, or policy terminated the Mission.	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 Client Instance Identification for Attestation-Based Client Authentication 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. 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. OAuth SPIFFE Client Authentication Defakto Security Defakto Security NIST IBM Cisco Systems This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. 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. Push-Based Security Event Token (SET) Delivery Using HTTP This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. 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. Grant Negotiation and Authorization Protocol (GNAP) The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. OAuth 2.0 Device Authorization Grant The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. 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. Mission Child Delegation for OAuth 2.0 Mission Template for OAuth 2.0 Mission Containment for OAuth 2.0 Mission Progressive Authorization for OAuth 2.0 Grant Management for OAuth 2.0 OpenID Foundation 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. Transaction Tokens CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Attenuating Authorization Tokens for Agentic Delegation Chains Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. Cedar Profile for OAuth 2.0 Rich Authorization Requests Amazon This specification defines a profile of OAuth 2.0 Rich Authorization Requests in Cedar policy format within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to distribute and recieve relevant Cedar policy sets in an interoperable manner. 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 Lifecycle Signals for OAuth 2.0 Mission Cross-Domain Projection for OAuth 2.0 Mission Cross-Organizational Delegation for OAuth 2.0 Mission Derivation Limits for OAuth 2.0 Mission Authority Server An Architecture for Mission-Bound Authorization Mission Substrate Requirements Mission-Bound Runtime Enforcement Mission Security Model Mission-Bound Runtime Enforcement: AuthZEN Profile Mission Capability Binding Mission Expansion for OAuth 2.0 Mission Consumption Metering Mission Intent Submission Evidence for OAuth 2.0 Mission Approved-Set Verification for OAuth 2.0 Mission Consent Evidence for OAuth 2.0 Mission Intent Shaping Mission Deferred Approval for OAuth 2.0 Mission Device Authorization for OAuth 2.0 Mission Approval Governance Mission Audit Transparency Mission Work Products for OAuth 2.0 Mission Resource Access Profile for OAuth 2.0 Mission Continuation for OAuth 2.0 Mission Management 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; the identity setup follows . 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. Text marked as a companion variation shows what an optional companion adds to the same Mission, and the timeline () lists both. Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in the home ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-.

Stage 0: Agent Identity (by Reference) The agent is an OAuth client with a workload identity, for example one established using WIMSE or SPIFFE . alice has delegated to it through an ordinary authorization code flow, per : the client_id claim names the agent, and the sub claim identifies alice. This document adds the Mission layer to that identity; Stage 0 is otherwise unchanged from that specification.

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 (each entry a same-type subset of a proposed entry, ), and renders it for alice's consent: 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. Companion variation (runtime enforcement): where the deployment runs the runtime profile (), the resource server also obtains a point-of-use permit against current Mission state from a policy decision point before executing the write. The AuthZEN profile's worked request () is that check for a 423.50 USD posting at 08:14:03, made with that write-only token. Companion variation (cross-domain): the end-to-end example of the Mission Cross-Domain Projection profile () follows a Mission like this one whose authority also covers a partner ERP in another trust domain.

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: Suspension, Resumption, and Revocation Suspension and resumption are Mission Status operations, shown in its companion variation below. 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. Companion variations:

Mission Status (). The Mission is created at state version 1, suspended at 08:20:00 and resumed at 08:30:00 (state versions 2 and 3) through the profile's lifecycle operations, and the AS derives nothing in between (). The revocation at 08:53:20 is the agent's own revoke operation, with the reason "Quarterly reconcile completed early", under an explicit lifecycle authorization the deployment grants it for this Mission; its resource tokens and refresh token confer no such authority. The AS commits it as state version 4.
Mission Signals (). A receiver learns of the revocation from a Security Event Token.
Runtime enforcement (). A resource server that obtains a point-of-use permit stops honoring the token within that deployment's declared freshness and permit bounds, since a permit can rest on a state observation taken before the revocation.

Timeline All times are 2026-11-02 UTC. The rows marked with a companion occur only where that companion is deployed. End-to-end example timeline

Time	Event	Defined by
08:00:00	`alice` approves; the AS creates the Mission	this document
08:00:05	The agent redeems the code; the access token expires at 08:05:05	this document
08:14:00	The agent refreshes for a write-only token	this document
08:14:03	A point-of-use permit for a 423.50 USD posting	runtime profile (AuthZEN)
08:20:00, 08:30:00	The Mission is suspended, then resumed	Mission Status
08:50:00	The agent refreshes for a read-only token that expires at 08:55:00	this document
08:53:20	The Mission is revoked and `terminated`; later refreshes are refused, and introspection reports the read-only token inactive	this document
After revocation; delivery time unspecified	A receiver learns of the revocation from a Security Event Token	Mission Signals
08:55:00	The read-only token expires; a resource server enforcing from the token alone stops honoring it	this document

Design Context and Boundaries This appendix explains the design choices behind the Mission and records what this document leaves to other work.

Relationship to Existing OAuth Objects OAuth already has objects near this need, but none is the approved task:

A scope value or an authorization_details entry () expresses authority but neither the task it serves nor a lifecycle of its own.
An access token is a short-lived projection; its jti claim identifies the token, not the task.
A refresh token preserves the ability to obtain further tokens but commits no bounded, approved authority.
A consent record proves that an approval event happened; it does not govern the resulting work as it continues.

The Mission is the durable object these project from: the approved task that bounds and outlives them and that every derived token refers back to. It is not another authorization_details type, since Rich Authorization Requests already express authority; it is the approved task with a lifecycle, which an Authority Set is derived for and gated by.

Relationship to Adjacent Work A grant, in the sense of FAPI Grant Management , is a durable, queryable, revocable container of consented authorization data, with no task, integrity commitment, or derivation gating. A deployment can surface Mission revocation through a grant-management-style API (). This document specifies the issuance and governance layer that agent-identity work for OAuth leaves unspecified. names the agent's mission and leaves its translation into authorization requirements out of scope. This document specifies that translation and reuses its assignments unchanged: the agent is the client, and the delegating principal is the token sub (). An agent authenticated and delegated per that document uses these mechanisms to obtain Mission-bound tokens. Decision-layer access-request and approval workflows, such as the OpenID AuthZEN Access Request and Approval Profile , manage approval tasks but do not tie an approval to token issuance. This document supplies the issuance-bound object such workflows complete into. Nearby individual proposals each carry one Mission property without the others:

task-linked Rich Authorization Requests with revocation webhooks carry a task link;
intent-digest admission assertions carry an intent commitment; and
offline capability attenuation () carries offline narrowing.

None combines the durable approved object, state-gated issuance, and integrity anchors this document defines. The Grant Negotiation and Authorization Protocol covers much of the same design space: a continuable authorization request, richer client instance identification, and native delegation. Rather than a new grant protocol, endpoints, and client machinery, this document uses deployed OAuth 2.0 surfaces: Pushed Authorization Requests (), Rich Authorization Requests (), DPoP (), and access tokens. A deployment that runs PAR, RAR, and sender-constrained tokens adopts the Mission model without a GNAP grant endpoint or migrating its clients to GNAP. The Authority Set's subset rule () follows capability systems in which a holder narrows what it passes on without contacting an issuer: macaroons' caveat narrowing, Biscuit's offline attenuation blocks, UCAN's delegation chains, SPKI/SDSI's local-name reduction, and object-capability designs generally. In this document, narrowing applies to a durable, approval-anchored object that its issuer can revoke for the Mission's full lifetime, not a bearer credential bounded only by its caveats. Revoking the Mission therefore still reaches everything derived from it that has not already left the issuer's reach ().

Missions, Plans, and Execution The Mission is the durable, AS-held object that commits the approved authority and owns the task's lifecycle. Two related things an agent produces around a task draw on the Mission's authority but carry none of their own and never enlarge it. The agent's plan (how it decomposes the task, chooses tools, and delegates to sub-agents) is its own strategy and is out of scope. It grants nothing: a sub-agent's authority is carried on its delegated token (), derived from the Mission and only narrowed from it (). The agent's execution (the tokens it derives, the calls it makes, and the decisions taken on them) references the Mission but cannot expand it. Revoking the Mission stops further derivation () but does not undo completed actions. Evaluating each action against the Mission at the point of use is the runtime layer's concern (). How a client produces the Intent (for example, a "Mission Shaper" deriving it from a natural-language instruction) is out of scope.

Scope and Future Work 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. Optional companion profiles, not required to implement this document, specify:

an additional integrity anchor over a structured consent disclosure (consent_rendering_hash, ), defined by Mission Consent Evidence ;
mission expansion, defined by Mission Expansion ; and
a cross-domain status or event-distribution mechanism for tighter revocation, defined by Mission Status and Mission Lifecycle Signals .

Future work includes:

the normative carriage of Mission context in Transaction Tokens (), shown only illustratively in the companion's end-to-end example; and
an optional Authority Set derivation profile for a vertical that wants cross-vendor agreement on what a task authorizes: a registry of standard task types mapped to authority templates, so that two vendors in that profile derive comparable Authority Sets. This document does not standardize the Authority Set derivation algorithm ().

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, a successor Mission, as specified by Mission Expansion .
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. Mission Lifecycle Signals () specifies a Shared Signals and CAEP profile for Mission lifecycle events, delivered as Security Event Tokens ().
Human-in-the-loop suspension. The base lifecycle is active and terminated (). Mission Status () defines a suspended state with resume/complete transitions as an optional extension. A pending-human-approval state and a holding-token pause-and-resume protocol are future lifecycle work.
Multi-hop cross-domain projection. Cross-Domain Projection () specifies a single projection hop. Mission Cross-Organizational Delegation () profiles recursive delegation across organizations; a destination verifies that delegation chain before projecting. 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. authority_hash 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, as a Mission-aware Resource Server does (). 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.

Role Mapping approval_basis separates three questions about a Mission's own creation, which a scenario can assign to different principals:

who is accountable for it (consent_principal);
who or what triggered it (activation_actor); and
what decided it (adjudication).

The companion profiles cited below define the scenarios; the list shows how each assigns the three roles: its accountability root (consent_principal), activation actor (activation_actor), and adjudication (where a profile or deployment populates it).

Direct approval:

Accountability root: The approving human
Activation actor: Equal to consent_principal: the Approver triggers their own approval
Adjudication: kind: human; the deciding human is consent_principal itself

Relocated human approval ():

Accountability root: The human who completes the relocated approval event
Activation actor: Equal to consent_principal, unchanged from the direct case: the instance activates at that human's decision, not at any earlier submission
Adjudication: kind: human, as direct

Template dispatch ():

Accountability root: The template's human approver, fixed at template creation
Activation actor: The Dispatcher that requested the Dispatch, distinct from consent_principal
Adjudication: kind: policy, policy naming the template's dispatch_policy id and version (already carried in the dispatched Mission's template lineage member), never the Template's own id/template_version nor the Dispatcher

Policy drawdown ():

Accountability root: The Parent Mission's human Approver
Activation actor: The requesting parent Agent, distinct from consent_principal
Adjudication: kind: policy, naming the child-creation policy's id/version where the entry carries one, otherwise the Parent Mission's approved delegation entry; never the requesting parent Agent

Ceiling drawdown ():

Accountability root: The Approver who consented the ceiling
Activation actor: The requesting client, distinct from consent_principal
Adjudication: kind: policy, naming the drawdown policy's policy_id/policy_version carried in activation; never the requesting client

Governed policy approval ():

Accountability root: The human who approved the exact policy version the instance activates under
Activation actor: The authenticated client that requested the activation, distinct from consent_principal
Adjudication: kind: policy, policy naming the deciding policy's id/version (the approved policy itself or the evaluator it commits), with governance_record: true; never the requesting client

AGR-backed direct approval ():

Accountability root: The approving human, whose own human assertion is the Approval Governance Record's accountable assertion
Activation actor: Equal to consent_principal, as for direct approval
Adjudication: kind: human, governance_record: true; how other assertions contribute is Approval Governance's

AGR-backed template or drawdown activation ():

Accountability root: Unchanged from the underlying basis, whose approval_basis stands in for an accountable assertion
Activation actor: Unchanged from the underlying basis
Adjudication: kind: policy, as the underlying basis assigns it, with governance_record: true; the full assertion set is never collapsed into a single principal

Direct approval is the degenerate case where one human fills every role. Where a profile or deployment does not populate adjudication (), the list shows the value it would carry.

Derivation Policy This appendix is illustrative and adds no requirements. It describes an authoring artifact for the contract in , not a standardized policy language or an alternative subset relation.

Policy Artifact A deployment retains a versioned derivation policy with its ceiling, configured mappings, and issuance limits. Its inputs include:

a validated Mission Intent;
the client's authority proposal in narrowing mode, or configured candidates when there is no proposal;
the applicable authority source ceiling;
the capability catalog's per-action properties; and
any recorded model output.

The output is the Authority Set committed by authority_hash, and policy_version identifies the policy used. Reproducing an Authority Set derivation requires the same inputs and the retained policy and catalog versions, not just the identifier of a mutable configuration. Replay uses a model's retained output and never reruns the model. Authority Set derivation is mechanical: a model may suggest an Intent or a proposal, or contribute a recorded input that refuses or narrows, but does not make the approval-time narrowing decision.

Derivation Policy Properties The five properties below restate, for a policy author, what and the rules it cites require.

Deterministic. The same Intent, proposal, ceiling, catalog, and recorded model output derive the same Authority Set, so policy_version can serve as an audit correlator ().
Narrowing only. Every derived entry is a subset of some proposed entry of the same type, under that type's own relation (, ); in configured-mapping mode the configured candidates supply that comparison input. Retaining fewer JSON fields is not narrowing: dropping a restriction can grant more. Where the relation cannot decide because two bounds are incomparable, the result is conservative refusal (). For mission_resource_access, two amount caps naming different currencies have no intersection, with no implicit conversion and no "ceiling wins" exception; defines the Common Constraints and their intersection rules.
Refusal over silent drop. An entry of an unsupported type, an entry that fails its schema, and an entry carrying a constraint the engine cannot compare, whether registered or deployment-defined, are refused (, , ). Authority Set derivation does not repair them by omitting the entry or dropping the constraint. An entry the engine compares but policy cannot accept differs: it is narrowed or omitted, and the granted echo reflects that ().
Issuer-established members are not client-supplied. The issuer establishes policy_version (), and authority_source and approval_basis (, ), at the approval event; no proposal member sets them.
No member the ceiling never granted. A grant-shaped member absent from the ceiling, such as a per-entry delegation policy, stays absent from the derived entry, so a proposal cannot introduce a capability the policy did not confer. A restriction nested inside an already-granted delegation, such as allowed_delegates, narrows in the ordinary direction. Where the ceiling's eligibility defers to the issuer's delegation policy (no allowed_delegates), a proposed list only restricts that policy's decision and never replaces it ().

Derivation Rule Example The following example uses a catalog whose read actions supply no amount for a cap to compare against, while a journal write does. The ceiling separates those actions: The validated proposal also separates the read from the amount-bound write: The resulting Authority Set contains the proposed invoices.read entry unchanged, and the proposed journal-entries.write entry with max_amount narrowed to 500.00 USD. The ceiling's unrequested journal-entries.read does not appear. Each proposed entry intersects the same-resource ceiling entries; an empty action intersection contributes no authority. Negative fixtures accompany this positive result; none is a special case that relaxes the type's relation:

A single mixed read and write proposal carrying the amount cap is refused at intake: the read supplies no amount for the cap to compare against, and Authority Set derivation does not drop the cap from the read fragment.
A write proposal naming a different currency cannot produce the USD intersection shown.
A proposal carrying a Common Constraint this deployment does not compare is refused with the invalid_authorization_details error code (), not derived with the constraint dropped.

Fixtures and Authoring Discipline Versioned Intent and proposal fixtures with expected Authority Sets make the optional publication in concrete. Reviewing their diffs on every policy change exposes altered grants before approval. Fixtures cover normal template and narrowing outcomes, empty intersections, unknown constraints, incomparable values, and attempts to introduce delegation. They check each subset against both the proposal and the ceiling. A further check runs the shipped configuration through intake, Authority Set derivation, and a real decision path, since a configuration that loads does not thereby authorize its intended workload. Applying the same entry checks at configuration load and at client intake keeps those two surfaces from disagreeing.

Ownership and Operational Signals Ownership and operational signals

Artifact	Owner	Responsibility
Derivation policy, ceilings, versions and issuance limits	Mission Issuer operator	Outer bounds and reproducible approval-time Authority Set derivation
Capability catalog and action properties	Resource owner or service team	Supported operations and the facts their constraints can evaluate
Templates and configured mappings	Template author within issuer policy	Candidate authority for supported Intent shapes

Templates amortize authoring across Missions and do not bypass the ceilings. The unmapped-resource rate, template-hit rate, and rule-exception rate show an operator where its policy authoring remains incomplete.

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.

OAuth Binding Mapping Assessment This appendix is this document's Mapping Assessment of itself against the kernel and capabilities of the Mission Substrate contract (the "Mission Substrate Statement" section of ). It describes, in the Statement's form, how the surfaces this document defines realize that vocabulary. The assessment is informative and adds no requirement: alone defines conformance to this document. This document publishes no Mission Substrate Statement, makes no substrate-conformance claim, and takes no requirement from the substrate; each document references the other informatively. The assessment applies to the substrate revision published with this document, in this document's base single-domain mode, with the optional capabilities active as the conditions below state. For the kernel:

The Mission Reference is mission_id: high-entropy, unambiguous within the issuer namespace, compared by exact string equality together with mission.issuer, never reassigned, retained for the audit horizon, and disclosed beyond the issuer only on this document's authorized surfaces.
The Controller is the Mission Issuer (the authorization server), established through mission.issuer and the deployment's issuer trust (AS metadata and published keys).
The Actor handle is the authenticated OAuth client at approval; the external Subject is fixed by this document's injective mapping; delegates are carried in the act chain; child and successor lineage is recorded through the parent and predecessor members; actor-type classification uses sub_profile and client-instance attestations where deployed.
The Approved Context is the Mission Intent recorded verbatim, the recorded authority proposal where one was submitted, and the derived Authority Set; the immutable boundary is the record's immutable members; commitments are the typed integrity anchors (intent_hash, proposal_hash, authority_hash); a material change obtains a new approval through an expansion successor.
The approval ceremony is this document's approval event (). Its direct realization, interactive or deferred, authenticates the Approver, establishes the Subject and authority source, renders the derived Authority Set and the effective expiry, and commits the record atomically. Under a standing-consent basis, such as a dispatch, the authorized policy ceremony decides the instance, and consent_principal remains the accountable owner ().
The active predicate is stored state equal to active with the decision time strictly before the record's effective expires_at, the issuer materializing the resulting terminated transition, reason expired, lazily where it chooses; any other stored value, recognized or not, is non-active; transitions are authenticated lifecycle operations; a non-active Mission refuses issuance and derivation.
The reliance bound is the record's effective expires_at (never later than the requested ceiling), which caps every derived credential's exp; the maximum residual after a Mission becomes non-active is the outstanding credential lifetime ().
The propagation and join surfaces are: the mission claim (artifact issuance under the Mission, authority derivation, and lifecycle-gated issuance); the mission_id and mission_expires_at response members (correlation only); the introspection projection (state as of the response, caller authorization and minimization applying); the Status surfaces (state as of a signed observation with explicit freshness); and the grant binding (the issuer's native association of Mission, Subject, client, and credential).
The governance record is the Mission Record with its approval evidence and lifecycle history, retained for the audit horizon, with integrity resting on record custody and the typed anchors.

The capability list:

Lifecycle-Gated Authorization:: Claim: supplied Activation: always Scope and defining sections: State-gated issuance and every derivation gate Limitations: Outstanding credentials run to their own exp; the residual is bounded, not zero
State-Observable:: Claim: supplied Activation: Status, introspection, or Signals companion active Scope and defining sections: Those surfaces Limitations: Staleness bounded by each surface's declared freshness
Structured Authority:: Claim: supplied Activation: always Scope and defining sections: authorization_details of AS-supported types (), each type's own specification defining semantics (for mission_resource_access, the Mission Resource Access Profile's Common Constraints, ) Limitations: Semantics exist per supported type, not universally
Monotonic Derivation:: Claim: supplied Activation: always Scope and defining sections: The subset rule over covered types at every derivation, delegation, and attenuation point Limitations: Covered transitions are attenuate; a cross-vocabulary transition is decide_anew, never silent attenuation
Credential-Bound:: Claim: supplied Activation: always Scope and defining sections: The mission claim on issued tokens Limitations: Fact semantics: issuance under the Mission, authority derivation, lifecycle-gated issuance; state-as-of only via the State-Observable surfaces
Authorized Context Correlation:: Claim: supplied Activation: the Delegation capability active () Scope and defining sections: The Token Exchange join at delegated issuance: the AS, as joining authority, joins the Mission and Subject carried by the Mission-bound subject_token with the delegate identity independently established by the actor_token or the delegate's own client authentication, binding both to the newly issued credential Limitations: The base grant binding at issuance co-establishes its facts and is not a join; cross-authority joins are the Mission Authority Server's machinery, not this binding's
Independently Verifiable:: Claim: supplied Activation: Mandate, signed Status, or audit companion active Scope and defining sections: Anchor recomputation and signed artifacts per those profiles Limitations: Signature verification never establishes current state
Portable Evidence:: Claim: supplied Activation: Evidence, Mandate, or audit companion active Scope and defining sections: Per those profiles Limitations: The governance record is otherwise issuer-local

Temporal elements: every issued credential's exp is capped by the record's effective expires_at; state observations carry their surface's declared freshness; the residual after non-active is the outstanding credential lifetime. Failure behavior: an unknown lifecycle state is non-active; an unresolvable reference, a failed anchor verification, and an unknown authorization_details type fail closed; where an entry's activation condition does not hold, the property is not supplied, and a consumer cannot rely on it. This document's three optional capabilities () are surfaces an implementation may or may not offer, each independent of the others. The capability list above states scoped guarantee claims: properties this document supplies and the conditions under which each is supplied. The entries below relate each optional capability to those claims. Declaring an optional capability never creates a claim beyond the eight already stated above.

Introspection:: Exercises State-Observable. One of State-Observable's three named activation surfaces, alongside Status and Signals; declaring it activates that otherwise-conditional claim.
Delegation:: Exercises Lifecycle-Gated Authorization, Structured Authority, Monotonic Derivation, Credential-Bound, and Authorized Context Correlation (). The first four are supplied always, and Delegation exercises them rather than creating them. Authorized Context Correlation is activated by this capability; its supplier is the Token Exchange join, which binds the Mission and Subject of the subject_token and the delegate's identity to the delegated credential without creating a new grant binding (). The act chain itself supplies none of these claims: it is attribution, never authority.
Cross-Domain:: Exercises Lifecycle-Gated Authorization, Structured Authority, Monotonic Derivation, and Credential-Bound. Carries these four always-supplied guarantees across the domain hop: the Mission reference and the authority_hash the projection carries, intact, authority that only narrows, and projection gated on active state, while adding an interoperable projection surface the guarantees alone do not provide. It does not become Portable Evidence by crossing a domain: that claim activates only when an Evidence, Mandate, or audit companion is active, and Cross-Domain is not among them.

Document History [[ To be removed from the final specification ]] -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 .