Mission-Bound Authorization for OAuth 2.0

1.1. 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 (Section 6.1.4).¶

Without its optional capabilities (Section 15.2), an implementation of this document needs nothing beyond its normative references and one AS-supported authorization_details type (Section 15). It turns an Approver's consent to a task's derived Authority Set into a Mission at approval and binds the Mission to the authorization code it issues (Section 6.4). Every token derived from that grant carries the Mission, every issuance is gated on its state and bounded by its Authority Set, every credential the Mission Issuer derives expires no later than the Mission, and the Mission Issuer accepts revocation by mission_id from a party its policy authorizes, independent of possession of any token (Section 10.2). Resource servers enforce the carried entries, or a scope projected from them (Section 7.7); a runtime layer that evaluates each consequential action against the Mission is out of scope (Section 17.3.1).¶

The direct realization creates each Mission at an approval interaction on the authorization endpoint, and a Mission is intended to cover one concrete task, not an agent's whole lifetime. Other creation paths are extensions (Section 14.3); [I-D.draft-mcguinness-mission-architecture] describes deployment patterns, including Mission sizing (Section "Mission Deployment Patterns").¶

2.1. Protocol Flow

The following figure shows the protocol flow between the agent (the OAuth client) and the Mission Issuer (the AS); Section 3 defines the Subject, the Approver, and the other terms:¶

 Agent (client)                       Mission Issuer (AS)
      |                                     |
      | 1. PAR: intent + proposal --------->| 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

1. Submit. The client pushes a Mission Intent describing the task, optionally with proposed authorization_details (Section 4.2). The AS derives the Authority Set, the concrete authority the task needs (Section 5).¶

2. Approve and commit. The Approver consents to that Authority Set itself, not to the task description alone (Section 6.1). The AS records the active Mission, commits the Intent as intent_hash and the approved Authority Set as authority_hash (Section 6.3.1), and binds the grant the approval produces to the Mission server-side. Any grant lineage bound to a Mission resolves to exactly that Mission, and no client input chooses it (Section 6.4).¶

3. Issue. At each token request the AS checks that the Mission is active and derives authority no broader than the approved Authority Set (Section 7.1, Section 5.4). The access token carries the derived authorization details and a mission claim identifying the Mission (Section 7.8), and a resource server enforces statelessly from the token (Section 9.1).¶

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

2.2. 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 ([I-D.draft-mcguinness-oauth-mission-resource-access]). 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 [I-D.draft-mcguinness-oauth-mission-resource-access]. 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.¶

1. 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 (Section 4.2).¶

2. 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 (Section 6.1.1, Section 6.4.1).¶

3. 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 (Section 7.3), mission_id, and mission_expires_at; the access token's five-minute lifetime is distinct from the Mission's one-hour lifetime (Section 7.3.1).¶

4. Use. The ERP is a Mission-aware Resource Server: it enforces the mission_resource_access entry itself, work a plain [RFC9068] resource server does not do (Section 15). 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 (Section 9.1).¶

5. 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 (Section 7.1.1). The already-issued access token can still be honored on this stateless path until 12:05; revocation does not undo a completed read (Section 10.2).¶

An ERP that instead introspects on every request stops honoring the token on its next request after revocation, through the composite active result (Section 9.2.2).¶

The later message examples use the end-to-end example's separate Q3 reconciliation Mission (Appendix A), whose approved authority includes invoice reads and bounded journal writes. Its identifiers and timeline differ from this introductory example.¶

3.1. Terminology

Agent (Client):

The OAuth client acting for the Mission's Subject, identified by client_id. Agent identity is established per [I-D.draft-ietf-wimse-aims] or ordinary OAuth client authentication.¶

Subject:

The user, workload, or organizational principal on whose behalf the Mission is approved (Section 6.1.4), 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 (Section 14.3). 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 (Section 6.1.8).¶

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 Section 15.¶

Mission-governed client:

A client that the deployment registers as Mission-governed ("a client registered as Mission-governed"); Section 4.3.3 states the rule that registration triggers.¶

Mission-aware Resource Server:

The resource server conformance role, defined in Section 15.¶

Resource AS:

An authorization server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources; it is never the Mission Issuer.¶

Mission Intent:

The structured description of the task the client submits (Section 4).¶

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 (Section 4.2.1).¶

Intent Submission Evidence:

Typed artifacts a client presents in support of claims about a submitted Mission Intent (Section 4.4): 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 (Section 4.3).¶

Authority Set:

The set of authorization_details entries the AS derives from a Mission Intent and the Approver approves (Section 5).¶

Authority Set derivation:

Computing the Authority Set from a Mission Intent and any authority proposal, in narrowing or configured-mapping mode (Section 5.1).¶

Derivation:

One issuance operation the issuer AS performs for a single request (Section 7.1): the initial authorization-code exchange, a refresh, a Token Exchange, or the redemption of a profile-defined grant. Distinct from Authority Set derivation, which some section titles and fixed phrases, such as "derivation policy", also call derivation.¶

Mission:

The durable authorization object that binds a disclosed task (its Mission Intent) to an explicitly approved Authority Set and governs the lifecycle of the authority derived from that approval. It is the record created at the approval event (Section 6.2), immutable except for its state and termination members, identified by a Mission Identifier (Section 6.2.5) and, globally, by the pair (issuer, id). A Mission is independent of any OAuth grant (Section 6.4). "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 (Section 6.4). Distinct from a Derived token's own mission claim, which every Derived token carries without itself creating a grant binding.¶

Mission-referenced token:

A token that carries a Mission reference (for example, a mission_id or a descriptor a companion profile defines) without Mission-derived authority or any gating guarantee. An access token of this class does not carry the mission claim (Section 7.8.1).¶

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

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 (Section 15).¶

Applicable entry:

An authorization_details entry that applies, under the entry's type, to a request to a resource server: where the type defines a resource, the request's operation target matches it under that type (Section 7.3). Section 9.1.1 governs an entry whose type the resource server does not implement, or whose type-defined enforcement it cannot complete.¶

Delegate:

A sub-agent, service, or tool, itself an OAuth client authenticated as a distinct actor, that obtains a delegated token by Token Exchange (Section 8).¶

Delegating party:

The holder of a Mission-bound access token that obtains a designation for a delegate: the Mission's approved agent, or a delegate delegating further (Section 8.1).¶

Designation:

The delegating party's authorization, obtained by Token Exchange, for one delegate to obtain delegated tokens (Section 8.1).¶

Delegated exchange (delegated token):

The Token Exchange in which a delegate redeems a designation naming it for a delegated token, whose act claim names that delegate as the current actor (Section 8.2).¶

Self-exchange (no-actor exchange):

A Token Exchange with no actor in which an agent presents its own Mission-bound access token to obtain a narrowed one; it delegates nothing (Section 7.5).¶

3.2. 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 ([I-D.draft-ietf-wimse-aims]).¶

• The Subject and Approver are each an (iss, sub) pair, matching the access token sub model of [RFC9068]. 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 (Section 14.3).¶

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 Section 6.1.3; adopting the external sub verbatim is the common case. Within the issuing AS's namespace, this (iss, sub) pair is the AS-local subject principal, authoritative for the Subject, and resource servers authorize against it.¶

The Mission separately records the Subject's home issuer and identifier as subject.iss and subject.sub: the external subject identity, carried as provenance for audit and not on the token. This document defines no runtime lookup of it.¶

The record's (subject.iss, subject.sub) and the token's (AS iss, sub) identify the same Subject in two issuer namespaces.¶

Issuer roles obey two invariants: a Mission has exactly one Mission Issuer, its issuer, and a Resource AS never creates or alters a Mission.¶

Principals are recorded at the approval event and are immutable. Two principals are equal when their iss and sub are byte-equal, so the test compares principals only within one issuer namespace and never compares the external subject identity with the AS-local subject principal.¶

Dynamic delegation (the actors an agent delegates to during execution) is carried on derived tokens in the act chain (Section 8.2), not on the Mission Record. This document uses only (iss, sub) pairs, not the subject identifier formats of [RFC9493].¶

4.1. Intent Members

The Mission Intent members are:¶

goal:

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

• It can describe the outcomes that show the task is complete; like the rest of the prose, that description carries no machine semantics (Section 5).¶

• Prose here persists on the record and can carry personal data about third parties (Section 18.4).¶

goal_lang:

OPTIONAL. A string. A BCP 47 language tag [RFC5646] 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 (Section 5).¶

• At submission acceptance, the AS MUST refuse a goal_lang that is not a well-formed language tag with invalid_request (Section 19).¶

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 [RFC8707]-style indicators or a protected resource per [RFC9728]).¶

• It bounds which resources a derived Authority Set entry may name (Section 5) and serves as a configured-mapping lookup key (Section 5.1); like purpose, the key alone grants no authority.¶

• It is not RFC 8707 resource carriage: a client separately requests the audience of a given token with the standard resource parameter (Section 7.3).¶

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 (Section 6.1.1), and carry no machine semantics (Section 5); 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 (Section 5); 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 [RFC3339] 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 (Section 6.1.1, Section 6.2).¶

• 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 (Section 6.1.1).¶

• 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 (Section 7.3.1, Section 6.2).¶

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 (Section 6.1.2.1).¶

The Mission Intent's top level is closed to the members above and to those a companion profile the AS implements defines (Section 14, Section 4.2.1).¶

The following is an example of a Mission Intent:¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

{
  "goal": "Reconcile Q3 invoices and post adjustments of at most \
    USD 500 per journal entry.",
  "target_resources": ["https://erp.example.com"],
  "task_bounds": [
    "Read only invoices issued in 2026-Q3.",
    "Post journal entries of at most USD 500 each."
  ],
  "purpose": "urn:example:purpose:reconcile",
  "expires_at": "2026-12-31T23:59:59Z"
}

4.2. Submitting a Mission Intent

A client submits a Mission Intent, with any Intent Submission Evidence, in a Submission envelope (Section 4.2.1) sent as mission_intent. On the authorization-code path, the envelope travels through a Pushed Authorization Request (Section 4.2.2); a companion profile can define another, back-channel carriage (Section 4.2.3).¶

A Mission Intent, and any authority proposal submitted alongside it (Section 4.3), 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 (Section 5).¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

{
  "intent": {
    "goal": "Reconcile Q3 invoices and post adjustments of at most \
      USD 500 per journal entry.",
    "target_resources": ["https://erp.example.com"],
    "expires_at": "2026-12-31T23:59:59Z"
  },
  "evidence": [
    {
      "type": "urn:example:intent-evidence:admission",
      "assertion": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImFkbS0xIn0..."
    }
  ]
}

4.3. Authority Proposal

A client MAY propose concrete authority for the task by submitting the standard [RFC9396] authorization_details request parameter, a JSON array of authorization_details objects, alongside mission_intent in the same pushed request (Section 4.2.2). The carriage rules of Section 4.2 apply to the proposal.¶

The submitted authorization_details is a proposal, not authority (Section 4.2); the AS derives and bounds the Authority Set from it (Section 5).¶

[
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["invoices.*"],
    "constraints": {
      "resource_issued_after": "2026-07-01T00:00:00Z",
      "resource_issued_before": "2026-09-30T23:59:59Z"
    },
    "delegation": {
      "max_depth": 2,
      "allowed_delegates": [{ "sub_profile": "ai_agent" }]
    } },
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["journal-entries.write"],
    "constraints": {
      "max_amount": { "amount": "500.00", "currency": "USD" }
    } }
]

4.4. Intent Submission Evidence

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

Processing is governed by the following rules:¶

• Refuse, do not ignore. An entry that is not a JSON object, or that lacks type, is structurally invalid and refused with the invalid_request error code at step 1 of the processing order (Section 4.5). 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 (Section 20.2). 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 (Section 6.1), 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 (Section 15.1).¶

The record's submission_evidence member (Section 6.2.2) is provenance, not enforcement input, and is not carried on the mission claim (Section 7.8). Recorded facts, such as a verified consent reference, are provenance and policy input only; a resource domain validates them under its own current policy (Section 18.4).¶

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 (Section 6.3.1, Section 14).¶

Mission Intent Submission Evidence for OAuth 2.0 ([I-D.draft-mcguinness-oauth-mission-submission-evidence]) specifies the evidence framework, including required-evidence resolution and the binding of evidence to one Intent and its presenter.¶

4.5. 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 (Section 5.1); step 8 belongs to the approval event, and step 9 to activation. Section 6.3.3 states how JSON destined for commitment is parsed, including the rejection of duplicate member names.¶

1. Parse the Submission envelope, enforce both closed top levels and the size bounds (Section 4.2), and check that each evidence entry is a JSON object with a type member (Section 4.4).¶

2. Validate the intent object against the Mission Intent member definitions (Section 4).¶

3. 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 (Section 4.3.1).¶

4. Compute the provisional intent_hash over the intent object (Section 6.3.1).¶

5. 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 ([I-D.draft-mcguinness-oauth-mission-submission-evidence], Section "Required Evidence Is Resolved Before Derivation").¶

6. Dispatch each presented entry on its type, and validate and verify it under that type's rules (Section 4.4).¶

7. Apply admission policy and derive the Authority Set independently (Section 5), including the target_resources membership of each entry that carries a resource member (Section 5.1) and, where a proposal was submitted, that each derived entry is a same-type subset of a proposed entry (Section 4.3.2).¶

8. 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 (Section 6.1).¶

9. At activation, record the approved intent, the Authority Set, and the verified evidence facts as submission_evidence (Section 6.2).¶

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

• a malformed proposal together with a missing required evidence type is refused at step 3, with invalid_authorization_details;¶

• a proposed entry outside target_resources together with a presented evidence entry that fails verification is refused at step 3, with invalid_request;¶

• an intent object that fails validation together with a malformed proposal is refused at step 2, with invalid_request; and¶

• a structurally invalid evidence entry together with a malformed proposal is refused at step 1, with invalid_request.¶

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

5.1. Derivation Modes

Derivation is governed by local policy: different authorization servers can derive different Authority Sets from the same Mission Intent, and interoperability begins at the derived Authority Set and its integrity anchors (Section 6.3.1).¶

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 (Section 4.3), and the Authority Set is the proposal narrowed to policy. Each derived entry is a same-type subset of a proposed entry (Section 4.3.2).¶

• Configured-mapping mode: no authority proposal was submitted, and a deployment-configured mapping, keyed on the Intent's purpose or target_resources, or on the requested scope values for a scope-only target (Section 7.7), yields the candidate entries, which are then narrowed to policy.¶

  The mapping is a lookup, not synthesis, and no key grants authority by itself. Because no authorization_details object was submitted, the AS refuses an Intent that matches no configured mapping, or whose mapped candidates policy narrows to nothing, with access_denied (Section 11). 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 (Section 6.1.1), so a refusal at PAR time is best-effort over what is checkable without the Subject.¶

  Every Mission this mode yields takes its own fresh approval; activation under standing consent (Section 14.3) is not this mode.¶

In either mode, narrowing a candidate entry needs a declared narrowing capability for its type; without one, the entry is retained unchanged or omitted (Section 5.5.1).¶

Authority Set derivation can run provisionally during submission processing, where the inputs it needs are available (Section 4.5). The candidate Authority Set is complete before the approval rendering (Section 6.1.1), and a change that Section 6.1.6 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 (Section 6.1.1), 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 (Section 4.3.1).¶

A later token issuance is bounded by the subset rule against the Authority Set (Section 5.4), not by the target list again. A type whose subset relation admits a narrower resource can yield a token entry that target_resources does not name, and a candidate outside every Authority Set entry fails that rule.¶

Where recorded, the Mission's policy_version names the policy version in force (Section 6.2).¶

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 (Section 5.4), 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 (Section 11).¶

When an omission or a narrowing leaves the Authority Set short of what was proposed (Section 4.3.2), Authority Set derivation is partial. The token response states what was granted (Section 7.3).¶

5.2. 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 (Section 6.1.1). The Intent's members describe and bound the task but grant no authority by themselves (Section 4): 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 (Section 4).¶

A client-proposed constraint on an individual Authority Set entry enters through the authorization_details proposal: constraints a supported type's specification defines, and the collision-resistant deployment extensions the AS understands (Section 14).¶

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 (Section 6.1.1) as the human check that the structure matches the words, not as a machine enforcement mechanism.¶

5.3. Authority Set Example

The following is an example of an Authority Set. The read entry is delegable to depth 2 and bounded to a Q3 issuance window by the resource_issued_after and resource_issued_before Common Constraints ([I-D.draft-mcguinness-oauth-mission-resource-access]); the write entry carries no delegation and so is non-delegable, because delegation is per entry:¶

[
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["invoices.read"],
    "constraints": {
      "resource_issued_after": "2026-07-01T00:00:00Z",
      "resource_issued_before": "2026-09-30T23:59:59Z"
    },
    "delegation": {
      "max_depth": 2,
      "allowed_delegates": [{ "sub_profile": "ai_agent" }]
    } },
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["journal-entries.write"],
    "constraints": {
      "max_amount": { "amount": "500.00", "currency": "USD" }
    } }
]

5.4. 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; Section 5.5 states the general rule and each supported type defines its own relation. The AS MUST refuse to derive an entry that is not a subset, under its type's relation, of some Mission Authority Set entry.¶

The AS MUST refuse a request that would widen authority under a Mission after the approval event on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation); broader authority requires a fresh approval event and a new Mission.¶

The comparison is representational, not semantic. A candidate that compares as no broader can still permit effects the parent's purpose never contemplated; semantic narrowing is not a property this rule can provide.¶

Where the comparison relation cannot decide (an unrecognized member, an incomparable value), the posture is conservative refusal, as each consuming rule of this document states. At the token endpoint, where the comparison cannot establish that a requested authorization_details entry is a subset, the AS MUST refuse the request with the invalid_authorization_details error code, as for an entry that exceeds the grant (Section 11).¶

An entry equal to its reference entry, byte-identical under the canonical form of Section 6.3.2, 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 (Section 5.5).¶

5.5. Authorization Details Types

The Authority Set MAY include any AS-supported [RFC9396] authorization_details type an audience consumes; this document defines no type itself. "Supported" here means the AS recognizes and documents the type: it appears in authorization_details_types_supported or, where the AS advertises the schema endpoint, as a key in its authorization_details_types_metadata_endpoint response, which is then the source of truth for the supported set (Section 12). 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 (Section 5.4, Section 8.4), under the transformation capabilities the AS declares for the type (below); and¶

• evaluating the entry against a concrete request is the responsibility of the resource server, under the entry's type (Section 9.1.1), or of a composing runtime layer (Section 17.3.1), not the AS's.¶

6.1. 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, Section 6.2) 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 (Section 14.3), the instance is decided under an accountable human's earlier approval, with no fresh human approval.¶

6.2. Mission Record

A Mission is the durable record created at the approval event; a Mission Identifier (Section 6.2.5) identifies it. Its members MUST NOT be changed after creation, except state and the termination member written once when the Mission terminates (Section 10.1).¶

The record is a logical object: this document constrains its members and their values and requires no storage form. Where a surface or profile exchanges or signs the record, the record's JSON form, with the members this section defines, governs.¶

Record member names omit the mission prefix, which marks surfaces that reference a Mission from outside it, such as the mission_id response parameter. They are spelled out (issuer, expires_at, created_at) and spelled identically on every surface; the compact JWT names (iss, exp, iat) belong to a signed artifact's own envelope or to an {iss, sub} party object, not the Mission.¶

Like the mission claim (Section 7.8), the record is open (Section 14): a companion profile of this document MAY record additional members set at creation using short names coordinated with it (for example, a lineage member linking the Mission to a predecessor or parent); any other extension MUST use collision-resistant names. A consumer does not interpret a member it does not recognize, and does not remove it from a record it retains or commits.¶

The following subsections define the record's members. The record's required members are its invariants: id, issuer, state, intent, authority_set, subject, approval_basis and authority_source with the members each requires, client_id, approval_event_id, created_at, and expires_at, and, under the condition each states, termination, proposed_authority, submission_evidence, and policy_version. The integrity anchors intent_hash, authority_hash, and proposal_hash are implied members (Section 6.2.2). Every other member is optional or defined by the profile that uses it.¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

{
  "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": {
    "goal": "Reconcile Q3 invoices and post adjustments of at most \
      USD 500 per journal entry.",
    "target_resources": ["https://erp.example.com"],
    "task_bounds": [
      "Read only invoices issued in 2026-Q3.",
      "Post journal entries of at most USD 500 each."
    ],
    "purpose": "urn:example:purpose:reconcile",
    "expires_at": "2026-12-31T23:59:59Z" },
  "proposed_authority": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.*"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ],
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ],
  "authority_hash":
    "sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM",
  "intent_hash":
    "sha-256:6T-7s_f-mNW9UpfrrZh3r0HRJmU4My_EsNAf1C1U4r0",
  "proposal_hash":
    "sha-256:p-s-EzdNQTn6RoPHXESkwVtGdk8yL1PxryNyMwroKGo",
  "subject": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "approval_basis": {
    "type": "direct",
    "consent_principal": { "iss": "https://idp.example.com",
      "sub": "user_3p2q8mN1a0kV7tR" },
    "activation": { "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z" },
    "activation_actor": { "iss": "https://idp.example.com",
      "sub": "user_3p2q8mN1a0kV7tR" },
    "adjudication": { "kind": "human" },
    "root_commitment":
      "sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM"
  },
  "authority_source": { "type": "user_delegated" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z",
  "created_at": "2026-11-02T08:00:00Z",
  "expires_at": "2026-12-31T23:59:59Z"
}

{
  "subject": { "iss": "https://login.example.com",
    "sub": "agt_ledger_reconciler" },
  "client_id": "ledger-reconciler",
  "authority_source": { "type": "service_owned" },
  "approval_basis": {
    "type": "direct",
    "consent_principal": { "iss": "https://login.example.com",
      "sub": "adm_4Hq9Tz" },
    "activation": { "approval_event_id": "ape_2Lw7Kq9Rv4" },
    "activation_actor": { "iss": "https://login.example.com",
      "sub": "adm_4Hq9Tz" },
    "root_commitment":
      "sha-256:R6tY2nD9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQo"
  }
}

6.3. Integrity and Commitments

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

6.4. Binding the Mission to the Grant

A Mission is independent of any OAuth grant: it is identified globally by the pair (issuer, id) (Section 6.2), 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 (Section 7.8).¶

The Mission grant binding is an AS-controlled, functional mapping from one persistent, redeemable grant lineage to exactly one Mission. The AS alone establishes a binding and resolves it from the grant itself; a client never supplies or negotiates one, and no client input determines its Mission.¶

A grant lineage is state the AS can resolve again on a later request, either:¶

• the authorization code issued at approval and, where its redemption emits one, the refresh-token family that follows it; or¶

• another profile-defined reusable grant, such as a refresh-token family a Token Exchange establishes later for the same Mission (Section 6.4.2).¶

7.1. Issuance Gating

A derivation is one issuance operation the issuer AS performs for a single request: the initial authorization-code exchange, a refresh, a Token Exchange, or the redemption of a profile-defined grant.¶

This document defines five issuance paths:¶

• code redemption, the token response that redeems a newly created Mission's authorization code (Section 6.1.7);¶

• a refresh (Section 7.4);¶

• a designation (Section 8.1);¶

• a delegated exchange (Section 8.2); and¶

• a self-exchange (Section 7.5).¶

Designation and the delegated exchange belong to the optional Delegation capability, and self-exchange is optional too (Section 15.2).¶

Each of these paths passes every check below. Each check is stated in the sections it cites, with any difference by path, and a path's own section states its further rules. Any other derivation, such as one a companion profile defines, passes at least checks 1, 3, 5, and 7, the exp bound of check 8, and check 10.¶

The numbering is presentation order only: it imposes no execution order and no error precedence (Section 11 gives the error codes). An order that a rule states still applies, including these:¶

• The Mission-governed refusal applies only to an otherwise processable request. On a refresh, it is decided before the refresh token is consumed or rotated (Section 4.3.3).¶

• A refresh establishes any scope projection before the refresh token is consumed or rotated, or within the same atomic issuance (Section 7.7.6).¶

• A delegated exchange authenticates the client before it refuses an actor_token (Section 8.2).¶

• The revocation refusal applies at the AS's final decision to release the result (check 10).¶

• A companion profile that sequences a check within a path keeps that sequence.¶

The checks are:¶

1. Mission resolution from the presented grant (Section 6.4.1): the code, the refresh token, or the subject_token, which on a delegated exchange is the designation.¶

2. Client and sender binding, as the path's section states for the code (Section 6.1.7), the refresh token (Section 7.4), the token a designation request presents (Section 8.1), the delegate (Section 8.2), and the self-exchanging agent (Section 7.5).¶

3. Mission state: the Mission is active (Section 7.1.1, Section 10). A delegated exchange evaluates each redemption afresh (Section 8.2).¶

4. Mission-governed resources (Section 4.3.3). A refresh, a self-exchange, or a designation request needs no mission_intent.¶

5. Subset (Section 5.4): against the Mission Authority Set, and also against the presented refresh grant on a refresh, the presented token on a designation or a self-exchange, and the designation on a delegated exchange; on a designation or a delegated exchange, only as Section 8.4 permits. An entry is narrowed, issued to another audience, delegated, or projected only under a declared capability (Section 5.5.1).¶

6. Audience (Section 7.2, Section 7.3, Section 5.5.1): by each entry's original approved audience. For a designation, the check uses the resource audiences of its entries, not the client its aud names. For a delegated token, the audience is also one that processes the act chain (Section 9.1.2).¶

7. Scope projection (Section 7.7), wherever scope is emitted, requested, or the only form the target consumes. On a refresh, it applies with that section's protection of the refresh token.¶

8. Claims and lifetime (Section 7.2, Section 7.8, Section 7.8.1, Section 7.6). Each token's exp does not exceed the Mission's expires_at. A designation, a delegated exchange, and a self-exchange keep the presented token's mission claim, with the differences Section 8.1 and Section 8.2 state.¶

9. Response members: the response echoes the granted authorization_details (Section 7.3) and carries mission_id and mission_expires_at as Section 7.3.1 states.¶

10. Release: the revocation refusal (Section 7.1.1) applies at the AS's final decision to release the result.¶

7.2. Token Claims

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

• carries the token's Mission-derived authority as authorization_details ([RFC9396]); this MAY be the full Authority Set or a narrowed subset (Section 5.4);¶

• carries a mission claim (Section 7.8);¶

• sets sub to the AS-local sub the AS maps the Mission's Subject to (Section 6.1);¶

• carries client_id with its ordinary meaning (Section 4.3 of [RFC8693], Section 2.2 of [RFC9068]): 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 (Section 7.3, Paragraph 1), except that a token the AS issues only for presentation back to itself at a Token Exchange, such as a designation (Section 8.1), names in aud the client that presents it;¶

• MAY carry an act claim when the agent has delegated execution (Section 8.2);¶

• MAY carry a scope claim, subject to Section 7.7; and¶

• can be sender-constrained, as Section 2.2.1 of [RFC9700] recommends, via a cnf claim [RFC7800]: DPoP [RFC9449] (cnf.jkt) or mTLS [RFC8705] (cnf.x5t#S256).¶

A Mission-bound access token that is not a delegated token may be a bearer token, preserving compatibility with bearer-only resource servers while retaining Section 2.2.1 of [RFC9700]'s recommendation; the cost is the stolen-token exposure (Section 17.4.1).¶

A delegated token is sender-constrained to the delegate's own key (Section 8.2), and the Cross-Domain capability sender-constrains every credential that crosses a trust domain (Section 15.2).¶

An AS that issues Mission-bound JWT access tokens for resource servers to consume MUST publish its token verification keys (for example, at its [RFC8414] jwks_uri, as Section 4 of [RFC9068] recommends); rotation retires a key from signing, never from resolvability while tokens signed under it remain valid. A token the AS issues only for presentation back to itself, such as a designation (Section 8.1), creates no publication duty by itself.¶

7.3. Audience and Token Response

A token-endpoint resource value outside the Authority Set is an invalid resource value in the sense of [RFC8707].¶

Three identifiers stay distinct. An entry's resource, where its type defines one, names the protected resource its authority covers, and a resource server matches each request's operation target against it under the entry's type. A token request's resource parameter ([RFC8707]) selects the audience the client asks for. The token's aud names the recipients that accept the token, and the AS relates an entry to them through the entry's original approved audience (Section 5.5.1).¶

A token issued for an audience carries only the entries whose original approved audience includes that audience; an entry approved for another audience is not carried, unless a declared narrowing capability permits issuing it there. A token whose aud names several audiences is issued only where the same entries are approved for each of them; where they differ, the AS refuses the request with invalid_target, and the client requests a separate token for each audience. The AS also refuses with invalid_target a request whose audience is approved for none of the entries the token would carry, and one whose authorization_details (Section 6 of [RFC9396]) names an entry not approved for its audience.¶

Section 8.1 states how these rules apply to a designation and to the delegated token issued at its redemption.¶

The AS returns the granted authorization_details in every token response, including refresh and Token Exchange responses (Section 7 of [RFC9396]). Strengthening Section 7 of [RFC9396], 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 (Section 4.3). A client MUST NOT assume authority absent from the granted set. An entry the echo narrows grants the narrower authority it states, and a client need not reject a grant narrower than its proposal. The mission_id and mission_expires_at response parameters carry the Mission reference and expiry beside it (Section 7.3.1).¶

The following is an example of a refresh request that narrows the canonical ERP Mission (the worked example of Section 6.2) to a read-only token with the [RFC8707] resource parameter and the authorization_details parameter (Section 6 of [RFC9396]). The ERP consumes authorization_details, so a resource scope for it would be refused (Section 7.7). Extra line breaks are for display purposes only:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

grant_type=refresh_token
&refresh_token=rt_4mN8qV2xP7sL1tY9zB3k
&resource=https%3A%2F%2Ferp.example.com
&authorization_details=%5B%7B%22type%22%3A%22mission_resource_acc...

The authorization_details value, before form encoding, requests the Mission's read entry alone:¶

[
  { "type": "mission_resource_access",
    "resource": "https://erp.example.com",
    "actions": ["invoices.read"],
    "constraints": {
      "resource_issued_after": "2026-07-01T00:00:00Z",
      "resource_issued_before": "2026-09-30T23:59:59Z"
    },
    "delegation": {
      "max_depth": 2,
      "allowed_delegates": [{ "sub_profile": "ai_agent" }]
    } }
]

The issuance is a derivation, gated on the Mission being active (Section 7.1). 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 (Section 7.3.1). The emitted entry is a subset (Section 5.4) of the Mission's read entry, its constraints carried intact:¶

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "DPoP",
  "expires_in": 300,
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "mission_expires_at": "2026-12-31T23:59:59Z",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } }
  ]
}

7.4. Refresh Tokens

Issuance on a refresh applies the issuance procedure of Section 7.1 as it states for a refresh. Section 4.3.3 states a refresh's exemption from mission_intent and, for a Mission-governed resource, the refusal's precedence and its timing relative to consuming or rotating the refresh token.¶

A Mission-bound refresh token is bound to the client it was issued to. For a confidential client, client authentication supplies the binding: on refresh, the AS authenticates the client and verifies that the refresh token was issued to it (Section 6 of [RFC6749]), so the token need not also be bound to the DPoP proof key (Section 5 of [RFC9449]). A public client's refresh token MUST be sender-constrained or use refresh token rotation (Section 2.2.2 of [RFC9700]).¶

The AS can rotate either client type's refresh token; rotation detects replay of a consumed refresh token (Section 4.14.2 of [RFC9700]) and is not a cryptographic binding.¶

A refresh request can carry authorization_details to narrow the issued token (Section 6 of [RFC9396]). 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 (Section 5.4), and MUST NOT instead issue a narrower set than the one requested.¶

7.5. Self-Exchange Down-Scoping

An agent MAY present its own Mission-bound access token as the subject_token of a Token Exchange ([RFC8693]) 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 (Section 8.1) names a delegate, so it is not a self-exchange, and these rules do not apply to it. An exchange whose subject_token is a designation is a delegated exchange (Section 8.2), not a no-actor exchange, even when it carries no actor_token. Issuance applies the issuance procedure of Section 7.1 as it states for a self-exchange. Section 4.3.3 states a self-exchange request's exemption from mission_intent and the checks that still apply to it. A no-actor exchange is subject to the following:¶

1. The AS MUST refuse a no-actor exchange with the invalid_request error code (Section 2.2.2 of [RFC8693]) unless the authenticated client is the Mission's approved agent (the Mission Record's client_id, Section 6.2). A delegate narrows only through a delegated exchange that names it in the act chain.¶

2. The result MUST be a subset (Section 5.4) of the presented token's authority; it carries the same mission claim (Section 7.8) and adds no act chain.¶

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

7.6. 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 Section 2.2.1 of [RFC9068]: 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 (Section 6.1.2). 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 (Section 7.7) is a compatibility projection that cannot carry per-entry constraints.¶

A credential the Mission Issuer derives MUST have an exp that does not exceed the Mission's expires_at, so that no credential outlives the approved Mission.¶

Within that bound, a derived token's lifetime is the AS's policy, which Section 7.1.3 recommends keeping short. Token Exchange does not tightly couple an issued token's lifetime to its subject_token's (Section 2.1 of [RFC8693]); Section 8.1 states how this applies to a designation and to the delegated token issued from it.¶

7.7. Scope Projection

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

7.8. Mission Claim

The mission claim is a JSON object:¶

id:

REQUIRED. A string. The Mission Identifier (Section 6.2.5).¶

issuer:

REQUIRED. A string. The Mission's issuer (Section 6.2). 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 (Section 7.8.1).¶

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 (Section 6.2), in RFC 3339 [RFC3339] 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 (Section 10).¶

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 (Section 9.1); approval_basis.type is provenance, not authority (Section 6.2). An authorized introspection caller can receive authority_hash and approval_basis.type (Section 9.2.1).¶

The mission claim is an open object (Section 14): 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 Section 4.2 of [RFC7519]) 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:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1793606405,
  "exp": 1793606705,
  "jti": "at_9Kp2vN7sR1tY8mZ3qX5b",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ],
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com"
  }
}

8.1. 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 ([RFC8693]): 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 (Section 8.4).¶

Issuing a designation applies the issuance procedure of Section 7.1 as it states for a designation. A designation request is a token request under an existing Mission-bound grant (Section 4.3.3): it needs no mission_intent, and every other check that section names still applies to it.¶

A designation the AS issues:¶

• carries a subset (Section 5.4) of the presented token's authority, and the same mission claim (Section 7.8);¶

• has aud equal to the designated client's identifier, and a may_act claim (Section 4.4 of [RFC8693]) whose sub is that identifier;¶

• carries no cnf and no act claim: like an authorization code, it is bound to the client that redeems it, which authenticates and proves its own key in the delegated exchange (Section 8.2), and the delegated token's act renders the AS's accounting (Section 8.4); and¶

• MUST expire shortly after it is issued, and no later than the presented token or the Mission's expires_at.¶

A designation's aud names its redeemer and reassigns no entry's original approved audience (Section 5.5.1). For a designation, the audience rules of Section 7.3 test the resource audiences associated with the entries it carries, never the designated client its aud names (Section 7.2). A designation carries only a permitted subset of the presented token's entries (Section 5.4, Section 8.4), each keeping its original approved audience (Section 5.5.1). An entry without an original approved audience is not carried, and a designation that would carry no entry is refused with invalid_target. Its redemption issues an entry only as Section 5.5.1 and Section 8.2 permit, including their narrowing condition. The delegated token issued at its redemption is subject to every rule of Section 7.3 unchanged.¶

A designation names a delegate and adds none. Whether one may be redeemed more than once within its lifetime is the AS's policy; each redemption is a delegated exchange of its own (Section 8.2). Its expiry bounds when it can be redeemed, not the lifetime of a delegated token issued from it (Section 7.6). That delegated token can outlive both the designation and the credential the designation was derived from. Revoking the grant state backing that credential still refuses every later redemption (Section 8.2).¶

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 (Section 2.2.2 of [RFC8693]), a designation request naming a client for which it cannot establish that separation. A resource server that validates a JWT access token's audience (Section 4 of [RFC9068]) therefore rejects a designation, and at introspection (Section 9.2.2) the AS MUST return active: false for one, with no mission member.¶

8.2. Delegated Exchange

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

• The exchange is explicit. The subject_token is a designation this AS issued naming the authenticated requesting client (Section 8.1), 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 (Section 2.2.2 of [RFC8693]); an access token issued for resource access is never sufficient. The delegate is identified by its own client authentication, and the AS asserts the actor itself (Section 8.4).¶

• The delegate authenticates. The AS MUST authenticate the requesting client, whether or not the request carries an actor_token, by a method it relies on to identify the client (Section 2.3 of [RFC6749]), and MUST refuse a client it does not so authenticate with invalid_client (Section 5.2 of [RFC6749]), issuing no token. Once it has so authenticated the client, the AS MUST refuse a request that carries an actor_token with invalid_request (Section 2.2.2 of [RFC8693]), issuing no token. A claimed client_id, possession of the designation, or proof of an independently chosen key, such as a DPoP key, does not authenticate a client. This document does not support a public client as a delegate: Section 2.3 of [RFC6749] lets an AS establish a client authentication method with a public client but not rely on it to identify the client. Only an extension that defines an explicit binding of a designation to its delegate admits one; deployment policy alone does not.¶

• Subject is stable. sub remains the Mission's Subject. The delegate is an actor, not the Subject.¶

• client_id keeps its ordinary meaning. It names the client that requested the token (Section 7.2); the originally-approved agent stays in the Mission Record (Appendix C.3).¶

• The act chain identifies the delegates. The delegated token carries an act claim per Section 4.1 of [RFC8693] and the Actor Profile [I-D.draft-mcguinness-oauth-actor-profile]: the outermost act is the current delegate, and each earlier delegate is nested in the previous actor's act member. Each actor object carries the members that profile defines (for example, sub, iss, and the sub_profile actor-type classification, such as ai_agent).¶

• The audience processes the chain. The AS issues the delegated token only for an audience that meets the issuance rule of Section 9.1.2, and refuses any other with invalid_target.¶

• Authority only narrows. The delegated token's authorization_details MUST be a subset (Section 5.4) of the designation's authority, hence of the delegating token's and of the Mission Authority Set. A type that declares delegation without narrowing (Section 5.5.1) is delegable only unchanged: the AS MUST NOT include an entry of such a type in a delegated token unless it is equal (Section 5.4) to an entry of the presented delegating token, it keeps that entry's approved audience, and the type's delegation policy permits the delegate (Section 8.4). The reference is the presented token, not the Mission Authority Set, so equality never restores an entry, or any part of one, that the presented token omits.¶

• The mission claim is unchanged. The delegated token carries the delegating token's mission claim (Section 7.8) 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 (Section 7.2) 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 (Section 7.1.1). The AS MUST evaluate every redemption of a designation afresh, as a derivation of its own: the credential the designation was derived from, and all applicable grant state backing that credential, are still valid; the Mission is active; and the delegation policy (Section 8.4) and the Mission's current authority admit the result. An earlier redemption establishes none of these. Where that credential was issued under a grant lineage, the backing grant state includes that lineage, kept through any exchange that established no new grant lineage (Section 6.4.2). A credential issued under none has no lineage to validate; that never excuses dropping or ignoring a lineage that does exist. The Mission's active state never substitutes for backing grant state.¶

A delegated exchange response MUST carry mission_id and mission_expires_at (Section 7.3.1), because the delegate did not receive the response that created the Mission.¶

The act chain nests (act.act) for as long as, and only while, authority continues under the same approved Mission. A new approval basis, such as a Mission created from an existing Mission's authority (Section 6.4.2), 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 Section 8.4 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 (Section 5.4), not the chain, show that authority narrowed.¶

8.3. Instance Context in Delegated Tokens

Where a deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-id], with attesters a client endorses under [I-D.draft-mcguinness-oauth-client-attesters]), the delegate named by the outermost act can be an actor that an authenticated instance represents. Instance evidence does not establish that actor (Section 5 of [I-D.draft-mcguinness-oauth-client-instance-id]), 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 (Section 8.2), and the Actor Profile makes the top-level cnf the current presenter's key ([I-D.draft-mcguinness-oauth-actor-profile]), that cnf is a key the instance possesses.¶

A deployment MAY convey client_instance in delegated tokens under [I-D.draft-mcguinness-oauth-client-instance-id]. 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 Section 5 of [I-D.draft-mcguinness-oauth-client-instance-id], 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 Section 7.1 of [I-D.draft-mcguinness-oauth-client-instance-id]. 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 Section 8.2 and Section 8.4 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. Section 11 gives the error codes for these refusals.¶

• If the exchange issues a refresh token, and so establishes a redeemable grant lineage (Section 6.4.2), the grant-continuity rules of Section 5.1 of [I-D.draft-mcguinness-oauth-client-instance-id] apply alongside Section 6.4; 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 [I-D.draft-mcguinness-oauth-client-instance-id]. A consumer requiring attribution rejects unestablished associations under Section 7.6 of [I-D.draft-mcguinness-oauth-client-instance-id].¶

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

8.4. Delegation Constraints

What may be delegated, how far, and to whom is governed per Authority Set entry by a type-defined delegation policy (Section 5.5). For mission_resource_access, the policy is the delegation member, whose concrete depth and matcher conditions the Mission Resource Access Profile defines ([I-D.draft-mcguinness-oauth-mission-resource-access]).¶

Because the policy lives in the entry, authority_hash commits it with the rest of the Authority Set.¶

Delegation depth. The delegation depth of a token is the number of delegations between the approved agent and the token's current actor: the agent's own non-delegated token is depth 0, the first delegate is depth 1, and each further delegate adds 1. The depth checked against max_depth is that of the token being issued, computed after appending the new outermost actor, not the depth of the delegating token.¶

Depth accounting. The AS MUST establish delegation depth from accounting it maintains for the tokens it issues under the Mission and associates with the credential it validates (for example, recorded at issuance against the token), not from the nesting of a presented act claim. The act chain is attribution (Section 8.2): it renders the accounted chain and is not the source of the count.¶

Over the exchanges this document defines, the accounting is complete:¶

• each delegated exchange adds exactly one delegate; and¶

• a designation (Section 8.1) and a self-exchange (Section 7.5) add none.¶

A profile that issues Mission-bound tokens by another path specifies how it preserves or reconstructs this accounting and any reset it defines.¶

Where the AS cannot establish the depth of the token being issued, no entry's delegation policy can be evaluated at that depth, so every entry narrows out under the per-entry rule below and the exchange is refused as an empty result. A resource server bases no authorization decision on a prior actor (Section 4.1 of [RFC8693]).¶

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:¶

1. The entry's type defines a delegation policy for the entry. An entry carrying no type-defined delegation policy is non-delegable, the default.¶

2. 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 (Section 5.4). 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 (Section 2.2.2 of [RFC8693]) 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 (Section 9.1).¶

8.5. 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:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "tool-runner-7",
  "iat": 1793607005,
  "exp": 1793607305,
  "jti": "at_3qX5bN7sR1tY8mZ9Kp2v",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } }
  ],
  "act": {
    "sub": "tool-runner-7",
    "iss": "https://as.example.com",
    "sub_profile": "ai_agent"
  },
  "cnf": { "jkt": "Inaz7NtW9__w8ZNhk-CB7X_Y1G-XSCRAYT4oBffaS_0" },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com"
  }
}

The sub claim is still the user. The client_id claim is tool-runner-7, the delegate that authenticated the Token Exchange and requested this token (Appendix C.3); it matches the outermost act only because tool-runner-7 authenticated the exchange itself. The client_id claim does not name s6BhdRkqt3, the originally-approved agent, whose identity remains recoverable from the Mission Record via mission_id (Section 6.2).¶

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

9.1. 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 Section 4 of [RFC9068], and any sender-constraint binding (cnf) per Section 7.1 of [RFC9449] or Section 3 of [RFC8705], locally, even when it introspects (Section 9.2.2).¶

An opaque Mission-bound token is enforced from its active introspection response or issuer-local resolution instead, under the same rules (Section 9.2.4).¶

9.2. Mission State via Token Introspection

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

• JWT state observation. A resource server that observes Mission state per request introspects the JWT Mission-bound token it holds, instead of waiting for the token to expire.¶

• Opaque-token consumption. For an opaque Mission-bound token, introspection is the claims carriage: an active response carries what the JWT would (Section 9.2.4).¶

• 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 (Section 9.2.4).¶

The cases separate token representation from state freshness. Representation is where a resource server reads the token's authority: the JWT itself or, for an opaque token, its active introspection response or issuer-local resolution. Freshness is how recent its view of Mission state is: a JWT read alone shows only that the Mission was active when the token was issued; an introspection response reports the token and its Mission for one decision; and a state-distribution companion reports the Mission's state, not a token's, with its own freshness. In every case the authority a resource server enforces is the one the token carries (Section 9.1.1).¶

An AS MAY support OAuth 2.0 Token Introspection [RFC7662] for Mission-bound access tokens. When it does, an active: true response for such a token, to a caller authorized to receive Mission data (Section 9.2.1), MUST carry, in addition to the standard members, a mission member: a JSON object with the following members:¶

• id and issuer: as in the mission claim (Section 7.8).¶

• 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 Section 10.¶

• termination: when state is terminated, the Mission's termination (Section 10.1) (object).¶

• proposal_hash: when the Mission records an authority proposal, the Mission's proposal_hash (Section 6.2) (string).¶

• authority_hash: the Mission's Authority Set commitment (Section 6.2) (string).¶

• approval_basis: the Mission's approval_basis (Section 6.2), carrying type only.¶

• authority_source: the Mission's authority_source (Section 6.2), 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 (Section 9.2.3). The last four are audit and correlation signals, not enforcement inputs (Section 9.1); each is disclosed only as Section 9.2.1 permits.¶

For a malformed, unknown, individually expired, or otherwise unresolvable token, the AS responds per [RFC7662] (active: false) with no mission member; it does not reveal Mission state for a token it cannot bind to a Mission. The AS discloses a mission member only for a token it has established was issued on a path that conforms to Section 7.8.1; a token it cannot establish so is unresolvable in this sense. How the AS establishes this is its own; a record of its own issuance is one means.¶

The composite-active rule (Section 9.2.2) and the mission member apply equally when a Mission-bound refresh token is introspected.¶

Freshness is per use. Strengthening Section 4 of [RFC7662], 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 ([I-D.draft-mcguinness-oauth-mission-status]).¶

{
  "active": true,
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "aud": "https://erp.example.com",
  "exp": 1793606705,
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "constraints": {
        "resource_issued_after": "2026-07-01T00:00:00Z",
        "resource_issued_before": "2026-09-30T23:59:59Z"
      },
      "delegation": {
        "max_depth": 2,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM",
    "proposal_hash":
      "sha-256:p-s-EzdNQTn6RoPHXESkwVtGdk8yL1PxryNyMwroKGo",
    "state": "active"
  }
}

{
  "active": false,
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM",
    "state": "terminated",
    "termination": {
      "reason": "revoked",
      "terminated_at": "2026-11-02T08:53:20Z"
    }
  }
}

10.1. 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 (Section 20.8): 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 [RFC3339] date-time: the instant the termination took effect. For expired, it is the Mission's expires_at.¶

A companion profile that registers a reason defines that reason's further members. A profile that maintains a state version for the Mission adds the version of the transition that committed the termination as its audit reference.¶

The issuer writes termination once, atomically with the transition to terminated, and MUST NOT change it: an expiry, or any later event, does not replace the reason or references of a Mission already terminated.¶

A termination carries every member its reason requires, except as follows.¶

A termination need not carry a member its reason requires when it was recorded before its reason defined that member, or derived from such a termination: such a termination exposes only the facts its record retained and omits a member it has no retained value for, terminated_at included, rather than inventing one. For expired, the retained terminated_at is the Mission's expires_at; for another reason, a retained commit time is its terminated_at only where that commit was the termination's effect.¶

A consumer that receives such a termination, or a reason it does not recognize, still treats the Mission as terminated: it stops work governed by the Mission, follows no absent reference, and infers no cause-specific action.¶

10.2. Revocation

A Mission is revoked when the AS receives a revocation for it from a party the deployment's policy authorizes to revoke it, or when that policy itself terminates the Mission; either way, its termination reason is revoked. The Subject, the Approver, and an administrator are parties that policy can authorize; none is authorized by its role alone. A Mission Issuer MUST accept, through an authenticated means independent of possession of any token, a revocation by mission_id from a party the deployment's policy authorizes (so a Mission can be stopped even when no refresh token is held).¶

The wire shape of that revocation is out of scope for this document. A deployment-defined surface that authenticates the revoking party independent of possession of any token satisfies this requirement.¶

When the AS establishes that the principal identified by a Mission's recorded subject (Section 6.2.3) has been deprovisioned, it SHOULD terminate that Mission with termination reason revoked. The rule reaches every Mission not yet terminated, including one a companion profile has suspended, and identifies the Subject by its recorded iss and sub. Temporary disablement, a source outage, or an unavailable lookup does not by itself establish deprovisioning. The departure or disablement of an Approver, an accountable owner, or a client triggers the rule only when that principal is the recorded Subject; an organizational Mission records the organizational principal as its Subject (Section 6.1.4), so an approving officer's departure does not terminate it under this rule. A deployment that does not follow this rule documents why; that exception cannot bypass a continuing dependency the deployment requires or rewrite the recorded Subject. Termination stops further issuance (Section 7.1.1) but does not itself recall tokens already issued; an earlier execution cutoff depends on the deployment's enforcement mechanism.¶

Revoking a token does not by itself revoke a Mission. Section 2.1 of [RFC7009] lets an authorization server's revocation policy extend a token's revocation to related tokens and the underlying grant; a deployment's revocation policy can likewise treat revoking a Mission's refresh token as revoking the Mission; a deployment that couples token revocation to Mission revocation documents that behavior.¶

Token validity and Mission validity are distinct: a consumer that enforces from the token alone can honor an issued access token until it expires (Section 7.1.3), and one that checks Mission state refuses it when that check reports a non-active state, under the mechanism's freshness rules. A deployment whose consumers rely on Mission state beyond a token's lifetime offers token introspection (Section 9.2) or Mission Status ([I-D.draft-mcguinness-oauth-mission-status]), so they read current state rather than infer it from token validity.¶

14.1. Extension Points

This document's extension points are:¶

• Authority types. The Authority Set is open to any AS-supported authorization_details type (Section 5.5); the Mission apparatus (commitment, gating, delegation) is type-agnostic, subject to the delegation and projection limits in Section 5.5, and an entry of a type the AS does not support is refused (Section 4.3.1). A type's specification supplies what the apparatus relies on for its entries:¶

  • the definition a proposed entry is validated against, alongside any schema advertised for the type or established out of band (Section 4.5);¶

  • the enforcement semantics a resource server applies to an entry (Section 9.1.1);¶

  • the subset relation, which the AS applies only where it declares narrowing for the type; otherwise an entry is carried as approved (Section 5.4, Section 5.5.1);¶

  • the delegation policy, which the AS applies only where it declares delegation; an entry with no type-defined policy is non-delegable (Section 8.4);¶

  • when a scope-projection mapping is safe for the type's entries, which the AS relies on only where it declares projection (Section 7.7); and¶

  • any normalization a comparison of its members uses; without one, URI-valued members compare byte for byte (Section 6.3.2).¶

• 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 ([I-D.draft-mcguinness-oauth-mission-submission-evidence]), and an AS refuses an entry of a type it does not support rather than ignoring it. A verified entry is policy input, never authority (Section 4.4).¶

• Mission Intent members. The Mission Intent's top level (Section 4) is open to members a companion profile defines, under a short name it registers in the Mission Intent Members registry (Section 20.9) 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 (Section 4.2.1) refuses any top-level member that neither this document nor an implemented companion profile defines, and the AS ignores none it recognizes. Registration settles which specification owns a short name, not whether an AS implements, recognizes, or trusts any member.¶

• Integrity anchors. Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (Section 6.3.1, Section 14.4). A profile that commits an evidence or disclosure object MUST commit it with this envelope and a typ that meets Section 6.3.1 and Section 14.4, 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 (Section 7.8), optionally extended with collision-resistantly named members, and is never authority-bearing on its own. An AS without such a profile produces and verifies none of its commitments.¶

• The mission claim. It is an open object: additional, collision-resistantly named members can be carried in it, under the consumer rules of Section 7.8.¶

• 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 Section 6.2 states.¶

• Lifecycle state and termination reason. The lifecycle state space (Section 10) is open to additional states that companion profiles register in the Mission Lifecycle States registry (Section 20.7) for lifecycles they introduce. The termination reasons (Section 10.1) are likewise open to reasons that companion profiles register in the Mission Termination Reasons registry (Section 20.8). Under the forward-compatibility rule of Section 10, only active permits issuance. A companion interface changing Mission state leaves Section 10.2 in force; a terminated Mission stays terminal.¶

• Approval bases. The approval_basis.type value space (Section 6.2.3) is open to standing-consent bases that companion profiles define under Section 14.3.¶

• Approval-event sequencing. The approval-event steps, their order, and the atomicity of record creation with the approval decision are fixed by Section 6.1.1; the coupling of that decision to authorization-code issuance belongs to the direct flow. A companion profile MAY relocate the approval event relative to code issuance (for example, deferring the decision beyond the authorization response, as [I-D.draft-mcguinness-oauth-mission-approval] does), and a back-channel carriage profile (Section 4.2.3) MAY instead couple the approval decision to establishing the Mission grant binding and activating for redemption a grant the profile defines, the Mission then binding to that profile-defined reusable grant (Section 6.4.1), provided in either case the steps and their atomicity with the approval decision hold unchanged and no Mission reference exists before the record is active.¶

• Grants and issuance paths. A companion profile can define a further grant lineage or a profile-defined grant. Its specification states when the AS establishes the binding and how it resolves the Mission, and every derivation through the grant passes Section 7.1 (Section 6.4.1). Neither a returned access token nor a per-request runtime join is a grant lineage (Section 6.4). Without such a profile, the AS resolves a Mission only from the authorization-code lineage and a Mission-bound subject_token.¶

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

14.2. 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 (Section 20.7), Mission Termination Reasons (Section 20.8), and Mission Intent Members (Section 20.9) 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 (Section 7.8), the Mission Record members (Section 6.2) and the approval_basis.type values (Section 6.2.3), is specification-defined: the defining documents are its value space.¶

• Collision-resistant. Deployment-defined names are collision-resistant names (Section 4.2 of [RFC7519]) and are never registered.¶

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

14.3. Mission-Creating Paths

The direct path of Section 6 is the one this document defines in full. A companion profile creates Missions on another path in one of two ways, which stay distinct:¶

• Relocating the direct ceremony. A profile that defers the approval decision, or carries the submission over a back channel, keeps the direct approval: the basis stays direct, and Approval-event sequencing (Section 14.1) states what the relocation keeps unchanged.¶

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

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

• authenticate the consenting principal (step 1 of Section 6.1.1);¶

• establish that principal's authorization over the root's permitted Subjects and authority sources (steps 2 and 3);¶

• obtain that principal's consent to the root's authority, its limits, and its activation policy (step 5); and¶

• record that principal as the consent_principal of every instance the root activates.¶

A future instance's Subject need not be known when the root is approved; each instance falls within what the root authorized. An already approved parent's delegation authority can supply the root, with no fresh human ceremony for each activation.¶

Each instance's creation still meets the rules of this document that bind it: the Subject is never taken from unauthenticated client input and is mapped injectively (step 2, Section 6.1.3); the authority source and its ceiling (Section 6.1.4); the effective expiry and its creation-commit check (steps 4 and 7); the integrity anchors (step 6); and atomic creation, deduplicated as Section 16.1 states.¶

An unrecognized type or adjudication.kind is handled as Section 6.2.3 states for every record consumer.¶

The companion profiles that define standing-consent bases for this document adopt the Approval Basis Contract of [I-D.draft-mcguinness-mission-approval-governance]; a profile defined elsewhere can meet this section's requirements by another mechanism.¶

14.4. 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 Section 6.3.1 (intent_hash, proposal_hash, authority_hash, and commitments produced with companion-defined typ values).¶

• Canonical-object digest: sha-256: over the JCS serialization of a normalized JSON object without the envelope, where protocol context already fixes what is committed.¶

• Raw-octet digest: sha-256: over an exact, specification-defined octet sequence, with no canonicalization: a whole artifact as exchanged, or the UTF-8 encoding of a defined scalar value.¶

The prefix and agility rules of Section 6.3.3 bind all three species. Its I-JSON rule binds the two JSON species. The envelope and typ discipline of Section 6.3.1, with the typ naming rule below, binds envelope anchors alone. The rules of Section 6.3.3 bind a prefixed digest of any species when its defining specification classifies it under this taxonomy and imports this section normatively; this document so classifies every anchor it defines.¶

This document's anchors and digest rules (Section 6.3.1, Section 6.3.3), with this taxonomy, instantiate the default commitment construction of [I-D.draft-mcguinness-mission-substrate]. A commitment outside this construction (a native content address, a member-named digest whose member name fixes the algorithm) is permitted; its defining specification states its own algorithm identification and agility behavior.¶

This document defines no registry of typ values; each committing specification defines its own and relies on the typ domain separation. To keep that domain separation safe without a registry, a new typ value MUST be a collision-resistant name (for example, a short name prefixed within a namespace the defining profile controls, following the Collision-Resistant Name guidance of Section 2 of [RFC7519]). Values with the mission- prefix, used by this document and the profiles that extend it, form a namespace coordinated through this document's change controller.¶

This document defines no transition mechanism: every commitment a current carrier defines is a single prefixed string, and no carrier defines a location for a second one. A specification that introduces a new prefix MUST define:¶

1. the carrier and schema of any parallel commitment;¶

2. the binding that proves the old and new values commit to the same object;¶

3. producer behavior during the transition;¶

4. verifier selection and downgrade behavior when recognition sets differ; and¶

5. the transition procedure itself.¶

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

15.1. 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 (Section 4.2), with the Intent Submission Evidence dispatch and refusal rules (Section 4.4);¶

• Authority Set derivation yielding authorization_details entries of its supported types (Section 5, Section 5.5);¶

• the approval event with its integrity anchors and its recorded approval_basis and authority_source (Section 6.1, Section 6.2);¶

• issuance of Mission-bound access tokens carrying the mission claim (Section 7), as the RFC 9068 JWT or as an opaque reference token under the introspected consumption mode (Section 9.2.4);¶

• the subset rule (Section 5.4);¶

• gating of issuance on Mission state (Section 7.1); and¶

• acceptance of a revocation by mission_id through an authenticated means independent of possession of any token (Section 10.2).¶

An AS can conform as a Mission Issuer without supporting any Intent Submission Evidence type. Such an AS refuses every presented entry under the dispatch and refusal rules (Section 4.4): a structurally invalid entry with the invalid_request error code, and any other entry, as an unsupported type, with the invalid_mission_intent_evidence error code.¶

A Mission-aware Resource Server implements resource server enforcement (Section 9.1). 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 (Section 9.2.4).¶

In either form, it enforces each applicable entry its tokens carry under that entry's type, work a plain [RFC9068] resource server does not do. Conformance in this role implies support for no particular type: an entry of a type the resource server does not implement provides no authority there (Section 9.1.1), so interoperable enforcement needs a type that both the AS and the resource server implement.¶

A Mission Client implements the client surfaces:¶

• submission of the Mission Intent via PAR on the authorization-code path (Section 4.2), proposing concrete authority, where it does, on the authorization_details parameter pushed alongside mission_intent (Section 4.3);¶

• reading its granted authority from the token-response authorization_details echo, and assuming none absent from it (Section 7.3); and¶

• obtaining mission_id from the mission_id token-response parameter (Section 7.3.1), never from the access token, treating it as a reference, not a credential.¶

15.2. Optional Capabilities

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

• Delegation (Section 8): issuing designations (Section 8.1) and the derived tokens that carry the act delegation chain, and consuming those tokens. Only a sender-constrained token can be designated, so Delegation requires sender-constrained non-delegated Mission-bound access tokens.¶

• Self-Exchange (Section 7.5): narrowing an agent's own Mission-bound token by a Token Exchange that names no actor. Supporting Delegation does not require Self-Exchange, and supporting Self-Exchange does not require Delegation.¶

• Introspection (Section 9.2): 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 (Section 9.2.4). 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 (Section 5.4);¶

  3. projection performed only by, or under the authorization of, the Mission issuer, gated on the Mission's active state (Section 10, Section 7.1);¶

  4. projected credential lifetimes capped by the Mission's expires_at (Section 7.6);¶

  5. projected credentials sender-constrained to their presenter (Section 7.2), never bearer credentials, each recipient verifying the proof of possession and refusing a credential whose binding is absent or invalid (Section 9.1); and¶

  6. renewal only through the Mission issuer: a projected grant is redeemable once, and the other trust domain issues no renewal authority on it, so a further credential there needs a new projection.¶

  This bar is self-contained in this document. The companion Mission Cross-Domain Projection profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]) specifies the interoperable mechanism that satisfies it.¶

15.3. Claiming Conformance

A conforming implementation names the optional capabilities it supports (for example, "Mission Issuer with Delegation and Cross-Domain"); each capability's defining section or document states its detailed requirements.¶

Emitting the mission claim is not, by itself, conformance: the claim is reserved for conforming issuance (Section 7.8.1). Conformance as a Mission Issuer requires the gates: authority derived from the approved Intent and committed by the anchors (Section 6.1), issuance bounded by the subset rule (Section 5.4), and derivation gated on Mission state (Section 7.1). 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 (Section 12), the machine-checkable form of that claim.¶

The Mission Binding Properties vector of [I-D.draft-mcguinness-mission-architecture] names what these gates supply as its credential-mission-bound property, informatively; these gates remain authoritative for conformance to this document regardless.¶

This document makes no Mission Substrate conformance claim and takes no requirement from the substrate contract ([I-D.draft-mcguinness-mission-substrate]), which is informative.¶

16.1. Approval Idempotency

The record's approval_event_id (Section 6.2.4) is the approval idempotency key: a retried or duplicate delivery of the same approval decision (a replayed callback, a double-submitted consent form, a retried standing-consent activation) MUST NOT create a second Mission, and the AS deduplicates on this identifier. Each creation path answers such a delivery in its own way, with the committed Mission, a denial or a credential delivery; none creates a second Mission.¶

The AS MUST allocate approval_event_id, unique among its Missions, and MUST NOT derive it from a value that a client supplies and can reuse. At a direct approval event the AS MUST allocate it before the decision commits and bind it to the authorization interaction, never to a request_uri or another client-supplied value. The identifier is immutable and is retained with the record (Section 16.2).¶

Each decision is bound to the interaction, deferral or activation that it decides, which has its own lifetime. A delivery of the decision after that lifetime MUST NOT create a Mission, and the AS MUST retain the identifier for at least that lifetime, so a retired record never turns an old delivery into fresh authorization.¶

Some creation paths recognize a retry by a request key that the client supplies. The profile defining such a key MUST state its retention contract: when the retry horizon starts and ends; that a reservation whose operation is still pending when the horizon ends is retained until that operation ends; that a published horizon is never shortened for a key already recorded; and that a reuse of the key after its reservation has expired under that contract, never while its operation is pending, is a new operation, which meets every check a new request meets, including authorization, policy, ceiling, expiry and accounting, and receives a new approval_event_id. Expiry of a key never lets an earlier decision create another Mission.¶

16.2. Audit Horizon

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

16.3. Binding Index

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

17.1. Commitment and Consent Integrity

17.2. Agent-Specific Threats

17.3. Enforcement Boundaries

17.4. Credentials and Delegation

18.1. Mission Identifier Correlation

This document carries a single canonical Mission Identifier on every derived token. Any party that observes credentials for the same Mission, whether a resource server, a Resource AS, or an auditor spanning audiences, can correlate that activity by the Mission Identifier, and mission.issuer further identifies the issuing AS.¶

That stable anchor lets a resource server, a cross-domain Resource AS, and an auditor bind credentials and evidence to one approved Mission. This document does not provide cross-audience unlinkability (Appendix C.2).¶

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

18.2. 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 Section 2.3 of [RFC9700] recommends (Section 7.3).¶

18.3. 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 Section 18.5.¶

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

18.4. 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 (Section 6.1). 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 (Section 6.2); those facts are provenance and policy input only, which the resource domain validates independently under its current disclosure policy.¶

Third-party personal data can enter through any Intent, proposal, authority, or recorded-evidence member:¶

• the prose members (goal, task_bounds) and purpose;¶

• target_resources and any explicit member a companion profile defines;¶

• any type-owned member of a proposed entry, and the derived Authority Set entries that reach tokens (Section 7); and¶

• submission_evidence facts, including a consent reference.¶

Whatever the member, it:¶

• persists on the Mission Record for its audit horizon (Section 16.2);¶

• concentrates at the AS with the record (Section 18.5); and¶

• if committed, is confirmable through the unsalted anchors by any party holding a candidate value (Section 18.3).¶

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

18.5. 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 (Section 16.2).¶

20.1. 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, Section 4.2¶

• Parameter name: mission_id¶

• Parameter usage location: token response¶

• Change controller: IETF¶

• Specification document(s): this document, Section 7.3.1¶

• Parameter name: mission_error¶

• Parameter usage location: token response¶

• Change controller: IETF¶

• Specification document(s): this document, Section 7.1.2¶

• Parameter name: mission_expires_at¶

• Parameter usage location: token response¶

• Change controller: IETF¶

• Specification document(s): this document, Section 7.3.1¶

PAR [RFC9126] 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 ([RFC6750], Section 9.1), for which no IANA registry exists; no action is required for it.¶

20.2. OAuth Extensions Error Registration

This document requests registration of the following in the "OAuth Extensions Error" registry [RFC6749]:¶

• Error name: invalid_mission_intent_evidence¶

• Error usage location: authorization code grant error response, token error response¶

• Related protocol extension: Intent Submission Evidence (Section 4.4)¶

• Change controller: IETF¶

• Specification document(s): this document, Section 4.4¶

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

20.3. 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, Section 7.8¶

The mission claim (Section 7.8) references a Mission, the authorization object this document defines. It is distinct from AAuth's mission_s256 claim ([I-D.draft-hardt-oauth-aauth-protocol]), the SHA-256 digest that identifies an AAuth mission, and from the agent's mission that [I-D.draft-ietf-wimse-aims] names, the purpose this document translates into authorization. The two claim names do not collide in that registry.¶

20.4. OAuth Token Introspection Response Registration

This document requests registration of the following in the "OAuth Token Introspection Response" registry ([RFC7662]):¶

• Name: mission¶

• Description: The Mission a token was derived under, with its current lifecycle state when returned by the Mission's issuer (Section 9.2).¶

• Change Controller: IETF¶

• Specification Document(s): this document, Section 9.2¶

20.5. OAuth Authorization Server Metadata Registration

This document requests registration of the following in the "OAuth Authorization Server Metadata" registry ([RFC8414]):¶

• 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, Section 12¶

20.6. OAuth Protected Resource Metadata Registration

This document requests registration of the following in the "OAuth Protected Resource Metadata" registry ([RFC9728]):¶

• 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, Section 13¶

20.7. Mission Lifecycle States Registry

IANA is requested to create the "Mission Lifecycle States" registry. The registration policy is Specification Required [RFC8126].¶

A Designated Expert reviews a submission for the discipline Section 10 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, Section 20.8); 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 (Section 10). 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:¶

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 (Section 20.8).¶

20.8. Mission Termination Reasons Registry

IANA is requested to create the "Mission Termination Reasons" registry. The registration policy is Specification Required [RFC8126].¶

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 (Section 10.1) 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 (Section 10).¶

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:¶

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

20.9. Mission Intent Members Registry

IANA is requested to create the "Mission Intent Members" registry. The registration policy is Specification Required [RFC8126].¶

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 (Section 14). 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:¶

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

21.1. Normative References

[I-D.draft-ietf-oauth-rar-metadata-remediation]

Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.

[I-D.draft-mcguinness-oauth-actor-profile]

McGuinness, K., "OAuth Actor Profile for Delegation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-profile-01, 8 October 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-profile-01>.

[I-D.draft-mcguinness-oauth-client-instance-id]

McGuinness, K., "OAuth 2.0 Client Instance Identifiers", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-01>.

[OpenID.Core]

OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC6920]

Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/rfc/rfc6920>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[RFC9101]

Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, <https://www.rfc-editor.org/rfc/rfc9101>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9207]

Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, <https://www.rfc-editor.org/rfc/rfc9207>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

21.2. Informative References

[AuthZEN.ARAP]

OpenID Foundation, "OpenID AuthZEN Access Request and Approval Profile 1.0", 2026, <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html>.

[I-D.draft-hardt-oauth-aauth-protocol]

Hardt, D., "AAuth Protocol", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-11, 25 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11>.

[I-D.draft-ietf-wimse-aims]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-01>.

[I-D.draft-ietf-wimse-arch]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-08, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08>.

[I-D.draft-mcguinness-mission-approval-governance]

McGuinness, K., "Mission Approval Governance", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html>.

[I-D.draft-mcguinness-mission-architecture]

McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html>.

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-metering]

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-mission-security-model]

McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.

[I-D.draft-mcguinness-mission-shaping]

McGuinness, K., "Mission Intent Shaping", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.

[I-D.draft-mcguinness-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

[I-D.draft-mcguinness-oauth-client-attesters]

McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-01>.

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-approved-set-verification]

McGuinness, K., "Mission Approved-Set Verification for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approved-set-verification.html>.

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-resource-access]

McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-resource-access.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[I-D.draft-mcguinness-oauth-mission-submission-evidence]

McGuinness, K., "Mission Intent Submission Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-submission-evidence.html>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8792]

Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.