Mission Intent Shaping

1.1. Scope

This document is Informational. Deployments differ in how they process prompts, which language models they use, and what their products require, so no two transform a request into a Mission Intent the same way. The interoperable surface is the result, the Mission Intent and Authority Proposal, which the issuance profile defines and validates. This document therefore describes the shaper's role in the trust model and recommended shaper behavior. It defines no shaping protocol, media type, claim name, conformance class, grant type, token format, policy language, runtime decision API, or required endpoint; the approved Mission and its tokens remain those of the issuance profile.¶

This document is optional. A deployment that accepts only hand-authored Mission Intents conforms to the issuance profile and is unaffected by this document.¶

1.2. Mission Substrate

This document is written against the Mission model, not OAuth 2.0 mechanics. A shaper produces a structured Mission Intent and, optionally, a proposal of concrete authority, for a submission that the receiving issuer treats as untrusted input. Shaping Evidence commitments use the Default Commitment Construction of [I-D.draft-mcguinness-mission-substrate]. The issuance profile carries the submission in a Pushed Authorization Request; the Mission Authority Server [I-D.draft-mcguinness-mission-authority-server] accepts the same Mission Intent at its mission submission endpoint. The AAuth binding [I-D.draft-mcguinness-mission-aauth] defines no Mission Intent: its mission proposal is a natural-language description, so the construction guidance in this document does not apply to it. Another authorization substrate that accepts a structured, untrusted task proposal and commits it at approval can host these practices unchanged.¶

3.1. Client-Side Placement

The shaper runs in the same trust domain as the client that submits the Mission Intent. The client consumes the shaper's output and submits it to the Mission Issuer (Section 9.1).¶

The shaper is not a separate principal. It has no identity of its own to the Mission Issuer, which sees only the client. A deployment MAY factor the shaper into its own process or network service for engineering reasons (Section 11.1), but doing so does not make the shaper a principal to the Mission Issuer and does not move it across the trust boundary: it remains client-side machinery that produces an untrusted proposal.¶

3.2. The Shaper Proposes; It Does Not Issue

The Mission Shaper MUST NOT issue, derive, or certify authority of any kind. It produces a shaped proposal, which is untrusted client input under the issuance profile until the Mission Issuer validates and narrows it and binds authority at the approval event ([I-D.draft-mcguinness-oauth-mission], Section "Submission via PAR"). Nothing in this document changes that treatment, and a shaper SHOULD NOT structure its output to imply otherwise.¶

Three consequences follow:¶

1. It does not act as a credential issuer. A shaper that signs its output as a statement of authority, attaches an authority assertion, emits a credential, or otherwise behaves as a credential issuer is acting outside this role and is NOT RECOMMENDED. A deployment MAY integrity-protect shaper output for client-internal reasons, for example to detect tampering between the shaper and the submission step in a multi-process client (Section 12.5). Such protection has no authority semantics at the Mission Issuer and MUST NOT be relied upon beyond the client.¶

2. It does not mimic Mission Issuer output. The Mission Intent proposal MUST NOT carry mission.id, intent_hash, authority_hash, an Authority Set, a lifecycle state, or approving-principal evidence. The Mission Issuer produces those values on the Mission record at and after the approval event ([I-D.draft-mcguinness-oauth-mission], Section "Mission Record"). The issuance profile rejects a Mission Intent that carries an unrecognized top-level member, including any such issuer-output member, with the invalid_request error code ([I-D.draft-mcguinness-oauth-mission], Section "Submission via PAR").¶

3. It does not cross the trust boundary. Admitting input across the boundary is a Mission Issuer action. The shaper does not initiate the submission, call the pushed authorization request endpoint or the authorization endpoint, handle the authorization response, select the recipient Mission Issuer on its own authority, or attest to the submission on the Mission Issuer's behalf.¶

3.3. Deployment Roles

This document separates four roles that implementations often collapse:¶

Mission requester:

The user or component that supplies the task request to be shaped.¶

Mission Shaper:

Produces a shaped proposal and Shaping Evidence. Not authoritative for policy or consent.¶

Mission Issuer:

The Authorization Server that validates the proposal, derives the Authority Set, records the approval event, and issues Mission-bound credentials under the issuance profile.¶

Capability source:

A resource-owning catalog, metadata endpoint, policy service, or other source the shaper consults to resolve candidate resources and actions.¶

A deployment MAY co-locate these roles, but it SHOULD preserve the authority boundary: shaping produces a proposal, issuance creates an approved Mission, and runtime enforcement permits or denies actions.¶

6.1. Mission Intent Members

The following guidance maps a request or trigger onto each Mission Intent member. It is guidance, not an algorithm. Concrete authority (actions, structured constraints, and delegation facts) does not appear in the Intent; it belongs in the Authority Proposal (Section 6.2).¶

goal:

A concise summary in the form the Approver sees at consent. It preserves the requester's framing, so that the disclosure matches the requester's understanding. The shaper SHOULD NOT quote verbatim prompt text that contains instructions or commands (Section 12.3).¶

goal_lang:

The language tag of the Intent's human-readable members (goal, task_bounds, and success_criteria), when the shaper knows it.¶

target_resources:

The resources, datasets, tools, or domains the request referenced, each as an absolute URI. A human-readable label belongs in Shaping Evidence as an audit annotation, not in target_resources. Every resource value in the Authority Proposal appears here; the issuance profile refuses a proposed entry whose resource is not among target_resources with the invalid_request error code ([I-D.draft-mcguinness-oauth-mission], Section "Authority Proposal"). The shaper SHOULD NOT widen target_resources beyond what the request referenced: a resource added "for convenience" enlarges approved authority.¶

task_bounds:

Free-text bounds the requester expressed, plus the deployment-policy bounds always applied, so that the Approver sees the full set of bounds. Where a bound is machine-enforceable, the shaper also emits it as a structured constraint in the Authority Proposal; the Mission Issuer never parses the prose ([I-D.draft-mcguinness-oauth-mission], Section "Mission Authority"). The shaper SHOULD NOT silently drop a user-expressed bound; it records the bound in task_bounds or in Shaping Evidence, or it requests clarification or refuses.¶

success_criteria:

Free-text observable outcomes that show the task is complete, phrased for the Approver. They are disclosure and audit material only. The shaper SHOULD NOT encode authority in success_criteria, which carries no machine semantics in the issuance profile.¶

purpose:

If the client has registered purposes, the registered purpose URI that matches the task. If none matches, the shaper omits purpose or requests clarification instead of choosing the nearest one: purpose can key the Mission Issuer's configured mapping ([I-D.draft-mcguinness-oauth-mission], Section "Mission Authority"), so a wrong choice changes the derived authority (Section 12.3). The shaper SHOULD NOT invent a new purpose URI.¶

expires_at:

The earliest expiry that lets the task complete; if the request names no bound, a conservative deployment default. The shaper does not request the maximum the Mission Issuer allows, and the Mission Issuer can narrow the value further.¶

requested_derivation_limit:

Proposed only where the Mission Issuer implements [I-D.draft-mcguinness-oauth-mission-derivation-limits]; a Mission Issuer without it refuses the member as an unknown Intent member. Where the task implies a natural issuance count (a one-shot read, a fixed number of scheduled runs), the shaper proposes that count. Otherwise it omits the member, leaving the limit to deployment policy alone, which can impose none ([I-D.draft-mcguinness-oauth-mission-derivation-limits], Section "Effective Limit"). The shaper does not propose a large round number "to be safe": a proposed count only lowers the effective limit, so a high guess adds no bound and misleads the Approver.¶

Other companion members:

A companion profile can define further top-level Mission Intent members (for example, the consumption bounds of [I-D.draft-mcguinness-mission-metering]). The shaper emits the ones the deployment's adopted companions recognize. It SHOULD NOT emit a member the deployment does not recognize, since the issuance profile rejects an Intent that carries one.¶

6.2. Authority Proposal

The Mission Intent carries no authority members. Where a task calls for concrete authority (actions, structured constraints such as max_amount, or delegation facts), the shaper produces an Authority Proposal: an authorization_details array [RFC9396] that the client submits alongside the Intent and that the Mission Issuer treats as untrusted input ([I-D.draft-mcguinness-oauth-mission], Section "Authority Proposal").¶

Where cross-vendor interoperability matters, the shaper SHOULD carry the concrete candidate authority it proposes (the resources, actions, and constraints) in an Authority Proposal, and record the same Authority Proposal in Shaping Evidence. The Mission Issuer then derives the Authority Set in narrowing mode, each derived entry a subset of a proposed entry, rather than from a configured mapping keyed on the Intent ([I-D.draft-mcguinness-oauth-mission], Section "Mission Authority"). Narrowing is the portable derivation path: the proposal format and the narrowing rule are interoperable, so the result is enforceable and auditable across domains, and only the Mission Issuer's choice of what to narrow to stays local.¶

The proposal MUST NOT present issuer outputs as approved authority: the derived Authority Set is the Mission Issuer's product (Section 3.2). Shaping Evidence that records the same facts is for audit only and is never an input to derivation.¶

6.3. Shaping Ceiling and Default Deny

The shaper SHOULD apply a default-deny posture: its proposal contains only resources that have a positive basis in the request, context, capability sources, and shaping policy, and only the task_bounds and success_criteria the shaper can defend. It does not include a broad resource class as a fallback for unresolved detail.¶

When the concrete objects of an open-ended task are not known at shaping time, the shaper SHOULD express the bound as invariants over those objects (the owning customer, the tenant, an amount ceiling, read-only except named writes, a time window), instead of reaching for a broad resource class to anticipate them. Each invariant is a structured constraint in the Authority Proposal, which bounds the derived authority, and is restated in task_bounds for the Approver. The Mission Issuer derives the same Authority Set whatever task_bounds says ([I-D.draft-mcguinness-oauth-mission], Section "Mission Authority"), and runtime enforcement applies the constraints per object at the point of use.¶

The shaper SHOULD propose a Mission Intent scoped to one concrete task, not to an agent's whole session or standing role. When a request spans several distinct tasks, it proposes several task-scoped Mission Intents instead of one broad proposal, so that each resulting Mission stays narrow and is approved and revoked separately.¶

When a deployment or caller supplies a shaping ceiling, the proposal MUST be a subset of it: each Authority Proposal entry is a subset of a ceiling entry of the same type under that type's subset rule ([I-D.draft-mcguinness-oauth-mission], Section "Subset Rule"), and each target_resources value is among the resources the ceiling's entries name. An Intent submitted without an Authority Proposal can be derived through the Mission Issuer's configured mapping, which can grant more actions on the same resources than the ceiling allows. When the ceiling must constrain authority, the shaper MUST therefore produce an Authority Proposal. If the task cannot be completed within that ceiling, the shaper MUST request clarification, refuse, or emit a partial proposal. It MUST NOT silently drop necessary authority: it emits a partial proposal only when both of the following hold:¶

• Shaping Evidence records the excluded authority; and¶

• the outcome clearly indicates that the proposal may not satisfy the task.¶

The Mission Issuer enforces its own ceiling whether or not a shaping ceiling is present.¶

6.4. Delegation and Child Missions

The shaper does not author the delegation member of an Authority Set entry ([I-D.draft-mcguinness-oauth-mission-resource-access]). If the task implies sub-agents, background workers, or other delegated execution, the shaper SHOULD propose that fact in the Authority Proposal, recording the same fact in Shaping Evidence for audit only; the Mission Issuer narrows it when deriving delegation, or refuses. The shaper MAY also describe the desired delegation bound in task_bounds or success_criteria. The shaper SHOULD NOT infer delegated execution from the existence of a task graph or an agent harness: a child actor needs explicit authority derived by the Mission Issuer, not session ancestry.¶

Where a deployment creates Child Missions ([I-D.draft-mcguinness-oauth-mission-child-delegation]), turning a sub-task into the proposed Child Mission Intent is a shaping act, and this document applies to it unchanged. The Parent Mission's Authority Set is the shaping ceiling. The child-delegation profile refuses a child that is not a strict subset of its parent, so a proposal that exceeds the parent cannot be approved; the shaper instead requests clarification, refuses, or emits a partial proposal (Section 6.3). Shaping Evidence for a child proposal SHOULD record the parent Mission identifier (parent_mission) and the parent-derived ceiling it shaped under (shaping_ceiling).¶

7.1. Clarifications

A clarification SHOULD identify, in terms the requester can understand, the authority consequence of each offered answer. "Need more scope?" is not sufficient; "May this Mission read invoices for customer 5678 in addition to customer 1234?" is. It SHOULD state what the shaper will do if it is left unanswered (refuse, narrow, or wait).¶

Clarification runs from the shaper to the requester and resolves task ambiguity before a proposal exists. The reverse channel, in which the Approver questions the proposal at the consent surface, is Disclosure Interrogation ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); Shaping Evidence, in particular entry_rationales, is its grounding material (Section 8).¶

7.2. Refusal

Refusal is a shaper-internal decision. It requires no Mission Issuer involvement, and this document defines no wire-level refusal error. A shaper SHOULD refuse to shape when one of the following conditions holds. Each label is a recommended value for Shaping Evidence and for reporting the refusal to the client:¶

unsupported_task:

The shaper cannot produce a Mission Intent for the task class.¶

unresolved_resource, unresolved_action:

A requested resource or action cannot be resolved to a capability source (Section 5).¶

outside_authority_ceiling:

The task requires authority outside the deployment or caller shaping ceiling (Section 6.3).¶

policy_prohibited:

Deployment policy prohibits shaping the task.¶

material_ambiguity:

Material ambiguity remains, and policy requires refusal instead of clarification.¶

unsafe_to_shape:

The request includes adversarial, conflicting, or untrusted content that prevents a defensible proposal (Section 12.3).¶

A deployment MAY define additional labels. It SHOULD NOT reuse these labels with a different meaning.¶

A shaper SHOULD NOT refuse merely because the requested authority is broad, or because the Authority Set the Mission Issuer would derive looks expensive. Breadth is the decision of the Mission Issuer and the Approver, and cost is a runtime concern; refusing on those grounds substitutes the shaper's judgment for the Approver's.¶

8.1. Integrity and the Evidence Hash

A deployment MAY bind a proposal to its evidence so that the Mission record can cite how the proposal was produced. When it does, shaping_evidence_hash is a string in the integrity-anchor form of the issuance profile, computed as follows:¶

1. Place the Shaping Evidence object in the issuance profile's domain-separated {typ, iss, value} envelope, with typ set to mission-shaping-evidence, iss set to the Mission Issuer's issuer identifier, and value set to the Shaping Evidence object.¶

2. Compute the prefixed digest of the JCS [RFC8785] canonical bytes of that envelope.¶

The envelope supplies the typ domain separation and the iss binding that a digest of the bare object would omit. The hash is an audit commitment only.¶

Because the shaper is client-side and MAY build a proposal before the target Mission Issuer is selected, the hash can be computed only once the Mission Issuer's issuer is fixed. A proposal re-submitted to a different Mission Issuer needs a shaping_evidence_hash recomputed under that issuer's issuer.¶

A deployment MAY instead, or in addition, carry an integrity envelope over the Shaping Evidence, for example a JWS [RFC7515] Compact Serialization over the JCS canonical bytes of the evidence. When the JWS is embedded in the evidence, the signing input omits the member that carries it.¶

Where the deployment records Consent Evidence, the client conveys the hash in the mission_shaping_evidence_hash request parameter, and the Mission Issuer records it in the OPTIONAL shaping_evidence_hash member of the consent-disclosure object ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

Neither the hash nor the envelope confers authority. A Resource Server or PDP MUST NOT treat a shaping evidence hash as proof of authority.¶

When a Mission record cites a shaping_evidence_hash, the deployment SHOULD retain the Shaping Evidence and its input_exclusion_ruleset for as long as it retains the Mission record (the audit horizon of [I-D.draft-mcguinness-oauth-mission], Section "Mission Record"), so that the cited evidence stays reproducible. Retained Shaping Evidence is not rewritten, for example to update a label: any change breaks the commitment the Mission record cites.¶

9.1. Entering the Issuance Flow

The issuance profile defines a mission_intent parameter carried in a Pushed Authorization Request (PAR) [RFC9126], whose value is the Submission envelope ([I-D.draft-mcguinness-oauth-mission], Section "Submission via PAR"). The Mission Intent proposal is the envelope's intent member, and an Authority Proposal is the value of the authorization_details parameter in the same request.¶

Intent-bound evidence in the envelope's evidence array names the exact intent_hash of the submitted Intent. Intent-bound evidence obtained for an earlier candidate does not admit a re-shaped Intent unless its evidence type explicitly authorizes that transformation and defines how its lineage is verified. Otherwise, a shaping pass that changes the Intent needs intent-bound evidence for the Intent it actually submits ([I-D.draft-mcguinness-oauth-mission-submission-evidence], Section "Evidence Binds One Exact Intent").¶

The shaper hands its output to the client, which performs the OAuth flow (Section 3.2) and MAY also convey a shaping_evidence_hash so that the Mission record can cite the evidence (Section 8.1). The issuance profile rejects an unrecognized top-level member of the Submission envelope or the Mission Intent, so the client sends the hash in the mission_shaping_evidence_hash request parameter of the same pushed authorization request ([I-D.draft-mcguinness-oauth-mission-consent-evidence], Section "Shaping Evidence Hash Parameter"), which a Mission Issuer without Consent Evidence ignores. The value is a client-supplied audit commitment, not verified provenance, so conveying it requires no trust in the shaper.¶

9.2. Mission Issuer Handling

A Mission Issuer MAY use a shaping_evidence_hash, and any Shaping Evidence available to it, as input to the consent disclosure and to audit, never to derivation (Section 6.2). Whatever a shaper produced, the Mission Issuer, under the issuance profile:¶

• validates the Mission Intent independently;¶

• does not approve a Mission solely because a shaper produced it;¶

• derives the Authority Set under its own policy; and¶

• refuses, narrows, or requires approval as that profile requires.¶

Runtime enforcement [I-D.draft-mcguinness-mission-runtime] consumes the Mission Intent and the Authority Set on the Mission record, both produced by the Mission Issuer, not shaper output. A runtime that reads Shaping Evidence for an authorization decision is misusing it.¶

11.1. Exposing Shaping as a Service

A deployment that factors shaping into a network service for engineering reasons MAY expose it over HTTPS. The request and response formats of such a service are a local implementation detail, not an interoperability contract, and their description here is non-normative; the authentication requirement below is normative.¶

A request typically conveys the task (free text, structured fields, or both), the subject and agent on whose behalf the Mission would run, deployment context, an optional shaping ceiling, and the capability sources the shaper may consult. A response typically conveys an outcome (a shaped proposal, a set of clarifications, or a refusal), Shaping Evidence, and, for a proposal, an optional shaping_evidence_hash. A deployment that advertises such an endpoint in its metadata might use fields such as mission_shaping_endpoint and mission_shaping_profiles_supported.¶

Such an endpoint MUST be authenticated when it can reveal sensitive task, tenant, or resource information; an anonymous shaping endpoint is appropriate only for public, non-sensitive tasks. The service remains client-side and is not a principal (Section 3.1).¶

11.2. Declaring the Shaping Posture

A deployment that runs a shaper can declare the following in its Mission Deployment Profile, the deployment-level manifest defined by [I-D.draft-mcguinness-mission-architecture]:¶

• whether shaping is in the submission path;¶

• the shaper version policy;¶

• whether Shaping Evidence is retained, and for how long; and¶

• whether Mission records cite shaping_evidence_hash.¶

The shaping posture then appears in the same artifact as the deployment's other claims, and its absence is visible.¶

Shaping is not part of any Mission Assurance Level, and no level requires it: the levels are built from issuer-side and runtime-side guarantees, and the shaper is client-side ([I-D.draft-mcguinness-mission-architecture]). Shaping improves the input at every level: narrower Missions, clearer consent disclosures, and a reviewable trail from request to authority.¶

12.1. Model Output Is Not Authority

A model-based shaper can draft a Mission Intent, but a deployment MUST NOT let model output grant or widen access (Section 3.2). A model-based shaper inherits its model's failure modes (hallucinated resources, fabricated constraints, inconsistent paraphrase, and sensitivity to small input perturbations), and SHOULD record the model identifier and version in Shaping Evidence so that failures can be attributed. The same bound holds at approval: a model's judgment enters adjudication only as a recorded input to a deterministic policy, and that input can refuse or narrow, never grant or widen ([I-D.draft-mcguinness-oauth-mission]).¶

12.2. Shaper Compromise Does Not Directly Grant Authority

A compromised shaper can produce an arbitrary Mission Intent and suppress ambiguity, but it cannot, by itself, cause the Mission Issuer to approve that Intent. A compromised shaper can:¶

• cause spurious proposals to be submitted;¶

• mis-shape an Intent so that the Approver approves a task different from the one intended; or¶

• leak prompts through shaper-local logging.¶

It cannot:¶

• issue credentials;¶

• set or change Mission lifecycle state;¶

• bypass the approval event; or¶

• cause a Resource Server to act without authority issued by the Mission Issuer.¶

The Mission Issuer remains the enforcement point for approval: the issuance profile requires it to validate the proposal and derive authority under its own policy ([I-D.draft-mcguinness-oauth-mission], Section "Mission Authority"). Deployments SHOULD monitor shaper versions and evidence for anomalous broadening.¶

12.3. Prompt Injection and Untrusted Content

The shaper's input is, by assumption, partly or wholly attacker-influenceable. Prompts can contain pasted content, content the user was tricked into typing, or content arriving through a non-prompt trigger such as an inbound email or webhook. Task text, tickets, documents, tool descriptions, and catalog metadata can all carry instructions aimed at the shaper. Concrete threats include attempts to:¶

• expand target_resources beyond what the user requested;¶

• push expires_at past deployment policy;¶

• suppress a stated constraint; or¶

• select a purpose the user did not choose.¶

Mitigations the shaper SHOULD apply:¶

1. Treat all prompt and attachment content as untrusted data, not as instructions to the shaper. Do not let it alter shaper policy or override deployment defaults.¶

2. Apply the refusal behavior of Section 7.2 when the input exhibits injection patterns.¶

3. Do not echo verbatim prompt-derived instruction text into goal or task_bounds that the Approver will read. Paraphrase, or quote with clear attribution, but do not present injected content as if it came from the user.¶

4. Use the resolved vocabulary of the capability sources as a hard allowlist (Section 5); do not infer new authority types from the prompt.¶

5. Record the prompt, the parsed intent, and the chosen defaults in Shaping Evidence so that an auditor can reconstruct what the shaper saw.¶

Injection cannot be fully eliminated at the shaper. The defense in depth is that the Approver sees the Mission Intent in a consent disclosure rendered by the Mission Issuer, not by the shaper, before authority is bound. A shaper that builds the Intent truthfully and a Mission Issuer that renders the disclosure truthfully together make injection visible at the approval step.¶

12.4. Silent Broadening and Stale Capability Sources

The primary failure mode is silent broadening: a vague goal becomes a wide Authority Set. The ambiguity rules of Section 7 fail closed by requiring clarification, narrowing, or refusal. A proposal shaped against an outdated catalog can also resolve the wrong capability. Capability resolutions SHOULD record source digests (Section 5) so that approval and runtime enforcement can detect drift. A shaped proposal can also go stale. When a proposal's freshness bound (for example, an expiry, or a source digest that no longer matches) shows that it was built against a capability catalog or policy version that has since changed, the client SHOULD re-shape it instead of submitting it. Deployments SHOULD re-shape when catalog data is volatile.¶

Re-shaping adds a loop variant of the same failure: widening by retry, in which refused authority is resubmitted in different words until something passes, or successive proposals walk the Mission Issuer's policy boundary (Section 10). A deployment SHOULD monitor for a requester whose successive proposals for one task broaden; Shaping Evidence chained across re-proposals is the record that makes such a pattern visible.¶

12.5. Shaper-to-Client Integrity in a Multi-Process Client

In a client where the shaper runs in a different process or on a different machine from the OAuth submission code, the step from shaper to submission is an in-client boundary. An attacker between the two could alter the Mission Intent before submission. The Mission Issuer still validates the altered Intent and renders its consent disclosure, so the Approver remains the final line of defense, but the altered Intent will not match what the shaper produced. A deployment MAY apply client-internal integrity protection between shaper output and the submission code (a client-local signature, a process-isolated channel). Such protection has no semantics at the Mission Issuer and MUST NOT be carried into the Mission Intent as if it did (Section 3.2).¶

15.1. Normative References

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

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

[RFC2119]

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

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

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

15.2. Informative References

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

McGuinness, K., "Mission Context Binding for AAuth", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.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-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-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-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-approval-revision]

McGuinness, K., "Mission Approval Revision for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval-revision.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-derivation-limits]

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

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

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

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

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

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

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

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

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

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

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

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

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