Mission-Bound Authorization for OAuth 2.0

1.1. Why a New Object

OAuth already has objects near this need, but none is the approved task. A scope value or an authorization_details entry ([RFC9396]) expresses authority but neither the task it serves nor a lifecycle of its own. An access token is a short-lived projection; its jti identifies the token, not the task. A refresh token preserves the ability to obtain further tokens but commits no bounded, approved authority. A consent record proves that an approval event happened; it does not govern the resulting work as it continues. The Mission is the durable object these project from: the approved task that bounds and outlives them, and that every derived token refers back to.¶

Rich Authorization Requests express authority; a Mission expresses an approved task with a lifecycle; that approved-task lifecycle, not a new way to express authority, is what OAuth lacks. A Mission is therefore not another authorization_details type; it is the durable, approval-backed object an Authority Set is derived for and gated by.¶

1.2. Relationship to Adjacent Work

A grant, in the sense of FAPI Grant Management [FAPI.GrantManagement], is a durable, queryable, revocable container of consented authorization data. It records consent to authority but carries no task, no integrity commitment, and no derivation gating; a deployment MAY surface Mission revocation through a grant-management-style API. [I-D.draft-klrc-aiagent-auth] names the agent's mission and leaves its translation into authorization out of scope; this document specifies that translation, reusing its agent-as-client and delegating-principal-as-token-sub assignments unchanged (Section 3.1), and an agent authenticated and delegated per it uses the mechanisms here to obtain Mission-bound tokens. Decision-layer access-request and approval workflows, such as the OpenID AuthZEN Access Request and Approval Profile [AuthZEN.ARAP], manage approval tasks but define no issuance binding; this document supplies the issuance-bound object such workflows complete into.¶

Nearby individual proposals each carry one Mission property without the others: task-linked Rich Authorization Requests with revocation webhooks carry a task link, intent-digest admission assertions carry an intent commitment, and offline capability attenuation ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens]) carries offline narrowing. None combines the durable approved object, state-gated issuance, and integrity anchors this document defines.¶

The Grant Negotiation and Authorization Protocol [RFC9635] occupies much of the same design space as this document: a continuable authorization request, richer client instance identification, and native support for delegation. This document takes a different path for the estates it targets. Rather than introduce a new grant protocol, endpoints, and client machinery, it composes with the OAuth 2.0 surfaces already deployed: Pushed Authorization Requests ([RFC9126]), Rich Authorization Requests ([RFC9396]), DPoP ([RFC9449]), and [RFC9068] access tokens. A Mission derives from and issues through those surfaces rather than replacing them, so an estate that already runs PAR, RAR, and sender-constrained tokens adopts the Mission model without standing up a GNAP grant endpoint or migrating its clients to it. Where a deployment starts from GNAP rather than from OAuth 2.0's authorization code grant, the Mission model, a durable, approval-anchored, integrity-bound task object gating derivation, is the OAuth-native instantiation of a binding-neutral contextual-governance kernel that admits a candidate binding onto that substrate; this document does not define one.¶

The Authority Set's subset rule (Section 5.1) and the offline attenuation it supports continue a lineage of capability systems: macaroons' caveat narrowing, Biscuit's offline attenuation blocks, UCAN's delegation chains, SPKI/SDSI's local-name reduction, and object-capability designs generally, in which a holder narrows what it passes on and the narrowing needs no further contact with an issuer to be enforced. This document's distinction is not the narrowing rule itself but what it narrows: a durable, approval-anchored governance object, centrally revocable by its issuer for the Mission's full lifetime, rather than a bearer credential whose only life is the caveats attached to it. A delegate's or an offline holder's attenuation narrows within that governance object; it does not replace it, and revoking the Mission still reaches everything derived from it that has not already left the issuer's reach (Section 10.2).¶

1.3. The Mission, the Plan, and Execution

The Mission is the durable, AS-held object that commits the approved authority and owns the task's lifecycle. Two related things an agent produces around a task are deliberately not the Mission and carry no authority of their own.¶

The agent's plan, how it decomposes the task, chooses tools, and delegates to sub-agents, is the agent's own strategy and is out of scope for this document. It grants nothing: authority a sub-agent exercises is carried by the act chain (Section 12), derived from the Mission and only ever narrowed from it (Section 5.1), never created by the plan.¶

The agent's execution, the tokens it derives, the calls it makes, and the decisions taken on them, references the Mission but cannot expand it. Revoking the Mission stops further derivation (Section 10); it does not undo actions already completed. Evaluating each action against the Mission at the point of use is the runtime layer's concern (Section 17.3.1), not this document's.¶

The invariant across all three: the plan and the execution draw on the Mission's authority; neither enlarges it.¶

1.4. Applicability

This profile 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. It is not intended for, and adds cost without benefit to, 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 3.2).¶

A Mission SHOULD be scoped to a concrete task, not to an agent's whole lifetime. A deployment SHOULD prefer narrow, per-task Missions, each separately approved and revocable, over a single broad standing Mission that accumulates authority across unrelated tasks. The durable object is the approved task: keeping it task-scoped is what makes its authority and audit meaningful and bounds the blast radius on compromise to one task. An agent pursuing many tasks holds many Missions, not one broad one.¶

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 what content flows within an authorized action, and an approved egress channel carries a status update or an exfiltrated payload with equal authority. Content-level controls (data loss prevention, redaction) are complementary, and mediated execution places their natural insertion point at the mediating enforcement component (Section 17.3.1, [I-D.draft-mcguinness-mission-runtime]).¶

1.5. Scope and Future Work

This document is a self-contained, minimum-viable profile: it binds Missions to OAuth 2.0 and is implementable on its own, depending only on the OAuth and JOSE specifications it cites.¶

It references the OAuth Actor Profile ([I-D.draft-mcguinness-oauth-actor-profile]), an in-progress individual draft, for the act chain shape the OPTIONAL Delegation capability uses. That reference is informative and confined to Delegation, so the mandatory single-domain core does not depend on it, and this document's RFC path does not wait on that draft's. Cross-domain projection, a single hop that lets an Authorization Server in another trust domain honor a Mission, is specified by the companion Mission Cross-Domain Projection profile [I-D.draft-mcguinness-oauth-mission-cross-domain], which carries the identity-chaining and ID-JAG dependencies with it; the Cross-Domain capability's conformance bar is self-contained in this document (Section 16), so that companion is not a normative dependency.¶

Separate from this document, and not required to implement it, several capabilities are specified as OPTIONAL companion profiles:¶

• an additional integrity anchor over a structured consent disclosure (consent_rendering_hash, Section 17.1.1), defined by Mission Consent Evidence [I-D.draft-mcguinness-oauth-mission-consent-evidence];¶

• mission expansion, defined by Mission Expansion [I-D.draft-mcguinness-oauth-mission-expansion]; and¶

• a cross-domain status or event-distribution mechanism for tighter revocation, defined by Mission Status [I-D.draft-mcguinness-oauth-mission-status] and Mission Lifecycle Signals [I-D.draft-mcguinness-oauth-mission-signals].¶

A deployment implements this document without any of them. A binding-neutral contextual-governance kernel, of which this document's Mission model is the OAuth-native instantiation, is specified separately and is out of scope for this document.¶

Remaining future work, not yet specified, includes:¶

• the normative carriage of Mission context in Transaction Tokens ([I-D.draft-ietf-oauth-transaction-tokens]), shown only illustratively in the companion's end-to-end example; and¶

• for a community that wants cross-vendor agreement on what a task authorizes within a vertical, an OPTIONAL derivation profile: a registry of standard task types mapped to authority templates, so that two vendors in that profile derive comparable Authority Sets. This document deliberately does not standardize the derivation algorithm itself (Section 5); a vertical profile is the appropriate vehicle where portable derivation is genuinely needed.¶

1.6. Non-Goals

The following are deliberately out of scope. Each is a recurring question for agent authorization; naming it here records that it was considered and where it belongs, not that it was overlooked.¶

• Semantic / intent verification. This profile binds a token to an approved authority and task; it does not evaluate whether a given runtime action serves the Mission's purpose beyond matching the approved authorization_details and constraints. Per-action evaluation is the runtime layer's role (Section 17.3.1). Verifying an agent's declared reasoning against the task is a further attestation problem outside both layers.¶

• Approval-free authorization upgrade. The Authority Set is committed at approval; this profile defines no mid-stream widening that bypasses consent. Widening requires a new approval, a successor Mission, as specified by Mission Expansion [I-D.draft-mcguinness-oauth-mission-expansion]; a widening that no consent authorizes remains out of scope.¶

• Lifecycle event distribution. A Resource Server learns Mission state from the token lifetime or optional introspection (Section 11); this profile defines no push-based notification of Mission state changes. A Shared Signals ([RFC8935]) / CAEP profile for Mission lifecycle events is specified separately by the Mission Lifecycle Signals profile ([I-D.draft-mcguinness-oauth-mission-signals]), not here.¶

• Human-in-the-loop suspension. The base lifecycle here is active, revoked, expired (Section 10). A suspended state with resume/complete transitions is defined as an OPTIONAL extension by the Mission Status and Lifecycle profile ([I-D.draft-mcguinness-oauth-mission-status]); a pending-human-approval state and a holding-token pause-and-resume protocol remain future lifecycle work.¶

• Multi-hop cross-domain provenance. A single cross-domain hop is specified by the companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]); chaining a Mission across more than one trust-domain boundary, and the verifiable provenance that would require, are future work.¶

• Decentralized agent identity. Agent identity and credentialing are out of scope ([I-D.draft-klrc-aiagent-auth], and workload identity efforts such as WIMSE, [I-D.draft-ietf-wimse-arch]); this profile governs the approved-task artifact those identities act within, not the identities themselves.¶

• Cross-audience unlinkability. A single canonical Mission Identifier and the authority_hash it shares deliberately let any party correlate a Mission's activity across audiences and resources. This is a design choice, not an omission: a stable, correlatable anchor is what lets a Resource Server, a cross-domain Resource AS, and an auditor bind evidence to one approved Mission, which is a core goal of this document and its companion profiles. Pairwise or unlinkable presentation of Mission-bound authority works against that anchor and is therefore future work (Section 19.1).¶

3.1. Principal Model

This document maps principals onto native OAuth constructs:¶

• The Agent is the OAuth client, referenced by client_id. Agent identity and credentialing are out of scope (see [I-D.draft-klrc-aiagent-auth]).¶

• The Subject and Approver are each an (iss, sub) pair, matching the access token sub model of [RFC9068]. The Approver is the accountable principal whose approval created the Mission; it may be a human or an authorized policy authority (Section 6.2).¶

On a derived token the sub claim is the AS-local sub the AS maps the Subject to under the injective mapping of Section 6, verbatim adoption of the external sub being the common case, and the token iss is the AS; 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: this pair is the external subject identity, carried as provenance for audit and not on the token, and this document defines no runtime lookup of it (there is no by-Mission status endpoint). 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 companion's cross-domain grant conveys Subject identity to the Resource AS through its own subject-resolution claims ([I-D.draft-mcguinness-oauth-mission-cross-domain]), not through a Mission lookup.¶

Issuer roles obey three invariants: a Mission has exactly one Mission Issuer, its issuer; a Resource AS never creates or alters a Mission; and a local token minted in another domain preserves the mission claim unchanged ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

Principals are recorded at the approval event and are immutable. Two principals are equal when their iss and sub are byte-equal, a test that therefore compares principals only within one issuer namespace; the external subject identity and the AS-local subject principal are two representations of one Subject and are never compared to each other under this rule. Dynamic delegation (the actors an agent delegates to during execution) is carried on derived tokens via the act chain (Section 12), not on the immutable Mission record. Richer subject identifier formats (for example, the formats of [RFC9493]) MAY be layered in future versions and are not required here.¶

3.2. Authority Sources

A Mission draws its authority from one of three sources: a delegating person's own authority (user-delegated), a workload's own provisioned authority (service-owned), or explicitly governed organizational policy with a named accountable owner (organizational). 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 8), and the two compose: any source may activate through a direct approval event or through a standing-consent basis a companion defines. Approval activates authority the source already holds and manufactures none: the AS establishes the source and verifies the derived Authority Set against it before approval (Section 6).¶

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

• The accountable principal is the record's approver, equal to 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: some work is not any one person's, and borrowing a human subject for it blurs the actor, the subject, and the accountable principal exactly where the record keeps them distinct. The injective mapping of Section 6 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 merely the task's beneficiary.¶

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

3.3. Protocol Flow

 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

The flow then leaves the AS: (4) the agent calls the Resource Server with the token; the RS enforces the authorization_details statelessly and MAY check the mission claim, with no callback to the AS required. (5) A management revoke, or expires_at passing, moves the Mission to revoked or expired, after which the AS refuses further issuance and refresh; a deployment MAY additionally compose RFC 7009 [RFC7009] refresh-token revocation (Section 10.2). The end-to-end example (Appendix A) walks this flow with concrete messages.¶

4.1. Submission via PAR

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 Mission Intent Submission envelope (the Submission envelope), a JSON object carried as an ordinary OAuth request-parameter value (form-encoded in the application/x-www-form-urlencoded PAR request body, like other OAuth parameters) 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.3). When present it MUST be non-empty: omission already expresses absence, and the AS refuses an empty array with invalid_request, preserving one closed canonical syntax for "no evidence".¶

The Submission envelope separates the semantic task from material presented about it: intent_hash commits exactly the intent object, never the Submission envelope or its evidence array (Section 7.1), so an evidence artifact can commit to the intent_hash of the Intent it supports without becoming part of the object that hash covers.¶

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

Submission is governed by the following rules:¶

• Closed top levels. The Submission envelope is closed: the AS MUST reject with invalid_request an envelope containing a top-level member other than intent and evidence. A bare Mission Intent submitted as the parameter value fails this rule, since its goal and sibling members are unknown envelope members. The Mission Intent's own top level is likewise closed: the AS MUST reject with invalid_request an intent containing a top-level member this document does not define; extension data belongs under controls (Section 4), so deployment-defined semantics are explicit and cannot masquerade as core Intent semantics. Both top levels are closed because their members feed approval rendering, the intent_hash commitment, and evidence dispatch, and the closure also keeps issuer-output members, such as a client-planted authority_hash, out of the Intent.¶

• Derivation failure is distinct from syntax. For an Intent that is well-formed but yields no valid Authority Set (an unsupported resource, action, or authorization details type, or a policy that bars the requested authority), the AS SHOULD refuse with invalid_authorization_details ([RFC9396]), whether or not the request carried an authority proposal (Section 4.2), so a client can tell a syntax error from a derivation failure.¶

• One carriage, through PAR. The Intent is accepted as the form-encoded mission_intent parameter of the PAR request body, or as a mission_intent claim inside a signed Request Object ([RFC9101]) that is itself pushed through PAR. 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: mission_intent MUST NOT appear 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, the [RFC9101] duplication rule applied to this parameter. A single point of precedence keeps the member set the AS validates and bounds in one place; PAR keeps the integrity-sensitive Intent off the untrusted front channel.¶

• 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, so an oversized submission cannot exhaust the AS at rendering, derivation, verification, or hashing. The verification-cost bound of Section 4.3 accompanies these.¶

• Concrete authority is proposed via authorization_details. A client proposing concrete authority submits the standard [RFC9396] authorization_details request parameter alongside mission_intent in the same push, as a proposal subject to derivation (Section 4.2); mission_intent itself carries no authority members. A client MAY submit scope and resource ([RFC8707]) values. The AS treats them as a requested subset and MUST NOT grant authority beyond what the Mission Intent yields.¶

• Pushed parameters are authoritative. On the front-channel request that redeems the request_uri, the AS MUST ignore any mission_intent, authorization_details, scope, or resource presented, and MUST NOT let such a value widen the authority derived from the pushed parameters.¶

• A proposal, never authority. A Mission Intent, and any authority proposal submitted alongside it (Section 4.2), is untrusted client input; trust enters only when the AS validates it and the Approver consents to the rendered result. The AS MUST treat the submission as a proposal and MUST derive and bound authority by policy regardless of what the client submitted. How a client produces the Intent (for example, a "Mission Shaper" deriving it from a natural-language instruction) is out of scope for this document.¶

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

{
  "intent": {
    "goal": "Reconcile Q3 invoices and post adjustments under $500.",
    "resources": ["https://erp.example.com"],
    "expires_at": "2026-12-31T23:59:59Z"
  },
  "evidence": [
    {
      "type": "urn:example:intent-evidence:admission",
      "assertion": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImFkbS0xIn0..."
    }
  ]
}

4.2. The 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.1). The Mission Intent carries no authority members: an Intent carrying one (a proposed_authority member among them) is refused as an unknown top-level member under the closed-top-level rule of Section 4.1.¶

The submitted authorization_details is a proposal, never authority, under the submission trust rule of Section 4.1: the AS derives and bounds the Authority Set by policy regardless of what was submitted (Section 5) and MUST NOT grant authority beyond what the Mission Intent yields.¶

Each submitted entry MUST be of a type the AS advertises and MUST validate against that type's published JSON Schema (Section 5.3, Section 14); where a deployment arranges Mission-bound authorization out of band rather than advertising the metadata endpoint, the supported types and their schemas are established out of band, and this rule applies over that knowledge the same way. This is the [RFC9396] Section 5 validation of the standard parameter: the AS MUST refuse a request carrying an entry of an unadvertised type, or an entry that fails its type's schema, with invalid_authorization_details; a validation failure is never repaired by omitting the entry. Policy narrowing is distinct. During derivation the AS MAY narrow or omit a syntactically valid entry that policy cannot accept (Section 5); it MUST NOT keep such an entry silently, and the granted authorization_details echo (Section 9) MUST reflect every narrowing and omission, so no entry is ever represented as granted when it was not.¶

When a proposal is present, the AS MUST derive each Authority Set entry as a subset (Section 5.1) of some proposed entry of the same type: a mission_resource_access entry derives only from a mission_resource_access proposal, under the subset rule of Section 5.1; an entry of another AS-supported type derives only from a same-type proposal, narrowed under that type's own subset rule where it defines one, or carried through unchanged where it defines none (Section 5.3). No entry derives from a proposed entry of a different type. goal and constraints 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 resources; the AS refuses a request violating this with invalid_request.¶

The proposal rides the Intent's carriage rules (Section 4.1): it is accepted only through PAR, inside the Request Object when one is used ([RFC9101]), it is ignored on the front-channel request that redeems the request_uri, and the bounded-size rule applies to it the same way. The AS records the submitted array on the Mission exactly as submitted and commits it by proposal_hash (Section 7.1, Section 8), present iff a proposal was submitted: what the agent asked for is committed separately from the task (intent_hash) and from what was granted (authority_hash), so a narrowed grant 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; the client-side and AS-side duties that keep a governed task from downgrading across that line are stated in Section 14 and Section 17.1.2.¶

Example authority proposal, submitted alongside the example Intent of Section 4. Derivation narrows invoices.* to invoices.read bounded to a Q3 issuance window, halves the proposed ceiling under the Intent's constraints, 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.3. 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. Intent Submission Evidence is inbound and client-presented; it is not the evidence this document and its companions emit and record as output (a consent-evidence artifact, a runtime decision record, an audit evidence base, [I-D.draft-mcguinness-mission-audit]). The naming keeps the two apart: evidence in this section is what a client shows the AS about a submission, and emitted Evidence is what the issuer or runtime records about its own decisions.¶

Each entry is a JSON object with a REQUIRED type member: a string naming the evidence type as a collision-resistant name, under the same guidance as anchor typ values (Section 7.1). The specification that owns a type defines the entry's remaining members as a closed schema, the artifact format, the verification procedure, and the verified output facts that verification yields. The generic entry has no other members: as with an [RFC9396] authorization-details type, the selected type owns the entry's exact members and semantics, and this document defines no bag of optional format, issuer, subject, reference, digest, or criticality members. This document defines no evidence types; a companion profile defines the first, and an AS that supports none refuses every presented entry under the dispatch rule below, which is the correct refusal, not a gap.¶

Processing is governed by the following rules:¶

• Reject, never ignore. An entry that is not a JSON object, or that lacks type, is structurally invalid and refused with invalid_request. The AS MUST refuse an entry whose type it does not support, and an entry that fails its type's validation or verification, with invalid_mission_intent_evidence (Section 20). Evidence presented for admission MUST NOT be silently ignored, dropped, or demoted to advisory input: a submission is accepted only when every presented entry verified.¶

• Policy input, never authority. A verified entry MUST NOT be interpreted as authority, copied into the Authority Set, or treated as the Mission approval event. Verified evidence MAY serve as authenticated input to the AS's admission and derivation policy; the AS remains responsible for deriving and bounding the Authority Set (Section 5), and the approval event (Section 6) remains the sole activation of authority. Verification authenticates the artifact issuer's claims; AS policy decides whether those claims are acceptable for this request.¶

• Required evidence is resolved before derivation. Rejecting presented evidence does not defend against evidence a client omits. The AS determines the evidence types its applicable profile, client, resource, or admission policy requires before derivation. When a required type is absent from the submission, the AS MUST refuse with invalid_mission_intent_evidence, and successful processing of a submission without evidence MUST NOT be interpreted as satisfying an evidence requirement. This is the submission-plane form of the downgrade-by-omission duty (Section 17.1.2).¶

• Evidence binds one exact Intent. Evidence bound to an intent_hash applies only to that exact semantic Intent. Any shaping or approval revision that changes intent_hash MUST obtain new evidence, unless the evidence type's specification explicitly authorizes defined transformations and defines how their lineage is verified. Evidence for the predecessor Intent MUST NOT be treated as evidence for the revised Intent.¶

• The exchange establishes the presenter; the evidence must agree. The AS establishes the presenter through the containing exchange: client authentication and, where present, proof of possession. An entry that names an authorized presenter (a client_id, a cnf key binding) MUST match the established presenter, and a mismatch fails that entry's verification. Evidence is never an alternative client-authentication mechanism and never selects the presenter.¶

• Bounded verification. Beyond the size and count bounds of Section 4.1, the AS MUST bound the verification cost a submission can impose (for example, the number of signature verifications it performs), refusing a submission that exceeds the bound with invalid_request, so presented evidence cannot exhaust the AS any more than an oversized Intent can.¶

On a surface that carries a Mission-creation idempotency fingerprint (the expansion and child-creation token exchanges, [I-D.draft-mcguinness-oauth-mission-expansion]), presented evidence affects admission, derivation, approval, and side effects and is therefore a member of that fingerprint; the profile that owns the fingerprint lists it. On those surfaces, recovery of a completed operation under the creation-idempotency rules ([I-D.draft-mcguinness-oauth-mission-expansion]) returns the recorded outcome without re-verifying the presented evidence: verification happened when the operation ran, and an artifact whose freshness or status has since lapsed does not invalidate the recovery of an already-completed request. PAR-based creation and surfaces that submit no Mission Intent carry no such fingerprint and retain their own replay and idempotency mechanisms.¶

4.4. Submission Processing Order

The AS processes a submission in this order:¶

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

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

3. Compute the provisional intent_hash over the intent object (Section 7.1).¶

4. Resolve the evidence types policy requires, and refuse a submission missing a required type.¶

5. Verify every evidence entry under its type's rules, verifying that intent-bound evidence names exactly the provisional intent_hash and is bound to this AS and to the established presenter.¶

6. Apply admission policy and derive the Authority Set independently (Section 5).¶

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

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

The material verified provenance of step 7 is part of the approval surface, not an annotation beside it: where a deployment commits the rendered approval surface, the commitment MUST cover the normalized provenance facts, at least as a digest of their canonical submission_evidence representation (Section 8), so the committed rendering proves which provenance supported the decision. The consent-evidence companion binds this with a submission_provenance_hash inside its committed disclosure ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

Schema validation and the provisional hash precede signature verification, so the AS never verifies artifacts for a submission it would refuse on shape, and so intent-bound evidence has a hash to be checked against.¶

5.1. Subset Rule

When the AS narrows the Authority Set for a derived token, a derived mission_resource_access entry A is a subset of a Mission entry B when:¶

1. A's effective resource set is contained in B's (resource_match, Section 5): when neither entry sets resource_match: "prefix", A.resource equals B.resource; when B is a prefix entry, A (whether exact or prefix) is contained when A.resource equals B.resource or extends its path at a path-segment boundary; a prefix A is never contained in an exact B.¶

2. Every A.actions value is within some B.actions value: a value is within an equal value; a literal action is within a family whose name it extends at a segment boundary (invoices.read is within invoices.*); a family is within a reference family when its own name extends the reference's name at a segment boundary (invoices.q3.* is within invoices.*). A family is never within a literal action.¶

3. For every key K in B.constraints:¶

   • K MUST also be present in A.constraints. A key present in B but absent from A is treated as the broadest possible value and therefore fails this test.¶

   • A's value MUST be no broader than B's under K's subset rule: the specification-defined rule when K is a Common Constraint (Section 5.2), the deployment-defined comparison otherwise.¶

The AS MUST refuse to derive an entry that is not a subset of some Mission Authority Set entry.¶

Authority under a Mission MUST NOT widen after the approval event: a request that exceeds the Authority Set on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation) is refused under this rule, and broader authority requires a fresh approval event, either a new Mission or a successor per the companion [I-D.draft-mcguinness-oauth-mission-expansion].¶

Resource containment under a prefix reference is compared after RFC 3986 [RFC3986] syntax-based normalization of both URIs: lowercase the scheme and host, remove a default port, uppercase the hexadecimal digits of any percent-encoding ([RFC3986] Section 2.1, so %2f and %2F are equivalent), decode percent-encoded octets of unreserved characters, and remove dot-segments. This normalization applies to comparison only, never to hashing: anchor computation (Section 7.1, Section 7.2) remains byte-exact over the recorded values and is untouched by this rule.¶

The default comparison is deliberately flat: resource matches by exact equality and a literal action by array membership. Hierarchy is opt-in and closed to the two forms above: resource_match: "prefix" for resource containment and .* action families for action containment (Section 5). A deployment that uses neither retains the flat behavior unchanged.¶

The delegation member is policy, not authority, and is not part of this comparison (Section 12.3). A derived entry's delegation, when present, MUST NOT be broader than the parent entry's:¶

• its max_depth MUST be no greater than the parent entry's;¶

• its allowed_delegates MUST be no wider than the parent entry's; and¶

• a derived entry MUST NOT introduce delegation where the parent entry has none.¶

The comparison is representational, not semantic. A candidate that compares as no broader can still permit effects the parent's purpose never contemplated, because narrowing is judged over the entry's members, not over meaning; 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.¶

5.2. Common Constraints

A constraints member name (Section 5) is either a specification-defined Common Constraint or a deployment-defined key. Common Constraints give independently developed deployments one vocabulary they interpret, narrow, and compare identically; further Common Constraints are defined by specification under the naming convention of Section 20.8.¶

A Common Constraint definition fixes:¶

• Value syntax: the JSON [RFC8259] value type and any additional rules.¶

• Subset rule: how a candidate value is judged no broader than a reference value, used by the subset comparison of Section 5.1.¶

• Intersection rule: how two values for the same key combine; the result MUST be no broader than either operand.¶

A constraints member whose name is a specification-defined Common Constraint is interpreted per its definition. Any other member name remains deployment-defined and is interpreted only within the issuing deployment; a consumer that does not recognize it MUST fail closed (Section 9.2).¶

The same duty binds the AS side of narrowing: whenever the AS derives a candidate entry from a ceiling (a client's authority proposal narrowed to the Authority Set (Section 4.2), or an Authority Set entry narrowed to a derived or delegated token, Section 5, Section 12.3), a registered Common Constraint key present in the ceiling entry that the AS does not implement narrowing for MUST NOT be dropped while the entry survives. The AS MUST instead fail closed: refuse the whole derivation, or omit the entry from the result, exactly as an unrecognized resources value already may be; the granted authorization_details echo reflects any such omission (Section 5). Carrying the entry forward with the key dropped would widen effective authority past the ceiling exactly as an unenforced key would at the Resource Server (Section 9.2).¶

This document defines the initial Common Constraints:¶

• max_amount (object): a per-action ceiling on a monetary amount. The value is an object with two members: amount (REQUIRED, a string containing a decimal number) and currency (REQUIRED, an ISO 4217 [ISO4217] currency code). Subset: no broader when the currency values are equal and the candidate amount is less than or equal to the reference amount, compared in decimal value space; differing currencies fail the comparison (no conversion is defined). Intersection: when the currency values are equal, the value with the smaller amount; differing currencies have no intersection and the combination fails.¶

• resource_issued_after (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or after this instant. Subset: no broader when greater than or equal to the reference. Intersection: the later instant.¶

• resource_issued_before (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or before this instant. Subset: no broader when less than or equal to the reference. Intersection: the earlier instant. The resource_ qualifier in both names marks that the window bounds resource issuance, not token issuance.¶

• tenant (string): the action applies only to resources of the named tenant. Subset: no broader when equal to the reference value. Intersection: the common value when the two are equal; otherwise there is no intersection and the combination fails.¶

• recipient_domain (string, a DNS name): the action applies only to recipients within the named domain. Subset: no broader when equal to the reference or a DNS subdomain of it. Intersection: the narrower value when one is equal to or a subdomain of the other; otherwise there is no intersection and the combination fails.¶

• time_window (object): the action may be exercised only within the window, evaluated at the point of use (unlike resource_issued_after and resource_issued_before, which bound resource issuance, and unlike token exp, which bounds the credential). The value has two members, not_before and not_after (each an RFC 3339 [RFC3339] date-time); at least one MUST be present, and an absent member is unbounded on that side. Subset: no broader when the candidate window lies within the reference window, an absent candidate bound counting as unbounded and therefore broader than any present reference bound. Intersection: the overlap (the later not_before, the earlier not_after); an empty overlap has no intersection and the combination fails.¶

• data_classification (array of strings): the action applies only to data whose classification label is among the named values. Label semantics are deployment- or registry-defined; the comparison is not. Subset: no broader when the candidate array's members are a subset of the reference array's, compared as exact strings. Intersection: the common members; an empty result has no intersection and the combination fails.¶

• allowed_tools (array of strings): the action may be exercised only through a capability whose identifier is among the named values (a tool or function identity, asserted at the point of use by the enforcing component). Subset: no broader when the candidate array's members are a subset of the reference array's, compared as exact strings. Intersection: the common members; an empty result has no intersection and the combination fails.¶

• requires_action_approval (boolean): when true, each exercise of the action requires a fresh, action-bound approval at the point of use; the enforcing component MUST NOT permit the action on Mission authority alone. A value of false is equivalent to omitting the member. Subset: no broader when the candidate is true or equals the reference (narrowing may add the requirement, never remove it). Intersection: the logical OR of the two values.¶

These comparisons are in value space, not lexical: max_amount amount members are compared as the decimal numbers the strings contain, so "500", "500.0", and "500.00" are equal; resource_issued_after and resource_issued_before values are compared as the instants they denote after normalization to UTC, so two RFC 3339 representations of the same instant that differ only in timezone offset or trailing subsecond zeros are equal; recipient_domain values are compared as DNS names, case-insensitively and on whole labels, so mail.example.com is within example.com and example.net is not. A Common Constraint definition MUST fix its subset and intersection in value-space terms, so that independent deployments compute the same result for the same values and the subset rule of Section 5.1 is reproducible.¶

A decimal-string value in a Common Constraint (max_amount's amount member, and any future Common Constraint with a decimal-valued member) MUST match ^[0-9]+(\.[0-9]{1,18})?$: one or more decimal digits, optionally followed by a single . and one to 18 further decimal digits. A leading - is out of scope for a ceiling value and MUST be rejected. A value of any other form, including scientific notation ("1e300"), a sign, a thousands separator, or a non-numeric token ("NaN", "Infinity"), is malformed, and a consumer MUST reject it rather than attempt to parse it: an authority proposal carrying one is refused at submission (Section 4.2), and a Resource Server treats a malformed decimal value the same as a constraints key it cannot enforce (Section 9.2). Comparison and intersection over two such decimal-string values MUST be computed as exact decimal arithmetic (for example, by scaling both values to integers by their fractional digit count and comparing the integers) and MUST NOT parse either value into an IEEE 754 binary floating-point type: that representation does not hold every value the grammar above admits exactly and can compare or combine two values incorrectly.¶

A numeric constraint value MUST lie within the range JCS [RFC8785] serializes exactly. Monetary amounts avoid that hazard by construction: max_amount carries its amount as a string containing a decimal number, paired with an ISO 4217 [ISO4217] currency code, and a future Common Constraint for a monetary value SHOULD reuse this shape rather than a JSON number.¶

5.3. Other Authorization Details Types

mission_resource_access is the only type this document defines, but the Authority Set MAY include other AS-supported [RFC9396] authorization_details types when an audience consumes them. ("Supported" here means the AS recognizes and documents the type: it appears as a key in the AS's authorization_details_types_metadata_endpoint response, the source of truth for the supported set (Section 14); authorization_details_types_supported, where the AS also advertises it, mirrors that key set. RFC 9396 establishes no IANA registry of type identifiers.) The Mission apparatus is type-agnostic toward such entries:¶

• they are committed by authority_hash and gated on Mission state exactly as mission_resource_access entries are;¶

• narrowing and delegation use the subset semantics the type defines (Section 5.1, Section 12.3). A type whose subset and delegation semantics the AS does not understand MUST NOT be delegated, audience-projected to a Resource AS, or narrowed: the AS cannot prove a transformed copy is still a subset of what was approved. Such an entry MAY be issued only to its original approved audience, carried exactly as approved, and MUST NOT appear in a delegated token or in a cross-domain grant ([I-D.draft-mcguinness-oauth-mission-cross-domain]);¶

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

This lets policy-language profiles compose without this document defining them: for example, an entry carrying a Cedar policy set ([I-D.draft-cecchetti-oauth-rar-cedar]), or an analogous AuthZEN policy entry, for an audience that evaluates it. The AS derives such an entry from the Mission Intent and bounds it by the Intent like any other, but treats the carried policy largely opaquely; the Resource Server or Policy Decision Point (PDP) evaluates it at request time.¶

Stated as a limit: the subset rule is fully defined only over mission_resource_access and its Common Constraints. Authority expressed in another type has whatever subset relation that type defines, or none, and where it has none the entry is carried as approved: never narrowed, delegated, or projected. The narrowing guarantee is therefore strongest while authority stays in mission_resource_access entries, and weakens as expressiveness moves into opaque policy-language entries.¶

Example (non-normative): an Authority Set with a Cedar policy entry for a finance audience that consumes Cedar, alongside a mission_resource_access entry for a calendar audience that does not. The Cedar policySet is abbreviated:¶

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

Both entries are committed by the one authority_hash and bound to the Mission. The Cedar entry is evaluated by the finance audience's PDP; the mission_resource_access entry is enforced as in Section 9. Because the Cedar profile defines no subset or delegation rule over policy sets, the AS carries the Cedar entry as approved rather than narrowing it, and it MUST NOT appear in a delegated token or cross-domain grant. Delegation controls on other entries, such as the mission_resource_access entry, apply to those entries only.¶

5.4. Modeling Tools and Function Calls

This section is non-normative guidance. A "tool" an agent invokes, such as a Model Context Protocol (MCP) tool or a function call, is modeled as a mission_resource_access entry. No separate entry type is needed, and the rules above (derivation, subset, delegation, authority_hash) apply unchanged.¶

The mapping is:¶

• resource is the tool provider. For an MCP tool it is the MCP server's URL. The MCP authorization model ([MCP]) makes the server an OAuth 2.0 resource server, so this is the resource identifier a token is audience-bound to.¶

• actions are the tool names the task needs at that provider. Authorizing a tool is authorizing its name as an action, which lines up with MCP filtering its tool list by the caller's granted authority and routing each tool call for authorization.¶

• constraints carry machine-actionable bounds on a tool's arguments, for example an amount ceiling or a recipient domain (the max_amount and recipient_domain Common Constraints, Section 5.2). Like all constraints, they are committed by authority_hash and carried to the point of use, but they are evaluated against the concrete call arguments by a runtime enforcement layer, not at issuance (Section 17.3.1).¶

For example, a Mission authorized to read invoices and post small adjustments through a finance MCP server, and to send messages through a messaging MCP server, derives:¶

[
  { "type": "mission_resource_access",
    "resource": "https://finance.example.com/mcp",
    "actions": ["query_invoices", "post_adjustment"],
    "constraints": {
      "max_amount": { "amount": "500.00", "currency": "USD" }
    } },
  { "type": "mission_resource_access",
    "resource": "https://mail.example.com/mcp",
    "actions": ["send_message"],
    "constraints": { "recipient_domain": "example.com" } }
]

Delegation to a sub-agent works unchanged: add a delegation member to a tool entry (Section 12.3). For example, an entry a sub-agent of type ai_agent may invoke at depth 1, narrowed to the read tool only:¶

{ "type": "mission_resource_access",
  "resource": "https://finance.example.com/mcp",
  "actions": ["query_invoices"],
  "delegation": {
    "max_depth": 1,
    "allowed_delegates": [{ "sub_profile": "ai_agent" }]
  } }

What this profile does not provide for tools is a typed, attenuable per-argument constraint grammar: narrowing one tool's argument schema against another (for example, amount in a range, recipient in a one_of set) as the grant is derived or delegated. Argument bounds here are the same flat, carried constraints used for any resource, evaluated at runtime. Structured per-argument attenuation ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens], with object capability systems such as UCAN as prior art) is a richer primitive deferred to future work; it would extend the delegation and subset model of this document (Section 12.3, Section 5.1) rather than introduce a new entry type.¶

6.1. Binding the Mission to the Grant

At the approval event the AS binds the Mission to the authorization grant it issues: the authorization code, and the refresh token issued from it. The binding is server-side and is what "the referenced Mission" in Section 10 refers to. At each subsequent derivation the AS resolves the Mission from the grant the client presents: the authorization code at the token endpoint (the initial exchange uses grant_type=authorization_code), the refresh token on refresh, or the Mission-bound subject_token on Token Exchange (the actor_token identifies the delegate, Section 12). It then applies the gating of Section 10. A client does not supply mission_id to obtain a derivation; an AS MUST NOT derive Mission-bound authority from a client-supplied mission_id, because the grant, not the identifier, determines the Mission. When the authorization code expires unredeemed, no derivation is possible under the Mission; the AS SHOULD revoke the Mission or allow it to expire.¶

A client learns its mission_id from the mission claim's id on each issued token (Section 9.1) or from the token response. This document defines mission_id as a token-endpoint response parameter: a string carrying the Mission Identifier, returned alongside the issued token. An AS SHOULD return it: the client is not expected to parse the access token, and when the parameter is absent the only path to the identifier is reading the mission claim, which fails for a token that is encrypted or opaque to the client. It is an informational reference only: presenting it authorizes nothing (Section 10), and a client MUST NOT derive authority from it.¶

Alongside it, this document defines mission_expires_at: the exact RFC 3339 string recorded as the Mission Record's effective expires_at (Section 8), the common member of every Mission-creating success response, whatever surface completes the creation. The success response that first delivers a newly created Mission's identifier or credential MUST carry it, and a Mission-bound token response SHOULD carry it beside mission_id: expires_in describes the access token's lifetime, not the Mission's, and the effective expiry may be shorter than the requested intent.expires_at. A creation replay deduplicated under the applicable operation identifier (approval_event_id for direct approval (Section 8), or the identifier a Mission-creating profile defines) returns the committed effective value unchanged. On OAuth token responses the member is additionally registered as a token-endpoint response parameter (Section 20). It is informational in the same way: presenting it authorizes nothing.¶

6.2. Single Accountable Approver

This document records exactly one approver: the accountable principal who approved the Mission. Two richer patterns are deliberately out of scope and deferred:¶

• Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers is orthogonal to the consent commitment: however many principals approve the same rendered Authority Set, the authority_hash is identical, as is every token derived from it. Multi-party approval raises the assurance of how approval was obtained; it does not change the artifacts this document produces. A deployment requiring dual control records one accountable Approver under the same authority_hash; this document does not natively represent the co-approvers.¶

• Approval-authority provenance (the deeper standing behind a delegate's authority to approve for another principal, for example, whether an administrator was themselves entitled to approve on a user's behalf). This is governance state about the delegate's own standing, not the named standing-consent basis approval_basis records for a template or drawdown-policy activation (Section 8), and is left to a governance layer.¶

Both remain out of the core. Where a deployment needs them, they are recorded by the Approval Governance Record ([I-D.draft-mcguinness-mission-approval-governance]). Consent Evidence may carry a deliberately partial presentation of that record through co_approvals and its approval-governance members ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

7.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>",
     "iss": "<the AS issuer URL>",
     "value": <the committed object>
   }
   

   ¶

   For intent_hash, typ is mission-intent and value is the approved Mission Intent object: the Submission envelope's intent member, never the envelope or its evidence (Section 4.1). For proposal_hash, typ is mission-proposed-authority and value is the submitted authorization_details array exactly as recorded (Section 4.2); the anchor exists iff a proposal was submitted. For authority_hash, typ is mission-authority-set and value is the Authority Set as a JSON array of entries.¶

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 can never be mistaken for another's. The iss binding prevents a committed object from being transplanted across Authorization Servers.¶

The typ value space is an extension point (Section 13): 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 [RFC7519] Section 4.2). The mission- prefixed values defined by profiles that extend this document share a namespace coordinated through this document series' change controller, or a registry a future revision establishes, for this reason.¶

One further committed object is defined here because several companions reference it: the Authority Set entry commitment, the envelope above with typ mission-authority-entry, iss the Mission issuer, and value a single Authority Set entry object exactly as recorded. A companion that cites an entry by digest (a decision record naming the entry it evaluated, containment or completion state keyed to an entry) computes it this way and this way only. 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, never 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. This document adds no Mission-record member for it (Appendix B).¶

SHA-256 is the only digest algorithm this document defines and is mandatory to implement; the sha-256: prefix identifies it. The prefix is the algorithm-agility mechanism, and the reject-unknown, no-downgrade rule binding every prefixed digest is stated once in Section 7.3.¶

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

• The party computing or verifying a commitment MUST parse externally received input with a parser that detects duplicate JSON member names, and MUST reject an object carrying them. An ordinary parser silently collapses duplicates, so the check happens at parse time, before the parsed data model exists.¶

• JCS does not reorder array elements, and this document defines no element sorting, so array order is significant. The AS MUST emit each array in a fixed, reproducible order; that order is part of the canonical form.¶

• URI-valued members are compared byte-for-byte unless a member's definition specifies a normalization. The only normalization this document defines is the RFC 3986 [RFC3986] comparison of the resource-containment test (Section 5.1), which applies to that comparison alone: the default resource equality test of Section 5.1 remains an exact match, and anchor computation is always byte-exact over the recorded values.¶

Test vectors for the anchors are provided in Appendix B.¶

7.3. Commitment Mechanisms

The family's default prefixed construction commits to bytes in three ways, and a specification defining a prefixed commitment classifies it as one of these species:¶

• Envelope anchor: the domain-separated, issuer-bound envelope of Section 7.1 (intent_hash, proposal_hash, authority_hash, and commitments produced with companion-defined typ values).¶

• Canonical-object digest: sha-256: over the JCS serialization of a normalized JSON object without the envelope, where protocol context already fixes what is committed (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 7.1 binds envelope anchors alone. This section instantiates the substrate's default commitment construction ([I-D.draft-mcguinness-mission-substrate]); the two state the same rules, and this document remains self-contained. 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 the envelope around it, MUST satisfy I-JSON [RFC7493], and the party computing or verifying a commitment MUST reject non-conformant input before canonicalization:¶

• 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 (Section 7.2);¶

• string data is valid Unicode, free of the surrogate and noncharacter code points I-JSON prohibits, and is preserved unchanged; and¶

• number data supplied to JCS is representable as a finite IEEE 754 binary64 value ([RFC8785], Section 3.1).¶

The commitment is over the parsed I-JSON data value, not the source text: JCS serializes the parsed binary64 value deterministically and 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 or defines a stricter numeric domain, as Common Constraints already does for constraint values (Section 5.2). 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 family 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 and MUST NOT treat an unrecognized prefix as sha-256, so an algorithm added later cannot be exploited as a downgrade. These rules bind a prefixed digest when its defining specification classifies it under this taxonomy and imports this section normatively, whichever species it is: this document so classifies its three anchors, and each family companion classifies the digests it defines.¶

This document defines no transition mechanism: every commitment a current carrier defines is a single prefixed string, and no carrier defines a location for a second one. A specification that introduces a new prefix MUST define the carrier and schema of any parallel commitment, the binding that proves the old and new values commit to the same object, producer behavior during the transition, verifier selection and downgrade behavior when recognition sets differ, and the transition procedure itself.¶

8.1. 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. It MUST NOT be reused. 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 6.1).¶

8.2. Worked Example

{
  "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "issuer": "https://as.example.com",
  "state": "active",
  "intent": { "goal": "Reconcile Q3 invoices ...",
    "resources": ["https://erp.example.com"],
    "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:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
  "intent_hash":
    "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY",
  "proposal_hash":
    "sha-256:kT2mR7vX4qL9nY5pB1sD8fJ6wZ3hC0aGeUoNvSqMrYo",
  "subject": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "approver": { "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" },
    "root_commitment":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "authority_source": { "type": "user_delegated" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z",
  "created_at": "2026-10-15T14:32:11Z",
  "expires_at": "2026-12-31T23:59:59Z"
}

This recorded intent, proposed_authority, and authority_set, and the anchors above, are this document's canonical worked example; the test vectors (Appendix B) compute over them. A companion that extends this example MUST either reproduce the recorded objects byte-exactly or state explicitly that its example diverges and its anchors differ; an extended example with silently different anchors reads as the same Mission and has repeatedly caused drift.¶

9.1. The Mission Claim

The mission claim is a JSON object:¶

id:

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

issuer:

REQUIRED. A string. The Mission's issuer (Section 8). A credential's iss names the party that minted it; mission.issuer names the party that approved and serves the Mission, and the two deliberately differ for tokens minted in another trust domain ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

authority_hash:

REQUIRED. A string. The Mission's authority_hash, the commitment over the complete consented Authority Set (Section 9.2).¶

expires_at:

OPTIONAL. A string. The Mission's expires_at (Section 8), in RFC 3339 [RFC3339] date-time form and named identically to the record member it mirrors. It is a bounding and audit commitment with no liveness: a validator can check that the token's exp does not exceed it, and its passing says nothing a state surface does not, since expiry is not revocation and only active permits reliance (Section 10).¶

approval_basis:

OPTIONAL. An object carrying type only: the Mission's approval_basis.type (Section 8), as a wire signal of which authorization basis the Mission is rooted in. The record's other approval_basis members are not carried on the token. It MUST NOT be relied on to grant or widen authority; the carried authorization_details and authority_hash remain authoritative.¶

The mission claim is an open object (Section 13): 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 [RFC7519] Section 4.2) 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. A future revision MAY establish a claim-member registry (the JWT Confirmation Methods registry of [RFC7800] is the structural precedent); until then the members are specification-defined.¶

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

Example decoded token payload:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840000,
  "exp": 1797840300,
  "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",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

9.2. Resource Server Enforcement

A Resource Server enforces from the token alone; no call to the AS is required. A Resource Server:¶

• MUST validate the JWT per [RFC9068] and verify any sender-constraint binding (cnf).¶

• MUST treat authorization_details as the authoritative expression of authority and enforce the entries whose resource it serves, permitting only the listed actions subject to constraints. Where more than one carried entry names a resource it serves, a request is permitted if at least one carried entry permits it: entries are alternative grants of authority, not conjunctive filters.¶

• MUST, when it matches a concrete request URI against a prefix entry (Section 5), apply the same RFC 3986 [RFC3986] syntax-based normalization the AS uses for containment (Section 5.1), and MUST apply it before the prefix comparison rather than after. That normalization decodes only unreserved octets, so reserved octets stay encoded: an encoded slash (%2F, equivalently %2f since percent-encoding is hex-case-insensitive) remains encoded and MUST NOT be treated as a path-segment separator when matching. An intermediary that percent-decodes %2F, or a downstream component that decodes and removes dot-segments after the Resource Server's check (for example collapsing a decoded %2e%2e), moves the enforced boundary, so a deployment MUST prevent such rewriting or account for it in what it authorizes.¶

• MUST fail closed on any constraints key it does not understand, or understands but cannot enforce, in an entry whose resource it serves: it MUST refuse the request (for example, a 403 with insufficient_scope [RFC6750], or the deployment's usual insufficient-authority error) rather than grant access while ignoring the key.¶

• MUST NOT reduce a constraint to disclosure-only.¶

• 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; in particular, scope MUST NOT be used to bypass a constraint carried only in authorization_details.¶

• MUST treat client_id per its ordinary meaning under [RFC8693] Section 4.3 and [RFC9068] Section 2.2: the OAuth client that requested this token. This profile does not redefine it, on a delegated token or otherwise (Section 12.1). The Mission's originally-approved agent is not carried on the token; it is recorded in the Mission Record (Section 8) at the issuer, and a Resource Server MUST NOT infer that identity from client_id.¶

• MAY impose stronger actor-chain requirements when it authorizes or logs the caller on a token that carries an act chain (for example, requiring and recording the chain), but MUST NOT reinterpret client_id to do so.¶

• MAY, for a Mission-governed resource, be configured to require the mission claim, and MUST then reject a token that lacks it with invalid_token. The downgrade this rejection prevents, and the issuance-side duty that pairs with it, are stated once in Section 17.1.2. A protected resource MAY advertise this requirement through the mission_bound_authorization_required protected resource metadata member (Section 15).¶

• MAY treat the mission claim as audit and correlation context.¶

• SHOULD, when serving Mission-bound requests, log the mission claim's id and the token jti with each served request, so its access logs join to Mission evidence.¶

• MAY recompute authority_hash (Section 7.1): a Resource Server that performs it recomputes the anchor over the full Authority Set it independently holds, compares the result to mission.authority_hash, and MUST reject on mismatch. It additionally verifies that each carried authorization_details entry is a subset (Section 5.1) of that held set.¶

• MUST NOT recompute authority_hash from a token's carried subset: the anchor is computed only over the full Authority Set, and a narrowed token matches by the subset test, never by hashing its carried entries.¶

• MAY, where the AS offers it, introspect the token (Section 11) to observe the Mission's current state per request rather than relying on the token lifetime to bound revocation latency.¶

• MUST, when it introspects, still verify the token's sender-constraint (cnf) locally and MUST NOT treat an active: true result as proof the caller holds the bound key; the AS does not check possession at introspection (Section 11).¶

A deployment MUST NOT route a delegated Mission-bound token to a Mission-unaware Resource Server that authorizes or logs the caller on client_id without processing the act chain. The requirement above binds a Mission-aware RS; a Mission-unaware [RFC9068] RS reads client_id as the immediate client, which is accurate for that single token, but it still cannot see the delegation lineage carried in the act chain, and it has no way to look up the originally-approved agent from the Mission Record, so it cannot apply actor-chain policy or join a delegate's action back to the Mission's approval in its own audit records. A resource that requires Mission-bound tokens at all advertises that through the mission_bound_authorization_required protected resource metadata member (Section 15), and a Resource Server that serves such a resource is, by that requirement, Mission-aware; a deployment that delegates routes delegated Mission-bound traffic only to a Resource Server it knows to be Mission-aware in this sense.¶

A constraints member narrows authority, so treating an unenforceable key as absent, or reducing it to disclosure-only, would silently widen the grant; that is why an unrecognized or unenforceable key fails closed. A Resource Server that holds only a narrowed token MUST treat mission.authority_hash as an audit correlator, not an enforcement input, and MUST NOT treat it as 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, and depends on the AS applying the subset rule correctly.¶

A worked contrast, using the two-entry Authority Set of the test vectors (Appendix B), shows what each party can verify. A single-audience token carries one narrowed entry: journal-entries.write with the approved max_amount of 500.00 USD tightened to 250.00. The Resource Server verifies the token signature and cnf, checks aud, enforces the carried entry, checks the anchor's algorithm prefix (Section 7.1), and logs the mission claim for correlation. It cannot recompute authority_hash: hashing the carried entry digests a one-entry array the anchor never committed, and the tightened max_amount makes the entry a semantic narrowing, not a byte-level member, of the approved set. Whether 250.00 sits within the approved ceiling is the subset test (Section 5.1), and that test needs the approved entry to compare against. A party holding the full Authority Set (a Resource Server provisioned with it, or a policy decision point holding the Mission record) recomputes the commitment over the held two-entry set, matches mission.authority_hash, and verifies the carried entry as a subset of the held journal-entries.write entry: containment verified relative to the authenticated committed set. For that verification to be independent of the issuer, the deployment provisions the set together with its provenance: the full Authority Set, the Mission id and issuer it belongs to, the expected authority_hash, and an authenticated approval-time source for all three (trusted Mission or consent evidence, or an audit commitment recorded before any compromise). Without that pinning, a compromised issuer signs a token carrying a replacement set's hash, and recomputation confirms the replacement.¶

Three denials above are byte-identical 403s to a client, and misrouting them turns a step-up into an authority-widening ceremony or a fail-closed mismatch into a retry loop. A Mission-aware Resource Server SHOULD therefore state which path it denies into, using the mission_denial attribute this document defines for the WWW-Authenticate response header, carried alongside error per [RFC6750], with one of three 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.¶

step_up_required:

The authority exists, but the presented token or its binding does not meet the resource's requirements: a step-up, not a widening.¶

constraint_unrecognized:

An applicable entry carries a constraints key the RS cannot enforce, and the request fails closed.¶

A value the client does not recognize is treated as insufficient_authority. The attribute's disclosure considerations are Section 17.3.3's.¶

A Mission-unaware Resource Server that authorizes only from scope still operates within the Mission at the coarse scope level, because the AS derived and bounded that scope by the Authority Set (Section 9); but it does not enforce the per-entry constraints, which scope cannot carry. A deployment that relies on those constraints MUST route the protected operation through a Resource Server that enforces authorization_details (or the runtime layer that evaluates them).¶

9.3. Remediation Grains

A denial is not the end of the exchange. The family treats "how to ask again" as a graduated challenge assembled from independent grains, each naming a next step without granting anything itself. This document's own grain is mission_denial above: which path a denial leads into.¶

A Resource Server MAY compose a second grain with it: the insufficient_authorization WWW-Authenticate error code and its authorization_remediation parameter, defined by [I-D.draft-zehavi-oauth-rar-metadata]. authorization_remediation is a base64url-encoded JSON object naming the actionable authorization_details the caller lacks, with an OPTIONAL authorization_reference letting the client match a previously issued token to that same gap. It names what mission_denial: insufficient_authority only points at. This document does not fold that grain into mission_denial's carriage, nor redefine either grain's response status: each rides the wire shape its own defining document gives it. A client that decodes authorization_remediation proposes the carried entries back on the standard authorization_details parameter (Section 4.2), where they derive under this document's ordinary rules (Section 5): of an advertised, schema-valid type (Section 14), narrowed same-type (Section 5.1, Section 5.3) like any other proposal. The loop closes natively: the remediation grain's output vocabulary is this document's input carriage, with no re-wrapping between them.¶

A third grain routes the same denial into a governed access request rather than a fresh derivation: the AuthZEN Access Request and Approval Profile's requestable denial over [AuthZEN.ARAP], adopted by the AuthZEN binding companion ([I-D.draft-mcguinness-mission-authzen]). The three grains compose rather than replace one another: a deployment MAY offer any subset, and none widens authority beyond what Section 5 would derive from the same proposal unremediated.¶

10.1. Issuance Gating

The AS MUST refuse to derive a token, at the token endpoint, on refresh, and on Token Exchange ([RFC8693]), unless the referenced Mission is active. Issuance against a revoked or expired Mission MUST fail with invalid_grant. Because derivation is gated on Mission state, revoking or expiring a Mission stops all further authority for the task, including refresh. The active check MUST be evaluated atomically with issuance, as the derivation-count check already is, so a revocation serialized before an issuance is honored by that issuance.¶

When the Mission Intent sets controls.max_derivations, the AS MUST maintain a per-Mission count of derivations and MUST refuse with invalid_grant any derivation that would exceed the bound. 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]). Each counts as exactly one, regardless of how many artifacts it emits: a code exchange that returns both an access token and a refresh token is one derivation, and a refresh that rotates both is one. The exact rules:¶

• A derivation that fails, including one refused for exceeding the bound, MUST NOT be counted.¶

• The check and increment MUST be atomic with issuance, so concurrent derivations cannot collectively exceed the bound.¶

• The count covers only derivations the issuer AS performs. Tokens another domain mints locally under the Mission are not counted by the issuer, which cannot observe them; the cross-domain issuance that authorized them was counted once, and the local issuer bounds its own minting by its policy ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

The AS maintains this count as internal bookkeeping; it is operational state, not part of the immutable Mission record.¶

invalid_grant 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 20) with one of the values mission_revoked, mission_expired, mission_superseded (where a companion defines supersession), or derivations_exhausted. The 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 revoked or expired takes effect promptly without per-request revocation checks.¶

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

This document does not define the wire shape of that operation. Revocation is a management-plane action by a party in the AS's own trust domain, not a cross-party protocol exchange, and the lifecycle gate that makes it effective (Section 10, Section 11) already rides on existing endpoints, so no standardized endpoint is required for interoperability. A standardized Mission management API, with suspend/resume/complete operations, is specified separately by Mission Status [I-D.draft-mcguinness-oauth-mission-status]; this document does not require it.¶

A deployment MAY additionally treat [RFC7009] revocation of a Mission's refresh token as revoking the Mission. A deployment MUST NOT couple routine token revocation to Mission revocation unless it documents that behavior. Already-issued access tokens remain valid until they expire; a deployment requiring lower cutoff latency SHOULD use short token lifetimes.¶

The stateless baseline satisfies the lifecycle-gated capability: a token is a self-contained authorization, verification is stateless, and it needs no status surface. A deployment MAY additionally offer token introspection (Section 11), an OPTIONAL state-observable overlay, so a Resource Server can observe Mission state per request and cut off a revoked Mission without waiting out the token lifetime. A canonical Mission Status surface (keyed by mission_id) and signed status responses are specified separately as another OPTIONAL state-observable overlay by Mission Status [I-D.draft-mcguinness-oauth-mission-status]; this document does not require them.¶

Token validity and Mission validity are distinct: a token can outlive a transition of its Mission, by at most the token lifetime. A deployment whose consumers rely on Mission state beyond a token's lifetime SHOULD offer introspection (Section 11) or the Mission Status companion, so an authorized party can determine the Mission's current state rather than inferring it from token validity.¶

11.1. Caller Authorization and Minimization

The introspection endpoint is protected per [RFC7662]. 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 9).¶

Because this profile returns the mission member and mission.state even when active is false (the deviation stated in Section 11), the AS MUST apply this same authorization and minimization to that data and MUST NOT reveal Mission detail to an unauthorized introspection caller.¶

11.2. Composite Active State

The introspection active member reflects the composite authorization, not the token in isolation. The AS MUST return active: true only when the access token is itself valid (valid signature, unexpired, and not individually revoked) AND the Mission is active. The AS does not verify the token's sender-constraint (cnf) at introspection: proof of possession is checked by the Resource Server when the token is presented, not by the AS over an introspection call, so active: true is not by itself evidence the caller holds the bound key.¶

When the token is otherwise valid but the Mission is revoked or expired, the AS MUST return active: false and include mission.state giving the reason, 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.¶

11.3. Only the Issuer Reports Mission State

An AS MUST NOT include mission.state 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 the claim-shape members only and never state, is specified by the companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

This is token introspection: it answers "is this token's authorization still good," keyed by the token presented. The canonical Mission Status surface (keyed by mission_id) remains out of scope (Section 10.2).¶

11.4. Examples

While the Mission is active, the response is the standard [RFC7662] body plus the mission member. The canonical ERP token (Section 9.1), introspected at the issuer AS:¶

{
  "active": true,
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "aud": "https://erp.example.com",
  "exp": 1797840300,
  "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:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "proposal_hash":
      "sha-256:kT2mR7vX4qL9nY5pB1sD8fJ6wZ3hC0aGeUoNvSqMrYo",
    "state": "active"
  }
}

The same token after the Mission is revoked, reported per the composite-active rule (Section 11.2):¶

{
  "active": false,
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
    "state": "revoked"
  }
}

12.1. Adopted Model: client_id Names the Requesting Client

This profile keeps client_id's registered meaning, stated normatively in Section 9 and enforced in Section 9.2: the OAuth client that requested the token, on every issued or derived token, a delegated one included. Downstream delegates ride the act chain (Section 12), and the Mission's originally-approved agent remains recorded in the Mission Record (Section 8), without redefining a registered claim. The alternative, freezing client_id to the approved agent on every derived token, would have a generic [RFC9068] Resource Server or logging pipeline attribute a delegate's action to the approved agent with no error to surface the mismatch, and it buys no relaxation: it is safe only where every Resource Server already processes the act chain, the discipline a Mission-aware Resource Server owes anyway (Section 9.2). The routing rule of Section 9.2 is independent of this choice: the mission claim's presence, not the binding choice, is what signals a token may carry an act chain a consumer needs to process, a Mission-unaware Resource Server cannot opt into that need, and routing a delegated token to one therefore remains forbidden.¶

12.2. 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). The AS MUST verify that the client authenticated at a no-actor exchange is the Mission's approved agent, per the Mission Record's client_id (Section 8); any other party's no-actor exchange is refused, since a delegate narrows only through a delegated exchange that names it in the act chain. The result MUST be a subset (Section 5.1) of the presented token's authority, carries the same mission claim (Section 9.1), and adds no act chain. It is a derivation and is gated on the Mission being active (Section 10). Because it names no actor, it does not delegate: it re-scopes the agent's own authority downward.¶

12.3. Delegation Constraints

What may be delegated, how far, and to whom is governed per Authority Set entry by the entry's optional delegation member (Section 5). Because the policy lives in the entry, it is committed by authority_hash with the rest of the Authority Set and travels with the entries wherever they are carried, including across a cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]), needing no separate mechanism.¶

Delegation depth. The delegation depth of a token is the number of actors in its act chain (the nesting depth of the act claim), counted from the approved agent: 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]).¶

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 all of the following hold:¶

1. the entry carries a delegation member (otherwise it is non-delegable, which is the default);¶

2. d is less than or equal to the entry's delegation.max_depth; and¶

3. the delegate is permitted by delegation.allowed_delegates or, when that member is absent, by the AS's delegation-authorization policy, which the AS MUST apply at every exchange: an absent matcher list is a decision deferred to policy, never a blanket grant of eligibility.¶

An entry failing any of these narrows out of the delegated token, consistent with the subset rule (Section 5.1). The delegation member is policy, not authority, and is not part of the subset comparison; surviving entries are carried with their delegation member intact so the next hop is evaluated the same way.¶

Matching allowed_delegates. Each entry is a matcher object modeled on the RFC 8693 may_act actor object ([RFC8693] Section 4.4): where may_act names a single party eligible to act on a token, allowed_delegates is a per-Authority-Set-entry list of such matchers, generalized to actor-type classes. A { "sub": ... } matcher permits a specific delegate by client identifier; a { "sub_profile": ... } matcher permits any actor of that type (for example, ai_agent). An actor's sub_profile MAY carry multiple space-separated values; a { "sub_profile": ... } matcher is satisfied when its value is among the actor's values. A deployment can thus permit a specific client, a class of actors, or both, and a delegate is permitted if it matches any entry. The AS MUST authenticate the delegate at the Token Exchange and assert the actor's sub and sub_profile itself. A self-asserted sub_profile MUST NOT satisfy a matcher; otherwise a client could claim any actor type to bypass the constraint.¶

A { "sub": ... } matcher is a client identifier in the issuing AS's namespace and is not portable across a trust domain; how a Resource AS evaluates conveyed matchers, failing closed and narrowing out any sub matcher it cannot resolve, is specified by the companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

Empty result. If narrowing leaves no entries for the delegate, the AS MUST refuse with invalid_target ([RFC8693] Section 2.2.2) 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. Delegation constraints are applied by the AS at issuance; a Resource Server sees only the already-narrowed authorization_details and enforces those as usual (Section 9).¶

12.4. Worked Example: Delegated Token

Suppose 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 delegates to sub-agent tool-runner-7, an ai_agent, at depth 1. The read entry is permitted (depth 1 <= 2, ai_agent allowed) and the write entry narrows out. The decoded delegated access token:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "tool-runner-7",
  "iat": 1797840600,
  "exp": 1797840900,
  "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": "qVx7y2N0p4Lq9Md3sZJ8b8mZ3rN2xT5pV4lE6sQqYY" },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

sub is still the user. client_id is now tool-runner-7, the delegate that authenticated the Token Exchange and requested this token (Section 12.1); client_id and the outermost act coincide here because tool-runner-7 authenticated the exchange itself, not because this profile requires the two to match. A deployment where a different, already-authenticated client requests the exchange on a delegate's behalf, asserting the delegate only through an actor_token, would instead show that client's own identifier in client_id. client_id does not name s6BhdRkqt3, the originally-approved agent; that identity remains recoverable from the Mission Record via mission_id (Section 8). 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 rest of the mission claim is unchanged.¶

13.1. Namespace Taxonomy

The family's extensible namespaces follow one of three postures:¶

• Registry-backed. A namespace whose values are load-bearing for fail-closed behavior and span multiple documents is backed by an IANA registry: the document that owns the namespace carries the IANA creation instruction and seeds the registry with the values it itself defines, and 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. Mission Common Constraints (Section 20.8) and Mission Lifecycle States (Section 20.9) are this document's two; the Mission Authority Server Metadata registry and the Mission Denial Reasons registry are established where those namespaces are defined.¶

• Specification-defined. A namespace with a defined fail-safe for unknown values and no demonstrated third-party extension demand stays specification-defined, coordinated through this document series' change controller. A future revision MAY establish a registry for such a set; until one exists, the defining documents are the value space.¶

• Collision-resistant. Deployment-defined names follow the collision-resistant naming rules of this section and are never registered.¶

A newly defined, family-specific typed artifact that crosses a protocol boundary is named by an application/mission-* media type, and its defining document carries the RFC 6838 registration template at definition time. An artifact typed by a standard this family composes (an access token profile, a Security Event Token) keeps that standard's type. A defining document MAY instead record a local-use identifier as a transitional reservation where cross-domain interoperability is not yet claimed, registering the type when the claim is made; the audit profile's deferred evidence types are this class. The JOSE protected typ of a family-typed artifact is the registered media type, with the application/ prefix omitted where JWS permits the shortened form; an HTTP Content-Type carries the full media type. A typ inside a JCS commitment envelope names a hash domain, not a representation crossing a boundary, and is deliberately not a media type (Section 7.1).¶

17.1. Commitment and Consent Integrity

17.2. Agent-Specific Threats

17.3. Enforcement Boundaries

17.4. Credentials and Delegation

17.5. Composition and Residual Authority

19.1. Mission Identifier Correlation

This document carries a single canonical Mission Identifier on every derived token; the companion's cross-domain projection carries it across trust domains unchanged ([I-D.draft-mcguinness-oauth-mission-cross-domain]). 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. This is intentional: a stable, correlatable Mission anchor is what lets a Resource Server, a cross-domain Resource AS, and an auditor bind credentials and evidence to one approved Mission, which the governance and audit properties of this document and its companion profiles depend on. The cost is that this profile does not provide cross-audience unlinkability, and that is a deliberate non-goal (Section 1.6), not an unfinished feature. 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; because they work against the stable anchor, they are future work. A deployment that carries the canonical Mission Identifier on the wire accepts this correlation as part of its privacy posture; the operative control is limiting who receives the stable identifier, per the guidance above, and a deployment that publishes its posture records the property there rather than treating documentation as a separate duty.¶

19.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. Per-RS single-audience tokens are the minimization measure: they carry only the entries the consuming Resource Server needs, and this document recommends them (Section 9). The privacy considerations of [RFC9396] apply to the carried authorization_details.¶

19.3. Intent Retention and Anchor Disclosure

The Mission record's Intent members (goal, constraints) are personal-data sinks: they carry whatever task description the user supplied. Record retention and erasure follow the deployment's retention policy, with the audit profile's erasure record as the transparency-side mechanism ([I-D.draft-mcguinness-mission-audit]). The integrity anchors are unsalted commitments: a party holding a candidate Intent can confirm it against intent_hash, so over low-entropy or guessable content the anchor is a disclosure channel, and deployments treat it as one when the Intent itself is sensitive; the same confirmation channel exists for a candidate proposal against proposal_hash.¶

19.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, and whether a basis is required and what satisfies it is deployment and legal policy outside this protocol. Where the resource domain requires data-subject consent or another basis, that disclosure policy MUST be satisfied in that domain's own lane, wherever the deployment evaluates it (the Resource Server, a gateway, a policy decision point, or an authorization server acting for the domain) and through that lane's mechanisms (claims gathering, a resource-domain consent artifact), and access MUST be refused while required evidence is absent or invalid. A conforming deployment treats that refusal as the resource's answer, never as a Mission gap to route around. Mission approval and Mission authority MUST NOT be treated as the data subject's consent; a Mission record MAY retain a verified consent reference or facts as submission_evidence (Section 8), and those facts are provenance and policy input only: the resource domain validates them independently under its current disclosure policy, and that policy remains authoritative.¶

Third-party personal data can enter through any Intent, proposal, authority, or recorded-evidence member: the prose members (goal, constraints, success_criteria), purpose, resources, deployment-defined controls, any type-owned member of a proposed entry, the derived Authority Set entries that reach tokens (Section 9), and submission_evidence facts, including a consent reference. Whatever the member, it persists on the Mission record for its audit horizon (Section 8) and concentrates at the AS with the record (Section 19.5), and the committed members are confirmable through the unsalted anchors by any party holding a candidate value (the retention consideration above). Clients SHOULD reference a third party through resource-scoped or pseudonymous identifiers rather than identifying prose; an opaque identifier is minimization, not anonymity, and personal-data obligations follow it. Retention and erasure follow the deployment's policy. Where approval-event evidence was registered under the audit transparency profile, its erasure record and data-subject-request basis are the transparency-side mechanism ([I-D.draft-mcguinness-mission-audit]): it records an erasure, it neither performs one nor overrides retention law, and the operational Mission record and its audit-horizon retention floor (Section 8) are untouched by it.¶

19.5. Mission Record and Evidence Access

The Mission record concentrates the task, its authority, and its principals at the AS, and 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, never the record: nothing in this profile puts goal, constraints, or other Intent content in a credential. 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, and retention is deployment policy bounded below by the audit horizon (Section 8).¶

20.1. OAuth Parameters Registration

This document registers the following in the "OAuth Parameters" registry:¶

• Name: mission_intent¶

• Parameter Usage Location: authorization request¶

• Change Controller: IESG¶

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

• Name: mission_id¶

• Parameter Usage Location: token response¶

• Change Controller: IESG¶

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

• Name: mission_error¶

• Parameter Usage Location: token response¶

• Change Controller: IESG¶

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

• Name: mission_expires_at¶

• Parameter Usage Location: token response¶

• Change Controller: IESG¶

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

PAR [RFC9126] carries authorization-request parameters without a distinct usage location, so the pushed submission of mission_intent needs no separate registration. The mission_error member rides the token-endpoint error response; "token response" is the registry's applicable usage location, and the member relies on the error response's JSON extensibility rather than defining a new error code, so generic [RFC6749] error handling is undisturbed. The mission_denial attribute rides the WWW-Authenticate scheme's extensible auth-param space ([RFC6750], Section 9.2), for which no IANA registry exists; no action is required for it.¶

20.2. OAuth Extensions Error Registration

This document registers the following in the "OAuth Extensions Error" registry [RFC6749]:¶

• Name: invalid_mission_intent_evidence¶

• Usage Location: authorization endpoint, token endpoint¶

• Protocol Extension: Intent Submission Evidence (Section 4.3)¶

• Change Controller: IESG¶

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

The error is returned where the containing exchange returns its errors: on a PAR submission, in the PAR error response; on a token-endpoint carriage defined by a companion profile, in the token error response.¶

20.3. The Mission Resource Access Authorization Details Type

mission_resource_access is an authorization_details type per [RFC9396] Section 2, defined by this document in Section 5. RFC 9396 does not establish an IANA registry of authorization details types (type identifiers are interpreted by the Authorization Server), so this document creates no registry entry for it and requires no IANA action here. If a registry of authorization details types is established in the future, this type SHOULD be registered in it.¶

20.4. JSON Web Token Claims Registration

This document registers the following in the "JSON Web Token Claims" registry:¶

• Claim Name: mission¶

• Claim Description: Reference to the Mission a token was derived under, with the consent-commitment authority_hash. An open object; additional members may be present and are ignored if unknown.¶

• Change Controller: IESG¶

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

20.5. OAuth Token Introspection Response Registration

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

• Name: mission¶

• Description: The Mission a token was derived under. Same object shape as the mission JWT claim (Section 9.1); a response from the Mission's issuer additionally carries a state member giving the current lifecycle state, where a derivation cap is in force a derivations_remaining member, and where the Mission records an authority proposal a proposal_hash member (Section 11).¶

• Change Controller: IESG¶

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

20.6. OAuth Authorization Server Metadata Registration

This document registers 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: IESG¶

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

20.7. OAuth Protected Resource Metadata Registration

This document registers 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: IESG¶

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

• Metadata Name: mission_constraints_supported¶

• Metadata Description: JSON array of the constraints keys the protected resource understands and enforces.¶

• Change Controller: IESG¶

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

20.8. Common Constraints Registry

This document establishes the "Mission Common Constraints" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for the discipline Section 5.2 requires: a name matching ^[A-Za-z0-9_.:-]+$ not already registered, a JSON [RFC8259] value syntax precise enough for independent implementations to agree on, and a subset rule and an intersection rule both stated in value-space terms, with the intersection of any two valid values never broader than either operand. Registration does not require IETF review or a Standards Track document; a Specification Required reference that a Designated Expert can review against these criteria suffices.¶

Each registration records:¶

• Key Name: the constraints member name.¶

• Value Space: the JSON value type and any additional syntax rules.¶

• Subset Rule: how a candidate value is judged no broader than a reference value.¶

• Intersection Rule: how two values for the key combine into a result no broader than either operand.¶

• Change Controller: IETF, or the registrant for any other registration.¶

• Reference: the specification defining the key.¶

This document populates the registry with the Common Constraints it defines (Section 5.2); the "Ref" column below is this document, at the section shown, for every row, and the full Subset Rule and Intersection Rule text is there, not restated in the table:¶

Names are kept collision-free by the convention Section 5.2 already uses: a specification-defined name is coordinated through this registry, and any other name is either collision-resistant or remains deployment-defined and outside the registry.¶

20.9. Mission Lifecycle States Registry

IANA is requested to create the "Mission Lifecycle States" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for the discipline Section 10 requires: a Value matching ^[a-z][a-z0-9_]*$ not already registered; a Terminal designation of yes or no consistent with the transitions the registrant's specification defines (a yes state admits no further transition; a no state does); 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. Registration does not require IETF review or a Standards Track document; a Specification Required reference that a Designated Expert can review against these criteria suffices.¶

Only the exact value active permits token derivation or continued reliance; a consumer treats every other value, including one it does not recognize, as non-active and never widens on it (Section 10). A Designated Expert MUST reject a registration whose governing specification attempts to redefine this interaction rather than adding a new value bound by it.¶

Each registration records:¶

• Value: the lifecycle state's string value.¶

• Terminal: yes if the state admits no further transition, no otherwise.¶

• Semantics: one sentence stating what the state means and, for a non-terminal state, what a Mission in that state cannot do.¶

• Change Controller: IETF, or the registrant for any other registration.¶

• Reference: the specification defining the state.¶

This document seeds the registry with the states it defines:¶

Each further document that defines a lifecycle state requests that state's registration in its own IANA considerations, carrying its Internet-Draft reference as a publication dependency under this registry's policy until it is published.¶

21.1. Normative References

[I-D.draft-zehavi-oauth-rar-metadata]

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

[ISO4217]

International Organization for Standardization, "ISO 4217:2015, Codes for the representation of currencies and funds", ISO 4217:2015, August 2015.

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

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

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

[RFC9700]

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

[RFC9728]

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

21.2. Informative References

[AuthZEN.ARAP]

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

[FAPI.GrantManagement]

OpenID Foundation, "Grant Management for OAuth 2.0", 2022, <https://openid.net/specs/fapi-grant-management-01.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-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-klrc-aiagent-auth]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-auth-03>.

[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-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-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-actor-profile]

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

[I-D.draft-mcguinness-oauth-ai-agent-instance]

McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth-ai-agent-instance-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-ai-agent-instance-00>.

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

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

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

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

[I-D.draft-mcguinness-oauth-mission-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-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-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-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-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", 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>.

[MCP]

Model Context Protocol Project, "Model Context Protocol: Authorization", 2026, <https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization>.

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

[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, a workload identity established using WIMSE or SPIFFE, [I-D.draft-ietf-wimse-arch], [I-D.draft-ietf-oauth-spiffe-client-auth]), and alice has delegated to it through an ordinary authorization-code flow, per [I-D.draft-klrc-aiagent-auth]: client_id is the agent and the token sub is alice. This document adds the Mission layer on top of that identity; Stage 0 is otherwise unchanged from that specification.¶

A.2. Stage 1: Mission Creation

The agent submits this Submission envelope through PAR (Section 4.1), carrying the Mission Intent and no evidence, and proposing concrete authority alongside it on the authorization_details parameter (Section 4.2):¶

{
  "intent": {
    "goal": "Reconcile Q3 invoices and post adjustments under $500.",
    "resources": ["https://erp.example.com"],
    "constraints": [
      "Read only invoices issued in 2026-Q3.",
      "Post journal entries under $500."
    ],
    "success_criteria": [
      "All Q3 invoices reconciled.",
      "Each posted adjustment references a source invoice."
    ],
    "purpose": "urn:example:purpose:reconcile",
    "expires_at": "2026-12-31T23:59:59Z",
    "controls": {
      "acr": "urn:example:acr:mfa",
      "max_derivations": 200
    }
  }
}

The submitted authority proposal, on authorization_details in the same push:¶

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

The AS (as.example.com) validates both, derives this Authority Set (each entry a same-type subset of a proposed entry, Section 4.2), 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" }
    } }
]

After approval, the AS records Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- in the active state with authority_hash sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ, intent_hash sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY, and proposal_hash sha-256:kT2mR7vX4qL9nY5pB1sD8fJ6wZ3hC0aGeUoNvSqMrYo.¶

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

The agent redeems the authorization code at the token endpoint. The AS resolves the Mission from the grant (Section 6.1), gates on it being active (Section 10), and issues a Mission-bound access token for the ERP. The token response carries the granted authorization_details echo (Section 9) and the Mission references beside the token, response members rather than JWT claims (Section 6.1):¶

{
  "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" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ]
}

The decoded token:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840000,
  "exp": 1797840300,
  "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",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

Everything enforcement needs is in the token: the audience, the sender-constraint (cnf), the authority with its constraints, and the mission claim carrying the authority_hash consent anchor. The token is short-lived (300 s) and its exp is far below expires_at; revoking the Mission stops further derivation, and this token dies at its own expiry (Section 10.2).¶

A.4. Stage 3: The Resource Server Enforces

The agent calls the ERP Resource Server (erp.example.com) with that token. The Resource Server validates the JWT and the cnf binding and enforces the authorization_details whose resource it serves, permitting invoices.read within the Q3 issuance window and journal-entries.write up to the max_amount ceiling of 500.00 USD (Section 9.2). It treats the mission claim as audit and correlation context and makes no call to the AS.¶

This is stateless enforcement from the token alone. journal-entries.write is a consequential write, so where the deployment runs the runtime profile ([I-D.draft-mcguinness-mission-runtime]) it also obtains a point-of-use PDP permit against current Mission state before executing. The baseline bounds the write only by token lifetime and the carried constraints.¶

The cross-domain continuation of this same Mission, projected to a partner ERP in another trust domain and enforced there, is walked through in the companion's end-to-end example ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶