Web Authorization Protocol K. McGuinness Internet-Draft Independent Intended status: Standards Track 27 September 2026 Expires: 31 March 2027 Mission-Bound Authorization for OAuth 2.0 draft-mcguinness-oauth-mission-latest Abstract An AI agent is typically given a mission: a task to pursue on a user's behalf. OAuth 2.0 issues access tokens for individual resource requests, but it has no durable, approved artifact that ties those tokens to the one task a user actually authorized. As a result, an agent's authority is a collection of independently obtained tokens with no shared, auditable boundary, and a user's approval is disconnected from what the agent later does. This document defines a Mission: a structured, explicitly approved, integrity-bound authorization artifact for OAuth 2.0. A client submits a Mission Intent through Pushed Authorization Requests; the Authorization Server derives Rich Authorization Requests authorization details from it, binds the approved task and its derived authority to the Approver's consent through integrity anchors, and records a durable Mission. Every access token derived under the Mission carries that authority and a "mission" claim, and issuance is gated on the Mission's lifecycle state. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. This is the issuance and governance "mission layer" left unspecified by agent-identity work for OAuth; runtime enforcement of each action is a separate, optional layer. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-oauth-mission.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness- oauth-mission/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 31 March 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 1.1. Why a New Object 1.2. Relationship to Adjacent Work 1.3. The Mission, the Plan, and Execution 1.4. Applicability 1.5. Scope and Future Work 1.6. Non-Goals 2. Conventions and Terminology 3. Overview 3.1. Principal Model 3.2. Protocol Flow 3.3. Authority Sources 4. Mission Intent 4.1. Submission via PAR 4.2. The Authority Proposal 4.3. Intent Submission Evidence 4.4. Submission Processing Order 5. Mission Authority 5.1. Subset Rule 5.2. Authorization Details Types 6. Mission Approval 6.1. Approver Authentication Strength 6.2. Binding the Mission to the Grant 6.3. Single Accountable Approver 7. Integrity and Commitments 7.1. Integrity Anchors 7.2. Canonicalization Rules 7.3. Commitment Mechanisms 8. Mission Record 8.1. Role Mapping 8.2. Mission Identifier Format 8.3. Worked Example 9. Mission-Bound Access Tokens 9.1. Scope Projection 9.2. The Mission Claim 9.3. Resource Server Enforcement 9.4. Local Approved-Set Verification 9.4.1. Authenticated Complete-Set Retrieval 9.4.2. A Typed Selective-Inclusion Proof: a Future Composition Point 9.5. Remediation Grains 9.6. Error and Challenge Mapping 10. Mission Lifecycle and Gating 10.1. Derivation Issuance Policy 10.2. Issuance Gating 10.3. Revocation 11. Mission State via Token Introspection 11.1. Caller Authorization and Minimization 11.2. Composite Active State 11.3. Only the Issuer Reports Mission State 11.4. Introspected Token Consumption 11.5. Examples 12. Delegation Within a Mission 12.1. Adopted Model: client_id Names the Requesting Client 12.2. Self-Exchange Down-Scoping 12.3. Delegation Constraints 12.4. Worked Example: Delegated Token 13. Extensibility 13.1. Namespace Taxonomy 14. Authorization Server Metadata 15. Protected Resource Metadata 16. Conformance 17. Security Considerations 17.1. Commitment and Consent Integrity 17.1.1. Consent Binding 17.1.2. Downgrade by Omission 17.2. Agent-Specific Threats 17.2.1. Prompt Injection and the Exfiltration Leg 17.2.2. Authority Does Not Propagate With Information 17.3. Enforcement Boundaries 17.3.1. Issuance Scope, Not Runtime Enforcement 17.3.2. Denial Detail Disclosure 17.4. Credentials and Delegation 17.4.1. Token Theft 17.4.2. Delegation and Chain Compromise 17.4.3. client_id Conformance and the Approved-Agent Residual 17.4.4. Signing and Key Rotation 17.5. Composition and Residual Authority 17.5.1. Compromised or Over-Broad Derivation 17.5.2. Authority Hash Is Not a Mission Identifier 17.5.3. Composition and the Effective Ceiling 17.5.4. The Containment Materialized-Capability Residual 18. Internationalization Considerations 19. Privacy Considerations 19.1. Mission Identifier Correlation 19.2. Token Payload Disclosure 19.3. Intent Retention and Anchor Disclosure 19.4. Third-Party Data Subjects 19.5. Mission Record and Evidence Access 20. IANA Considerations 20.1. OAuth Parameters Registration 20.2. OAuth Extensions Error Registration 20.3. JSON Web Token Claims Registration 20.4. OAuth Token Introspection Response Registration 20.5. OAuth Authorization Server Metadata Registration 20.6. OAuth Protected Resource Metadata Registration 20.7. Mission Lifecycle States Registry 20.8. Mission Intent Members Registry 21. References 21.1. Normative References 21.2. Informative References Appendix A. End-to-End Example (Non-Normative) A.1. Stage 0: Agent Identity (by Reference) A.2. Stage 1: Mission Creation A.3. Stage 2: Mission-Bound Token Issuance A.4. Stage 3: The Resource Server Enforces Appendix B. Derivation Policy (Non-Normative) B.1. The Policy as an Artifact B.2. Properties a Derivation Policy Holds B.3. A Worked Rule B.4. Fixtures and Authoring Discipline B.5. Ownership and Operational Signals Appendix C. Integrity Anchor Test Vectors Appendix D. OAuth Binding Mapping Assessment Appendix E. Document History Acknowledgments Author's Address 1. Introduction Agent-identity work such as [I-D.draft-klrc-aiagent-auth] establishes how an AI agent authenticates and how a user delegates authority to it: the agent is an OAuth 2.0 [RFC6749] client identified by client_id, the delegating user is the access token sub, and the agent obtains tokens for the resources its task requires. That work deliberately leaves three things out of scope: how an agent's task (its "mission") is translated into authorization, how a user's approval of that task is captured as a durable artifact, and how later token issuance stays bound to what the user approved. Without that layer the gap is invisible to every individual OAuth component. Each token is individually valid and each request individually in scope, yet nothing checks whether the task the user approved is still the one being pursued. A token issued for a task remains usable after the user's approval has lapsed or been withdrawn, because no OAuth object ties the token's validity to the task's authorization: the credential stays secure while the work it authorizes has quietly become unauthorized. This document specifies that missing layer. It defines a *Mission*: a structured, explicitly approved, integrity-bound OAuth authorization artifact. The contribution is a single chain: 1. The client submits a structured *Mission Intent* describing the task (goal, target resources, task bounds) instead of requesting raw scopes, optionally proposing concrete authority alongside it as standard authorization_details. 2. The Authorization Server (AS) derives *authorization details* ([RFC9396]), the *Authority Set*: the concrete authority the task needs. 3. At an *approval event*, the Approver consents to that authority, and the AS commits the task as an *intent_hash* and the authority as an *authority_hash* and records a durable *Mission*. 4. Every access token the agent obtains under the Mission carries the derived authorization details and a *mission claim* identifying the Mission (id, issuer) it was derived under. A Resource Server enforces statelessly from the token. 5. Token issuance and refresh are *gated on Mission state*, so revoking or expiring the Mission stops the agent from obtaining further authority. The result is that a user approves a task once, and that approval, not a per-request scope grant, bounds and outlives every token the agent derives. The consented authority is committed once, as authority_hash, on the Mission record; a party holding the full Authority Set can independently verify it, and a deployment that needs that verification from a token holding only a narrowed subset adopts the Local Approved-Set Verification profile (Section 9.4, Section 17.1.1). This chain is the first of two deliberate enforcement layers. It gives task-bound issuance, auditability, and a revocation gate over future derivation, which is sufficient for a low-risk workflow whose exposure is bounded by short token lifetimes and narrow authority. It does not evaluate individual actions: an agent taking consequential autonomous actions needs the second layer, the runtime enforcement chokepoint (Section 17.3.1), specified separately. A deployment chooses its layers deliberately, matching the enforcement it runs to the consequence of what its agents do; the Mission Assurance Levels of [I-D.draft-mcguinness-mission-architecture] name the composed levels informatively. 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.3). 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.3). 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 deliberately lets any party holding a token correlate a Mission's activity across audiences and resources. This is a design choice, not an omission: a stable, correlatable identifier 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. authority_hash is no longer part of that baseline correlation surface: it stays on the Mission record and the audit and profile surfaces that carry it by disclosure privilege (Section 9.2), rather than traveling by default on every token. Pairwise or unlinkable presentation of Mission-bound authority works against the identifier and is therefore future work (Section 19.1). 2. 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. Agent (Client): The OAuth client acting for the Mission's Subject, identified by client_id. Agent identity is established per [I-D.draft-klrc-aiagent-auth] or ordinary OAuth client authentication. Subject: The user, workload, or organizational principal on whose behalf the Mission is approved (Section 3.3), identified by an (iss, sub) pair and carried in derived tokens' sub claim. Approver: The single accountable principal who approves the Mission at the approval event. Equal to the Subject for self-approval; different for administrator or delegated approval. This document records one accountable Approver; multi-party approval and the provenance of delegated approval authority are deferred (Section 6.3). Mission Issuer (Authorization Server): The OAuth AS that validates a Mission Intent, runs the approval event, records the Mission, and derives tokens. It is the Mission's issuer. "Mission Issuer", "issuer AS", "originating AS", and "AS" are used interchangeably in this document. Resource AS: An Authorization Server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources; it is never the Mission Issuer. Cross-domain projection is specified by the companion Mission Cross-Domain Projection profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Mission Intent: The structured description of the task the client submits (Section 4). Mission Intent Submission (Submission envelope): The object a client submits as the mission_intent parameter value: the Mission Intent under intent, and Intent Submission Evidence under evidence where any is presented (Section 4.1). Intent Submission Evidence: Typed artifacts a client presents in support of claims about a submitted Mission Intent (Section 4.3): authenticated policy input, never authority. The term names inbound, client-presented material; the evidence this document and companion profiles emit and record (a consent-evidence artifact, an audit evidence base) is issuer- or runtime-produced output, not this. Authority Proposal: The authorization_details array a client submits alongside a Mission Intent, a proposal for derivation and never authority (Section 4.2). Authority Set: The set of authorization_details entries the AS derives from a Mission Intent and the Approver approves (Section 5). "Authority Set" names these concrete entries; it does not mean an identity authority, a trust authority, a legal authority, or an issuing authority. Mission: The durable, immutable record created at the approval event (Section 8), identified by a Mission Identifier (Section 8.2) and, globally, by the pair (issuer, id). A Mission is independent of any OAuth grant (Section 6.2). Mission Grant Binding (Grant Binding): The AS-controlled, functional mapping from one persistent, redeemable grant lineage to exactly one Mission (Section 6.2). A Mission MAY have zero or more grant bindings; a grant binding never resolves to more than one Mission. Distinct from a Derived token's own mission claim, which every issued credential carries without itself creating a grant binding. Mission-referenced token: A token that carries a Mission reference (the mission claim or a mission_id) without Mission-derived authority or any gating guarantee. A reference is never authority. Derived token (Mission-derived token): An access token issued under a Mission, carrying its Mission-derived authority (the full Authority Set or a narrowed subset) as authorization_details and a mission claim (Section 9). Mission-bound token: A Mission-derived access token or refresh token whose issuance and refresh are gated on the Mission's active state and bounded by the subset rule (with refresh tokens bound server- side). Only this class carries this profile's gating guarantee, and this document reserves "Mission-bound" for it; a token that merely references or carries Mission data without the gates is not Mission-bound (Section 16). 3. Overview 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 consent principal whose approval created the Mission, always equal to approval_basis.consent_principal; under a standing-consent basis a policy adjudicates the activation, a mechanism the basis's OPTIONAL discriminated adjudication MAY make explicit (Section 8), while the Approver remains the human whose consent roots it (Section 3.3, Section 6.3). 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. 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.3). The end-to-end example (Appendix A) walks this flow with concrete messages. 3.3. 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). 4. Mission Intent Before the approval event (Section 6) only the Mission Intent exists, as untrusted client input (Section 4.1); after it, only the Mission is authoritative. A Mission Intent therefore has no protocol identifier of its own: two submissions of the same Intent produce two distinct pending requests, and a Mission acquires its Mission Identifier (Section 8.2) only at activation. The approved Intent is recorded on the Mission and committed by intent_hash (Section 7.1); it describes the task and carries no authority members. Concrete authority is proposed separately, on the standard authorization_details parameter pushed alongside the Intent (Section 4.2) and committed by proposal_hash when submitted; the granted authority is committed by authority_hash over the derived Authority Set (Section 5). A Mission Intent is a JSON object describing the task. The client submits it as the intent member of the Mission Intent Submission envelope (Section 4.1), in place of scope or alongside a narrowed scope. It has the following members: goal: REQUIRED. A string. A human-readable statement of the task, for rendering to the Approver. Maximum 4096 characters. Prose here persists on the record and can carry personal data about third parties (Section 19.4). goal_lang: OPTIONAL. A string. A BCP 47 language tag [RFC5646] declaring the language of the Intent's human-readable members (goal, task_bounds, success_criteria). It is disclosure metadata for rendering, committed by intent_hash like every Intent member; it carries no machine semantics and MUST NOT be used to derive, widen, or gate authority. At submission acceptance, the AS MUST refuse a goal_lang that is not a well-formed language tag with invalid_request (Section 18). target_resources: REQUIRED. An array of strings. A client- requested Intent ceiling on the task's target resources, each an absolute URI identifying a protected resource (an OAuth resource per [RFC8707]-style indicators or a Protected Resource per [RFC9728]). It is not RFC 8707 resource carriage: it bounds which resources a derived Authority Set entry may name (Section 5) and serves as a configured-mapping lookup key, but a client separately requests the audience of a given token with the standard resource parameter (Section 9). task_bounds: OPTIONAL. An array of strings. Human-readable bounds on the task (for example, "read only invoices from 2026"). They are disclosure and audit context, rendered to the Approver beside the derived Authority Set (Section 6); the AS MUST NOT parse them for machine semantics, and a machine-enforceable bound enters as structure instead (Section 5). success_criteria: OPTIONAL. An array of strings. Human-readable observable outcomes that indicate the task is complete. These are disclosure and audit material only: they are rendered to the Approver and committed by intent_hash (Section 7.1), but carry no machine semantics and MUST NOT be used to derive, widen, or gate authority. purpose: OPTIONAL. A string. A URI identifying the purpose of the task, recorded for disclosure and audit. Its semantics are deployment- or registry-defined and opaque to this document. It is a structured, opaque lookup key permitted only for configured- mapping-mode selection: the configured mapping MAY key on it (Section 5), and the derived set stays bounded by the Intent and by policy like any derivation. It MUST NOT otherwise be used to derive, widen, or gate authority, and once the Mission is approved it is inert. A deployment MAY consult it for out-of-band policy or logging that does not affect the authority derived here. expires_at: REQUIRED. A string. An RFC 3339 [RFC3339] date-time: the client's requested not-after ceiling for the Mission's lifetime. The submitted Intent is recorded verbatim; the lifetime actually granted is the Mission Record's effective expires_at, which MUST NOT be later than this value (Section 8). An AS or Mission-creating profile MAY grant a shorter lifetime under applicable policy or an already-approved bound; a longer one requires a new submitted value through a creation or fresh- approval path that authorizes it. At submission acceptance, the AS MUST refuse a malformed or already-past value with invalid_request (the member rides mission_intent, and the request may carry no authorization_details for an invalid_authorization_details refusal to describe); acceptance does not freeze time, and Mission creation re-checks the effective expiry atomically at the commit (Section 6). Submission acceptance governs a new operation; a request that resolves to an already-committed operation is recovery and returns the stored outcome under the applicable idempotency rules even when the requested ceiling has since passed (Section 6.2). requested_derivation_limit: OPTIONAL. A positive integer (1 or greater). A client-requested ceiling on the number of derivations the issuer AS performs under the Mission. A value of 0 is invalid (it would forbid even the initial issuance); to stop a Mission, revoke it (Section 10.3). An AS MUST reject a value below 1 with invalid_request. This member is a request only: the AS- established effective ceiling, its omission semantics, its rendering, and its enforcement are defined once, in Section 10.1. This document defines no Agent Deployment Binding. Pinning a Mission to an approved agent deployment class or version, and verifying at every derivation that the presenting instance belongs to it, needs two distinct objects (a committed approval-context pin, and presenter-instance evidence checked at issuance), not a single machine-actionable Intent member, and this document reserves no Intent member for either. A profile that defines this binding owns: the request carriage for the pin; its resolution to an AS-approved deployment identifier; the immutable Mission Record extension and its approval rendering; the instance assertion or attestation format and the presenter-binding check performed at every derivation, building where useful on the client-instance-assertion family ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]); and fail-closed behavior when the binding is requested but the client cannot prove it. No such profile is defined in this document series today. This document defines no cumulative consumption bounds (for example, a budget, call-count, or activity-duration cap): every bound this document defines is enforced by a party this document names. An experimental companion defines cumulative consumption bounds as explicit Mission Intent extension members together with the runtime metering that enforces them ([I-D.draft-mcguinness-mission-metering]). The following table summarizes which party enforces each bound a Mission carries and what holds when that enforcer is absent: +================+======================================================+=============+ |Bound |Enforced by |When that | | | |enforcer is | | | |absent | +================+======================================================+=============+ |resource and |any Resource Server that enforces |a scope-only | |actions |mission_resource_access per its type specification |RS is served | | |([I-D.draft-mcguinness-oauth-mission-resource-access],|only where | | |Section 9.3) |the AS | | | |established a| | | |safe scope | | | |projection | | | |(Section | | | |9.1); the AS | | | |refuses | | | |issuance to | | | |it otherwise | +----------------+------------------------------------------------------+-------------+ |per-entry |a Resource Server that understands and enforces the |a Mission- | |constraints |key, per that type's specification |aware RS | | |([I-D.draft-mcguinness-oauth-mission-resource-access],|fails closed;| | |Section 9.3) |a scope-only | | | |RS is served | | | |only where | | | |the | | | |projection | | | |independently| | | |accounts for | | | |the | | | |constraint | | | |(Section 9.1)| +----------------+------------------------------------------------------+-------------+ |derivation_limit|the issuer AS at each derivation (Section 10.1, |never absent | | |Section 10.2) |at the issuer| | | |when | | | |established; | | | |it does not | | | |bound another| | | |domain's | | | |local minting| | | |(see the | | | |cross-domain | | | |companion) | +----------------+------------------------------------------------------+-------------+ Table 1 The Approver's authentication strength for the approval event is requested at the OAuth layer, not on the Intent: the direct flow carries it, where a client requests one, on the standard acr_values and max_age authorization-request parameters (Section 6.1). It is not a Mission Intent member. The Mission Intent's top level is closed to the members above; a companion profile MAY add further top-level members, under Section 13. Example Mission Intent: { "goal": "Reconcile Q3 invoices and post adjustments under $500.", "target_resources": ["https://erp.example.com"], "task_bounds": [ "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", "requested_derivation_limit": 200 } 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 neither this document nor a companion profile the AS implements defines (Section 13); presented evidence belongs under the envelope's evidence member, so deployment- or companion- defined semantics are always 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, and its error code follows which object failed* (Section 9.6 states this mapping normatively). For an Intent that is well-formed but yields no valid Authority Set, the failing object determines the code. Where the client submitted an authority proposal (Section 4.2) and an entry of it is unsupported or policy-barred, the AS SHOULD refuse with invalid_authorization_details ([RFC9396]), since an actual authorization_details object is what failed. In configured-mapping mode, where no proposal was submitted and the Mission Intent alone yields no valid Authority Set (no configured mapping matches, or policy bars the mapped authority), the AS refuses with access_denied (Section 5): no authorization_details object exists for invalid_authorization_details to describe. Either way a client can tell a syntax error, refused at parse, from a derivation failure, refused after validation. * *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.", "target_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 supported type (Section 5.2, Section 14) and MUST validate against that type's documented definition; where a machine-readable JSON Schema for the type is advertised (Section 14) or established out of band, the entry MUST also validate against that schema. This is the [RFC9396] Section 5 validation of the standard parameter: the AS MUST refuse a request carrying an entry of an unsupported type, or an entry that fails its type's documented definition or applicable 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_: an entry 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.2). No entry derives from a proposed entry of a different type. goal and task_bounds then serve as rendering and bounding context over the proposed authority. Each proposed entry that carries a resource member MUST have it among the Intent's target_resources; 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 task bounds, 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. Mission Authority From the Mission Intent, and from the authority proposal where one was submitted (Section 4.2), the AS derives the *Authority Set*: one or more [RFC9396] authorization_details entries of an AS-supported type (Section 5.2). Derivation is mechanical. It happens once, at the approval event, over the derivation policy then in force, in one of two modes: * *Narrowing mode* (RECOMMENDED): the client submitted an authority proposal (Section 4.2), and the Authority Set is the proposal narrowed to policy. Each derived entry MUST be a subset (Section 5.1) of some proposed entry of the same type (Section 4.2). An entry of an unadvertised type, or one that fails its schema, was refused at validation and never reaches derivation (Section 4.2); a valid proposed entry that policy cannot accept is narrowed or omitted, and the granted echo reflects it (Section 4.2). * *Configured-mapping mode*: no authority proposal was submitted, and a deployment-configured mapping, keyed on the Intent's purpose or target_resources, yields the candidate entries, which are then narrowed to policy. The mapping is a lookup, never synthesis; because no authorization_details object was submitted, the AS refuses an Intent that matches no configured mapping, or whose mapped candidates policy narrows to nothing, with access_denied (Section 9.6), and SHOULD make a no-match refusal distinguishable from a policy-narrowing refusal in error_description. A deployment publishes its mapping space as deployment documentation; eligibility MAY be scoped per Subject and client, and a mapping keyed on Subject attributes resolves at the approval event, where the Subject is established (Section 6), so a refusal at PAR time is best-effort over what is checkable without the Subject. Configured-mapping mode is the low-integration on-ramp: the client submits a Mission Intent and no authorization_details proposal at all, so an estate adopts Mission governance without teaching clients RAR authoring, and the client-side cost is the Intent envelope alone. Every Mission this mode yields still takes its own fresh approval; standing consent to a pre-approved ceiling with machine-speed dispatch is the separate, experimental Mission Template profile ([I-D.draft-mcguinness-oauth-mission-template]), not this mode. In both modes the AS MUST bound every derived entry by the Mission Intent: each derived entry that carries a resource member MUST have it among the Intent's target_resources values. In both modes the AS MUST also record the policy version in force as the Mission's policy_version: an opaque audit correlator naming the policy a derivation ran under, not a value whose policy travels. Deriving authority generatively, with model assistance over the structured inputs above, is not one of this profile's modes: a deployment MAY implement it as a local-policy extension, it is the least portable option, and the Intent bounds, the prose boundary below, and the recording rule above all apply to it unchanged. A target_resources entry the deployment does not recognize either causes refusal under the derivation-failure rule above (Section 4.1) or is omitted from the Authority Set, by deployment policy. When an omission or a narrowing leaves the Authority Set short of what was proposed (Section 4.2), derivation is partial. The granted authorization_details echo (Section 9) MUST reflect every omission and narrowing and remains the authoritative statement of what was granted; a client learns of any shortfall by comparing the echo against its proposal, which proposal_hash commits as submitted (Section 7.1). No omitted or narrowed entry is ever represented as granted. The derived Authority Set, not the Mission Intent, is the authority the Approver consents to: the AS renders the Authority Set for approval and commits it as authority_hash (Section 6). The Intent's members describe and bound the task but grant no authority by themselves (Section 4): its structured members constrain what the AS MAY derive mechanically, its prose members bound through disclosure (the Approver refuses authority the words do not support), and none widens. The goal, task_bounds, and success_criteria members are human- readable disclosure and audit context. The AS MUST NOT parse them for machine semantics or vary the derived Authority Set on an interpretation of their prose; translating a user's words into structure is the shaper's job, before admission and outside the trust boundary ([I-D.draft-mcguinness-mission-shaping]). A client-proposed constraint on an individual Authority Set entry enters through the top-level authorization_details proposal: constraints a supported type's specification defines (for example, the Common Constraints the Mission Resource Access Profile defines for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]), and the collision-resistant deployment extensions the AS understands (Section 13). Authority is further bounded by the Intent's structured members (target_resources, expires_at), by the template mapping keyed on purpose or target_resources (a lookup over structured values yielding structured candidate entries, never an interpretation of prose), and by local policy and eligibility. The approval surface renders the prose beside the derived Authority Set (Section 6): the human check that the structure matches the words, never a machine enforcement mechanism. Derivation is governed by local policy and is not a portable algorithm: different Authorization Servers MAY derive different Authority Sets from the same Mission Intent, exactly as different deployments grant different authority for the same [RFC9396] request or the same scope. That locality is intended, not a gap. A Mission Intent has no portable semantics: interoperability begins at the committed result, the derived Authority Set's structure and vocabulary, as each supported type defines it (Section 5, Section 5.2), and its integrity anchors (Section 7.1), which a consumer in any domain interprets, enforces, and audits identically. A consumer enforces the derived Authority Set, never the Intent, and audit establishes what was derived, against intent_hash and policy_version, never whether the derivation was the right reading of the task. A deployment whose partners reason about its derivations SHOULD publish a derivation policy identifier and test fixtures pinning Intent-to-Authority-Set outcomes; the policy itself does not travel. For an open-ended task whose concrete objects cannot be enumerated at approval (for example, "reconcile this customer's ledger," where the individual invoices are not yet known), the AS SHOULD bound the derived authority primarily by constraints that hold as invariants over those objects (the owning customer, the tenant, an amount ceiling, read-only except named write actions, a validity window) rather than by an exhaustive resource enumeration. The runtime layer (Section 17.3.1) checks each concrete object against the constraint at the point of use. Constraint-bounding lets a Mission cover an open-ended task with tight authority even though the specific objects are unknown at approval, and avoids the over-broad enumeration a deployment would otherwise need in order to anticipate them. mission_resource_access is an [RFC9396] authorization_details type: a cross-resource authorization language matching a resource exactly or by prefix, an action namespace with wildcard families, generic per- entry constraints (including the Common Constraints, Section 5.2), and a delegation policy, together with the subset and intersection algebra that compares two entries. It is defined, in full, by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]), a companion of this document; the Authority Set MAY carry mission_resource_access entries, or entries of any other AS-supported type, on the same type- agnostic terms (Section 5.2). Example Authority Set (the read entry is delegable to depth 2 and bounded to a Q3 issuance window by the resource_issued_after and resource_issued_before Common Constraints ([I-D.draft-mcguinness-oauth-mission-resource-access]); the write entry carries no delegation and so is non-delegable, because delegation is per entry): [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"], "constraints": { "resource_issued_after": "2026-07-01T00:00:00Z", "resource_issued_before": "2026-09-30T23:59:59Z" }, "delegation": { "max_depth": 2, "allowed_delegates": [{ "sub_profile": "ai_agent" }] } }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount": { "amount": "500.00", "currency": "USD" } } } ] 5.1. Subset Rule A derived authorization_details entry is a subset of a reference entry when it is no broader under the subset relation the entry's own type defines; Section 5.2 states the general rule and each supported type defines its own relation (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]). The AS MUST refuse to derive an entry that is not a subset, under its type's relation, of some Mission Authority Set entry. 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]. 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. Authorization Details Types The Authority Set MAY include any AS-supported [RFC9396] authorization_details type an audience consumes; this document defines no type itself. ("Supported" here means the AS recognizes and documents the type: it appears in authorization_details_types_supported or, where the AS advertises the schema endpoint, as a key in its authorization_details_types_metadata_endpoint response, then the source of truth for the supported set (Section 14). RFC 9396 establishes no IANA registry of type identifiers.) The Mission apparatus is type-agnostic toward every supported type: * an entry is committed by authority_hash and gated on Mission state the same way regardless of type; * narrowing and delegation use the subset 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, alongside a general- purpose type such as mission_resource_access ([I-D.draft-mcguinness-oauth-mission-resource-access]). 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 for a type whose specification defines it. Authority expressed in a type with no defined subset relation is carried as approved: never narrowed, delegated, or projected. That boundary is declared per type, not discovered at a refused derivation. For every supported type, the AS MUST declare three independent capabilities: whether it understands the type's subset relation (narrowing), whether it understands the type's delegation semantics (delegation), and whether it establishes a safe scope projection for the type (Section 9.1) (projection); understanding one establishes none of the others. A type undeclared on a capability is thereby carried-as-approved on it: non-delegable if delegation is undeclared, non-projectable to scope if projection is undeclared. The AS satisfies this MUST through, in order of preference: a mission_transformation_capabilities member in the type's entry in the authorization_details_types_metadata_endpoint response, where the AS advertises that endpoint (Section 14); an equivalently-shaped member of its supported-type documentation; or, where neither carrier is implemented, deployment documentation naming the type as supported (Section 14) alone. Deployment documentation is always a sufficient carrier; a machine-readable carrier is additive, not a replacement for it. The narrowing guarantee is therefore strongest for a type whose specification defines a subset relation, such as mission_resource_access, and weakens as expressiveness moves into opaque policy-language entries. A mission_transformation_capabilities value is a JSON object with three OPTIONAL boolean members, narrowing, delegation, and projection; an absent member declares that capability undeclared by this carrier, falling through to the next carrier in the preference order above. 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. For example, invoking a Model Context Protocol tool or a function call is modeled as a mission_resource_access entry with no separate type; the mapping is specified in [I-D.draft-mcguinness-oauth-mission-resource-access]. 6. Mission Approval The approval event is the atomic transition at which the Approver consents and the AS creates the Mission. It runs as an OAuth 2.0 [RFC6749] authorization-code flow initiated from the PAR-issued request_uri (Section 4.1). Because the authorization code is the artifact the Mission grant binds to (Section 6.2) and it travels the front channel, the AS MUST bind the code to the requesting client with PKCE ([RFC7636], S256 challenge method) or, equivalently, issue a DPoP-bound authorization code ([RFC9449]). The AS MUST reject a code redemption whose PKCE verifier or DPoP key does not match the binding established for the request. This prevents authorization- code injection from yielding the Mission grant. The AS SHOULD include the iss authorization-response parameter ([RFC9207]) on the authorization response, so the client can detect a mix-up attack on the consent-bearing redirect leg (per the guidance of [RFC9700]). At the approval event the AS MUST, in order: 1. Authenticate the Approver, subject to the approval-authentication floor and any client-requested strength (Section 6.1). The AS MUST NOT take the Approver's identity or achieved authentication context from unauthenticated client input; the authenticated surface that resolved the approval establishes both. 2. Establish the Subject: the principal the task is for, recorded as the Mission's subject and mapped to the sub of every derived token (Section 9). * *Self-approval.* When the Approver is the Subject (self- approval), this is the authenticated Approver. * When the Approver is a different principal (for example, an administrator or manager approving on a user's behalf), the AS MUST itself establish the Subject's (iss, sub), and MUST authorize the Approver to approve for that Subject under local policy. The AS MUST NOT take the Subject from unauthenticated client input. This document defines no wire parameter for the Subject; how the AS establishes it (administrative selection, a directory, an authenticated reference) is a deployment matter. * *Workload or organizational Subject.* The Subject may be a workload or organizational principal (Section 3.3); its establishment and the mapping below are unchanged. * When the Subject's home issuer (subject.iss) differs from the AS, the AS MUST map the external (subject.iss, subject.sub) pair to an AS-local sub under an injective mapping: one external Subject maps to exactly one AS-local sub, and no two distinct external Subjects map to the same local sub, so a derived token's (iss, sub) pair unambiguously denotes the Subject. Adopting the external sub string verbatim as the local sub is one permitted deployment choice, valid exactly where it collides with no other principal's sub; the injectivity, not the verbatim adoption, is the rule. 3. Establish the authority source: whose authority the approval draws on, recorded as the Mission's authority_source (Section 3.3, Section 8). The AS MUST establish it from trusted configuration or authenticated governance state, never from client assertion. The AS MUST verify the Approver is authorized under local policy to activate the established source, and MUST verify the derived Authority Set lies within that source's authority (for organizational, within the governed policy identified by authority_source.policy). These are distinct checks: an organizational owner may be authorized to activate policy without personally holding every operational permission. The AS MUST refuse when either relationship cannot be established. 4. Establish the effective Mission expiry: the requested intent.expires_at ceiling narrowed by applicable AS policy and any ceiling an applicable Mission-creating profile defines (Section 8). The established value MUST NOT be later than the requested ceiling and MUST be in the future when established. The next step renders exactly this value, and the record commits exactly the rendered value; a change to an applicable policy or ceiling before the commit forces re-establishment and re- rendering before approval. 5. Render for consent the derived Authority Set in human-meaningful terms, with the goal, task_bounds, the effective expires_at (and, when it differs, the requested intent.expires_at, so the Approver sees the narrowing; the approval commits the effective Mission Record while intent_hash commits the verbatim request), and the established derivation_limit (Section 10.1), where one applies, as context: * The object the Approver consents to is the *derived Authority Set*, what the agent may actually do, not the goal or Mission Intent: the authority itself MUST be what is rendered and consented to. An approval surface that renders only the goal, success_criteria, or Mission Intent and not the derived Authority Set does not conform. * When the Approver is not the Subject, the rendering MUST identify the Subject the authority is granted for. * The rendering MUST identify the authority source and, for organizational, the governed policy it draws on (authority_source.policy). A change to the established source before the decision MUST force re-evaluation and re-rendering. * When the client submitted an authority proposal (Section 4.2), the rendering MUST distinguish the entries the client proposed from any narrowing or restructuring the AS applied. The Authority Set, not the Intent, is the consent object because derivation is local policy: nothing commits that the derived authority faithfully reflects the goal the Approver read. 6. Compute the integrity anchors (Section 7.1): authority_hash over the consented Authority Set, intent_hash over the approved Mission Intent, and, when an authority proposal was submitted (Section 4.2), proposal_hash over the submitted authorization_details array. 7. Create the Mission record (Section 8) in the active state, atomically with issuance of the authorization code. The commit MUST verify atomically that the effective expiry is strictly later than the creation instant: acceptance of the submission does not freeze time, and where the requested ceiling passed while the approval was pending, completion creates no Mission. A deferred or relocated approval flow inherits this check at its own creation commit, with the completion error each flow defines. The atomic coupling of the approval decision to authorization-code issuance is this flow's shape, not the model's: a companion profile ([I-D.draft-mcguinness-oauth-mission-approval]) relocates the approval event for deployments whose approvals are asynchronous or reviewer-narrowed, under the extension seam of Section 13; the steps above, their order, and the atomicity of record creation with the approval decision are what any relocation preserves. Every Mission is rooted in an approved authorization basis (Section 8): the steps above define the direct basis, which MUST be a human approval event. A companion profile MAY define a named standing-consent basis instead (a template ceiling, a drawdown policy), so a policy can approve an instance at machine speed within a bound a human already consented to; such a basis MUST still trace to an accountable human through approval_basis.consent_principal and root_commitment, and creates no fresh approval event per instance. The consent rendering is hardened against client text: * Client-supplied strings (goal, task_bounds, success_criteria) MUST be rendered as inert text and MUST NOT be interpreted as markup. * The AS SHOULD mitigate Unicode direction-override and confusable- character presentation in them. * The rendering MUST visually distinguish the AS-derived Authority Set from client-supplied text, so crafted client text cannot pass as derived authority. A deployment MUST publish a statement declaring the minimum approval- authentication strength it enforces for Missions whose derived Authority Set carries high-risk authority: irreversible, external- commitment, or privileged-administration actions under the deployment's classification, or a consumption bound ([I-D.draft-mcguinness-mission-metering]), and the deployment scope to which that declaration applies. This published floor is the AS's own risk-based policy, detailed together with the client-requested form in Section 6.1. The Mission Deployment Profile of [I-D.draft-mcguinness-mission-architecture] names the system-level composition of such statements informatively; this specification requires no particular serialization. The material notices of the consent-evidence profile identify these same high-risk classes ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). An Approver who declines, and an Approver whose authentication does not satisfy Section 6.1's requirements, yield access_denied on the authorization response ([RFC6749]). A token-endpoint resource value outside the Authority Set yields invalid_target ([RFC8707]). Rendering a bound is not the same as enforcing it: a deployment MUST NOT present a rendered bound as enforced when no party enforces it. Which party enforces each bound, and what holds when that enforcer is absent, is summarized in the enforcement table (Section 4). An AS SHOULD make clear to the Approver which rendered bounds its deployment actually enforces, so consent is not given to a limit that binds nowhere. The authority_hash is the *authority commitment*: it commits, by cryptographic digest, exactly the authority the Approver approved. It commits the approved authority, not the way that authority was rendered to the Approver; this profile commits no separate consent disclosure object (see Section 17.1.1). It is recorded on the Mission; the baseline token derived under the Mission does not carry it by default (Section 9.2). A party verifying the carried authority against it independently of the token signature does so under the Local Approved-Set Verification profile (Section 9.4, Section 17.1.1). If the task, the authority proposal, the derived Authority Set, the effective expires_at, or a policy input establishing any of them changes between approval rendering and the approval decision, the AS MUST recompute the affected values and the anchors the Mission records (intent_hash and authority_hash, and proposal_hash where a proposal was submitted) and MUST NOT create the Mission without the Approver's consent to the changed context, each anchor computed over the context actually approved (the approval-event rule of [I-D.draft-mcguinness-mission-substrate], stated here across this document's commitments). Committing the proposal separately keeps the anchors from equivocating: a proposal swapped between rendering and decision changes proposal_hash even where intent_hash is unchanged. The intent_hash commits the *approved Mission Intent*: the task the Approver consented to, as recorded on the Mission. It makes the recorded task tamper-evident: an auditor can verify the Mission's intent against intent_hash and detect any later alteration. intent_hash commits the task; authority_hash commits the authority derived from it. 6.1. Approver Authentication Strength A deployment's published approval-authentication floor (Section 6) is its own risk-based policy: it is authoritative and conjunctive with anything a client requests below, and is never narrowed by a client's request. For the direct flow, a client MAY additionally request an approval- authentication strength on the authorization request using the standard acr_values and max_age parameters, defined by [OpenID.Core] Section 3.1.2.1. This profiles their request-carriage syntax only, for a purpose distinct from [RFC9470]'s own exchange: that RFC associates the same parameters with the token's own Subject authentication and has the AS carry the achieved acr/auth_time on the resulting access token; this document uses that exchange unchanged, on its own terms, at Section 9.3, for a Resource Server's challenge against the token-associated user authentication. In a Mission approval interaction these parameters instead describe the requested authentication of the *Approver*, never of the token's Subject, who MAY be a different principal (Section 6, step 2); requesting them carries no inference about which principal an issued token's own authentication claims describe, and this document does not adopt [RFC9470]'s token-claim-carriage behavior for them (see below). acr_values is a space-separated, preference-ordered list, not a single required class: the Approver's authentication satisfies the request when it matches any one listed value, under the deployment's own policy mapping (this document defines no global ordering of acr values); max_age bounds the elapsed time since that authentication. Approval authentication for a high-risk Mission (Section 6) MUST satisfy both the published floor and, where the client requested one, the acr_values/max_age carriage above; the floor is never relaxed by a narrower or absent client request. The authentication actually achieved for the approval event (acr, amr, and auth_time, in the sense [RFC9470] and [OpenID.Core] define them) is approval-time provenance, not requested Intent: this document never records it as, and an AS MUST NOT read it back from, a Mission Intent member. Where a deployment records Consent Evidence, the achieved values belong in its authentication_context member ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); this document defines no Mission Record member for them, and they MUST NOT be carried on, or inferred from, a derived access token (Section 9). 6.2. Binding the Mission to the Grant A Mission is independent of any OAuth grant: it is identified globally by the pair (issuer, id) (Section 8), and it can be approved, tracked, and terminated with no OAuth grant at all (the Mission Authority Server profile is the standing proof, [I-D.draft-mcguinness-mission-authority-server]). Where this document derives a Mission through OAuth, it relates the Mission to OAuth in two distinct ways: the *Mission grant binding*, defined below, and the mission claim a derived token carries as its own Mission reference (Section 9.2). The two are not the same relation, and this section keeps them apart. The Mission grant binding is an AS-controlled, functional mapping from one persistent, redeemable *grant lineage* to exactly one Mission. A grant lineage is state the AS can resolve again on a later request: the authorization code issued at approval and, where its redemption emits one, the refresh-token family that follows it; or another profile-defined reusable grant, such as a refresh-token family a continuation transport establishes later for the same Mission ([I-D.draft-mcguinness-oauth-mission-continuation]). The AS alone establishes and resolves a binding; a client never supplies or negotiates one. At the approval event the AS binds the Mission to the authorization code it issues. The binding is server-side and is what "the referenced Mission" in Section 10 refers to. The code itself carries no refresh-token family: only a successful redemption produces one, and where it does, the resulting refresh-token family inherits the code's binding atomically with its issuance, extending the same Mission grant binding rather than starting a second one. 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 Mission MAY carry zero or more grant bindings. Beyond the authorization-code lineage established at approval, a refresh-token family a continuation transport establishes later for the same Mission ([I-D.draft-mcguinness-oauth-mission-continuation]) is a further binding, rooted in the Mission its own subject_token resolved to. The AS MUST resolve a bound grant lineage to the same Mission on every derivation performed against it: the mapping is fixed for the lineage's lifetime and is never reassigned to a different Mission. No profile-defined operation lets a client present an input that could name a second Mission for an already-bound lineage; a lineage is always resolved from the grant itself, never negotiated, so this is an AS storage property rather than a client-visible refusal. An AS that failed to hold it, through corruption or defect, treats the condition as a data-integrity fault: it fails closed on the affected lineage and audits the event, rather than surfacing an ordinary authorization outcome. (Where a profile-defined operation does let a client present a Mission identifier the AS separately resolves from a credential, the identifier is a non-authoritative cross-check the AS MUST verify against the resolved Mission and refuse a mismatch with invalid_grant; the Expansion companion's predecessor parameter is the family's example of that pattern, [I-D.draft-mcguinness-oauth-mission-expansion], and it guards which Mission a new successor is created from, not reassignment of an existing binding.) A Token Exchange derivation ([RFC8693]) that returns only an access token establishes no new grant lineage: ordinary in-Mission delegation (Section 12) and self-exchange down-scoping (Section 12.2) both work this way, and the issued token is a derived token (Section 9.2) whose mission claim identifies the one Mission its subject_token's binding resolved to. A Token Exchange that instead establishes reusable authorization state, such as the continuation profile's delegation-family-creating exchange ([I-D.draft-mcguinness-oauth-mission-continuation]), creates a new grant binding, rooted in that same Mission. A cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]) establishes no destination-side grant binding. The cross-domain grant a Resource AS consumes is single-use and confers no standing authority in the partner domain, and the local access token it mints there is a derived token: it identifies the one originating Mission (mission.id, mission.issuer) but is not backed by a persistent local lineage. A Resource AS that needs the projected Mission again is presented a fresh cross-domain grant; this document defines no destination-side grant lineage for a cross-domain-derived credential. A grant lineage is never bound to more than one Mission, and a derived token's mission claim never names more than one Mission either. A Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]) and an expansion successor ([I-D.draft-mcguinness-oauth-mission-expansion]) are new Missions, each with its own identity; any grant binding or derived token they carry is their own under this section's rules, never an extension of the origin Mission's binding to a second Mission. They relate to their origin only by lineage (the child's parent member, the successor's predecessor member): an expansion successor's initial credential, for example, is ordinarily a derived token from the Token Exchange that creates it, with no grant binding of its own until a further exchange establishes one. A continuation handle and a refresh-token family are execution and credential machinery rooted in one Mission ([I-D.draft-mcguinness-oauth-mission-continuation]), not the Mission itself: they confer no authority of their own, only carrying a reference that a live derivation re-resolves against the Mission's current state. A grant binding is distinct from a decision-time runtime join. A Policy Decision Point MAY join an ordinary OAuth credential to a Mission at the point of a request, the pattern the Mission Authority Server specifies in full as the Mission Join ([I-D.draft-mcguinness-mission-authority-server]). Such a join is evaluated per request, MAY associate the same credential with different Missions across separate requests where the credential's subject and client are eligible for more than one, and MUST NOT be modeled as a persistent Mission grant binding: it does not make the joined OAuth grant Mission-bound, and it rests on its own authenticated inputs and evidence, never on this section's binding. Non-active state gates every future derivation across every binding this section defines (Section 10.2). It does not itself revoke an OAuth grant the same client or subject holds outside any Mission binding, and it does not recall an access token already issued before its exp absent a runtime state check the token's consumer performs (Section 10.3, Section 11). Where an issuer's fleet management needs to cascade a lifecycle operation or enumerate a Mission's bound grant lineages and credentials, it maintains its own issuer-side index from the Mission to each binding. That index is deployment and management-plane state, kept distinct from the interoperable model this section defines, and this document does not require any party outside the issuer to reconstruct it. A companion Mission Management profile MAY standardize the index's wire surface ([I-D.draft-mcguinness-oauth-mission-management]). 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 regardless of which lifecycle outcome follows: a deployment MUST adopt, document, and consistently apply one policy, either revoking the Mission or allowing it to reach expired at expires_at, and MUST NOT alternate between the two for the same event. Reprocessing the same unredeemed-code timeout (for example, a retried cleanup pass) MUST be idempotent: reapplying the declared policy to a Mission already in its resulting terminal state MUST NOT change that state or emit a second transition. A client learns its mission_id from the mission claim's id on each issued token (Section 9.2) 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.3. 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]). Where a deployment populates adjudication (Section 8) and an Approval Governance Record backs the decision, adjudication.governance_record is true and kind equals the record's accountable assertion's own mechanism, never a value that names the record itself, and never a flattening of its assertion set into a single principal; Section 8.1 names how this and other scenarios assign the three approval_basis roles. 7. Integrity and Commitments The anchors the Approver consents to at the approval event (Section 6) are constructed, canonicalized, and bound by the rules of this section; the Mission Record (Section 8) records them, and the test vectors (Appendix C) pin the construction byte-for-byte. 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": "", "iss": "", "value": } 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 C). 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 own type definition specifies a normalization; this document defines no such normalization itself. Where a type defines one, as mission_resource_access does for its prefix-match resource containment test ([I-D.draft-mcguinness-oauth-mission-resource-access]), it applies to that comparison alone: the default resource equality test remains an exact match, and anchor computation is always byte- exact over the recorded values regardless. Test vectors for the anchors are provided in Appendix C. 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 the Mission Resource Access Profile's Common Constraints already do for constraint values ([I-D.draft-mcguinness-oauth-mission-resource-access]). The security considerations of [RFC8785] apply to every JCS computation. The algorithm prefix is the agility mechanism. sha-256 is mandatory to implement and the only algorithm this 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. Mission Record A Mission is the durable record created at the approval event. Its members are immutable after creation except for its state, and it is identified by a Mission Identifier (Section 8.2). Operational issuance bookkeeping (the running derivation count gated under Section 10, as distinct from the fixed derivation_limit it is gated against, Section 10.1) is AS-side state about the Mission, not a member of the immutable record. Naming follows one rule across every surface that carries Mission facts. Record members do not repeat the mission prefix, because the record itself is the Mission; prefixed names belong to surfaces that reference a Mission from outside it, such as the mission_intent request parameter and the mission_id response parameter. Member names are spelled out (issuer, expires_at, created_at) and spelled identically everywhere; the compact JWT names (iss, exp, iat) describe a signed artifact's own envelope, or identify a party in an {iss, sub} object, never the Mission. Like the mission claim (Section 9.2), the record is open (Section 13): a companion profile of this document MAY record additional members set at creation using short names coordinated with it (for example, a lineage member linking the Mission to a predecessor or parent); any other extension MUST use collision- resistant names. A future revision MAY establish a registry for these members on demonstrated third-party extension demand; until then they are specification-defined. The members below are the ones this profile defines: id: REQUIRED. A string. The canonical Mission Identifier (Section 8.2). issuer: REQUIRED. A string. The issuer URL of the Mission Issuer that approved the Mission. Equals the iss of tokens that AS derives; for cross-domain tokens it remains the originating AS even though the issuing iss differs ([I-D.draft-mcguinness-oauth-mission-cross-domain]). state: REQUIRED. A string. The current lifecycle state: active, revoked, or expired in this profile, or an additional state defined by a companion profile, subject to the forward- compatibility rule of Section 10. intent: REQUIRED. An object. The approved Mission Intent. proposed_authority: OPTIONAL. An array. The authorization_details array the client submitted as its authority proposal (Section 4.2), recorded exactly as submitted. Present iff a proposal was submitted; a Mission derived in configured-mapping mode (Section 5) records none. authority_set: REQUIRED. An array. The consented Authority Set. authority_hash: REQUIRED. A string. The consent commitment over the Authority Set (Section 7.1). Like proposal_hash, it is surfaced on the record and through introspection (Section 11) to a caller holding that member's disclosure privilege, and is not carried on the baseline mission claim (Section 9.2); a profile that needs it on the claim carries its own copy (Section 9.2, Section 9.4). intent_hash: REQUIRED. A string. The integrity commitment over the approved Mission Intent (Section 7.1), making the recorded task tamper-evident. proposal_hash: OPTIONAL. A string. The integrity commitment over the recorded proposed_authority (Section 7.1). Present iff proposed_authority is present. It is approval-time provenance, not enforcement input: like approval_basis, it is surfaced on the record and through introspection (Section 11) and is not carried on the mission claim (Section 9.2). submission_evidence: OPTIONAL. An array. The verified Intent Submission Evidence facts (Section 4.3), one element per verified entry, present iff the approved submission carried evidence. Each element carries exactly these members: type, the entry's evidence type; artifact_hash, an integrity anchor (Section 7.1) with typ mission-intent-evidence over the entry exactly as presented; verified_at, an RFC 3339 timestamp of verification; and facts, an object holding the verified output facts the type's specification designates for recording, nested so type-owned facts cannot collide with the common members. Elements preserve the submission's evidence order, so the array has one canonical form (Section 7.2). Like approval_basis, it is provenance, not enforcement input, and it is not carried on the mission claim (Section 9.2). No integrity anchor commits it: its digests are record metadata whose trustworthiness is the trust in this immutable record, not an independently verifiable association between the Mission and the artifacts presented at admission, and an auditor who does not trust the record cannot prove from the anchors which evidence was used. A profile whose threat model requires that association commits normalized provenance under its own anchor typ (Section 7.1, Section 13); this document defines none. subject: REQUIRED. An object. The Subject, an object with iss and sub. approver: REQUIRED. An object with iss and sub. DEPRECATED compatibility alias for approval_basis.consent_principal (below), the canonical accountability-root name; normatively equal to it in every Mission this document produces. MAY equal subject. This document does not remove approver here; its removal is scheduled for a future breaking-change window. approval_basis: REQUIRED. An object. The authorization basis this Mission is rooted in: every Mission is rooted in an approved authorization basis, fixed at the approval event and immutable thereafter, like approver and subject. Members: type: REQUIRED. A string: direct, defined in full by this document, or an additional value defined by a companion profile that generalizes approval to a named standing-consent basis (for example, template ([I-D.draft-mcguinness-oauth-mission-template]) or policy_drawdown ([I-D.draft-mcguinness-oauth-mission-child-delegation])). An unrecognized type, and likewise an unrecognized adjudication.kind (below), is preserved unchanged as opaque provenance on an otherwise valid record: a consumer MUST NOT infer or fabricate the human, policy, or Approval Governance Record standing behind it, and MUST refuse only a profile operation that itself requires recognized adjudication semantics to proceed (for example, evaluating a policy-approval recency ceiling). This is a distinct rule from the Mission Lifecycle state rule of Section 10, under which any unrecognized value is uniformly non-active; an unrecognized value here does not by itself invalidate or deactivate the Mission. consent_principal: REQUIRED. An object with iss and sub. The accountable human (or human-accountable principal) who consented. This is the value of approver; this document does not add a second accountable principal. activation: REQUIRED. An object naming what activated this Mission instance, shaped by type. For direct: approval_event_id, mirroring the record's own approval_event_id (below). activation_actor: REQUIRED. An object with iss and sub. Who or what triggered this instance. For direct it equals consent_principal: the Approver triggers their own approval. A standing-consent type names a dispatching or requesting party distinct from the consenting human. adjudication: OPTIONAL. A discriminated object naming the decision _mechanism_ that adjudicated this instance: distinct from activation_actor (who triggered it) and consent_principal (who is accountable for it). Present when a Mission-creating profile or deployment chooses to make the mechanism explicit; where absent, the mechanism is nonetheless fixed by type and this document's or a companion profile's construction rules (below), and this document does not require restating it as a duplicate member in this revision. A future breaking-change window, the same one tracked for the approver alias's removal (above), MAY promote this member to REQUIRED once every Mission-creating profile populates it. Members, where present: kind: REQUIRED. A string: human or policy, naming a decision mechanism, never a storage location for supporting evidence; a companion profile MUST NOT define an additional value that names a record or evidence store in kind's place. An unrecognized value is handled under the same rule as approval_basis.type (above). For kind: human: no further members. The deciding human is consent_principal, and this document does not add a second reference to the same principal. For kind: policy: policy, a REQUIRED object with id and version identifying the deciding policy or workflow. This document defines no further members here; a companion profile that needs a typed evidence reference for the decision adds its own extension member under the collision-resistant naming rule of Section 13. governance_record: OPTIONAL. A boolean. true when an Approval Governance Record is recorded for this approval event ([I-D.draft-mcguinness-mission-approval-governance]), joined by this Mission's own approval_event_id; this document does not duplicate a reference to it, since a typed pointer would repeat a join the record already carries. When true, kind MUST equal the record's accountable assertion's own kind (exactly one assertion is accountable, by that document's assertion requirements, so this is well defined): a governed decision still names its mechanism, and the record supplies the fuller assertion set behind it, including any multi- assertion set, never flattened into it. root_commitment: REQUIRED. A string. The commitment to the consented root: an integrity anchor where the root is a committed object, otherwise the committed reference that identifies it. For direct, this Mission's own authority_hash. approved_at: REQUIRED for every standing-consent type; absent for direct, whose approval event carries its own instant (Section 6). An RFC 3339 date-time: the instant the accountable human approved the exact consented root that root_commitment commits (the template version, the drawdown policy version), not the instant this Mission instance was activated. The activating issuer MUST verify approved_at against its retained, authenticated record of that standing consent for that exact version; it MUST NOT accept the value as the activating request's own uncorroborated assertion. For direct, activation.approval_event_id MUST identify a human approval event (Section 6). A companion profile defining a standing-consent type MUST make its consent_principal and root_commitment trace to an accountable human's approval of the named standing consent, with no fresh approval event per instance, and MUST carry that approval's instant as approved_at. Where adjudication is present for direct, kind MUST be human unless governance_record is true, in which case kind instead follows the override that member defines (above). Where a companion profile defining a standing-consent type populates adjudication, kind MUST be policy, naming the identity and version of the policy or workflow that adjudicated the instance, subject to the same governance_record override; a companion profile MUST NOT define a kind value naming the requesting or dispatching party, and MUST NOT flatten a policy's or an Approval Governance Record's assertion set into a single principal member. *Standing-consent recency.* A deployment MAY declare maximum standing-consent ages (recency ceilings), and MAY declare them per consequence class where it classifies actions; where a declared ceiling applies, activating an instance whose approved_at is older than the ceiling MUST be refused. Where ceilings are declared, four rules are normative: * The evaluation instant is the atomic Mission-creation commit (Section 6), the same commit that re-checks the effective expiry; a deferred or relocated flow inherits the check at its own creation commit. Recency is issuance-time eligibility only: a later change to a ceiling, or the passage of time past one, does not retroactively terminate an active Mission (the lifecycle operations exist for that, Section 10.3). * approved_at MUST NOT be later than the evaluation instant beyond the deployment's declared, bounded clock-skew allowance; a future-dated value is refused. * Where ceilings are declared per consequence class, the issuer MUST classify the committed Mission from the derived Authority Set and from any consumption bound the Mission Intent carries (for example, a metering companion member, [I-D.draft-mcguinness-mission-metering]), and MUST apply the strictest ceiling across every class present. * The ceilings and the skew allowance MUST be part of the versioned policy the record's policy_version identifies, or a separately versioned declaration retained with it, so an auditor can reproduce the eligibility decision from retained state; a mutable out-of-band statement MUST NOT serve this role. The Approval Governance companion defines the analogous bound for its policy-assertion path ([I-D.draft-mcguinness-mission-approval-governance], Section "Policy-Approval Recency"). approval_basis is provenance: it is recorded alongside approver and is not folded into intent_hash or authority_hash (Section 7.1). Neither anchor commits it, and it MUST NOT be added to either digest; a profile that commits the Mission Record itself covers it under that profile's own anchor. Token introspection MAY disclose approval_basis.type to a caller holding that member's disclosure privilege (Section 11); it is not carried on the baseline mission claim (Section 9.2), and it MUST NOT be relied on to grant or widen authority wherever it does appear. authority_source: REQUIRED. An object. The source of the authority the approval draws on (Section 3.3), established at the approval event (Section 6) and immutable thereafter, like approver and approval_basis. Members: type: REQUIRED. A string: user_delegated, service_owned, or organizational, subject to the forward-compatibility rule of Section 10. policy: REQUIRED for organizational, absent otherwise. An object with id, version, and digest: the stable reference to, and commitment over, the governed organizational policy the Mission draws on. authority_source is provenance like approval_basis: recorded alongside it, folded into neither intent_hash nor authority_hash, and not carried on access tokens; Resource Servers enforce authorization_details and do not consult it. client_id: REQUIRED. A string. The Agent (OAuth client) that submitted the Mission Intent. policy_version: REQUIRED. A string. The derivation policy version in effect at the approval event. approval_event_id: REQUIRED. A string. A unique identifier of the approval event, used as the approval idempotency key: a retried or duplicate delivery of the same approval decision (a replayed callback, a double-submitted consent form) MUST NOT create a second Mission, and the AS deduplicates on this identifier. It is otherwise an opaque audit identifier with no wire semantics. created_at: REQUIRED. A string. RFC 3339 timestamp of creation. expires_at: REQUIRED. A string. An RFC 3339 date-time: the AS- established effective Mission expiry, after which the AS MUST NOT derive tokens under the Mission. It MUST be later than created_at and MUST NOT be later than intent.expires_at, the requested ceiling (Section 4). Shortening under applicable AS policy, or under an already-approved parent, predecessor, or standing-consent bound a Mission-creating profile defines, is ordinary narrowing of the granted lifetime, not Authority Set derivation; for direct creation under this document the only additional ceiling is applicable AS policy. Extension beyond the submitted request is never permitted. derivation_limit: OPTIONAL. A positive integer. The AS-established effective ceiling on derivations performed under this Mission, fixed at the approval event and immutable thereafter like expires_at (Section 10.1). Present whenever the deployment's policy imposes a ceiling on this Mission, whether by requested narrowing or by policy alone; absent only where it imposes none. Enforcement of this ceiling, and the running derivation count it is gated against, are defined in Section 10.2. The *audit horizon* is the deployment-declared retention window for the Mission record and its evidence: at least the Mission's lifetime plus a declared post-expiry period. After the Mission reaches a terminal state (revoked or expired), the record MUST be retained for the audit horizon. 8.1. Role Mapping approval_basis separates three questions about a Mission's own creation, and a scenario can assign them to different principals: who is accountable for it (consent_principal), who or what triggered it (activation_actor), and what decided it (adjudication). The companion profiles below define the scenarios; this table names how each assigns the three roles. +=======================================================+===================+==================+==================+ |Scenario |Accountability root|Activation actor |Adjudication | | |(consent_principal)|(activation_actor)|(where a profile | | | | |or deployment | | | | |populates it) | +=======================================================+===================+==================+==================+ |Direct approval |The approving human|Equal to |kind: human; the | | | |consent_principal:|deciding human is | | | |the Approver |consent_principal | | | |triggers their own|itself | | | |approval | | +-------------------------------------------------------+-------------------+------------------+------------------+ |Relocated human approval |The human who |Equal to |kind: human, as | |([I-D.draft-mcguinness-oauth-mission-approval]) |completes the |consent_principal,|direct | | |relocated approval |unchanged from the| | | |event |direct case: the | | | | |instance activates| | | | |at that human's | | | | |decision, not at | | | | |any earlier | | | | |submission | | +-------------------------------------------------------+-------------------+------------------+------------------+ |Template dispatch |The template's |The Dispatcher |kind: policy, | |([I-D.draft-mcguinness-oauth-mission-template]) |human approver, |that requested the|policy naming the | | |fixed at template |Dispatch, distinct|template's | | |creation |from |dispatch_policy id| | | |consent_principal |and version | | | | |(already carried | | | | |in the dispatched | | | | |Mission's template| | | | |lineage member), | | | | |never the | | | | |Template's own id/| | | | |template_version | | | | |nor the Dispatcher| +-------------------------------------------------------+-------------------+------------------+------------------+ |Policy drawdown |The Parent |The requesting |kind: policy, | |([I-D.draft-mcguinness-oauth-mission-child-delegation])|Mission's human |parent Agent, |naming the child- | | |Approver |distinct from |creation policy's | | | |consent_principal |id/version where | | | | |the entry carries | | | | |one, otherwise the| | | | |Parent Mission's | | | | |approved | | | | |delegation entry; | | | | |never the | | | | |requesting parent | | | | |Agent | +-------------------------------------------------------+-------------------+------------------+------------------+ |Ceiling drawdown |The Approver who |The requesting |kind: policy, | |([I-D.draft-mcguinness-oauth-mission-progressive]) |consented the |client, distinct |naming the | | |ceiling |from |drawdown policy's | | | |consent_principal |policy_id/ | | | | |policy_version | | | | |carried in | | | | |activation; never | | | | |the requesting | | | | |client | +-------------------------------------------------------+-------------------+------------------+------------------+ |AGR-backed approval |The principal the |Unchanged from the|governance_record:| |([I-D.draft-mcguinness-mission-approval-governance]) |Approval Governance|underlying basis |true; kind equals | | |Record's | |the record's | | |accountable | |accountable | | |assertion names, | |assertion's own | | |equal to | |mechanism (human | | |consent_principal | |or policy), never | | | | |a value that names| | | | |the record itself,| | | | |and its full | | | | |assertion set is | | | | |never collapsed | | | | |into a single | | | | |principal | +-------------------------------------------------------+-------------------+------------------+------------------+ Table 2 Direct approval is the degenerate case where one human fills every role; that coincidence does not define the model, and no other scenario collapses the three questions into it. adjudication itself is OPTIONAL (Section 8): a profile or deployment that does not populate it still fixes the mechanism through type and its own construction rules, and this table states what an explicit value would be for each scenario, not a wire requirement this revision imposes on every one of them. 8.2. 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.2). 8.3. Worked Example { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com", "state": "active", "intent": { "goal": "Reconcile Q3 invoices ...", "target_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" }, "adjudication": { "kind": "human" }, "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 C) 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. Mission-Bound Access Tokens Access tokens issued under a Mission are JWTs per [RFC9068], which fixes the required claims (including jti) and the at+jwt JOSE header typ ([RFC9068] Sections 2.1 and 2.2); a Resource Server MUST verify the typ per [RFC9068]. In addition to what that profile requires, a derived token: * carries the token's Mission-derived authority as authorization_details ([RFC9396]); this MAY be the full Authority Set or a narrowed subset (Section 5.1); * carries a mission claim (Section 9.2); * sets sub to the AS-local sub the AS maps the Mission's Subject to (Section 6); * carries client_id per its ordinary [RFC8693] Section 4.3 and [RFC9068] Section 2.2 meaning, the client that requested this particular token; the Mission's originally-approved agent is not carried on the token, and remains recorded in the Mission Record (Section 8); * MUST set aud to identify the Resource Server(s) authorized to consume the carried authorization_details, and MUST NOT include an audience unrelated to that carried authority (see below); * MAY carry an act claim when the agent has delegated execution (Section 12); * MAY carry a scope claim, subject to the rule below; * SHOULD be sender-constrained, via a cnf claim [RFC7800]: DPoP [RFC9449] (cnf.jkt) or mTLS [RFC8705] (cnf.x5t#S256). Stated explicitly for estates whose access tokens are opaque reference tokens: this document's token-carried enforcement assumes the JWT above, and an opaque Mission-bound token is profiled only under the introspected consumption mode (Section 11.4), which makes introspection the REQUIRED claims carriage with the same enforcement obligations. An estate whose AS can issue neither deploys the standalone Mission Issuer binding, which governs ordinary tokens at the enforcement layer ([I-D.draft-mcguinness-mission-authority-server]). The AS MUST NOT include authorization_details exceeding the Mission's Authority Set. On any issuance that narrows authority (for example, a single-audience token), each emitted entry MUST be a subset of a Mission Authority Set entry under Section 5.1. The aud SHOULD be derived from the resource indicators ([RFC8707]), Protected Resource metadata ([RFC9728]), or the deployment's resource-to-RS mapping. It identifies the Resource Server(s) and need not be byte-equal to the resource values of the authorization_details entries: an aud typically names an RS, API, or security domain, while entries name resources, accounts, tools, or locations beneath it. Bounding aud to the consuming Resource Server(s) prevents a confused-deputy or token-redirection attack, in which a multi-resource Authority Set yields a token an unrelated Resource Server would accept even though it was obtained to act elsewhere. A deployment SHOULD prefer per-RS (single-audience) tokens, narrowed under Section 5.1: the client requests one at the token endpoint with the [RFC8707] resource parameter (and MAY further narrow with scope), and the AS narrows the Authority Set under Section 5.1 to the requested resource(s) and sets aud to the corresponding Resource Server(s). This is the within-domain counterpart of the audience- scoping the Mission Issuer applies when projecting authority to a Resource AS ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Sender-constraining is a SHOULD for this primary token, aligned with [RFC9700]. It is stronger (MUST) for delegated tokens, which face higher replay exposure in the hands of a less-trusted delegate (Section 12); the companion sets the same MUST for the credentials that cross a trust domain ([I-D.draft-mcguinness-oauth-mission-cross-domain]). A deployment SHOULD sender-constrain the primary token as well where its threat model warrants. The token-endpoint response conveys the granted authority to the client. Because what the client submitted was a proposal, never the grant (Section 4.2), and the client is not expected to parse the access token, the AS MUST return the granted authorization_details in the token-endpoint response, per [RFC9396] Section 7, reflecting exactly the (possibly narrowed) set assigned to the issued token; the same applies to refresh and Token Exchange responses. The mission_id response parameter carries the Mission reference beside it (Section 6.2). For example, the agent narrows the canonical ERP Mission (the worked example of Section 8) to a read-only token, presenting the Mission's refresh token with the [RFC8707] resource parameter and narrowing further with scope: POST /token HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... grant_type=refresh_token &refresh_token=rt_4mN8qV2xP7sL1tY9zB3k &resource=https%3A%2F%2Ferp.example.com &scope=invoices.read The issuance is a derivation, gated on the Mission being active (Section 10). The response echoes the narrowed grant and the mission_id reference (Section 6.2); the emitted entry is a subset (Section 5.1) of the Mission's read entry, its constraints carried intact: { "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...", "token_type": "DPoP", "expires_in": 300, "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "mission_expires_at": "2026-12-31T23:59:59Z", "authorization_details": [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"], "constraints": { "resource_issued_after": "2026-07-01T00:00:00Z", "resource_issued_before": "2026-09-30T23:59:59Z" }, "delegation": { "max_depth": 2, "allowed_delegates": [{ "sub_profile": "ai_agent" }] } } ] } Mission-bound refresh tokens MUST be sender-constrained or use refresh token rotation. This matters most for a public client, since Mission-state gating bounds a stolen refresh token's usefulness over time but not while the Mission is still active. This strengthens the refresh-token guidance of [RFC9700] Section 2.2.2, whose MUST applies to public clients, to all Mission-bound refresh tokens. The authentication achieved for the approval event describes the Approver at approval time, not the token's Subject or any later presentation of the token; it is approval-time provenance (Section 6.1), never carried on a derived token. A derived token's authority comes from the Mission, not from a fresh authentication, so this document requires no acr or auth_time claim on it, and an AS MUST NOT include either on a derived access token to convey approval- event context. Where an AS includes acr or auth_time per [RFC9068], each keeps that claim's standard token-authentication meaning, describing the token's own presentation or Subject, never repurposed to carry the Approver's approval-time context; a consumer MUST NOT infer approval provenance from their presence and MUST NOT treat their absence as an authentication downgrade. authorization_details is the authoritative expression of a Mission- bound token's authority. A token MAY also carry scope, subject to the Scope Projection rule of Section 9.1. Because scope is a coarse string list, it cannot carry the per-entry constraints; where it is emitted at all, it is a compatibility projection, never the authoritative form of the Mission's authority. A credential the Mission Issuer derives MUST have an exp that does not exceed the Mission's expires_at, so that no credential outlives the approved Mission (not merely that none is issued after expiry). How this bound extends transitively to tokens minted in another trust domain is specified by the companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Short-lived access tokens remain this profile's issuance-only recommendation: with no runtime layer, token lifetime is the revocation-latency bound at unmodified Resource Servers. Where a runtime layer covers the high-consequence classes with an active freshness source, the point-of-use decision is the revocation cutoff, and a deployment MAY size lifetimes by action class without losing the kill switch (Section 17.3.1, [I-D.draft-mcguinness-mission-runtime]). Classes attach to entries while exp attaches to the token: an extended lifetime is appropriate only for a token whose carried entries are all on runtime-gated paths, since a single ungated entry stretches its own revocation latency to the extended lifetime. Narrowed, single-audience tokens (Section 5.1) are the mechanism that keeps gated and ungated authority from sharing one long-lived token. 9.1. Scope Projection For every target audience, the AS MUST establish that the effective rights the target's enforcement path grants from the projected scope, together with every independently mandatory control on that path, are a subset of the rights the token's applicable authorization_details grant. This is a semantic condition, not a structural one: it fails for a constraints-free entry whose scope aggregates a broader action, spans more resource instances or paths than the entry, carries rights the target's local scope interpretation implies, or arises from the union of several entries, exactly as it fails for a relaxed constraint. To emit scope for an entry, the AS: 1. determines the target Resource Server or audience for the token; 2. resolves a trusted, versioned scope-projection mapping for that target, established through the target's protected resource metadata (Section 15) or authenticated out-of-band configuration; 3. establishes, under the subset condition above, that the complete effective authorization the projected scope grants at that target is no broader than the applicable carried entries; 4. omits scope for an entry where the target's enforcement path consumes authorization_details instead; 5. MUST refuse issuance to a target that is scope-only when no safe projection exists for the applicable entries: an issued token no enforcement path can safely evaluate is not a usable credential; and 6. for a multi-audience token, establishes the condition independently for each audience; a single-audience token (Section 9) remains preferred. Unknown scope semantics, unknown Resource Server enforcement behavior, or an ambiguous or stale mapping all fail closed under step 5. This rule applies to every issuance path that can emit scope on a Mission-bound token: initial issuance, refresh, Token Exchange, and any other derived-token path. This is the type-agnostic form of the rule; a type's own specification states when the mapping in step 3 is safe for that type's entries (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]). A runtime profile's own enforcement-scope declarations ([I-D.draft-mcguinness-mission-runtime]) MAY reference the same mapping for the paths it covers; it does not own the mapping, and this rule does not depend on the runtime profile being deployed. 9.2. The Mission Claim The mission claim is a JSON object: id: REQUIRED. A string. The Mission Identifier (Section 8.2). 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]). id and issuer identify the Mission and carry no authority of their own; the token's own signature authenticates the pair, and the carried authorization_details remains the token's concrete authority. This document does not carry authority_hash or approval_basis on the baseline claim. Neither is an enforcement input a narrowed-token Resource Server can exercise: authority_hash commits the complete Authority Set, which such a Resource Server does not hold (Section 9.3); approval_basis.type is provenance, not authority (Section 8). Both stay available elsewhere: the Authority Set commitment lives on the Mission Record and the audit surfaces that already carry it, an authorized introspection caller MAY receive authority_hash and approval_basis.type (Section 11.1), and a deployment needing local verification of the approved set, not merely its audit trail, adopts the Local Approved-Set Verification profile (Section 9.4). A companion profile needing a stable per-token audit or lineage anchor across tokens it mints or carries (offline attenuation, a cross-trust-domain grant) defines that as its own claim member under the extensibility rule below; the baseline supplies none for it to inherit. 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). A consumer that relies only on the presented token's own validity needs nothing further: the token's exp already bounds it. A profile that mints a further credential downstream of this one, or that verifies a Mission's remaining lifetime from retained state rather than a live token, MUST require expires_at and MUST treat its absence as an error; it MUST NOT substitute the token's own exp, which bounds only that one credential, for a member that bounds every credential the Mission may still yield. 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" } } 9.3. Resource Server Enforcement A Resource Server enforces from the token alone; no call to the AS is required for the JWT carriage. An opaque Mission-bound token is enforced from its active introspection response instead, the response standing as the claims source under these same rules (Section 11.4). 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 each applicable entry according to that entry's own type specification (for mission_resource_access, [I-D.draft-mcguinness-oauth-mission-resource-access]). Where more than one carried entry applies, entries are alternative grants of authority, not conjunctive filters, unless the entry's type states otherwise. * MUST fail closed (refuse the request, for example a 403 with insufficient_scope [RFC6750], or the deployment's usual insufficient-authority error) on any applicable entry whose type it does not implement, or whose type-defined enforcement it cannot complete (an unrecognized member, an unenforceable constraint, or an unrecognized matching mode), rather than grant access on the strength of an entry it cannot fully evaluate. * MUST NOT reduce any type-defined 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 implement the Local Approved-Set Verification profile (Section 9.4) to verify a carried entry against the complete approved Authority Set rather than the token signature alone. * 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 type-defined constraint narrows authority, so treating an unenforceable key or member as absent, or reducing it to disclosure- only, would silently widen the grant; that is why an entry whose type-defined enforcement a Resource Server cannot complete fails closed. The baseline token carries no authority_hash for a Resource Server to consult at all; where a deployment discloses it to that Resource Server all the same (through introspection's disclosure privilege, Section 11.1, or a companion profile that carries its own copy), the Resource Server MUST treat it 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 Resource Server that needs more than that assertion adopts the Local Approved-Set Verification profile (Section 9.4). A Resource Server denial falls into one of four cases, each riding the OAuth-standard challenge for its own failure class (Section 9.6 states the full endpoint x parameter x failure-stage mapping normatively): * *Weak or stale token-associated user authentication.* The authentication event associated with the presented token does not meet the resource's requirement: the RS challenges with insufficient_user_authentication and the acr_values/max_age WWW- Authenticate parameters ([RFC9470]). This describes the authentication behind the presented token's own Subject, a distinct fact from the Approver's approval-time authentication (Section 6.1); a client MUST NOT infer that satisfying one satisfies the other. * *Sender-constraint or key-binding failure.* The token's proof of possession is missing or invalid: the RS challenges with invalid_token. A DPoP-bound token ([RFC9449]) uses the DPoP WWW- Authenticate scheme, with error="invalid_token" for a missing, invalid, or mismatched proof and error="use_dpop_nonce" where the RS requires a fresh nonce the client omitted or replayed ([RFC9449] Section 9); a certificate-bound token ([RFC8705]) defines no challenge scheme of its own, and a presented client certificate that fails to match the token's confirmed thumbprint is denied under the ordinary Bearer invalid_token error ([RFC6750]), per [RFC8705] Section 3. This is never a step-up: no fresh user authentication repairs a missing or wrong key. * *Insufficient carried authority.* The action is outside the token's carried authority: the RS challenges with insufficient_scope ([RFC6750]), or the RAR-remediation challenge where [I-D.draft-zehavi-oauth-rar-metadata] is deployed (Section 9.5); more requires a new approval or an expansion where that companion is deployed. * *Unenforceable constraint.* An applicable entry carries a type- defined member or constraint the RS cannot enforce, and the request fails closed under the same base error as insufficient authority. The last two cases are byte-identical 403s to a client, and misrouting them turns a fail-closed mismatch into a retry loop the client cannot resolve. A Mission-aware Resource Server SHOULD therefore state which of the two 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 two values: insufficient_authority: The action is outside the token's carried authority; more requires a new approval or an expansion where that companion is deployed. constraint_unrecognized: An applicable entry carries a type-defined member or constraint the RS cannot enforce, and the request fails closed. This value MUST NOT be read as inviting retry, step-up, or fresh approval: none of those makes an RS understand a constraint it does not implement. A value the client does not recognize is treated as insufficient_authority. The attribute's disclosure considerations are Section 17.3.2's. A Mission-unaware Resource Server that authorizes only from scope operates within the Mission only to the extent the AS established a safe projection for it at issuance (Section 9.1): the AS proved that the projected scope's effective rights, together with every independently mandatory control on that path, are no broader than the applicable authorization_details. Where no such projection exists for an entry, the AS omits scope for it or refuses issuance to that audience rather than emit a scope the Resource Server would over- grant on (Section 9.1). A deployment that needs constrained authority enforced where no safe projection exists MUST route the protected operation through a Resource Server that enforces authorization_details (or the runtime layer that evaluates them). 9.4. Local Approved-Set Verification This OPTIONAL profile lets a verifying party check a token's carried authority against the Mission's complete approved Authority Set, rather than relying on the token signature and the AS's subset assertion alone (Section 9.3). A deployment adopts it when a Resource Server, a policy decision point, or an auditor needs that independent check; a deployment that does not is unaffected and remains fully conformant to the baseline. A worked contrast, using the two-entry Authority Set of the test vectors (Appendix C), 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. A party outside this profile verifies the token signature and cnf, checks aud, and enforces the carried entry (Section 9.3). 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 claiming this profile holds, or retrieves, 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 it against the Mission's authority_hash independently obtained, and verifies the carried entry as a subset of the held journal-entries.write entry: containment verified relative to the authenticated committed set. A conforming implementation claims this capability (Section 16) through authenticated complete-set retrieval, declaring which of the two tiers below it supports. This document also identifies a typed selective-inclusion proof as a future composition point (Section 9.4.2); it is not, by itself, an alternative a conforming implementation can claim today. 9.4.1. Authenticated Complete-Set Retrieval The verifying party retrieves the complete Authority Set, and the authority_hash it expects to match, over a channel authenticated to the Mission issuer, never from an unauthenticated or self-reported source, and: * MUST recompute the commitment over the retrieved set (Section 7.1) and reject on mismatch, rather than trust the retrieval channel alone; * MUST verify each carried authorization_details entry is a subset (Section 5.1) of an entry in the retrieved set, and MUST NOT treat commitment match alone as sufficient; and * MUST fail closed: a retrieval failure, an unauthenticated response, a commitment mismatch, or a subset-test failure refuses the request under Section 9.3, never falls back to trusting the token signature alone as if this profile were not claimed. That much is *Tier 1*, and it has a specific limit: it does not by itself establish that the retrieved set is the set the Approver consented to. The same issuer supplies both the retrieved set and the authority_hash Tier 1 checks it against, so an issuer that returns a substituted set together with a digest recomputed to match it passes Tier 1 undetected. Tier 1 defends against a projection bug, a stale or corrupted materialization, or a compromised link between the record store and the retrieval endpoint; it does not defend against an issuer dishonest at the moment of retrieval, nor against a signing key compromised after approval. *Tier 2* adds that defense: the verifying party additionally holds an expected authority_hash obtained from a source independent of the Tier 1 retrieval channel, never re-derived from the same call being verified, and MUST reject unless the retrieved (and recomputed- matching) value also equals that independently held one. A deployment claiming Tier 2 declares: * a *retention point*: which party retains the expected authority_hash and where, independent of the retrieval channel above (for example, a Resource Server's own durable copy of the value disclosed to it under introspection's authority_hash disclosure privilege at the time it first received the Mission's tokens, Section 11.1); * a *trust basis*: how the retaining party authenticated that value when it captured it, which is the same issuer-authenticated channel any disclosure under this document requires, never an unauthenticated or self-reported source; and * a *retention rule*: how long the retained value is held and under what conditions, if any, it is replaced, which MUST NOT include re-deriving it from the Tier 1 channel it is meant to check. A conforming implementation MAY claim Tier 1 alone or Tier 1 with Tier 2, and states which it claims (Section 16): a "verified" result means different things under each, and a caller relying on it needs to know which. The approved Authority Set and its authority_hash are immutable for the Mission's life (Section 8). Once retrieved and verified under the tier(s) claimed, a verifying party MAY retain them for as long as it relies on the Mission; this profile imposes no re-retrieval requirement of its own. Freshness applies instead to what does change: the Mission's current active state and its current effective (containment-filtered) authority, already governed by the runtime profile's state-freshness rules ([I-D.draft-mcguinness-mission-runtime]). A verifying party that also needs those observes that profile's rules directly, rather than treating a re-retrieval of the immutable approved set as if it were itself a freshness signal. This document does not mandate a specific retrieval endpoint or transport; a deployment provisions one, discoverable and authorization-gated more strongly than the introspection disclosure privilege it otherwise parallels (Section 11.1): introspection minimizes its response to one audience at a time, while a complete- set retrieval response necessarily discloses every audience's entries to the retrieving party, so its authorization gate MUST be at least as strong as the disclosure privilege for every audience the Mission has issued to, not any single audience's own. Mission Status ([I-D.draft-mcguinness-oauth-mission-status]) is *not* a compatible retrieval surface for this profile. Its authenticated, mission_id-keyed lookup returns only the requesting audience's own entries ([I-D.draft-mcguinness-oauth-mission-status]), and, once containment has applied, the Mission's current effective set rather than its complete immutable approved set. Recomputing authority_hash over a Status response therefore fails by construction for any multi- audience Mission, and fails after any containment or discharge even for a single-audience one. A deployment claiming this profile provisions a retrieval surface distinct from Status, meeting the stronger disclosure gate above. 9.4.2. A Typed Selective-Inclusion Proof: a Future Composition Point Rather than retrieving the complete set, a future profile MAY instead define a proof type under which the verifying party holds, per carried entry, a proof that entry's unnarrowed approved parent entry is included in the Mission's committed Authority Set, and applies the type-owned subset test (Section 5.1) between that disclosed parent entry and the carried, possibly narrowed, entry, exactly as Section 17.1.1 states: never a proof of the carried entry directly, since a narrowed entry was never itself an array member authority_hash committed. A concrete proof type would need to: cover every carried entry, not merely one; authenticate its own proof root as the Mission's approval-time commitment, under a collision-resistant typ distinct from authority_hash's own (Section 7.1); define the verifier's processing, so a party lacking the proof type's software cannot misread it as a plain digest; reject an unrecognized proof typ rather than skip verification; and define no downgrade path back to bare digest equality. The middle requirement is the open problem: this document's flat authority_hash digests a single array and by itself authenticates nothing about a differently structured proof root (a Merkle root or an accumulator, for example), so a concrete proof type would need its own construction binding that root to the Mission, for example the Mission Issuer signing or committing to it alongside authority_hash at the approval event. Until a concrete proof type supplies that construction, this mechanism remains a composition point for a future companion profile, not an alternative this document lets an implementation claim today. Under Authenticated Complete-Set Retrieval, what verification buys depends on when the issuer is compromised, and Tier 2's independent pinning is what defends against post-approval substitution; that analysis is stated once, in Section 17.1.1. 9.5. 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. +==========================+======================+======================================+ |Grain |Carriage |Defined by | +==========================+======================+======================================+ |mission_denial |WWW-Authenticate |This document (Section 9.3) | | |attribute | | +--------------------------+----------------------+--------------------------------------+ |insufficient_authorization|WWW-Authenticate error|[I-D.draft-zehavi-oauth-rar-metadata] | |with |code and parameter | | |authorization_remediation | | | +--------------------------+----------------------+--------------------------------------+ |Requestable denial |AuthZEN denial |[AuthZEN.ARAP], profiled by | | |response: |[I-D.draft-mcguinness-mission-authzen]| | |context.access_request| | | |with next_action: | | | |request | | +--------------------------+----------------------+--------------------------------------+ Table 3: The three remediation grains 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.2) 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. 9.6. Error and Challenge Mapping This document reuses standard OAuth errors and challenges by parameter ownership and processing stage rather than defining a parallel Mission diagnostic protocol. This table is the normative statement; every other rule in this document that names one of these codes (Section 4.1, Section 5, Section 6.1, Section 10.2, Section 9.3) applies this mapping and does not restate it. +=====================+================================+=================+ |Surface / failing |Base OAuth error |Optional detail | |input | | | +=====================+================================+=================+ |PAR: malformed |invalid_request |safe | |Mission envelope or | |error_description| |Intent (schema, | | | |unknown member, | | | |invalid value) | | | +---------------------+--------------------------------+-----------------+ |PAR or authorization:|invalid_authorization_details |RAR-defined | |malformed or |([RFC9396]) |detail | |unsupported actual | | | |RAR object (an entry | | | |of a submitted | | | |authorization_details| | | |proposal) | | | +---------------------+--------------------------------+-----------------+ |Authorization or |invalid_target ([RFC8707]) |safe | |token request: | |error_description| |invalid, unknown, or | | | |malformed actual RFC | | | |8707 resource | | | |parameter | | | +---------------------+--------------------------------+-----------------+ |Authorization |access_denied ([RFC6749]) |none unless a | |decision: the | |defined extension| |Approver declines, | |applies | |approval | | | |authentication fails | | | |the floor or a | | | |requested acr_values/| | | |max_age, or a well- | | | |formed request | | | |(including | | | |configured-mapping | | | |mode) is refused by | | | |AS policy | | | +---------------------+--------------------------------+-----------------+ |Token endpoint: the |invalid_grant |mission_error | |Mission is revoked, | |(Section 20) | |expired, superseded, | | | |or its | | | |derivation_limit is | | | |exhausted | | | +---------------------+--------------------------------+-----------------+ |Token endpoint: the |invalid_authorization_details |safe detail | |requested RAR subset |([RFC9396]) | | |exceeds the Mission's| | | |granted authority | | | +---------------------+--------------------------------+-----------------+ |Protected resource: |insufficient_user_authentication|acr_values/ | |weak or stale token- |([RFC9470]) |max_age | |associated user | | | |authentication | | | +---------------------+--------------------------------+-----------------+ |Protected resource: |DPoP invalid_token challenge |none | |DPoP proof missing, |([RFC9449]) | | |invalid, or | | | |mismatched | | | +---------------------+--------------------------------+-----------------+ |Protected resource: |DPoP use_dpop_nonce challenge |fresh nonce | |DPoP nonce required, |([RFC9449]) | | |missing, or stale | | | +---------------------+--------------------------------+-----------------+ |Protected resource: |Bearer invalid_token challenge |none | |certificate-bound |([RFC6750], per [RFC8705] | | |token's presented |Section 3) | | |certificate mismatch | | | +---------------------+--------------------------------+-----------------+ |Protected resource: |insufficient_scope ([RFC6750]) |mission_denial | |insufficient carried |or the RAR-remediation challenge|(Section 9.3), | |authority, or an |(Section 9.5) |minimized | |unenforceable | | | |constraint | | | +---------------------+--------------------------------+-----------------+ Table 4: Endpoint x parameter x failure-stage error mapping An AS performing an applicable check early, at PAR, returns the same error class the check would yield at the authorization or token endpoint: [RFC9126] Section 2.3 permits an authorization-request error at PAR, and doing so does not change which of the rows above applies. 10. Mission Lifecycle and Gating A Mission is in one of three states: * active: tokens MAY be derived. The only state from which issuance proceeds. * revoked: terminated by the Subject, Approver, or policy. Terminal. * expired: expires_at has passed. Terminal. The transitions are: +========+====================+=========+ | From | Event | To | +========+====================+=========+ | (none) | approval event | active | +--------+--------------------+---------+ | active | revoke | revoked | +--------+--------------------+---------+ | active | expires_at reached | expired | +--------+--------------------+---------+ Table 5 These three states are the mandatory core of the Mission lifecycle state space. This profile owns that state space and establishes its registry, the Mission Lifecycle States registry (Section 20.7); an OPTIONAL companion profile MAY register an additional state for a lifecycle it introduces (for example, a paused or a superseded state), but only active ever permits issuance. A consumer MUST apply this forward-compatibility rule wherever a Mission state is reported, including the Mission record and the introspection mission member: only the exact value active permits derivation or continued reliance, and every other value, including a value the consumer does not recognize, MUST be treated as non-active and non-deriving. A consumer MUST NOT fail open on an unrecognized state. This makes a registered state added by a companion profile fail safe for a consumer that predates it. One rule makes the clock boundary authoritative ahead of stored state: for every state-dependent decision this document defines, the AS MUST evaluate expires_at before relying on stored state, and a Mission is effectively active only when its stored state is active and the decision time is strictly before expires_at. Persisting the expired transition, and emitting any corresponding lifecycle event where a state-distribution companion is deployed, MAY happen lazily, after the decision that observed the boundary. 10.1. Derivation Issuance Policy A Mission's derivation limit bounds the number of derivations (Section 10.2) the issuer AS performs under it. The limit is always AS-established operational policy; a client MAY additionally request a ceiling narrower than that policy through the Mission Intent's requested_derivation_limit member (Section 4). Omission of requested_derivation_limit means no client-requested ceiling, not necessarily a bounded effective result: the effective limit is set entirely by AS policy, which MAY itself impose no ceiling. The Mission Record's derivation_limit (Section 8) is the immutable, AS-established *effective* ceiling. At the approval event the AS establishes it as the minimum of the deployment's own policy ceiling for this Mission and the requested requested_derivation_limit, where one was submitted: a client's request MAY only narrow, never widen, the AS's own policy ceiling. The rendered approval surface (Section 6) MUST display the established derivation_limit, not merely the requested value, so the Approver consents to the ceiling actually enforced. This establishment happens afresh at every approval event that creates a Mission Record: a Child Mission's, a dispatched Template instance's, and an Expansion successor's, exactly as at direct approval. An established derivation_limit is never inherited unchanged from a parent, a template, or a predecessor Mission; each Mission Record's ceiling comes only from its own Intent's requested_derivation_limit, clamped by the deployment's policy for that Mission. An auditor recomputes the expected derivation_limit from the recorded requested_derivation_limit (or its absence) and the Mission's policy_version (Section 5) against the deployment's retained, versioned policy; a mismatch is a policy-application defect to investigate, not a Mission-record integrity failure, since neither integrity anchor commits derivation_limit (Section 7.1). Enforcement of derivation_limit (the per-Mission derivation count, its atomicity with issuance, and the cross-domain and refresh accounting rules) is defined once, in Section 10.2, which this ceiling bounds. 10.2. 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's derivation_limit (Section 10.1) is established, the AS MUST maintain a per-Mission count of *derivations* and MUST refuse with invalid_grant any derivation that would exceed it. 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 running count as internal bookkeeping, distinct from the fixed derivation_limit it is gated against (Section 10.1): the count 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.3. 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 revoke/suspend/resume/complete operations, is specified separately by Mission Status [I-D.draft-mcguinness-oauth-mission-status]; this document does not require it. The MUST is satisfiable through a deployment-defined authenticated surface; where a deployment adopts Mission Status, its Mission Lifecycle endpoint's revoke operation provides the interoperable operation, authorized per Status's own lifecycle authorization policy. 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. Mission State via Token Introspection This section is OPTIONAL for the JWT carriage: there it is one state- observable overlay on the lifecycle-gated baseline. For a deployment issuing opaque Mission-bound tokens it is REQUIRED, as the token's claims carriage (Section 11.4). The stateless baseline (Section 9) needs no introspection; an AS that does not offer it, and a Resource Server that does not use it, are unaffected. It lets a Mission- state-aware Resource Server observe a Mission's current state per request instead of waiting out a token's lifetime. Because it can report Mission state for a token whose Mission is no longer active, this section deviates from the SHOULD NOT of [RFC7662] Sections 2.2 and 4 against including additional information about an inactive token; that deviation is justified and governed by the caller-authorization and minimization rules below (Section 11.1). An AS MAY support OAuth 2.0 Token Introspection [RFC7662] for Mission-bound access tokens. When it does, the response for such a token carries, in addition to the standard members, a mission member: id and issuer (as in the mission claim, Section 9.2) plus, when the responding AS is the Mission issuer, the current lifecycle state (string); when derivation_limit (Section 10.1) is established, derivations_remaining (a number): the derivations left under the cap at the time of the response, counting committed issuances (Section 10), so a harness can plan refreshes against the budget; when the Mission records an authority proposal, proposal_hash (string): the Mission's proposal_hash (Section 8), surfaced for audit; and authority_hash (string), approval_basis (an object carrying type only), and authority_source (an object carrying type and, for organizational, policy with id and version only, never the policy digest): the Mission's own Authority Set commitment and provenance signals (Section 8), surfaced the same way for an audit or correlation consumer, never as an enforcement input (Section 9.3). Like state, only the issuer reports derivations_remaining, proposal_hash, authority_hash, approval_basis, and authority_source (Section 11.3). The core states are active, revoked, and expired (Section 10); a deployment that runs a companion profile defining an additional state reports that state here, and a consumer applies the forward- compatibility rule of Section 10 (only active permits reliance; any other value, recognized or not, is non-active). Only the issuer reports state (Section 11.3). The AS includes the mission member only when it has authenticated the caller, the caller is authorized for the token (Section 11.1), and the presented token resolves to a Mission. For a malformed, unknown, individually expired, or otherwise unresolvable token, the AS responds per [RFC7662] (active: false) with no mission member; it does not reveal Mission state for a token it cannot bind to a Mission. The case below (active: false with mission.state) applies only to a token that is itself valid but whose Mission is no longer active. The composite-active rule (Section 11.2) and the mission member apply equally when a Mission-bound refresh token is introspected. Freshness is per use: this document defines no caching semantics for the mission member, so a Resource Server that relies on introspection for Mission state treats each response as an observation for that decision, not as a cacheable state assertion. A deployment that needs bounded-staleness caching adopts the Mission Status companion, whose signed responses carry explicit freshness ([I-D.draft-mcguinness-oauth-mission-status]). 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. Disclosure is member-scoped as well as caller-scoped: derivations_remaining, proposal_hash, authority_hash, approval_basis, and authority_source serve the issuance-budget, audit, and correlation consumers, not Resource Server enforcement, and the AS MUST disclose each only to a caller the deployment has granted that member's disclosure privilege; an audience-authorized Resource Server receives the ordinary audience-filtered enforcement projection defined above, without them, by default. The same member-scoped rule governs any further mission member a companion profile defines for disclosure here. Such a member is disclosed only to a caller the deployment has granted that member's disclosure privilege, never by default, and it is audit and correlation metadata under this section's minimization rules, never an enforcement input (Section 9.3). This document defines no such member. 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.3). 11.4. Introspected Token Consumption The RFC 9068 JWT of Section 9 is this profile's self-contained carriage. An AS MAY instead issue a Mission-bound access token as an opaque reference token, under this mode and only under it; an opaque Mission-bound token outside this mode is not profiled (Section 9). * Introspection support is not optional here: an AS issuing opaque Mission-bound tokens MUST offer introspection for them with the members this mode names. * An active (active: true) response for such a token MUST carry, as introspection response members, the audience-filtered granted authorization_details ([RFC9396]), the mission member above, aud, cnf where the token is sender-constrained ([RFC8705], [RFC9449]), and act where execution was delegated (Section 12): everything Section 9 requires the JWT to carry, sourced from the same issuance state. * The granted authorization_details and any act chain appear only on an active response. An inactive response stays within the deviation this section already justifies: active: false with the mission state facts above, never the authority itself. * A Resource Server consuming an opaque Mission-bound token MUST resolve it through introspection before service, MUST verify active is true, its own identity in aud, and the sender-constraint binding cnf names, and MUST enforce the response's authorization_details under the same rules as the token-carried form (Section 9.3), the fail-closed duties included. * Introspection failure is refusal: a Resource Server that cannot obtain a valid introspection response for an opaque Mission-bound token MUST refuse the request rather than serve it from any cached or out-of-band belief about the token's authority. Freshness follows the section's per-use rule: this mode makes introspection the claims source, and each response remains one observation, never a cacheable authority record. 11.5. Examples While the Mission is active, the response is the standard [RFC7662] body plus the mission member. The canonical ERP token (Section 9.2), introspected at the issuer AS by a caller holding this deployment's audit-and-correlation disclosure privilege (hence authority_hash and proposal_hash below, absent from the default audience-filtered enforcement projection): { "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. Delegation Within a Mission This section is OPTIONAL. A deployment whose agents never delegate, and a Resource Server that sees no delegated tokens, are unaffected. An agent may delegate execution to downstream actors (a sub-agent, service, or tool that is itself an OAuth client) within a Mission. Delegation is represented with the OAuth Actor Profile [I-D.draft-mcguinness-oauth-actor-profile], which profiles the RFC 8693 [RFC8693] act (actor) claim. A delegate obtains a delegated token by Token Exchange ([RFC8693]). The AS issues the delegated token subject to all of the following: * *The exchange is explicit.* The delegating Mission-bound access token is the subject_token, with subject_token_type of urn:ietf:params:oauth:token-type:access_token. The delegate is identified by an actor_token (with its actor_token_type; for example, an attested client-instance assertion presented as urn:ietf:params:oauth:token-type:client-instance-jwt ([I-D.draft-mcguinness-oauth-client-instance-assertion])) or by its own client authentication, and the AS asserts the actor itself (Section 12.3); a requested_token_type of urn:ietf:params:oauth:token-type:access_token is used. The response carries the matching issued_token_type and a token_type for the issued access token, per [RFC8693] Section 2.2.1. * *Subject is stable.* sub remains the Mission's Subject. The delegate is an actor, not the subject. * *client_id keeps its ordinary meaning.* A delegated token's client_id is the OAuth client that requested it, per [RFC8693] Section 4.3 and [RFC9068] Section 2.2; this profile does not override that definition. The Mission's originally-approved agent is not named by client_id on such a token; it remains recorded in the Mission Record (Section 8). * *The act chain identifies the delegates.* The delegated token carries an act claim per the Actor Profile [I-D.draft-mcguinness-oauth-actor-profile] and [RFC8693]: the outermost act is the current delegate, with each earlier delegate nested inside the previous actor's act member (act.act), back through the chain. Each actor object carries the members that profile defines (sub, iss, and the RECOMMENDED sub_profile actor- type classification, e.g. ai_agent). This document does not re- specify the act structure. * *Authority only narrows.* The delegated token's authorization_details MUST be a subset (Section 5.1) of the delegating token's authority, hence of the Mission Authority Set. Delegation MUST NOT add authority. * *The Mission binding rides unchanged.* The delegated token carries the same mission claim (Section 9.2), its id and issuer (and any further member the baseline or an adopted profile carries) unchanged, so every actor in the chain operates under the one consented authority. * *Each delegate is bound to its own key.* The delegated token MUST be sender-constrained (Section 9) to the *delegate's own* key: its cnf is the delegate's DPoP or mTLS key, not the delegating party's. The delegate proves possession of that key in the Token Exchange. A compromised delegate key therefore cannot be replayed as the agent or as another actor in the chain, and each actor's credential is independently revocable by key. * *Each delegation is gated.* Issuing a delegated token is a derivation event; the AS MUST refuse it unless the Mission is active (Section 10). Delegation history follows authorization continuity, not organizational topology. The act chain nests (act.act) exactly while authority continues under the same approved Mission; a new approval basis, a Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]) or an expansion successor ([I-D.draft-mcguinness-oauth-mission-expansion]), begins its own delegation basis and its own chain; and no boundary of organization, network, or deployment topology by itself restarts or extends a chain. The chain is attribution, never authority: an act entry names who acted, for audit and as policy input to the eligibility matching of Section 12.3, while an asserted actor identity grants nothing, and a consumer MUST NOT treat the chain as proof that authority narrowed; the authorization_details subset relations prove that (Section 5.1). Where a deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-assertion]; for AI agents, its agent profile [I-D.draft-mcguinness-oauth-ai-agent-instance]), the delegate identified by the outermost act is the concrete instance: act.sub is the instance identifier and act.cnf is the instance-specific key. This profile's requirement that a delegated token be sender- constrained to the delegate's own key then lands on an instance- possessed key by construction. An allowed_delegates matcher can select instance-grade actors (Section 12.3), for example { "sub_profile": "client_instance" }. The sub_profile values used here (ai_agent, client_instance) are drawn from the entity-profiles vocabulary those instance profiles use; the Actor Profile [I-D.draft-mcguinness-oauth-actor-profile] remains the structural reference for the actor object. 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.3: 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.3). The routing rule of Section 9.3 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.2), 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 a type-defined delegation policy (Section 5.2) (for mission_resource_access, the delegation member, [I-D.draft-mcguinness-oauth-mission-resource-access]). 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 the entry's type defines a delegation policy for the entry and that policy, evaluated at depth d, permits this delegate; an entry carrying no type-defined delegation policy is non-delegable, the default. The AS applies the policy's own eligibility test at every exchange; where the policy leaves a matcher unstated, the AS's delegation-authorization policy decides, and absence is never a blanket grant. An entry failing this test narrows out of the delegated token, consistent with the subset rule (Section 5.1); the delegation policy is not part of the subset comparison itself, and a surviving entry carries it intact so the next hop is evaluated the same way. mission_resource_access's own delegation policy, the delegation member and its concrete depth and matcher conditions, is defined by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]). *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" } } 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. Extensibility This profile is a base layer that other agent-authorization work is expected to extend. Extensions build alongside the stable interface below; they MUST NOT redefine it. An extension MAY rely on these remaining stable across revisions of this profile: * the mission claim members id and issuer (Section 9.2); * the authorization_details carriage and its type-agnostic subset discipline (Section 5.2, Section 5.1); and * the act delegation chain (Section 12). The profile's extension points are each a declared seam rather than new machinery: * *Authority types.* The Authority Set is open to any AS-supported authorization_details type (Section 5.2); the Mission apparatus (commitment, gating, delegation) is type-agnostic toward every type, subject to the delegation and projection limits in Section 5.2. * *Intent Submission Evidence types.* The evidence array of the Submission envelope is open to evidence types defined by companion profiles (Section 4.3): each type is a collision-resistant name whose owning specification defines the entry's closed schema, verification, and verified output facts, and an AS refuses an entry of a type it does not support rather than ignoring it. * *Mission Intent members.* The Mission Intent's top level (Section 4) is open to additional members beyond those this document defines: a companion profile registers a short member name in the Mission Intent Members registry (Section 20.8) before using it, as the metering companion's consumption-bound members do ([I-D.draft-mcguinness-mission-metering]), or uses a collision- resistant name without registering it. Each such member is defined, produced, and enforced entirely by its owning specification; this document defines no generic extension container for them. An AS's closed-top-level validation (Section 4.1) recognizes exactly the members this document defines plus those of the companion profiles it implements, and refuses any other top-level member; a recognized member never grants or widens authority beyond what its owning specification states, and an AS ignores none of the members it recognizes. The registry resolves which specification owns a given short name before two independently implemented companions can collide on it; it does not itself make an AS implement, recognize, or trust any member, registered or not. * *Integrity anchors.* Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (Section 7.1). A consent-disclosure commitment, an instruction- text attestation, or a delegation receipt can be committed this way without changing this profile. A profile that commits an evidence or disclosure object MUST commit it with this envelope and a collision-resistant typ, not by hashing the bare object, so the domain separation and issuer binding hold uniformly. A mission descriptor embedded in such an object uses the mission claim shape (Section 9.2), optionally extended with collision- resistantly named members (for example, an intent_hash for audit), and is never authority-bearing on its own. * *The mission claim.* It is an open object (Section 9.2): additional, collision-resistantly named members ride the mission binding (for example, a runtime decision reference, a delegation receipt, or an attestation reference), and consumers ignore unknown members and never derive authority from them. * *Lifecycle state.* The lifecycle state space (Section 10) is open to additional states registered by companion profiles for lifecycles they introduce, in the Mission Lifecycle States registry (Section 20.7). The forward-compatibility rule in Section 10 keeps this safe regardless: only active permits issuance, and a consumer treats every other state, recognized or not, as non-active. * *Approval-event sequencing.* The approval-event steps, their order, and the atomicity of record creation with the approval decision are the model's (Section 6); the coupling of that decision to authorization-code issuance is this flow's. A companion profile MAY relocate the approval event relative to code issuance (for example, deferring the decision beyond the authorization response), provided the steps and their atomicity hold unchanged and no Mission reference exists before the record is active; the Mission Deferred Approval companion is such a profile ([I-D.draft-mcguinness-oauth-mission-approval]). This document defines no capability-negotiation mechanism or profile- version field; an extension declares its own identifiers and, where it needs discovery, its own metadata. The extensibility of the typ value space and the mission claim rests on collision-resistant naming and the fail-safe rules above rather than on central registration; the lifecycle state space is additionally backed by the Mission Lifecycle States registry (Section 20.7). Section 13.1 states the general rule this section's extension points follow. 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 Lifecycle States (Section 20.7) is this document's; the Mission Common Constraints registry is established by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]); 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). 14. Authorization Server Metadata An AS MAY advertise support for this specification in its authorization server metadata [RFC8414]: mission_bound_authorization_supported: OPTIONAL boolean. When true, the AS supports the core Mission Issuer surfaces of this profile (Section 16): the mission_intent authorization request parameter through PAR (Section 4), derivation of authorization_details entries of its supported types (Section 5, Section 5.2), Mission- bound access tokens (Section 9), and the mission JWT claim (Section 9.2). It asserts Mission Issuer support only; it makes no claim about any Resource Server, nor about the OPTIONAL capabilities (delegation, introspection, cross-domain projection), which are discovered out of band or by attempt (Section 16). An AS that advertises this profile MUST include at least one AS- supported type in its authorization_details_types_supported metadata ([RFC9396]): the approved-set commitment a Mission-aware client relies on. Where mission_resource_access is among them, the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]), not out-of- band documentation, is that type's normative definition. A client MAY use the RFC 9396 client metadata authorization_details_types at registration to declare the types it understands. Each supported type's transformation-capability declaration, whether the AS understands the type's narrowing, delegation, and scope- projection semantics, is required by Section 5.2. Deployment documentation naming the type as supported is always a sufficient carrier for it; where the AS advertises the schema endpoint below, it MAY additionally carry the declaration machine-readably as a mission_transformation_capabilities member of the type's entry, letting a client establish the boundary without an out-of-band lookup. An advertised type, mission_resource_access included, appears in authorization requests only as a proposal subject to derivation (Section 4.2): a client submits entries of advertised types on the authorization_details parameter alongside mission_intent, and the AS derives, narrows, or refuses under Section 5. The granted entries on issued tokens and echoes are issuer-derived, never the submission carried through by right. Discovery is OPTIONAL: a deployment MAY arrange Mission-bound authorization out of band, and this member only lets an AS advertise it. When the member is absent or false, a client MUST NOT infer that the AS supports this specification. A client holding a Mission Intent MUST NOT silently downgrade the task to an ungoverned authorization request against an AS whose support is not advertised and not otherwise established: submitting the same authority as bare scope or authorization_details obtains tokens no Mission governs, the client-side face of downgrade by omission (Section 17.1.2). The client surfaces the inability instead; where the estate's AS cannot change, the standalone Mission Issuer binding is the governed alternative ([I-D.draft-mcguinness-mission-authority-server]). An AS that advertises mission_bound_authorization_supported: true MUST also publish pushed_authorization_request_endpoint ([RFC9126]), since a Mission Intent is accepted only through PAR (Section 4.1). An AS that advertises mission_bound_authorization_supported: true SHOULD also advertise authorization_details_types_metadata_endpoint [I-D.draft-zehavi-oauth-rar-metadata] where it implements that endpoint; the endpoint is defined by an individual draft without formal standing, and conformance to this document does not depend on it. The stable baseline is [RFC9396]: authorization_details_types_supported listing at least one AS- supported type (a MUST for an advertising AS, above); where mission_resource_access is among them, the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]) is its normative definition. Where the endpoint IS advertised: its response is a JSON object keyed by authorization_details type identifier, each value carrying, per [I-D.draft-zehavi-oauth-rar-metadata], a JSON Schema for exactly one authorization_details object of that type (schema or schema_uri) and optionally version, description, documentation_uri, and examples; its key set is then the source of truth for which types the AS supports, and authorization_details_types_supported, where the AS also advertises it, mirrors those keys and MUST NOT list a type absent from them; and the AS MUST publish, within that response, an entry for every supported type whose schema validates that type's documented object shape. For mission_resource_access, that shape, including the Common Constraints structure, is the Mission Resource Access Profile's ([I-D.draft-mcguinness-oauth-mission-resource-access]). Where a deployment arranges Mission-bound authorization out of band rather than advertising mission_bound_authorization_supported, the supported types and their schemas are likewise established out of band. This member and the mission_bound_authorization_required member of Section 15 are unauthenticated discovery data: their integrity rests on the metadata retrieval protections of [RFC8414] and [RFC9728], whose security considerations apply. 15. Protected Resource Metadata A protected resource MAY advertise, in its protected resource metadata [RFC9728]: mission_bound_authorization_required: OPTIONAL boolean. When true, the protected resource accepts only Mission-bound tokens: a token that lacks the mission claim (Section 9.2) is rejected (Section 9.3). When absent or false, the resource makes no such requirement. A type-defined authorization_details member may define its own constraint-discovery surface; mission_resource_access's is defined by the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]). 16. Conformance The smallest useful conforming deployment is a Mission Issuer that derives in narrowing mode from the client's authority proposal (Section 5), supports one AS-supported authorization_details type and emits only that type's specification-defined vocabulary, and implements none of the OPTIONAL capabilities; a scope-only Resource Server is served only where the AS established a safe scope projection for it (Section 9.1). This note names a starting point and creates no new conformance class. A Mission Issuer MAY instead reach that starting point through configured-mapping mode, the low-integration on-ramp (Section 5), which is equally conforming and adds no conformance class. An implementation conforms in one of three roles. A *Mission Issuer* (the Authorization Server) implements the core issuance surfaces: * submission of a Mission Intent, in the Submission envelope, via PAR (Section 4.1), with the Intent Submission Evidence dispatch and refusal rules (Section 4.3); * derivation of authorization_details entries of its supported types (Section 5, Section 5.2); * the approval event with its integrity anchors and its recorded approval_basis and authority_source (Section 6, Section 8); * issuance of Mission-bound access tokens carrying the mission claim (Section 9), as the RFC 9068 JWT or as an opaque reference token under the introspected consumption mode, whose introspection support is then REQUIRED (Section 11.4); * the subset rule (Section 5.1); and * gating of issuance on Mission state (Section 10). A *Mission-aware Resource Server* implements Resource Server enforcement (Section 9.3), from the token's own claims or from its active introspection response under the introspected consumption mode (Section 11.4). A *Mission Client* implements the client surfaces: * submission of the Mission Intent via PAR only (Section 4.1), proposing concrete authority, where it does, on the authorization_details parameter pushed alongside mission_intent (Section 4.2); * reading its granted authority from the token-response authorization_details echo (Section 9); and * obtaining mission_id from the mission_id token-response parameter or the mission claim's id (Section 6.2), treating it as a reference, never a credential. Beyond these mandatory roles, an implementation MAY additionally claim four OPTIONAL capabilities. Each is independent, and an implementation that supports none of them is still conformant: * *Delegation* (Section 12): issuing and consuming derived tokens that carry the act delegation chain. * *Introspection* (Section 11): reporting Mission state through the mission token introspection response member. OPTIONAL as a state overlay for JWT deployments; REQUIRED where the AS issues opaque Mission-bound tokens (Section 11.4). * *Cross-Domain*: projecting a Mission so it is honored by an Authorization Server in another trust domain. An implementation claiming this capability preserves, across the hop: the Mission reference (mission.id, mission.issuer, authority_hash) carried intact; authority that only narrows (Section 5.1); projection performed only by, or under the authorization of, the Mission issuer, gated on the Mission's active state (Section 10); and projected credential lifetimes capped by the Mission's expires_at (Section 9). This bar is self-contained in this document; the companion Mission Cross-Domain Projection profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]) specifies the interoperable mechanism that satisfies it, and implementations that interoperate across the hop implement that companion. * *Local Approved-Set Verification* (Section 9.4): a Mission-aware Resource Server or policy decision point independently recomputing and subset-checking a Mission's complete approved Authority Set, rather than relying on the token signature and the AS's subset assertion alone. An implementation claiming this capability states which tier it supports, Tier 1 alone or Tier 1 with Tier 2 (Section 9.4.1), and fails closed under Section 9.3 whenever the retrieval, recomputation, or subset check it depends on cannot complete for a given request, never treating that one request as though the capability were unclaimed. This capability's activation, and which tier and retrieval surface a deployment has provisioned, are established out of band between the claiming party and the Mission Issuer, the same way the retrieval surface itself is (Section 9.4.1); this document defines no discovery metadata for it. A conforming implementation names the optional capabilities it supports (for example, "Mission Issuer with Delegation and Cross- Domain"); each capability's defining section or document states its detailed requirements. A token carrying a mission claim is not, by itself, Mission-bound authorization. Conformance as a Mission Issuer requires the gates: authority derived from the approved Intent and committed by the anchors (Section 6), issuance bounded by the subset rule (Section 5.1), and derivation gated on Mission state (Section 10). An implementation that carries Mission metadata without these gates conforms to no role in this document and does not implement it: in particular, it MUST NOT advertise mission_bound_authorization_supported as true (Section 14), the machine-checkable form of that claim. The Mission Binding Properties vector of [I-D.draft-mcguinness-mission-architecture] names this discharge as its credential-mission-bound property, informatively; these gates remain authoritative for OAuth binding conformance regardless. The mission_bound_authorization_supported metadata (Section 14) advertises Mission Issuer support only. It makes no assertion about any Resource Server, which does not advertise through Authorization Server metadata. The OPTIONAL capabilities are discovered first through existing OAuth metadata ([RFC8414]): introspection_endpoint for introspection, and grant_types_supported containing urn:ietf:params:oauth:grant- type:token-exchange for delegation and for the companion's cross- domain grant issuance. Absent such a signal, a capability is discovered out of band or by attempt: a Token Exchange, a cross- domain grant issuance, or an introspection request fails if the issuer does not support it. Local Approved-Set Verification has no OAuth metadata signal of its own: it is a Resource Server or policy decision point's own claimed capability, never something an Authorization Server advertises, so its activation is established out of band by construction, not merely absent a signal (Section 9.4). This binding publishes its own Mapping Assessment of how the surfaces above realize the Mission Substrate contract's kernel and capabilities (Appendix D). It is not this document's conformance result: this document makes no substrate-conformance claim, takes no requirement from the substrate, and remains self-contained; its reference to the substrate contract ([I-D.draft-mcguinness-mission-substrate]) is informative. 17. Security Considerations 17.1. Commitment and Consent Integrity 17.1.1. Consent Binding The security goal of this document is that a user's approval of a task bounds every token derived for it. The authority_hash commits the exact Authority Set the Approver consented to, recorded on the Mission (Section 8); the security goal rests on the AS deriving only subsets of that set and signing every token accordingly, not on every token carrying the commitment itself (Section 9.2). The complete mechanism also requires the AS to issue only subsets of that set and the Resource Server to verify the AS's token signature and enforce the carried authority. The hash alone, where a token or a profile carries it, does not prove containment of a narrowed token's authority. The requirements that uphold the commitment live at the approval event (Section 6): the AS computes authority_hash over the same Authority Set it rendered for consent, and re-renders and re-consents if that set changes. authority_hash commits the full Authority Set, while a derived token may carry a narrowed subset, so a Resource Server cannot in general recompute it from the token alone. Recomputation, where a Resource Server undertakes it, is the Local Approved-Set Verification profile (Section 9.4); a Resource Server outside that profile enforces the token's authorization_details directly (Section 9) and, where the deployment discloses authority_hash to it at all (introspection's disclosure privilege, Section 11.1, or a companion profile's own copy, such as cross-domain's, [I-D.draft-mcguinness-oauth-mission-cross-domain]), treats it as a whole-Mission audit and correlation anchor. It relies on the signed token as the AS's assertion that the carried authority was correctly projected from the approved set; authority_hash supplies no independent subset proof by itself. This document's flat Authority Set commitment defines no selective inclusion-proof mechanism by itself: authority_hash digests the complete set as a single array (Section 7.1), so recomputing it needs the full set. The Local Approved-Set Verification profile (Section 9.4) defines the retrieval and fail-closed rules for a party that recomputes it this way, split into the Tier 1 projection-error check and the Tier 2 independently-pinned check (Section 9.4.1), and identifies the minimum properties a typed selective-inclusion proof would need as a future composition point, without defining such a type itself (Section 9.4.2). Retrieval carries a real privacy and authorization burden rather than an architectural prohibition: the minimization rules of Section 11.1 keep other audiences' entries out of token introspection, so that profile's retrieval surface needs authorization at least that strong. A future selective proof would compose with the existing subset rules: it would commit the approved entries to a structure that supports inclusion proofs, prove the approved parent entry against that approval-time root, and apply the type-specific subset test (Section 5.1) between the carried narrowed entry and the disclosed parent; the cryptography stays generic, and only the semantic comparison is type-owned, the division this document uses throughout. A deployment that needs assurance independent of the token signature provisions the verifying party out of band, the Resource Server itself or a policy decision point holding a materialized view of the Mission record, and adopts the Local Approved-Set Verification profile (Section 9.4). What such verification buys depends on when the issuer is compromised. Tier 1 retrieval issued under the same trust root as the token adds nothing against an issuer malicious at approval time: that issuer can approve and commit arbitrary authority, and no containment mechanism changes that. The same checks do defend against projection implementation errors, against corruption of the record after an independently anchored approval commitment, and against post-approval signing-key compromise where the original commitment is pinned outside the issuer under Tier 2. The pinning is what makes the difference; Section 9.4.1 lists the retention point, trust basis, and retention rule a deployment declares to get it. intent_hash extends the same protection to the task itself: it commits the approved Mission Intent, so an auditor can detect any later alteration of the recorded task, independently of the authority derived from it. proposal_hash, present when the client submitted an authority proposal (Section 4.2), commits what the agent asked for: approval-time provenance that lets an auditor compare the narrowed grant against the request that sought it. The anchors are domain- separated (Section 7.1); none is a substitute for another. The task and the authority are committed separately, rather than folded into one hash over the whole Mission, because they are distinct objects with distinct uses. authority_hash commits what a Resource Server enforces and what a cross-domain projection carries, so it MUST be verifiable from a token that conveys only the authority, without the Intent. intent_hash commits the task as audit material, tamper-evident even where the authority is projected without the Intent traveling with it. One combined hash could not serve both a token that carries authority alone and an auditor that holds the task alone. Neither anchor proves the Approver understood the rendered task, nor that the AS rendered it faithfully; they commit what the AS recorded, and make post-hoc tampering of those records detectable. This profile commits the task (intent_hash) and the authority (authority_hash) the Approver consented to, but deliberately does not commit the *rendered consent disclosure* itself: the locale, disclosure-template version, and material notices the Approver was shown are not bound by any anchor here. Because of this gap, a buggy or malicious rendering layer could mislead the Approver, showing a narrower or different task than the Authority Set actually committed, without leaving any committed trace. A deployment whose Missions carry high-risk authority SHOULD therefore record presentation-level audit evidence: for example, a hash over the exact consent disclosure rendered to the Approver, retained so the disclosure shown can be reconstructed and audited after the fact. Binding this on the wire (a consent_rendering_hash over a structured consent-disclosure object) is specified as an OPTIONAL companion profile by Mission Consent Evidence [I-D.draft-mcguinness-oauth-mission-consent-evidence]; an AS that does not implement it MAY record equivalent evidence out of band. As that profile makes explicit, such a commitment binds the structured disclosure the AS records, not the pixels actually presented; it narrows this gap for audit but does not close it. 17.1.2. Downgrade by Omission A token bearing equivalent authorization_details but no mission claim is governed by no Mission state, revocation, or consent commitment. A deployment that designates a resource Mission-governed MUST NOT issue tokens for that resource outside a Mission, except under documented policy exceptions. The same rule has a per-client form: a deployment MAY register a client as Mission-governed, and an AS MUST reject a bare authorization_details request, one carrying no mission_intent, from a client so registered, so a governed client cannot strip the Intent from its submission to obtain ungoverned tokens; the client-side face of this duty is stated in Section 14. On the enforcement side, a Resource Server for such a resource rejects a token lacking the mission claim (Section 9.3), and MAY advertise the requirement through mission_bound_authorization_required (Section 15). 17.2. Agent-Specific Threats 17.2.1. Prompt Injection and the Exfiltration Leg An agent that reads attacker-influenceable content can be prompt- injected; this profile assumes that and does not try to make the agent immune. Injection is dangerous when one agent combines access to private data, exposure to untrusted content, and the ability to communicate externally; the robust defense is architectural, constraining one of those, not making the model resistant. This profile constrains the data-access leg: a Mission narrows authority from everything the agent's standing credentials allow to the resources the approved task needs, and per-task Missions (Section 1.4) shrink the blast radius further. It contributes one thing against the untrusted-content leg: success_criteria is inert, granting, widening, and gating no authority, and goal and purpose shape authority only through the pre- approval derivation whose result the Approver reads and consents to (Section 4, Section 5); authority is fixed at the approval event, so injected text cannot talk an approved Mission into expanding itself. This profile does not constrain the external-communication leg and provides no information-flow control. It models authority over resources and actions, not how an agent uses authority it holds: within an approved Authority Set, an injected agent can read what the Mission permits and write to a sink the Mission permits, and the flat subset and constraint model cannot express "may read secrets, may write documents, but not write secrets into documents." Constraining exfiltration by a compromised agent is the runtime enforcement layer's role (Section 17.3.1), and even there it is bounded, not closed (see that profile's security considerations). Closing within- scope data laundering needs a separate taint or information-flow layer this profile does not define. 17.2.2. Authority Does Not Propagate With Information Issuance gating bounds escalation by token acquisition (Section 10, Section 5.1): an agent cannot exceed the approved task by acquiring additional tokens. The same bound holds for information. No authority may be acquired by information propagation alone. An agent may inherit another agent's knowledge; it never inherits another agent's authority. Information may cross a boundary without authority crossing with it. A work product produced under one Mission, such as a file, message, memory entry, queue event, or other durable shared artifact, is input when an agent operating under another Mission reads it, not authority. The receiving Mission determines what may be done with the information under its own Authority Set (Section 5.1), and the producing Mission's authority does not transfer through the artifact by copying, referencing, embedding, or communicating it. An agent that needs authority to act on what it read acquires it only through an authorized derivation or delegation bounded by the Mission (Section 12), never from the artifact. This extends a possession-independence the profile already requires. Revocation acts on the mission_id independent of possession of any token (Section 10.3); here, authority is likewise independent of possession of any information. It is not information-flow control, which this profile does not provide (Section 17.2.1): the profile does not constrain what agents communicate, only what that communication can confer. Coordination between agents remains possible and cannot route around Mission authority. The threat is emergent authority through coordination. Multiple agents executing independently bounded work communicate through shared state, so discoveries, credentials, techniques, or intermediate results persist across runtimes and Missions, and individually acceptable actions compose into behavior that no single Mission authorized. This differs from a compromised or multiplied agent acting within one Mission's Authority Set: the composing units are independent Missions coordinating through a carrier outside any Mission's gate. The mechanism that upholds the invariant across such a carrier, work-product provenance and a non-transitive Mission-to- Mission handoff, is specified by Mission Work Products [I-D.draft-mcguinness-oauth-mission-work-products]; this document takes no normative dependency on it. 17.3. Enforcement Boundaries 17.3.1. Issuance Scope, Not Runtime Enforcement This profile governs the issuance and derivation of authority: it bounds what authority a Mission yields, binds it to the Approver's consent, and gates derivation on Mission state. It does not evaluate individual runtime actions. In particular, it does not: * evaluate a request's parameters against the Mission at the point of use; * produce runtime enforcement evidence for each consequential action; * bind tool or function identities to the Mission; or * re-evaluate at execution time to close the approval-to-execution (time-of-check to time-of-use) gap. Mission governance is necessary but not sufficient. An active Mission still bounds a set of authority an agent may exercise freely within a token's lifetime, so an active Mission can become ambient authority for individual consequential actions. Preventing that requires a runtime enforcement layer that evaluates each consequential action against the Mission and records evidence; such a layer composes with this profile and is out of scope here. Which party enforces each Mission-carried bound is summarized in the enforcement table (Section 4). Short token lifetimes and narrow authority bound, but do not eliminate, this exposure. Where the Resource Server or a composing runtime layer matches a concrete request URI against a prefix entry, the single-normalization rule of the Mission Resource Access Profile's Resource Boundary Canonicalization analysis ([I-D.draft-mcguinness-oauth-mission-resource-access]) binds that match the same way, for a deployment that supports that type. 17.3.2. Denial Detail Disclosure The mission_denial attribute (Section 9.3) and the RFC 9470 insufficient_user_authentication challenge (Section 9.3) each tell a caller which path a denial leads into, and thereby reveal authorization shape: an insufficient_user_authentication challenge confirms to the presenting party that the authority exists and only the token's own associated authentication is weak or stale, where mission_denial: insufficient_authority denies the authority's existence outright. Introspection guards the same class of fact behind caller authorization (Section 11.1); a Resource Server applies the same care here. It SHOULD return the attribute only on a response to a validly signed, audience-correct token whose holder its deployment accepts learning the distinction, and SHOULD omit the attribute otherwise; when in doubt, insufficient_authority is the value that reveals least, and omission reveals nothing. 17.4. Credentials and Delegation 17.4.1. Token Theft Derived tokens are sender-constrained (DPoP [RFC9449] or mTLS [RFC8705]) at the levels set in Section 9 and Section 12: SHOULD for the primary access token, MUST for delegated tokens; the companion sets the same MUST for its cross-domain credentials ([I-D.draft-mcguinness-oauth-mission-cross-domain]). A stolen token is bounded by the Authority Set and the Mission lifetime regardless, but sender-constraint prevents replay by a different party. 17.4.2. Delegation and Chain Compromise Delegation (Section 12) widens the set of parties holding Mission- derived authority. Because authority only narrows down the chain, a compromised actor can act only within the authority it was delegated, for the lifetime of the token it holds: the exposure of any actor is bounded by its narrowed authorization_details times its token lifetime. The per-entry delegation constraints (Section 12.3) bound this exposure at approval time: non-delegable entries never reach a delegate at all, max_depth caps how far an entry can propagate, and allowed_delegates restricts who may receive it. Note that max_depth bounds the _length_ of a delegation chain, not its _breadth_: fan-out to many distinct depth-1 delegates is bounded only by allowed_delegates, so a deployment that needs to limit breadth MUST constrain allowed_delegates (and MAY use derivation_limit to cap total derivations, Section 10.1). Because each delegated token is bound to the delegate's own key (Section 12), a compromised delegate is confined to its own narrowed credential: it cannot replay as the agent or another actor, and its credential can be revoked by key without revoking the rest of the chain. Deployments SHOULD keep delegated token lifetimes short and SHOULD make only the entries that need delegation delegable. A distinct path deserves its name: audience replay into the exchange. A Mission-bound token obtained by or issued to one party, presented as a subject_token, would launder into a fresh delegated credential bound to the presenter. The gates above bound it: the exchange is a derivation gated on Mission state, the AS applies delegation- authorization policy at every exchange (Section 12.3), the result is bound to the authenticated delegate's own key and narrowed by the subset rule, and a no-actor exchange is accepted only from the Mission's approved agent (Section 12.2). Sender-constraining the primary token (Section 9) closes the remaining gap, since a token stolen from an audience then fails presentation at the token endpoint. 17.4.3. client_id Conformance and the Approved-Agent Residual Because this profile keeps client_id's ordinary [RFC9068] meaning (Section 12.1), a generic [RFC9068] Resource Server, or a logging, SIEM, or audit pipeline built for ordinary OAuth tokens, that keys identity and attribution on client_id attributes a Mission-derived token, delegated or not, to the correct requesting client without needing to understand this profile. What such a component cannot see is different from misattribution: it has no visibility into the delegation lineage carried in the act chain (Section 12), and it has no way to look up the Mission's originally-approved agent, which this profile does not carry in client_id and instead leaves recorded in the Mission Record (Section 8) at the issuer. A component that authorizes or logs on the approved agent's identity, or that must join a delegate's action back to the Mission's approval, MUST NOT assume client_id carries it. A deployment that delegates MUST route delegated Mission-bound traffic, including to logging and audit infrastructure, only through components that process the act chain (Section 9.3), and SHOULD review any existing component that authorizes or logs solely from client_id for this gap before exposing it to delegated Mission-bound tokens. 17.4.4. Signing and Key Rotation The mission claim and authorization_details are carried inside the [RFC9068] JWT and are covered by the AS's token signature; their integrity reduces to the AS's signing key. An AS MUST publish its verification keys (for example, via [RFC8414] jwks_uri), and the retired-key rule is: rotation retires a key from signing, never from resolvability within its retention bound. For this document's artifacts the floor is token lifetime: a verification key stays resolvable while tokens signed under it remain valid. Verification for audit outlives validity, so the key SHOULD remain resolvable at least as long as the audit horizon (Section 8) of any Mission whose tokens were signed under it. A companion that anchors a longer-lived artifact to the same keys (a status assertion, a Mandate, registered evidence) states its own retention bound as an extension of this same rule, not a new one. Revocation for a known or suspected compromise is distinct from routine retirement: the issuer publishes the compromised key as revoked, or marks it with a compromise time, rather than silently rotating it out. Key custody carries the model: a compromised issuer signing key voids every guarantee the signature carries. Issuer signing keys SHOULD be held in non-exportable or HSM/KMS-grade custody with dual-controlled generation, and SHOULD be segmented by artifact class under distinct kid values within the one jwks_uri, so that high-value, low-volume signing (long-lived evidence and portable artifacts) can sit under stricter custody than high-volume online token signing; verification is already kid-indexed, so the segmentation needs no wire change. Recovery from a signing-key compromise is deployment-owned and belongs in the deployment's documented procedures. 17.5. Composition and Residual Authority 17.5.1. Compromised or Over-Broad Derivation The AS is trusted to derive authority no broader than the Mission Intent. Both derivation modes (Section 5) are mechanical, a proposal narrowed to policy or a configured mapping, rather than free-form inference, and the recorded policy_version names the policy a derivation ran under so the derivation can be audited. General OAuth security guidance [RFC9700] applies. 17.5.2. Authority Hash Is Not a Mission Identifier authority_hash commits the approved Authority Set, not the Mission. Two distinct Missions that approve byte-identical authority carry the same authority_hash: a successor Mission that re-approves the same Authority Set, or an unrelated Mission with the same derived authority, differs in its intent_hash, approver, and id while sharing the authority_hash. It is therefore not globally unique to a Mission and MUST NOT be used as a Mission Identifier or as a replay or idempotency key for a Mission. The canonical Mission Identifier names the Mission; authority_hash names the authority the Mission approved. A consumer that needs to bind to or correlate a specific Mission uses the Mission Identifier, and intent_hash and approver distinguish Missions that share an Authority Set. 17.5.3. Composition and the Effective Ceiling Delegation depth (Section 12.3) resets to 0 at each cross-domain hop ([I-D.draft-mcguinness-oauth-mission-cross-domain]) and, where a deployment runs the child-delegation profile, at each child generation ([I-D.draft-mcguinness-oauth-mission-child-delegation]). derivation_limit (Section 10.1) is a per-Mission bound the issuer AS enforces for that Mission alone; a Child Mission's own derivation_limit is independent of its parent's, and the parent's cap does not bound the child subtree by default. The aggregate surface a Mission's descendants can reach, the product of delegation depth, the number of trust domains projected into, and the number of child generations, together with the derivations summed across an entire child subtree, can therefore exceed what a single approval appears to bound at consent time. This is a composition property of independently-bounded mechanisms, not a defect in any one of them. An informative illustration with the variables explicit: a child- delegation deployment allowing max_children 3 per Mission with max_child_depth 2 admits up to 12 descendant Missions (3 in the first generation, up to 9 in the second), each with its own independent derivation_limit; at 10 each, the subtree admits up to 120 derivations while no single bound the Approver saw exceeds 10. Cross-domain projection composes separately: a projected grant preserves the Mission's lineage rather than rooting a new one, and the Resource AS's local issuance under it is bounded by that grant's own lifetime and local policy, not counted against the origin issuer's per-Mission derivation cap. A deployment SHOULD disclose the composed bound, not only the immediate Mission's, at the consent surface, and MAY impose a global cap out of band where a single approval's apparent bound must hold in practice. Bounding aggregate consumption (calls, spend, or activity over the life of a Mission and its descendants) is the metering profile's role ([I-D.draft-mcguinness-mission-metering]), not a property this document or its composition partners provide by themselves. 17.5.4. The Containment Materialized-Capability Residual Where a deployment runs the Mission Containment profile ([I-D.draft-mcguinness-oauth-mission-containment]), containment narrows an Authority Set entry's authorization to derive going forward and propagates to Child Missions justified by that entry, per that profile. It does not reach back into authority already materialized before the containment transition: a cross-domain grant already redeemed at a Resource AS ([I-D.draft-mcguinness-oauth-mission-cross-domain]), or an offline attenuation root already minted and now attenuating on its own outside the issuer's reach, continues to operate for its own remaining lifetime. This is the same residual bound that revocation carries (Section 10.3): a party that already holds a materialized credential is bounded by that credential's own lifetime, not by a state change at the issuer it can no longer observe in time. A deployment that needs containment to take effect quickly against already-materialized authority SHOULD keep cross-domain grant and offline attenuation root lifetimes short, so the residual window is one the next lease or re-mint closes. 18. Internationalization Considerations Mission Intent prose (goal, task_bounds, success_criteria) is human- readable disclosure, and the Approver's consent is only as good as their comprehension of it. goal_lang (Section 4) declares the language of that prose as a BCP 47 language tag [RFC5646], so an approval surface can render, translate, or route it deliberately rather than by guess. Three rules keep the declaration honest: * goal_lang is a syntactic declaration. The AS validates well- formedness ([RFC5646], Section 2.1) at submission acceptance and refuses a malformed tag invalid_request; it does not verify that the prose is in the declared language, and a consumer MUST NOT treat the tag as a verified property of the text. * Rendering to the Approver follows the consent-binding rules unchanged (Section 17.1.1): client prose stays inert text in any language and any script, including bidirectional text. Where the approval surface presents a translation, the rendered disclosure is what the deployment's consent evidence records (Mission Consent Evidence binds one locale, one disclosure, one hash, [I-D.draft-mcguinness-oauth-mission-consent-evidence]); goal_lang declares the source's language and is never a record of what was rendered. * Authority Set entries carry machine-facing identifiers (URIs, action strings, structured constraints), not prose; this document deliberately adds no language-tagged display fields to them. Localizing how authority is explained is the approval surface's duty under Section 17.1.1, never a property of the committed set. 19. Privacy Considerations A Mission Identifier is a correlation handle: a deployment limits exposure by giving stable Mission Identifiers only to parties that enforce, audit, or observe that Mission, preferring audience-scoped projections of authority where possible, and minimizing status and introspection disclosures to authorized callers. The subsections that follow and the introspection minimization rules (Section 11.1) give the specific rules. An Intent Submission Evidence artifact can carry personal data (an originator identity, a consent reference); PAR keeps it off the front channel, and the record retains the designated verified facts under the same access governance as the rest of the Mission's evidence (Section 19.5). 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, task_bounds) 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, task_bounds, success_criteria) and purpose; * target_resources and any explicit member a companion profile defines (for example, the metering companion's consumption bounds, [I-D.draft-mcguinness-mission-metering]); * any type-owned member of a proposed entry, and the derived Authority Set entries that reach tokens (Section 9); * 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, task_bounds, 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. IANA Considerations 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.2 * 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.2 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.3), 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. This document keeps invalid_mission_intent_evidence as its own error rather than folding it into invalid_request: a typed evidence extension (Section 4.3) is genuinely involved, and a client that can distinguish a malformed submission from missing or untrusted evidence can remedy each differently, which a single generic code would not let it do. 20.3. 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. An open object; additional members may be present and are ignored if unknown. * Change Controller: IESG * Specification Document(s): this document, Section 9.2 20.4. 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.2); a response from the Mission's issuer additionally carries a state member giving the current lifecycle state, and, to a caller holding the disclosure privilege for the member, derivations_remaining where a derivation cap is in force, proposal_hash where the Mission records an authority proposal, and authority_hash, approval_basis, and authority_source (Section 11). * Change Controller: IESG * Specification Document(s): this document, Section 11 20.5. 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.6. 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 20.7. Mission Lifecycle States Registry IANA is requested to create the "Mission Lifecycle States" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for the discipline Section 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: +=========+==========+====================+============+===========+ | Value | Terminal | Semantics | Change | Reference | | | | | Controller | | +=========+==========+====================+============+===========+ | active | no | Tokens MAY be | IETF | this | | | | derived; the only | | document, | | | | state from which | | Section | | | | issuance proceeds. | | 10 | +---------+----------+--------------------+------------+-----------+ | revoked | yes | Terminated by the | IETF | this | | | | Subject, Approver, | | document, | | | | or policy. | | Section | | | | | | 10 | +---------+----------+--------------------+------------+-----------+ | expired | yes | The Mission's | IETF | this | | | | expires_at has | | document, | | | | passed. | | Section | | | | | | 10 | +---------+----------+--------------------+------------+-----------+ Table 6 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. 20.8. Mission Intent Members Registry IANA is requested to create the "Mission Intent Members" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for: a Name not already registered by a different owning specification; and a Semantics sentence naming what the member means and which specification defines its schema, production, and enforcement in full. This registry resolves ownership of a short top-level name so two independently implemented companions cannot assign it incompatible schemas; it does not itself define member semantics, and registering a name confers no authority and does not make any AS recognize, implement, or trust it (Section 13). A companion profile MAY instead use a collision- resistant name and skip registration entirely; registration is how a _short_ name stays available for reuse across the family. Registration does not require IETF review or a Standards Track document; a Specification Required reference a Designated Expert can review against these criteria suffices. Each registration records: * *Name*: the member's top-level key in the Mission Intent. * *Status*: stable or experimental. An experimental entry's owning specification has not completed that specification's own promotion criteria for the member; a Designated Expert MUST NOT register a member stable on a specification's unverified say-so, and MUST NOT treat registration itself as a promotion event for an experimental member. * *Semantics*: one sentence stating what the member means and pointing to the section that fully defines it. * *Change Controller*: IETF, or the registrant for any other registration. * *Reference*: the specification defining the member. This document seeds the registry with the members it defines itself: +==========================+======+===========+==========+=========+ |Name |Status|Semantics |Change |Reference| | | | |Controller| | +==========================+======+===========+==========+=========+ |goal |stable|The |IETF |this | | | |Mission's | |document,| | | |plain- | |Section 4| | | |language | | | | | |objective. | | | +--------------------------+------+-----------+----------+---------+ |goal_lang |stable|BCP 47 |IETF |this | | | |language | |document,| | | |tag for | |Section 4| | | |goal. | | | +--------------------------+------+-----------+----------+---------+ |target_resources |stable|Client- |IETF |this | | | |requested | |document,| | | |derivation | |Section 4| | | |ceiling and| | | | | |template- | | | | | |mode lookup| | | | | |source. | | | +--------------------------+------+-----------+----------+---------+ |task_bounds |stable|Non- |IETF |this | | | |machine- | |document,| | | |readable | |Section 4| | | |prose | | | | | |bounds on | | | | | |the task. | | | +--------------------------+------+-----------+----------+---------+ |purpose |stable|Prose |IETF |this | | | |purpose | |document,| | | |statement. | |Section 4| +--------------------------+------+-----------+----------+---------+ |expires_at |stable|Requested |IETF |this | | | |Mission | |document,| | | |expiry | |Section 4| | | |ceiling. | | | +--------------------------+------+-----------+----------+---------+ |requested_derivation_limit|stable|Client- |IETF |this | | | |requested | |document,| | | |derivation-| |Section 4| | | |count | | | | | |ceiling | | | | | |(Section | | | | | |10.1). | | | +--------------------------+------+-----------+----------+---------+ Table 7: Core-defined Mission Intent members It further seeds the registry with the metering companion's members, registered on that profile's behalf; the companion's own document owns each member's schema, production, and enforcement in full, and this table records ownership only: +=================+============+===========+==========+=======================================+ |Name |Status |Semantics |Change |Reference | | | | |Controller| | +=================+============+===========+==========+=======================================+ |max_budget |stable |Consumption|IETF |[I-D.draft-mcguinness-mission-metering]| | | |ceiling on | | | | | |a currency-| | | | | |denominated| | | | | |spend | | | | | |bound. | | | +-----------------+------------+-----------+----------+---------------------------------------+ |max_calls |stable |Consumption|IETF |[I-D.draft-mcguinness-mission-metering]| | | |ceiling on | | | | | |a call- | | | | | |count | | | | | |bound. | | | +-----------------+------------+-----------+----------+---------------------------------------+ |max_duration |stable |Consumption|IETF |[I-D.draft-mcguinness-mission-metering]| | | |ceiling on | | | | | |an elapsed-| | | | | |duration | | | | | |bound. | | | +-----------------+------------+-----------+----------+---------------------------------------+ |max_egress_volume|stable |Consumption|IETF |[I-D.draft-mcguinness-mission-metering]| | | |ceiling on | | | | | |a data- | | | | | |egress | | | | | |bound. | | | +-----------------+------------+-----------+----------+---------------------------------------+ |exclusive |experimental|Consented |IETF |[I-D.draft-mcguinness-mission-metering]| | | |exclusivity| | | | | |groups over| | | | | |Authority | | | | | |Set | | | | | |selectors, | | | | | |latched | | | | | |PDP-side; | | | | | |NOT | | | | | |promoted | | | | | |(2026-08 | | | | | |assessment | | | | | |against the| | | | | |companion's| | | | | |own | | | | | |promotion | | | | | |criteria | | | | | |found every| | | | | |applicable | | | | | |gate | | | | | |unmet). | | | +-----------------+------------+-----------+----------+---------------------------------------+ Table 8: Metering-owned Mission Intent members Each further document that defines a Mission Intent member requests that member'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. References 21.1. Normative References [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, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [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, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [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, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [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, . [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, . [RFC9207] Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [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, . [RFC9470] Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, . [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, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 21.2. Informative References [AuthZEN.ARAP] OpenID Foundation, "OpenID AuthZEN Access Request and Approval Profile 1.0", 2025, . [FAPI.GrantManagement] OpenID Foundation, "Grant Management for OAuth 2.0", 2022, . [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, . [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, . [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, . [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, . [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, . [I-D.draft-mcguinness-mission-approval-governance] McGuinness, K., "Mission Approval Governance", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-shaping] McGuinness, K., "Mission Intent Shaping", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [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, . [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, . [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, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-continuation] McGuinness, K., "Mission Continuation: Authorization Continuity for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-management] McGuinness, K., "Mission Management for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-progressive] McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-resource-access] McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-template] McGuinness, K., "Mission Template for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-work-products] McGuinness, K., "Mission Work Products", 2026, . [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, . [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, . [MCP] Model Context Protocol Project, "Model Context Protocol: Authorization", 2026, . [OpenID.Core] OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", 2023, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [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, . [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, . [RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, . [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . Appendix A. End-to-End Example (Non-Normative) This appendix walks one Mission from an agent through Mission creation, token issuance, and Resource Server enforcement in a single trust domain. It is illustrative and adds no normative requirements. The OAuth pieces use the rules in this document; the identity setup is by reference to [I-D.draft-klrc-aiagent-auth]. Identifiers and hash values are illustrative and are not computed from the displayed JSON. This walkthrough is the baseline issuance path: stateless enforcement bounded only by token lifetime. No stage calls back to the AS for Mission state; each party enforces from the credential it holds. Stage 3 notes where the OPTIONAL runtime layer adds a point-of-use check. Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in the home ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-. 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.", "target_resources": ["https://erp.example.com"], "task_bounds": [ "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", "requested_derivation_limit": 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.2), 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.2): { "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" } } Everything enforcement needs is in the token: the audience, the sender-constraint (cnf), the authority with its constraints, and the mission claim identifying the Mission it was derived under. 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.3). 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.3). 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]). Appendix B. Derivation Policy (Non-Normative) This appendix is illustrative and adds no normative requirements. It describes an authoring artifact for the contract in Section 5, not a standardized policy language or an alternative subset relation. B.1. The Policy as an Artifact A deployment retains a versioned derivation policy with its ceiling, configured mappings, and issuance limits. Its inputs include a validated Mission Intent, the client's authority proposal in narrowing mode (or configured candidates when there is no proposal), the applicable authority source ceiling, and the capability catalog's per-action properties. The output is the Authority Set committed by authority_hash; policy_version identifies the policy used. The policy does not travel. Its identifier and published Intent-to- Authority-Set fixtures let a partner review outcomes. Reproducing a derivation requires the same inputs and the retained policy and catalog versions, not just the identifier of a mutable configuration. Derivation is mechanical: a model may suggest an Intent or a proposal, and does not make the approval-time narrowing decision. B.2. Properties a Derivation Policy Holds The five properties below restate, for a policy author, what Section 5 and the rules it cites already require of a derivation. They add no requirement of their own. * *Deterministic.* The same Intent, proposal, ceiling, and catalog derive the same Authority Set, which is what makes policy_version an audit correlator at all (Section 5). * *Narrowing only.* Every derived entry is a subset of some proposed entry of the same type, under that type's own relation (Section 4.2, Section 5.1); in configured-mapping mode the configured candidates supply that comparison input. Retaining fewer JSON fields is not narrowing: dropping a restriction can grant more. Where the relation cannot decide, because two bounds are incomparable, the posture is conservative refusal (Section 5.1). For mission_resource_access, two amount caps naming different currencies have no intersection, with no implicit conversion and no "ceiling wins" exception; the Common Constraints and their intersection rules are defined by [I-D.draft-mcguinness-oauth-mission-resource-access]. * *Refusal over silent drop.* A policy demonstrates narrowing only for a constraint its engine compares. An entry of an unsupported type, or one that fails its schema, is refused, and a validation failure is never repaired by omitting the entry (Section 4.2). An entry carrying a constraint the engine cannot compare is refused rather than derived with that constraint dropped (Section 5.1, Section 9.6): a narrowing intent that vanishes silently is a widening. An entry the engine compares and policy cannot accept is the distinct case, narrowed or omitted with the granted echo reflecting it (Section 4.2). A deployment-defined constraint carries the same obligation as a registered one, its own implemented comparison, and a name absent from the common registry does not relieve it. * *Issuer-established members are not client-supplied.* policy_version (Section 5), authority_source and approval_basis (Section 3.3, Section 8), and the effective derivation_limit (Section 10.1) are established by the issuer at the approval event, and no proposal member sets them. A client's requested_derivation_limit is an input the issuer clamps, never an independently established ceiling (Section 10.1). * *No member the ceiling never granted.* A grant-shaped member absent from the ceiling, such as a per-entry delegation policy, stays absent from the derived entry, so a proposal introduces no capability the policy never conferred. A restriction nested inside an already-granted delegation, such as allowed_delegates, narrows in the ordinary direction. B.3. A Worked Rule Consider a catalog whose read actions supply no amount for a cap to compare against, while a journal write does. The ceiling separates those actions: [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read", "journal-entries.read"] }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount": { "amount": "500.00", "currency": "USD" } } } ] The validated proposal also separates the read from the amount-bound write: [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"] }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount": { "amount": "900.00", "currency": "USD" } } } ] The resulting Authority Set contains the proposed invoices.read entry unchanged, and the proposed journal-entries.write entry with max_amount narrowed to 500.00 USD. The ceiling's unrequested journal-entries.read does not appear. Each proposal intersects the same-resource ceiling fragments; disjoint action intersections contribute no authority. Attaching the amount cap to a single mixed read and write proposal is not a shortcut to that result: the read supplies no amount for the cap to compare against. A deployment applying one entry-admission rule at intake refuses that modeling error, rather than leaving derivation to drop the cap from a read fragment. A write proposal naming a different currency likewise cannot produce the USD intersection shown. And a proposal carrying a Common Constraint this deployment does not compare is refused with invalid_authorization_details (Section 9.6), not derived with the constraint dropped. These are negative fixtures alongside the positive result, not special cases that relax the type's relation. B.4. Fixtures and Authoring Discipline Versioned Intent/proposal fixtures with expected Authority Sets make the existing publication recommendation in Section 5 concrete. Reviewing their diffs with every policy change exposes altered grants before approval. Include empty intersections, unknown constraints, incomparable values, and attempts to introduce delegation, as well as normal template and narrowing outcomes. Check subset against both proposal and ceiling, not only against the issuer's ceiling. An additional tripwire runs the configuration actually shipped through intake, derivation and a real decision path. A successful configuration load alone does not prove that it can authorize its intended workload. Using the same entry-admission rule at configuration load and client intake helps prevent those two surfaces from disagreeing. A reference implementation's split action ceiling and shipped-configuration tests realize this discipline. This appendix states the contract and certifies no implementation's handling of a constraint it does not compare or of mismatched currencies; a deployment establishes that with its own fixtures. B.5. Ownership and Operational Signals +=====================+===============+==========================+ | Artifact | Owner | Responsibility | +=====================+===============+==========================+ | Derivation policy, | Mission | Outer bounds and | | ceilings, versions | Issuer | reproducible approval- | | and issuance limits | operator | time derivation | +---------------------+---------------+--------------------------+ | Capability catalog | Resource | Supported operations and | | and action | owner or | the facts their | | properties | service team | constraints can evaluate | +---------------------+---------------+--------------------------+ | Templates and | Template | Candidate authority for | | configured mappings | author within | supported Intent shapes | | | issuer policy | | +---------------------+---------------+--------------------------+ Table 9 Templates amortize repeated authoring across Missions; they do not bypass the ceilings. Unmapped-resource rate, template-hit rate and rule-exception rate help an operator see where its policy authoring surface remains incomplete. None of these metrics certifies that a policy captured a human's intended meaning; the derivation boundary remains the one stated in Section 5. Appendix C. Integrity Anchor Test Vectors These non-normative vectors let an implementation verify its anchor computation (Section 7.1, Section 7.2) byte for byte. All use the issuer https://as.example.com. Each canonical-bytes block is the exact JCS [RFC8785] output: a single line, UTF-8, with no whitespace outside string values. It is shown here wrapped only for layout; remove the layout line breaks, adding no characters, to recover the canonical form. Note that JCS sorts object member names (so iss precedes typ precedes value, within an entry actions precedes constraints precedes resource precedes type, and within max_amount amount precedes currency) and preserves array order. intent_hash, over this Mission Intent as the envelope value with typ mission-intent: { "goal": "Reconcile Q3 invoices", "target_resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z" } Canonical bytes of the envelope: {"iss":"https://as.example.com","typ":"mission-intent","value":{"e xpires_at":"2026-12-31T23:59:59Z","goal":"Reconcile Q3 invoices"," target_resources":["https://erp.example.com"]}} intent_hash = sha-256:sE_2V3NaDpGNYM8dH1tLpNJnj-RmaHN3FC6ZcbOLJSw authority_hash, over this Authority Set as the envelope value with typ mission-authority-set: [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"] }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount": { "amount": "500.00", "currency": "USD" } } } ] Canonical bytes of the envelope: {"iss":"https://as.example.com","typ":"mission-authority-set","val ue":[{"actions":["invoices.read"],"resource":"https://erp.example. com","type":"mission_resource_access"},{"actions":["journal-entrie s.write"],"constraints":{"max_amount":{"amount":"500.00","currency ":"USD"}},"resource":"https://erp.example.com","type":"mission_res ource_access"}]} authority_hash = sha-256:vUCCfjGulit9u0qJ0Z6pQSNerZtXMqRlfJNCr4PzLro The third pair exercises an additional flat Intent member beyond target_resources, and an Authority Set entry whose delegation.allowed_delegates is an array of matcher objects, where JCS sorts each object's members but preserves the array's order (the sub_profile matcher stays before the sub matcher). intent_hash, over this Mission Intent as the envelope value with typ mission-intent: { "goal": "Reconcile Q3 invoices", "target_resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z", "requested_derivation_limit": 20 } Canonical bytes of the envelope: {"iss":"https://as.example.com","typ":"mission-intent","value":{"e xpires_at":"2026-12-31T23:59:59Z","goal":"Reconcile Q3 invoices","r equested_derivation_limit":20,"target_resources":["https://erp.exa mple.com"]}} intent_hash = sha-256:r--mF07yZfWRGV6N28A2u_8rUzIG-bNhpvFSS5FhoBk authority_hash, over this Authority Set as the envelope value with typ mission-authority-set: [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"], "delegation": { "max_depth": 2, "allowed_delegates": [ { "sub_profile": "ai_agent" }, { "sub": "s6BhdRkqt3" } ] } } ] Canonical bytes of the envelope: {"iss":"https://as.example.com","typ":"mission-authority-set","val ue":[{"actions":["invoices.read"],"delegation":{"allowed_delegates ":[{"sub_profile":"ai_agent"},{"sub":"s6BhdRkqt3"}],"max_depth":2} ,"resource":"https://erp.example.com","type":"mission_resource_acc ess"}]} authority_hash = sha-256:notrA9wZaP3I5Gx8UzN0mfzUjHYPeX4Ri_B3ilh7BbA The last vector exercises the third anchor. proposal_hash, over this submitted authorization_details proposal as the envelope value with typ mission-proposed-authority (Section 4.2): [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.*"] }, { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["journal-entries.write"], "constraints": { "max_amount": { "amount": "1000.00", "currency": "USD" } } } ] Canonical bytes of the envelope: {"iss":"https://as.example.com","typ":"mission-proposed-authority" ,"value":[{"actions":["invoices.*"],"resource":"https://erp.exampl e.com","type":"mission_resource_access"},{"actions":["journal-entr ies.write"],"constraints":{"max_amount":{"amount":"1000.00","curre ncy":"USD"}},"resource":"https://erp.example.com","type":"mission_ resource_access"}]} proposal_hash = sha-256:udzftXYQy0pvYNxz4KgtmyL_EV8ry4DhIbBFfwILEBA The entry commitment (Section 7.1) is computed over one immutable Mission-record Authority Set entry, never an issued or narrowed token projection. Over this entry: { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read"], "constraints": { "resource_issued_after": "2026-07-01T00:00:00Z", "resource_issued_before": "2026-09-30T23:59:59Z" }, "delegation": { "max_depth": 2, "allowed_delegates": [{ "sub_profile": "ai_agent" }] } } as the envelope value with typ mission-authority-entry: {"iss":"https://as.example.com","typ":"mission-authority-entry","v alue":{"actions":["invoices.read"],"constraints":{"resource_issued _after":"2026-07-01T00:00:00Z","resource_issued_before":"2026-09- 30T23:59:59Z"},"delegation":{"allowed_delegates":[{"sub_profile":" ai_agent"}],"max_depth":2},"resource":"https://erp.example.com","t ype":"mission_resource_access"}} entry_digest = sha-256:OUrwTnuirT29YxQmMSyiJce8W1PfGryvrVViQ1lJCqQ An implementation that canonicalizes the same value under the same typ and iss, computes SHA-256, and encodes as sha-256: followed by base64url with no padding (Section 7.1) reproduces these anchors exactly. A divergence indicates a JCS or encoding difference to resolve before interoperating. Appendix D. OAuth Binding Mapping Assessment This appendix is informative. It is this document's own Mapping Assessment of itself against the Mission Substrate contract's kernel and capabilities ([I-D.draft-mcguinness-mission-substrate], Section "Mission Substrate Statement"), describing in the Statement's form how the surfaces this document already defines normatively realize that vocabulary. An assessment cannot be normative content in its own right while depending, even to be read, on a contract it cites only informatively: this document's own Conformance gates (Section 16) remain its sole normative requirements, this document publishes no Mission Substrate Statement and makes no substrate- conformance claim, and it takes no requirement from the substrate. Its reference to the substrate is informative, and the substrate's own reference back to this document is informative in turn, so neither document takes a normative dependency on the other. This appendix applies to the substrate edition published from the same repository revision as this document (the two editions revise and publish in lockstep, so the assessed revision is exact; for a copy obtained independently of the repository, the family's conformance manifest publishes the assessed substrate's content digest in its source.specs entry, identifying the exact assessed bytes), in this document's base single-domain mode with the OPTIONAL capabilities as the activation conditions below state, and to the kernel and capability vocabulary of the substrate document as of that revision. The digest marker above keeps this description synchronized with the substrate's own text; a mismatch prompts review, not a normative failure. For the kernel: 1. The Mission Reference is mission_id: high-entropy, unambiguous within the issuer namespace, compared by exact string equality together with mission.issuer, never reassigned, retained for the audit horizon, and disclosed beyond the issuer only on this document's authorized surfaces. 2. The Controller is the Mission Issuer (the Authorization Server), established through mission.issuer and the deployment's issuer trust (AS metadata and published keys). 3. The Actor handle is the authenticated OAuth client at approval; the external Subject is fixed by this document's injective mapping; delegates ride the act chain; child and successor lineage is recorded through the parent and predecessor members; actor-type classification uses sub_profile and instance assertions where deployed. 4. The Approved Context is the Mission Intent recorded verbatim, the recorded authority proposal where one was submitted, and the derived Authority Set; the immutable boundary is the record's immutable members; commitments are the typed integrity anchors (intent_hash, proposal_hash, authority_hash); a material change obtains a new approval through an expansion successor. 5. The approval ceremony is this document's approval event: authenticated Approver, the distinct-approver rule for write- bearing Missions, rendering of the derived Authority Set and the effective expiry, and atomic record commit, with deferred, interactive, and dispatch realizations. 6. The active predicate is stored state equal to active with the decision time strictly before the record's effective expires_at, the issuer materializing the resulting expired transition lazily where it chooses; any other stored value, recognized or not, is non-active; transitions are authenticated lifecycle operations; a non-active Mission refuses issuance and derivation. 7. The reliance bound is the record's effective expires_at (never later than the requested ceiling), which caps every derived credential's exp; the maximum residual after a Mission becomes non-active is the outstanding credential lifetime, bounded by the deployment's declared access-token TTL. 8. The propagation and join surfaces are: the mission claim (artifact issuance under the Mission, authority derivation, and lifecycle-gated issuance); the mission_id and mission_expires_at response members (correlation only); the introspection projection (state as of the response, caller authorization and minimization applying); the Status surfaces (state as of a signed observation with explicit freshness); and the grant binding (the issuer's native association of Mission, Subject, client, and credential). 9. The governance record is the Mission Record with its approval evidence and lifecycle history, retained for the audit horizon, with integrity resting on record custody and the typed anchors. The capability table: +=============+========+==============+=====================================================+============+ |Capability |Claim |Activation |Scope and defining sections |Limitations | +=============+========+==============+=====================================================+============+ |Lifecycle- |supplied|always |State-gated issuance and every derivation gate |Outstanding | |Gated | | | |credentials | |Authorization| | | |run to their| | | | | |own exp; the| | | | | |residual is | | | | | |bounded, not| | | | | |zero | +-------------+--------+--------------+-----------------------------------------------------+------------+ |State- |supplied|Status, |Those surfaces |Staleness | |Observable | |introspection,| |bounded by | | | |or Signals | |each | | | |companion | |surface's | | | |active | |declared | | | | | |freshness | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Structured |supplied|always |authorization_details of AS-supported types |Semantics | |Authority | | |(Section 5.2), each type's own specification defining|exist per | | | | |semantics (for mission_resource_access, the Mission |supported | | | | |Resource Access Profile's Common Constraints, |type, not | | | | |[I-D.draft-mcguinness-oauth-mission-resource-access])|universally | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Monotonic |supplied|always |The subset rule over covered types at every |Covered | |Derivation | | |derivation, delegation, and attenuation point |transitions | | | | | |are | | | | | |attenuate; a| | | | | |cross- | | | | | |vocabulary | | | | | |transition | | | | | |is | | | | | |decide_anew,| | | | | |never silent| | | | | |attenuation | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Credential- |supplied|always |The mission claim on issued tokens |Fact | |Bound | | | |semantics: | | | | | |issuance | | | | | |under the | | | | | |Mission, | | | | | |authority | | | | | |derivation, | | | | | |lifecycle- | | | | | |gated | | | | | |issuance; | | | | | |state-as-of | | | | | |only via the| | | | | |State- | | | | | |Observable | | | | | |surfaces | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Authorized |supplied|the Delegation|The Token Exchange join at delegated issuance: the |The base | |Context | |role active |AS, as joining authority, joins the Mission and |grant | |Correlation | |(Section 12) |Subject carried by the Mission-bound subject_token |binding at | | | | |with the delegate identity independently established |issuance co-| | | | |by the actor_token or the delegate's own client |establishes | | | | |authentication, binding both to the newly issued |its facts | | | | |credential |and is not a| | | | | |join; cross-| | | | | |authority | | | | | |joins are | | | | | |the Mission | | | | | |Authority | | | | | |Server's | | | | | |machinery, | | | | | |not this | | | | | |binding's | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Independently|supplied|Mandate, |Anchor recomputation and signed artifacts per those |Signature | |Verifiable | |signed Status,|profiles |verification| | | |or audit | |never | | | |companion | |establishes | | | |active | |current | | | | | |state | +-------------+--------+--------------+-----------------------------------------------------+------------+ |Portable |supplied|Evidence, |Per those profiles |The | |Evidence | |Mandate, or | |governance | | | |audit | |record is | | | |companion | |otherwise | | | |active | |issuer-local| +-------------+--------+--------------+-----------------------------------------------------+------------+ Table 10: OAuth Mission binding capability table Temporal elements: every issued credential's exp is capped by the record's effective expires_at; state observations carry their surface's declared freshness; the residual after non-active is the outstanding credential lifetime under the deployment's declared TTL. Failure behavior: an unknown lifecycle state is non-active; an unresolvable reference, a failed anchor verification, and an unknown authorization_details type fail closed; where a row's activation condition does not hold, the property is not supplied and a consumer MUST NOT rely on it. This document's three OPTIONAL implementation roles, which its Conformance section names OPTIONAL capabilities (Section 16), are surfaces an implementation may or may not offer, each independent of the others. The capability table above states scoped guarantee claims: properties this document supplies and the conditions under which each is supplied. The two vocabularies answer different questions and are not equivalent; the entries below relate them without collapsing one into the other. Declaring an OPTIONAL role never creates a claim beyond the eight already stated above. Introspection: Exercises State-Observable. One of State- Observable's three named activation surfaces, alongside Status and Signals; declaring it activates that otherwise-conditional claim. Delegation: Exercises Lifecycle-Gated Authorization, Structured Authority, Monotonic Derivation, Credential-Bound, and Authorized Context Correlation. This document's delegation subset-checks authorization_details, carries the mission claim unchanged, sender-constrains the delegated credential to the delegate's own key, and refuses issuance unless the Mission is active. The Token Exchange that issues the delegated credential associates, at issuance, the Mission and Subject carried by the Mission-bound subject_token with the delegate identity established by the actor_token or the delegate's own client authentication, binding all three to the newly issued credential without itself establishing a new grant binding: an access-token-only delegated exchange is a derived token under the subject_token's existing binding, not a second binding of its own (Section 6.2). Four of the five claims are supplied always, and Delegation exercises them rather than creating them; Authorized Context Correlation is the exception, activated by this role, whose Token Exchange join is its supplier. The act chain itself supplies none of them: it is attribution, never authority. Cross-Domain: Exercises Lifecycle-Gated Authorization, Structured Authority, Monotonic Derivation, and Credential-Bound. Carries these four always-supplied guarantees across the domain hop: the Mission reference and authority_hash intact, authority that only narrows, and projection gated on active state, while adding an interoperable projection surface the guarantees alone do not provide. It does not become Portable Evidence by crossing a domain: that claim activates only when an Evidence, Mandate, or audit companion is active, and Cross-Domain is not among them. Appendix E. Document History [[ To be removed from the final specification ]] -01 * Added an informative derivation-policy appendix with an admissible split-action worked rule, authoring fixtures and ownership guidance; no normative requirements were added. * PR #725 review round: split Local Approved-Set Verification's authenticated complete-set retrieval into two explicit tiers (Section 9.4.1): Tier 1 (recompute and subset-check against a retrieved set, detecting projection errors under continuing trust in the issuer) and Tier 2 (additionally require the expected authority_hash to come from an independently retained, separately authenticated source, defending against post-approval substitution). Removed the claim that Mission Status is a compatible retrieval surface: Status returns only the requesting audience's, and only the current effective (containment-filtered), entries, never the complete immutable approved set. Corrected the typed selective-inclusion proof from a claimable alternative to a future composition point (Section 9.4.2), pending a concrete proof type that authenticates its own root as the Mission's approval- time commitment, and fixed its description to prove the approved parent entry, never the carried narrowed entry directly. Added the capability to the Conformance section's OPTIONAL capabilities list (Section 16). Closed a mismatched- issuer gap in token introspection and child-grant redemption: both resolved a Mission by id alone without checking the presented mission.issuer against the resolved record's, now that (id, issuer) is the complete Mission identity. Clarified that Harness Evidence and Orchestration Evidence carry authority_hash as their own optional audit extension, not inherited from the baseline claim. * Minimal Mission claim (#702, coordinated with #699): the baseline mission claim shrinks to exactly id and issuer. authority_hash and approval_basis leave the baseline claim; both stay on the Mission record and become available through token introspection's member- scoped disclosure privilege, alongside derivations_remaining and proposal_hash. Added the Local Approved-Set Verification profile (Section 9.4), an OPTIONAL profile defining authenticated complete-set retrieval, commitment recomputation, and a subset check, or a typed selective-inclusion proof this document does not itself define, for a party that needs to verify a token's carried authority against the complete approved Authority Set independently of the token signature. expires_at on the claim is now explicitly profile-scoped: a consumer relying only on the presented token's own validity needs nothing further, while a profile minting a further credential downstream, or verifying Mission lifetime from retained state, MUST require it and MUST treat its absence as an error, never a silent fall back to the token's own exp. The Extensibility section's documented stability list narrows from id, issuer, authority_hash to id and issuer; an extension that relied on authority_hash's baseline presence adopts the new profile or introspection's disclosure privilege instead. A companion document that carries the recurring {id, issuer, authority_hash} micro-descriptor as its own lineage or audit anchor (offline attenuation, the cross-domain and cross-org grants, the Mission Authority Server's Join Assertion) now carries it as its own profile-owned extension member, never inherited from this baseline. * Controls taxonomy retired and error codes reused per typical OAuth patterns (#636, #706, #117; one coordinated breaking cut). The controls extension bucket is removed: acr is replaced by the standard acr_values/max_age authorization-request parameters for the direct flow, with explicit Approver semantics distinct from the token's Subject and an AS approval floor that stays authoritative and conjunctive (Section 6.1); achieved approval context (acr, amr, auth_time) is provenance recorded on the approval event or Consent Evidence, never a Mission Intent member, and an AS MUST NOT carry it on a derived access token (Section 9). max_derivations is replaced by a requested-vs-effective pair, requested_derivation_limit (Intent) and derivation_limit (Mission Record), with the architecture's fan-out characterization removed and the clamp, omission, rendering, and audit-recomputation rules stated in a dedicated Derivation Issuance Policy section (Section 10.1). agent_deployment is removed with no replacement member defined in this document series; a pointer names what a future Agent Deployment Binding profile would own (Section 4). resources is renamed target_resources (a client-requested Intent ceiling, explicitly not RFC 8707 resource carriage) and constraints is renamed task_bounds, so the name cannot collide with a Resource Access entry's enforced constraints. The Mission Intent's top level is now open to companion-defined members by name (Section 13); this is the seam metering's consumption-bound members ride directly, no longer nested under controls ([I-D.draft-mcguinness-mission-metering]). Error codes: two no- RAR uses of invalid_authorization_details (the configured-mapping no-match refusal and the unrecognized-target_resources refusal) are replaced by access_denied, since no authorization_details object exists for that code to describe (Section 5); the RS mission_denial attribute drops step_up_required in favor of the standard RFC 9470 insufficient_user_authentication challenge for weak or stale token-associated user authentication, with sender- constraint/key-binding failure routed to the applicable Bearer/DPoP/mTLS invalid_token challenge instead (Section 9.3); mission_error and mission_denial_reason are unchanged, and invalid_mission_intent_evidence is retained with its rationale now stated (Section 20.2). This is a breaking wire-shape change to intent_hash's covered object: the Integrity Anchor Test Vectors are regenerated (Appendix C), and there is no deprecated alias for any renamed or relocated member. * PR #717 review fix: the OAuth Binding Mapping Assessment appendix (Appendix D) is now explicitly informative throughout, correcting a layering contradiction (normative-as-own-content text that depended, to be read, on a substrate contract cited only informatively). This document's Conformance gates remain its sole normative requirements; the appendix publishes no Mission Substrate Statement and makes no substrate-conformance claim. The digest-marker tripwire is unchanged in mechanism: a mismatch still prompts review, now understood as an editorial finding rather than a normative one. * Added an OAuth Binding Mapping Assessment appendix (Appendix D): this document's own self-assessment against the Mission Substrate contract's kernel and capabilities, relocated here from the substrate document so the substrate carries no binding-specific discharge (#708); its reference to the substrate remains informative, and replaces the prior pointer to the substrate's family appendix. No requirement on a Mission Issuer, Resource Server, or Client changed. * Informative pointer from the Conformance section's Mission-bound gates to the architecture's Mission Binding Properties vector, naming this document's discharge as its credential-mission-bound property; the core's own gates remain authoritative and the document remains self-contained (#663). * Mission Resource Access Profile split (#637, #645, #698): the mission_resource_access type definition, its resource and action matching, generic constraints, the Common Constraints registry, the delegation member and matching rules, the subset and intersection algebra, the Resource Server's enforcement duties for this type's resource/actions/constraints members (including the prefix-match normalization rule) and the mission_constraints_supported protected-resource metadata member (definition and IANA registration), and the Resource Boundary Canonicalization security analysis relocated to the Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]); this document keeps type-agnostic commitment, the approved-set metadata requirement, and derivation gating (Section 5, Section 5.2, Section 14). Adds the type-agnostic scope-projection rule and issuance algorithm (Section 9.1) and the machine-readable per-type transformation-capability declaration (mission_transformation_capabilities, Section 5.2); sweeps every scope-only claim that assumed a lossy projection was always available (the Intent enforcement table, Resource Server Enforcement, and the minimum-deployment note). * Mission-to-OAuth-grant cardinality made explicit (Section 6.2): a Mission is independent of any OAuth grant and identified globally by (issuer, id). The Mission grant persistent, redeemable grant lineage (the authorization-code lineage established at approval, or a further reusable grant such as a continuation-established refresh-token family) to exactly one Mission, zero or more bindings per Mission and never more than one Mission per binding, resolved stably on every derivation and never client-negotiated; a violation is an AS-internal data-integrity fault, not a client- visible refusal. A Token Exchange or cross-domain projection that issues only an access token establishes no new binding: the issued token is a derived token, a mission-claim association to its input binding's Mission, not itself a grant binding. A Child Mission or expansion successor gets its own identity and, where it has one, its own grant binding, related to its origin by lineage, never by extending the origin's binding; a continuation handle or refresh- token family is credential machinery rooted in one Mission, not the Mission itself. Non-active state gates every bound derivation without implying revocation of an unrelated grant or recall of an unexpired token. A decision-time runtime join (the Mission Authority Server's Mission Join) never becomes a grant binding. The unredeemed-authorization-code fork is now one deployment policy applied consistently, with idempotent replay (#700). * Reader-program normative follow-ups: each supported authorization_details type's transformation boundary (subset relation and delegation semantics understood, or carried-as- approved) is declared in the deployment documentation that names the type as supported (Section 5.2, Section 14); opaque Mission- bound tokens get a defined consumption mode, introspection REQUIRED as the claims carriage with active-only authority disclosure and fail-closed Resource Server duties (Section 11.4); the second derivation mode is renamed configured-mapping mode (formerly template mode) and framed as the no-RAR on-ramp (Section 5); Authority Sources moved after Protocol Flow within the Overview (structure only). * Editorial consolidation; no normative change: every removed sentence restates a rule that remains normatively stated at its home (Section 9 and Section 9.3 for client_id's registered meaning, Section 4.1 for the submission trust rule, Section 11 for the RFC 7662 deviation, the (since relocated) Resource Boundary Canonicalization section for the single-normalization rule, Section 10 for short-lifetime guidance). The rejected client_id- freezing narrative compressed to its design rationale; spec- archaeology sentences removed in favor of this history; the Mission Drift consideration folded away. Structure: the commitment machinery promoted to Integrity and Commitments; the Introduction's positioning subsections merged into Relationship to Adjacent Work; the submission processing order given its own section; Security Considerations grouped into five themed clusters. Scanability: mission_denial values as a definition list, a remediation-grains table, a prefix-matching example table. Explicit anchors pinned on every previously auto-slugged surviving heading, matching the published fragments; the end-to-end example now shows mission_id and mission_expires_at on the token response. * goal_lang (OPTIONAL, BCP 47) on the Mission Intent and an Internationalization Considerations section: a syntactic language declaration for the Intent's human-readable prose, committed by intent_hash, refused invalid_request when malformed, with no authority semantics and deliberately no language-tagged display fields on Authority Set entries (#534). * Standing-consent approval instant: approval_basis.approved_at (REQUIRED for every standing-consent type) carries the human approval instant of the exact consented root, verified by the activating issuer from retained state, never accepted as the activating request's own assertion, with deployment-declared recency ceilings mirroring the Approval Governance companion's policy-approval recency (#580). * Informative pointer to the substrate-hosted OAuth Mission Binding Statement from the Conformance section; the core remains self- contained (#551). * Requested versus effective expiry: intent.expires_at is the client's requested not-after ceiling and the Mission Record's expires_at is the AS-established effective lifetime, never later than the request (invalid_request for a malformed or non-future new request; delayed approval rechecks at activation, while idempotent recovery returns the stored outcome; the exact-mirror rule and the invalid_authorization_details refusal are replaced). Approval reconsent covers a changed effective expiry. The new mission_expires_at token-response parameter carries the exact effective value on every Mission-creating success response. * The Authority Set entry commitment: the committed-object typ mission-authority-entry over a single recorded entry, with its Mission-binding rule, selector equivalence class, and test vector (Section 7.1, Appendix C). * Breaking change to the Intent carriage shape: the mission_intent parameter value is the Mission Intent Submission envelope (Section 4.1), intent plus an OPTIONAL typed evidence array, and the bare-Intent value is refused under the closed envelope. Anchors are stable: intent_hash commits exactly the intent object, so committed values, recorded anchors, and the test vectors are unchanged. The Intent Submission Evidence hook (Section 4.3) adds type-dispatched verification that rejects unknown or failing entries, the policy-input-never-authority rule, the required- evidence anti-downgrade rule, evidence invalidation across shaping and revision, the presenter conjunction, verification-cost bounds, the invalid_mission_intent_evidence error registration, and the submission_evidence record member as record-trusted provenance metadata. * Breaking change to the authority-proposal carriage: the proposal moves from the Intent's proposed_authority member, which is removed, to the standard top-level authorization_details parameter pushed alongside mission_intent (Section 4.2), and the old prohibition on submitting the two together inverts. Anchor inputs changed: intent_hash no longer covers the authority proposal, and the new proposal_hash (typ mission-proposed-authority) commits the submitted proposal, recorded on the Mission and surfaced through introspection, never on the mission claim. Worked examples and test vectors are recomputed; an approval-event rule recomputing every recorded anchor and a Mission-governed-client bare-request rejection accompany the change. * Derivation is mechanical, in two modes: narrowing (RECOMMENDED) and configured-mapping. The deterministic-reproducibility and policy-inspectability rules are retired, policy_version stays as an opaque audit correlator, generative derivation is demoted to a local-policy extension, and the derivation trust boundary (no portable Intent semantics) is stated. Configured-mapping mode publishes its mapping space as deployment documentation and distinguishes no-mapping from policy refusals. * New wire surface: the mission_error and derivations_remaining introspection members, the mission_denial WWW-Authenticate attribute, and the mission_constraints_supported protected- resource metadata member. The mission claim gains an OPTIONAL expires_at; the mission_id token-response parameter is promoted to SHOULD. * Authority vocabulary: four new Common Constraints (time_window, data_classification, allowed_tools, requires_action_approval) with prefix-match fixes; the OPTIONAL controls.agent_deployment class pin; max_derivations sizing guidance. * Delegation hardening: delegation-authorization policy applies at every exchange, allowed_delegates is RECOMMENDED and its absence is never a blanket grant, self-exchange is accepted only from the Mission's client_id, and the delegated-token routing guardrail is raised to MUST NOT. * Model precision: the Mission-referenced, Mission-derived, and Mission-bound token-class taxonomy; anchors as independent commitments with authority_hash an audit correlator at a narrowed- token Resource Server; the subset rule named representational, not semantic; approval-event sequencing named as an extensibility seam; Intent carriage closed to the form-encoded PAR parameter. * Operational and privacy: verification-key retention anchored to the audit horizon, issuer-key custody and per-artifact-class kid guidance, a Mission-record and evidence-access privacy section, and extended token lifetimes scoped to fully runtime-gated tokens with single-audience narrowing as the splitting mechanism. * Editorial throughout, no normative change: requirement lists for the PAR submission and rendering duties, twice-stated rules reduced to one home, a third integrity-anchor test vector, and registry hygiene. * External review resolutions: GNAP and capability-system prior art positioned in Relationship to Other Authorization Objects; the mission claim named as the actor-freezing wire signal, with the Resource Server routing guardrail and a new Security Considerations subsection on client_id misattribution; RFC 6750 and RFC 9700 promoted to normative and the OAuth Actor Profile reference demoted to informative; an actual Common Constraints IANA registry replacing the future-revision deferral; and new Security Considerations on composition's effective ceiling and the containment materialized-capability residual. * Editorial density pass: split over-dense paragraphs at their natural idea boundaries, converted a few flowing comparisons and one dense list item into bullets, and reordered surrounding prose so a rule sentence opens its paragraph or list item; every normative sentence kept its exact wording and home section. * Three-role approval model (#701): approval_basis gains an OPTIONAL discriminated adjudication member (kind: human or policy, a decision mechanism, plus an independent governance_record boolean) naming what decided a Mission instance, distinct from activation_actor (who triggered it) and consent_principal (the accountability root). It is OPTIONAL rather than REQUIRED in this revision because the family's standing-consent constructors (Template dispatch, Child Delegation, Ceiling drawdown) do not yet emit it; a future breaking-change window, the same one tracked for approver's removal, MAY promote it once they do. A new Role Mapping table (Section 8.1) covers direct, relocated human approval, Template dispatch, policy drawdown, ceiling drawdown, and AGR-backed approval, with direct approval as the degenerate one-human case. type and adjudication.kind get their own unknown- value rule, distinct from the Mission Lifecycle state rule. The top-level approver member is DEPRECATED as a compatibility alias for approval_basis.consent_principal, normatively equal to it; its removal is deferred to the same future breaking-change window. -00 * Initial individual draft. Acknowledgments This work builds on the OAuth 2.0 Rich Authorization Requests, Pushed Authorization Requests, and JWT access token specifications, and is intended to complement agent-identity work including [I-D.draft-klrc-aiagent-auth]. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com