]> Independent

public@karlmcguinness.com

Web Authorization Protocol oauth mission agent authorization rar par An AI agent is typically given a mission: a task to pursue on a user's behalf. OAuth 2.0 issues access tokens for individual resource requests, but it has no durable, approved artifact that ties those tokens to the one task a user actually authorized. As a result, an agent's authority is a collection of independently obtained tokens with no shared, auditable boundary, and a user's approval is disconnected from what the agent later does. This document defines a Mission: a structured, human-approved, integrity-bound authorization artifact for OAuth 2.0. A client submits a Mission Intent through Pushed Authorization Requests; the Authorization Server derives Rich Authorization Requests authorization details from it, binds the approved task and its derived authority to the Approver's consent through two integrity anchors, and records a durable Mission. Every access token derived under the Mission carries that authority and a "mission" claim, and issuance is gated on the Mission's lifecycle state. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. This is the issuance and governance "mission layer" left unspecified by agent-identity work for OAuth; runtime enforcement of each action is a separate, optional layer. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Agent-identity work such as establishes how an AI agent authenticates and how a user delegates authority to it: the agent is an OAuth 2.0 client identified by client_id, the delegating user is the access token sub, and the agent obtains tokens for the resources its task requires. That work deliberately leaves three things out of scope: how an agent's task (its "mission") is translated into authorization, how a user's approval of that task is captured as a durable artifact, and how later token issuance stays bound to what the user approved. Without that layer the gap is invisible to every individual OAuth component. Each token is individually valid and each request individually in scope, yet nothing checks whether the task the user approved is still the one being pursued. A token issued for a task remains usable after the user's approval has lapsed or been withdrawn, because no OAuth object ties the token's validity to the task's authorization: the credential stays secure while the work it authorizes has quietly become unauthorized. This document specifies that missing layer. It defines a Mission: a structured, human-approved, integrity-bound OAuth authorization artifact. The contribution is a single chain:

1. The client submits a structured Mission Intent describing the task (goal, target resources, constraints) instead of requesting raw scopes.
2. The Authorization Server (AS) derives authorization details (), the Authority Set: the concrete authority the task needs.
3. At an approval event, the Approver consents to that authority, and the AS commits the task as an intent_hash and the authority as an authority_hash and records a durable Mission.
4. Every access token the agent obtains under the Mission carries the derived authorization details and a mission claim bearing the authority_hash. A Resource Server enforces statelessly from the token.
5. Token issuance and refresh are gated on Mission state, so revoking or expiring the Mission stops the agent from obtaining further authority.

The result is that a user approves a task once, and that approval, not a per-request scope grant, bounds and outlives every token the agent derives. Each token carries an authority_hash audit anchor back to the consented authority; a holder of the full Authority Set can verify it, and a holder of only a narrowed subset (a downstream or cross-domain party) treats it as an audit anchor it cannot recompute (). This chain is the first of two deliberate security tiers. It gives task-bound issuance, auditability, and a revocation gate over future derivation, which is sufficient for a low-risk workflow whose exposure is bounded by short token lifetimes and narrow authority. It does not evaluate individual actions: an agent taking consequential autonomous actions needs the second tier, the runtime enforcement layer (), specified separately. A deployment chooses its tier deliberately, matching the enforcement it runs to the consequence of what its agents do.

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

Relationship to Other Authorization Objects A grant, in the sense of FAPI Grant Management , is a durable, queryable, revocable container of consented authorization data. It records consent to authority but carries no task, no integrity commitment, and no derivation gating; a deployment MAY surface Mission revocation through a grant-management-style API. names the agent's mission and leaves its translation into authorization out of scope; this document specifies that translation. Decision-layer access-request and approval workflows, such as the OpenID AuthZEN Access Request and Approval Profile , manage approval tasks but define no issuance binding; this document supplies the issuance-bound object such workflows complete into. Nearby individual proposals each carry one Mission property without the others: task-linked Rich Authorization Requests with revocation webhooks carry a task link, intent-digest admission assertions carry an intent commitment, and offline capability attenuation () carries offline narrowing. None combines the durable approved object, state-gated issuance, and integrity anchors this document defines.

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 (), derived from the Mission and only ever narrowed from it (), 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 (); it does not undo actions already completed. Evaluating each action against the Mission at the point of use is the runtime layer's concern (), not this document's. The invariant across all three: the plan and the execution draw on the Mission's authority; neither enlarges it.

Relationship to Agent-Identity Specifications This document is complementary to 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.

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.

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. One normative dependency is on an in-progress individual draft, so this document cannot advance ahead of it: the OAuth Actor Profile () for the act chain. That dependency is confined to the OPTIONAL Delegation capability, 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 , which carries the identity-chaining and ID-JAG dependencies with it. 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, ) is defined by Mission Consent Evidence ; mission expansion is defined by Mission Expansion ; and a cross-domain status or event-distribution mechanism for tighter revocation is defined by Mission Status and Mission Lifecycle 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 companion's end-to-end example; and, for a community that wants cross-vendor agreement on what a task authorizes within a vertical, an OPTIONAL derivation profile: a registry of standard task types mapped to authority templates, so that two vendors in that profile derive comparable Authority Sets. This document deliberately does not standardize the derivation algorithm itself (); a vertical profile is the appropriate vehicle where portable derivation is genuinely needed.

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 (). 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 ; a widening that no consent authorizes remains out of scope.
• Lifecycle event distribution. A Resource Server learns Mission state from the token lifetime or optional introspection (); this profile defines no push-based notification of Mission state changes. A Shared Signals () / CAEP profile for Mission lifecycle events is specified separately by the Mission Lifecycle Signals profile (), not here.
• Human-in-the-loop suspension. The base lifecycle here is active, revoked, expired (). A suspended state with resume/complete transitions is defined as an OPTIONAL extension by the Mission Status and Lifecycle profile (); a pending-human-approval state and a holding-token pause-and-resume protocol remain future lifecycle work.
• Multi-hop cross-domain provenance. A single cross-domain hop is specified by the companion (); 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 (, and workload identity efforts such as WIMSE); this profile governs the approved-task artifact those identities act within, not the identities themselves.
• Cross-audience unlinkability. A single canonical Mission Identifier and the authority_hash it shares deliberately let any party correlate a Mission's activity across audiences and resources. This is a design choice, not an omission: a stable, correlatable anchor is what lets a Resource Server, a cross-domain Resource AS, and an auditor bind evidence to one approved Mission, which is a core goal of this document and its companion profiles. Pairwise or unlinkable presentation of Mission-bound authority works against that anchor and is therefore future work, not a v1 property ().

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

Mission Issuer (Authorization Server):

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

Resource AS:

An Authorization Server in another trust domain that honors a Mission it did not issue, minting its own tokens for its resources; it is never the Mission Issuer. Cross-domain projection is specified by the companion Mission Cross-Domain Projection profile ().

Mission Intent:

The structured description of the task the client submits ().

Authority Set:

The set of authorization_details entries the AS derives from a Mission Intent and the Approver approves (). "Authority Set" names these concrete entries; it does not mean an identity authority, a trust authority, a legal authority, or an issuing authority.

Mission:

The durable, immutable record created at the approval event (), identified by a Mission Identifier ().

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

Mission-bound token:

An access token or refresh token issued under a Mission, carrying its authority and the mission claim (or bound server-side, for refresh tokens).

Conformance An implementation conforms in one of three roles. A Mission Issuer (the Authorization Server) implements the core issuance surfaces:

• submission of a Mission Intent via PAR ();
• derivation of mission_resource_access authorization details ();
• the approval event with its integrity anchors ();
• issuance of Mission-bound access tokens carrying the mission claim ();
• the subset rule (); and
• gating of issuance on Mission state ().

A Mission-aware Resource Server implements Resource Server enforcement (). A Mission Client implements the client surfaces:

• submission of the Mission Intent via PAR only (), never sending authorization_details alongside mission_intent;
• reading its granted authority from the token-response authorization_details echo (); and
• obtaining mission_id from the mission_id token-response parameter or the mission claim's id (), treating it as a reference, never a credential.

Beyond these mandatory roles, an implementation MAY additionally claim three OPTIONAL capabilities. Each is independent, and an implementation that supports none of them is still conformant:

• Delegation (): issuing and consuming derived tokens that carry the act delegation chain.
• Introspection (): reporting Mission state through the mission token introspection response member.
• Cross-Domain: projecting a Mission so it is honored by an Authorization Server in another trust domain. Cross-domain projection is specified by the companion ; an implementation claiming this capability conforms to that document.

A conforming implementation names the optional capabilities it supports (for example, "Mission Issuer with Delegation and Cross-Domain"); each capability's defining section or document states its detailed requirements. A token carrying a mission claim is not, by itself, Mission-bound authorization. Conformance as a Mission Issuer requires the gates: authority derived from the approved Intent and committed by the anchors (), issuance bounded by the subset rule (), and derivation gated on Mission state (). An implementation that carries Mission metadata without these gates conforms to no role in this document and MUST NOT be described as implementing it. The mission_bound_authorization_supported metadata () advertises Mission Issuer support only. It makes no assertion about any Resource Server, which does not advertise through Authorization Server metadata. The OPTIONAL capabilities are discovered first through existing OAuth metadata (): introspection_endpoint for introspection, and grant_types_supported containing urn:ietf:params:oauth:grant-type:token-exchange for delegation and for the companion's cross-domain grant issuance. Absent such a signal, a capability is discovered out of band or by attempt: a Token Exchange, a cross-domain grant issuance, or an introspection request fails if the issuer does not support it. The smallest useful conforming deployment, noted here informatively, is a Mission Issuer that derives in narrowing mode from the Intent's proposed_authority (), emits only the Common Constraints of , and implements none of the OPTIONAL capabilities; a scope-only Resource Server still operates at the coarse scope level (). This note names a starting point and creates no new conformance class.

Overview

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 ).
• The Subject and Approver are each an (iss, sub) pair, matching the access token sub model of .

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 companion's cross-domain grant conveys Subject identity to the Resource AS through its own subject-resolution claims (), not through a Mission lookup. Issuer roles obey three invariants: a Mission has exactly one Mission Issuer, its issuer; a Resource AS never creates or alters a Mission; and a local token minted in another domain preserves the mission claim unchanged (). 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 (), not on the immutable Mission record. Richer subject identifier formats (for example, the formats of ) MAY be layered in future versions and are not required here.

Protocol Flow | derive authority |<----------- request_uri ------------| (authz_details) | | | 2. authorization request ---------->| Approver consents | | -> authority_hash |<-------------- code ----------------| -> Mission active | | (bound to the grant) | | | 3. token request ------------------>| gate: active? |<----------- access token -----------| + authz_details | | + mission claim v ]]> The flow then leaves the AS: (4) the agent calls the Resource Server with the token; the RS enforces the authorization_details statelessly and MAY check the mission claim, with no callback to the AS required. (5) A management revoke, or expires_at passing, moves the Mission to revoked or expired, after which the AS refuses further issuance and refresh; a deployment MAY additionally compose RFC 7009 refresh-token revocation (). The end-to-end example () walks this flow with concrete messages.

Mission Intent A Mission Intent is the proposal; the Mission is the approval; the integrity anchors commit the moment of transition. Before the approval event () only the Intent exists, as untrusted client input (); after it, only the Mission is authoritative. A Mission Intent therefore has no protocol identifier of its own: two submissions of the same Intent produce two distinct pending requests, and a Mission acquires its Mission Identifier () only at activation. The approved Intent is recorded on the Mission and committed by intent_hash (); it describes the task but commits no authority, which is committed separately by authority_hash over the derived Authority Set (). A Mission Intent is a JSON object describing the task. The client submits it in place of scope, or alongside a narrowed scope. It has the following members:

goal:

REQUIRED. A string. A human-readable statement of the task, for rendering to the Approver. Maximum 4096 characters.

resources:

REQUIRED. An array of strings. The target resources the task needs, each an absolute URI identifying a protected resource (an OAuth resource per -style indicators or a Protected Resource per ).

constraints:

OPTIONAL. An array of strings. Human-readable bounds on the task (for example, "read only invoices from 2026"). These inform derivation and consent rendering.

proposed_authority:

OPTIONAL. An array of objects, each shaped as an authorization_details entry. The client's concrete authority proposal for the task. It is untrusted input like the rest of the Intent and is committed by intent_hash with it (). When present, the AS MUST derive each Authority Set entry as a subset () of some proposed_authority entry, and the deterministic-reproducibility rule for narrowing-mode derivation applies (); goal and constraints then serve as rendering and bounding context over the proposed authority.

success_criteria:

OPTIONAL. An array of strings. Human-readable observable outcomes that indicate the task is complete. These are disclosure and audit material only: they are rendered to the Approver and committed by intent_hash (), but carry no machine semantics and MUST NOT be used to derive, widen, or gate authority.

purpose:

OPTIONAL. A string. A URI identifying the purpose of the task, recorded for disclosure and audit. Its semantics are deployment- or registry-defined and opaque to this document; like success_criteria it MUST NOT be used to derive, widen, or gate authority. A deployment MAY consult it for out-of-band policy or logging that does not affect the authority derived here.

expires_at:

REQUIRED. A string. An RFC 3339 date-time after which the AS MUST NOT derive tokens under the Mission.

controls:

OPTIONAL. An object of machine-actionable bounds. This document defines the members below; others MAY be added by deployments or defined by companion profiles (an extension member follows the collision-resistant naming and fail-safe rules of ):

acr:

OPTIONAL. A string. An authentication context class for the approval event: the approval authentication MUST be one the deployment's policy maps as satisfying the named class. No global ordering of acr values exists; the mapping is deployment policy.

max_derivations:

OPTIONAL. A positive integer (1 or greater). A bound on the number of derivations the issuer AS performs under the Mission, enforced per . A value of 0 is invalid (it would forbid even the initial issuance); to stop a Mission, revoke it (). An AS MUST reject max_derivations below 1 with invalid_request. This is an issuer-AS derivation cap, not an end-to-end credential cap: a cross-domain issuance counts as one derivation, and tokens another domain mints locally are not counted by the issuer, which cannot observe them (; detail in ).

This document defines no cumulative consumption bounds (for example, a budget, call-count, or activity-duration cap): every bound this document defines is enforced by a party this document names. An experimental companion defines cumulative consumption bounds as controls extension members together with the runtime metering that enforces them (). The following table summarizes which party enforces each bound a Mission carries and what holds when that enforcer is absent:

Bound	Enforced by	When that enforcer is absent
resource and actions	any Resource Server that enforces authorization_details ()	a scope-only RS enforces only the coarse scope projection ()
per-entry constraints	a Resource Server that understands and enforces the key ()	a Mission-aware RS fails closed; a scope-only RS does not evaluate them
max_derivations	the issuer AS at each derivation ()	never absent at the issuer; it does not bound another domain's local minting (see the cross-domain companion)

Example Mission Intent:

Submission via PAR A client MUST submit a Mission Intent through a Pushed Authorization Request using the mission_intent request parameter. The parameter value is the UTF-8 JSON 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 Mission Intent is closed at the top level: an AS MUST reject with invalid_request a Mission Intent containing a top-level member this document does not define. The top level is closed because its members feed approval rendering and the intent_hash commitment: an undefined member would enter what the Approver reads and what the anchor commits. Extension data belongs under controls, so deployment-defined semantics are explicit and cannot masquerade as core Intent semantics. This closure also keeps issuer-output members, such as a client-planted authority_hash, from entering through the Intent. 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 (), 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 with invalid_request a mission_intent presented on a front-channel authorization request that does not use a PAR-issued request_uri; a stray mission_intent on a request that redeems a request_uri is ignored, as specified below. The prohibition applies regardless of carriage: a mission_intent carried inside a signed request object is equally rejected; only PAR submission is accepted. PAR keeps the integrity-sensitive Intent off the untrusted front channel. Because mission_intent is untrusted client input that the AS records, derives from, and hashes, an AS MUST bound its total size and the lengths of its arrays, refusing an Intent that exceeds the deployment's limits with invalid_request, so an oversized Intent cannot exhaust the AS at rendering, derivation, or hashing. The limits are deployment-defined. A client MUST NOT submit authorization_details directly together with mission_intent; the AS derives authorization details from the Intent (). A request carrying both MUST be refused with invalid_request. This prohibition governs the raw request parameter; a client proposes concrete authority inside the Intent, through proposed_authority (). A client MAY submit scope and resource () 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.

Mission Authority From the Mission Intent, the AS derives the Authority Set: one or more authorization_details entries of type mission_resource_access (). The AS MUST:

• Produce, for each resources entry the deployment recognizes, a mission_resource_access entry whose resource is that URI and whose actions are derived from the Intent's goal, constraints, and deployment policy.
• Bound every derived entry by the Mission Intent: each derived entry's resource MUST be one of the Intent's resources values, and the derived authority MUST NOT exceed any machine-actionable controls bound. When the Intent carries proposed_authority (), each derived entry MUST additionally be a subset () of some proposed_authority entry. The AS SHOULD derive with fidelity to the Intent's goal and constraints; the recorded policy_version makes that fidelity auditable.
• Record the policy version used for derivation as the Mission's policy_version.

A resources entry the deployment does not recognize either causes refusal with invalid_authorization_details () or is omitted from the Authority Set, by deployment policy. When an entry is omitted, the token-response authorization_details echo () conveys the granted set, and the AS SHOULD signal to the client that derivation was partial. The derived Authority Set, not the Mission Intent, is the authority the Approver consents to: the AS renders the Authority Set for approval and commits it as authority_hash (). The Intent's goal, constraints, and other members describe and bound the task but grant no authority by themselves (); they constrain what the AS MAY derive, never widen it. Derivation is governed by local policy and is not a portable algorithm: different Authorization Servers MAY derive different Authority Sets from the same Mission Intent, exactly as different deployments grant different authority for the same request or the same scope. That locality is intended, not a gap. It is the resource-owning AS's policy, and it is not a value a foreign party needs to reproduce. What this profile makes interoperable is therefore not the derivation step but its result: the derived Authority Set's structure and vocabulary (, ) and its integrity anchors (), which a consumer in any domain interprets, enforces, and audits identically. A consumer enforces the derived Authority Set, never the Intent. Two rules keep local derivation accountable rather than opaque. First, reproducibility, scoped to how the AS derives. When the AS derives by narrowing the Intent's proposed_authority entries (), the same Mission Intent and the same policy_version MUST yield the same Authority Set at a given AS, so a derivation can be re-checked and a divergence detected. When the AS derives generatively, from free text or with model assistance, that determinism is not achievable; such an AS SHOULD instead make the derivation reproducible on a best-effort basis, disclose that it is non-deterministic, and record the policy_version and the inputs so a derivation can still be reviewed after the fact. Second, an AS SHOULD make the policy identified by a policy_version inspectable to relying parties and auditors that need to evaluate how it derives authority. Local policy is thus versioned and reviewable, which is what a cross-domain trust decision actually needs, even though the policy itself does not travel. Where cross-vendor interoperability matters, an AS SHOULD derive the Authority Set by narrowing the Intent's proposed_authority entries () to policy, rather than generating one from free text. Narrowing is governed by the subset rule (), which is interoperable, so the result is verifiable and enforceable in any domain even though the policy decision of what to narrow to stays local; the Intent's goal and constraints then serve as the human-readable consent-rendering layer over that proposed authority. Generating authority from free text alone is permitted but is the least portable and most semantically fraught option, and SHOULD be reserved for deployments that do not need cross-vendor agreement. For an open-ended task whose concrete objects cannot be enumerated at approval (for example, "reconcile this customer's ledger," where the individual invoices are not yet known), the AS SHOULD bound the derived authority primarily by constraints that hold as invariants over those objects (the owning customer, the tenant, an amount ceiling, read-only except named write actions, a validity window) rather than by an exhaustive resource enumeration. The runtime layer () checks each concrete object against the constraint at the point of use. Constraint-bounding lets a Mission cover an open-ended task with tight authority even though the specific objects are unknown at approval, and avoids the over-broad enumeration a deployment would otherwise need in order to anticipate them. A mission_resource_access entry is a authorization_details object with these members:

type:

REQUIRED. A string. mission_resource_access.

resource:

REQUIRED. A string. The single protected resource the entry applies to, an absolute URI identifying an OAuth protected resource () or a Protected Resource (). It is the same kind of identifier as the resource value. The AS derives the token aud from the resource values of the carried entries as described in ; the aud identifies the Resource Server(s) and need not be byte-equal to a resource (it is typically coarser). resource is carried here as a type-specific member of each mission_resource_access entry, which permits; carrying it per entry (rather than once for the request, as the resource request parameter does) lets one token scope distinct authority to distinct resources. Per Section 3.2, the resource authorization request parameter does not affect how the AS processes authorization_details, and this member is distinct from the common locations field.

resource_match:

OPTIONAL. A string: exact (the default, and the behavior when the member is absent) or prefix. Under exact the entry applies to the resource URI alone. Under prefix the entry authorizes the resource itself and any URI beneath it at a path-segment boundary (the resource followed by / and further path). These two values are the only ones defined; a consumer MUST treat an entry whose resource_match value it does not recognize as unenforceable and fail closed (). Containment between effective resource sets is compared as defined in .

actions:

REQUIRED. An array of strings. Permitted action values. Each value is either an action identifier matching [A-Za-z0-9_.:-]+ or an action family: an action identifier followed by .*. Like an OAuth scope, an action value carries meaning only at the resource that defines it; a consumer enforces only the actions it recognizes for that resource and honors no others, so an action a consumer does not understand is fail-closed by construction (the action is simply not within the authority it can enforce). An AS SHOULD draw action identifiers from a namespace the serving resource documents, so the set is interpretable cross-vendor rather than ad hoc. An action family authorizes every action whose dot-separated identifier extends the family name at a segment boundary (invoices.* authorizes invoices.read and invoices.q3.export, not invoicesx.read). A consent rendering MUST present a family as the breadth it is: all actions under the name, not one action. An AS SHOULD treat deriving a family as high-risk breadth.

constraints:

OPTIONAL. An object. Machine-actionable per-resource bounds (for example, max_amount). A member name defined as a Common Constraint () has shared semantics across deployments; any other name is deployment-defined.

• Because a constraints member narrows authority, a Resource Server that cannot enforce one MUST fail closed ().
• To avoid that failure mode, the AS SHOULD emit for a given resource only constraints keys that the Resource Server serving it is known (by registration or deployment policy) to understand and enforce.

delegation:

OPTIONAL. An object. The delegation policy for this entry (). When absent, this entry's authority is non-delegable: it MUST NOT appear in a delegated token. When present, it has these members:

max_depth:

REQUIRED. An integer. The maximum delegation depth at which this entry's authority may be exercised ().

allowed_delegates:

OPTIONAL. An array of objects. The permitted delegates, each a may_act-style matcher (): { "sub": "<client_id>" } for a specific delegate, or { "sub_profile": "<actor-type>" } for an actor-type class. When absent, any actor is permitted (subject to max_depth).

A companion profile of this document MAY define additional delegation members. Such a member is policy, not authority (): a derived entry's value for it MUST NOT be broader than the parent entry's, and a member the AS does not understand is carried unchanged.

Example Authority Set (the read entry is delegable to depth 2 and bounded to a Q3 issuance window by the resource_issued_after and resource_issued_before Common Constraints (); the write entry carries no delegation and so is non-delegable, because delegation is per entry):

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's effective resource set is contained in B's (resource_match, ): when neither entry sets resource_match: "prefix", A.resource equals B.resource; when B is a prefix entry, A (whether exact or prefix) is contained when A.resource equals B.resource or extends its path at a path-segment boundary; a prefix A is never contained in an exact B.
2. Every A.actions value is within some B.actions value: a value is within an equal value; a literal action is within a family whose name it extends at a segment boundary (invoices.read is within invoices.*); a family is within a reference family when its own name extends the reference's name at a segment boundary (invoices.q3.* is within invoices.*). A family is never within a literal action.
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 specification-defined rule when K is a Common Constraint (), 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. Authority under a Mission MUST NOT widen after the approval event: a request that exceeds the Authority Set on any dimension (a new resource, action, actor, delegation path, longer duration, or constraint relaxation) is refused under this rule, and broader authority requires a fresh approval event, either a new Mission or a successor per the companion . Resource containment under a prefix reference is compared after RFC 3986 syntax-based normalization of both URIs: lowercase the scheme and host, remove a default port, decode percent-encoded octets of unreserved characters, and remove dot-segments. This normalization applies to comparison only, never to hashing: anchor computation (, ) remains byte-exact over the recorded values and is untouched by this rule. The default comparison is deliberately flat: resource matches by exact equality and a literal action by array membership. Hierarchy is opt-in and closed to the two forms above: resource_match: "prefix" for resource containment and .* action families for action containment (). A deployment that uses neither retains the flat behavior unchanged. The delegation member is policy, not authority, and is not part of this comparison (). 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.

Common Constraints A constraints member name () is either a specification-defined Common Constraint or a deployment-defined key. Common Constraints give independently developed deployments one vocabulary they interpret, narrow, and compare identically; further Common Constraints are defined by specification under the naming convention of . A Common Constraint definition fixes:

• Value syntax: the JSON 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 .
• 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 a specification-defined Common Constraint is interpreted per its definition. Any other member name remains deployment-defined and is interpreted only within the issuing deployment; a consumer that does not recognize it MUST fail closed (). This document defines the initial Common Constraints:

• max_amount (object): a per-action ceiling on a monetary amount. The value is an object with two members: amount (REQUIRED, a string containing a decimal number) and currency (REQUIRED, an ISO 4217 currency code). Subset: no broader when the currency values are equal and the candidate amount is less than or equal to the reference amount, compared in decimal value space; differing currencies fail the comparison (no conversion is defined). Intersection: when the currency values are equal, the value with the smaller amount; differing currencies have no intersection and the combination fails.
• resource_issued_after (string, an RFC 3339 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.
• resource_issued_before (string, an RFC 3339 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. The resource_ qualifier in both names marks that the window bounds resource issuance, not token issuance.
• tenant (string): the action applies only to resources of the named tenant. Subset: no broader when equal to the reference value. Intersection: the common value when the two are equal; otherwise there is no intersection and the combination fails.
• recipient_domain (string, a DNS name): the action applies only to recipients within the named domain. Subset: no broader when equal to the reference or a DNS subdomain of it. Intersection: the narrower value when one is equal to or a subdomain of the other; otherwise there is no intersection and the combination fails.

These comparisons are in value space, not lexical: max_amount amount members are compared as the decimal numbers the strings contain, so "500", "500.0", and "500.00" are equal; resource_issued_after and resource_issued_before values are compared as the instants they denote after normalization to UTC, so two RFC 3339 representations of the same instant that differ only in timezone offset or trailing subsecond zeros are equal; recipient_domain values are compared as DNS names, case-insensitively and on whole labels, so mail.example.com is within example.com and not-example.net is not. A Common Constraint definition MUST fix its subset and intersection in value-space terms, so that independent deployments compute the same result for the same values and the subset rule of is reproducible. A numeric constraint value MUST lie within the range JCS serializes exactly. Monetary amounts avoid that hazard by construction: max_amount carries its amount as a string containing a decimal number, paired with an ISO 4217 currency code, and a future Common Constraint for a monetary value SHOULD reuse this shape rather than a JSON number.

Other Authorization Details Types mission_resource_access is the only type this document defines, but the Authority Set MAY include other AS-supported 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 (); 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 (, ). A type whose subset and delegation semantics the AS does not understand MUST NOT be delegated, audience-projected to a Resource AS, or narrowed: the AS cannot prove a transformed copy is still a subset of what was approved. Such an entry MAY be issued only to its original approved audience, carried exactly as approved, and MUST NOT appear in a delegated token or in a cross-domain grant ();
• evaluating the entry against a concrete request is the runtime layer's responsibility (), not the AS's.

This lets policy-language profiles compose without this document defining them: for example, an entry carrying a Cedar policy set (), 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: 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 . Because the Cedar profile defines no subset or delegation rule over policy sets, the AS carries the Cedar entry as approved rather than narrowing it, and it MUST NOT appear in a delegated token or cross-domain grant. Delegation controls on other entries, such as the mission_resource_access entry, apply to those entries only.

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 (the max_amount and recipient_domain Common Constraints, ). 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 ().

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: Delegation to a sub-agent works unchanged: add a delegation member to a tool entry (). For example, an entry a sub-agent of type ai_agent may invoke at depth 1, narrowed to the read tool only: 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 (, 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 (, ) rather than introduce a new entry type.

Mission Approval The approval event is the atomic transition at which the Approver consents and the AS creates the Mission. It runs as an OAuth 2.0 authorization-code flow initiated from the PAR-issued request_uri (). Because the authorization code is the artifact the Mission grant binds to () and it travels the front channel, the AS MUST bind the code to the requesting client with PKCE (, S256 challenge method) or, equivalently, issue a DPoP-bound authorization code (). The AS MUST reject a code redemption whose PKCE verifier or DPoP key does not match the binding established for the request. This prevents authorization-code injection from yielding the Mission grant. At the approval event the AS MUST, in order:

1. Authenticate the Approver. If the Mission Intent's controls.acr is present, the authentication MUST satisfy it.
2. Establish the Subject: the principal the task is for, recorded as the Mission's subject and set as the sub of every derived token (). When the Approver is the Subject (self-approval), this is the authenticated Approver. When the Approver is a different principal (for example, an administrator or manager approving on a user's behalf), the AS MUST itself establish the Subject's (iss, sub), and MUST authorize the Approver to approve for that Subject under local policy. The AS MUST NOT take the Subject from unauthenticated client input. This document defines no wire parameter for the Subject; how the AS establishes it (administrative selection, a directory, an authenticated reference) is a deployment matter.
3. Render for consent the derived Authority Set in human-meaningful terms, with the goal, constraints, expires_at, and any controls bounds (notably max_derivations) as context. The object the Approver consents to is the derived Authority Set, what the agent may actually do, not the goal or Mission Intent: derivation is local policy, and nothing commits that the derived authority faithfully reflects the goal the Approver read, so the authority itself MUST be what is rendered and consented to. An approval surface that renders only the goal, success_criteria, or Mission Intent and not the derived Authority Set does not conform. When the Approver is not the Subject, the rendering MUST identify the Subject the authority is granted for. When the Intent carried proposed_authority (), the rendering MUST distinguish the entries the client proposed from any narrowing or restructuring the AS applied.
4. Compute the integrity anchors (): authority_hash over the consented Authority Set and intent_hash over the approved Mission Intent.
5. Create the Mission record () in the active state, atomically with issuance of the authorization code.

Client-supplied strings (goal, constraints, success_criteria) MUST be rendered as inert text and MUST NOT be interpreted as markup. The AS SHOULD mitigate Unicode direction-override and confusable-character presentation in them. The rendering MUST visually distinguish the AS-derived Authority Set from client-supplied text, so crafted client text cannot pass as derived authority. A deployment MUST declare a minimum approval-authentication strength 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 (). The approval authentication for such a Mission MUST meet that minimum, and controls.acr can raise the required strength but never lower it below the floor. The material notices of the consent-evidence profile identify these same high-risk classes (). An Approver who declines, and an Approver whose authentication cannot satisfy controls.acr or the declared approval-strength floor, yield access_denied on the authorization response (). A token-endpoint resource value outside the Authority Set yields invalid_target (). Rendering a bound is not the same as enforcing it, and a deployment MUST NOT let the rendering imply otherwise. Which party enforces each bound, and what holds when that enforcer is absent, is summarized in the enforcement table (). An AS SHOULD make clear to the Approver which rendered bounds its deployment actually enforces, so consent is not given to a limit that binds nowhere. The authority_hash is the authority commitment: it binds, by cryptographic digest, exactly the authority the Approver approved. It commits the approved authority, not the way that authority was rendered to the Approver; this profile commits no separate consent disclosure object (see ). If the derived Authority Set changes between rendering and consent, the AS MUST recompute and MUST refuse to activate unless the Approver consents to the changed set. Every token derived under the Mission carries this value (), so a party holding the full Authority Set can verify a token's authority against what was approved. A party holding only a narrowed subset cannot recompute it and treats it as an audit anchor (see ). The intent_hash commits the approved Mission Intent: the task the Approver consented to, as recorded on the Mission. It makes the recorded task tamper-evident: an auditor can verify the Mission's intent against intent_hash and detect any later alteration. intent_hash commits the task; authority_hash commits the authority derived from it.

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 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, ). It then applies the gating of . A client does not supply mission_id to obtain a derivation; an AS MUST NOT derive Mission-bound authority from a client-supplied mission_id, because the grant, not the identifier, determines the Mission. When the authorization code expires unredeemed, no derivation is possible under the Mission; the AS SHOULD revoke the Mission or allow it to expire. A client learns its mission_id from the mission claim's id on each issued token () or from the token response. This document defines mission_id as an OPTIONAL token-endpoint response parameter: a string carrying the Mission Identifier, returned alongside the issued token. It is an informational reference only: presenting it authorizes nothing (), and a client MUST NOT derive authority from it.

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

• Multi-party approval (M-of-N or dual control), where more than one principal must approve. The number of approvers is orthogonal to the consent commitment: however many principals approve the same rendered Authority Set, the authority_hash is identical, as is every token derived from it. Multi-party approval raises the assurance of how approval was obtained; it does not change the artifacts this document produces. A deployment requiring dual control 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.

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: ", "iss": "", "value": } ]]> 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 .
3. Compute SHA-256 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 (): 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). The mission- prefixed values defined by profiles that extend this document 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.

Canonicalization Rules JCS 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 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. The only normalization this document defines is the RFC 3986 comparison of the resource-containment test (), which applies to that comparison alone: the default resource equality test of remains an exact match, and anchor computation is always byte-exact over the recorded values.

Test vectors for both anchors are provided in .

Mission Record A Mission is the durable record created at the approval event. Its members are immutable after creation except for its state, and it is identified by a Mission Identifier (). Its members do not repeat the mission prefix: the record is the Mission, and prefixed names belong to surfaces that reference a Mission from outside it, such as the mission_intent request parameter and the mission_id response parameter. Member names are spelled out (issuer, expires_at, created_at) and are spelled identically on every surface that carries Mission facts; the compact JWT names (iss, exp, iat) describe a signed artifact's own envelope, or identify a party in an {iss, sub} object, never the Mission. Operational issuance bookkeeping, such as the derivation count gated under , is AS-side state about the Mission, not a member of the immutable record. Like the mission claim (), the record is open (): a companion profile of this document MAY record additional members set at creation using short names coordinated with it (for example, a lineage member linking the Mission to a predecessor or parent); any other extension MUST use collision-resistant names. The members below are the ones this profile defines:

id:

REQUIRED. A string. The canonical Mission Identifier ().

issuer:

REQUIRED. A string. The issuer URL of the Mission Issuer that approved the Mission. Equals the iss of tokens that AS derives; for cross-domain tokens it remains the originating AS even though the issuing iss differs ().

state:

REQUIRED. A string. The current lifecycle state: active, revoked, or expired in this profile, or an additional state defined by a companion profile, subject to the forward-compatibility rule of .

intent:

REQUIRED. An object. The approved Mission Intent.

authority_set:

REQUIRED. An array. The consented Authority Set.

authority_hash:

REQUIRED. A string. The consent commitment over the Authority Set ().

intent_hash:

REQUIRED. A string. The integrity commitment over the approved Mission Intent (), making the recorded task tamper-evident.

subject:

REQUIRED. An object. The Subject, an object with iss and sub.

approver:

REQUIRED. An object. The Approver, an object with iss and sub. MAY equal subject.

client_id:

REQUIRED. A string. The Agent (OAuth client) that submitted the Mission Intent.

policy_version:

REQUIRED. A string. The derivation policy version in effect at the approval event.

approval_event_id:

REQUIRED. A string. A unique identifier of the approval event, used as the approval idempotency key.

created_at:

REQUIRED. A string. RFC 3339 timestamp of creation.

expires_at:

REQUIRED. A string. Mirrors intent.expires_at.

The audit horizon is the deployment-declared retention window for the Mission record and its evidence: at least the Mission's lifetime plus a declared post-expiry period. After the Mission reaches a terminal state (revoked or expired), the record MUST be retained for the audit horizon.

Mission Identifier Format A Mission Identifier is an opaque URL-safe ASCII string of [A-Za-z0-9_-] characters, with at least 128 bits of entropy, carrying no semantic content. It MUST NOT be reused. The record and the mission claim carry it as id; a surface that references a Mission from outside carries it as mission_id, as in the token-response parameter ().

Worked Example

Mission-Bound Access Tokens Access tokens issued under a Mission are JWTs per , which fixes the required claims (including jti) and the at+jwt JOSE header typ ( Sections 2.1 and 2.2); a Resource Server MUST verify the typ per . In addition to what that profile requires, a derived token:

• carries the token's Mission-derived authority as authorization_details (); this MAY be the full Authority Set or a narrowed subset ();
• carries a mission claim ();
• sets sub to the Mission's Subject sub and client_id to the Mission's client_id;
• MUST set aud to identify the Resource Server(s) authorized to consume the carried authorization_details, and MUST NOT include an audience unrelated to that carried authority (see below);
• MAY carry an act claim when the agent has delegated execution ();
• MAY carry a scope claim, subject to the rule below;
• SHOULD be sender-constrained, via a cnf claim : DPoP (cnf.jkt) or mTLS (cnf.x5t#S256).

The AS MUST NOT include authorization_details exceeding the Mission's Authority Set. On any issuance that narrows authority (for example, a single-audience token), each emitted entry MUST be a subset of a Mission Authority Set entry under . The aud SHOULD be derived from the resource indicators (), Protected Resource metadata (), or the deployment's resource-to-RS mapping. It identifies the Resource Server(s) and need not be byte-equal to the resource values of the authorization_details entries: an aud typically names an RS, API, or security domain, while RAR entries may name resources, accounts, tools, or locations beneath it. Bounding aud to the consuming Resource Server(s) prevents a confused-deputy or token-redirection attack: a multi-resource Authority Set otherwise yields a token an unrelated Resource Server would accept even though it was obtained to act elsewhere. A deployment SHOULD prefer per-RS (single-audience) tokens, narrowed under . A client requests such a token at the token endpoint with the resource parameter (and MAY further narrow with scope); the AS narrows the Authority Set under to the requested resource(s) and sets aud to the corresponding Resource Server(s). This is the within-domain counterpart of the audience-scoping the Mission Issuer applies when projecting authority to a Resource AS (). Sender-constraining is a SHOULD for this primary token, aligned with . It is stronger (MUST) for delegated tokens, which face higher replay exposure in the hands of a less-trusted delegate (); the companion sets the same MUST for the credentials that cross a trust domain (). A deployment SHOULD sender-constrain the primary token as well where its threat model warrants. The token-endpoint response conveys the granted authority to the client. Because the client submits mission_intent rather than authorization_details, the access token is otherwise the only place the granted authority appears, and a client is not expected to parse the access token for authority. The AS therefore MUST return the granted authorization_details in the token-endpoint response, per Section 7, reflecting exactly the (possibly narrowed) set assigned to the issued token. (A client does read the mission claim's id from the token to learn its mission_id, per ; "not expected to parse for authority" refers only to the authorization_details, which the response echoes.) The same applies to refresh and Token Exchange responses. For example, the agent narrows the canonical ERP Mission (the worked example of ) to a read-only token, presenting the Mission's refresh token with the resource parameter and narrowing further with scope: The issuance is a derivation, gated on the Mission being active (). The response echoes the narrowed grant and the mission_id reference (); the emitted entry is a subset () of the Mission's read entry, its constraints carried intact: Mission-bound refresh tokens MUST be sender-constrained or use refresh token rotation. This matters most for a public client, since Mission-state gating bounds a stolen refresh token's usefulness over time but not while the Mission is still active. This strengthens the refresh-token guidance of Section 2.2.2, whose MUST applies to public clients, to all Mission-bound refresh tokens. The authentication context of the approval event (controls.acr, ) describes the Approver at approval time and is recorded on the Mission, not on derived tokens; a derived token's authority comes from the Mission, not from a fresh authentication, so this document requires no acr or auth_time claim on it. An AS MAY include acr and auth_time per to convey the approval context, but a consumer MUST NOT treat their absence as an authentication downgrade. authorization_details is the authoritative expression of a Mission-bound token's authority. Any scope the token carries MUST be derived from, and no broader than, the Authority Set. Specifically:

• every scope value MUST correspond to authority already present in authorization_details; and
• a scope value MUST NOT convey authority, or relaxation of a constraint, that the Authority Set does not grant.

Because scope is a coarse string list, it cannot carry the per-entry constraints; it is a compatibility projection, never the authoritative form of the Mission's authority. The AS MUST NOT issue a Mission-bound token whose scope exceeds the Authority Set. A credential the Mission Issuer derives MUST have an exp that does not exceed the Mission's expires_at, so that no credential outlives the approved Mission (not merely that none is issued after expiry). How this bound extends transitively to tokens minted in another trust domain is specified by the companion ().

The Mission Claim The mission claim is a JSON object:

id:

REQUIRED. A string. The Mission Identifier ().

issuer:

REQUIRED. A string. The Mission's issuer (). A credential's iss names the party that minted it; mission.issuer names the party that approved and serves the Mission, and the two deliberately differ for tokens minted in another trust domain ().

authority_hash:

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

The mission claim is an open object (): additional members MAY appear alongside the three 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) 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:

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 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 , 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 (); 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 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. A protected resource MAY advertise this requirement through the mission_bound_authorization_required protected resource metadata member ().
• MAY treat the mission claim as audit and correlation context.
• SHOULD, when serving Mission-bound requests, log the mission claim's id and the token jti with each served request, so its access logs join to Mission evidence.
• MAY recompute authority_hash (). A Resource Server that performs it recomputes the anchor over the full Authority Set it independently holds, compares the result to mission.authority_hash, and MUST reject on mismatch. It additionally verifies that each carried authorization_details entry is a subset () of that held set. A narrowed token matches by the subset test, never by hashing its carried entries: the anchor is computed only over the full Authority Set, so a Resource Server MUST NOT recompute it from a token's carried subset.
• MAY, where the AS offers it, introspect the token () 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 ().

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 (); 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).

Mission Lifecycle and Gating A Mission is in one of three states:

• active: tokens MAY be derived. The only state from which issuance proceeds.
• revoked: terminated by the Subject, Approver, or policy. Terminal.
• expired: expires_at has passed. Terminal.

The transitions are:

From	Event	To
(none)	approval event	active
active	revoke	revoked
active	expires_at reached	expired

These three states are the mandatory core of the Mission lifecycle state space. This profile owns that state space; an OPTIONAL companion profile MAY define an additional state for a lifecycle it introduces (for example, a paused or a superseded state), but only active ever permits issuance. To keep the state space extensible without a registry, a consumer MUST apply this forward-compatibility rule wherever a Mission state is reported, including the Mission record and the introspection mission member: only the exact value active permits derivation or continued reliance, and every other value, including a value the consumer does not recognize, MUST be treated as non-active and non-deriving. A consumer MUST NOT fail open on an unrecognized state. This makes a state added by a companion profile fail safe for a consumer that predates it.

Issuance Gating The AS MUST refuse to derive a token, at the token endpoint, on refresh, and on Token Exchange (), unless the referenced Mission is active. Issuance against a revoked or expired Mission MUST fail with invalid_grant. Because derivation is gated on Mission state, revoking or expiring a Mission stops all further authority for the task, including refresh. The active check MUST be evaluated atomically with issuance, as the derivation-count check already is, so a revocation serialized before an issuance is honored by that issuance. When the Mission Intent sets controls.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 issuer AS performs for a single request: the initial authorization-code exchange, a refresh, a Token Exchange, or a cross-domain grant issuance (). Each counts as exactly one, regardless of how many artifacts it emits: a code exchange that returns both an access token and a refresh token is one derivation, and a refresh that rotates both is one. The exact rules:

• A derivation that fails, including one refused for exceeding the bound, MUST NOT be counted.
• The check and increment MUST be atomic with issuance, so concurrent derivations cannot collectively exceed the bound.
• The count covers only derivations the issuer AS performs. Tokens another domain mints locally under the Mission are not counted by the issuer, which cannot observe them; the cross-domain issuance that authorized them was counted once, and the local issuer bounds its own minting by its policy ().

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.

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 (, ) already rides on existing endpoints, so no standardized endpoint is required for interoperability. A standardized Mission management API, with suspend/resume/complete operations, is specified separately by Mission Status ; this document does not require it. A deployment MAY additionally treat 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 () 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 ; this document does not require them. Token validity and Mission validity are distinct: a token can outlive a transition of its Mission, by at most the token lifetime. A deployment whose consumers rely on Mission state beyond a token's lifetime SHOULD offer introspection () or the Mission Status companion, so an authorized party can determine the Mission's current state rather than inferring it from token validity.

Mission State via Token Introspection This section is OPTIONAL. The stateless baseline () needs no introspection; an AS that does not offer it, and a Resource Server that does not use it, are unaffected. It lets a Mission-state-aware Resource Server observe a Mission's current state per request instead of waiting out a token's lifetime. Because it can report Mission state for a token whose Mission is no longer active, this section deviates from the SHOULD NOT of Sections 2.2 and 4 against including additional information about an inactive token; that deviation is justified and governed by the caller-authorization and minimization rules below (). An AS MAY support OAuth 2.0 Token Introspection for Mission-bound access tokens. When it does, the response for such a token carries, in addition to the standard members, a mission member: id, issuer, and authority_hash (as in the mission claim, ) plus, when the responding AS is the Mission issuer, the current lifecycle state (string). The core states are active, revoked, and expired (); a deployment that runs a companion profile defining an additional state reports that state here, and a consumer applies the forward-compatibility rule of (only active permits reliance; any other value, recognized or not, is non-active). Only the issuer reports state (). The AS includes the mission member only when it has authenticated the caller, the caller is authorized for the token (), and the presented token resolves to a Mission. For a malformed, unknown, individually expired, or otherwise unresolvable token, the AS responds per (active: false) with no mission member; it does not reveal Mission state for a token it cannot bind to a Mission. The case below (active: false with mission.state) applies only to a token that is itself valid but whose Mission is no longer active. The composite-active rule () and the mission member apply equally when a Mission-bound refresh token is introspected.

Caller Authorization and Minimization The introspection endpoint is protected per . 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 ().

Because this profile returns the mission member and mission.state even when active is false (diverging from the SHOULD NOT against disclosing detail 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.

Composite Active State The introspection active member reflects the composite authorization, not the token in isolation. The AS MUST return active: true only when the access token is itself valid (valid signature, unexpired, and not individually revoked) AND the Mission is active. The AS does not verify the token's sender-constraint (cnf) at introspection: proof of possession is checked by the Resource Server when the token is presented, not by the AS over an introspection call, so active: true is not by itself evidence the caller holds the bound key. When the token is otherwise valid but the Mission is revoked or expired, the AS MUST return active: false and include mission.state giving the reason, so a Resource Server can distinguish a dead Mission from a bad token. (This deviates from the SHOULD NOT against including 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.

Only the Issuer Reports Mission State An AS MUST NOT include mission.state in an introspection response unless it holds the Mission, that is, unless it is the Mission issuer. Introspection at a non-issuer Resource AS, which returns the claim-shape members only and never state, is specified by the companion (). 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 ().

Examples While the Mission is active, the response is the standard body plus the mission member. The canonical ERP token (), introspected at the issuer AS: The same token after the Mission is revoked, reported per the composite-active rule ():

Delegation Within a Mission This section is OPTIONAL. A deployment whose agents never delegate, and a Resource Server that sees no delegated tokens, are unaffected. An agent may delegate execution to downstream actors (a sub-agent, service, or tool that is itself an OAuth client) within a Mission. Delegation is represented with the OAuth Actor Profile , which profiles the RFC 8693 act (actor) claim. A delegate obtains a delegated token by Token Exchange (). The AS issues the delegated token subject to all of the following:

• The exchange is explicit. The delegating Mission-bound access token is the subject_token, with subject_token_type of urn:ietf:params:oauth:token-type:access_token. The delegate is identified by an actor_token (with its actor_token_type) or by its own client authentication, and the AS asserts the actor itself (); a requested_token_type of urn:ietf:params:oauth:token-type:access_token is used. The response carries the matching issued_token_type and a token_type for the issued access token, per Section 2.2.1.
• Subject is stable. sub remains the Mission's Subject. The delegate is an actor, not the subject.
• The approved agent stays client_id. This profile keeps client_id equal to the Mission's approved agent on every derived token (), so the approved party is verifiable everywhere. Downstream delegates are carried in the act chain, not in client_id. For delegated tokens this deliberately overrides the client_id definition of Section 4.3, which Section 2.2 incorporates (the client that requested the token); here the immediate delegate is the outermost act.
• The act chain identifies the delegates. The delegated token carries an act claim per the Actor Profile : the outermost act is the immediate delegate, with prior delegates nested inward, back toward the approved agent. Each actor object carries the members that profile defines (sub, iss, and the RECOMMENDED sub_profile actor-type classification, e.g. ai_agent). This document does not re-specify the act structure.
• Authority only narrows. The delegated token's authorization_details MUST be a subset () of the delegating token's authority, hence of the Mission Authority Set. Delegation MUST NOT add authority.
• The Mission binding rides unchanged. The delegated token carries the same mission claim (), its id, issuer, and authority_hash, so every actor in the chain operates under the one consented authority.
• Each delegate is bound to its own key. The delegated token MUST be sender-constrained () to the delegate's own key: its cnf is the delegate's DPoP or mTLS key, not the delegating party's. The delegate proves possession of that key in the Token Exchange. A compromised delegate key therefore cannot be replayed as the agent or as another actor in the chain, and each actor's credential is independently revocable by key.
• Each delegation is gated. Issuing a delegated token is a derivation event; the AS MUST refuse it unless the Mission is active ().

Where a deployment authenticates client instances (; for AI agents, its agent profile ), the delegate identified by the outermost act is the concrete instance: act.sub is the instance identifier and act.cnf is the instance-specific key. This profile's requirement that a delegated token be sender-constrained to the delegate's own key then lands on an instance-possessed key by construction. An allowed_delegates matcher can select instance-grade actors (), for example { "sub_profile": "client_instance" }. The sub_profile values used here (ai_agent, client_instance) are drawn from the entity-profiles vocabulary those instance profiles use; the Actor Profile remains the structural reference for the actor object.

Design Alternative: Rebinding client_id to the Delegate A rejected alternative rebinds client_id to the immediate delegate on each hop, the plain reading in which client_id names the immediate client. Rebinding loses the stable approved-agent binding that every consumer of a derived token can verify: each downstream token presents as a new client rather than an actor executing within the approved Mission, and joining who was approved to who executed requires reconstructing the hop history from issuance records rather than reading both from the token. Rebinding is also safe only where every Resource Server processes act anyway, since the delegation history lives nowhere else; that is exactly the discipline this profile's chosen design requires, so rebinding buys no relaxation. The operational rule of therefore holds regardless of the binding choice: a Resource Server that authorizes or logs the caller MUST process the act chain, and a deployment SHOULD NOT route delegated tokens to a Resource Server that authorizes or logs on client_id without processing act.

Self-Exchange Down-Scoping An agent MAY present its own Mission-bound access token as the subject_token of a Token Exchange () with no actor, to obtain a narrowed token (for example, a single-audience one). The result MUST be a subset () of the presented token's authority, carries the same mission claim (), and adds no act chain. It is a derivation and is gated on the Mission being active (). Because it names no actor, it does not delegate: it re-scopes the agent's own authority downward.

Delegation Constraints What may be delegated, how far, and to whom is governed per Authority Set entry by the entry's optional delegation member (). Because the policy lives in the entry, it is committed by authority_hash with the rest of the Authority Set and travels with the entries wherever they are carried, including across a cross-domain projection (), needing no separate mechanism. Delegation depth. The delegation depth of a token is the number of actors in its act chain (the nesting depth of the act claim), counted from the approved agent: the agent's own non-delegated token is depth 0, the first delegate is depth 1, and each further delegate adds 1. The depth checked against max_depth is that of the token being issued, computed after appending the new outermost actor, not the depth of the delegating token. A credential projected across a trust domain carries no act chain and enters the target domain at depth 0 (). 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 (). 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 ( 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). An actor's sub_profile MAY carry multiple space-separated values; a { "sub_profile": ... } matcher is satisfied when its value is among the actor's values. 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; how a Resource AS evaluates conveyed matchers, failing closed and narrowing out any sub matcher it cannot resolve, is specified by the companion (). Empty result. If narrowing leaves no entries for the delegate, the AS MUST refuse with invalid_target ( Section 2.2.2) rather than issue a token with empty authority: the requested delegation has no authority to carry, while the subject grant itself remains valid for other exchanges. The Resource Server enforces none of this. Delegation constraints are applied by the AS at issuance; a Resource Server sees only the already-narrowed authorization_details and enforces those as usual ().

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

Extensibility This profile is a base layer that other agent-authorization work is expected to extend. Extensions build alongside the stable interface below; they MUST NOT redefine it. An extension MAY rely on these remaining stable across revisions of this profile:

• the mission claim members id, issuer, and authority_hash ();
• the mission_resource_access authorization details shape (); and
• the act delegation chain ().

The profile offers four extension points, each a declared seam rather than new machinery:

• Authority types. The Authority Set is open to other AS-supported authorization_details types (); the Mission apparatus (commitment, gating, delegation) is type-agnostic toward them, subject to the delegation and projection limits in .
• Integrity anchors. Additional committed objects use the same domain-separated, issuer-bound envelope with a new typ (). A consent-disclosure commitment, an instruction-text attestation, or a delegation receipt can be committed this way without changing this profile. A profile that commits an evidence or disclosure object MUST commit it with this envelope and a collision-resistant typ, not by hashing the bare object, so the domain separation and issuer binding hold uniformly. A mission descriptor embedded in such an object uses the mission claim shape (), optionally extended with collision-resistantly named members (for example, an intent_hash for audit), and is never authority-bearing on its own.
• The mission claim. It is an open object (): additional, collision-resistantly named members ride the mission binding (for example, a runtime decision reference, a delegation receipt, or an attestation reference), and consumers ignore unknown members and never derive authority from them.
• Lifecycle state. The lifecycle state space () is open to additional states defined by companion profiles for lifecycles they introduce. The forward-compatibility rule in keeps this safe without a registry: only active permits issuance, and a consumer treats every other state, recognized or not, as non-active.

This document defines no extension registry, capability-negotiation mechanism, or profile-version field; an extension declares its own identifiers and, where it needs discovery, its own metadata. The extensibility of the typ value space, the mission claim, and the lifecycle state space rests on collision-resistant naming and the fail-safe rules above rather than on central registration.

Authorization Server Metadata An AS MAY advertise support for this specification in its authorization server metadata :

mission_bound_authorization_supported:

OPTIONAL boolean. When true, the AS supports the core Mission Issuer surfaces of this profile (): the mission_intent authorization request parameter through PAR (), derivation of mission_resource_access authorization details (), Mission-bound access tokens (), and the mission JWT claim (). It asserts Mission Issuer support only; it makes no claim about any Resource Server, nor about the OPTIONAL capabilities (delegation, introspection, cross-domain projection), which are discovered out of band or by attempt ().

An AS that advertises this profile SHOULD also include mission_resource_access in its authorization_details_types_supported metadata (), so that RFC 9396-aware clients discover the authorization details type through the standard mechanism. A client MAY use the RFC 9396 client metadata authorization_details_types at registration to declare the types it understands. Discovery is OPTIONAL: a deployment MAY arrange Mission-bound authorization out of band, and this member only lets an AS advertise it. When the member is absent or false, a client MUST NOT infer that the AS supports this specification. An AS that advertises mission_bound_authorization_supported: true MUST also publish pushed_authorization_request_endpoint (), since a Mission Intent is accepted only through PAR (). This member and the mission_bound_authorization_required member of are unauthenticated discovery data: their integrity rests on the metadata retrieval protections of and , whose security considerations apply.

Protected Resource Metadata A protected resource MAY advertise, in its protected resource metadata :

mission_bound_authorization_required:

OPTIONAL boolean. When true, the protected resource accepts only Mission-bound tokens: a token that lacks the mission claim () is rejected (). When absent or false, the resource makes no such requirement.

Security Considerations

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 (). authority_hash commits the full Authority Set, while a derived token may carry a narrowed subset, so a Resource Server cannot in general recompute it from the token alone. Recomputation is OPTIONAL. A Resource Server that performs it recomputes the anchor over the full Authority Set it independently holds, compares the result to mission.authority_hash, and MUST reject on mismatch; it additionally verifies that each carried authorization_details entry is a subset () of that held set. A narrowed token matches by that subset test, never by hashing its carried entries: the anchor is defined only over the full set. A Resource Server that does not hold the full Authority Set treats authority_hash as a whole-Mission audit and correlation anchor () and enforces the token's authorization_details directly (). 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 (); 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 traveling with it. One combined hash could not serve both a token that carries authority alone and an auditor that holds the task alone. Neither anchor proves the Approver understood the rendered task, nor that the AS rendered it faithfully; they commit what the AS recorded, and make post-hoc tampering of those records detectable. This profile commits the task (intent_hash) and the authority (authority_hash) the Approver consented to, but deliberately does not commit the rendered consent disclosure itself: the locale, disclosure-template version, and material notices the Approver was shown are not bound by any anchor here. Because of this gap, a buggy or malicious rendering layer could mislead the Approver, showing a narrower or different task than the Authority Set actually committed, without leaving any committed trace. A deployment whose Missions carry high-risk authority SHOULD therefore record presentation-level audit evidence: for example, a hash over the exact consent disclosure rendered to the Approver, retained so the disclosure shown can be reconstructed and audited after the fact. Binding this on the wire (a consent_rendering_hash over a structured consent-disclosure object) is specified as an OPTIONAL companion profile by Mission Consent Evidence ; 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.

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 (), 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.

Downgrade by Omission A token bearing equivalent authorization_details but no mission claim is governed by no Mission state, revocation, or consent commitment. A deployment that designates a resource Mission-governed MUST NOT issue tokens for that resource outside a Mission, except under documented policy exceptions. On the enforcement side, a Resource Server for such a resource rejects a token lacking the mission claim (), and MAY advertise the requirement through mission_bound_authorization_required ().

Prompt Injection and the Exfiltration Leg An agent that reads attacker-influenceable content can be prompt-injected; this profile assumes that and does not try to make the agent immune. Injection is dangerous when one agent combines access to private data, exposure to untrusted content, and the ability to communicate externally; the robust defense is architectural, constraining one of those, not making the model resistant. This profile constrains the data-access leg: a Mission narrows authority from everything the agent's standing credentials allow to the resources the approved task needs, and per-task Missions () shrink the blast radius further. It contributes one thing against the untrusted-content leg: purpose and success_criteria are inert, granting, widening, and gating no authority, and goal shapes authority only through the pre-approval derivation whose result the Approver reads and consents to (, ); authority is fixed at the approval event, so injected text cannot talk an approved Mission into expanding itself. This profile does not constrain the external-communication leg and provides no information-flow control. It models authority over resources and actions, not how an agent uses authority it holds: within an approved Authority Set, an injected agent can read what the Mission permits and write to a sink the Mission permits, and the flat subset and constraint model cannot express "may read secrets, may write documents, but not write secrets into documents." Constraining exfiltration by a compromised agent is the runtime enforcement layer's role (), and even there it is bounded, not closed (see that profile's security considerations). Closing within-scope data laundering needs a separate taint or information-flow layer this profile does not define.

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

• evaluate a request's parameters against the Mission at the point of use;
• produce runtime enforcement evidence for each consequential action;
• bind tool or function identities to the Mission; or
• re-evaluate at execution time to close the approval-to-execution (time-of-check to time-of-use) gap.

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

Token Theft Derived tokens are sender-constrained (DPoP or mTLS ) at the levels set in and : SHOULD for the primary access token, MUST for delegated tokens; the companion sets the same MUST for its cross-domain credentials (). A stolen token is bounded by the Authority Set and the Mission lifetime regardless, but sender-constraint prevents replay by a different party.

Delegation and Chain Compromise Delegation () 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 () 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 (), 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.

Signing and Key Rotation The mission claim and authorization_details are carried inside the 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 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.

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

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

Privacy Considerations A Mission Identifier is a correlation handle: a deployment limits exposure by giving stable Mission Identifiers only to parties that enforce, audit, or observe that Mission, preferring audience-scoped projections of authority where possible, and minimizing status and introspection disclosures to authorized callers. The subsections that follow and the introspection minimization rules () give the specific rules.

Mission Identifier Correlation This document carries a single canonical Mission Identifier on every derived token; the companion's cross-domain projection carries it across trust domains unchanged (). Any party that observes credentials for the same Mission, whether a Resource Server, a Resource AS, or an auditor spanning audiences, can correlate that activity by the Mission Identifier, and mission.issuer further identifies the issuing AS. This is intentional: a stable, correlatable Mission anchor is what lets a Resource Server, a cross-domain Resource AS, and an auditor bind credentials and evidence to one approved Mission, which the governance and audit properties of this document and its companion profiles depend on. The cost is that this profile does not provide cross-audience unlinkability, and that is a deliberate non-goal for this version (), not an unfinished feature. Audience-pairwise (or request-pairwise) Mission references, in which the issuer projects a distinct opaque identifier per audience and resolves them server-side, are the fuller mechanism for unlinkability; because they work against the stable anchor, they are future work rather than a v1 property. A deployment that carries the canonical Mission Identifier on the wire SHOULD document this correlation property.

Token Payload Disclosure The carried constraints and a multi-resource Authority Set disclose the shape of the task and its business bounds (for example, an amount ceiling) to every holder and every audience of a derived token. Per-RS single-audience tokens are the minimization measure: they carry only the entries the consuming Resource Server needs, and this document recommends them (). The privacy considerations of apply to the carried authorization_details.

IANA Considerations

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

• Name: mission_intent
• Parameter Usage Location: authorization request
• Change Controller: IETF
• Specification Document(s): this document,
• Name: mission_id
• Parameter Usage Location: token response
• Change Controller: IETF
• Specification Document(s): this document,

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

The Mission Resource Access Authorization Details Type mission_resource_access is an authorization_details type per Section 2, defined by this document in . 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.

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,

OAuth Token Introspection Response Registration This document registers the following in the "OAuth Token Introspection Response" registry ():

• Name: mission
• Description: The Mission a token was derived under. Same object shape as the mission JWT claim (); a response from the Mission's issuer additionally carries a state member giving the current lifecycle state ().
• Change Controller: IETF
• Specification Document(s): this document,

OAuth Authorization Server Metadata Registration This document registers the following in the "OAuth Authorization Server Metadata" registry ():

• 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,

OAuth Protected Resource Metadata Registration This document registers the following in the "OAuth Protected Resource Metadata" registry ():

• 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,

Common Constraints This document creates no Common Constraints registry. The Common Constraints it defines (max_amount, resource_issued_after, resource_issued_before, tenant, recipient_domain) are specified in , and a further Common Constraint is defined by specification: it fixes a name matching ^[A-Za-z0-9_.:-]+$, its JSON value syntax, its subset rule, and its intersection rule, in value-space terms (). Names are kept collision-free by the same convention the rest of this document uses: a specification-defined name is coordinated within this document family, and any other name is collision-resistant or remains deployment-defined (). Should the set of interoperable Common Constraints grow beyond what specification coordination bears, a future revision can create a "Mission Common Constraints" registry with a Specification Required policy, seeded with the entries then defined; this document does not create it.

References Normative References This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Independent OAuth deployments increasingly involve agents and workloads acting on behalf of human users across organizational boundaries. Existing specifications provide relevant building blocks (notably the act claim from RFC 8693 Token Exchange) but do not define a consistent profile for representing delegated actor relationships across JWT assertion grants (RFC 7523), JWT access tokens (RFC 9068), and Transaction Tokens, nor for classifying actor entity types or signaling support between authorization servers and resource servers. The result is inconsistent actor representation and actor- representation interoperability gaps that force deployments to rely on proprietary conventions. This document defines the OAuth Actor Profile for Delegation. It specifies a common act claim structure extended with sub_profile for entity-type classification, processing rules for authorization servers and resource servers across the three token families and their Token Exchange inputs, and OAuth discovery metadata parameters for advertising actor-profile support. The profile applies uniformly across token types and integrates with existing sender-constraint mechanisms (DPoP, mTLS). It does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject; those decisions remain deployment-specific. International Organization for Standardization In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. OpenID Foundation Model Context Protocol Project OpenID Foundation Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Tenuo This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. Amazon This specification defines a profile of OAuth 2.0 Rich Authorization Requests in Cedar policy format within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to distribute and recieve relevant Cedar policy sets in an interoperable manner. Independent This specification defines the Client Instance Assertion: a signed JWT identifying a concrete runtime instance of an OAuth 2.0 client. It registers the client_instance_assertion request parameter for carrying the assertion at the OAuth 2.0 token endpoint on the authorization_code, client_credentials, refresh_token, and JWT bearer (RFC 7523) grants; on the token-exchange grant (RFC 8693), the same assertion is presented as actor_token with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt, also registered by this specification. This specification does not introduce a new client_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses. Independent This specification profiles the OAuth 2.0 Client Instance Assertion for AI agent deployments, where a single OAuth client identifier represents an agent platform running many concurrent agent instances. It defines claims that convey an attested agent instance identifier and agent provenance (platform, model, runtime environment) from an agent attester to the authorization server, rules for surfacing that identity in issued access tokens, and delegation-chain semantics for agents that spawn sub-agents. The claims are carrier-independent: they may be conveyed in a Client Instance Assertion or in a Client Attestation defined by OAuth 2.0 Attestation-Based Client Authentication.

End-to-End Example (Non-Normative) This appendix walks one Mission from an agent through Mission creation, token issuance, and Resource Server enforcement in a single trust domain. It is illustrative and adds no normative requirements. The OAuth pieces use the rules in this document; the identity setup is by reference to . Identifiers and hash values are illustrative and are not computed from the displayed JSON. This walkthrough is the baseline issuance path: stateless enforcement bounded only by token lifetime. No stage calls back to the AS for Mission state; each party enforces from the credential it holds. Stage 3 notes where the OPTIONAL runtime layer adds a point-of-use check. Scenario: agent s6BhdRkqt3, acting for alice (user_3p2q8mN1a0kV7tR), reconciles Q3 invoices in the home ERP under Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-.

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

Stage 1: Mission Creation The agent submits this Mission Intent through PAR (): The AS (as.example.com) validates it, derives this Authority Set, and renders it for alice's consent: After approval, the AS records Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- in the active state with authority_hash sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ and intent_hash sha-256:wQ7p4LHnX9Md0LqJ6sZJ8b8mZ3rN2xT5pV4lE6sQqYY.

Stage 2: Mission-Bound Token Issuance The agent redeems the authorization code at the token endpoint. The AS resolves the Mission from the grant (), gates on it being active (), and issues a Mission-bound access token for the ERP, echoing the granted authorization_details in the token response (). The decoded token: Everything enforcement needs is in the token: the audience, the sender-constraint (cnf), the authority with its constraints, and the mission claim carrying the authority_hash consent anchor. The token is short-lived (300 s) and its exp is far below expires_at; revoking the Mission stops further derivation, and this token dies at its own expiry ().

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 (). It treats the mission claim as audit and correlation context and makes no call to the AS. This is stateless enforcement from the token alone. journal-entries.write is a consequential write, so where the deployment runs the runtime profile () it also obtains a point-of-use PDP permit against current Mission state before executing. The baseline bounds the write only by token lifetime and the carried constraints. The cross-domain continuation of this same Mission, projected to a partner ERP in another trust domain and enforced there, is walked through in the companion's end-to-end example ().

Integrity Anchor Test Vectors These non-normative vectors let an implementation verify its anchor computation (, ) byte for byte. Both use the issuer https://as.example.com. Each canonical-bytes block is the exact JCS output: a single line, UTF-8, with no whitespace outside string values. It is shown here wrapped only for layout; remove the layout line breaks, adding no characters, to recover the canonical form. Note that JCS sorts object member names (so iss precedes typ precedes value, within an entry actions precedes constraints precedes resource precedes type, and within max_amount amount precedes currency) and preserves array order. intent_hash, over this Mission Intent as the envelope value with typ mission-intent: Canonical bytes of the envelope: authority_hash, over this Authority Set as the envelope value with typ mission-authority-set: Canonical bytes of the envelope: An implementation that canonicalizes the same value under the same typ and iss, computes SHA-256, and encodes as sha-256: followed by base64url with no padding () reproduces these anchors exactly. A divergence indicates a JCS or encoding difference to resolve before interoperating.

Acknowledgments This work builds on the OAuth 2.0 Rich Authorization Requests, Pushed Authorization Requests, and JWT access token specifications, and is intended to complement agent-identity work including .