Overview

This post defines a substrate-neutral capability and adoption model for Mission-Bound Authorization. Capability is not a single number. A deployment reports a coordinate on three related axes: the Capability Ladder (Levels 0-5) describes maturity of governance and enforcement, Resource Server Tiers (RS-A through RS-D) describe what a Resource Server does with a Mission-bound credential, and Authorization Domain Tiers (AD-1 through AD-3) describe what an authorization domain delivers to its consumers.

Three named adoption claims sit atop the coordinate model and serve as the headline conformance signal. A deployment conforms to the applicable substrate or runtime profile through that profile’s testable requirements; a level or tier in this document is a capability description, not an independent interoperability or certification claim. The sections below name the three adoption claims, define the three axes, walk a deployment through climbing the ladder, and close with the minimum profile excerpt and gaps.

Three adoption claims

Before the coordinate model, three named adoption claims serve as the headline conformance signal a deployment, vendor, or working group can rally around. Each claim has a clear yes-or-no answer at audit time and maps directly to coordinates on the three axes below.

1. Mission-Bound Issuance. The state authority records an Approved Mission with integrity anchors, issues Mission-bound credentials, and gates credential derivation (refresh, exchange, substrate-native re-derivation) on Mission state. Resource Servers may remain unchanged. Maps to: Capability Ladder Level 1, Resource Server Tier A, Authorization Domain Tier 1; substrate-local Mission record.
2. Mission-Bound Runtime Enforcement. Within a deployment-named enforcement scope, every consequential action is evaluated by a PDP against the Mission’s versioned policy view, the audience-relevant Authority Set projection, authenticated actor context, and current Resource policy, producing a Runtime Evidence record. Maps to: Capability Ladder Level 4, Resource Server Tier D, Authorization Domain Tier 3; Runtime Enforcement Profile Core.
3. Mission-Bound Cross-Domain Projection. A canonical Mission record is consumed by more than one authorization domain (OAuth Authorization Server, AAuth Person Server, or both), each consuming domain validates the projection before issuing local credentials, and revocation at the canonical record demonstrably terminates derivation across every consuming domain. Maps to: Capability Ladder Levels 2 and above with the MAS topology or an equivalent multi-domain validation rule; cross-substrate Authority Set serialization.

The three claims are independent in principle: a deployment can ship Cross-Domain Projection without Runtime Enforcement, or Runtime Enforcement without Cross-Domain Projection. In practice they climb together, since each new claim adds enforcement points and authorization domains that the Authority Set has to remain coherent across. The Capability Ladder and the Resource Server and Authorization Domain Tiers below remain the detailed maturity description; the three claims are what a deployment names when describing itself in one sentence.

The three axes

Capability is not a single number. A deployment reports a coordinate on three related axes.

Capability Ladder (Levels 0-5). Maturity of governance and enforcement. Level 0 is substrate-native credential issuance without a Mission-Bound governance claim. Level 5 is verifiable governance with portable evidence.

Resource Server Tiers (RS-A through RS-D). What a Resource Server does with a Mission-bound credential when it sees one. RS-A validates the credential and ignores the Mission. RS-D evaluates each consequential request through a PDP against the Mission’s versioned policy view plus current Resource policy.

Authorization Domain Tiers (AD-1, AD-2, AD-3). What an authorization domain (an AS, a PS, or a MAS) delivers. AD-1 is Mission-bound issuance. AD-2 is Mission-aware projection. AD-3 adds authenticated Mission Status and audience-filtered authority for enforcement.

Three axes are useful because they answer different questions. The Ladder describes how much of the spine the deployment implements end to end. The RS Tiers describe what each Resource Server does at request time. The Authorization Domain Tiers describe what the authorization domain offers issuers and consumers. The coordinate preserves detail that one score would hide, while consistency rules prevent contradictory claims such as Level 4 with only RS-A Resource Servers.

Capability Ladder

Mission-Bound Authorization is designed for incremental adoption. A deployment sits at any of these levels and gains value; higher levels add capability without invalidating lower ones.

Not every deployment must implement Level 5 on day one. Level 1 gets Mission-bound issuance and lifecycle control immediately. Higher levels are opt-in maturity.

Level 4 scope is explicit, not implied. A Level 4 claim is valid only for the consequential action classes and Resource Servers whose execution paths are actually mediated by an RS-D or runtime-PEP enforcement boundary. The deployment’s Level 4 claim MUST name those action classes and resources. Action paths the deployment cannot stop (debug shells, unsanctioned egress routes, direct database connectors outside an RS-D Resource Server, agent-side tool invocations not gated by an orchestrator PEP) fall outside the claim regardless of how comprehensive the rest of the runtime story is.

The Ladder is not a universal OAuth maturity model. Level 0, substrate-only without a Mission-Bound governance claim, is a perfectly correct destination for any OAuth or AAuth deployment that does not need Mission-layer governance. Single-call user-driven web flows, machine-to-machine service credentials, short-lived consumer authorizations where the credential lifetime is the task lifetime, and any non-agentic deployment without a cross-hop audit requirement should stay at Level 0. The Ladder measures progress for deployments that have chosen to adopt Mission-Bound governance. It does not imply that every OAuth deployment is behind, or that every deployment should climb. The right level for a deployment depends on whether it has the user-approved durable task that the Mission layer exists to govern.

Cross-substrate notes

OAuth-only deployments map onto the Ladder through the Mission-Bound OAuth Profile’s wire surfaces. The default Mission record home is the AS.

AAuth-only deployments map through the Mission-Bound AAuth Composition Profile. The Mission record home is the Person Server. Native AAuth without the composition profile remains Level 0 in this capability model even though it has its own useful Mission. Level 1 adds the Mission-Bound governance mapping, Authority Set commitment, integrity hashes, and lifecycle projection.

Cross-substrate deployments add the Mission Authority Server Profile’s MAS topology. The Mission record lives at the MAS; each substrate is an authorized projection issuer. Capability Levels 1-5 describe the same governance outcomes, but the protocol obligations are not identical: each substrate satisfies its own adapter and projection contract.

What a Level-1 deployment looks like

Concretely, a deployment that ships only Level 1:

• The state authority (OAuth AS, composing AAuth PS, or MAS) admits a substrate-appropriate proposal, validates it against requester bounds and policy, renders the validated intent and authority for consent, and stores an Approved Mission with proposal_hash, authority_hash, and consent_rendering_hash.
• The state authority commits authorization_details (OAuth) or the applicable AAuth Authority Set projection.
• Issued credentials carry the substrate-native Mission reference and are sender-constrained with DPoP, mTLS, or substrate-native proof of possession. OAuth uses mission.id and mission.origin; AAuth preserves (approver, s256) and the composition mapping.
• Refresh, Token Exchange (OAuth), or AAuth credential derivation check Mission state before issuing new authority; non-active Missions cause issuer-defined inactive-Mission signaling.
• Existing Resource Servers (RS-A) continue accepting ordinary OAuth tokens or AAuth credentials unmodified.
• The state authority exposes a Mission inventory and lifecycle operations (revoke, suspend, resume, complete by mission.id) to users and admins.
• Audit records are keyed on the Mission and its integrity anchors.

What a Level-1 deployment does not require:

• At the Resource Server. Reading the mission claim, validating Mission state, evaluating Authority Set entries, consulting a PDP, or listening for Shared Signals or CAEP events on Mission lifecycle. RS-A is the credential-only floor; existing Resource Servers need no changes.
• At the state authority, OAuth substrate. Cross-AS ID-JAG, Mission Expansion wire mechanics, the Common Constraints Catalog, Delegated Authority Validation, Concurrent Expansion reconciliation, Same-IdP Chain Continuation Assertions, Transaction Token Chaining, Capability Source Binding, or any Runtime Enforcement Profile surface. All of these belong in the OAuth Extensions companion or the Runtime Enforcement Profile.
• At the state authority, AAuth substrate. A suspended lifecycle state is optional; the Resumable Suspension composition extension is deferred to extension profiles. The native AAuth two-state lifecycle plus the governance-mapped pending_approval → active → (revoked | completed | expired) transitions are sufficient.
• Cross-substrate. The MAS topology, cross-substrate Authority Set serialization, audience-filtered authority projection (AD-3), and verifiable governance evidence (Level 5). All belong at Level 2 or higher.
• At the protocol surface. A Mission Status endpoint, expansion handles, or access-request submission. Clients fail-and-restart when a Mission becomes inactive at Level 1.

What that buys a deployment on day one:

• One user approval can derive many resource-specific credentials; revocation at the state authority terminates future derivation across every audience.
• Refresh and exchange become governable. A long-running agent cannot refresh past a Mission that the user revoked.
• Audit reconstruction across audiences is a Mission-binding join, not log stitching by timestamp.
• The user has a place to see and stop in-flight Missions independent of credential expiry.

Resource Server Tiers

Resource Server tiers describe what an RS does with a Mission-bound credential at request time. They are reported per Resource Server. The deployment’s Ladder claim is bounded by the minimum tier among consequential Resource Servers included in that claim.

Ladder requirements at each level:

• Level 1: RS-A is sufficient (the Ladder’s enforcement at this level is at the credential-issuance gate, not at the RS).
• Level 2: RS-A is still permitted; projection correctness is primarily an issuer and authorization-domain property.
• Level 3: RS-C minimum for every consequential Resource Server in scope.
• Level 4: RS-D for every consequential Resource Server and local-action enforcement point in scope.
• Level 5: RS-D plus interoperable specifications for each claimed verifiable-governance capability.

A deployment with mixed-tier Resource Servers (some RS-A, some RS-D) is normal. Any reported coordinate must name its scope. An organization can report Level 4 for a bounded agent platform whose consequential actions all pass through RS-D while separately reporting legacy RS-A resources outside that scope. It cannot report Level 4 for the whole deployment if consequential in-scope actions bypass RS-D.

Authorization Domain Tiers

Authorization Domain Tiers describe what an authorization domain (the AS, the PS, or the MAS) delivers to its clients, downstream domains, and Resource Servers. The three tiers map roughly onto the Ladder but are described from the issuer’s perspective rather than the deployment’s.

A deployment reports one Authorization Domain Tier per authorization domain. In a MAS topology, the MAS reports its governance tier; each consuming AS or PS separately reports the projection behavior it implements. ASes and PSes are credential issuers, not Resource Servers, so their responsibilities cannot be described only by an RS tier.

The Runtime Enforcement Profile requires AD-3 at the state authority plus RS-D Resource Servers; it does not introduce a separate Authorization Domain Tier 4.

The coordinate, not the score

A deployment’s capability description is a coordinate, not a single number. Examples:

• “Level 1 / RS-A / AD-1”: An AS issues Mission-bound credentials, but Resource Servers ignore the Mission. The deployment gets the governance layer (revocation, audit, inventory) without per-request enforcement. Most v1 deployments.
• “Level 3 / RS-C / AD-3”: Resource Servers enforce Authority Set entries and Mission state; the state authority exposes Mission Status. No PDP. Strong default for production deployments without Runtime Enforcement.
• “Level 4 / RS-D / AD-3”: PDPs evaluate each consequential request. Decision evidence recorded. Full Runtime Enforcement. The point at which the deployment becomes Intent-Based Access Control.
• “Level 5 / RS-D / AD-3 plus interoperable optional-capability specifications”: Portable cryptographic receipts, verifiable capability-source bindings, attestation, or another independently verifiable capability. Cross-organizational governance.

Worked Capability Snapshot: the board-packet deployment

To make the coordinate concrete, walk the board-packet Mission (msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1) through what each tier looks like in deployment.

Suppose Example Corp runs an internal agent platform with one OAuth AS, three first-party Resource Servers (document, finance, workflow), and a planned MCP integration with a fourth-party signing service. Two snapshots over time:

Day 1 (“Level 1 / mixed RS / AD-1”): The AS adopts the OAuth Profile Core: accepts mission_intent at PAR, stores the Mission record for msn_01J9Z2P8... with proposal_hash / authority_hash / consent_rendering_hash, derives mission_resource_access entries for the three first-party RSes, issues tokens carrying the mission claim, and gates refresh on Mission state. Resource Servers are unchanged (RS-A). Mission revocation at the AS terminates future derivation; in-flight tokens drain at their TTL. The deployment gets revocation, audit join on mission.id, and a user-visible inventory immediately, without changing any RS code.

Day 90 (“Level 3 / RS-C / AD-3”): The document RS now reads the mission claim, validates Mission state through authenticated introspection (AD-3 at the AS), and enforces audience-relevant mission_resource_access entries (including the folder: board-materials constraint) on every request. The finance and workflow RSes have moved to RS-C as well. The signing service stays at RS-A under a cross-AS ID-JAG; the deployment’s Level 3 claim is scoped to the in-house RSes per the mixed-tier-scope rule above. The state authority exposes Mission Status with policy_version for the soon-to-arrive Runtime Enforcement step.

Day 180 (“Level 4 / RS-D / AD-3” within scope): Runtime Enforcement Profile Core is adopted at the document and workflow RSes. Every documents.write and notify_reviewer call passes through a PDP that evaluates the request against the Mission’s versioned policy view, policy_version, and the Common Constraints Catalog bounds (max_calls on workflow notifications, data_classification: confidential on document writes). Decision evidence is written per consequential action. The finance RS still operates at RS-C; the deployment’s Level 4 claim names the consequential-action scope (document writes, workflow notifications) and reports finance reads under the broader Level 3 RS-C posture.

The deployment does not rely on a single “Level X” label. It reports a coordinate, names the scope, identifies the profile versions it implements, and reports the capabilities it has not yet adopted. Each Mission (msn_01J9Z2P8... and its successors) is enforceable under the same coordinate; the audit chain joins decisions across tiers through the Mission binding.

Excerpting a minimum profile

The capability model is intentionally rich because it must describe deployments across substrates and across maturity. A standards-track minimum profile does not need to ship the full model on day one. The minimum self-contained capability coordinate is:

Capability Ladder Level 1, Resource Server Tier A, Authorization Domain Tier 1 (short: L1 / RS-A / AD-1).

This coordinate is the smallest deployable Mission-Bound Authorization claim. It delivers Mission-bound issuance, revocation, audit binding, and lifecycle control without requiring changes to existing Resource Servers and without requiring runtime enforcement. The required surfaces and the deferred surfaces are listed in What a Level-1 deployment looks like above; the normative requirements live in the Mission-Bound OAuth Profile (OAuth substrate) and the Mission-Bound AAuth Composition Profile (AAuth substrate).

A minimum-profile Internet-Draft can specify only the surfaces required by this coordinate and defer the higher-level surfaces to extension profiles. Specifically, the minimum profile excerpts:

• One substrate per minimum-profile I-D. OAuth-only or AAuth-only. The MAS topology and cross-substrate Authority Set serialization belong in a separate cross-substrate-governance extension profile.
• Authorization Domain Tier 1 only. Mission-bound issuance and lifecycle operations. A Mission Status endpoint and audience-filtered authority projection (AD-3) are deferred to the runtime-enforcement extension profile.
• Resource Server Tier A only. No Mission-aware Resource Server behavior. The mission claim is informational at this tier; RS-A implementations need no changes.
• Mission lifecycle: minimum required transitions. pending_approval → active → (revoked | completed | expired). Suspension and the resumption signal sketched for AAuth in the AAuth Composition Profile are deferred to extension profiles.

Higher capabilities then ship as separate extension profiles that normatively reference the minimum profile: a Resource Server Awareness profile (RS-B and RS-C), a Multi-Domain Projection profile (AD-2, ID-JAG, MAS topology), and a Runtime Enforcement profile (RS-D, AD-3 Mission Status, PEP placement, Runtime Evidence Object). The Capability Ladder remains the common vocabulary across all of them.

This is publication sequencing, not architectural retreat. The minimum profile is what an implementer needs to claim a non-trivial Mission-Bound Authorization deployment without buying into runtime enforcement or cross-substrate governance on day one. Each extension profile adds capability against the same governance vocabulary defined here.

Capability Advertisement

A state authority may advertise capabilities through metadata. The proposed surface is future work and is not itself a conformance signal:

• mission_authorization_domain_tiers_supported: subset of ["AD-1", "AD-2", "AD-3"].
• mission_ladder_levels_supported: subset of [1, 2, 3, 4, 5].
• mission_profiles_supported: subset of ["oauth", "aauth", "runtime_enforcement", "mas"] matching the substrate profiles this domain implements.
• mission_optional_modules_supported: subset of ["tool_binding", "decision_receipt", "purpose_registry", "actor_provenance", "attestation", "policy_projection"] per the Runtime Enforcement Profile.

The metadata location is substrate-specific: OAuth uses the AS metadata document, AAuth uses the PS metadata document, MAS uses its own metadata document defined in the Mission Authority Server Profile.

Resource Server tier and PDP capability are advertised by the Resource Server through PRM (OAuth) or AAuth Resource metadata. The exact field names are out of scope here; the principle is that a client or upstream consumer can discover what the Resource Server actually does with a Mission-bound credential before invoking it.

Reading Paths by Capability Goal

If your deployment goal is…

• “Bind tokens to a Mission and revoke as one”: target Ladder Level 1, AD-1. Read the Mission-Bound OAuth Profile (OAuth) or the Mission-Bound AAuth Composition Profile (AAuth) plus this post.
• “Project one Mission across multiple authorization domains”: target at least Ladder Level 2 and AD-2 in each participating issuer domain. Add the Mission Authority Server Profile if the domains need one shared Mission record.
• “Resource Servers evaluate approved bounds at request time”: target Ladder Level 3, RS-C. Add the audience-relevant Authority Set projection contracts from the OAuth Profile, AAuth Composition Profile, and Mission Authority Server Profile.
• “Every consequential action evaluated through a PDP”: target Ladder Level 4, RS-D. Add the Runtime Enforcement Profile Core.
• “Portable third-party-verifiable governance”: target Ladder Level 5. Add an interoperable specification for each claimed Runtime Enforcement Profile optional capability, such as Decision Receipt, Tool Binding, or Attestation. The sketches in the Runtime Enforcement Profile are not sufficient alone.

Gaps and open issues

This post defines the capability coordinates. Several follow-on questions remain.

• Capability advertisement standardization. Field names, namespaces, and IANA registration. The current proposal is a set of names; standardization is future work.
• Mixed-tier Resource Server reporting. When a deployment has some RS-A and some RS-D Resource Servers, a deployment-wide summary hides important scope. A richer per-RS capability signal may belong in PRM responses.
• Cross-substrate claim serialization. The coordinate model requires a MAS governance claim plus a projection claim for each OAuth AS or AAuth PS in scope. A future metadata format needs to serialize those per-domain claims without collapsing them into one misleading deployment-wide tier.
• Profile testing. Reference suites should test the normative OAuth, AAuth, MAS, Shaper, and Runtime profiles. Capability levels can then be derived from the successfully tested profile surfaces.

Standards Ask

Standardize as part of a Mission-Bound Authorization capability-model document:

• The six-level Capability Ladder.
• The four Resource Server Tiers.
• The three Authorization Domain Tiers.
• Capability-advertisement metadata names (separate from substrate-specific metadata).
• The mapping rules from OAuth, AAuth, and MAS profiles onto each Ladder Level.

Compose with the substrate-specific posts: this document supplies common vocabulary, while conformance is specified and tested in each substrate profile.

References

• The Mission is the Missing Abstraction for Agents
• Mission Shaper Profile
• Mission-Bound OAuth Profile
• Mission-Bound AAuth Composition Profile
• Mission Authority Server Profile
• Mission-Bound Runtime Enforcement Profile
• Least-Privilege MCP Tool Calls Need a Mission