Mission Intent Shaping

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") makes a Mission a first-class authorization artifact. It defines how a Mission Intent is submitted, how an Authorization Server derives an Authority Set, how an Approver consents, and how issued tokens are bound to the approved Mission. It does not standardize how a deployment turns an open-ended task request, such as "resolve this billing dispute," into a Mission Intent with a goal, resources, free-text constraints, success criteria, purpose, controls, and expiry.¶

This document describes that missing shaping step. A Mission Shaper is a client-side component that produces a candidate Mission Intent before the issuance profile's approval flow begins. The shaper can be a deterministic rules engine, a form, an LLM-assisted function, or a workflow. Whatever its implementation, its output is only a proposal (Section 5.2).¶

The purpose of this profile is to make shaping auditable and fail closed. When a task request is ambiguous, the shaper does not silently invent authority: it narrows to a defensible candidate, asks for clarification, or refuses to shape. When a capability or resource is unknown, the shaper records that fact rather than treating natural language as authority to create it. When the shaper uses model output, that output is evidence for review, not an entitlement decision.¶

2. Relationship to the Issuance Profile

This document is OPTIONAL and layered on [I-D.draft-mcguinness-oauth-mission]. A deployment that accepts only hand-authored Mission Intent values is fully conformant to the issuance profile and is unaffected by this document.¶

This document describes:¶

• the shaper's role and trust boundary (Section 5);¶

• a processing model and recommended Mission Intent construction (Section 6, Section 7);¶

• recommended ambiguity, refusal, and capability-resolution behavior (Section 8, Section 9);¶

• Shaping Evidence, an audit artifact (Section 10); and¶

• how a shaped proposal enters the issuance flow (Section 13).¶

This document does not define a new OAuth grant type, a new access token format, a policy language, a runtime authorization decision API, or a required shaping endpoint. The approved Mission and its tokens remain those of the issuance profile.¶

It uses the terms Mission, Mission Intent, Authority Set, Mission Issuer, Approver, and Authorization Server as defined by [I-D.draft-mcguinness-oauth-mission]. Where this document refers to "the issuance profile" without a section, it means that document as a whole. "Client" and "client-side" in this document mean the OAuth client, the Agent (Client) of the issuance profile that submits the Mission Intent; the shaper runs on that Agent's side of the trust boundary.¶

3. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The normative keywords in this document describe recommended shaper-side behavior that an auditor can observe in the shaper's output. Mission Issuer behavior is cited from the issuance profile ([I-D.draft-mcguinness-oauth-mission]), not legislated here. The keywords do not establish a conformance class: this profile is Informational (Section 1.1).¶

All JSON shown in this document is non-normative and illustrative; the member descriptions in the surrounding text are authoritative. This document uses JSON [RFC8259] as the data model for the illustrative objects, and JCS [RFC8785] where a hash is computed over Shaping Evidence (Section 10).¶

This document additionally uses:¶

Mission Shaper (or "shaper"):

A client-side component that produces a candidate Mission Intent from a task request and supporting context. A Mission Shaper does not grant authority.¶

Mission requester:

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

Mission Intent proposal:

The candidate mission_intent object the shaper emits for validation and approval 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.¶

Shaping Evidence:

The record of inputs, inferences, policy decisions, unresolved ambiguities, and capability-resolution facts that produced the Mission Intent proposal. Audit material, not authority.¶

4. Mission Substrate

This document is defined against the Mission model rather than against OAuth 2.0 mechanics. A shaper consumes two substrate primitives: the Mission Intent structure it proposes, and the submission channel through which a proposal reaches the Mission Issuer as untrusted input (Pushed Authorization Requests in the OAuth binding); Shaping Evidence additionally uses the substrate's integrity-anchor envelope. The issuance profile [I-D.draft-mcguinness-oauth-mission] defines these for OAuth 2.0. The Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]) is a standalone binding of that submission channel; a shaped proposal enters it through the MAS mission submission endpoint unchanged. Another authorization substrate that accepts a structured, untrusted task proposal and commits it at approval can host the shaping practices described here unchanged.¶

5. Shaper Role and Trust Boundary

The Mission Shaper occupies a single, narrow role. This section defines that role and the trust boundary the shaper does not cross. It is the stable core of this profile.¶

6. Processing Model

A sound shaper processes a request in this order:¶

1. Normalize and classify the caller-supplied task input.¶

2. Distinguish facts supplied by the requester, facts supplied by trusted context, and facts inferred by the shaper.¶

3. Resolve candidate resources and actions against capability sources (Section 9).¶

4. Apply deployment shaping policy, including authority ceilings and risk classification.¶

5. Detect material ambiguity (Section 8).¶

6. Produce an outcome: a proposal, a request for clarification, or a refusal.¶

7. Record Shaping Evidence and, for a proposal, optionally a shaping_evidence_hash (Section 10).¶

The shaper SHOULD NOT skip capability resolution merely because a task is natural-language plausible. A request such as "email the customer" does not identify which mailbox, sender, recipient, template, or data source is allowed unless the deployment's capability sources or policy resolve those details.¶

7. Mission Intent Construction

A Mission Intent proposal MUST satisfy the syntactic requirements of the issuance profile's mission_intent object ([I-D.draft-mcguinness-oauth-mission]): a goal, resources (each an absolute URI), optional free-text constraints, optional success_criteria, an optional purpose, an optional proposed_authority array of candidate Authority Set entries, an expires_at, and an optional controls object. The shaper proposes the resources and describes the desired bounds in free-text constraints and success_criteria; it does not author actions, structured constraints, or delegation. The Mission Issuer derives the actions, structured (object) constraints, and delegation as members of the Authority Set it computes ([I-D.draft-mcguinness-oauth-mission]). The proposal MUST be bounded enough for the Mission Issuer to derive an Authority Set without interpreting natural language as authority.¶

The proposal MUST NOT present issuer outputs as approved authority: the derived Authority Set is the Mission Issuer's product, and nothing the shaper emits carries authority. Concrete candidate authority (actions, structured constraints such as max_amount, delegation) belongs in the Intent's proposed_authority member, where the core treats it as untrusted proposal input and bounds the derivation to a subset of it ([I-D.draft-mcguinness-oauth-mission]). A shaper that has resolved such facts (for example, the actions a resource supports, or that the task implies delegated execution) proposes them there and records them in Shaping Evidence (Section 10), where the Mission Issuer MAY consult them, rather than placing them in the proposal.¶

A sound shaper does not include a resource in the proposal merely because the task text implies it might be useful. The shaper should have a resolution basis under Section 9, or it should produce a clarification request or a refusal.¶

8. Ambiguity Handling

A sound shaper classifies material ambiguity. Ambiguity is material when choosing one interpretation over another would change the Authority Set, the action class, the actor allowed to exercise it, the expiry, or the risk posture.¶

For material ambiguity, a sound shaper does one of:¶

1. request clarification;¶

2. emit a narrower proposal that excludes the ambiguous authority and records the exclusion in Shaping Evidence; or¶

3. refuse with a reason.¶

Because a shaper is a client-side component whose internal reasoning the Mission Issuer cannot observe, this profile expresses the requirement through the observable artifact rather than the internal choice: when a shaper resolves an ambiguity in the broadening direction, Shaping Evidence MUST record the resolution and, where a deployment permits policy-based default narrowing, the policy rule that authorized it. A proposal that broadens authority on an ambiguity without a corresponding Shaping Evidence record is unsound. The Mission Issuer enforces its own ceiling and consent regardless of what the shaper recorded.¶

Requesting clarification is not approval. The user's response is incorporated into the Mission Intent; the Mission Issuer still validates, narrows, and renders the consent disclosure for binding approval. A shaper MUST NOT treat answered clarifications as a reason to skip the Mission Issuer consent step: the shaper is not the Approver's agent for consent.¶

9. Capability and Resource Resolution

Before proposing a resource, a sound shaper establishes a resolution basis. The basis is one of:¶

catalog:

Resolved from a catalog, metadata endpoint, OpenAPI description, MCP tool catalog, or equivalent source.¶

policy:

Selected by a deployment policy rule.¶

user_supplied_exact:

The requester supplied a concrete resource identifier and the shaper verified it is admissible for shaping.¶

authority_source:

A resource-owning system or Authorization Server supplied an allowed resource/action projection for this task.¶

A sound shaper records the resolution basis in Shaping Evidence. A model-generated capability name with none of these bases is not resolved, and a sound shaper treats it as unresolved (Section 8.2).¶

For each resolved capability, Shaping Evidence SHOULD record what was requested, what it resolved to, the basis, the source consulted (for catalog and authority_source), and, where available, a digest over the source representation so later approval and runtime enforcement can detect drift. A confidence value, if recorded, is audit evidence only and MUST NOT be treated as authority.¶

10. Shaping Evidence

Shaping Evidence records how a proposal was produced. It is audit material: it does not grant authority and MUST NOT be used by a Resource Server or Policy Decision Point to permit an action. This profile defines no required schema, media type, or transport for it; the following members are RECOMMENDED content.¶

shaper_id:

A string identifying the shaper.¶

shaper_version:

A string identifying the shaper implementation, model, policy bundle, or workflow version.¶

input_digest:

A digest over the shaping request, in the integrity-anchor encoded form of [I-D.draft-mcguinness-oauth-mission], computed over the JCS [RFC8785] canonical bytes of the request after removing the fields the named exclusion ruleset marks as non-retained. To make the digest recomputable by a later auditor, the evidence MUST also record input_exclusion_ruleset, an identifier (and version) of the exclusion ruleset applied, and the auditor recomputes the digest over the retained canonical input under that ruleset. A digest whose exclusion set is not recorded cannot be reproduced and so is not a sound input_digest.¶

user_supplied_facts:

Facts copied from the request.¶

inferred_facts:

Facts the shaper inferred, each with its supporting evidence and whether human confirmation is required.¶

policy_decisions:

Policy rules applied during shaping.¶

capability_resolutions:

Each resource or action and its resolution basis (Section 9).¶

ambiguities:

Material ambiguities and how each was handled.¶

excluded_authority:

Plausible authority the shaper deliberately excluded.¶

model_trace:

Model prompts, outputs, or tool calls used during shaping. When retained it MUST be treated as sensitive audit data (Section 16) and MUST NOT be rendered as authority.¶

{
  "shaper_id": "mission-shaper.example.com",
  "shaper_version": "policy-bundle-2026-06-30",
  "input_digest":
    "sha-256:InP9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4aB7cDe",
  "input_exclusion_ruleset": "standard-2026-06",
  "user_supplied_facts": [
    "support ticket 456",
    "customer 1234"
  ],
  "capability_resolutions": [
    {
      "requested": "invoice.read",
      "resolved": "invoice.read",
      "basis": "catalog",
      "source_uri":
        "https://billing.example.com/.well-known/tools"
    }
  ]
}

11. Worked Example

alice tells her agent, in free text: "reconcile our Q3 invoices and post any adjustments under $500." The shaper turns that open-ended goal into a bounded proposal. It scopes to the one task, bounds the work by invariants rather than enumerating invoices it cannot know yet, and proposes only authority it can defend from the request; it does not add a broad fallback. The candidate Mission Intent it submits:¶

{
  "goal": "Reconcile Q3 invoices and post adjustments under $500.",
  "resources": ["https://erp.example.com"],
  "constraints": [
    "Read only invoices in fiscal period 2026-Q3.",
    "Post journal entries no greater than $500.",
    "Customer scope: acme-corp only."
  ],
  "success_criteria": ["All Q3 invoices for acme-corp reconciled."],
  "purpose": "urn:example:purpose:reconcile",
  "expires_at": "2026-11-05T00:00:00Z"
}

This is only a proposal (Section 5.2). The Mission Issuer, not the shaper, validates it, narrows it to policy, and derives the concrete Authority Set the agent will be bound to: a mission_resource_access entry for https://erp.example.com with invoices.read constrained to the 2026-Q3 period and the acme-corp tenant, and journal-entries.write constrained to a max_amount of 500.00 USD. The shaper's free-text constraints informed that derivation but granted nothing; the invariants (period, amount, tenant) are what bound an open-ended task whose individual invoices were unknown when the goal was written. Had the request been ambiguous about which entity's invoices, the shaper would have asked alice rather than guess (Section 8.1).¶

12. Mission Issuer Handling

A Mission Issuer that receives a shaped Mission Intent MAY use a shaping_evidence_hash and Shaping Evidence as input to approval and audit. Under [I-D.draft-mcguinness-oauth-mission] it independently validates the Mission Intent, does not approve a Mission solely because a shaper produced it, derives an Authority Set under issuer policy, and refuses, narrows, or requires approval as that profile requires. A shaping_evidence_hash the Mission Issuer records on the Mission record is an audit commitment only.¶

A shaped proposal can go stale. A deployment that conveys a freshness bound with the proposal (for example, an expiry, or an evidence source digest that no longer matches) SHOULD re-shape rather than submit a proposal built against a capability catalog or policy version that has since changed.¶

13. Composition

14. Exposing Shaping as a Service

This profile requires no shaping endpoint, and a shaper is a client-side function (Section 5.1). A deployment that nevertheless factors shaping into a network service for engineering reasons MAY expose it over HTTPS. The request and response shapes such a service uses are a local implementation detail, not an interoperability contract, and this section is non-normative.¶

A request typically conveys the task (free text and/or structured fields), the subject and agent on whose behalf the Mission would run, deployment context, an optional authority ceiling, and the capability sources the shaper may consult. A response typically conveys an outcome (a Mission Intent proposal, a set of clarifications, or a refusal) together with Shaping Evidence and, for a proposal, an optional shaping_evidence_hash. A deployment that publishes such an endpoint through 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. Exposing the shaper this way does not change its role: it remains client-side machinery that produces an untrusted proposal (Section 5), and it is not a principal to the Authorization Server.¶

15. Security Considerations

The shaper sits at the prompt-to-Intent boundary. Its security properties follow from the role contract: the shaper proposes, and authority is created only at the Mission Issuer's approval event.¶

16. Privacy Considerations

The shaper sits where a user's natural-language prompt, which may carry personal data, business-confidential content, or free-form expression, becomes structured artifacts. The privacy surface follows from where that content flows.¶

The shaper copies or paraphrases prompt content into goal, resources, constraints, and controls, which the Mission Issuer renders in a consent disclosure the Approver reads and which may be retained in the Mission record. A shaper SHOULD carry into these fields only the content needed to describe the task, SHOULD NOT widen resources or echo unrelated prompt content (Section 7), and SHOULD avoid copying third-party personal data into goal where a non-identifying description suffices.¶

Shaping Evidence aggregates the prompt, applied defaults, inferences, and model outputs into one artifact and is therefore a concentrated sink of sensitive content. Deployments SHOULD minimize retained raw task text, prefer digests where full content is not required for audit, apply access controls equivalent to those used for Mission records, and be able to produce a redacted evidence record for audiences that need the transformation provenance but not the raw prompt.¶

The shaper introduces no identifier of its own and is not a separate principal to the Mission Issuer (Section 5). It therefore adds no cross-party correlation surface beyond the prompt content it processes and the requesting-client identity the Mission Issuer already sees.¶

17. IANA Considerations

This document has no IANA actions. The Mission Intent Shaping profile is Informational; it registers no media type, claim name, endpoint name, parameter name, error code, metadata field, or namespace URI. A future portable shaping protocol, if specified, would be a separate document and would carry its own registrations there.¶

18. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 set and describes the shaping layer that precedes Mission issuance. It builds on Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] and complements Mission-Bound Runtime Enforcement [I-D.draft-mcguinness-mission-runtime].¶

Author's Address