Mission-Bound Authorization for OAuth 2.0

1.1. Why a New Object

OAuth already has objects near this need, but none is the approved task. A scope value or an authorization_details entry ([RFC9396]) expresses authority but neither the task it serves nor a lifecycle of its own. An access token is a short-lived projection; its jti identifies the token, not the task. A refresh token preserves the ability to obtain further tokens but commits no bounded, approved authority. A consent record proves that an approval event happened; it does not govern the resulting work as it continues. The Mission is the durable object these project from: the approved task that bounds and outlives them, and that every derived token refers back to.¶

Put plainly: Rich Authorization Requests express authority; a Mission expresses an approved task with a lifecycle. The Mission is a separate object because that approved-task lifecycle, not a new way to express authority, is what OAuth lacks. A Mission is therefore not another authorization_details type; it is the durable, approval-backed object an Authority Set is derived for and gated by.¶

1.2. The Mission, the Plan, and Execution

The Mission is the durable, AS-held object that commits the approved authority and owns the task's lifecycle. Two related things an agent produces around a task are deliberately not the Mission and carry no authority of their own.¶

The agent's plan, how it decomposes the task, chooses tools, and delegates to sub-agents, is the agent's own strategy and is out of scope for this document. It grants nothing: authority a sub-agent exercises is carried by the act chain (Section 11), derived from the Mission and only ever narrowed from it (Section 5.1), never created by the plan.¶

The agent's execution, the tokens it derives, the calls it makes, and the decisions taken on them, references the Mission but cannot expand it. Revoking the Mission stops further derivation (Section 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 15.3), not this document's.¶

The invariant across all three: the plan and the execution draw on the Mission's authority; neither enlarges it.¶

1.3. Relationship to Agent-Identity Specifications

This document is complementary to [I-D.draft-klrc-aiagent-auth] and reuses its model: the agent is the OAuth client (client_id); the delegating user or system is the token sub. This document does not define agent identity, credentialing, or posture; it defines the approved-task artifact those identities act within. An agent authenticated and delegated per that specification uses the mechanisms here to obtain Mission-bound tokens.¶

1.4. Applicability

This profile targets OAuth deployments where authority serves a durable, user-approved task that spans more than one token, request, or audience: an agent pursuing a multi-step objective on a user's behalf, or a workflow whose audit must join activity across hops on a shared task. It is not intended for, and adds cost without benefit to, single-request user flows, machine-to-machine service credentials, or short-lived authorizations where the credential's lifetime is the task's lifetime; those use OAuth unchanged.¶

A Mission SHOULD be scoped to a concrete task, not to an agent's whole lifetime. A deployment SHOULD prefer narrow, per-task Missions, each separately approved and revocable, over a single broad standing Mission that accumulates authority across unrelated tasks. The durable object is the approved task: keeping it task-scoped is what makes its authority and audit meaningful and bounds the blast radius on compromise to one task. An agent pursuing many tasks holds many Missions, not one broad one.¶

1.5. Scope and Future Work

This document is a self-contained, minimum-viable profile: it binds Missions to OAuth 2.0 and is implementable on its own, depending only on the OAuth and JOSE specifications it cites. A single cross-domain hop is supported as an optional binding (Section 12); the single-domain core is implementable without it.¶

Two normative dependencies are on in-progress individual drafts, so this document cannot advance ahead of them: the OAuth Actor Profile ([I-D.draft-mcguinness-oauth-actor-profile]) for the act chain, and the identity-chaining and ID-JAG drafts ([I-D.draft-ietf-oauth-identity-chaining], [I-D.draft-ietf-oauth-identity-assertion-authz-grant]) for cross-domain projection. Both are confined to OPTIONAL capabilities (Delegation and Cross-Domain), so the mandatory single-domain core does not depend on them.¶

Separate from this document, and not required to implement it, are several capabilities now specified as OPTIONAL companion profiles: an additional integrity anchor over a structured consent disclosure (consent_rendering_hash, Section 15.1) is defined by Mission Consent Evidence [I-D.draft-mcguinness-oauth-mission-consent-evidence]; mission expansion is defined by Mission Expansion [I-D.draft-mcguinness-oauth-mission-expansion]; and a cross-domain status or event-distribution mechanism for tighter revocation is defined by Mission Status [I-D.draft-mcguinness-oauth-mission-status] and Mission Lifecycle Signals [I-D.draft-mcguinness-oauth-mission-signals]. A deployment implements this document without any of them. Remaining future work, not yet specified, includes a substrate-neutral generalization of the Mission model across non-OAuth authorization substrates, the normative carriage of Mission context in Transaction Tokens (shown only illustratively in the end-to-end example appendix), and, for a community that wants cross-vendor agreement on what a task authorizes within a vertical, an OPTIONAL derivation profile: a registry of standard task types mapped to authority templates, so that two vendors in that profile derive comparable Authority Sets. This document deliberately does not standardize the derivation algorithm itself (Section 5); a vertical profile is the appropriate vehicle where portable derivation is genuinely needed.¶

1.6. Non-Goals

The following are deliberately out of scope. Each is a recurring question for agent authorization; naming it here records that it was considered and where it belongs, not that it was overlooked.¶

• Semantic / intent verification. This profile binds a token to an approved authority and task; it does not evaluate whether a given runtime action serves the Mission's purpose beyond matching the approved authorization_details and constraints. Per-action evaluation is the runtime layer's role (Section 15.3). Verifying an agent's declared reasoning against the task is a further attestation problem outside both layers.¶

• Approval-free authorization upgrade. The Authority Set is committed at approval; this profile defines no mid-stream widening that bypasses consent. Widening requires a new approval, a successor Mission, as specified by Mission Expansion [I-D.draft-mcguinness-oauth-mission-expansion]. That approval MAY be given by policy rather than by a human when the original approval pre-consented to an authority ceiling and a drawdown policy (progressive authorization, [I-D.draft-mcguinness-oauth-mission-expansion]); a widening that no consent, human or pre-given, authorizes remains out of scope.¶

• Lifecycle event distribution. A Resource Server learns Mission state from the token lifetime or optional introspection (Section 10); this profile defines no push-based notification of Mission state changes. A Shared Signals ([RFC8935]) / CAEP profile for Mission lifecycle events is specified separately by the Mission Lifecycle Signals profile ([I-D.draft-mcguinness-oauth-mission-signals]), not here.¶

• Human-in-the-loop suspension. The base lifecycle here is active, revoked, expired (Section 9). A suspended state with resume/complete transitions is defined as an OPTIONAL extension by the Mission Status and Lifecycle profile ([I-D.draft-mcguinness-oauth-mission-status]); a pending-human-approval state and a holding-token pause-and-resume protocol remain future lifecycle work.¶

• Multi-hop cross-domain provenance. A single cross-domain hop is supported (Section 12); chaining a Mission across more than one trust-domain boundary, and the verifiable provenance that would require, are future work.¶

• Decentralized agent identity. Agent identity and credentialing are out of scope ([I-D.draft-klrc-aiagent-auth], and workload identity efforts such as WIMSE); this profile governs the approved-task artifact those identities act within, not the identities themselves.¶

1.7. Conventions and Terminology

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

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

Agent (Client):

The OAuth client acting on a user's behalf, identified by client_id. Agent identity is established per [I-D.draft-klrc-aiagent-auth] or ordinary OAuth client authentication.¶

Subject:

The user or system on whose behalf the Mission is approved, identified by an (iss, sub) pair and carried in derived tokens' sub claim.¶

Approver:

The single accountable principal who approves the Mission at the approval event. Equal to the Subject for self-approval; different for administrator or delegated approval. This document records one accountable Approver; multi-party approval and the provenance of delegated approval authority are deferred (Section 6.2).¶

Mission Issuer (Authorization Server):

The OAuth AS that validates a Mission Intent, runs the approval event, records the Mission, and derives tokens. It is the Mission's origin. "Mission Issuer", "originating AS", and "AS" are used interchangeably in this document.¶

Resource AS:

An Authorization Server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources from a cross-domain grant (Section 12), for which the Identity Assertion Authorization Grant (ID-JAG) is the recommended profile. A Resource AS is never the Mission Issuer. Relevant only to deployments using the optional cross-domain binding.¶

Mission Intent:

The structured description of the task the client submits (Section 4).¶

Authority Set:

The set of authorization_details entries the AS derives from a Mission Intent and the Approver approves (Section 5).¶

Mission:

The durable, immutable record created at the approval event (Section 7), identified by a mission_id.¶

Derived token:

An access token issued under a Mission, carrying its Mission-derived authority (the full Authority Set or a narrowed subset) as authorization_details and a mission claim (Section 8).¶

3.1. Principal Model

This document carries principals natively to OAuth:¶

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

• The Subject and Approver are each an (iss, sub) pair, matching the access token sub model of [RFC9068].¶

On a derived token the sub claim is the Subject's sub and the token iss is the AS; within the issuing AS's namespace this (iss, sub) pair is authoritative for the Subject, and Resource Servers authorize against it. The Subject's home issuer is recorded on the Mission as subject.iss for audit and is not carried on the token; this document defines no runtime lookup of it (there is no by-Mission status endpoint). Across trust domains, the ID-JAG conveys Subject identity to the Resource AS through its own subject-resolution claims (Section 12), not through a Mission lookup.¶

Principals are recorded at the approval event and are immutable. Two principals are equal when their iss and sub are byte-equal. Dynamic delegation (the actors an agent delegates to during execution) is carried on derived tokens via the act chain (Section 11), not on the immutable Mission record. Richer subject identifier formats (for example, the formats of [RFC9493]) MAY be layered in future versions and are not required here.¶

3.2. Protocol Flow

 Agent (client)                       Mission Issuer (AS)
      |                                     |
      | 1. PAR: mission_intent ------------>| derive authority
      |<----------- request_uri ------------| (authz_details)
      |                                     |
      | 2. authorization request ---------->| principal consents
      |                                     |   -> authority_hash
      |<-------------- code ----------------| -> Mission active
      |                                     |   (bound to the grant)
      |                                     |
      | 3. token request ------------------>| gate: active?
      |<----------- access token -----------| + authz_details
      |                                     |   + mission claim
      v

The flow then leaves the AS: (4) the agent calls the Resource Server with the token; the RS enforces the authorization_details statelessly and MAY check the mission claim, with no callback to the AS required. (5) A management revoke or mission_expiry moves the Mission to revoked or expired, after which the AS refuses further issuance and refresh; a deployment MAY additionally compose RFC 7009 [RFC7009] refresh-token revocation (Section 9.2).¶

4.1. Submission via PAR

A client MUST submit a Mission Intent through a Pushed Authorization Request [RFC9126] using the mission_intent request parameter. The parameter value is the UTF-8 JSON [RFC8259] serialization of the Mission Intent 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). 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 it structurally invalid against this document's member definitions, MUST refuse the request with invalid_request.¶

A different case is an Intent that is well-formed but from which the AS cannot derive a valid Authority Set (for example, an unsupported resource, action, or authorization details type, or a policy that bars the requested authority). In that case the AS SHOULD refuse with invalid_authorization_details ([RFC9396]), even though the client did not submit authorization_details directly. This lets a client distinguish a syntax error from an authority-derivation failure.¶

The Intent MUST arrive through PAR: an AS MUST reject a mission_intent presented directly on a front-channel authorization request, rather than through a PAR-issued request_uri, with invalid_request. PAR keeps the integrity-sensitive Intent off the untrusted front channel. Because mission_intent is untrusted client input that the AS records and hashes, a deployment SHOULD also bound its total size and the lengths of its arrays, refusing an Intent that exceeds those limits with invalid_request.¶

A client MUST NOT submit authorization_details directly together with mission_intent; the AS derives authorization details from the Intent (Section 5). A request carrying both MUST be refused with invalid_request. A client MAY submit scope and resource ([RFC8707]) values; the AS treats them as a requested subset and MUST NOT grant authority beyond what the Mission Intent yields.¶

For a Mission request, the parameters pushed via PAR are authoritative. The AS MUST ignore any mission_intent, authorization_details, scope, or resource presented on the front-channel authorization request that redeems the request_uri. The AS MUST NOT let such a front-channel value widen the authority derived from the pushed Intent.¶

A Mission Intent is untrusted client input. Trust enters only when the AS validates it and the Approver consents to the rendered result. The AS MUST treat the submitted Intent as a proposal, never as authority. The AS MUST derive authority and bound it by policy regardless of what the client submitted. How a client produces the Mission Intent (for example, a "Mission Shaper" that derives it from a natural-language instruction) is out of scope for this document.¶

5.1. Subset Rule

When the AS narrows the Authority Set for a derived token, a derived mission_resource_access entry A is a subset of a Mission entry B when:¶

1. A.resource equals B.resource.¶

2. A.actions is a subset of B.actions.¶

3. For every key K in B.constraints, K MUST also be present in A.constraints, and A's value MUST be no broader than B's under K's subset rule: the registered rule when K is a Common Constraint (Section 5.2), the deployment-defined comparison otherwise. A key present in B but absent from A is treated as the broadest possible value and therefore fails this test. In short, constraints MUST NOT be dropped, only added or tightened.¶

The AS MUST refuse to derive an entry that is not a subset of some Mission Authority Set entry.¶

The delegation member is policy, not authority, and is not part of this comparison (Section 11.1). A derived entry's delegation, when present, MUST NOT be broader than the parent entry's: its max_depth MUST be no greater and its allowed_delegates MUST be no wider. A derived entry MUST NOT introduce delegation where the parent entry has none.¶

5.2. Common Constraints

A constraints member name (Section 5) is either a registered Common Constraint or a deployment-defined key. Common Constraints give independently developed deployments one vocabulary they interpret, narrow, and compare identically; the "Mission Common Constraints" registry (Section 17.6) is the extension point.¶

A registered Common Constraint defines:¶

• Value syntax: the JSON [RFC8259] value type and any additional rules.¶

• Subset rule: how a candidate value is judged no broader than a reference value, used by the subset comparison of Section 5.1.¶

• Intersection rule: how two values for the same key combine; the result MUST be no broader than either operand.¶

A constraints member whose name is registered is interpreted per the registry. A member whose name is not registered remains deployment-defined and is interpreted only within the issuing deployment; a consumer that does not recognize it MUST fail closed (Section 8.2).¶

This document registers the initial Common Constraints:¶

• max_amount_usd (number): a per-action ceiling, in US dollars, on a monetary amount. Subset: no broader when less than or equal to the reference value. Intersection: the minimum of the two values.¶

• issued_after (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or after this instant. Subset: no broader when greater than or equal to the reference. Intersection: the later instant.¶

• issued_before (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or before this instant. Subset: no broader when less than or equal to the reference. Intersection: the earlier instant.¶

5.3. Other Authorization Details Types

mission_resource_access is the only type this document defines, but the Authority Set MAY include other AS-supported [RFC9396] authorization_details types when an audience consumes them. ("Supported" here means the AS recognizes and documents the type, as advertised by authorization_details_types_supported (Section 14); RFC 9396 establishes no IANA registry of type identifiers.) The Mission apparatus is type-agnostic toward such entries:¶

• they are committed by authority_hash and gated on Mission state exactly as mission_resource_access entries are;¶

• narrowing and delegation use the subset semantics the type defines (Section 5.1, Section 11.1). A type whose subset and delegation semantics the AS does not understand MUST NOT be delegated, audience-projected to a Resource AS, or narrowed: the AS cannot prove a transformed copy is still a subset of what was approved. Such an entry MAY be issued only to its original approved audience, carried exactly as approved, and MUST NOT appear in a delegated or cross-domain (ID-JAG) token;¶

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

This lets policy-language profiles compose without this document defining them: for example, an entry carrying a Cedar policy set ([I-D.draft-cecchetti-oauth-rar-cedar]), or an analogous AuthZEN policy entry, for an audience that evaluates it. The AS derives such an entry from the Mission Intent and bounds it by the Intent like any other, but treats the carried policy largely opaquely; the Resource Server or Policy Decision Point (PDP) evaluates it at request time.¶

Example (non-normative): an Authority Set with a Cedar policy entry for a finance audience that consumes Cedar, alongside a mission_resource_access entry for a calendar audience that does not. The Cedar policySet is abbreviated:¶

[
  {
    "type": "account_information",
    "rarFormat": "cedar",
    "policySet": "permit(principal, action, resource) when {...};"
  },
  {
    "type": "mission_resource_access",
    "resource": "https://calendar.example.com",
    "actions": ["events.read"],
    "constraints": { "window_days": 30 }
  }
]

Both entries are committed by the one authority_hash and bound to the Mission. The Cedar entry is evaluated by the finance audience's PDP; the mission_resource_access entry is enforced as in Section 8. Because the Cedar profile defines no subset rule over policy sets, the AS carries the Cedar entry as approved rather than narrowing it; the per-entry delegation controls still bound who may delegate it and how far.¶

5.4. Modeling Tools and Function Calls

This section is non-normative guidance. A "tool" an agent invokes, such as a Model Context Protocol (MCP) tool or a function call, is modeled as a mission_resource_access entry. No separate entry type is needed, and the rules above (derivation, subset, delegation, authority_hash) apply unchanged.¶

The mapping is:¶

• resource is the tool provider. For an MCP tool it is the MCP server's URL. The MCP authorization model makes the server an OAuth 2.0 resource server, so this is the resource identifier a token is audience-bound to.¶

• actions are the tool names the task needs at that provider. Authorizing a tool is authorizing its name as an action, which lines up with MCP filtering its tool list by the caller's granted authority and routing each tool call for authorization.¶

• constraints carry machine-actionable bounds on a tool's arguments, for example an amount ceiling or a recipient domain. Like all constraints, they are committed by authority_hash and carried to the point of use, but they are evaluated against the concrete call arguments by a runtime enforcement layer, not at issuance (Section 15.3).¶

For example, a Mission authorized to read invoices and post small adjustments through a finance MCP server, and to send messages through a messaging MCP server, derives:¶

[
  { "type": "mission_resource_access",
    "resource": "https://finance.example.com/mcp",
    "actions": ["query_invoices", "post_adjustment"],
    "constraints": { "max_amount_usd": 500 } },
  { "type": "mission_resource_access",
    "resource": "https://mail.example.com/mcp",
    "actions": ["send_message"],
    "constraints": { "recipient_domain": "example.com" } }
]

Delegation to a sub-agent works unchanged: add a delegation member to a tool entry (Section 11.1). For example, an entry a sub-agent of type ai_agent may invoke at depth 1, narrowed to the read tool only:¶

{ "type": "mission_resource_access",
  "resource": "https://finance.example.com/mcp",
  "actions": ["query_invoices"],
  "delegation": {
    "max_depth": 1,
    "allowed_delegates": [{ "sub_profile": "ai_agent" }]
  } }

What this profile does not provide for tools is a typed, attenuable per-argument constraint grammar: narrowing one tool's argument schema against another (for example, amount in a range, recipient in a one_of set) as the grant is derived or delegated. Argument bounds here are the same flat, carried constraints used for any resource, evaluated at runtime. Structured per-argument attenuation ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens], with object capability systems such as UCAN as prior art) is a richer primitive deferred to future work; it would extend the delegation and subset model of this document (Section 11.1, Section 5.1) rather than introduce a new entry type.¶

6.1. Binding the Mission to the Grant

At the approval event the AS binds the Mission to the authorization grant it issues: the authorization code, and the refresh token issued from it. The binding is server-side and is what "the referenced Mission" in Section 9 refers to: at each subsequent derivation the AS resolves the Mission from the grant the client presents: the authorization code at the token endpoint (the initial exchange uses grant_type=authorization_code), the refresh token on refresh, or the Mission-bound subject_token on Token Exchange (the actor_token identifies the delegate, Section 11). It then applies the gating of Section 9. A client does not supply mission_id to obtain a derivation; an AS MUST NOT derive Mission-bound authority from a client-supplied mission_id, because the grant, not the identifier, determines the Mission.¶

The interoperable surface for mission_id is the mission claim's id on each issued token (Section 8.1); a client reads it from there. A deployment MAY additionally surface mission_id in the token response as a deployment-local convenience for correlation and display, but this document defines no interoperable token-response parameter for it. Either way mission_id is a reference, not a credential: presenting it authorizes nothing (Section 9).¶

6.2. Single Accountable Approver

This document records exactly one approver: the accountable principal who approved the Mission. Two richer patterns are deliberately out of scope and deferred:¶

• Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers is orthogonal to the consent commitment: however many principals approve the same rendered Authority Set, the authority_hash, and every token derived from it, is identical. Multi-party approval raises the assurance of how approval was obtained; it does not change the artifacts this document produces. A deployment requiring dual control today can obtain the additional approvals out of band and record one accountable Approver under the same authority_hash; this document simply does not natively represent the co-approvers.¶

• Approval-authority provenance (the standing policy or delegation an administrator or headless approval traces back to). This is governance state about who stands behind a delegated approval, not part of binding tokens to approved authority, and is left to a governance layer.¶

6.3. Integrity Anchors

Both anchors are 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-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. 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, encoding of the digest.¶

The typ field domain-separates the two anchors so a digest of one object can never be mistaken for the other. The iss binding prevents a committed object from being transplanted across Authorization Servers.¶

The typ value space is an extension point (Section 13): additional committed objects use this same envelope with a new typ and the canonicalization below. This document defines no registry of typ values; each committing specification defines its own and relies on the typ domain separation. To keep that domain separation safe without a registry, a new typ value MUST be a collision-resistant name (for example, a short name prefixed within a namespace the defining profile controls, following the Collision-Resistant Name guidance of [RFC7519] Section 4.2). The mission- prefixed values defined across this Mission-Bound Authorization profile set share an author-coordinated namespace for this reason.¶

SHA-256 is the only digest algorithm this document defines; the sha-256: prefix identifies it. Algorithm agility is future work.¶

A verifier MUST reject an integrity anchor whose algorithm prefix it does not recognize. A verifier MUST NOT treat an unrecognized prefix as sha-256. This ensures that adding an algorithm later cannot be exploited as a downgrade.¶

6.4. 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 mission_intent for intent_hash, the authority_set for authority_hash. An auditor reproduces a digest from the record alone.¶

• The AS MUST reject an input object containing duplicate JSON member names before canonicalization; such input is invalid.¶

• JCS does not reorder array elements, and this document defines no element sorting, so array order is significant. The AS MUST emit each array in a fixed, reproducible order; that order is part of the canonical form.¶

• URI-valued members are compared byte-for-byte unless a member's definition specifies a normalization. This document defines none, so resource and every other URI MUST match exactly (this governs the resource equality test of Section 5.1).¶

7.1. mission_id Format

mission_id is an opaque URL-safe ASCII string of [A-Za-z0-9_-] characters, at least 128 bits of entropy, carrying no semantic content. It MUST NOT be reused.¶

7.2. Worked Example

{
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "origin": "https://as.example.com",
  "state": "active",
  "mission_intent": { "goal": "Reconcile Q3 invoices ...",
    "resources": ["https://erp.example.com"],
    "mission_expiry": "2026-12-31T23:59:59Z" },
  "authority_set": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "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_usd": 500 } }
  ],
  "authority_hash":
    "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
  "intent_hash":
    "sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY",
  "subject": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "approver": { "iss": "https://idp.example.com",
    "sub": "user_3p2q8mN1a0kV7tR" },
  "client_id": "s6BhdRkqt3",
  "policy_version": "deploy-policy:v17",
  "approval_event_id": "ape_8K2nP4qV9rL3tY6sB1z",
  "created_at": "2026-10-15T14:32:11Z",
  "mission_expiry": "2026-12-31T23:59:59Z"
}

8.1. The mission Claim

The mission claim is a JSON object:¶

id:

REQUIRED. A string. The Mission's mission_id.¶

origin:

REQUIRED. A string. The AS issuer URL.¶

authority_hash:

REQUIRED. A string. The Mission's authority_hash, binding the token to the consented authority.¶

The mission claim is an open object (Section 13): additional members MAY appear alongside the three above. This document defines no registry of mission members; an extension member MUST use a collision-resistant name (for example, a name in a namespace the extension controls, per the Collision-Resistant Name guidance of [RFC7519] Section 4.2) and is defined by the profile that introduces it. A consumer MUST ignore members it does not understand and MUST NOT use any additional member to grant or widen authority; the three members above remain authoritative.¶

Example decoded token payload:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840000,
  "exp": 1797840300,
  "jti": "at_9Kp2vN7sR1tY8mZ3qX5b",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "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_usd": 500 } }
  ],
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

8.2. Resource Server Enforcement

A Resource Server enforces from the token alone; no call to the AS is required. A Resource Server:¶

• MUST validate the JWT per [RFC9068] and verify any sender-constraint binding (cnf).¶

• MUST treat authorization_details as the authoritative expression of authority and enforce the entries whose resource it serves, permitting only the listed actions subject to constraints.¶

• MUST fail closed on any constraints key it does not understand, or understands but cannot enforce, in an entry whose resource it serves: it MUST refuse the request (for example, a 403 with insufficient_scope [RFC6750], or the deployment's usual insufficient-authority error) rather than grant access while ignoring the key. A constraints member narrows authority, so treating an unenforceable key as absent would silently widen the grant; an RS MUST NOT reduce a constraint to disclosure-only.¶

• MUST NOT, when a token also carries scope, grant on the basis of a scope value any access broader than the corresponding authorization_details entry permits; in particular, scope MUST NOT be used to bypass a constraint carried only in authorization_details.¶

• MUST NOT treat client_id as the identity of the acting party on a delegated token. This profile keeps client_id equal to the Mission's approved agent on every derived token (Section 11); the immediate actor is the outermost act. An RS that authorizes or logs the caller MUST process the act chain to identify the acting party, or it will attribute a delegate's action to the approved agent.¶

• This act-processing requirement binds a Mission-aware RS. Because a Mission-unaware [RFC9068] RS reads client_id as the immediate client and would misattribute, a deployment SHOULD NOT route delegated tokens to an RS that authorizes or logs on client_id without processing act.¶

• MAY, for a Mission-governed resource, be configured to require the mission claim, and MUST then reject a token that lacks it with invalid_token. This prevents downgrade by omission: where the same AS also issues ordinary tokens, a token bearing equivalent authorization_details but no mission claim is governed by no Mission state, revocation, or consent commitment, and MUST NOT be accepted where Mission governance is required.¶

• MAY treat the mission claim as audit and correlation context.¶

• MAY, if it independently holds the Authority Set, recompute authority_hash (Section 6.3) and compare it to the mission claim to detect a token whose authority does not match the approved Mission.¶

• MAY, where the AS offers it, introspect the token (Section 10) to observe the Mission's current state per request rather than relying on the token lifetime to bound revocation latency. An RS that introspects MUST still verify the token's sender-constraint (cnf) locally and MUST NOT treat an active: true result as proof the caller holds the bound key; the AS does not check possession at introspection (Section 10).¶

A Mission-unaware Resource Server that authorizes only from scope still operates within the Mission at the coarse scope level, because the AS derived and bounded that scope by the Authority Set (Section 8); but it does not enforce the per-entry constraints, which scope cannot carry. A deployment that relies on those constraints MUST route the protected operation through a Resource Server that enforces authorization_details (or the runtime layer that evaluates them).¶

9.1. Issuance Gating

The AS MUST refuse to derive a token, at the token endpoint, on refresh, and on Token Exchange ([RFC8693]), unless the referenced Mission is active. Issuance against a revoked or expired Mission MUST fail with invalid_grant. Because derivation is gated on Mission state, revoking or expiring a Mission stops all further authority for the task, including refresh.¶

When the Mission Intent sets context.max_derivations, the AS MUST maintain a per-Mission count of derivations and MUST refuse with invalid_grant any derivation that would exceed the bound. A derivation is one issuance operation the origin AS performs for a single request: the initial authorization-code exchange, a refresh, a Token Exchange, or an ID-JAG issuance (Section 12). Each counts as exactly one, regardless of how many artifacts it emits: a code exchange that returns both an access token and a refresh token is one derivation, and a refresh that rotates both is one. The exact rules:¶

• A derivation that fails, including one refused for exceeding the bound, MUST NOT be counted.¶

• The check and increment MUST be atomic with issuance, so concurrent derivations cannot collectively exceed the bound.¶

• The count covers only derivations the origin AS performs. Tokens a Resource AS mints from an ID-JAG (Section 12) are NOT counted by the origin (the origin cannot observe them); the ID-JAG issuance that authorized them was counted once, and the Resource AS bounds its own local issuance by its policy.¶

The AS maintains this count as internal bookkeeping; it is operational state, not part of the immutable Mission record.¶

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. Revocation is a management-plane action by a party in the AS's own trust domain, not a cross-party protocol exchange, and the lifecycle gate that makes it effective (Section 9, Section 10) already rides on existing endpoints, so no standardized endpoint is required for interoperability. A standardized Mission management API, and the richer suspend/complete operations, are deferred to future work.¶

A deployment MAY additionally treat [RFC7009] revocation of a Mission's refresh token as revoking the Mission. A deployment MUST NOT couple routine token revocation to Mission revocation unless it documents that behavior. Already-issued access tokens remain valid until they expire; a deployment requiring lower cutoff latency SHOULD use short token lifetimes.¶

The stateless baseline needs no status surface: a token is a self-contained authorization and verification is stateless. A deployment MAY additionally offer token introspection (Section 10) so a Resource Server can observe Mission state per request and cut off a revoked Mission without waiting out the token lifetime. A canonical Mission Status surface (keyed by mission_id) and signed status responses are specified separately as an OPTIONAL companion profile by Mission Status [I-D.draft-mcguinness-oauth-mission-status]; this document does not require them.¶

10.1. Caller Authorization and Minimization

The introspection endpoint is protected per [RFC7662]. The AS:¶

• MUST authenticate the calling party.¶

• MUST return Mission data only to a caller authorized to receive it, in particular a Resource Server that is an audience of the token.¶

• MUST audience-filter the response, returning the authorization_details entries and Mission data relevant to the caller's audience and not disclosing entries addressed to other audiences (Section 12.1).¶

Because this profile returns the mission member and mission.state even when active is false (diverging from the [RFC7662] default of omitting members for inactive tokens), the AS MUST apply this same authorization and minimization to that data and MUST NOT reveal Mission detail to an unauthorized introspection caller.¶

10.2. Composite active

The introspection active member reflects the composite authorization, not the token in isolation. The AS MUST return active: true only when the access token is itself valid (valid signature, unexpired, and not individually revoked) AND the Mission is active. The AS does not verify the token's sender-constraint (cnf) at introspection: proof of possession is checked by the Resource Server when the token is presented, not by the AS over an introspection call, so active: true is not by itself evidence the caller holds the bound key.¶

When the token is otherwise valid but the Mission is revoked or expired, the AS MUST return active: false and include mission.state giving the reason, so a Resource Server can distinguish a dead Mission from a bad token. (This extends the [RFC7662] default of omitting members when active is false.) A Mission transition does not by itself revoke the token as an individual credential; introspection reports the composite authorization as inactive.¶

10.3. Only the Origin Reports Mission State

An AS MUST NOT include mission.state in an introspection response unless it holds the Mission, that is, unless it is the Mission origin. A Resource AS introspecting a local token it minted from an ID-JAG (Section 12) knows the Mission state only as of ID-JAG validation and has no query to the origin keyed by mission_id (this document defines none); it MUST omit mission.state rather than report a stale value as current. authority_hash, when included, is the origin reporting its own commitment, not the introspecting party recomputing a subset (Section 15.1).¶

This is token introspection: it answers "is this token's authorization still good," keyed by the token presented. The canonical Mission Status surface (keyed by mission_id) remains out of scope (Section 9.2).¶

10.4. Example

A Mission-bound token whose Mission has been revoked, introspected at the origin AS:¶

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

While the Mission is active, the response is the standard [RFC7662] body (active: true, sub, client_id, aud, exp, authorization_details, ...) plus the mission member carrying state: active.¶

11.1. Delegation Constraints

What may be delegated, how far, and to whom is governed per Authority Set entry by the entry's optional delegation member (Section 5). Because the policy lives in the entry, it is committed by authority_hash with the rest of the Authority Set and travels with the audience-scoped entries across the cross-domain hop (Section 12), needing no separate mechanism.¶

Delegation depth. The delegation depth of a token is the number of actors in its act chain (the nesting depth of the act claim), counted from the approved agent: the agent's own non-delegated token is depth 0, the first delegate is depth 1, and each further delegate adds 1. The depth checked against max_depth is that of the token being issued, computed after appending the new outermost actor, not the depth of the delegating token. A cross-domain grant carries no act chain (Section 12.2) and so enters the target domain at depth 0; a Resource AS that then issues delegated tokens of its own counts from there (Section 12.3).¶

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

1. the entry carries a delegation member (otherwise it is non-delegable, which is the default);¶

2. d is less than or equal to the entry's delegation.max_depth; and¶

3. the delegate is permitted by delegation.allowed_delegates, or that member is absent.¶

An entry failing any of these narrows out of the delegated token, consistent with the subset rule (Section 5.1). The delegation member is policy, not authority, and is not part of the subset comparison; surviving entries are carried with their delegation member intact so the next hop is evaluated the same way.¶

Matching allowed_delegates. Each entry is a matcher object modeled on the RFC 8693 may_act actor object ([RFC8693] Section 4.4): where may_act names a single party eligible to act on a token, allowed_delegates is a per-Authority-Set-entry list of such matchers, generalized to actor-type classes. A { "sub": ... } matcher permits a specific delegate by client identifier; a { "sub_profile": ... } matcher permits any actor of that type (for example, ai_agent). A deployment can thus permit a specific client, a class of actors, or both, and a delegate is permitted if it matches any entry. The AS MUST authenticate the delegate at the Token Exchange and assert the actor's sub and sub_profile itself. A self-asserted sub_profile MUST NOT satisfy a matcher; otherwise a client could claim any actor type to bypass the constraint.¶

A { "sub": ... } matcher is a client identifier in the issuing AS's namespace and is not portable across a trust domain. When a Resource AS evaluates a conveyed entry (Section 12), it MUST fail closed, narrowing the entry out, for any sub matcher it cannot resolve against the delegate it authenticated in its own namespace. Portable cross-domain matching SHOULD therefore use a sub_profile matcher, an actor-type class rather than a domain-relative identifier.¶

Empty result. If narrowing leaves no entries for the delegate, the AS MUST refuse with invalid_grant rather than issue a token with empty authority.¶

The Resource Server enforces none of this. Delegation constraints are applied by the AS at issuance; a Resource Server sees only the already-narrowed authorization_details and enforces those as usual (Section 8).¶

11.2. Worked Example: Delegated Token

Suppose the Mission's Authority Set has two entries on the ERP: invoices.read, delegable to ai_agent actors through depth 2; and journal-entries.write, which carries no delegation member and is therefore non-delegable. The approved agent s6BhdRkqt3 delegates to sub-agent tool-runner-7, an ai_agent, at depth 1. The read entry is permitted (depth 1 <= 2, ai_agent allowed) and the write entry narrows out. The decoded delegated access token:¶

{
  "iss": "https://as.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "aud": "https://erp.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840600,
  "exp": 1797840900,
  "jti": "at_3qX5bN7sR1tY8mZ9Kp2v",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read"],
      "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-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

sub is still the user and client_id is still the approved agent; tool-runner-7 appears only as the actor. 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.¶

12.1. Audience-Scoped Authority

When projecting authority toward a Resource AS, the Mission Issuer includes only the Authority Set entries whose resource that Resource AS is authoritative for, under the deployment's resource-to-AS mapping. Entries for other Resource ASes MUST NOT be disclosed.¶

12.2. Issuing the Cross-Domain Grant

Issuing a cross-domain grant is a derivation event and is gated like any other (Section 9). A Mission-bound cross-domain grant:¶

• MUST be a JWT authorization grant issued and signed by the Mission origin, redeemable at the target Resource AS through the [RFC7523] JWT-bearer grant;¶

• MUST be audienced to the target Resource AS, and MUST NOT have a lifetime exceeding 300 seconds (a short lifetime bounds cross-domain revocation latency; see Section 15.6);¶

• MUST be sender-constrained ([RFC7800]) to the presenting client by the proof-of-possession mechanism the cross-domain grant profile defines (for the ID-JAG profile, as that specification defines). This document does not define a new PoP mechanism; the originating AS and the Resource AS MUST use the mechanism of the profile in use, so that binding and verification interoperate;¶

• MUST carry a jti for one-time use, so the bound party cannot replay it within its lifetime (Section 12.3, [RFC7523] Section 3);¶

• MUST carry the mission claim (Section 8.1) with id, origin, and authority_hash unchanged from the Mission, and the audience-scoped authorization_details (Section 12.1); and¶

• MUST convey the Mission's Subject in the form the identity chaining architecture defines, so the Resource AS can resolve it locally (Section 12.3).¶

The ID-JAG profile meets these requirements and is RECOMMENDED; in it the artifact is the ID-JAG and the issuance request carries a requested_token_type of urn:ietf:params:oauth:token-type:id-jag.¶

The client obtains the grant with an [RFC8693] token exchange. The subject_token MUST be the Mission's refresh token, with subject_token_type of urn:ietf:params:oauth:token-type:refresh_token, and the audience identifies the target Resource AS. This refresh-token mode is what binds the request to a Mission: the AS resolves the Mission from the presented grant per Section 6.1, exactly as on any other refresh, and the grant therefore projects the agent's full Mission authority (audience-scoped), never a narrowed delegate's.¶

This profile intentionally fixes the refresh-token subject mode to remove any ambiguity about which Mission authority a cross-domain grant projects: the refresh token resolves to exactly one Mission and its full authority, whereas an access token or delegated token could carry a narrowed or actor-specific subset. The cost is that this optional cross-domain binding is unavailable to a deployment that issues no refresh token; such a deployment uses the single-domain core, which needs no refresh token.¶

The AS MUST reject an access token or a delegated token presented as subject_token for cross-domain issuance. The AS MUST NOT resolve the Mission from a client-supplied mission_id, nor from an identity assertion that carries no Mission binding.¶

Before issuing, the AS MUST verify the Mission is active (failing otherwise with invalid_grant) and that the target Resource AS is authorized for the requested resources under the Mission's Authority Set (failing otherwise with invalid_target, [RFC8693]). The token-exchange response carries issued_token_type of urn:ietf:params:oauth:token-type:id-jag (for the RECOMMENDED profile) and token_type of N_A, per [RFC8693] Section 2.2.1.¶

This profile defines only the refresh-token subject_token mode above. Other Mission-bound subject-token modes, such as an access-token subject mode (which would have to bound the projected authority by the presenting token rather than by the full Mission Authority Set), are left to future profiles. Excluding the access-token subject mode here is a deliberate choice for this minimum-viable profile: it avoids propagating a narrowed or delegated authority across a trust boundary, where it could be re-widened. A deployment that does not issue the agent a Mission refresh token therefore cannot use this OPTIONAL cross-domain hop as defined here.¶

A delegate, rather than the agent, crossing a trust domain directly and carrying its own narrowed authority into another domain is out of scope for this document and deferred to future work. Cross-domain issuance here always projects the agent's Mission authority; delegation within the target domain is performed by the Resource AS (Section 12.3).¶

Two roles must not be conflated. The grant the client presents to obtain the cross-domain grant (the Mission's refresh token) is the input to the exchange and selects the Mission; the Mission-bound access token plays no part here. The identity the issued grant conveys to the Resource AS is the Mission's Subject, which the AS populates from the Mission's recorded subject and which the Resource AS resolves locally per the identity chaining rules (this document defines no cross-domain subject mapping, Section 12.3).¶

Sender-constraining is REQUIRED for the cross-domain grant, stronger than the RECOMMENDED level for the primary access token (Section 8): it is the highest-authority credential in the chain and the only one that crosses a trust boundary, and the underlying grant provides no replay backstop of its own.¶

12.3. Validation at the Resource AS

A Resource AS consuming a Mission-bound cross-domain grant:¶

• MUST establish issuer trust in the originating AS by local policy or issuer metadata before accepting any Mission reference. It MUST NOT trust a mission.origin merely because it appears inside a signed assertion.¶

• MUST validate the grant's signature and expiry, and verify its aud is the Resource AS's own identifier, rejecting a grant minted for a different Resource AS.¶

• MUST verify the grant's sender-constraint by the proof-of-possession mechanism the cross-domain grant profile defines (for the ID-JAG profile, as that specification defines), and MUST reject with invalid_grant a cross-domain grant that is not sender-constrained or whose proof-of-possession does not verify. A bearer grant MUST NOT be accepted: it is the highest-authority credential crossing the trust boundary, so accepting one unbound would let any party that captured it mint a local token.¶

  • Because this document defines no cross-domain status query, freshness is the Resource AS's only check that the Mission was active at issuance; the short grant lifetime bounds the staleness.¶

• MUST reject a replayed cross-domain grant: it MUST track the grant's jti for the grant's validity window and refuse a second presentation with invalid_grant ([RFC7523] Section 3), so a grant cannot be replayed even by the party it is bound to.¶

• When issuing local access tokens for its resources, the Resource AS uses the subject-resolution rules of the underlying cross-domain grant and identity chaining specifications. The local token preserves the mission claim (id, origin, and authority_hash) unchanged from the cross-domain grant. The issuing iss is the Resource AS; mission.origin remains the originating AS. Such a local token:¶

  • has an exp that MUST NOT exceed the grant's exp (Section 8), which bounds it transitively by mission_expiry;¶

  • MUST be sender-constrained ([RFC7800]), like the grant it derives from, and MUST NOT be issued as a bearer token; and¶

  • if it preserves the origin client_id, does so only as an audit reference, not a local identity: that value is in the originating AS's namespace, and a partner Resource Server MUST NOT resolve or authorize on it as a local client, for the same portability reason that applies to a sub matcher in allowed_delegates (Section 11.1).¶

• MUST bound the issued authorization_details by what the cross-domain grant conveyed, and MUST apply its own local authorization policy in addition: honoring a Mission does not obligate it to authorize any particular request. Because the conveyed entries were derived under the originating AS's local policy, the Resource AS does not re-derive them; it interprets and enforces them by their structure and vocabulary. It MUST fail closed on a conveyed actions identifier or constraints key it does not recognize for the resource in question, exactly as a Resource Server does (Section 8.2), so authority it cannot interpret is never honored across the trust boundary rather than enforced by guess.¶

• MUST, when it issues delegated tokens of its own, enforce each entry's delegation policy as in Section 11.1; the policy travels on the conveyed entries. The cross-domain grant carries no act chain (Section 12.2), so the Resource AS's own delegation depth begins at 0.¶

This document does not define cross-domain subject mapping. A Resource AS consuming a Mission-bound cross-domain grant resolves the subject of any local token according to the cross-domain grant profile in use (the Identity Assertion Authorization Grant profile in the recommended case), the OAuth identity chaining architecture, and its local trust and account-linking policy. This document only requires that the Mission binding (mission.id, mission.origin, and authority_hash) and the audience-scoped authorization_details remain bounded as described here.¶

Downstream, authority_hash is an immutable audit and correlation anchor to the originating AS's consent commitment. A Resource AS and its Resource Servers hold only the audience-scoped subset, never the full Authority Set, so they cannot recompute authority_hash (Section 6.3); its integrity rests on the signature chain (the originating AS signs the ID-JAG; the Resource AS validates issuer trust and signs its local token). It is verifiable only against the originating AS, which this document does not require to be exposed.¶

15.1. Consent Binding

The security goal of this document is that a user's approval of a task bounds every token derived for it. The authority_hash is the mechanism: it commits the exact Authority Set the Approver consented to, and every derived token carries it in the mission claim. An AS MUST compute authority_hash over the same Authority Set it rendered for consent, and MUST re-render and re-consent if that set changes (Section 6). authority_hash commits the full Authority Set, while a derived token may carry a narrowed subset, so a Resource Server cannot in general recompute it from the token alone. A Resource Server that independently holds the full Authority Set MUST reject a token whose set does not match authority_hash; otherwise authority_hash serves as a whole-Mission audit and correlation anchor (Section 12) and the Resource Server enforces the token's authorization_details directly (Section 8).¶

intent_hash extends the same protection to the task itself: it commits the approved Mission Intent, so an auditor can detect any later alteration of the recorded task, independently of the authority derived from it. The two anchors are domain-separated (Section 6.3); neither is a substitute for the other.¶

The task and the authority are committed separately, rather than folded into one hash over the whole Mission, because they are distinct objects with distinct uses. authority_hash commits what a Resource Server enforces and what a cross-domain projection carries, so it MUST be verifiable from a token that conveys only the authority, without the Intent. intent_hash commits the task as audit material, tamper-evident even where the authority is projected without the Intent travelling with it. One combined hash could not serve both a token that carries authority alone and an auditor that holds the task alone.¶

Neither anchor proves the Approver understood the rendered task, nor that the AS rendered it faithfully; they commit what the AS recorded, and make post-hoc tampering of those records detectable.¶

This profile commits the task (intent_hash) and the authority (authority_hash) the Approver consented to, but deliberately does not commit the rendered consent disclosure itself: the locale, disclosure-template version, and material notices the Approver was shown are not bound by any anchor here. Because of this gap, a buggy or malicious rendering layer could mislead the Approver, showing a narrower or different task than the Authority Set actually committed, without leaving any committed trace. A deployment whose Missions carry high-risk authority SHOULD therefore record presentation-level audit evidence: for example, a hash over the exact consent disclosure rendered to the Approver, retained so the disclosure shown can be reconstructed and audited after the fact. Binding this on the wire (a consent_rendering_hash over a structured consent-disclosure object) is specified as an OPTIONAL companion profile by Mission Consent Evidence [I-D.draft-mcguinness-oauth-mission-consent-evidence]; an AS that does not implement it MAY record equivalent evidence out of band. As that profile makes explicit, such a commitment binds the structured disclosure the AS records, not the pixels actually presented; it narrows this gap for audit but does not close it.¶

15.2. Mission Drift

Because issuance is gated on Mission state and bounded by the Authority Set, an agent cannot escalate beyond the approved task by acquiring additional tokens: every derived token is a subset of the approved authority (Section 5.1), and no token can be derived once the Mission is revoked or expired. Deployments SHOULD keep derived token lifetimes short so state transitions take effect promptly.¶

15.3. Issuance Scope, Not Runtime Enforcement

This profile governs the issuance and derivation of authority: it bounds what authority a Mission yields, binds it to the Approver's consent, and gates derivation on Mission state. It does not evaluate individual runtime actions. In particular, it does not:¶

• evaluate a request's parameters against the Mission at the point of use;¶

• produce runtime enforcement evidence for each consequential action;¶

• bind tool or function identities to the Mission; or¶

• re-evaluate at execution time to close the approval-to-execution (time-of-check to time-of-use) gap.¶

Mission governance is necessary but not sufficient. An active Mission still bounds a set of authority an agent may exercise freely within a token's lifetime, so an active Mission can become ambient authority for individual consequential actions. Preventing that requires a runtime enforcement layer that evaluates each consequential action against the Mission and records evidence; such a layer composes with this profile and is out of scope here. Short token lifetimes and narrow authority bound, but do not eliminate, this exposure.¶

15.4. Token Theft

Derived tokens are sender-constrained (DPoP [RFC9449] or mTLS [RFC8705]) at the levels set in Section 8, Section 12.2, and Section 12.3: SHOULD for the primary access token, MUST for delegated tokens, cross-domain grants, and Resource AS local tokens. A stolen token is bounded by the Authority Set and the Mission lifetime regardless, but sender-constraint prevents replay by a different party.¶

15.5. Delegation and Chain Compromise

Delegation (Section 11) widens the set of parties holding Mission-derived authority. Because authority only narrows down the chain, a compromised actor can act only within the authority it was delegated, for the lifetime of the token it holds: the exposure of any actor is bounded by its narrowed authorization_details times its token lifetime. The per-entry delegation constraints (Section 11.1) bound this exposure at approval time: non-delegable entries never reach a delegate at all, max_depth caps how far an entry can propagate, and allowed_delegates restricts who may receive it. Note that max_depth bounds the length of a delegation chain, not its breadth: fan-out to many distinct depth-1 delegates is bounded only by allowed_delegates, so a deployment that needs to limit breadth MUST constrain allowed_delegates (and MAY use max_derivations to cap total derivations). Because each delegated token is bound to the delegate's own key (Section 11), a compromised delegate is confined to its own narrowed credential: it cannot replay as the agent or another actor, and its credential can be revoked by key without revoking the rest of the chain. Deployments SHOULD keep delegated token lifetimes short and SHOULD make only the entries that need delegation delegable.¶

15.6. Cross-Domain Revocation Latency

Single-domain revocation is prompt: the AS that issued a token also honors its revocation (Section 9.2). The cross-domain case (Section 12) is strictly weaker. When a Mission is revoked at the originating AS, that AS can stop issuing new ID-JAGs, but it cannot revoke a token a Resource AS has already minted in another domain: that token remains valid until its own expiry. Cross-domain revocation latency is therefore the downstream token lifetime. For this reason, Resource ASes MUST issue short-lived local tokens for Mission-bound interactions; the originating AS bounds ID-JAG lifetimes by the 300-second cap of Section 12, so a revoked Mission cannot continue to seed new downstream tokens for long. The introspection of Section 10 closes the revocation gap only single-domain: it requires the introspecting AS to hold the Mission, and a Resource AS has no query to the origin keyed by mission_id, so short downstream lifetimes remain the only cross-domain control. Deployments needing tighter cross-domain revocation can add the status or event-distribution mechanisms specified separately by Mission Status [I-D.draft-mcguinness-oauth-mission-status] and Mission Lifecycle Signals [I-D.draft-mcguinness-oauth-mission-signals], which this document does not require.¶

15.7. Signing and Key Rotation

The mission claim and authorization_details are carried inside the [RFC9068] JWT and are covered by the AS's token signature; their integrity reduces to the AS's signing key. An AS MUST publish its verification keys (for example, via [RFC8414] jwks_uri) and SHOULD retain the verification key for each key identifier it has signed under long enough to verify tokens issued before a rotation.¶

15.8. Compromised or Over-Broad Derivation

The AS is trusted to derive authority no broader than the Mission Intent. Deployments SHOULD constrain derivation with explicit resource and action mappings rather than free-form inference, and SHOULD record policy_version so a derivation can be audited and reproduced. General OAuth security guidance [RFC9700] applies.¶

15.9. Authority Hash Is Not a Mission Identifier

authority_hash commits the approved Authority Set, not the Mission. Two distinct Missions that approve byte-identical authority carry the same authority_hash: a successor Mission that re-approves the same Authority Set, or an unrelated Mission with the same derived authority, differs in its intent_hash, approver, and mission_id while sharing the authority_hash. It is therefore not globally unique to a Mission and MUST NOT be used as a Mission identifier or as a replay or idempotency key for a Mission. The canonical mission_id identifies the Mission; authority_hash identifies the authority the Mission approved. A consumer that needs to bind to or correlate a specific Mission uses mission_id, and intent_hash and approver distinguish Missions that share an Authority Set.¶

16.1. Mission Identifier Correlation

This document carries a single canonical mission_id on every derived token and ID-JAG. 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 mission_id, and mission.origin further identifies the issuing AS. This profile does not provide cross-audience unlinkability. Audience-pairwise (or request-pairwise) Mission references, in which the origin projects a distinct opaque identifier per audience and resolves them server-side, are the fuller mechanism for that and are deferred to future work. A deployment that carries the canonical mission_id on the wire SHOULD document this correlation property.¶

17.1. OAuth Parameters Registration

This document registers the following in the "OAuth Parameters" registry:¶

• Name: mission_intent¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4¶

PAR [RFC9126] carries authorization-request parameters without a distinct usage location, so the pushed submission of mission_intent needs no separate registration.¶

17.2. Authorization Details Type mission_resource_access

mission_resource_access is an authorization_details type per [RFC9396] Section 2, defined by this document in Section 5. RFC 9396 does not establish an IANA registry of authorization details types (type identifiers are interpreted by the Authorization Server), so this document creates no registry entry for it and requires no IANA action here. If a registry of authorization details types is established in the future, this type SHOULD be registered in it.¶

17.3. JSON Web Token Claims Registration

This document registers the following in the "JSON Web Token Claims" registry:¶

• Claim Name: mission¶

• Claim Description: Reference to the Mission a token was derived under, with the consent-commitment authority_hash. An open object; additional members may be present and are ignored if unknown.¶

• Change Controller: IETF¶

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

17.4. OAuth Token Introspection Response Registration

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

• Name: mission¶

• Description: The Mission a token was derived under. Same object shape as the mission JWT claim (Section 8.1); a response from the Mission origin additionally carries a state member giving the current lifecycle state (Section 10).¶

• Change Controller: IETF¶

• Reference: this document, Section 10¶

17.5. OAuth Authorization Server Metadata Registration

This document registers the following in the "OAuth Authorization Server Metadata" registry ([RFC8414]):¶

• Metadata Name: mission_bound_authorization_supported¶

• Metadata Description: Boolean indicating that the Authorization Server supports the Mission Issuer core surfaces of this document.¶

• Change Controller: IETF¶

• Reference: this document, Section 14¶

17.6. Mission Common Constraints Registry

IANA is requested to create the "Mission Common Constraints" registry. The registration policy is Specification Required [RFC8126]. Each entry has:¶

• Name: the constraints member name, matching ^[A-Za-z0-9_.:-]+$.¶

• Value syntax: the JSON [RFC8259] value type and any rules.¶

• Subset rule: the narrowing semantics (Section 5.2).¶

• Intersection rule: how two values combine.¶

• Change Controller.¶

• Reference.¶

The registry is seeded with the constraints defined in Section 5.2; for each, Change Controller IETF and Reference this document:¶

• max_amount_usd¶

• issued_after¶

• issued_before¶

18.1. Normative References

[I-D.draft-ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04>.

[I-D.draft-ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-15, 19 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-15>.

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

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

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

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

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

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

[RFC9126]

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

[RFC9396]

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

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

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

18.2. Informative References

[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-transaction-tokens]

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

[I-D.draft-klrc-aiagent-auth]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth-02, 1 June 2026, <https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-auth-02>.

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

McGuinness, K., "Mission Consent Evidence for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-consent-evidence, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-consent-evidence>.

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

McGuinness, K., "Mission Expansion for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-expansion, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-expansion>.

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

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-signals, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-signals>.

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

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth-mission-status, 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-status>.

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

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

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

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

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

The agent is an OAuth client with a workload identity (for example a WIMSE or SPIFFE identity), and alice has delegated to it through an ordinary authorization-code flow, per [I-D.draft-klrc-aiagent-auth]: client_id is the agent and the token sub is alice. This document adds the Mission layer on top of that identity; Stage 0 is otherwise unchanged from that specification.¶

A.2. Stage 1: Mission Creation at the Home AS

The agent submits this Mission Intent through PAR (Section 4):¶

{
  "goal": "Reconcile Q3 invoices in the partner ERP.",
  "resources": ["https://erp.partner.example.com"],
  "constraints": [
    "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",
  "mission_expiry": "2026-12-31T23:59:59Z",
  "context": {
    "acr": "urn:example:acr:mfa",
    "max_derivations": 200,
    "max_budget": { "amount": "5000.00", "currency": "USD" },
    "max_calls": [
      { "call_class": "journal-entries.write", "count": 50 }
    ],
    "max_duration": "PT8H"
  }
}

The home AS (as.example.com) validates it, derives this Authority Set, and renders it for alice's consent:¶

[
  { "type": "mission_resource_access",
    "resource": "https://erp.partner.example.com",
    "actions": ["invoices.read"],
    "delegation": {
      "max_depth": 1,
      "allowed_delegates": [{ "sub_profile": "ai_agent" }]
    } },
  { "type": "mission_resource_access",
    "resource": "https://erp.partner.example.com",
    "actions": ["journal-entries.write"],
    "constraints": { "max_amount_usd": 500 } }
]

After approval, the home AS records Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- in the active state with authority_hash sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ and intent_hash sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY. The ERP is in the partner trust domain, so the agent's next step is a cross-domain projection rather than a home-domain access token.¶

A.3. Stage 2: Cross-Domain Projection via ID-JAG (Between Domains)

The agent needs the partner ERP, behind the Resource AS ras.partner.example.com. It presents its Mission refresh token as the subject_token of a token exchange requesting an ID-JAG (Section 12); the home AS resolves the Mission from that grant, gates on Mission active, and mints a Mission-bound ID-JAG audienced to that Resource AS, carrying the mission claim and the audience-scoped authority for the ERP:¶

{
  "iss": "https://as.example.com",
  "aud": "https://ras.partner.example.com",
  "sub": "user_3p2q8mN1a0kV7tR",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840000,
  "exp": 1797840300,
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount_usd": 500 } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

The ID-JAG is short-lived (300 s) and sender-constrained to the agent. Its exp does not exceed mission_expiry (Section 8).¶

A.4. Stage 3: The Resource AS Issues a Local Access Token

ras.partner.example.com validates the ID-JAG (Section 12): it establishes issuer trust in as.example.com, verifies the signature, checks that aud is itself, checks the expiry, and verifies the sender-constraint proof. It then issues its own access token for the ERP, preserving the mission claim unchanged and capping exp at the ID-JAG's exp:¶

{
  "iss": "https://ras.partner.example.com",
  "aud": "https://erp.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "client_id": "s6BhdRkqt3",
  "iat": 1797840030,
  "exp": 1797840290,
  "jti": "at_7Kp4QnZ2vR9sT1mX8b3N",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["invoices.read"],
      "delegation": {
        "max_depth": 1,
        "allowed_delegates": [{ "sub_profile": "ai_agent" }]
      } },
    { "type": "mission_resource_access",
      "resource": "https://erp.partner.example.com",
      "actions": ["journal-entries.write"],
      "constraints": { "max_amount_usd": 500 } }
  ],
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

The issuing iss is now the Resource AS, but mission.origin remains the home AS. The token's exp (1797840290) is below the ID-JAG's (1797840300) and far below mission_expiry. The Resource AS-local sub is illustrative; its value is determined by the subject-resolution rules of the ID-JAG and identity chaining profiles, not by this document.¶

A.5. Stage 4: The Resource Server Enforces

The agent calls the ERP Resource Server (erp.partner.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 and journal-entries.write up to max_amount_usd: 500 (Section 8). It treats the mission claim as an audit anchor; holding only this audience's subset of the Authority Set, it does not recompute authority_hash.¶

A.6. Stage 5: Internal Call Context via Transaction Tokens

To serve the request, the ERP Resource Server calls internal services inside the partner trust domain. Here it calls a ledger service for one invoice. The Resource Server is the entry edge of that domain: after it has validated the Mission-bound access token, it obtains a short-lived Transaction Token for the internal call.¶

The following shows one illustrative way the Mission context could ride in that Transaction Token. This is not a Mission-derived OAuth access token, and this document does not define the Transaction Token claim names or issuance rules. The important point is that the local context can keep the Mission anchor while narrowing the internal operation:¶

{
  "iss": "https://txn.partner.example.com",
  "aud": "https://ledger.partner.example.com",
  "sub": "partner-user_7Kp4QnZ2vR9s",
  "tid": "txn_5kQ9pX2vN7sR1tY8mZ3",
  "iat": 1797840060,
  "exp": 1797840120,
  "txn_authorization": {
    "source_resource": "https://erp.partner.example.com",
    "source_actions": ["invoices.read"],
    "internal_operation": "ledger.lookup_invoice",
    "constraints": { "invoice_id": "inv_2026Q3_1042" }
  },
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  }
}

The Transaction Token is intra-domain and the shortest-lived credential in the chain (60 s). The holder has changed: the Resource Server's workload, not the agent, possesses it. The local context has narrowed again, to one ledger lookup for one invoice, while the mission anchor is unchanged.¶

A.7. Stage 6: The Internal Service Enforces

The ledger service receives the Transaction Token, validates it under partner-domain policy, reads the Mission context and local transaction authorization, and enforces them for the internal operation. Like every consumer downstream of the home AS, it treats authority_hash as an audit and correlation anchor it cannot recompute, and it makes no call to mission.origin.¶

A.8. What Rode Through, and What Narrowed

The Mission anchor (id, origin, authority_hash) is constant end to end. OAuth authority is preserved or narrowed at the cross-domain boundary, and local transaction context narrows the internal operation inside the partner domain. The lifetime shrinks at every hop and never exceeds mission_expiry. The ID-JAG carried identity between trust domains; the Transaction Token carried context within one. The Mission bound both.¶