Mission-Bound Authorization for OAuth 2.0

1.1. Implementation Map

The core establishes six properties; Section 18 states the requirements that realize them:¶

1. The task is disclosed: the approval rendering shows the Intent's task, and the AS commits the Intent as intent_hash (Section 6, Section 8.1).¶

2. The authority is explicitly approved: the Approver consents to the derived Authority Set itself, not to the task description alone (Section 6).¶

3. The Mission Record durably associates the disclosed task, the approved authority, and the approval basis; separate commitments protect the recorded Intent and Authority Set (Section 7, Section 8.1).¶

4. The OAuth grant lineage is bound to exactly one Mission, server-side (Section 6.4).¶

5. Every derived authority is no broader than the approved Authority Set (Section 5.1).¶

6. A Mission that is not active yields no further derivation (Section 9.1).¶

Section 18 is the complete statement of roles and optional capabilities. The starting path is one client, one Authorization Server, direct approval, and a single resource audience. It needs no runtime profile, delegated token, or cross-domain projection.¶

A Resource Server need not become Mission-aware for this starting path. A scope-only resource is eligible only when the AS establishes that its scope projection and the resource's independent controls cannot over-grant (Section 10.1). Delegated tokens have a separate Mission-awareness requirement (Section 11).¶

Some duties apply only when their condition holds: a submitted authority proposal, presented or required submission evidence (Section 4.3, [I-D.draft-mcguinness-oauth-mission-submission-evidence]), or opaque tokens (which require introspection). The optional capabilities (Delegation, Introspection as a state overlay for JWTs, and Cross-Domain projection) are adopted explicitly under Section 18. Ordinary JWT consumption does not require retrieving the Mission Record or recomputing the complete approved Authority Set.¶

1.2. Applicability

This document 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 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 6.2).¶

A Mission is intended to cover one concrete task, not an agent's whole lifetime: narrow, per-task Missions, each separately approved and revocable, are preferred over a single broad standing Mission that accumulates authority across unrelated tasks.¶

This preference has a consent cost. Many narrow Missions can create approval fatigue; combining unrelated authority into one broad Mission can make approval difficult to evaluate. A useful boundary is a task whose purpose, authority, and bounds the Approver can evaluate together (Section 6.1).¶

For recurring or evolving work, optional, experimental companions can reduce repeated approvals through standing consent (Section 7.1). Mission Template ([I-D.draft-mcguinness-oauth-mission-template]) creates bounded instances of recurring tasks. Progressive Authorization ([I-D.draft-mcguinness-oauth-mission-progressive]) permits successor Missions within a previously approved authority ceiling as a task evolves. The template or ceiling still needs a meaningful human approval. Neither mechanism removes its profile's fresh-human-approval requirement for prohibited high-consequence authority.¶

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; under mediated execution they fit at the mediating enforcement component (Section 19.3.1).¶

3.1. Principal Model

This document maps principals onto native OAuth constructs:¶

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

• 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, which the basis's adjudication member can make explicit (Section 7), while the Approver remains the human whose consent roots it (Section 6.2, Section 6.5).¶

On a derived token, the iss claim is the AS and the sub claim is the AS-local sub to which the AS maps the Subject under the injective mapping of Section 6; adopting the external sub verbatim is the common case. 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: the external subject identity, carried as provenance for audit and not on the token. This document defines no runtime lookup of it.¶

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 cross-domain companion conveys Subject identity through its own subject-resolution claims, not a Mission lookup, and a token minted in another domain preserves the mission claim unchanged ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

Issuer roles obey two invariants: a Mission has exactly one Mission Issuer, its issuer, and a Resource AS never creates or alters a Mission.¶

Principals are recorded at the approval event and are immutable. Two principals are equal when their iss and sub are byte-equal, so the test compares principals only within one issuer namespace; the external subject identity and the AS-local subject principal represent one Subject and are never compared under this rule.¶

Dynamic delegation (the actors an agent delegates to during execution) is carried on derived tokens in the act chain (Section 14), not on the immutable Mission Record. This document uses only (iss, sub) pairs; the subject identifier formats of [RFC9493] are not used.¶

3.2. Protocol Flow

The following figure shows the protocol flow between the agent and the Mission Issuer:¶

 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 Resource Server enforces the authorization_details statelessly and can check the mission claim (Section 11), 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 can also treat [RFC7009] revocation of the refresh token as revoking the Mission (Section 9.2). The end-to-end example (Appendix A) walks this flow with concrete messages.¶

4.1. Submission via PAR

A client MUST submit a Mission Intent through a Pushed Authorization Request [RFC9126] using the mission_intent request parameter. The parameter value is the UTF-8 JSON [RFC8259] serialization of the 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); the AS refuses an empty array with the invalid_request error code.¶

intent_hash commits exactly the intent object, not the Submission envelope or its evidence array (Section 8.1).¶

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 the invalid_request error code.¶

Submission is governed by the following rules:¶

• Closed top levels. The AS MUST reject a submission with the invalid_request error code if the Submission envelope contains a top-level member other than intent and evidence, or if the intent contains a top-level member that neither this document nor a companion profile the AS implements defines (Section 15). A bare Mission Intent submitted as the parameter value fails this rule, since its goal and sibling members are unknown envelope members.¶

• One carriage, through PAR. The AS accepts the Intent in one of two forms:¶

  1. the form-encoded mission_intent parameter of the PAR request body; or¶

  2. 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. A client MUST NOT send mission_intent 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, strengthening Section 6.3 of [RFC9101], under which the AS would only ignore such a value.¶

• 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. The verification-cost bound of [I-D.draft-mcguinness-oauth-mission-submission-evidence] accompanies these.¶

• Concrete authority is proposed via authorization_details. A client proposes concrete authority on the standard authorization_details parameter in the same push (Section 4.2). A client can also push scope and resource ([RFC8707]) values; the AS treats them as a requested subset of the authority the Mission Intent yields (Section 5).¶

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

• A proposal, not 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 treats the submission as a proposal and derives and bounds authority by its own policy, whatever the client submitted (Section 5).¶

The following is an example of a 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. 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 submitted authorization_details is a proposal, not authority (Section 4.1); the AS derives and bounds the Authority Set from it (Section 5).¶

The AS validates each submitted entry per Section 5 of [RFC9396]: it refuses a request carrying an entry of a type it does not support (Section 5.2, Section 16), or one that fails its type's documented definition, with the invalid_authorization_details error code, and never repairs a failure by omitting the entry. Where a machine-readable JSON Schema for the type is advertised (Section 16) or established out of band, the entry MUST also validate against that schema, and the AS MUST refuse a request carrying an entry that fails it with the invalid_authorization_details error code.¶

Policy narrowing is distinct. During derivation the AS MAY narrow or omit a syntactically valid entry that policy cannot accept (Section 5). The granted authorization_details in the token response reflects every narrowing and omission (Section 10).¶

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: narrowed under that type's own subset rule where it defines one, or carried through unchanged where it defines none (Section 5.2).¶

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 the invalid_request error code.¶

The carriage rules of Section 4.1 apply to the proposal. The AS records the submitted array on the Mission exactly as submitted and commits it by proposal_hash (Section 8.1, Section 7), separately from the task (intent_hash) and the grant (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. Two AS-side rules keep a governed task from being downgraded to such a request; Section 19.1.2 states the client-side rule and the threat. Where a deployment designates a resource Mission-governed, its AS MUST NOT issue a token for that resource outside a Mission, except under documented policy exceptions. If a client registered as Mission-governed sends an authorization_details request that carries no mission_intent, the AS MUST reject the request with the invalid_request error code, so the client cannot omit the Intent to obtain ungoverned tokens.¶

The following is an example of an authority proposal submitted alongside the example Intent of Section 4. Derivation narrows invoices.* to invoices.read, keeps the proposed Q3 issuance window and write ceiling, which the Intent's task bounds support, 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. Each entry is a JSON object whose type member names its evidence type.¶

Processing is governed by the following rules:¶

• Reject, do not ignore. An entry that is not a JSON object, or that lacks type, is structurally invalid and refused with the invalid_request error code. The AS MUST refuse an entry whose type it does not support, and an entry that fails its type's validation or verification, with the invalid_mission_intent_evidence error code (Section 22). A submission is accepted only when every presented entry verifies.¶

• Policy input, not authority. A verified entry is policy input, not authority: it is not copied into the Authority Set and does not stand in for the approval event (Section 6), the sole activation of authority. Verified evidence can serve as authenticated input to admission and derivation policy; AS policy decides whether the verified claims are acceptable for this request.¶

Mission Intent Submission Evidence for OAuth 2.0 ([I-D.draft-mcguinness-oauth-mission-submission-evidence]) specifies the entry convention, required-evidence resolution, the binding of evidence to one Intent and to the presenter, the verification-cost bound, where the error is returned, and evidence on idempotent creation surfaces.¶

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

4. Apply any submission checks that configured admission policy or adopted profiles require before evidence verification, including when no evidence member is present. For example, the Submission Evidence companion resolves required evidence here and refuses a missing required type ([I-D.draft-mcguinness-oauth-mission-submission-evidence], Section "Required Evidence Is Resolved Before Derivation").¶

5. Apply the evidence dispatch and refusal rules, verifying every presented entry under its type's rules (Section 4.3).¶

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

The material verified provenance of step 7 is part of the approval surface. Where a deployment commits the rendered approval surface, that commitment MUST cover the normalized provenance facts, at least as a digest of their canonical submission_evidence representation (Section 7). For example, the consent-evidence companion binds them with a submission_provenance_hash inside its committed disclosure ([I-D.draft-mcguinness-oauth-mission-consent-evidence]).¶

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

The AS MUST refuse a request that would widen authority under a Mission after the approval event on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation); broader authority requires a fresh approval event, either a new Mission or a successor ([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 16).) 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 14.3). A type whose subset and delegation semantics the AS does not understand MUST NOT be delegated, audience-projected to a Resource AS ([I-D.draft-mcguinness-oauth-mission-cross-domain]), or narrowed, since the AS cannot prove that a transformed copy is still a subset of what was approved. The AS MUST NOT issue such an entry to any audience other than its original approved audience, or in any form other than exactly as approved;¶

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

The subset rule is fully defined only for a type whose specification defines it. For every supported type, the AS declares three independent transformation capabilities; understanding one establishes none of the others:¶

• narrowing: the AS understands the type's subset relation;¶

• delegation: the AS understands the type's delegation semantics; and¶

• projection: the AS establishes a safe scope projection for the type (Section 10.1).¶

The AS MUST NOT narrow, delegate, or project to scope an entry of a type for which it has not declared the corresponding capability; on an undeclared capability the entry is carried as approved.¶

The AS declares the capabilities through these carriers, in order of preference:¶

1. 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 16);¶

2. an equivalently shaped member of its supported-type documentation; or¶

3. deployment documentation naming the type as supported (Section 16).¶

Deployment documentation is always a sufficient carrier; a machine-readable carrier is additive. A mission_transformation_capabilities value is a JSON object with three OPTIONAL boolean members, narrowing, delegation, and projection; an absent member leaves that capability undeclared by this carrier, falling through to the next carrier in the order above.¶

Type-agnosticism 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 does not interpret the carried policy beyond its type's declared capabilities; the Resource Server or Policy Decision Point (PDP) evaluates it at request time.¶

The following is an example of 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 10. Because the Cedar profile defines no subset or delegation rule over policy sets, the AS carries the Cedar entry as approved, so it does 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.¶

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.1. Approval Comprehension

The approval event commits the Mission Intent and Authority Set the AS records as approved. Those commitments establish neither that the AS rendered them faithfully nor that the Approver understood them (Section 19.1.1). Step 5 of Section 6 requires human-meaningful rendering; comprehension cannot be inferred from an approval or its integrity anchors.¶

A short task can legitimately have a large or varied Authority Set: an erasure request whose proposal or configured lookup (Section 5) yields dozens of delete entries across resources. The consent object remains the complete derived Authority Set. The following non-normative practices can help make it reviewable:¶

• Group entries by resource and action, so the Approver reviews kinds of authority rather than a list of entries, while keeping material differences in constraints visible: a group of identical actions still shows an entry whose resource range or consumption bound is much broader than the rest.¶

• Summarize with drill-down: a summary covering every resource, action, and bound, with each complete entry one interaction away. A summary is a view of the set, never a substitute for it.¶

• Surface high-risk entries: make the irreversible, external-commitment, privileged-administration, and consumption-bounded authority of Section 6.3 prominent in the initial view, distinguishing materially different risks and bounds.¶

• Split rather than approve: when the set is too large or varied for one decision, narrower Missions can keep each approval meaningful (Section 1.2).¶

Mission Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) defines layered rendering of a committed disclosure, including what its first layer carries, and lets the Approver ask the basis for an entry before deciding.¶

6.2. Authority Sources

A Mission draws its authority from one of three sources: a delegating person's own authority (user-delegated), a workload's own provisioned authority (service-owned), or explicitly governed organizational policy with a named accountable owner (organizational). The source names whose authority the approval draws on, recorded immutably as the Mission's authority_source; approval_basis records how drawing on it was activated (Section 7), 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. 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 only the task's beneficiary.¶

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

6.3. Approver Authentication Strength

A deployment publishes a statement declaring the minimum approval-authentication strength (the approval-authentication floor) 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 it applies to. This document requires no particular serialization.¶

For the direct flow, a client MAY additionally request an approval-authentication strength on the authorization request using the acr_values and max_age parameters defined in Section 3.1.2.1 of [OpenID.Core]. In a Mission approval interaction these parameters describe the requested authentication of the Approver, not of the token's Subject, who can be a different principal (Section 6, step 2). Requesting them implies nothing about the authentication claims of an issued token, which describe the token's Subject, not the Approver (Section 10); when the Approver is the Subject, one authentication event can back both.¶

The Approver's authentication satisfies acr_values 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 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.¶

An authorization request whose scope includes openid [OpenID.Core] asks for an ID Token about the End-User the approval interaction authenticates, who is the Approver. When the Approver is not the Subject established at step 2 of Section 6, the AS MUST refuse such a request, without creating the Mission, with the invalid_scope error code (Section 4.1.2.1 of [RFC6749]). When the Approver is not the Subject, whether or not openid was requested, the AS MUST NOT issue an ID Token, serve UserInfo, or establish an authentication session for the Subject solely as a result of the Approver's authentication or approval.¶

When the Approver is the Subject, openid, acr_values, and max_age keep their [OpenID.Core] meaning, which then describes the same authentication this document requires. In every approval interaction, prompt, login_hint, and id_token_hint concern the Approver.¶

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. A derived access token carries authentication claims only as authentication information about its own Subject (Section 10), never as evidence of approval.¶

6.4. Binding the Mission to the Grant

A Mission is independent of any OAuth grant: it is identified globally by the pair (issuer, id) (Section 7), and it can be approved, tracked, and terminated with no OAuth grant at all. 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 10.2).¶

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 9 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 refresh token on refresh; or¶

• the Mission-bound subject_token on Token Exchange (the actor_token identifies the delegate, Section 14).¶

It then applies the gating of Section 9.¶

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 (above) 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. The AS resolves a lineage from the grant itself, and no client input names its Mission. An AS that finds a lineage resolving to more than one Mission fails closed on that lineage.¶

Where a profile-defined operation lets a client present a Mission identifier alongside a credential, the identifier is a non-authoritative cross-check: the AS MUST verify it against the Mission the credential resolves to and refuse a mismatch with the invalid_grant error code. The predecessor parameter of [I-D.draft-mcguinness-oauth-mission-expansion] is an example: it selects the Mission a successor is created from and does not reassign an existing binding.¶

The grant binding relates to other mechanisms as follows:¶

• Token Exchange. A Token Exchange derivation ([RFC8693]) that returns only an access token establishes no new grant lineage: ordinary in-Mission delegation (Section 14) and self-exchange down-scoping (Section 14.2) both work this way, and the issued token is a derived token (Section 10.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.¶

• Cross-domain projection. 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.¶

• Child Missions and successors. 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. Any grant binding or derived token they carry is their own under this section's rules, not an extension of the origin Mission's binding. They relate to their origin only by lineage (the child's parent member, the successor's predecessor member).¶

• Continuation handles. A continuation handle and a refresh-token family ([I-D.draft-mcguinness-oauth-mission-continuation]) are credential machinery rooted in one Mission, not the Mission itself: they confer no authority of their own, and a live derivation re-resolves the reference they carry against the Mission's current state.¶

A grant binding is also distinct from a decision-time runtime join, such as the Mission Join of [I-D.draft-mcguinness-mission-authority-server], in which a Policy Decision Point joins an ordinary OAuth credential to a Mission per request. The same credential can be joined to different Missions across separate requests where its subject and client are eligible for more than one. Such a join is not a 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 9.1). 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 9.2, Section 13).¶

An issuer that needs to cascade a lifecycle operation, or to enumerate a Mission's bound grant lineages and credentials, maintains its own issuer-side index from the Mission to each binding; a Mission Management companion ([I-D.draft-mcguinness-oauth-mission-management]) can standardize that index's wire surface.¶

Because the grant, not the identifier, determines the Mission, a client does not supply mission_id to obtain a derivation, and an AS MUST NOT derive Mission-bound authority from a client-supplied mission_id.¶

When the authorization code expires unredeemed, no derivation is possible under the Mission regardless of which lifecycle outcome follows. The deployment either revokes the Mission or lets it reach expired at expires_at, and applies one choice consistently; both outcomes are terminal (Section 9), so reprocessing the same timeout changes nothing.¶

A client learns its mission_id from the mission claim's id on each issued token (Section 10.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, because a client need not parse the access token and cannot read the mission claim of a token that is encrypted or opaque to it. It is an informational reference only: presenting it authorizes nothing (Section 9), 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 7), 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 can be shorter than the requested intent.expires_at.¶

A creation replay deduplicated under the applicable operation identifier (approval_event_id for direct approval (Section 7), 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 22). It is informational in the same way: presenting it authorizes nothing.¶

6.5. Single Accountable Approver

This document records exactly one approver: the accountable principal who approved the Mission. Two richer patterns are outside the scope of this document:¶

• Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers does not change the authority commitment: principals approving the same rendered Authority Set produce the same authority_hash and the same derived tokens. A deployment requiring dual control records one accountable Approver; this document does not represent the co-approvers.¶

• Approval-authority provenance: the standing behind a delegate's authority to approve for another principal (for example, whether an administrator was entitled to approve on a user's behalf). This is governance state about the delegate, not the standing-consent basis that approval_basis records (Section 7).¶

Where a deployment needs either, the Approval Governance Record ([I-D.draft-mcguinness-mission-approval-governance]) records it, and Consent Evidence can carry a partial presentation of that record through co_approvals and its approval-governance members ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). The adjudication.governance_record member (Section 7) marks an approval such a record backs, and Appendix C shows how each scenario assigns the three approval_basis roles.¶

7.1. Standing-Consent Bases

A companion profile can generalize approval to a named standing-consent basis, under which a template or policy activates Mission instances against an accountable human's earlier approval, with no fresh approval event per instance. The type values template ([I-D.draft-mcguinness-oauth-mission-template]) and policy_drawdown ([I-D.draft-mcguinness-oauth-mission-child-delegation]) are such bases. For a standing-consent type, activation takes the shape that its companion profile defines, and activation_actor names a dispatching or requesting party distinct from the consenting human.¶

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). Unlike an unrecognized lifecycle state (Section 9), an unrecognized value here does not by itself invalidate or deactivate the Mission.¶

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

approved_at:

REQUIRED for every standing-consent type. 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.¶

adjudication:

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 still fixed by type and the construction rules of this document or a companion profile (below). Members, where present:¶

kind:

REQUIRED. A string: human or policy, naming a decision mechanism, not a storage location for supporting evidence; a companion profile MUST NOT define a kind value that names a record, an evidence store, or the requesting or dispatching party. 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.¶

For kind: policy: policy, a REQUIRED object with id and version identifying the deciding policy or workflow.¶

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. When true, kind MUST equal the record's accountable assertion's own kind: 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.¶

The adjudication member, where present, follows the basis:¶

• 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 flatten a policy's or an Approval Governance Record's assertion set into a single principal member.¶

Standing-consent recency. A deployment can declare a maximum standing-consent age (a recency ceiling), overall or per consequence class. Where a declared ceiling applies, the activating issuer MUST refuse to activate an instance whose approved_at is older than the ceiling. Where ceilings are declared:¶

• The evaluation instant is the atomic Mission-creation commit (Section 6), including the creation commit of a deferred or relocated flow. Recency is issuance-time eligibility only: a later change to a ceiling, or the passage of time past one, does not terminate an active Mission (Section 9.2).¶

• The activating issuer MUST refuse an approved_at later than the evaluation instant by more than the deployment's declared, bounded clock-skew allowance.¶

• 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, [I-D.draft-mcguinness-mission-metering]), and MUST apply the strictest ceiling across every class present.¶

• The ceilings and the skew allowance belong to the versioned policy that policy_version identifies, or to a separately versioned declaration retained with it, so an auditor can reproduce the eligibility decision.¶

7.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. The AS MUST NOT reuse a Mission Identifier. 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.4).¶

7.3. Worked Example

The following is an example of a Mission Record.¶

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

The hash values above are illustrative: the test vectors (Appendix E) compute anchors over a reduced Mission Intent and Authority Set, not over these objects. A companion that extends this example either reproduces the recorded objects byte-exactly or states that its example diverges and its anchors differ.¶

8.1. Integrity Anchors

Every anchor is computed the same way over a domain-separated, issuer-bound envelope:¶

1. Construct the envelope, where typ selects the committed object and value is that object:¶

   {
     "typ": "<mission-intent | mission-proposed-authority
             | mission-authority-set>",
     "iss": "<the AS issuer URL>",
     "value": <the committed object>
   }
   

   ¶

   For intent_hash, typ is mission-intent and value is the approved Mission Intent object: the Submission envelope's intent member, not 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 is present exactly when 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 cannot be mistaken for another's. The iss binding prevents a committed object from being transplanted across Authorization Servers. The sha-256: prefix is the algorithm-agility mechanism (Section 8.3).¶

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

The typ value space is an extension point (Section 15): 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 Section 4.2 of [RFC7519]). mission- prefixed values, used by this document and the profiles that extend it, form a namespace coordinated through this document's change controller.¶

This document also defines 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 (Appendix E). 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. 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, not 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.¶

authority_hash likewise commits an Authority Set, not a Mission: two Missions that approve byte-identical authority share it, and a consumer MUST NOT use it as a Mission Identifier or as a replay or idempotency key for a Mission.¶

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

• Duplicate member names are rejected at parse time (Section 8.3).¶

• JCS does not reorder array elements, and this document defines no element sorting, so array order is significant. The AS MUST present each committed array in its recorded order wherever it emits the committed object; that order is part of the canonical form.¶

• URI-valued members are compared byte-for-byte, consistent with Section 12 of [RFC9396], unless a member's own type definition specifies a normalization. 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.¶

8.3. Commitment Mechanisms

This document'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 8.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 8.1 binds envelope anchors alone.¶

This section instantiates the default commitment construction of [I-D.draft-mcguinness-mission-substrate]. 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 its envelope are I-JSON [RFC7493] data, as Section 3.1 of [RFC8785] requires. Strengthening Section 3.1 of [RFC8785], which adapts input to I-JSON, the party computing or verifying a commitment MUST reject non-conformant input before canonicalization rather than adapt it: 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.¶

The commitment is over the parsed I-JSON data value, not the source text: JCS 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, as Section 3.1 of [RFC8785] recommends, or defines a stricter numeric domain, as the Mission Resource Access Profile's Common Constraints 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 document 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, so an algorithm added later cannot be exploited as a downgrade. These rules bind a prefixed digest of any species when its defining specification classifies it under this taxonomy and imports this section normatively; this document so classifies its three anchors.¶

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

1. the carrier and schema of any parallel commitment;¶

2. the binding that proves the old and new values commit to the same object;¶

3. producer behavior during the transition;¶

4. verifier selection and downgrade behavior when recognition sets differ; and¶

5. the transition procedure itself.¶

9.1. Issuance Gating

A derivation (defined below) passes these checks, each stated where cited:¶

1. the Mission resolves from the presented grant (Section 6.4);¶

2. the Mission is active (Section 9, and below);¶

3. each emitted entry is a subset of a Mission Authority Set entry (Section 5.1);¶

4. any emitted scope meets Section 10.1; and¶

5. each token's exp does not exceed the Mission's expires_at (Section 10).¶

Unless the referenced Mission is active, the AS MUST refuse, with the invalid_grant error code, a request to derive a token at the token endpoint, on refresh, or on Token Exchange ([RFC8693]). The AS MUST refuse, with the invalid_grant error code, a derivation request it answers after it has acknowledged a revocation of the Mission. Where a profile of a Token Exchange that the AS implements assigns its own error code to either refusal, such as a continuation profile's code for an ended chain, the AS uses that profile's code instead of invalid_grant; the refusal itself, and the mission_error member below, still apply.¶

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]). A companion profile bounds the number of derivations under a Mission ([I-D.draft-mcguinness-oauth-mission-derivation-limits]).¶

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 22) with one of the values mission_revoked, mission_expired, or mission_superseded (where a companion defines supersession). 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.¶

9.2. Revocation

A Mission is revoked when the AS receives an authorized revocation for it. A deployment MUST provide an authenticated means for the Subject, the Approver, or an administrator to revoke a Mission by mission_id, independent of possession of any token (so a Mission can be stopped even when no refresh token is held).¶

This document does not define the wire shape of that operation. A deployment-defined authenticated surface satisfies this requirement; Mission Status ([I-D.draft-mcguinness-oauth-mission-status]) defines an interoperable revoke operation, authorized under its own lifecycle authorization policy.¶

As Section 2.1 of [RFC7009] permits, a deployment's revocation policy can treat revoking a Mission's refresh token as revoking the Mission; a deployment that couples token revocation to Mission revocation documents that behavior.¶

Token validity and Mission validity are distinct: an already-issued access token remains valid until it expires (Section 9.1), so a token can outlive a transition of its Mission by at most the token lifetime. Token introspection (Section 13) is a state-observable overlay that lets a Resource Server see Mission state per request and cut off a revoked Mission before the token expires; Mission Status specifies another, a status surface keyed by mission_id with signed responses. A deployment whose consumers rely on Mission state beyond a token's lifetime offers one of these, so they read current state rather than infer it from token validity.¶

10.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 ([RFC9728]) 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 10) remains preferred.¶

Unknown scope semantics, unknown Resource Server enforcement behavior, or an ambiguous or stale mapping all fail closed under step 5 (Section 12). A changed mapping is not by itself stale: the AS evaluates each issuance, refresh included, against the target's current trusted mapping, and a mapping is stale only when the AS cannot establish that it is the current trusted mapping for that target. 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.¶

Scope projection does not change OAuth response semantics and does not make access-token inspection a client requirement. Section 3.3 of [RFC6749] requires the token response to carry scope whenever the granted scope differs from the requested scope, and its grammar defines no empty scope, so an issuance cannot report an ungranted requested value by omission. The AS MUST refuse, with invalid_scope (Section 12), a request that explicitly names a scope value the issuance cannot grant: a value the target's trusted mapping names but no carried entry makes safe (step 3), or any scope value the AS associates with a target that consumes authorization_details (step 4). An unknown, ambiguous, or stale mapping is a step 5 failure and yields invalid_target even when the request also names a scope value; invalid_scope applies only under a mapping the AS trusts. Where the AS emits a projected scope, a requested scope narrows it to the requested values, and the token response reports the values granted (Section 5.1 of [RFC6749]). Scope values with their own semantics, such as openid ([OpenID.Core]), are unaffected and combine with authorization_details as Section 3.1 of [RFC9396] permits. A Mission-creating client does not request a resource scope for a target that consumes authorization_details; for a scope-only target, a requested scope selects among the values the projection can grant.¶

A refusal caused solely by failure to establish a safe scope projection MUST NOT invalidate an otherwise-valid refresh token or its authorization grant. Independent expiration, revocation, and replay-detection rules continue to apply. An AS meets this by establishing the projection before it consumes or rotates the refresh token, or within the same atomic issuance, not by disabling rotation or restoring a consumed token.¶

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

The runtime profile's enforcement-scope declarations ([I-D.draft-mcguinness-mission-runtime]) can reference the same mapping for the paths it covers; this rule does not depend on that profile.¶

10.2. The Mission Claim

The mission claim is a JSON object:¶

id:

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

issuer:

REQUIRED. A string. The Mission's issuer (Section 7). A credential's iss names the party that minted it; mission.issuer names the party that approved and serves the Mission, and the two 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.¶

expires_at:

OPTIONAL. A string. The Mission's expires_at (Section 7), 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 9).¶

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. The token's own exp bounds only that one credential, not every credential the Mission may still yield.¶

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 11); approval_basis.type is provenance, not authority (Section 7). An authorized introspection caller can receive authority_hash and approval_basis.type (Section 13.1).¶

The mission claim is an open object (Section 15): 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 Section 4.2 of [RFC7519]) 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.¶

The following is an example of a decoded Mission-bound 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"
  }
}

11.1. Remediation Grains

A denial can carry independent remediation grains, each naming a next step without granting anything. This document's own grain is mission_denial (Section 11): which path a denial leads into.¶

A Resource Server can also return the insufficient_authorization error code with authorization_remediation ([I-D.draft-ietf-oauth-rar-metadata-remediation]), which names what mission_denial: insufficient_authority only points at. Each grain keeps the wire shape and response status its 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 16), narrowed same-type (Section 5.1, Section 5.2) like any other proposal.¶

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 Mission AuthZEN Profile ([I-D.draft-mcguinness-mission-authzen]). The three grains compose: a deployment can offer any subset, and none widens authority beyond what Section 5 derives from the same proposal unremediated.¶

13.1. Caller Authorization and Minimization

Strengthening Section 2.1 of [RFC7662], which requires some form of authorization to access the introspection endpoint, 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 10).¶

These rules apply equally to the mission member of an active: false response (Section 13.2).¶

Disclosure is member-scoped as well as caller-scoped. proposal_hash, authority_hash, approval_basis, and authority_source serve 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. By default, an audience-authorized Resource Server receives the audience-filtered enforcement projection above, without them. A mission member that a companion profile defines for disclosure here follows the same member-scoped rule and is not an enforcement input.¶

13.2. Composite Active State

The introspection active member reflects the composite authorization, not the token in isolation. Strengthening Section 4 of [RFC7662], the AS MUST return active: true only when the access token passes that section's checks (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; the Resource Server checks proof of possession when the token is presented, so active: true is not by itself evidence that 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.¶

Reporting the mission member, mission.state included, for an inactive token deviates from the SHOULD NOT of Sections 2.2 and 4 of [RFC7662] against including additional information about an inactive token. The caller authorization and minimization rules (Section 13.1) govern that deviation.¶

13.3. Only the Issuer Reports Mission State

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

13.4. Introspected Token Consumption

The RFC 9068 JWT of Section 10 is this document'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.¶

• In this mode, 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 14): everything Section 10 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 carries active: false and the mission state facts (Section 13.2), 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 11), the fail-closed duties included.¶

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

The per-use freshness rule of Section 13 covers the whole response in this mode: each response is one observation of the token's claims and Mission state, not a cacheable authority record.¶

13.5. Examples

The following is an example of an introspection response for the canonical ERP token (Section 10.2) while the Mission is active. The issuer AS returns the standard [RFC7662] members and the mission member to a caller holding the deployment's audit-and-correlation disclosure privilege, so authority_hash and proposal_hash appear; the default audience-filtered enforcement projection omits them.¶

{
  "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 following is an example of the response for the same token after the Mission is revoked (Section 13.2):¶

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

14.1. Instance Context in Delegated Tokens

Where a deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-id], with attesters a client endorses under [I-D.draft-mcguinness-oauth-client-attesters]), the delegate named by the outermost act can be an actor that an authenticated instance represents. Instance evidence does not establish that actor (Section 5 of [I-D.draft-mcguinness-oauth-client-instance-id]), so the AS establishes the delegate's actor identity, and that actor's trusted association with the instance, separately. Because a delegated token is sender-constrained to the delegate's own key (Section 14), and the Actor Profile makes the top-level cnf the current presenter's key ([I-D.draft-mcguinness-oauth-actor-profile]), that cnf is a key the instance possesses.¶

A deployment MAY convey client_instance in delegated tokens under [I-D.draft-mcguinness-oauth-client-instance-id]. This optional composition selects the authenticated presenting instance for output context. The instance specification owns attestation validation, instance-to-key association, audience-scoped mapping, and Context Consumer validation; this section supplies the Mission-specific authorization and context selection. Deployments configure its use and whether instance attribution is required.¶

When issuing context under this composition, the AS MUST use the presenting instance validated under Section 5 of [I-D.draft-mcguinness-oauth-client-instance-id], establish its trusted association with the separately authenticated delegate, and bind the output token to an instance-unique key whose possession it verified in that exchange. Context is mapped from that validated instance into the output audience's Consumer Scope under Section 7.1 of [I-D.draft-mcguinness-oauth-client-instance-id]. The AS MUST NOT use context copied or remapped from an input token as a substitute for the presenting instance's evidence. For example, when instance B is authorized to continue work from instance A, output context names B; A's context does not become B's identity by remapping it.¶

The actor authentication, delegation eligibility, subset, and lifecycle checks of Section 14 and Section 14.3 still authorize the exchange; instance evidence satisfies none of them by itself. Where deployment policy requires instance attribution, the AS MUST refuse the exchange if the required instance evidence or its association with the delegate and output key cannot be established. Section 12 gives the error codes for these refusals. If the exchange issues a refresh token, the grant-continuity rules of Section 5.1 of [I-D.draft-mcguinness-oauth-client-instance-id] apply alongside Section 6.4; instance continuity alone does not authorize replacement of the recorded instance or key rebinding.¶

Consumers establish presenter attribution under Sections 7.3 and 7.5 of [I-D.draft-mcguinness-oauth-client-instance-id]. This composition does not add provenance to client_instance: a consumer can use the direct-attestation trust configuration only when the issuer meets that configuration's restriction against upstream context. An issuer also conveying upstream context needs a separately specified, authenticated provenance mechanism before its context can support presenter attribution. A consumer requiring attribution rejects unestablished associations under Section 7.6 of [I-D.draft-mcguinness-oauth-client-instance-id].¶

14.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). Because it names no actor, such an exchange does not delegate: it re-scopes the agent's own authority downward. A no-actor exchange is subject to the following:¶

1. The AS MUST refuse a no-actor exchange with the invalid_request error code (Section 2.2.2 of [RFC8693]) unless the authenticated client is the Mission's approved agent (the Mission Record's client_id, Section 7). A delegate narrows only through a delegated exchange that names it in the act chain.¶

2. The result MUST be a subset (Section 5.1) of the presented token's authority; it carries the same mission claim (Section 10.2) and adds no act chain.¶

3. The exchange is a derivation, gated on the Mission being active (Section 9.1).¶

14.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 policy is the delegation member, whose concrete depth and matcher conditions the Mission Resource Access Profile defines ([I-D.draft-mcguinness-oauth-mission-resource-access]). Because the policy lives in the entry, authority_hash commits it with the rest of the Authority Set, and it is carried with the entries wherever they go, including across a cross-domain projection ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

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

1. The entry's type defines a delegation policy for the entry. An entry carrying no type-defined delegation policy is non-delegable, the default.¶

2. That policy, evaluated at depth d, permits this delegate. 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 either condition 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.¶

Empty result. If narrowing leaves no entries for the delegate, the AS MUST refuse the exchange with the invalid_target error code (Section 2.2.2 of [RFC8693]) 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. The AS applies delegation constraints at issuance; a Resource Server sees only the already-narrowed authorization_details and enforces those as usual (Section 10).¶

14.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 following is an example of 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 tool-runner-7, the delegate that authenticated the Token Exchange and requested this token (Appendix B.6); it matches the outermost act only because tool-runner-7 authenticated the exchange itself. client_id does not name s6BhdRkqt3, the originally-approved agent, whose identity remains recoverable from the Mission Record via mission_id (Section 7).¶

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 mission claim is unchanged.¶

15.1. Namespace Taxonomy

This document's extensible namespaces follow one of three postures:¶

• Registry-backed. A namespace whose values determine fail-closed behavior and span multiple documents is backed by an IANA registry. This document creates the Mission Lifecycle States (Section 22.7) and Mission Intent Members (Section 22.8) registries and seeds each with the values it defines; 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.¶

• Specification-defined. A namespace with a defined fail-safe for unknown values and no registry, such as the mission claim members (Section 10.2) and the Mission Record members (Section 7), is specification-defined: the defining documents are its value space.¶

• Collision-resistant. Deployment-defined names are collision-resistant names (Section 4.2 of [RFC7519]) and are never registered.¶

A typ inside a JCS commitment envelope (Section 8.1) names a hash domain, not a representation crossing a protocol boundary, and is not a media type.¶

19.1. Commitment and Consent Integrity

19.2. Agent-Specific Threats

19.3. Enforcement Boundaries

19.4. Credentials and Delegation

19.5. Composition and Residual Authority

20.1. Mission Identifier Correlation

This document carries a single canonical Mission Identifier on every derived token, and 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.¶

That stable anchor is what lets a Resource Server, a cross-domain Resource AS, and an auditor bind credentials and evidence to one approved Mission; this document does not provide cross-audience unlinkability (Appendix B.5).¶

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; they work against the stable anchor, and this document does not define them. 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.¶

20.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. Single-audience tokens, one per Resource Server, are the minimization measure: they carry only the entries the consuming Resource Server needs, as Section 2.3 of [RFC9700] recommends (Section 10).¶

20.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, and their retention and erasure follow Section 20.5. The integrity anchors are unsalted commitments: a party holding a candidate Intent can confirm it against intent_hash, and a candidate proposal against proposal_hash. Over low-entropy or guessable content each anchor is therefore a disclosure channel, and deployments treat it as one when the Intent itself is sensitive.¶

20.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. 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 domain's own lane (the Resource Server, a gateway, a policy decision point, or an authorization server acting for the domain) evaluates it through that lane's mechanisms, such as claims gathering or a resource-domain consent artifact. That lane refuses access while required evidence is absent or invalid; the refusal is the resource's answer, and Mission authority does not override it.¶

Mission approval and Mission authority are not the data subject's consent: a Mission Record can retain a verified consent reference or facts as submission_evidence (Section 7), and those facts are provenance and policy input only, which the resource domain validates independently under its current disclosure policy.¶

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

• submission_evidence facts, including a consent reference.¶

Whatever the member, it persists on the Mission Record for its audit horizon (Section 7), concentrates at the AS with the record (Section 20.5), and, if committed, is confirmable through the unsalted anchors by any party holding a candidate value (Section 20.3). Referencing a third party through resource-scoped or pseudonymous identifiers, rather than identifying prose, minimizes this exposure; an opaque identifier is minimization, not anonymity, and personal-data obligations follow it.¶

20.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, not the record: nothing in this document puts goal, task_bounds, or other Intent content in a credential. 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.¶

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. Retention and erasure are deployment policy, bounded below by the audit horizon (Section 7). Where approval-event evidence was registered under the audit transparency profile ([I-D.draft-mcguinness-mission-audit]), its erasure record and data-subject-request basis are the transparency-side mechanism: it records an erasure but neither performs one nor overrides retention law, and it leaves the operational Mission Record and its audit-horizon retention floor untouched.¶

22.1. OAuth Parameters Registration

This document requests registration of the following in the "OAuth Parameters" registry:¶

• Name: mission_intent¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

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

• Name: mission_id¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

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

• Name: mission_error¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

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

• Name: mission_expires_at¶

• Parameter Usage Location: token response¶

• Change Controller: IETF¶

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

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 is carried in the token-endpoint error response, for which "token response" is the registry's applicable usage location; it uses the error response's JSON extensibility rather than defining a new error code. The mission_denial attribute uses the extensible auth-param space of the WWW-Authenticate scheme ([RFC6750], Section 11), for which no IANA registry exists; no action is required for it.¶

22.2. OAuth Extensions Error Registration

This document requests registration of 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: IETF¶

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

A code distinct from invalid_request lets a client tell a malformed submission from missing or untrusted evidence, and remedy each differently.¶

22.3. JSON Web Token Claims Registration

This document requests registration of the following in the "JSON Web Token Claims" registry:¶

• Claim Name: mission¶

• Claim Description: Reference to the Mission a token was derived under.¶

• Change Controller: IETF¶

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

22.4. OAuth Token Introspection Response Registration

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

• Name: mission¶

• Description: The Mission a token was derived under, with its current lifecycle state when returned by the Mission's issuer (Section 13).¶

• Change Controller: IETF¶

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

22.5. OAuth Authorization Server Metadata Registration

This document requests registration of 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: IETF¶

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

22.6. OAuth Protected Resource Metadata Registration

This document requests registration of 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: IETF¶

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

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

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 9). A Designated Expert MUST reject a registration whose governing specification attempts to redefine this interaction rather than adding a new value bound by it.¶

Each registration records:¶

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

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

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

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

• Reference: the specification defining the state.¶

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

Each further document that defines a lifecycle state requests that state's registration in its own IANA considerations.¶

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

The registry resolves ownership of a short top-level name, so that two independently implemented specifications cannot assign it incompatible schemas. Registration defines no member semantics and confers no authority (Section 15). A companion profile can instead use a collision-resistant name without registering it.¶

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 as stable without confirming that its owning specification's promotion criteria are met, 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:¶

Each further document that defines a Mission Intent member requests that member's registration in its own IANA considerations.¶

23.1. Normative References

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

McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-id-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-00>.

[RFC2119]

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC6920]

Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/rfc/rfc6920>.

[RFC7493]

Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/rfc/rfc7493>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[RFC9101]

Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, <https://www.rfc-editor.org/rfc/rfc9101>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9207]

Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, March 2022, <https://www.rfc-editor.org/rfc/rfc9207>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC9700]

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

[RFC9728]

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

23.2. Informative References

[AuthZEN.ARAP]

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

[FAPI.GrantManagement]

OpenID Foundation, "Grant Management for OAuth 2.0", 2022, <https://openid.net/specs/fapi-grant-management-01.html>.

[I-D.draft-cecchetti-oauth-rar-cedar]

Cecchetti, S., "Cedar Profile for OAuth 2.0 Rich Authorization Requests", Work in Progress, Internet-Draft, draft-cecchetti-oauth-rar-cedar-02, 21 February 2024, <https://datatracker.ietf.org/doc/html/draft-cecchetti-oauth-rar-cedar-02>.

[I-D.draft-ietf-oauth-rar-metadata-remediation]

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

[I-D.draft-ietf-oauth-spiffe-client-auth]

Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-02, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

[I-D.draft-ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11>.

[I-D.draft-ietf-wimse-aims]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf-wimse-aims-00, 15 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00>.

[I-D.draft-ietf-wimse-arch]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-08, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08>.

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

McGuinness, K., "Mission Approval Governance", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html>.

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

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

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

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

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

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

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

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

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

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

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

McGuinness, K., "Mission Intent Shaping", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.

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

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

[I-D.draft-mcguinness-oauth-actor-profile]

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

[I-D.draft-mcguinness-oauth-client-attesters]

McGuinness, K., "OAuth 2.0 Client Attester Endorsement", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-attesters-00, 28 September 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-attesters-00>.

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

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

[I-D.draft-mcguinness-oauth-mission-approved-set-verification]

McGuinness, K., "Mission Approved-Set Verification for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approved-set-verification.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

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

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

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

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

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

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

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

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-derivation-limits]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[I-D.draft-mcguinness-oauth-mission-work-products]

McGuinness, K., "Mission Work Products", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-work-products.html>.

[I-D.draft-niyikiza-oauth-attenuating-agent-tokens]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01>.

[OpenID.Core]

OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8935]

Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935, November 2020, <https://www.rfc-editor.org/rfc/rfc8935>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

A.1. Stage 0: Agent Identity (by Reference)

The agent is an OAuth client with a workload identity, for example one established using WIMSE [I-D.draft-ietf-wimse-arch] or SPIFFE [I-D.draft-ietf-oauth-spiffe-client-auth]. alice has delegated to it through an ordinary authorization code flow, per [I-D.draft-ietf-wimse-aims]: 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"
  }
}

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.4), gates on it being active (Section 9), and issues a Mission-bound access token for the ERP. The token response carries the granted authorization_details echo (Section 10) and the mission_id and mission_expires_at response parameters (Section 6.4):¶

{
  "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 following is the decoded access 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"
  }
}

The token carries everything enforcement needs: the audience, the sender constraint (cnf), the authority with its constraints, and the mission claim naming the Mission it was derived under. Its 300-second lifetime ends well before the Mission's expires_at. Revoking the Mission stops further derivation; this token remains valid until its own exp (Section 9.2).¶

A.4. Stage 3: The Resource Server Enforces

The agent calls the ERP Resource Server (erp.example.com) with that token. The Resource Server validates the JWT and the cnf binding and enforces the authorization_details whose resource it serves, permitting invoices.read within the Q3 issuance window and journal-entries.write up to the max_amount ceiling of 500.00 USD (Section 11). 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: the baseline bounds the consequential journal-entries.write only by token lifetime and the carried constraints. Where the deployment runs the runtime profile ([I-D.draft-mcguinness-mission-runtime]), the Resource Server also obtains a point-of-use permit from a policy decision point, against current Mission state, before executing the write.¶

The end-to-end example of the Mission Cross-Domain Projection profile ([I-D.draft-mcguinness-oauth-mission-cross-domain]) continues this Mission to a partner ERP in another trust domain.¶

B.1. Relationship to Existing OAuth Objects

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. It is therefore not another authorization_details type. Rich Authorization Requests already express authority; what OAuth lacks is the approved task with a lifecycle, the durable, approval-backed object an Authority Set is derived for and gated by.¶

B.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 can surface Mission revocation through a grant-management-style API (Section 9.2).¶

[I-D.draft-ietf-wimse-aims] names the agent's mission and leaves its translation into authorization requirements out of scope. This document specifies that translation, reusing its agent-as-client and delegating-principal-as-token-sub assignments unchanged (Section 3.1); 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 do not tie an approval to token issuance; 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: a continuable authorization request, richer client instance identification, and native support for delegation. Rather than introduce a new grant protocol, endpoints, and client machinery, this document composes with the OAuth 2.0 surfaces already deployed: Pushed Authorization Requests ([RFC9126]), Rich Authorization Requests ([RFC9396]), DPoP ([RFC9449]), and [RFC9068] access tokens. A deployment 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.¶

The Authority Set's subset rule (Section 5.1) continues the lineage of capability systems in which a holder narrows what it passes on without further contact with an issuer: macaroons' caveat narrowing, Biscuit's offline attenuation blocks, UCAN's delegation chains, SPKI/SDSI's local-name reduction, and object-capability designs generally. What this document narrows is a durable, approval-anchored object that its issuer can revoke for the Mission's full lifetime, not a bearer credential whose only life is its caveats, so revoking the Mission still reaches everything derived from it that has not already left the issuer's reach (Section 9.2).¶

B.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 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 on its delegated token (Section 14), derived from the Mission and only narrowed from it (Section 5.1), not 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 9); 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 19.3.1), not this document's.¶

Across all three, the plan and the execution draw on the Mission's authority; neither enlarges it.¶

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

B.4. Scope and Future Work

This document is self-contained: 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]) 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.¶

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 18), 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 19.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].¶

Future work 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 does not standardize the derivation algorithm itself (Section 5); a vertical profile is the appropriate vehicle where portable derivation is needed.¶

This document defines no mechanism that pins a Mission to an approved agent deployment class or version, and reserves no Intent member for one. Such a pin needs two objects rather than one Intent member: a committed approval-context pin, and presenter-instance evidence checked at every derivation (for example, using [I-D.draft-mcguinness-oauth-client-instance-id] and [I-D.draft-mcguinness-oauth-client-attesters]). A profile that defines the pin also defines its request carriage and resolution to an approved deployment identifier, its Mission Record extension and approval rendering, and its fail-closed behavior when the client cannot prove the pin.¶

This document defines no cumulative consumption bounds (for example, a budget, call-count, or activity-duration cap). 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]).¶

B.5. Non-Goals

The following are out of scope for this document:¶

• Semantic / intent verification. This document 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 19.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 document 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 is out of scope.¶

• Lifecycle event distribution. A Resource Server learns Mission state from the token lifetime or optional introspection (Section 13); this document 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]).¶

• Human-in-the-loop suspension. The base lifecycle is active, revoked, expired (Section 9). A suspended state with resume/complete transitions is defined as an optional extension by Mission Status ([I-D.draft-mcguinness-oauth-mission-status]); a pending-human-approval state and a holding-token pause-and-resume protocol are 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-ietf-wimse-aims] and the WIMSE architecture, [I-D.draft-ietf-wimse-arch]); this document governs the approved-task artifact those identities act within, not the identities themselves.¶

• Cross-audience unlinkability. A single canonical Mission Identifier lets any party holding a token correlate a Mission's activity across audiences and resources. 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. authority_hash is not 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 10.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 20.1).¶

B.6. The client_id Claim in Delegated Tokens

This profile keeps client_id's registered meaning, stated normatively in Section 10 and enforced in Section 11: the OAuth client that requested the token, on every issued or derived token, a delegated one included. Downstream delegates are named in the act chain (Section 14), and the Mission's originally-approved agent remains recorded in the Mission Record (Section 7), without redefining a registered claim.¶

The alternative, fixing client_id to the approved agent on every derived token, would lead a generic [RFC9068] Resource Server or logging pipeline to attribute a delegate's action to the approved agent with no error to surface the mismatch. It would be safe only where every Resource Server already processes the act chain, as a Mission-aware Resource Server does (Section 11). The routing rule of Section 11 does not depend on this choice: the mission claim's presence signals that a token may carry an act chain a consumer needs to process, a Mission-unaware Resource Server cannot opt into that processing, and routing a delegated token to one is therefore forbidden.¶

D.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 is not transmitted; 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.¶

D.2. Properties a Derivation Policy Holds

The five properties below restate, for a policy author, what Section 5 and the rules it cites require of a derivation.¶

• Deterministic. The same Intent, proposal, ceiling, and catalog derive the same Authority Set, so policy_version can serve as an audit correlator (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; [I-D.draft-mcguinness-oauth-mission-resource-access] defines the Common Constraints and their intersection rules.¶

• Refusal over silent drop. An entry of an unsupported type, an entry that fails its schema, and an entry carrying a constraint the engine cannot compare, whether registered or deployment-defined, are refused (Section 4.2, Section 5.1, Section 12). Derivation does not repair them by omitting the entry or dropping the constraint: a dropped constraint widens the grant. An entry the engine compares but policy cannot accept is the distinct case: it is narrowed or omitted, and the granted echo reflects that (Section 4.2).¶

• Issuer-established members are not client-supplied. The issuer establishes policy_version (Section 5), and authority_source and approval_basis (Section 6.2, Section 7), at the approval event; no proposal member sets them.¶

• 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 cannot introduce a capability the policy did not confer. A restriction nested inside an already-granted delegation, such as allowed_delegates, narrows in the ordinary direction.¶

D.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 proposed entry intersects the same-resource ceiling entries; an empty action intersection contributes no authority.¶

Attaching the amount cap to a single mixed read and write proposal does not reach that result: the read supplies no amount for the cap to compare against, so the deployment refuses the proposal at intake rather than letting derivation drop the cap from the read fragment. A write proposal naming a different currency likewise cannot produce the USD intersection shown. A proposal carrying a Common Constraint this deployment does not compare is refused with the invalid_authorization_details error code (Section 12), not derived with the constraint dropped. These are negative fixtures alongside the positive result, not special cases that relax the type's relation.¶

D.4. Fixtures and Authoring Discipline

Versioned Intent and proposal fixtures with expected Authority Sets make the optional publication in Section 5 concrete. Reviewing their diffs on every policy change exposes altered grants before approval. Fixtures cover empty intersections, unknown constraints, incomparable values, and attempts to introduce delegation, as well as normal template and narrowing outcomes, and check each subset against both the proposal and the ceiling.¶

A further check runs the shipped configuration through intake, derivation, and a real decision path, since a configuration that loads does not thereby authorize its intended workload. Applying the same entry checks at configuration load and at client intake keeps those two surfaces from disagreeing.¶

D.5. Ownership and Operational Signals

Templates amortize authoring across Missions and do not bypass the ceilings. The unmapped-resource rate, template-hit rate, and rule-exception rate show an operator where its policy authoring remains incomplete.¶