Mission-Bound Authorization for OAuth 2.0

1.1. Implementation Map

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

Mission Client:

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

Mission Issuer (AS):

Its duties on the starting path:¶

• validate the submission and derive bounded authority (Section 4.5, Section 5);¶

• obtain approval, commit the Mission, and bind the grant to it (Section 6.2, Section 14, Section 8.1);¶

• gate every issuance and refresh on the Mission's state, its Authority Set, its expiry, and any emitted scope value's projection (Section 8.2); and¶

• terminate the Mission on an authorized revocation (Section 7.2).¶

Mission-aware Resource Server:

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

This document defines no authorization_details type (Section 5.5). Each Authority Set entry is of a type the AS supports, such as mission_resource_access ([I-D.draft-mcguinness-oauth-mission-resource-access]), and a Mission-aware Resource Server enforces each applicable entry its tokens carry under that entry's type (Section 9.1).¶

The following table summarizes which surfaces apply, to whom, and when; the cited sections govern. Ordinary JWT consumption does not require retrieving the Mission Record or recomputing the complete approved Authority Set.¶

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

The direct realization creates each Mission at an approval interaction on the authorization endpoint. [I-D.draft-mcguinness-mission-architecture] (Section "Mission Creation Paths") maps the paths where an administrator, or a policy a human consented to, decides without one.¶

A Mission is intended to cover one concrete task, not an agent's whole lifetime. Narrow Missions, each separately approved and revocable, are preferred over one broad standing Mission that accumulates authority across unrelated tasks.¶

This preference has a consent cost: many narrow Missions can create approval fatigue, and combining unrelated authority into one broad Mission can make approval difficult to evaluate. A useful boundary is a task whose purpose, authority, and bounds the Approver can evaluate together (Section 6.6).¶

Optional companions can reduce repeated approvals through standing consent (Section 13): for example, a template, an authority ceiling, or a policy that a human approved once governs later Missions. The template, ceiling, or policy still needs a meaningful human approval, and no such mechanism removes its profile's human-approval requirement for high-consequence authority.¶

The unit of governance is the action, not the content. A Mission bounds where an agent may act (resources, actions) and how much (constraints and, where metered, cumulative bounds). It does not inspect the content that flows within an authorized action: an approved egress channel carries a status update or an exfiltrated payload with equal authority. Content-level controls (data loss prevention, redaction) are complementary; under mediated execution they fit at the mediating enforcement component (Section 20.3.1).¶

2.1. Protocol Flow

Besides the agent (the OAuth client) and the Mission Issuer (the AS), the flow involves two principals: the Subject, on whose behalf the Mission is approved, and the Approver, who approves it. Section 3 defines these and the other terms.¶

The following figure shows the protocol flow between the agent and the Mission Issuer:¶

 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

After token issuance, resource access and lifecycle management proceed as follows:¶

(4) The agent calls the resource server with the token. The resource server enforces the authorization_details statelessly and can check the mission claim (Section 9), with no callback to the AS required.¶

(5) An authorized revocation (Section 7.2), or expires_at passing, moves the Mission to terminated, with reason revoked or expired, after which the AS refuses further issuance and refresh. A deployment can also treat [RFC7009] revocation of the refresh token as revoking the Mission (Section 7.2).¶

The end-to-end example (Appendix A) walks this flow with concrete messages.¶

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

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

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

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

Mission-aware Resource Server:

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

Resource AS:

An authorization server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources; it is never the Mission Issuer. The companion Mission Cross-Domain Projection profile specifies cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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

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 8.2): the initial authorization-code exchange, a refresh, a Token Exchange, or a cross-domain grant issuance. Distinct from Authority Set derivation, which some section titles and fixed phrases, such as "derivation policy", also call derivation.¶

Mission:

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

Mission-referenced token:

A token that carries a Mission reference (the mission claim or a mission_id) without Mission-derived authority or any gating guarantee.¶

Derived token (Mission-derived token):

An access token issued under a Mission, carrying its Mission-derived authority (the full Authority Set or a narrowed subset) as authorization_details and a mission claim (Section 8).¶

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

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

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.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. Across trust domains, the cross-domain companion conveys Subject identity through its own subject-resolution claims, not a Mission lookup, and a token minted in another domain preserves the mission claim unchanged ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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 12.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. 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). Maximum 4096 characters. Prose here persists on the record and can carry personal data about third parties (Section 21.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 22).¶

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. It is not RFC 8707 resource carriage: a client separately requests the audience of a given token with the standard resource parameter (Section 8.4).¶

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

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.2). 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 8.1.4, Section 14).¶

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

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

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

On the authorization-code path (Section 6), a client MUST submit a Mission Intent through a Pushed Authorization Request [RFC9126] using the mission_intent request parameter. The parameter value is the UTF-8 JSON [RFC8259] serialization of the Submission envelope, form-encoded in the application/x-www-form-urlencoded PAR request body like any other OAuth parameter. The Submission envelope is a JSON object with exactly these members:¶

intent:

REQUIRED. The Mission Intent object (Section 4).¶

evidence:

OPTIONAL. A non-empty array of Intent Submission Evidence entries (Section 4.4); the AS refuses an empty array with the invalid_request error code.¶

intent_hash commits exactly the intent object, not the Submission envelope or its evidence array (Section 15.1).¶

The AS returns a request_uri as usual, which the client uses to start authorization. An AS that cannot parse mission_intent as a JSON object, or that parses it but finds the Submission envelope or the Intent structurally invalid against this document's member definitions, MUST refuse the request with the invalid_request error code.¶

Submission is governed by the following rules:¶

• Closed top levels. The AS MUST reject a submission with the invalid_request error code if the Submission envelope contains a top-level member other than intent and evidence, or if the intent contains a top-level member that neither this document nor a companion profile the AS implements defines (Section 16). A bare Mission Intent submitted as the parameter value fails this rule, since its goal and sibling members are unknown envelope members.¶

• Carriage through PAR. On the authorization-code path, the AS accepts the Intent in one of two forms:¶

  1. the form-encoded mission_intent parameter of the PAR request body; or¶

  2. a mission_intent claim inside a signed Request Object ([RFC9101]) that is itself pushed through PAR. The claim's value is the Submission envelope itself, a JSON object, not its serialization; the AS MUST reject with invalid_request a claim whose value is a string or any other value that is not a JSON object.¶

  The AS MUST reject with invalid_request a mission_intent presented on a front-channel authorization request that does not use a PAR-issued request_uri. A client MUST NOT send mission_intent as a plaintext front-channel authorization-request parameter, whether or not a Request Object is also present.¶

  When the pushed request carries a Request Object (a request parameter value), that object is authoritative: a mission_intent submitted outside the Request Object in the same push MUST be rejected with invalid_request, strengthening Section 6.3 of [RFC9101], under which the AS would only ignore such a value.¶

• Alternative back-channel profiles. A Mission Intent travels on no other request unless a companion profile explicitly defines that request as a back-channel carriage of the Submission envelope. Such a profile carries the envelope and any authority proposal in one request that never traverses a user agent, and preserves:¶

  • this section's envelope and proposal rules;¶

  • the processing order (Section 4.5);¶

  • Authority Set derivation (Section 5);¶

  • the approval-event rules for the Mission's approval basis (Section 6, Section 13.1, with a direct approval relocated only as Section 16 permits); and¶

  • the grant binding (Section 8.1).¶

  Support for a grant type or endpoint never establishes such a carriage on its own. The experimental Mission Device Authorization profile ([I-D.draft-mcguinness-oauth-mission-device-authorization]) defines one for a client that cannot complete the authorization-code path, on the device authorization grant [RFC8628].¶

• Bounded size. The AS MUST bound the Submission envelope's total size, the Intent's total size and the lengths of its arrays, and the count and per-entry sizes of evidence entries, refusing a submission that exceeds the deployment-defined limits with invalid_request. The verification-cost bound of [I-D.draft-mcguinness-oauth-mission-submission-evidence] accompanies these.¶

• Concrete authority is proposed via authorization_details. A client proposes concrete authority on the standard authorization_details parameter in the same push (Section 4.3). A client can also push scope and resource ([RFC8707]) values; the AS treats them as a requested subset of the authority the Mission Intent yields (Section 5).¶

• Pushed parameters are authoritative. On the front-channel request that redeems the request_uri, the AS MUST ignore any mission_intent, authorization_details, scope, or resource presented.¶

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

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

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

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

The AS validates each submitted entry per Section 5 of [RFC9396]: it refuses a request carrying an entry of a type it does not support (Section 5.5, Section 17), or one that fails its type's documented definition, with the invalid_authorization_details error code, and never repairs a failure by omitting the entry. Where a machine-readable JSON Schema for the type is advertised (Section 17) or established out of band, the entry MUST also validate against that schema, and the AS MUST refuse a request carrying an entry that fails it with the invalid_authorization_details error code.¶

Policy narrowing is distinct. During Authority Set derivation the AS MAY narrow or omit a syntactically valid entry that policy cannot accept (Section 5). The granted authorization_details in the token response reflects every narrowing and omission (Section 8.4).¶

When a proposal is present, the AS MUST derive each Authority Set entry as a subset (Section 5.4) of some proposed entry of the same type: narrowed under that type's own subset rule where it defines one, or carried through unchanged where it defines none (Section 5.5).¶

goal and task_bounds then serve as rendering and bounding context over the proposed authority. Each proposed entry that carries a resource member MUST have it among the Intent's target_resources, compared as Section 5 states; the AS refuses a request violating this with the invalid_request error code.¶

The carriage rules of Section 4.2 apply to the proposal. The AS records the array on the Mission exactly as submitted and commits it by proposal_hash (Section 15.1, Section 14), separately from the task (intent_hash) and the approved Authority Set (authority_hash), so a narrowed approved Authority Set can be audited against the proposal that sought it.¶

Submitting authorization_details without mission_intent is an ordinary [RFC9396] request that this document does not govern. Two AS-side rules keep a governed task from being downgraded to such a request (Section 17 states the client-side rules and Section 20.1.2 the threat):¶

• Where a deployment classifies a resource as Mission-governed (a Mission-governed resource), its AS MUST NOT issue a token for that resource outside a Mission, except under documented policy exceptions.¶

• If a client registered as Mission-governed sends an authorization request, through PAR or at the authorization endpoint, that carries authorization_details but no mission_intent, the AS MUST reject the request with the invalid_request error code, so the client cannot drop the Intent from a request that still carries authorization_details. The rule applies to that request until it completes, including when the AS resumes it after an interaction. A request carrying neither is an ordinary request that this rule does not reach; the first rule, for a Mission-governed resource, is what keeps that resource's tokens inside a Mission.¶

A token request under an existing Mission-bound grant, such as a narrowing refresh, a self-exchange (Section 12.4) or an exchange for a delegation designation (Section 12.1), needs no mission_intent under the second rule. This exception opens no Mission submission carriage, and every other check still applies to the request: Issuance Gating (Section 8.2), the subset rule (Section 5.4), the first rule above, and the grant's binding to its Mission, client and sender.¶

The following is an example of an authority proposal submitted alongside the example Intent of Section 4. Authority Set derivation narrows invoices.* to invoices.read, keeps the proposed Q3 issuance window and write ceiling, which the Intent's task bounds support, and carries the proposed delegation policy through unchanged (the example Authority Set of 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:¶

• Reject, do not ignore. An entry that is not a JSON object, or that lacks type, is structurally invalid and refused with the invalid_request error code. The AS MUST refuse an entry whose type it does not support, and an entry that fails its type's validation or verification, with the invalid_mission_intent_evidence error code (Section 23.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), 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 19.1).¶

Mission Intent Submission Evidence for OAuth 2.0 ([I-D.draft-mcguinness-oauth-mission-submission-evidence]) specifies:¶

• the entry convention;¶

• required-evidence resolution;¶

• the binding of evidence to one Intent and to the presenter;¶

• the verification-cost bound;¶

• where the error is returned; and¶

• evidence on idempotent creation surfaces.¶

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

1. Parse the Submission envelope and enforce both closed top levels (Section 4.2).¶

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

4. Compute the provisional intent_hash over the intent object (Section 15.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. Apply the evidence dispatch and refusal rules, verifying every presented entry under its 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).¶

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

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

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

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

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

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

The material verified provenance of step 8 is part of the approval surface. Where a deployment commits the rendered approval surface, that commitment MUST cover the normalized provenance facts, at least as a digest of their canonical submission_evidence representation (Section 14). For example, the consent-evidence companion binds them with a submission_provenance_hash inside its committed disclosure ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

5.1. Derivation Modes

Authority Set derivation is mechanical: one procedure whose candidate entries depend on whether an authority proposal was submitted:¶

• Narrowing mode (preferred where the client can author authorization_details): the client submitted an authority proposal (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).¶

• Configured-mapping mode: no authority proposal was submitted, and a deployment-configured mapping, keyed on the Intent's purpose or target_resources, yields the candidate entries, which are then narrowed to policy.¶

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

  Every Mission this mode yields takes its own fresh approval; standing consent to a pre-approved ceiling is the separate, experimental Mission Template profile ([I-D.draft-mcguinness-oauth-mission-template]), not this mode.¶

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.2), and a change that Section 6.5 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.2), 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).¶

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 (for mission_resource_access, a descendant of a prefix entry) can yield a token entry that target_resources does not name, and a candidate outside every Authority Set entry fails that rule.¶

The Mission records the policy version in force as policy_version (Section 14).¶

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

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

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.2). 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 ([I-D.draft-mcguinness-mission-shaping]).¶

A client-proposed constraint on an individual Authority Set entry enters through the authorization_details proposal: constraints a supported type's specification defines (for example, the Common Constraints that [I-D.draft-mcguinness-oauth-mission-resource-access] defines for mission_resource_access), and the collision-resistant deployment extensions the AS understands (Section 16).¶

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

5.3. Derivation Policy and Open-Ended Tasks

Authority Set derivation is governed by local policy and is not a portable algorithm: different authorization servers can derive different Authority Sets from the same Mission Intent, as they can grant different authority for the same [RFC9396] request or the same scope. Interoperability begins at the derived Authority Set, whose structure and vocabulary each supported type defines (Section 5.5), and at its integrity anchors (Section 15.1).¶

A consumer enforces the derived Authority Set, not the Intent. Audit establishes what was derived, against intent_hash and policy_version, not whether the Authority Set derivation was the right reading of the task. A deployment whose partners reason about its Authority Set derivations can publish a derivation policy identifier and test fixtures that pin Intent-to-Authority-Set outcomes.¶

For an open-ended task whose concrete objects cannot be enumerated at approval (for example, "reconcile this customer's ledger," where the individual invoices are not yet known), the derived authority is better bounded by constraints that hold as invariants over those objects than by an exhaustive resource enumeration. Such invariants include the owning customer, the tenant, an amount ceiling, read-only except named write actions, and a validity window. The runtime layer (Section 20.3.1) checks each concrete object against the constraint at the point of use.¶

mission_resource_access is defined by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]); the Authority Set carries it on the same type-agnostic terms as any supported type (Section 5.5).¶

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 (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]). The AS MUST refuse to derive an entry that is not a subset, under its type's relation, of some Mission Authority Set entry.¶

The AS MUST refuse a request that would widen authority under a Mission after the approval event on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation); broader authority requires a fresh approval event, either a new Mission or a successor ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

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

Where the comparison relation cannot decide (an unrecognized member, an incomparable value), the posture is conservative refusal, as each consuming rule of this document states.¶

An entry equal to its reference entry, byte-identical under the canonical form of Section 15.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, then the source of truth for the supported set (Section 17).) 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 12.5), under the transformation capabilities the AS declares for the type (below); and¶

• evaluating the entry against a concrete request is the runtime layer's responsibility (Section 20.3.1), not the AS's.¶

[
  {
    "type": "account_information",
    "rarFormat": "cedar",
    "policySet": "permit(principal, action, resource) when {...};"
  },
  {
    "type": "mission_resource_access",
    "resource": "https://calendar.example.com",
    "actions": ["events.read"],
    "constraints": { "window_days": 30 }
  }
]

6.1. Authorization Code Protection

The direct realization runs as an OAuth 2.0 [RFC6749] authorization-code flow initiated from the PAR-issued request_uri (Section 4.2). Because the authorization code is the artifact the Mission grant binds to (Section 8.1.1) and it passes through the front channel, the AS MUST bind the code to the requesting client with PKCE ([RFC7636], S256 challenge method) or, equivalently, issue a DPoP-bound authorization code ([RFC9449]). Redemption is then verified as Section 4.6 of [RFC7636] or Section 10 of [RFC9449] specifies. This prevents authorization-code injection from yielding the Mission grant.¶

The AS SHOULD include the iss authorization-response parameter ([RFC9207]) on the authorization response, so the client can detect a mix-up attack on the consent-bearing redirect leg ([RFC9700]).¶

6.2. Direct Approval Steps

Steps 1 to 3 establish the Approver, the Subject and the authority source, and check the derived Authority Set against that source. Step 4 establishes the effective expiry. Step 5 renders the derived Authority Set for consent, and Section 6.5 covers a change before the decision. Steps 6 and 7 compute the integrity anchors over the approved context and create the Mission atomically with the decision.¶

At a direct approval event the AS MUST perform steps 1 to 7, in order, as one procedure: steps 1 to 5 prepare the approval (Section 6.2.1), and steps 6 and 7, which continue the same procedure, commit the Mission (Section 6.2.2).¶

The steps of this section define the direct approval basis (approval_basis, Section 14); a companion profile that relocates a direct approval keeps them unchanged (Section 16).¶

Refusals follow Section 10.¶

6.3. Subject Establishment

These rules apply at step 2 of the direct approval steps (Section 6.2).¶

• Approval for another principal. When the Approver is a different principal (for example, an administrator approving on a user's behalf), the AS MUST NOT take the Subject from unauthenticated client input, and MUST authorize the Approver to approve for that Subject under local policy. This document defines no wire parameter for the Subject; how the AS establishes it (administrative selection, a directory, an authenticated reference) is a deployment matter.¶

• External Subject. When the Subject's home issuer (subject.iss) differs from the AS, the AS MUST map the external (subject.iss, subject.sub) pair to an AS-local sub under an injective mapping (no two distinct external Subjects map to the same local sub). A derived token's (iss, sub) pair then denotes exactly one Subject. Adopting the external sub verbatim is valid only where it collides with no other principal's sub.¶

6.4. Rendering Safeguards

The consent rendering is hardened against client text:¶

• Client-supplied strings (goal, task_bounds) MUST be rendered as inert text and MUST NOT be interpreted as markup.¶

• The AS SHOULD mitigate Unicode direction-override and confusable-character presentation in them.¶

• The rendering MUST visually distinguish the AS-derived Authority Set from client-supplied text, so crafted client text cannot pass as derived authority.¶

Rendering a bound is not the same as enforcing it: a deployment MUST NOT present a rendered bound as enforced when no party enforces it. The enforcement table (Section 9.5) summarizes which party enforces each bound and what holds when that enforcer is absent. An AS SHOULD make clear to the Approver which rendered bounds its deployment actually enforces, so consent is not given to a limit that binds nowhere.¶

6.5. Changes Before the Decision

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

• the task or the authority proposal;¶

• the derived Authority Set;¶

• the established authority source (Section 6.7);¶

• the effective expires_at; or¶

• a policy input establishing any of them.¶

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

6.6. Approval Comprehension

The approval event commits the Mission Intent and Authority Set the AS records as approved. Those commitments establish neither that the AS rendered them faithfully nor that the Approver understood them (Section 20.1.1). Step 5 of Section 6.2 requires human-meaningful rendering; comprehension cannot be inferred from an approval or its integrity anchors.¶

A short task can legitimately have a large or varied Authority Set: an erasure request whose proposal or configured lookup (Section 5) yields dozens of delete entries across resources. The consent object remains the complete derived Authority Set. The following non-normative practices can help make it reviewable:¶

• Group entries by resource and action, so the Approver reviews kinds of authority rather than a list of entries, while keeping material differences in constraints visible: a group of identical actions still shows an entry whose resource range or consumption bound is much broader than the rest.¶

• Summarize with drill-down: a summary covering every resource, action, and bound, with each complete entry one interaction away. A summary is a view of the set, never a substitute for it.¶

• Surface high-risk entries: make the irreversible, external-commitment, privileged-administration, and consumption-bounded authority of Section 6.8 prominent in the initial view, distinguishing materially different risks and bounds.¶

• Split rather than approve: when the set is too large or varied for one decision, narrower Missions can keep each approval meaningful (Section 1.2).¶

Mission Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) defines layered rendering of a committed disclosure, including what its first layer carries, and lets the Approver ask the basis for an entry before deciding.¶

6.7. Authority Sources

A Mission draws its authority from one of three sources:¶

• user-delegated: a delegating person's own authority;¶

• service-owned: a workload's own provisioned authority; or¶

• organizational: explicitly governed organizational policy with a named accountable owner.¶

The source names whose authority the approval draws on, recorded immutably as the Mission's authority_source; approval_basis records how drawing on it was activated (Section 14). The two compose: any source may activate under the direct basis or a standing-consent basis a companion defines.¶

Approval activates only authority the source already holds: the AS establishes the source and verifies the derived Authority Set against it before approval (Section 6.2, Section 13.1).¶

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

• The accountable principal is the record's approval_basis.consent_principal in every source; it is never inferred from the token sub.¶

• sub carries a delegating person only in the user-delegated source. A service-owned or organizational Mission MUST record the workload or organizational principal as subject and MUST NOT record a human principal in its place. The injective mapping of Section 6.3 applies unchanged: that principal receives its own AS-local sub, denotes itself, and impersonates nobody. It MUST be an authorization subject the AS recognizes as a resource owner in its own right (the sub model of [RFC9068]), not only the task's beneficiary.¶

• The actor model does not vary by source: client_id names the Agent, and delegates are carried in the act chain (Section 12).¶

6.8. Approver Authentication Strength

A deployment publishes a statement declaring the minimum approval-authentication strength (the approval-authentication floor) it enforces for Missions whose derived Authority Set carries high-risk authority, and the deployment scope it applies to. High-risk authority means irreversible, external-commitment, or privileged-administration actions under the deployment's classification, or a consumption bound ([I-D.draft-mcguinness-mission-metering]). This document requires no particular serialization.¶

For the direct flow, a client MAY additionally request an approval-authentication strength on the authorization request using the acr_values and max_age parameters defined in Section 3.1.2.1 of [OpenID.Core]. In a Mission approval interaction these parameters describe the requested authentication of the Approver, not of the token's Subject, who can be a different principal (Section 6.3).¶

Requesting these parameters implies nothing about the authentication claims of an issued token, which describe the token's Subject, not the Approver (Section 8.6); when the Approver is the Subject, one authentication event can back both.¶

The Approver's authentication satisfies acr_values when it matches any one listed value under the deployment's own policy mapping (this document defines no global ordering of acr values); max_age bounds the elapsed time since that authentication.¶

Approval authentication for a high-risk Mission MUST satisfy both the published floor and, where the client requested one, the acr_values/max_age carriage above; the floor is never relaxed by a narrower or absent client request.¶

This document does not require an AS to support OpenID Connect [OpenID.Core]. An authorization request whose scope includes openid asks for an ID Token about the End-User the approval interaction authenticates, who is the Approver. When the Approver is not the Subject established at step 2 of Section 6.2, the AS MUST refuse such a request, without creating the Mission, with the invalid_scope error code (Section 4.1.2.1 of [RFC6749]). When the Approver is not the Subject, whether or not openid was requested, the AS MUST NOT issue an ID Token, serve UserInfo, or establish an authentication session for the Subject solely as a result of the Approver's authentication or approval.¶

When the Approver is the Subject, the openid scope value and the acr_values and max_age parameters keep their [OpenID.Core] meaning, which then describes the same authentication this document requires. In every approval interaction, the prompt, login_hint, and id_token_hint parameters concern the Approver.¶

The authentication actually achieved for the approval event (acr, amr, and auth_time, in the sense [RFC9470] and [OpenID.Core] define them) is approval-time provenance, not requested Intent: this document never records it as, and an AS MUST NOT read it back from, a Mission Intent member.¶

Where a deployment records Consent Evidence, the achieved values belong in its authentication_context member ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); this document defines no Mission Record member for them.¶

6.9. Single Accountable Approver

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

• Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers does not change the authority commitment: principals approving the same rendered Authority Set produce the same authority_hash and the same derived tokens. A deployment requiring dual control records one accountable Approver; this document does not represent the co-approvers.¶

• Approval-authority provenance: the standing behind a delegate's authority to approve for another principal (for example, whether an administrator was entitled to approve on a user's behalf). This is governance state about the delegate, not the standing-consent basis that approval_basis records (Section 14).¶

Where a deployment needs either, the Approval Governance Record ([I-D.draft-mcguinness-mission-approval-governance]) records it, and Consent Evidence can carry a partial presentation of that record through co_approvals and its approval-governance members ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

The adjudication.governance_record member (Section 14) marks an approval such a record backs, and Appendix C shows how each scenario assigns the three approval_basis roles.¶

7.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 23.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 never changes it: an expiry, or any later event, does not replace the reason or references of a Mission already terminated.¶

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

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

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

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

7.2. Revocation

A Mission is revoked when the AS receives an authorized revocation for it. A deployment MUST provide an authenticated means for the Subject, the Approver, or an administrator to revoke a Mission by mission_id, independent of possession of any token (so a Mission can be stopped even when no refresh token is held).¶

The wire shape of that operation is out of scope for this document. A deployment-defined authenticated surface satisfies this requirement; Mission Status ([I-D.draft-mcguinness-oauth-mission-status]) defines an interoperable revoke operation, authorized under its own lifecycle authorization policy, which a deployment can serve alone under that document's revoke-only conformance class.¶

As Section 2.1 of [RFC7009] permits, a deployment's revocation policy can treat revoking a Mission's refresh token as revoking the Mission; a deployment that couples token revocation to Mission revocation documents that behavior.¶

Token validity and Mission validity are distinct: an already-issued access token remains valid until it expires (Section 8.2), so a token can outlive a transition of its Mission by at most the token lifetime.¶

Token introspection (Section 11) is a state-observable overlay that lets a resource server see Mission state per request and refuse a revoked Mission's token before the token expires; Mission Status specifies another, a status surface keyed by mission_id with signed responses. A deployment whose consumers rely on Mission state beyond a token's lifetime offers one of these, so they read current state rather than infer it from token validity.¶

8.1. Binding the Mission to the Grant

A Mission is independent of any OAuth grant: it is identified globally by the pair (issuer, id) (Section 14), 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 8.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 continuation transport establishes later for the same Mission ([I-D.draft-mcguinness-oauth-mission-continuation]).¶

8.2. Issuance Gating

A derivation is one issuance operation the issuer AS performs for a single request: the initial authorization-code exchange, a refresh, a Token Exchange, or a cross-domain grant issuance ([I-D.draft-mcguinness-oauth-mission-cross-domain]). A companion profile bounds the number of derivations under a Mission ([I-D.draft-mcguinness-oauth-mission-derivation-limits]).¶

A derivation passes these checks, each stated where cited:¶

1. the Mission resolves from the presented grant (Section 8.1.1);¶

2. the Mission is active (Section 7, and below);¶

3. each emitted entry is a subset of a Mission Authority Set entry (Section 5.4);¶

4. any emitted scope meets Section 8.7; and¶

5. each token's exp does not exceed the Mission's expires_at (Section 8.6).¶

Unless the referenced Mission is active, the AS MUST refuse a request to derive a token at the token endpoint: a Token Exchange ([RFC8693]) with the invalid_request error code (Section 2.2.2 of [RFC8693]), and any other grant, refresh included, with the invalid_grant error code. The AS MUST refuse a derivation request it answers after it has acknowledged a revocation of the Mission, with the same error code.¶

Where a profile of a Token Exchange that the AS implements assigns its own error code to either refusal, such as a continuation profile's code for an ended chain, the AS uses that profile's code instead; the refusal itself, and the mission_error member below, still apply.¶

The error code alone does not tell a client which gate refused. On a refusal under this section the AS SHOULD include, alongside error, the mission_error token-error-response member (Section 23.1) with one of the values revoked, expired, or superseded (where a companion defines supersession), the Mission's termination reason (Section 7.1).¶

The mission_error member is diagnostic only: it grants nothing, an unrecognized value is ignored, and it is returned only to the authenticated client presenting the Mission's grant.¶

Derived tokens SHOULD be short-lived so that a transition to terminated takes effect promptly without per-request revocation checks.¶

8.3. 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]). In addition to what that profile 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 8.8);¶

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

• 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 8.4, Paragraph 1), except that a token the AS issues only for presentation back to itself at a Token Exchange, such as a designation (Section 12.1), names in aud the client that presents it;¶

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

• MAY carry a scope claim, subject to Section 8.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).¶

The primary access 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 20.4.1).¶

A delegated token is sender-constrained to the delegate's own key (Section 12.2); the cross-domain companion requires sender-constraint for credentials that cross a trust domain ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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

Every emitted authorization_details entry is a subset of a Mission Authority Set entry (Section 5.4).¶

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

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). The mission_id response parameter carries the Mission reference beside it (Section 8.1.4).¶

The following is an example of a refresh request that narrows the canonical ERP Mission (the worked example of Section 14) 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 8.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 8.2). 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 8.1.4). 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" }]
      } }
  ]
}

8.5. Refresh Tokens

A Mission-bound refresh token is bound to the client it was issued to. For a confidential client, client authentication supplies the binding: on refresh, the AS authenticates the client and verifies that the refresh token was issued to it (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.¶

8.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.8). 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 8.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. The cross-domain companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]) specifies how this bound extends transitively to tokens minted in another trust domain.¶

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

For every target audience, the AS MUST establish that the effective rights the target's enforcement path grants from the projected scope, together with every independently mandatory control on that path, are a subset of the rights the token's applicable authorization_details grant.¶

This is a semantic condition, not a structural one. Exactly as it fails for a relaxed constraint, it fails for a constraints-free entry whose scope:¶

• aggregates a broader action;¶

• spans more resource instances or paths than the entry;¶

• carries rights the target's local scope interpretation implies; or¶

• arises from the union of several entries.¶

To emit scope for an entry, the AS:¶

1. determines the target resource server or audience for the token;¶

2. resolves a trusted, versioned scope-projection mapping for that target, established through the target's protected resource metadata ([RFC9728]) or authenticated out-of-band configuration;¶

3. establishes, under the subset condition above, that the complete effective authorization the projected scope grants at that target is no broader than the applicable carried entries;¶

4. omits scope for an entry where the target's enforcement path consumes authorization_details instead;¶

5. MUST refuse issuance to a target that is scope-only when no safe projection exists for the applicable entries: an issued token no enforcement path can safely evaluate is not a usable credential; and¶

6. for a multi-audience token, establishes the condition independently for each audience; a single-audience token (Section 8.4) remains preferred.¶

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

Scope projection does not change OAuth response semantics and does not make access-token inspection a client requirement.¶

Section 3.3 of [RFC6749] requires the token response to carry scope whenever the granted scope differs from the requested scope, and its grammar defines no empty scope, so an issuance cannot report an ungranted requested value by omission. The AS MUST refuse, with invalid_scope (Section 10), a request that explicitly names a scope value the issuance cannot grant: a value the target's trusted mapping names but no carried entry makes safe (step 3), or any scope value the AS associates with a target that consumes authorization_details (step 4).¶

An unknown, ambiguous, or stale mapping is a step 5 failure and yields the invalid_target error code even when the request also names a scope value; invalid_scope applies only under a mapping the AS trusts.¶

Where the AS emits a projected scope, a requested scope narrows it to the requested values, and the token response reports the values granted (Section 5.1 of [RFC6749]). A Mission-creating client does not request a resource scope for a target that consumes authorization_details; for a scope-only target, a requested scope selects among the values the projection can grant. Scope values with their own semantics, such as openid ([OpenID.Core]), are unaffected and combine with authorization_details as Section 3.1 of [RFC9396] permits.¶

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

This is the type-agnostic form of the rule; a type's own specification states when the mapping in step 3 is safe for that type's entries (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]).¶

The runtime profile's enforcement-scope declarations ([I-D.draft-mcguinness-mission-runtime]) can reference the same mapping for the paths it covers; this rule does not depend on that profile.¶

8.8. Mission Claim

The mission claim is a JSON object:¶

id:

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

issuer:

REQUIRED. A string. The Mission's issuer (Section 14). 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 ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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

expires_at:

OPTIONAL. A string. The Mission's expires_at (Section 14), 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 7).¶

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

The mission claim is an open object (Section 16): 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"
  }
}

9.1. Enforcement Requirements

A resource server:¶

1. MUST treat authorization_details as the authoritative expression of authority and enforce each applicable entry according to that entry's own type specification (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]). Where more than one carried entry applies, entries are alternative grants of authority, not conjunctive filters, unless the entry's type states otherwise.¶

2. MUST treat as providing no authority any applicable entry whose type it does not implement, or whose type-defined enforcement it cannot complete (an unrecognized member, an unenforceable constraint, or an unrecognized matching mode). It MUST refuse the request (for example, a 403 with the insufficient_scope error code [RFC6750], or the deployment's usual insufficient-authority error) unless another applicable entry that it can fully enforce authorizes the whole request on its own, and MUST NOT combine parts of several entries to authorize one request. A failure of the token's own validation (above) rejects the token whatever its entries carry.¶

3. MUST NOT, when a token also carries scope, grant on the basis of a scope value any access broader than the corresponding authorization_details entry permits, including access that bypasses a constraint carried only in authorization_details.¶

4. MUST NOT infer the Mission's originally-approved agent from client_id, which names the client that requested this token, on a delegated token or otherwise (Section 4.3 of [RFC8693], Appendix B.6); the approved agent is recorded only in the Mission Record (Section 14) at the issuer.¶

5. MUST, when configured to require the mission claim for a Mission-governed resource, reject a token that lacks it with the invalid_token error code. The issuance-side duty that pairs with this rejection is stated in Section 4.3, the downgrade it prevents in Section 20.1.2, and the metadata that advertises the requirement in Section 18.¶

6. MUST accept a mission claim only from an issuer it explicitly trusts to issue Mission-bound authorization for the resource; trusting the issuer's ordinary access tokens is not enough. It MUST require mission.issuer to equal the token's iss, unless a cross-domain profile it has adopted ([I-D.draft-mcguinness-oauth-mission-cross-domain]) explicitly establishes the permitted relationship between the two. It MUST reject a token that fails either check with the invalid_token error code. For an opaque token, the issuer is the AS whose introspection response or issuer-local resolution the resource server relies on, and the same checks apply to that response's mission member (Section 11.4).¶

A resource server can also:¶

• require that a token carry an act chain and record it, while authorizing only the token's current actor (Section 4.1 of [RFC8693]);¶

• log the mission claim's id and the token's jti claim with each served request, so its access logs join to Mission evidence; or¶

• where the AS offers it, introspect the token (Section 11) to observe Mission state per request.¶

9.2. Mission-Unaware Resource Servers

A deployment MUST NOT route a delegated Mission-bound token to a Mission-unaware resource server, or to logging or audit infrastructure, that authorizes or logs the caller on client_id without processing the act chain.¶

A Mission-unaware [RFC9068] resource server reads client_id as the immediate client, which is accurate for that single token. It cannot see the delegation lineage in the act chain or look up the originally-approved agent in the Mission Record, so it cannot recognize the current actor as a delegate, record that lineage, or join a delegate's action to the Mission's approval in its audit records.¶

A resource that requires Mission-bound tokens can advertise that through the mission_bound_authorization_required protected resource metadata member (Section 18); a resource server that serves such a resource is, by that requirement, Mission-aware.¶

A Mission-unaware resource server that authorizes only from scope operates within the Mission only to the extent the AS established a safe projection for it at issuance (Section 8.7). Constrained authority that no safe projection carries is enforced only where a resource server, or a runtime layer, evaluates authorization_details.¶

9.3. Carried Authority

An entry whose type-defined enforcement a resource server cannot complete fails closed because a type-defined constraint narrows authority: treating an unenforceable key or member as absent, or reducing it to disclosure-only, would widen the grant.¶

The baseline token carries no authority_hash (Section 8.8). Where a deployment discloses it to a resource server (through introspection's disclosure privilege, Section 11.1, or a companion profile that carries its own copy), it is an audit correlator, not an enforcement input, and not a cryptographic proof that the carried entries are a subset of the approved set.¶

That subset relationship is an assertion by the AS, authenticated by the token signature. Mission Approved-Set Verification ([I-D.draft-mcguinness-oauth-mission-approved-set-verification]) defines an independent check for a resource server that needs more than that assertion.¶

9.4. Denial Responses

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

1. Weak or stale Subject authentication. Where the deployment conveys the authentication of the token's Subject, through the claims of Section 8.6 or introspection (Section 6 of [RFC9470]), and that authentication does not meet the resource's requirement, the resource server challenges with insufficient_user_authentication and the acr_values or max_age parameters (Section 3 of [RFC9470]).¶

   Where no Subject authentication applies, the token carries no such claims and the challenge offers no remediation, so the resource server does not use it. The Subject's authentication is a distinct fact from the Approver's approval-time authentication; a requirement on the Approver is an approval floor (Section 6.8), not a resource server challenge.¶

2. Sender-constraint or key-binding failure. The token's proof of possession is missing or invalid: the resource server challenges with invalid_token, in the DPoP scheme for a DPoP-bound token (Section 7.1 of [RFC9449], with use_dpop_nonce per Section 9 of [RFC9449]) and in the Bearer scheme for a certificate-bound token (Section 3 of [RFC8705]). This is not a step-up: no fresh user authentication repairs a missing or wrong key.¶

3. Insufficient carried authority. The action is outside the token's carried authority: the resource server challenges with insufficient_scope ([RFC6750]), or with the RAR-remediation challenge where [I-D.draft-ietf-oauth-rar-metadata-remediation] is deployed (Section 9.6).¶

4. Unenforceable constraint. An applicable entry carries a type-defined member or constraint the resource server cannot enforce, and the request fails closed under the same base error as case 3.¶

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

insufficient_authority:

The action is outside the token's carried authority; more requires a new approval or an expansion where that companion is deployed.¶

constraint_unrecognized:

An applicable entry carries a type-defined member or constraint the resource server cannot enforce, and the request fails closed. A client MUST NOT treat this value as inviting retry, step-up, or fresh approval: none of those makes a resource server enforce a constraint it does not implement.¶

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

9.5. Enforcement Responsibilities

Every bound this document defines is enforced by a party this document names. The following table summarizes which party enforces each bound a Mission carries and what holds when that enforcer is absent. Where a row names a type specification, it is the one for mission_resource_access ([I-D.draft-mcguinness-oauth-mission-resource-access]):¶

9.6. Remediation Grains

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

mission_denial:

• Carriage: WWW-Authenticate attribute¶

• Defined by: This document (Section 9.4)¶

insufficient_authorization with authorization_remediation:

• Carriage: WWW-Authenticate error code and parameter¶

• Defined by: [I-D.draft-ietf-oauth-rar-metadata-remediation]¶

Requestable denial:

• Carriage: AuthZEN denial response: context.access_request with next_action: request¶

• Defined by: [AuthZEN.ARAP], profiled by [I-D.draft-mcguinness-mission-authzen]¶

A resource server can also respond with the insufficient_authorization error code and the authorization_remediation parameter ([I-D.draft-ietf-oauth-rar-metadata-remediation]), which names what mission_denial: insufficient_authority only points at. Each grain keeps the wire shape and response status its defining document gives it.¶

A client that decodes authorization_remediation can request the carried entries on the standard authorization_details parameter of a refresh request (Section 8.4), where they derive under this document's ordinary rules (Section 5): of an advertised, schema-valid type (Section 17), narrowed same-type (Section 5.4, Section 5.5) like any other request. The AS issues only what both the presented refresh grant (Section 6 of [RFC9396]) and the Authority Set contain, and refuses a request beyond either (Section 8.5), so a refresh-token family narrower than the Mission does not obtain the Mission's wider authority.¶

For entries outside the Authority Set, more authority requires a new approval, proposed as for a new Mission (Section 4.3), or an expansion where that companion is deployed ([I-D.draft-mcguinness-oauth-mission-expansion]). A client holding no refresh grant that covers the entries proposes them as for a new Mission.¶

A third grain, the requestable denial of [AuthZEN.ARAP], profiled by [I-D.draft-mcguinness-mission-authzen], routes the same denial into a governed access request rather than a fresh derivation.¶

The three grains compose: a deployment can offer any subset, and none widens authority beyond what Section 5 derives from the same proposal unremediated.¶

11.1. Caller Authorization and Minimization

Strengthening Section 2.1 of [RFC7662], which requires some form of authorization to access the introspection endpoint, the AS:¶

• MUST authenticate the calling party.¶

• MUST return Mission data only to a caller authorized to receive it, in particular a resource server that is an audience of the token.¶

• MUST audience-filter the response, returning the authorization_details entries and Mission data relevant to the caller's audience and not disclosing entries addressed to other audiences (Section 8).¶

These rules apply equally to the mission member of an active: false response (Section 11.2).¶

Disclosure is member-scoped as well as caller-scoped. proposal_hash, authority_hash, approval_basis, and authority_source serve audit and correlation consumers, not resource server enforcement, and the AS MUST disclose each only to a caller the deployment has granted that member's disclosure privilege. By default, an audience-authorized resource server receives the audience-filtered enforcement projection above, without them.¶

A mission member that a companion profile defines for disclosure here follows the same member-scoped rule and is not an enforcement input.¶

11.2. Composite Active State

The introspection active member reflects the composite authorization, not the token in isolation. Strengthening Section 4 of [RFC7662], the AS MUST return active: true only when the access token passes that section's checks (valid signature, unexpired, and not individually revoked) and the Mission is active. A designation (Section 12.1) authorizes no resource access: the AS MUST return active: false for one, with no mission member.¶

The AS does not verify the token's sender-constraint (cnf) at introspection; the resource server checks proof of possession when the token is presented, so active: true is not by itself evidence that the caller holds the bound key.¶

When the token is otherwise valid but the Mission is terminated, the AS MUST return active: false and include mission.state and mission.termination, whose reason gives the cause, so a resource server can distinguish a dead Mission from a bad token. A Mission transition does not by itself revoke the token as an individual credential; introspection reports the composite authorization as inactive.¶

Reporting the mission member, mission.state included, for an inactive token deviates from the SHOULD NOT of Sections 2.2 and 4 of [RFC7662] against including additional information about an inactive token. The caller authorization and minimization rules (Section 11.1) govern that deviation.¶

11.3. Issuer-Only Members

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

11.4. Introspected Token Consumption

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

• In this mode, an AS issuing opaque Mission-bound tokens MUST offer introspection for them with the members this mode names, unless every resource server that consumes them uses issuer-local resolution (below).¶

• An active (active: true) response for such a token MUST carry, as introspection response members, the audience-filtered granted authorization_details ([RFC9396]), the mission member above, aud, cnf where the token is sender-constrained ([RFC8705], [RFC9449]), and act where execution was delegated (Section 12): everything Section 8 requires the JWT to carry, sourced from the same issuance state.¶

• The granted authorization_details and any act chain appear only on an active response. An inactive response carries active: false and the mission state facts (Section 11.2), never the authority itself.¶

• A resource server consuming an opaque Mission-bound token:¶

  • MUST resolve it through introspection or issuer-local resolution (below) before service;¶

  • MUST verify active is true, its own identity in aud, and the sender-constraint binding cnf names; and¶

  • MUST enforce the response's authorization_details under the same rules as the token-carried form (Section 9), the fail-closed duties included.¶

• A resource server that cannot obtain a valid introspection response or issuer-local resolution for an opaque Mission-bound token MUST refuse the request rather than serve it from any cached or out-of-band belief about the token's authority.¶

The per-use freshness rule of Section 11 covers the whole response in this mode: each response is one observation of the token's claims and Mission state, not a cacheable authority record.¶

An AS MAY serve a resource server through issuer-local resolution: a direct read of the AS's authoritative committed token and grant state, not a call to an introspection endpoint. [RFC7662] introspection keeps its meaning as a network protocol. A resource server qualifies only when it is inside the issuer's trusted implementation boundary and the AS authorizes it to read that state; common ownership or a shared network does not by itself qualify it.¶

For each resolution, the AS:¶

1. MUST resolve the presented token to that token's own issuer-qualified issuance or grant record, and establish from that record the token's expiry, revocation and grant validity, its intended audience, the composite active state (Section 11.2), and the token's own authority;¶

2. MUST authorize the resource server and minimize disclosure to it as Section 11.1 requires for an introspection caller; and¶

3. MUST yield, when the token is active, only what an active response for that token carries in this mode, audience-filtered for that resource server and with act and cnf as that response carries them, and never the Mission's Authority Set or other authority the token does not carry.¶

Mission state alone, or a lookup by Mission Identifier, never establishes a token's validity or authority. An unknown, invalid, expired or revoked token, or a Mission that is not active, resolves as inactive and yields no authority; missing or unavailable state yields no valid resolution.¶

In the resource server duties above, the resolution stands in for the introspection response, possession proof and fail-closed refusal included, and each resolution is one per-use observation, not a cacheable assertion.¶

11.5. Introspection Response Examples

The following is an example of an introspection response for the canonical ERP token (Section 8.8) while the Mission is active. The issuer AS returns the standard [RFC7662] members and the mission member to a caller holding the deployment's audit-and-correlation disclosure privilege, so authority_hash and proposal_hash appear; the default audience-filtered enforcement projection omits them.¶

{
  "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"
  }
}

The following is an example of the response, after the Mission is revoked, for an unexpired token the AS issued on refresh before the revocation (Section 11.2):¶

{
  "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"
    }
  }
}

12.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 12.5).¶

A designation the AS issues:¶

• carries a subset (Section 5.4) of the presented token's authority, and the same mission claim (Section 8.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 proves its own key in the delegated exchange (Section 12.2), and the delegated token's act renders the AS's accounting (Section 12.5); and¶

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

A designation names a delegate and adds none. Whether one may be redeemed more than once within its lifetime is the AS's policy; each redemption is a delegated exchange of its own (Section 12.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 the AS reports one inactive at introspection (Section 11.2).¶

12.2. Delegated Exchange

A delegate obtains a delegated token by Token Exchange ([RFC8693]), presenting a designation that the delegating party obtained for it (Section 12.1). 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 12.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 an actor_token or by its own client authentication, and the AS asserts the actor itself (Section 12.5).¶

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

• client_id keeps its ordinary meaning. A delegated token's client_id is the OAuth client that requested it (Section 4.3 of [RFC8693], Section 2.2 of [RFC9068]). The originally-approved agent remains recorded in the Mission Record (Section 14, Appendix B.6).¶

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

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

• The mission claim is unchanged. The delegated token carries the delegating token's mission claim (Section 8.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 8.3) 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 8.2). The AS MUST evaluate every redemption of a designation afresh, as a derivation of its own: the credential the designation was derived from, and that credential's grant, are still valid; the Mission is active; and the delegation policy (Section 12.5) and the Mission's current authority admit the result. An earlier redemption establishes none of these.¶

The act chain nests (act.act) for as long as, and only while, authority continues under the same approved Mission. A new approval basis, such as a Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]) or an expansion successor ([I-D.draft-mcguinness-oauth-mission-expansion]), 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 12.5 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.¶

12.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 12.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 12.2 and Section 12.5 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 10 gives the error codes for these refusals.¶

If the exchange issues a refresh token, the grant-continuity rules of Section 5.1 of [I-D.draft-mcguinness-oauth-client-instance-id] apply alongside Section 8.1; 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.¶

12.4. 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 12.1) names a delegate, so it is not a self-exchange, and these rules do not apply to it. A no-actor exchange is subject to the following:¶

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 14). 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 8.8) and adds no act chain.¶

3. The exchange is a derivation, gated on the Mission being active (Section 8.2).¶

12.5. 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, and it is carried with the entries wherever they go, including across a cross-domain projection where that profile's provenance rule keeps it ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

Delegation depth. The delegation depth of a token is the number of delegations between the approved agent and the token's current actor: the agent's own non-delegated token is depth 0, the first delegate is depth 1, and each further delegate adds 1. The depth checked against max_depth is that of the token being issued, computed after appending the new outermost actor, not the depth of the delegating token. A credential projected across a trust domain carries no act chain and enters the target domain at depth 0 ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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

• a designation (Section 12.1) and a self-exchange (Section 12.4) add none; and¶

• a cross-domain projection is the one defined reset.¶

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

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

12.6. 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"
  }
}

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

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

13.1. Standing-Consent Instances

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

• the Subject is never taken from unauthenticated client input and is mapped injectively (step 2, Section 6.3);¶

• the authority source and its ceiling (Section 6.7);¶

• the effective expiry and its creation-commit check (steps 4 and 7);¶

• the integrity anchors (step 6); and¶

• atomic creation deduplicated on approval_event_id (Section 14).¶

13.2. Activation Policy Commitment

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

13.3. Standing-Consent Recency

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

• The evaluation instant is the atomic Mission-creation commit (Section 6), including the creation commit of a deferred or relocated flow. Recency is issuance-time eligibility only: a later change to a ceiling, or the passage of time past one, does not terminate an active Mission (Section 7.2).¶

• The activating issuer MUST refuse an approved_at later than the evaluation instant by more than the deployment's declared, bounded clock-skew allowance.¶

• Where ceilings are declared per consequence class, the issuer MUST classify the committed Mission from the derived Authority Set and from any consumption bound the Mission Intent carries (for example, [I-D.draft-mcguinness-mission-metering]), and MUST apply the strictest ceiling across every class present.¶

• The ceilings and the skew allowance belong to the versioned policy that policy_version identifies, or to a separately versioned declaration retained with it, so an auditor can reproduce the eligibility decision.¶

14.1. Identity and Lifecycle Members

id:

REQUIRED. A string. The canonical Mission Identifier (Section 14.5).¶

issuer:

REQUIRED. A string. The issuer URL of the Mission Issuer that approved the Mission. Equals the iss of tokens that AS derives; for cross-domain tokens it remains the issuer AS that approved the Mission even though the issuing iss differs ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

state:

REQUIRED. A string. The current lifecycle state: active or terminated in this document, or an additional state defined by a companion profile, subject to the forward-compatibility rule of Section 7.¶

termination:

CONDITIONAL. An object, present exactly when state is terminated: the reason and instant the Mission terminated (Section 7.1).¶

14.2. Approved Content and Commitments

intent:

REQUIRED. An object. The approved Mission Intent.¶

proposed_authority:

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

authority_set:

REQUIRED. An array. The consented Authority Set.¶

authority_hash:

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

intent_hash:

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

proposal_hash:

REQUIRED when proposed_authority is present, absent otherwise. A string. The integrity commitment over the recorded proposed_authority (Section 15.1). It is approval-time provenance, not enforcement input, and is not carried on the mission claim (Section 8.8).¶

submission_evidence:

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

type:

The entry's evidence type.¶

artifact_hash:

An integrity anchor (Section 15.1) with typ mission-intent-evidence over the entry exactly as presented.¶

verified_at:

An RFC 3339 timestamp of verification.¶

facts:

An object holding the verified output facts the type's specification selects for recording, nested so type-owned facts cannot collide with the common members.¶

submission_evidence is provenance, not enforcement input, and is not carried on the mission claim (Section 8.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 21.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 15.1, Section 16).¶

14.3. Principals and Approval Basis

subject:

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

approval_basis:

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

type:

REQUIRED. A string: direct, or a standing-consent value that a companion profile defines (Section 13).¶

An unrecognized type, and likewise an unrecognized adjudication.kind (Section 14), is preserved unchanged as opaque provenance on an otherwise valid record: a consumer MUST NOT infer or fabricate the human, policy, or Approval Governance Record standing behind it, and MUST refuse only a profile operation that itself requires recognized adjudication semantics to proceed (for example, evaluating a policy-approval recency ceiling). Unlike an unrecognized lifecycle state (Section 7), an unrecognized value here does not by itself invalidate or deactivate the Mission.¶

consent_principal:

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

activation:

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

activation_actor:

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

root_commitment:

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

adjudication:

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

kind:

REQUIRED. A string: human or policy, naming a decision mechanism, not a storage location for supporting evidence; a companion profile MUST NOT define a kind value that names a record, an evidence store, or the requesting or dispatching party. An unrecognized value is handled under the same rule as approval_basis.type (Section 14.3).¶

governance_record:

OPTIONAL. A boolean. true when an Approval Governance Record is recorded for this approval event ([I-D.draft-mcguinness-mission-approval-governance]), joined by this Mission's own approval_event_id. It never changes kind, which follows the basis (below and Section 13). Approval Governance aligns the record's accountable assertion, where it carries one, with that kind: a governed decision still names its mechanism, and the record supplies the fuller assertion set behind it, including any multi-assertion set, never flattened into it.¶

For kind: human: no additional kind-specific members; the deciding human is consent_principal.¶

For kind: policy: policy, a REQUIRED object with id and version identifying the deciding policy or workflow. It decides deterministically over recorded inputs, so re-evaluating that version over them re-checks the decision. A model's output can be one such input, recorded with the model's identifier and version: it can refuse an activation or narrow the authority it activates, and the AS MUST NOT let it supply or widen authority. A model is never itself the deciding policy or workflow.¶

Where adjudication is present for direct, kind MUST be human, with or without governance_record: a policy decides an instance only under a standing-consent basis (Section 13).¶

approved_at:

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

For direct, activation.approval_event_id MUST identify a human approval event (Section 6). Approval Governance states how a record backing a direct approval keeps that human decision as its accountable assertion ([I-D.draft-mcguinness-mission-approval-governance]).¶

approval_basis is provenance: none of the record's integrity anchors, such as intent_hash, authority_hash or proposal_hash, covers it (Section 15.1); a profile that commits the Mission Record itself covers it under that profile's own anchor. Two optional profiles commit it (Section 20.1.1). Mission Audit Transparency's approval-event registration ([I-D.draft-mcguinness-mission-audit]) covers the record at creation except its state and termination. Approval Governance's Approval Context Commitment ([I-D.draft-mcguinness-mission-approval-governance]) covers a closed manifest of creation facts that includes approval_basis. Its disclosure through introspection follows Section 11.1. It is not carried on the baseline mission claim (Section 8.8), and it MUST NOT be relied on to grant or widen authority wherever it does appear.¶

authority_source:

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

type:

REQUIRED. A string: user_delegated, service_owned, or organizational. An unrecognized value is handled under the same rule as an unrecognized approval_basis.type (Section 14.3): it is preserved unchanged as opaque provenance and does not by itself invalidate or deactivate the Mission, and only an operation that itself requires recognized source semantics refuses (for example, applying the source's authority ceiling or its governed policy). An AS MUST NOT approve a Mission whose authority source it does not recognize.¶

policy:

REQUIRED for organizational, absent otherwise. An object with id, version, and digest: the stable reference to, and commitment over, the governed organizational policy the Mission draws on. digest is a prefixed commitment (Section 15.3) whose exact committed input and construction the policy's format specifies: its species and, for an envelope anchor, its typ, iss, and value. The party that produces the reference computes digest; a consumer holding the policy can reproduce it, and one that does not compares it as an opaque value.¶

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

client_id:

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

14.4. Provenance and Expiry

policy_version:

REQUIRED. A string. An opaque audit correlator naming the derivation policy version in effect at the approval event; the policy itself does not travel.¶

approval_event_id:

REQUIRED. A string. A unique identifier of the approval event, used as the approval idempotency key: a retried or duplicate delivery of the same approval decision (a replayed callback, a double-submitted consent form) MUST NOT create a second Mission, and the AS deduplicates on this identifier.¶

created_at:

REQUIRED. A string. RFC 3339 timestamp of creation.¶

expires_at:

REQUIRED. A string. An RFC 3339 date-time: the AS-established effective Mission expiry (Section 7, Section 8.2). It MUST be later than created_at and MUST NOT be later than intent.expires_at, the requested ceiling (Section 4).¶

Shortening under applicable AS policy, or under an already-approved parent, predecessor, or standing-consent bound a Mission-creating profile defines, is ordinary narrowing of the granted lifetime, not Authority Set derivation; for direct creation under this document the only additional ceiling is applicable AS policy.¶

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

14.5. Mission Identifier Format

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

14.6. Mission Record Example

The following is an example of a Mission Record:¶

=============== 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"
}

The following example shows an excerpt, other members omitted, of a Mission for an agent acting for its own workload principal: subject is the workload principal, client_id is the agent, and consent_principal is the administrator who approved it under the service_owned source.¶

{
  "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"
  }
}

The first example's anchors are computed over its displayed intent, proposed_authority and authority_set (Section 15.1); the excerpt's root_commitment is illustrative. A companion that extends this example either reproduces the recorded objects byte-exactly or states that its example diverges and its anchors differ.¶

15.1. Integrity Anchors

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

1. Construct the envelope, where typ selects the committed object and value is that object:¶

   {
     "typ": "<mission-intent | mission-proposed-authority
             | mission-authority-set | mission-activation-policy>",
     "iss": "<the AS issuer URL>",
     "value": <the committed object>
   }
   

   ¶

   Each anchor sets typ and value as follows:¶

   • For intent_hash, typ is mission-intent and value is the approved Mission Intent object: the Submission envelope's intent member, not the envelope or its evidence (Section 4.2).¶

   • For proposal_hash, typ is mission-proposed-authority and value is the submitted authorization_details array exactly as recorded (Section 4.3); the anchor is present exactly when a proposal was submitted.¶

   • For authority_hash, typ is mission-authority-set and value is the Authority Set as a JSON array of entries.¶

   • For an activation policy reference's digest, typ is mission-activation-policy and value is the policy snapshot object that Section 13.2 defines.¶

2. Canonicalize the envelope with JCS [RFC8785].¶

3. Compute SHA-256 [RFC6234] over the canonical bytes.¶

4. Encode as sha-256: followed by the base64url, no-padding [RFC4648] encoding of the digest.¶

The typ field domain-separates the anchors so a digest of one object cannot be mistaken for another's. The iss binding prevents a committed object from being transplanted across authorization servers. The sha-256: prefix is the algorithm-agility mechanism (Section 15.3).¶

The anchors this section lists, and the Authority Set entry commitment below, bind the AS issuer. The digest of an authority_source.policy reference (Section 14.3) is not one of them: it uses the issuer the policy's format defines, for a governed organizational policy its governing authority. That binding keeps the policy's commitment from being transplanted across policy authorities, and the same policy commits identically at every AS that records it.¶

intent_hash and authority_hash are independent commitments to independent objects. That the approved task bounds the derived authority is a governance assertion, made by derivation policy and auditable through policy_version (Section 5), not a cryptographic relation between the anchors: neither anchor proves anything about the other's object.¶

The typ value space is an extension point (Section 16): additional committed objects use this same envelope with a new typ and the canonicalization below.¶

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

This document also defines the Authority Set entry commitment, the envelope above with typ mission-authority-entry, iss the Mission issuer, and value a single Authority Set entry object exactly as recorded (Appendix E). A companion that cites an entry by digest (a decision record naming the entry it evaluated, containment or completion state keyed to an entry) computes it this way.¶

Entries whose canonical commitment envelopes are identical produce the same digest, and within one Mission Record every recorded entry resolving to the same digest forms one selector equivalence class; the class is defined by the canonical bytes, not by pre-canonical source text the record does not preserve.¶

The commitment is not a globally unique entry identifier: the envelope binds the issuer, not the Mission, so a protocol that uses it to select or cite an entry MUST bind it to the Mission issuer and Mission Identifier whose recorded Authority Set is searched, directly or through an enclosing object whose integrity protection binds them.¶

authority_hash likewise commits an Authority Set, not a Mission: two Missions that approve byte-identical authority share it, and a consumer MUST NOT use it as a Mission Identifier or as a replay or idempotency key for a Mission.¶

15.2. Canonicalization Rules

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

• The committed value is exactly the object the AS recorded on the Mission: the approved intent for intent_hash, the recorded proposed_authority for proposal_hash, and the authority_set for authority_hash. An auditor reproduces a digest from the record alone.¶

• Duplicate member names are rejected at parse time (Section 15.3).¶

• JCS does not reorder array elements, and this document defines no element sorting, so array order is significant. The AS MUST present each committed array in its recorded order wherever it emits the committed object; that order is part of the canonical form.¶

• URI-valued members are compared byte-for-byte, with no normalization (Section 12 of [RFC9396]), unless a member's own type definition specifies a normalization. Where a type defines one, as mission_resource_access does for its prefix-match resource containment test ([I-D.draft-mcguinness-oauth-mission-resource-access]), it applies to that comparison alone: the default resource equality test remains an exact match, and anchor computation is always byte-exact over the recorded values.¶

15.3. 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 15.1 (intent_hash, proposal_hash, authority_hash, an activation policy reference's digest, and commitments produced with companion-defined typ values).¶

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

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

The prefix and agility rules below bind all three species. The I-JSON rule binds the two JSON species. The envelope and typ discipline of Section 15.1 binds envelope anchors alone.¶

This section instantiates 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.¶

Every committed JSON value and its envelope are I-JSON [RFC7493] data, as Section 3.1 of [RFC8785] requires. Strengthening Section 3.1 of [RFC8785], which adapts input to I-JSON, the party computing or verifying a commitment MUST reject non-conformant input before canonicalization rather than adapt it: externally received JSON destined for commitment is parsed by a duplicate-detecting parser, and an object carrying duplicate member names is rejected at parse time, before the parsed data model exists.¶

The commitment is over the parsed I-JSON data value, not the source text: JCS does not preserve a source lexeme's spelling or excess precision. A profile whose values need exact decimal or large-integer semantics carries them as strings, as Section 3.1 of [RFC8785] recommends, or defines a stricter numeric domain, as the Mission Resource Access Profile's Common Constraints do for constraint values ([I-D.draft-mcguinness-oauth-mission-resource-access]).¶

The security considerations of [RFC8785] apply to every JCS computation.¶

The algorithm prefix is the agility mechanism. sha-256 is mandatory to implement and the only algorithm this document defines. A new algorithm enters only through a new prefix defined by a referencing specification, its name drawn from the Named Information Hash Algorithm Registry ([RFC6920]); this document defines no negotiation.¶

A verifier MUST reject a digest whose algorithm prefix it does not recognize, so an algorithm added later cannot be exploited as a downgrade. These rules bind a prefixed digest of any species when its defining specification classifies it under this taxonomy and imports this section normatively; this document so classifies every anchor it defines.¶

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

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

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

• 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 (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 23.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) refuses any top-level member that neither this document nor an implemented companion profile defines, and the AS ignores none it recognizes. Registration settles which specification owns a short name; it does not make an AS implement, recognize, or trust any member.¶

• Integrity anchors. Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (Section 15.1). A consent-disclosure commitment, an instruction-text attestation, or a delegation receipt can be committed this way without changing this document. A profile that commits an evidence or disclosure object MUST commit it with this envelope and a typ that meets Section 15.1, 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 8.8), optionally extended with collision-resistantly named members (for example, an intent_hash for audit), and is never authority-bearing on its own.¶

• The mission claim. It is an open object: additional, collision-resistantly named members can be carried in it (for example, a runtime decision reference, a delegation receipt, or an attestation reference), under the consumer rules of Section 8.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 14 states.¶

• Lifecycle state and termination reason. The lifecycle state space (Section 7) is open to additional states that companion profiles register in the Mission Lifecycle States registry (Section 23.7) for lifecycles they introduce. The termination reasons (Section 7.1) are likewise open to reasons that companion profiles register in the Mission Termination Reasons registry (Section 23.8). Under the forward-compatibility rule of Section 7, only active permits issuance.¶

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

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 16.2 states the general rule these extension points follow.¶

16.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 23.7), Mission Termination Reasons (Section 23.8), and Mission Intent Members (Section 23.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 8.8) and the Mission Record members (Section 14), 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 15.1) names a hash domain, not a representation crossing a protocol boundary, and is not a media type.¶

19.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, Section 14);¶

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

• the subset rule (Section 5.4); and¶

• gating of issuance on Mission state (Section 8.2).¶

An AS can conform as a Mission Issuer without supporting any Intent Submission Evidence type. Such an AS refuses every presented entry as an unsupported type under the dispatch and refusal rules (Section 4.4), with the invalid_mission_intent_evidence error code. It need not implement the evidence framework of [I-D.draft-mcguinness-oauth-mission-submission-evidence] for this configuration. The companion defines conformance for ASs supporting an evidence type, whether its evidence is optional or required.¶

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

In either form, it enforces each applicable entry its tokens carry under that entry's type, which for mission_resource_access is work a plain [RFC9068] resource server does not do.¶

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 (Section 8.4); and¶

• obtaining mission_id from the mission_id token-response parameter or the mission claim's id (Section 8.1.4), treating it as a reference, not a credential.¶

19.2. Optional Capabilities

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

• Delegation (Section 12): issuing designations (Section 12.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 primary tokens.¶

• Introspection (Section 11): 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 11.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 7, Section 8.2); and¶

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

  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, and implementations that interoperate across the hop implement that companion.¶

Mission Approved-Set Verification ([I-D.draft-mcguinness-oauth-mission-approved-set-verification]) defines an independent check, by a resource server or policy decision point, that a token's carried authority is a subset of the complete approved Authority Set; conformance to this document does not require it.¶

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

A token carrying a mission claim is not, by itself, Mission-bound authorization. Conformance as a Mission Issuer requires the gates: authority derived from the approved Intent and committed by the anchors (Section 6), issuance bounded by the subset rule (Section 5.4), and derivation gated on Mission state (Section 8.2). 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 17), 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 publishes a Mapping Assessment of how the surfaces above realize the Mission Substrate contract's kernel and capabilities (Appendix F). It is not this document's conformance result: this document makes no substrate-conformance claim, takes no requirement from the substrate, and remains self-contained; its reference to the substrate contract ([I-D.draft-mcguinness-mission-substrate]) is informative.¶

20.1. Commitment and Consent Integrity

20.2. Agent-Specific Threats

20.3. Enforcement Boundaries

20.4. Credentials and Delegation

20.5. Composition and Residual Authority

21.1. Mission Identifier Correlation

This document carries a single canonical Mission Identifier on every derived token, and cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]) carries it across trust domains unchanged. Any party that observes credentials for the same Mission, whether a resource server, a Resource AS, or an auditor spanning audiences, can correlate that activity by the Mission Identifier, and mission.issuer further identifies the issuing AS.¶

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

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

21.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 8.4).¶

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

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

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

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

• target_resources and any explicit member a companion profile defines (for example, the metering companion's consumption bounds, [I-D.draft-mcguinness-mission-metering]);¶

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

• submission_evidence facts, including a consent reference.¶

Whatever the member, it:¶

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

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

• if committed, is confirmable through the unsalted anchors by any party holding a candidate value (Section 21.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.¶

21.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 14.4).¶

Where approval-event evidence was registered under the audit transparency profile ([I-D.draft-mcguinness-mission-audit]), its erasure record and data-subject-request basis are the transparency-side mechanism. That mechanism records an erasure but neither performs one nor overrides retention law, and it leaves the operational Mission Record and its audit-horizon retention floor untouched.¶

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

• Parameter name: mission_error¶

• Parameter usage location: token response¶

• Change controller: IETF¶

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

• Parameter name: mission_expires_at¶

• Parameter usage location: token response¶

• Change controller: IETF¶

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

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), for which no IANA registry exists; no action is required for it.¶

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

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

23.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 11).¶

• Change Controller: IETF¶

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

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

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

23.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 7 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 23.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 7). 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 23.8).¶

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

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

23.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 16). 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.¶

24.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., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-00>.

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

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

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

[FAPI.GrantManagement]

OpenID Foundation, "Grant Management for OAuth 2.0", 2023, <https://openid.net/specs/oauth-v2-grant-management.html>.

[I-D.draft-cecchetti-oauth-rar-cedar]

Cecchetti, S., "Cedar Profile for OAuth 2.0 Rich Authorization Requests", Work in Progress, Internet-Draft, draft-cecchetti-oauth-rar-cedar-02, 21 February 2024, <https://datatracker.ietf.org/doc/html/draft-cecchetti-oauth-rar-cedar-02>.

[I-D.draft-ietf-oauth-spiffe-client-auth]

Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-02, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

[I-D.draft-ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-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-00, 15 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00>.

[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-audit]

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.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-capability-binding]

McGuinness, K., "Mission Capability Binding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-capability-binding.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-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-00>.

[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-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

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

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

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

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

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

McGuinness, K., "Mission Continuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-continuation.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-cross-org-delegation]

McGuinness, K., "Mission Cross-Organizational Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-org-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-derivation-limits]

McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-derivation-limits.html>.

[I-D.draft-mcguinness-oauth-mission-device-authorization]

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

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

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

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

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

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

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.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-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.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>.

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

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

[I-D.draft-mcguinness-oauth-mission-work-products]

McGuinness, K., "Mission Work Products for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-work-products.html>.

[I-D.draft-niyikiza-oauth-attenuating-agent-tokens]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01>.

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

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

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

[RFC8935]

Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, November 2020, <https://www.rfc-editor.org/rfc/rfc8935>.

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

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

A.1. Stage 0: Agent Identity (by Reference)

The agent is an OAuth client with a workload identity, for example one established using WIMSE [I-D.draft-ietf-wimse-arch] or SPIFFE [I-D.draft-ietf-oauth-spiffe-client-auth]. alice has delegated to it through an ordinary authorization code flow, per [I-D.draft-ietf-wimse-aims]: the client_id claim names the agent, and the sub claim identifies alice. This document adds the Mission layer to that identity; Stage 0 is otherwise unchanged from that specification.¶

A.2. Stage 1: Mission Creation

The following example shows the Submission envelope the agent pushes through PAR (Section 4.2), carrying the Mission Intent and no evidence:¶

=============== 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"],
    "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"
  }
}

In the same push, the agent proposes concrete authority on the authorization_details parameter (Section 4.3):¶

[
  { "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" }
    } }
]

Both are parameters of one pushed authorization request ([RFC9126]), with PKCE ([RFC7636]); client authentication is omitted, and extra line breaks are for display purposes only:¶

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

response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fagent.example.com%2Fcb
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
&mission_intent=%7B%22intent%22%3A%7B%22goal%22%3A%22Reconcile...
&authorization_details=%5B%7B%22type%22%3A%22mission_resource_acc...

The AS returns a request_uri:¶

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store

{
  "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc",
  "expires_in": 60
}

and the agent sends alice's user agent to the authorization endpoint with it:¶

GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
  %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc HTTP/1.1
Host: as.example.com

The AS (as.example.com) validates both, derives this Authority Set (each entry a same-type subset of a proposed entry, Section 4.3), and renders it for alice's consent:¶

[
  { "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" }
    } }
]

alice approves at 08:00:00 UTC on 2026-11-02, and the AS records Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- in the active state with authority_hash sha-256:hjXlwWBY64-RPs1Z-E_gbyklNcViI5c9jiyMbE4KvFM, intent_hash sha-256:6T-7s_f-mNW9UpfrrZh3r0HRJmU4My_EsNAf1C1U4r0, and proposal_hash sha-256:p-s-EzdNQTn6RoPHXESkwVtGdk8yL1PxryNyMwroKGo.¶

A.3. Stage 2: Mission-Bound Token Issuance

At 08:00:05 the agent redeems the authorization code with its PKCE verifier and a DPoP proof ([RFC9449]):¶

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

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fagent.example.com%2Fcb
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

The AS resolves the Mission from the grant (Section 8.1.1), checks that it is active (Section 8.2), and issues a Mission-bound access token for the ERP and a refresh token. The token response carries the granted authorization_details echo (Section 8.4) and the mission_id and mission_expires_at response parameters (Section 8.1.4):¶