---
title: "Mission-Bound Authorization Conformance"
date: "2026-06-06T17:00:00-07:00"
lastmod: "2026-06-06T17:00:00-07:00"
description: "Substrate-neutral conformance for Mission-Bound Authorization. The Conformance Ladder describes end-to-end deployment capability. Resource Server Tiers describe request-time behavior. Compliance Tiers describe what each authorization domain delivers. The three axes are complementary and constrained."
summary: "Conformance to Mission-Bound Authorization is described along three complementary axes: the six-level Conformance Ladder, the four-tier Resource Server scale, and the three-tier Compliance scale. This post defines valid combinations and shows what each level looks like on OAuth-only, AAuth-only, and cross-substrate deployments."
slug: "mission-bound-authorization-conformance"
tags:
  - "OAuth"
  - "AAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Conformance"
  - "Internet-Draft"
series:
  - "mission-bound-authorization"
---


# Abstract

**On the spine:** Part 8 sits across the whole spine. Conformance is what a deployment claims about how much of the **Intent → Mission → Authority → Enforcement** progression it implements, on whichever substrate.

This profile defines substrate-neutral conformance contracts for Mission-Bound Authorization. The Conformance Ladder is six levels, from a credential substrate without Mission-Bound governance to full verifiable governance. Resource Server Tiers describe what an RS does at request time. Compliance Tiers describe what an authorization domain delivers. A deployment sits at a coordinate, but not every coordinate is valid: the axes are complementary and subject to the consistency rules below.

The contracts apply identically to OAuth-only deployments (per [Part 3](/notes/mission-bound-oauth-profile/)), AAuth-only deployments adopting the composition profile (per [Part 4](/notes/mission-bound-aauth/)), and cross-substrate deployments under the MAS topology (per [Part 5](/notes/mission-authority-server-profile/)). Each level is described in substrate-neutral language with explicit notes on what each substrate's wire profile contributes.

# The three axes

Conformance is not a single number. A deployment claims a coordinate on three related axes.

**Conformance 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 compiled policy plus current Resource policy.

**Compliance Tiers (1, 2, 3).** What an authorization domain (an AS, a PS, or a MAS) delivers. Tier 1 is Mission-bound issuance. Tier 2 is Mission-aware projection. Tier 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 Compliance 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.

# Conformance 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.

| Level | What it delivers | Required surfaces |
| --- | --- | --- |
| **Level 0: Substrate-only.** | No Mission-Bound governance claim. Baseline OAuth 2.0/OIDC, or native AAuth `-01` with or without its optional Mission. | Existing OAuth or AAuth deployment. |
| **Level 1: Mission-bound issuance.** | The state authority stores the governance Mission, commits approved authority and integrity anchors, issues Mission-bound credentials, and gates new derivation on Mission state. Works with RS-A audiences. | OAuth Core from [Part 3](/notes/mission-bound-oauth-profile/). AAuth native Mission plus the governance mapping, Authority Set commitment, hash separation, and lifecycle projection from [Part 4](/notes/mission-bound-aauth/). |
| **Level 2: Mission-aware projection.** | Audience-specific credentials and assertions preserve the Mission binding and remain bounded by its authority. When a second authorization domain is involved, that domain validates the projection before issuing local credentials. | Same-domain audience projection is sufficient where the deployment has one authorization domain. Multi-AS OAuth additionally uses ID-JAG and the Multi-AS validation rules. AAuth preserves native and governance references through resource/auth-token flows. Transaction Token Mission carriage remains a proposed follow-on composition. |
| **Level 3: Mission-aware Resource Server.** | Resource Servers validate Mission state and enforce audience-relevant Mission authority against each request. | Level 2 plus RS-C for every consequential Resource Server in scope and Compliance Tier 3 Mission Status or an equivalent authenticated issuer-provided view. |
| **Level 4: Full Runtime Enforcement.** | Every consequential action, including local tool calls, is evaluated against compiled Mission policy and produces decision evidence. | Level 3 plus RS-D and the Runtime Enforcement Profile Core ([Part 6](/notes/mission-bound-runtime-enforcement-profile/)): compiled policy artifact, AuthZEN evaluation, authority-expandable denial handling, and per-decision evidence. |
| **Level 5: Verifiable governance.** | Selected governance evidence is portable and independently verifiable across the claim's trust boundaries. | Level 4 plus interoperable specifications for each claimed optional capability, such as portable Decision Receipts, Tool Binding, or Attestation. The module sketches in Part 6 are a roadmap, not sufficient by themselves for a portable Level 5 claim. |

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.

## Cross-substrate notes

**OAuth-only deployments** map onto the Ladder through [Part 3](/notes/mission-bound-oauth-profile/)'s wire surfaces. The default Mission record home is the AS.

**AAuth-only deployments** map through [Part 4](/notes/mission-bound-aauth/). The Mission record home is the Person Server. Native AAuth without the composition profile remains Level 0 for this conformance scheme 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 [Part 5](/notes/mission-authority-server-profile/)'s MAS topology. The Mission record lives at the MAS; each substrate is an authorized projection issuer. Conformance Levels 1-5 apply identically; what changes is the location of the Mission record and the projection contracts each consumer satisfies.

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

| Tier | Behavior | Mission awareness |
| --- | --- | --- |
| **RS-A: Token-only.** | Validates the credential (audience, expiry, scope, signature, sender constraint). Ignores Mission state and the Mission claim. | None. Compatible with the AS-narrowed credential bounds; relies on credential issuer to enforce Mission gating at issuance time. |
| **RS-B: Mission-bound credentials.** | Reads the `mission` claim, validates that the Mission is active (per local cache, recent event, or freshness rules), refuses requests on inactive Missions. Does not evaluate per-request authority. | Reads Mission state. Does not evaluate Authority Set entries. |
| **RS-C: Authority-aware.** | Validates Mission state and enforces Authority Set entries (per-resource authority, action permits, constraints) for the audience at request time. | Reads Mission state and the audience-relevant Authority Set. |
| **RS-D: PDP-evaluated.** | Consults a PDP for every consequential request. PDP evaluates the request against the Mission's compiled policy plus current Resource policy. Per-decision evidence is recorded. | Full Runtime Enforcement contract per [Part 6](/notes/mission-bound-runtime-enforcement-profile/). |

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. Its claim MUST name the scope. An organization can claim 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 claim Level 4 for the whole deployment if consequential in-scope actions bypass RS-D.

# Compliance Tiers

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

| Tier | What the domain delivers | Mapping onto Ladder |
| --- | --- | --- |
| **Compliance Tier 1: Mission-bound issuance.** | Accepts Mission Intent, validates and stores a Mission, issues Mission-bound credentials, gates derivation on Mission state, exposes a Mission inventory and lifecycle operations. | Required for Ladder Level 1+. |
| **Compliance Tier 2: Mission-aware projection.** | Plus: issues audience-specific Mission-bound credentials or assertions. When projection crosses an authorization-domain boundary, the receiving domain validates the binding before issuing local credentials. | Required for Ladder Level 2+. |
| **Compliance Tier 3: Authority-aware projection plus Mission Status.** | Plus: exposes authenticated Mission Status (state, integrity hashes, audience-filtered Authority Set projection, and `policy_version` when Runtime Enforcement is enabled) for Resource Servers and PDPs. When the state authority also issued the credential, an authenticated issuer endpoint may combine this view with credential introspection; otherwise the services remain separate. | Required for Ladder Level 3+. |

A deployment claims one Compliance Tier per authorization domain. In a MAS topology, the MAS claims its governance Compliance Tier; each consuming AS or PS separately claims 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 ([Part 6](/notes/mission-bound-runtime-enforcement-profile/)) requires Compliance Tier 3 at the state authority plus RS-D Resource Servers; it does not introduce a separate Compliance Tier 4.

# The coordinate, not the score

A deployment's conformance claim is a coordinate, not a single number. Examples:

- **"Level 1 / RS-A / Compliance Tier 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 / Compliance Tier 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 / Compliance Tier 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 / Compliance Tier 3 plus interoperable optional-capability specifications"**: Portable cryptographic receipts, tool-manifest signatures, attestation, or another independently verifiable capability. Cross-organizational governance.

## Worked Conformance Claim: the board-packet deployment

To make the coordinate concrete, walk the [board-packet Mission](/notes/the-mission-is-the-missing-abstraction/#a-concrete-mission-record) (`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 / Compliance Tier 1"):** The AS adopts [Part 3 Core](/notes/mission-bound-oauth-profile/) — accepts `mission_intent` at PAR, stores the Mission record for `msn_01J9Z2P8...` with `proposal_hash` / `authority_hash` / `consent_rendering_hash`, derives `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 / Compliance Tier 3"):** The document RS now reads the `mission` claim, validates Mission state through authenticated introspection (Compliance Tier 3 at the AS), and enforces audience-relevant `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 / Compliance Tier 3" within scope):** [Runtime Enforcement Profile Core](/notes/mission-bound-runtime-enforcement-profile/) 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 compiled policy view, `policy_version`, and the [Common Constraints Catalog](/notes/mission-bound-oauth-extensions/#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 never claims a single "Level X" sticker. It claims a coordinate, names the scope, and reports the levers 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.

# Conformance advertisement

A state authority SHOULD advertise its conformance claim through metadata. The proposed surface (under future work in this series):

- `mission_compliance_tiers_supported`: subset of `[1, 2, 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 [Part 6](/notes/mission-bound-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 [Part 5](/notes/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 conformance goal

If your deployment goal is...

- **"Bind tokens to a Mission and revoke as one"**: target Ladder Level 1, Compliance Tier 1. Read [Part 3](/notes/mission-bound-oauth-profile/) (OAuth) or [Part 4](/notes/mission-bound-aauth/) (AAuth) plus this post.
- **"Project one Mission across multiple authorization domains"**: target at least Ladder Level 2 and Compliance Tier 2 in each participating issuer domain. Add [Part 5](/notes/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 [Parts 3](/notes/mission-bound-oauth-profile/), [4](/notes/mission-bound-aauth/), and [5](/notes/mission-authority-server-profile/).
- **"Every consequential action evaluated through a PDP"**: target Ladder Level 4, RS-D. Add [Part 6](/notes/mission-bound-runtime-enforcement-profile/) Core.
- **"Portable third-party-verifiable governance"**: target Ladder Level 5. Add an interoperable specification for each claimed Part 6 optional capability, such as Decision Receipt, Tool Binding, or Attestation. The sketches in Part 6 are not sufficient alone.

# Gaps and open issues

This profile defines the conformance coordinates. Several follow-on questions remain.

- **Conformance 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, the conformance claim is the minimum tier. Should there be a richer per-RS conformance signal, perhaps inline 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.
- **Conformance testing.** A reference test suite that exercises each Level and Tier would let deployments validate their claims. Companion work.

# Standards Ask

Standardize as part of `draft-mcguinness-mission-bound-authorization-conformance`:

- The six-level Conformance Ladder.
- The four Resource Server Tiers.
- The three Compliance Tiers.
- Conformance 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: each authorization domain's compliance is described in this post but specified in its substrate profile.

# References

- [Part 1: The Mission is the Missing Abstraction for Agents](/notes/the-mission-is-the-missing-abstraction/)
- [Part 2: Mission Shaper Profile](/notes/mission-shaper-profile/)
- [Part 3: Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/)
- [Part 4: Mission-Bound AAuth Composition Profile](/notes/mission-bound-aauth/)
- [Part 5: Mission Authority Server Profile](/notes/mission-authority-server-profile/)
- [Part 6: Mission-Bound Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/)
- [Part 7: Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls/)