Mission Template for OAuth 2.0

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 22 February 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

An agent that runs a recurring task dispatches it many times: once per ticket, per document, per scheduled window. Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") commits a Mission's authority at a single human approval event. Requiring that event at every dispatch does not scale to machine speed, and the alternative, a single standing Mission broad enough to cover every dispatch, over-provisions: the agent holds the full breadth the whole time, and a fresh approval per run is what the deployment was trying to avoid.¶

This document defines an experimental third option: the Mission Template. A human consents once to a template, which fixes a ceiling of resources, actions, and constraints, names a dispatch policy, and publishes a set of bounds. Each dispatch then instantiates an ordinary Mission from the template by that policy, at machine speed, with no fresh human approval. Consent is given once, to the ceiling; each instance draws within it deterministically.¶

This concretizes the blessed semantics the architecture's Approve verb states: a deterministic, versioned policy can approve at machine speed within a ceiling a human consented to, because the policy approves the instance and a human approved the policy, with a policy version keeping that chain re-checkable ([I-D.draft-mcguinness-mission-architecture]). The accountable principal for every dispatched Mission is the human who approved the template. The high-consequence classes stay on a fresh human decision, exactly as that verb requires (Section 8).¶

2. Status: An Experimental Extension

This document is optional and experimental: adopt it for evaluation, not as a stable interface. It removes the per-dispatch human from a consented template, which is a high-consequence capability. This document therefore conditions the capability on the ceiling, the bounds, the prohibited-class rule, and the audit linkage it requires, and an ordinary human-approved Mission ([I-D.draft-mcguinness-oauth-mission]) remains the better fit where each run can carry its own approval. No Standards-Track document depends on this one.¶

A Mission Issuer that does not implement this document creates every Mission through a fresh human approval and is a fully conforming issuance-profile Mission Issuer ([I-D.draft-mcguinness-oauth-mission]). Nothing here places a new requirement back on the issuance profile.¶

3. Relationship to Other Profiles

This document depends normatively on the issuance profile [I-D.draft-mcguinness-oauth-mission] and on the Consent Evidence profile [I-D.draft-mcguinness-oauth-mission-consent-evidence], and is not implementable alone. It reuses, without restating, the issuance profile's approval event, integrity-anchor envelope, subset rule, Authority Set derivation, Mission record, and active/revoked/expired lifecycle; and the Consent Evidence profile's rule that a consented object's disclosure is committed. It uses Agent, Subject, Approver, Mission Issuer, Mission Intent, Authority Set, and Mission as the issuance profile defines them.¶

The runtime enforcement profile [I-D.draft-mcguinness-mission-runtime] is a normative dependency for its action classes, which the prohibited-class rule tests against (Section 8).¶

Progressive authorization ([I-D.draft-mcguinness-oauth-mission-progressive]) and expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) are informative siblings. Progressive removes the per-expansion human from a consented authority ceiling on a single evolving Mission; this document removes the per-dispatch human from a consented template that mints many independent Missions. Both concentrate one considered human consent to a ceiling in place of many hurried consents, and both hold the high-consequence classes back for a human. Where progressive draws a successor within one chain, a template dispatches independent instances.¶

Terminology disambiguation:

The Consent Evidence profile ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) already uses template_id and template_version to name a disclosure-rendering template, the presentation template a Consent Disclosure object was rendered from. The Mission Template of this document is a different object on a different surface: a consented ceiling and dispatch policy that instances are minted from, not a rendering of a disclosure. The two never share a member. Where this document commits a Mission Template's disclosure under Consent Evidence, that disclosure carries the Consent Evidence profile's template_id and template_version for its own rendering template, which are unrelated to the Mission Template being disclosed.¶

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

All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

Mission Template:

A consented object that fixes a Template Ceiling, a Dispatch Policy, the allowed dispatchers and recipients, per-instance bounds, and a review cadence, and from which Missions are dispatched by policy without a fresh human approval (Section 5).¶

Template Ceiling:

The pre-consented maximum authority any Mission dispatched from a Mission Template may reach: an array of authorization-details-shaped entries, each the shape of an Authority Set entry ([I-D.draft-mcguinness-oauth-mission]), that every dispatched instance MUST be within (Section 7).¶

Dispatch:

The act of instantiating an ordinary Mission from a Mission Template by policy, at machine speed, with no fresh human approval (Section 7).¶

Dispatcher:

The authenticated principal that requests a Dispatch. A Dispatcher is not an Approver: it triggers instantiation within a template a human already approved, and its authority to do so is fixed by the template's allowed dispatchers.¶

Dispatch Policy:

The deployment-defined policy, identified and versioned, under which the Mission Issuer instantiates a Mission from a Mission Template. It is the policy the human approved when consenting to the template (Section 5), and it is trusted governance held by the Mission Issuer.¶

Mission Deployment Profile:

The deployment-level manifest the architecture defines ([I-D.draft-mcguinness-mission-architecture]). The bounds, the action-class mapping, and the review cadence this document requires a deployment to publish are published there.¶

5. The Mission Template

A Mission Template is a consented object with these members:¶

id:

REQUIRED. A string. The Mission Template Identifier, stable across the template's lifetime.¶

issuer:

REQUIRED. A string. The Mission Issuer that holds and dispatches from the template.¶

template_version:

REQUIRED. A string. The version of this template's consented content. A change to any consented member is a new template_version and, per Section 6, a new human approval.¶

ceiling:

REQUIRED. An array of authorization-details-shaped entries, each the shape of an Authority Set entry ([I-D.draft-mcguinness-oauth-mission]). This is the Template Ceiling: the pre-consented maximum any dispatched instance may reach. A ceiling entry MAY name a resource family rather than a single resource, under the resource-narrowing semantics the subset rule fixes ([I-D.draft-mcguinness-oauth-mission]).¶

dispatch_policy:

REQUIRED. An object carrying id and version, identifying the Dispatch Policy under which the Mission Issuer instantiates from this template. Its content is deployment-defined. Committing only id and version leaves the policy body itself uncommitted, so a change to its logic between template consent and a given dispatch is not detectable from the template alone. A deployment SHOULD additionally commit the Dispatch Policy body under an integrity anchor, computed the way the issuance profile computes authority_hash ([I-D.draft-mcguinness-oauth-mission]), or disclose it under Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), so a machine-speed dispatch decision stays auditable against the policy content a human actually consented to, not only its identifier.¶

allowed_dispatchers:

REQUIRED. An array identifying the principals permitted to dispatch from this template. A Dispatch request from a principal not in this set is refused (Section 7).¶

allowed_recipients:

REQUIRED. An array bounding which Subjects and Agents a Mission dispatched from this template may be created for. The Mission Issuer establishes the instance's Subject as the issuance profile requires, never from Dispatcher input ([I-D.draft-mcguinness-oauth-mission]), and refuses a Dispatch whose established Subject or Agent falls outside this set, so a template cannot mint a Mission for a party the human did not consent to.¶

instance_lifetime:

REQUIRED. A duration. The per-instance lifetime clamp: a dispatched Mission's expires_at is clamped to no more than this from its committed created_at (Section 7).¶

max_active:

REQUIRED. An integer. The maximum number of Missions dispatched from this template that may be active at once. A Dispatch that would exceed it is refused until an active instance terminates.¶

dispatch_rate:

REQUIRED. A rate bound on Dispatch from this template per unit time.¶

expires_at:

REQUIRED. The template's own expiry ([I-D.draft-mcguinness-oauth-mission]). After it, the template dispatches nothing.¶

review_cadence:

REQUIRED. The maximum age of the template's most recent human approval past which the Mission Issuer MUST NOT dispatch (Section 6).¶

The concrete values of instance_lifetime, max_active, dispatch_rate, and review_cadence, and the action-class mapping the prohibited-class rule needs (Section 8), MUST be published in the Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]).¶

6. Template Consent

Creating a Mission Template is itself a human approval event under the issuance profile ([I-D.draft-mcguinness-oauth-mission]). Its consent object is the Mission Template: the human consents to the ceiling, the dispatch policy, the allowed dispatchers and recipients, and the bounds, and the approval commits them under template_hash (Section 5.1), the anchor over the object consented to.¶

Where Consent Evidence is claimed, the template-creation approval's disclosure is committed as that profile commits any disclosure ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). The template is consented before any Mission exists, so, as the Consent Evidence profile already handles for an approval that commits no Mission, the disclosure and its evidence carry the Mission Issuer's issuer and the committed anchor and no Mission id.¶

The consent disclosure MUST render, at minimum:¶

• the Template Ceiling, as the maximum authority any dispatched Mission may reach;¶

• that instances issue at machine speed, by policy, with no per-instance human approval; and¶

• that the high-consequence classes (Section 8) are never dispatched by policy and still require a fresh human decision.¶

A consent that does not render these is standing dispatch authority obtained by omission. A template the human did not knowingly consent to is not a Mission Template under this document.¶

A Mission Template's consent is standing consent, and standing consent decays. The Mission Issuer MUST NOT dispatch from a template whose most recent human approval is older than the published review_cadence (Section 5): dispatch stops until a fresh human approval re-consents, or narrows, the template. The review approval is an ordinary template-creation approval; its disclosure SHOULD render the template's dispatch record since the prior review, so the reviewer sees the cycle they renew.¶

7. Dispatch

A Dispatch instantiates an ordinary Mission from a Mission Template. It is submitted on the binding's existing Mission creation surface as a single authenticated back-channel request that references the template by id and carries the dispatch intent, and it is answered in one round trip. This document defines no new endpoint and no new Authorization Server metadata: dispatch is a non-interactive Mission creation under the pre-consented template, at the token endpoint under the grant type this document defines (Section 7.2).¶

Because the human decision was made once, at template creation, a Dispatch uses no Pushed Authorization Request, no front-channel authorization request, and no interactive consent surface, and the Mission Issuer never answers a Dispatch with authorization_pending: there is no pending human step to wait for. A deployment that needs a human in the loop for a given run does not dispatch it; it creates an ordinary Mission through a fresh approval.¶

The Mission Issuer adjudicates a Dispatch in this order:¶

1. Authenticate the Dispatcher. Resolve and authenticate the principal making the request.¶

2. Authorize the Dispatcher. Verify the Dispatcher is in the template's allowed_dispatchers. Refuse a request from any other principal.¶

3. Derive the instance Authority Set. Derive an Authority Set from the dispatch intent, and from the Dispatcher's authority proposal where one was submitted (Section 7.2), and bound it by the deployment's derivation policy, exactly as for any Mission ([I-D.draft-mcguinness-oauth-mission]). This document adds no authority-derivation rule.¶

4. Double intersection. The derived instance Authority Set MUST be a subset, under the issuance profile's subset rule ([I-D.draft-mcguinness-oauth-mission]), of both the deployment's derivation-policy ceiling and the Template Ceiling. Each surviving instance entry MUST be a subset of some ceiling entry. If no entry survives the intersection with the Template Ceiling, the Mission Issuer MUST refuse the Dispatch with out_of_template_ceiling (Section 9). Raising the ceiling is a new template consent, not a dispatch.¶

5. Prohibited-class check. Apply the prohibited-class rule (Section 8) to the surviving post-intersection set. If it would grant a high-consequence class, refuse the Dispatch with dispatch_prohibited_class (Section 9).¶

6. Enforce the bounds. Refuse the Dispatch if it would exceed max_active or dispatch_rate, or if the instance's Mission-Issuer-established Subject or its Agent falls outside allowed_recipients (Section 5).¶

7. Commit the instance. Commit an ordinary Mission whose Authority Set is the surviving set and whose:¶

   • approver is the template's human approver, the accountable principal ([I-D.draft-mcguinness-oauth-mission]). The Dispatcher is not the approver. The instance is rooted in the approval_basis authorization basis the issuance profile defines ([I-D.draft-mcguinness-oauth-mission]), with type: "template": consent_principal is the template's human approver (equal to approver); activation carries the template's id (as template_id, the same value the Dispatch grant names Section 7.2), template_version, and template_hash (the template lineage member's fields, Section 7.1), plus this Dispatch's dispatch_event_id; activation_actor is the Dispatcher, distinct from consent_principal; root_commitment is template_hash; and approved_at (the issuance profile's standing-consent requirement) is the instant the consenting human approved this exact template_version, read from the Mission Issuer's retained template record at Dispatch, never from the Dispatch request. This makes the approver-of-record shift from a fresh human decision to policy adjudication under a prior human consent structured and flagged consistently across the family, superseding a bare policy-adjudicated marking. The template lineage member (Section 7.1), present on every dispatched Mission and absent on an ordinarily approved one, remains the claim-carried record of which template and Dispatch Policy adjudicated the instance; approval_basis is the structured authorization-basis record, and the two are consistent by construction;¶

   • subject is established as the issuance profile requires, never taken from Dispatcher input, and is within allowed_recipients ([I-D.draft-mcguinness-oauth-mission]);¶

   • intent_hash and authority_hash are computed over the instance's own Intent and final Authority Set, never over the template; the template commits the ceiling under template_hash (Section 5.1);¶

   • expires_at is the effective Mission expiry of the issuance profile's requested-versus-effective rule ([I-D.draft-mcguinness-oauth-mission]): the minimum of the dispatch intent's requested expires_at, the committed Mission created_at plus the template's instance_lifetime, and the template's expires_at. The lifetime addend is measured from the committed created_at, not a separate clock read, so audit recomputation is exact. These are the complete expiry inputs for Dispatch: a deployment that needs a tighter standing-consent lifetime records it in instance_lifetime or the template's expires_at under a newly consented template_version, rather than applying an undisclosed fourth clamp; and¶

   • template lineage member is set (Section 7.1).¶

A Dispatch MUST be idempotent per dispatch event identifier. The Dispatcher supplies a dispatch event identifier with the request; a repeated request bearing an identifier the Mission Issuer has already committed returns the Mission it already committed, and instantiates no second Mission. This makes retry safe at machine speed and keeps max_active and dispatch_rate accounting exact. The dispatch event identifier is this grant's realization of the creation idempotency the expansion profile defines for the family's Mission-creating token exchanges ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

8. Prohibited Classes

Some authority classes are too consequential to activate without a human at the moment of the decision. A Dispatch MUST NOT instantiate a Mission that grants authority in any of these classes, even when the class is within the Template Ceiling:¶

• the irreversible, external-commitment, or privileged-administration class;¶

• authority satisfying the runtime profile's external-communication predicate, the exfiltration leg ([I-D.draft-mcguinness-mission-runtime]); or¶

• cross-domain authority.¶

This is the prohibited set the progressive profile holds back from policy adjudication ([I-D.draft-mcguinness-oauth-mission-progressive]), applied here to dispatch. To make the rule testable, a deployment MUST publish in the Mission Deployment Profile a mapping from its action identifiers to the runtime profile's action classes ([I-D.draft-mcguinness-mission-runtime]), or an equivalent declared classification.¶

The deployment's configured dispatch-prohibited action set MUST cover every action the published mapping classifies as irreversible, external-commitment, or privileged-administration, as satisfying the runtime profile's external-communication predicate ([I-D.draft-mcguinness-mission-runtime]), or as cross-domain. A configured set narrower than the mapping is nonconformant: it lets a Dispatch confer a class the deployment's own mapping already identifies as prohibited, which is exactly the outcome this section forbids.¶

A Dispatch that would grant a prohibited class is refused with dispatch_prohibited_class (Section 9). Unlike the progressive profile, which falls back to a fresh human approval in band, a Dispatch has no interactive surface to escalate on: the human path is an ordinary Mission created through a fresh approval ([I-D.draft-mcguinness-oauth-mission]), requested out of band. The Dispatch Policy MUST NOT dispatch a Mission bearing a prohibited class.¶

9. The Denial Reasons

This document defines a closed set of dispatch denial reasons, carried in the shared mission_denial_reason member that the expansion profile established for adjudication denials ([I-D.draft-mcguinness-oauth-mission-expansion]):¶

out_of_template_ceiling:

The dispatched instance's Authority Set is not within the Template Ceiling (Section 7), so it cannot be instantiated by policy. Raising the ceiling requires a fresh human template consent.¶

dispatch_prohibited_class:

The dispatched instance would grant a high-consequence class (Section 8), which a Dispatch never auto-approves. The authority is available only through a fresh human approval.¶

A consumer that does not implement this document treats either value as it treats any unrecognized reason code: the Dispatch stays denied, with no further semantics.¶

10. Instance Composition

A dispatched Mission is an ordinary Mission. Nothing about its origin makes it special to the rest of the family; the template bounded its creation and then steps out of the way.¶

• Containable. A dispatched Mission is subject to Mission Containment ([I-D.draft-mcguinness-oauth-mission-containment]): its effective authority can be narrowed by event-triggered containment exactly as any Mission's can.¶

• Continuable. A dispatched Mission's work continues under the continuation profile's transports ([I-D.draft-mcguinness-oauth-mission-continuation]). Async delegation is the natural scheduled-dispatch path: a scheduled run dispatches an instance and carries it forward on that transport.¶

• Expandable, but not by the template. A dispatched Mission MAY be expanded through a human-approved expansion ([I-D.draft-mcguinness-oauth-mission-expansion]). Such an expansion is not bound by the Template Ceiling: it is a fresh human consent that supersedes the instance, and its successor derives its authority from that new approval, not from the template. The successor therefore MUST NOT carry the template lineage member (Section 7.1): it was not dispatched, and an auditor re-running the ceiling check (Section 11) MUST NOT be led to test a freshly consented successor against the template.¶

• Child-delegable within the ceiling. A dispatched Mission MAY create Child Missions ([I-D.draft-mcguinness-oauth-mission-child-delegation]). As a consequence of the child-delegation profile's strict-subset rule, a Child Mission is a strict subset of the instance's Authority Set, which is itself within the Template Ceiling, so the whole delegation tree stays within the ceiling without any new rule here.¶

11. Audit Linkage

A dispatched Mission is re-checkable in audit with no per-dispatch human in the record, because the human is at the template. For a dispatched Mission an authorized auditor can:¶

• recompute template_hash, the envelope anchor of Section 5.1, from the stored Mission Template object and match it to the committed anchor the template-creation consent evidence carries in its source_hashes ([I-D.draft-mcguinness-oauth-mission-consent-evidence]; that disclosure's own rendering_template_digest commits the rendering template, a different object) and to the instance's template lineage member (Section 7.1), so the ceiling the instance was checked against is the one the human consented to;¶

• re-run the subset check of the instance's Authority Set against the Template Ceiling (Section 7), confirming the instance is within the ceiling;¶

• recompute the instance's effective expires_at as the minimum of the dispatch intent's requested expires_at, the committed created_at plus instance_lifetime, and the template's expires_at (Section 7), and match it to the recorded value, so the granted lifetime is exactly the three-way clamp; and¶

• verify that the instance's approver equals the template's approver at the recorded template_version, so the accountable principal is the human who consented to that version of the template.¶

Each Dispatch MUST record the Dispatch Policy id and version that instantiated the Mission, and the dispatch event identifier (Section 7), so the policy chain the architecture's Approve verb requires stays re-checkable ([I-D.draft-mcguinness-mission-architecture]). A deployment MUST retain the consented template, template_hash, and dispatch records for each instance's audit horizon ([I-D.draft-mcguinness-oauth-mission]), so every dispatch is verifiable to have stayed within the consented template.¶

12. Security Considerations

The issuance profile's security considerations apply in full. This document adds the dispatch surface.¶

• Standing consent decays. A template consented once and dispatched from indefinitely is a standing grant with a calendar. The bounds (instance_lifetime, max_active, dispatch_rate) cap breadth and rate, not duration; the review_cadence (Section 6) is the temporal bound, and dispatch stops past it until a human re-consents. The tells of decay are checkable from the dispatch record: reviews that never narrow the ceiling, ceilings that only grow, and a dispatch_rate raised without a task that needs it. A review that cannot cite the cycle it renews has not reviewed it.¶

• A compromised Dispatcher is bounded. A Dispatcher is authenticated and is not an Approver: it can trigger instantiation only within the template a human approved. A compromised Dispatcher cannot exceed the Template Ceiling (double intersection, Section 7), cannot dispatch a high-consequence class (Section 8), and cannot outrun max_active or dispatch_rate. Its blast radius is therefore bounded to no more than the human consented to when approving the template, and every instance it dispatched is independently gated, revocable, and enforced per action by the runtime layer ([I-D.draft-mcguinness-mission-runtime]).¶

• The Dispatch Policy is authority-bearing governance. A misconfigured policy can over-instantiate within the ceiling, so it is reviewed and versioned like other approval policy, and its id and version are part of every dispatch record (Section 11).¶

• The template bounds, and does not eliminate, standing exposure. A deployment SHOULD pair a Mission Template with short instance_lifetime values, constraint-bounded ceilings, and runtime enforcement, so the authority any single dispatched Mission actively holds stays narrow.¶

13. Privacy Considerations

The Template Ceiling discloses, at template-consent time, the full envelope every future dispatch may draw within, which can reveal more about the anticipated recurring task than any single dispatched Mission's Authority Set. The template lineage member correlates every instance dispatched from one template across distinct Missions. Access to the template, its ceiling, and the dispatch records SHOULD be scoped to parties with a governance need. The issuance profile's Mission Identifier correlation considerations apply to each dispatched Mission.¶

14. Conformance

A Mission Issuer that claims Dispatch from a Mission Template is a conforming issuance-profile Mission Issuer ([I-D.draft-mcguinness-oauth-mission]) and MUST:¶

• record a consented Mission Template with the required members and commit it under template_hash with typ mission-template (Section 5, Section 5.1), and treat template creation as a human approval event whose disclosure renders the ceiling, the no-per-instance-approval fact, and the prohibited-class reservation (Section 6);¶

• adjudicate a Dispatch in the order of Section 7: authenticate and authorize the Dispatcher, derive the instance Authority Set, double-intersect it with the derivation-policy ceiling and the Template Ceiling, apply the prohibited-class check, enforce the bounds, and commit an ordinary Mission whose approver is the template's human approver and whose anchors are over the instance's own Intent and Authority Set;¶

• record every dispatched Mission's approval_basis with type: "template": consent_principal the template's human approver, activation the template lineage and this Dispatch's dispatch_event_id, activation_actor the Dispatcher, and root_commitment the template_hash (Section 7);¶

• refuse a Dispatch outside the ceiling with out_of_template_ceiling and a Dispatch of a prohibited class with dispatch_prohibited_class (Section 9);¶

• make every Dispatch idempotent per dispatch event identifier (Section 7);¶

• answer a Dispatch in one authenticated back-channel round trip, using no PAR, no interactive consent surface, and never authorization_pending (Section 7);¶

• record the template lineage member on the dispatched Mission (Section 7.1);¶

• stop dispatch past the published review_cadence until a fresh human approval (Section 6); and¶

• publish the bounds and the action-class mapping in the Mission Deployment Profile (Section 5, Section 8) and retain the audit linkage of Section 11.¶

A Resource Server requires no new behavior: it enforces a dispatched Mission's tokens exactly as it enforces any Mission-bound token, and treats the template member, if it reads it at all, as audit context it MUST NOT use to grant authority (Section 7.1).¶

15. IANA Considerations

This document requests registration of the following value in the "OAuth URI" registry established by [RFC6755]:¶

URN:

urn:ietf:params:oauth:grant-type:mission-dispatch¶

Common Name:

Mission Dispatch Grant Type¶

Change Controller:

IETF¶

Specification Document:

this document, Section 7.2¶

This is a proposed registration. The value is used under the reserved urn:ietf:params:oauth arc by implementations of this document in advance of registration completing; this document is the specification that names and defines it.¶

Beyond that registration, this document requests no further IANA action. Following the restraint of the sibling profiles:¶

• template_hash is a Mission integrity anchor whose typ, mission-template, follows the issuance profile's collision-resistant typ convention ([I-D.draft-mcguinness-oauth-mission]) and requires no registration;¶

• the template member of the mission claim (Section 7.1) is carried inside the already-open mission claim and needs no separate registration;¶

• out_of_template_ceiling and dispatch_prohibited_class are requested as registrations in the expansion profile's Mission Denial Reasons registry ([I-D.draft-mcguinness-oauth-mission-expansion]), each with its semantics as defined in this document and Reference this document; and¶

• the Mission Template's type identifier, application/mission-template+json, is used by local agreement pending registration; an audit or transparency profile registers the object by that value.¶

16. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 work and expresses, in family terms, a define-a-template-once, dispatch-per-run lifecycle: one considered human consent to a ceiling in place of a fresh approval at every machine-speed run.¶

Author's Address