--- title: "Mission Authority Server Profile" date: "2026-06-06T14:00:00-07:00" lastmod: "2026-06-06T14:00:00-07:00" description: "A deployment-topology profile that moves the Mission record from a substrate-local server to a dedicated Mission Authority Server. OAuth, AAuth, and future substrates can then project from one governance object." summary: "The default OAuth topology places the Mission record at the Authorization Server. This profile defines a dedicated Mission Authority Server as the state authority. OAuth ASes and AAuth Person Servers become authorized projection issuers. The MAS binds the subject, consent disclosure, canonical Authority Set, lifecycle, and pairwise Mission identifiers. Credential issuers remain responsible for credential validity; the MAS supplies Mission Status." slug: "mission-authority-server-profile" tags: - "OAuth" - "AAuth" - "Authorization" - "Agentic Identity" - "Mission-Bound Authorization" - "Mission Authority Server" - "Internet-Draft" series: - "mission-bound-authorization" --- # Abstract **On the spine:** Part 5 decouples the **Mission** step from any single authorization substrate so OAuth ASes and AAuth Person Servers can share one governance record. It also defines the Authority step's substrate-neutral container, the **Authority Set**. Intent shaping and runtime enforcement remain separate concerns. The [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/) places the Mission record at the Authorization Server by default. That is the simplest deployment topology, but it combines two roles: issuing OAuth credentials and governing the user-approved task those credentials serve. This profile separates them. A **Mission Authority Server (MAS)** becomes the Mission state authority. OAuth Authorization Servers and [AAuth Person Servers](/notes/mission-bound-aauth/) become authorized projection issuers. Credential issuers continue to validate or introspect the credentials they mint. Resource ASes query the MAS for Mission lifecycle and audience-relevant authority. `mission.origin` identifies the MAS. The topology preserves the semantics of `proposal_hash`, `authority_hash`, `consent_rendering_hash`, and the Mission lifecycle. It does not preserve every substrate-specific wire shape. A cross-substrate MAS commits a canonical **Authority Set** and returns substrate- and audience-specific projections to authorized consumers. The result is one Mission, many substrates. A deployment that adopts both OAuth and AAuth surfaces can run them under a single governance object instead of two parallel ones. # Introduction The [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/) puts the Mission record at the OAuth Authorization Server by default; [Mission-Bound AAuth](/notes/mission-bound-aauth/) puts it at the Person Server. Both are pragmatic substrate-local choices. Neither provides one canonical Mission across OAuth and AAuth, multiple ASes inside one trust domain, or a governance service distinct from every credential issuer. > The Mission record's location is a deployment choice, not a structural one. Once the Mission is a typed object on the wire, it does not have to live anywhere in particular. Three pressures push toward separating the roles: 1. **Multi-AS deployments.** When a tenant has multiple OAuth ASes (federation, microservices, B2B), each AS either hosts local Mission records or proxies through a chosen state authority. A dedicated MAS makes that shared role explicit. 2. **Substrate independence.** [AAuth](/notes/mission-bound-aauth/) has its own native Mission and Person Server flow. Two substrate-local Missions for one task means two governance objects to correlate. One MAS projects to both. 3. **Organizational reality.** IAM teams run authorization servers. GRC teams own policy, consent UX, and audit. The MAS pattern matches that split: the AS team operates the AS, the GRC team operates the MAS, and the Mission record lives where governance lives. Single-substrate deployments do not need a MAS. This series uses the MAS topology when OAuth and AAuth must share one canonical governance Mission. ## Protocol Status This post defines the architectural contract and a proposed wire shape. The role boundaries, trust rules, integrity semantics, and separation of credential validation from Mission Status are the stable core. Endpoint names, metadata members, request bodies, and the well-known suffix remain proposal-level until fixed by an Internet-Draft and registry actions. Normative keywords below describe the target profile, not an already-published standard. # Design Goals The profile has five goals: - Defines the Mission Authority Server as a distinct deployment role with its own metadata, endpoints, and trust framework. - Preserves the Mission reference, integrity-anchor semantics, and lifecycle while defining the projection rules needed when consumers use different credential substrates. - Specifies how the OAuth Authorization Server consumes MAS state without changing the client-AS contract from the OAuth Profile. - Specifies how the [AAuth Person Server](/notes/mission-bound-aauth/) consumes MAS state as a parallel substrate. - Provides a role contract that future substrates can adopt without defining their carriage here. This profile does not: - Define cross-MAS federation. A Mission lives at one MAS for its lifetime. Two MASes managing the same Mission is out of scope for v1. - Define a Mission Receipt format. Receipts compose at the MAS as they would at an AS; that work belongs in a separate profile. - Re-specify Mission Intent or the lifecycle states. It defines only the Authority Set and consent-disclosure contracts needed by a substrate-independent state authority. - Change the [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/) contract. The PDP consumes Mission state the same way; the MAS is just where state lives. # The Mission Authority Server The Mission Authority Server is the durable home of the Mission record. It: - **Receives Mission Intent submissions** from trusted consumers (OAuth ASes, AAuth Person Servers, and future substrates). - **Validates Mission Intent** against MAS-managed client registration and deployment policy. - **Binds the subject** from authenticated identity evidence and maintains the necessary consumer- and substrate-specific mappings. - **Derives the candidate Authority Set before consent.** The disclosure contains the validated Mission Intent and the complete maximum authority the user is being asked to approve. - **Produces the canonical consent disclosure.** The MAS MAY delegate presentation to a consumer, but the MAS generates and integrity-protects the structured content. - **Activates the Approved Mission** after consent and computes `proposal_hash`, `authority_hash`, and `consent_rendering_hash`. - **Authorizes projection issuers.** The Mission record identifies which OAuth ASes, AAuth Person Servers, or other consumers may issue credentials for each projection. - **Maintains lifecycle state** for the Mission's lifetime. - **Answers Mission Status** for authorized consumers and Resource ASes. - **Emits lifecycle events** through SSF/CAEP. - **Exposes lifecycle operations** to authorized users and administrators. The MAS does not mint OAuth access tokens, refresh tokens, ID-JAGs, or AAuth auth tokens. Credential issuance and introspection remain with the relevant substrate. The MAS governs the Mission; authorized consumers issue native credentials only while MAS state and policy permit. # Architecture ## Conceptual Model ```mermaid flowchart TB User([User]) Orchestrator([Orchestrator]) MAS([Mission Authority Server]) Mission[("Mission record
state, proposal_hash,
authority_hash, consent_rendering_hash")] AS([OAuth Authorization Server]) PS([AAuth Person Server]) OAuthToken[Mission-bound access token
+ mission claim] AAuthCred[AAuth resource/auth token
+ Mission projection] RAS([Resource AS]) LocalToken[Local access token
+ mission claim] RS([Resource Server]) Auditor([Auditor / Governance]) User -->|goal| Orchestrator Orchestrator -->|OAuth path:
Mission Intent via PAR| AS Orchestrator -->|AAuth path:
native Mission proposal| PS AS -->|submit and gate on state| MAS PS -->|submit and gate on state| MAS User -->|consent on canonical disclosure| MAS MAS -->|owns| Mission AS -->|mints| OAuthToken PS -->|issues or brokers| AAuthCred OAuthToken -->|same-audience| RS OAuthToken -->|cross-audience| RAS RAS -->|query Mission Status| MAS RAS -->|issues| LocalToken LocalToken --> RS Auditor -->|status, events| MAS ``` Reading the diagram: - The OAuth AS and AAuth PS are alternative or parallel consumers of MAS state. Neither owns the governance Mission; both gate native issuance on it. - The Mission record lives at the MAS for its lifetime. `mission.origin` identifies the MAS, not the consuming substrate. - Mission-bound credentials preserve a substrate-native Mission reference and an authenticated governance projection. OAuth carries `mission.id` and `mission.origin`; AAuth preserves `(approver, s256)` and resolves its MAS mapping. - Resource ASes validate credential status with the credential issuer and follow `mission.origin` for Mission Status. - Auditors and governance teams consume canonical lifecycle state at the MAS. They still correlate credential and execution evidence, but they no longer have to infer whether AS and PS records refer to the same Mission. ## Roles This profile adds one role and refines two existing roles: - **Mission Authority Server (MAS).** Owns the Mission record, subject mapping, canonical Authority Set, consent disclosure, lifecycle, projection-issuer authorization, events, and Mission Status. - **OAuth Authorization Server (AS).** Receives `mission_intent` at PAR, forwards the governance request to the MAS, issues Mission-bound OAuth credentials, and gates issuance, refresh, exchange, and derivation on MAS state. It remains the credential issuer but is no longer the Mission state authority. - **AAuth Person Server (PS).** Receives AAuth's native Mission proposal, coordinates its governance mapping with the MAS, issues PS-asserted auth tokens or brokers federated auth tokens, and gates governed operations on MAS state. The orchestrator, Resource AS, and Resource Server retain their existing protocol roles. Their source of Mission state changes from a substrate-local server to `mission.origin`. ## Trust Boundaries Four trust relationships are added or sharpened: 1. **AS-to-MAS trust.** The AS authenticates to the MAS and is authorized to submit Mission Intent on behalf of registered clients. This is a backend trust relationship; it does not appear on the client-AS wire. 2. **PS-to-MAS trust.** Same shape, parallel substrate. 3. **Resource-AS-to-MAS trust.** Resource ASes that query `mission.origin` must trust the MAS and verify that the credential issuer was authorized to project the referenced Mission. 4. **Subject-to-MAS binding.** The MAS accepts a subject only with identity evidence it can validate or through a consumer explicitly trusted to perform subject binding. A bare subject string is not proof. The MAS becomes the Mission-state trust anchor. It does not replace trust in credential issuers: relying parties must validate both the credential issuer and the state authority. # Canonical Governance Objects Moving Mission state outside a credential substrate requires two canonical objects: the Authority Set and the consent disclosure. ## Authority Set The **Authority Set** is the maximum typed authority approved for the Mission. In a cross-substrate or MAS deployment, it is a JCS-canonical JSON object: ```json { "version": 1, "entries": [ { "substrate": "oauth", "type": "resource_access", "authority": { "resource": "https://finance.example.com", "actions": ["financials.read"], "constraints": { "period": "2026-Q3" } } }, { "substrate": "aauth", "type": "aauth_scope", "authority": { "resource": "https://workflow.example", "scope": ["notification.send"] } } ] } ``` The MAS computes `authority_hash` over the JCS-canonical Authority Set. Entries are deterministically ordered by substrate, type, resource identifier, and canonical entry bytes. Each type owner defines subset and narrowing semantics. Consumers receive only entries relevant to their substrate, tenant, and audience. Unknown entry types may pass only to a known consumer that is required to understand and enforce them. Otherwise the MAS refuses derivation; consumers must not silently reinterpret or drop unknown authority. An OAuth-only deployment without a MAS may continue to hash its deterministic `authorization_details` array directly. A MAS deployment uses the generic Authority Set even when OAuth is its only current consumer, preserving a stable commitment domain as additional substrates are added. ## Consent Disclosure The canonical consent disclosure contains: - the validated Mission Intent; - the complete candidate Authority Set; - locale and disclosure-template version; and - material notices required by deployment policy. The MAS computes `consent_rendering_hash` over the JCS-canonical disclosure object. The integrity semantics match the OAuth Profile's: the hash identifies the structured content the state authority says was presented and does not prove that a compromised renderer displayed that content honestly (see [Part 3's Integrity Anchors](/notes/mission-bound-oauth-profile/#integrity-anchors)). Any material change to Mission Intent, authority, or notices after disclosure requires a new disclosure and approval. # Wire Interop Requirements The OAuth and AAuth composition profiles retain their native credential rules. The MAS topology adds these cross-substrate requirements: - `mission.origin` MUST identify the MAS issuer URI. Consumers resolve Mission Status and SSF transmitter metadata from MAS discovery. - A consuming AS or PS MUST NOT issue a Mission-bound credential whose `mission.origin` differs from the MAS that authoritatively manages the Mission. - A credential issuer remains responsible for validating or introspecting credentials it issued. Mission-state queries go to `mission.origin`; an issuer MAY include fresh, clearly attributed MAS-derived state in its own authenticated response. - Mission state events SHOULD originate from the MAS. Consumers MAY republish events into substrate-specific streams (an AS that publishes a Mission-revoked event to its existing SSF feed, for instance) but the authoritative event is the one from the MAS. - `proposal_hash`, `authority_hash`, and `consent_rendering_hash` MUST be computed by the MAS over their canonical objects. `authority_hash` commits the generic Authority Set, not an OAuth-only `authorization_details` array. - A consumer MUST NOT issue a Mission-bound credential unless fresh Mission Status or a MAS-signed projection assertion authorizes that consumer for the Mission, tenant, substrate, and applicable audience. # MAS Metadata and Discovery A MAS publishes a metadata document at a profile-defined well-known location, modeled on RFC 8414. The proposed minimum members are: - `issuer`: the MAS's issuer URI. MUST match `mission.origin` for Missions managed at this MAS. - `mission_submit_endpoint`: where consumers submit Mission Intent. - `mission_activation_endpoint`: where a consumer completes an approved pending submission. - `mission_status_endpoint`: where consumers, Resource ASes, and auditors query Mission state and audience-filtered authority. - `mission_lifecycle_endpoint`: where authorized administrators perform revoke/suspend/resume/complete operations. - `jwks_uri`: keys used to verify MAS-signed projection assertions and other signed MAS artifacts, when the MAS issues them. - `ssf_transmitter_configuration_uri`: location of the MAS's SSF Transmitter Configuration. Stream creation, status, subject management, verification, and delivery use the endpoints advertised by SSF. - `mission_intent_schema_uri`: JSON Schema for the Mission Intent parameter, identical to the AS-side schema defined in the OAuth Profile. - `authority_types_supported`: registered Authority Set entry types the MAS can derive, including the owning substrate and schema URI. - `consumer_authentication_methods_supported`: how consumers (ASes, PSes) authenticate to the MAS. Typical values: `client_secret_basic`, `private_key_jwt`, `tls_client_auth`. - `projection_assertion_signing_alg_values_supported`: algorithms the MAS may use for signed projection assertions, when supported. - `purpose_uris_supported`: optional, list or URI of the registered purpose URIs the MAS validates against. A MAS MAY publish additional fields for federation hints, event-type registries, or governance contact metadata. Metadata discovery is not trust establishment. Resource ASes that follow `mission.origin` MUST validate the MAS issuer under local policy or a trust framework before accepting state. They must also verify that the credential issuer is authorized for the Mission projection. # Submit Flow The proposed API defines two submission patterns. Conforming MAS deployments support Flow A. Flow B is optional. ## Flow A: Consumer-mediated submission (default) The client-substrate contract is unchanged from the OAuth Profile. The MAS interaction is a backend concern between the consumer and the MAS. For OAuth: 1. The orchestrator submits `mission_intent` at PAR to the OAuth AS, exactly as defined in the OAuth Profile. 2. The AS authenticates to the MAS and forwards the Mission Intent, consumer and client identifiers, tenant context, and verifiable subject-binding evidence. 3. The MAS validates the subject evidence, resolves canonical and consumer-specific subject identifiers, validates the Mission Intent, and derives the candidate Authority Set. 4. The MAS returns a pending Mission projection and a canonical consent-disclosure object containing the validated Mission Intent and complete candidate Authority Set. 5. The AS presents that disclosure without changing its material meaning, or redirects the user to MAS-hosted consent. Deferred approval may keep the Mission in `pending_approval`. 6. On approval, the consumer returns the activation handle and `consent_rendering_hash`. The MAS verifies that the disclosed Authority Set has not changed, commits the integrity anchors, authorizes the consumer as a projection issuer, and transitions the Mission to `active`. 7. The AS issues a Mission-bound code; the client exchanges it for a Mission-bound access token carrying a projected `mission.id` and `mission.origin` (the MAS URI). For AAuth, the client-facing wire remains AAuth-native: the agent sends a Mission proposal plus optional tools to the PS's `mission_endpoint`. The PS maps that proposal to the structured governance submission it sends to the MAS, and returns AAuth's native Mission blob and `AAuth-Mission` header after activation. A representative AS-to-MAS submit request (Flow A, OAuth consumer): ```http POST /missions/submit HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: Bearer { "consumer_id": "https://as.example.com", "client_id": "agent.example.com", "tenant": "example-corp", "subject_evidence": "", "subject_evidence_type": "urn:ietf:params:oauth:token-type:jwt", "purpose": "urn:example:mission:board-packet", "mission_intent": { "goal": "Prepare the Q3 board packet", "objects": ["Q3 financials", "board presentation"], "constraints": ["confidential classification"], "success_criteria": ["packet drafted", "approval obtained"], "mission_expiry": "2026-10-15T18:00:00Z" } } ``` The MAS validates the subject and submission, derives the candidate Authority Set, and returns the pending Mission projection plus the canonical consent disclosure: ```json { "mission": { "id": "consumer-pairwise-mission-id", "origin": "https://mas.example.com", "state": "pending_approval" }, "mission_intent": { "goal": "Prepare the Q3 board packet", "objects": ["Q3 financials", "board presentation"], "constraints": ["confidential classification"], "success_criteria": ["packet drafted", "approval obtained"], "mission_expiry": "2026-10-15T18:00:00Z" }, "authority_set": { "version": 1, "entries": [ { "substrate": "oauth", "type": "resource_access", "authority": { "resource": "https://finance.example.com", "actions": ["financials.read"] } } ] }, "consent_rendering_hash": "e9X2...base64url-sha256...", "activation_handle": "act_01J9Z..." } ``` The consumer drives consent (consumer-rendered) or redirects the user to the MAS (MAS-rendered), then notifies activation: ```http POST /missions/activate HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: Bearer { "activation_handle": "act_01J9Z...", "consent_rendering_hash": "e9X2...base64url-sha256...", "decision": "approved" } ``` The MAS verifies that the approved disclosure still matches the candidate Authority Set, computes the integrity anchors, records the AS as an authorized projection issuer, transitions the Mission to `active`, and returns the activated consumer projection. The activation handle prevents the consumer from needing the canonical Mission identifier. If policy, resource metadata, or derivation output changed after disclosure, activation fails and a new disclosure is required. ## Flow B: Direct-to-MAS submission (optional) For deployments where the client is already MAS-aware (governance-team-built agents, internal platforms), the client MAY submit Mission Intent directly to the MAS and present a Mission handle to the AS. 1. The client submits Mission Intent to `mission_submit_endpoint` and authenticates as a registered MAS client. 2. The MAS authenticates the user, resolves the subject, derives and renders the candidate Authority Set, accepts user consent, activates the Mission, and returns a consumer-specific, sender-constrained Mission handle. 3. The client submits a PAR request to the AS with `mission_id` (the existing client-AS contract is extended by one parameter; see below). 4. The AS validates the handle through Mission Status, confirms that the handle is bound to the requesting client and AS, verifies projection-issuer authorization, and issues a Mission-bound code. Flow B requires one new PAR parameter, `mission_id`, as an alternative to `mission_intent`. The value is a consumer-specific Mission handle, not necessarily the canonical identifier. An AS that supports Flow B MUST reject a request containing both parameters. Flow A is the default because it preserves the existing client-AS contract. Flow B is useful when the client is already coordinating directly with the governance layer. ## Rendering The MAS or the consumer renders the validated Mission Intent for user consent. Two patterns: - **Consumer-presented.** The MAS creates a canonical consent-disclosure object. The consumer presents it using its existing UX and returns the MAS-computed disclosure digest. The digest identifies the approved structured disclosure; it does not prove that a compromised consumer displayed it honestly. - **MAS-rendered.** The consumer redirects the user to the MAS. The MAS authenticates the user, presents the canonical disclosure, captures consent, and redirects back with an activation handle. Both patterns are supported. Consumer-rendered is the natural fit for OAuth deployments where the AS already owns the consent UX. MAS-rendered is useful for governance deployments where the GRC team owns consent UX directly. # Mission Status at the MAS Credential introspection and Mission Status answer different questions: - The credential issuer answers whether a credential is valid, unexpired, unrevoked, properly sender-constrained, and intended for the relying party. - The MAS answers whether the Mission is active, which integrity anchors and policy version apply, which issuers may project it, and which Authority Set entries are relevant to the authenticated requester. A Resource AS first validates or introspects the credential at its issuer. It then extracts the authenticated Mission projection and queries Mission Status at `mission.origin`. A credential issuer MAY proxy fresh MAS state in its introspection response, but it MUST identify the MAS as the state authority and keep credential validity distinct from Mission state. ```http POST /missions/status HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: Bearer { "mission_id": "audience-pairwise-mission-id", "credential_issuer": "https://as.example.com", "audience": "https://ras.example.com" } ``` The response is audience-filtered and states whether the credential issuer was authorized to project the Mission: ```json { "active": true, "projection_issuer_authorized": true, "projection_issuer": { "issuer": "https://as.example.com", "substrate": "oauth", "tenant": "example-corp", "audience": "https://ras.example.com" }, "mission": { "id": "audience-pairwise-mission-id", "origin": "https://mas.example.com", "state": "active", "expiry": "2026-10-15T18:00:00Z", "proposal_hash": "fS8h4w7Z3Lq...", "authority_hash": "o2j2...", "consent_rendering_hash": "e9X2...", "policy_version": "pv_01J9Z..." }, "authority": [ { "substrate": "oauth", "type": "resource_access", "authority": { "resource": "https://finance.example.com", "actions": ["financials.read"] } } ] } ``` # Lifecycle Operations Revoke, suspend, resume, and complete operations target the MAS using an authorized Mission identifier. The MAS is the lifecycle authority. Consumers MAY provide their own lifecycle UI, but state changes occur at the MAS. The MAS exposes: - `POST {mission_lifecycle_endpoint}/{mission_id}/revoke` - `POST {mission_lifecycle_endpoint}/{mission_id}/suspend` - `POST {mission_lifecycle_endpoint}/{mission_id}/resume` - `POST {mission_lifecycle_endpoint}/{mission_id}/complete` Authorization is policy-driven. Typical callers are the user who approved the Mission, an authorized administrator, or a client submitting an advisory completion request. The MAS MUST document its authorization model, and client-requested completion remains subject to MAS policy. On any state change, the MAS MUST make the new state available through Mission Status and SHOULD emit a Mission state SET to configured SSF streams. # Event Propagation The MAS acts as an SSF Transmitter. Its metadata identifies an SSF Transmitter Configuration URI. Receivers create and manage streams through the SSF-advertised endpoints, and event delivery uses the configured push or poll method. The event set matches the OAuth Profile: activated, suspended, revoked, completed, expired, and superseded. On the SSF wire, event types are URI identifiers; dotted names such as `mission.revoked` are local shorthand only. Event payloads carry the relevant Mission projection, `mission.origin`, prior and new state, event time, and an event identifier. Consumers MAY republish MAS events into substrate-specific streams. The authoritative lifecycle source remains the MAS; republished events MUST preserve the MAS issuer and event identifier. Resource ASes may use current SSF streams instead of querying Mission Status on every request, subject to the freshness requirements in the Runtime Enforcement Profile. The MAS authenticates and authorizes subscribers before creating a stream. # Cross-Substrate Integration This is the primary reason to adopt the MAS topology: one governance Mission can span more than one authorization substrate. ## OAuth AS as a MAS Consumer The AS authenticates to the MAS, submits Mission Intent, issues Mission-bound OAuth credentials, and gates issuance and derivation on MAS state. ## AAuth Person Server as a MAS Consumer [Mission-Bound AAuth](/notes/mission-bound-aauth/) composes AAuth's native Mission with this governance model. Under the MAS topology: - The PS authenticates to the MAS using one of the methods advertised in metadata. - The PS maps AAuth-native Mission proposals into structured governance submissions for `mission_submit_endpoint`; the native agent-to-PS wire is unchanged. - The PS receives the pending Mission handle, presents consent or redirects to the MAS, completes activation, and issues or brokers AAuth auth tokens under the active Mission. - AAuth resource and auth tokens preserve the native `(approver, s256)` Mission reference. The composition profile defines how that reference maps to consumer-specific `mission.id` and `mission.origin` without replacing AAuth's native claim shape. A deployment running OAuth and AAuth against the same MAS can project one approved Authority Set into both substrates. Each substrate issues native credentials and preserves its native Mission reference. Cross-substrate audit uses authorized resolution of projected identifiers at the MAS. [Part 4](/notes/mission-bound-aauth/) defines the detailed AAuth mapping. ## Future Substrates [GNAP](https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/), transaction substrates, and governance-only consent surfaces can all be MAS consumers under the same role contract. The MAS owns a substrate-neutral Authority Set. Each registered authority type identifies its substrate owner and schema; consumers translate applicable entries into native credential and enforcement semantics. This profile does not define carriage for non-OAuth, non-AAuth substrates. Each follow-on composition must define its Mission proposal, native reference, projection rules, and authenticated way to identify the state authority. # Trust Framework Three trust relationships need management. **Consumer-to-MAS trust.** Each AS or PS is a registered MAS consumer with an identifier, authentication credentials, authorized operations, tenant binding, accepted subject-evidence types, and authority-projection types. Mission activation records which consumers may issue projections for that Mission. **Resource-AS-to-MAS trust.** Resource ASes querying Mission Status validate the MAS issuer against an existing trust framework and verify projection-issuer authorization. The MAS issuer URI is the Mission-state trust anchor; it does not replace validation of the credential issuer. **Subject-to-MAS trust.** Direct-to-MAS flows authenticate the user at the MAS. Consumer-mediated flows carry a signed identity assertion or use a consumer explicitly trusted for subject binding. The MAS maps that evidence to a canonical subject and consumer-specific identifiers. A submitted email address or bare `sub` is not sufficient. Tenant binding rules from the OAuth Profile apply at the MAS. A Mission approved under tenant A MUST NOT be presented to consumers under tenant B. The MAS enforces this regardless of which consumer submitted the Mission Intent. # Privacy and Security The OAuth Profile's privacy requirements still apply, but centralizing state changes the correlation and compromise surface. ## Audience-Pairwise Mission Identifiers The MAS holds the canonical Mission identifier and issues consumer- or audience-pairwise projections. Consumers normally see only the projections needed for their own credentials and audiences. A MAS that issues pairwise Mission identifiers MUST expose authenticated resolution for authorized auditors. Audit documentation MUST state whether direct raw-string joins are possible or resolution is required. For deployments whose threat model includes a single audience joining records across calls within one Mission, the MAS MAY issue request-pairwise (per-credential) identifiers: a fresh opaque value on each derived credential, mapped server-side to the canonical Mission. This is the stronger privacy tier described in [Part 3's Privacy and Security section](/notes/mission-bound-oauth-profile/#privacy-and-security) and applies identically under the MAS topology. The trade is privacy strength against per-call resolution overhead at audit time, since every record join now requires authoritative resolution at the MAS. ## The MAS Is the Correlation Root Concentrating Mission state at a MAS increases correlation and compromise impact compared with a substrate-local topology. A MAS serving many tenants and consumers can observe activity across all of them. A compromised substrate-local AS exposes its own Mission state; a compromised MAS exposes state across every dependent consumer. This is the cost of an interoperable shared governance object. The mitigations reduce correlation or make later tampering easier to detect: - Use a per-tenant MAS where regulatory or organizational boundaries require it. Tenant isolation at the MAS is the strongest mitigation a deployment controls. - Use audience-pairwise Mission identifiers so consumers cannot correlate across each other on the wire. Resolution of pairwise identifiers happens only at `mission.origin`, under authenticated access. - Limit MAS administrator visibility through standard role and audit controls. Audit-record access is itself an authorization decision. - For high-assurance Mission classes, use an external transparency or signed-audit mechanism when one is defined. An external commitment can make later rewriting detectable, but it does not prevent a compromised MAS from issuing false status in real time. The OAuth Profile's other privacy guidance (opaque `mission.id`, tenant binding, pairwise subject identifiers, and `purpose` URI confidentiality) applies at the MAS with a larger blast radius. Deployments that cannot accept that concentration should retain substrate-local state authorities. # Threat Model The OAuth Profile's threat model applies. The MAS topology introduces or sharpens three concerns. **Compromised MAS.** A compromised MAS can fabricate Mission records, backdate hashes, alter lifecycle state, authorize malicious projection issuers, or return false Mission Status. Preventing state-authority compromise is outside this profile; external transparency can make some retrospective tampering detectable. **Consumer impersonation at the MAS.** A consumer (AS or PS) that submits Mission Intent on behalf of a client is trusted to represent that client faithfully. A compromised consumer could submit Mission Intent the client never authored and then issue credentials against the resulting Mission. Strong consumer authentication, subject evidence, client and tenant binding, and per-consumer audit limit this risk. The substrate-local topology has the analogous risk when its state authority is compromised. **Trust-anchor drift at Resource ASes.** Resource ASes querying `mission.origin` need to know which MASes they trust. Accepting Mission state from an attacker-controlled MAS remains a material risk. # Conformance The MAS topology is independent of the Conformance Ladder. A deployment can use a MAS at any level if it also meets that level's issuance, enforcement, and evidence requirements. This post supports an architectural conformance claim. A future Internet-Draft must fix the metadata location, endpoint schemas, error model, and registry values before independent implementations can claim wire interoperability. An architectural MAS deployment MUST: - Operate a MAS that publishes metadata over authenticated TLS containing the capabilities described in this profile. - Route Mission Intent submission, Mission Status, lifecycle operations, and events through the MAS. - Ensure `mission.origin` on every Mission-bound credential identifies the MAS. - Authenticate every consumer (AS, PS, Resource AS subscriber) per the trust framework. A deployment can conform to Mission-Bound OAuth without adopting this profile. The OAuth Profile's default AS-internal topology remains valid. # Standards Composition | Concern | This profile mechanism | Why it is needed | Composed with | | --- | --- | --- | --- | | Mission Record home | MAS as a dedicated server role | Lets the Mission be a substrate-independent governance object instead of an OAuth feature | [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/) | | MAS discovery | Profile-defined well-known metadata document | Lets consumers and Resource ASes locate MAS endpoints | [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) modeled | | Submit flow | Consumer-mediated (Flow A) or direct-to-MAS (Flow B) | Preserves the client-substrate contract while moving the Mission record off the substrate | [RFC 9126 PAR](https://datatracker.ietf.org/doc/html/rfc9126) extends with `mission_id` for Flow B | | Mission Status | MAS status endpoint at `mission.origin` | Consumers and Resource ASes get lifecycle, issuer authorization, and audience-filtered authority from the canonical source | New Mission Status contract; credential introspection remains with the issuer | | Lifecycle operations | MAS lifecycle endpoint using an authorized Mission identifier | Centralizes revoke/suspend/resume/complete at the governance layer | Composes with the Mission lifecycle | | Event propagation | MAS-originated SSF/CAEP events | One canonical event stream regardless of which consumer minted credentials | [RFC 8417 SET](https://datatracker.ietf.org/doc/html/rfc8417), [SSF](https://openid.net/specs/openid-sharedsignals-framework-1_0.html), [CAEP](https://openid.net/specs/openid-caep-1_0.html) | | Cross-substrate | AAuth PS as a parallel consumer; future GNAP and transaction substrates | One Mission, many authorization substrates | [Mission-Bound AAuth Composition Profile](/notes/mission-bound-aauth/) | | Resource AS trust | Resource ASes validate MAS issuer against a trust framework | Prevents Mission spoofing from attacker-controlled issuers | [Identity Assertion Trust Framework](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-identity-assertion-trust-framework/), [Domain-Authorized Issuer Discovery](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-domain-authorized-issuer-discovery/) | # Gaps and Open Issues ☐ **Cross-MAS federation.** Two MASes that need to recognize each other's Missions (cross-organizational agents, M&A scenarios). This profile assumes one MAS per Mission. A federation profile would define cross-MAS trust and Mission resolution; out of scope for v1. ☐ **MAS-to-MAS Mission portability.** A Mission moves from one MAS to another (vendor migration, governance handoff). Out of scope; the operational pattern today is to revoke at the source MAS and re-approve at the destination MAS, with audit linkage maintained outside the protocol. ☐ **Consent UX default.** The profile supports consumer-presented and MAS-rendered disclosure. Standardization should decide whether one is the default and whether high-assurance Mission classes require MAS rendering. ☐ **MAS metadata location.** Should MAS metadata live at `/.well-known/mission-authority-configuration`, or at a profile-defined IANA-registered path? The choice affects interop with non-OAuth substrates. ☐ **Submit and activation endpoint shape.** The API needs stable request, response, error, idempotency, and concurrency semantics. This post sketches JSON endpoints but does not lock the final shape. ☐ **Authorization model for lifecycle operations.** Standardization must define discoverable authorization requirements for user, administrator, and client-advisory operations. Deployment policy still decides who may act on a particular Mission. ☐ **AAuth projection carriage.** AAuth `-01` already defines the native `mission` claim as `{approver, s256}` on resource and auth tokens. The remaining question is whether a separate optional claim should carry the MAS projection or whether authenticated Mission Status resolution from `(approver, s256)` is sufficient. ☐ **Event-stream authentication.** SSF/CAEP subscribers authenticate to the MAS, but the exact scheme (push, poll, bidirectional) needs nailing down. # Standards Path The natural shape is a single Internet-Draft, `draft-mcguinness-oauth-mission-authority-server`, layered as a deployment-topology profile on top of `draft-mcguinness-oauth-mission-bound-minimum-profile`. Normative additions: - The Mission Authority Server role definition. - MAS metadata document and discovery. - Consumer authentication methods and trust framework. - Submit Flow A (consumer-mediated) and Flow B (direct-to-MAS). - MAS Mission Status endpoint contract. - MAS lifecycle operations endpoint. - Mission state event publication at the MAS. - Cross-substrate consumer requirements (AS, PS, future). - Audience-pairwise Mission identifier resolution rules. Flow A composes with the [OAuth Profile](/notes/mission-bound-oauth-profile/) without changing the client-AS wire. Optional Flow B adds the `mission_id` PAR parameter. The MAS profile is orthogonal to the [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/): one chooses the state-authority topology, while the other defines execution-time enforcement. # Roadmap ## Now: Core MAS Profile Package the role contract, discovery, submit and activation flows, Mission Status, lifecycle operations, event publication, and pairwise identifier resolution as `draft-mcguinness-oauth-mission-authority-server`. ## Next: Cross-Substrate Composition - **AAuth composition deepening.** [Part 4](/notes/mission-bound-aauth/) defines the baseline mapping between AAuth's native `(approver, s256)` reference and the governance Mission reference, plus projection-carriage and consent rules. Implementation work should validate those mappings across AAuth's four resource-access modes and the MAS-mediated activation flow. - **MBO/GNAP Composition Profile.** Same shape, GNAP substrate. - **MBO/Transaction Tokens Composition Profile.** Defines how a MAS-rooted Mission flows through Transaction Token chaining when AS-A and AS-B both consume the same MAS. ## Later: Governance and Federation - **Cross-MAS Federation Profile.** Trust between multiple MASes; Mission portability. - **MAS Transparency Profile.** Anchor Mission state hashes to an external transparency log or signed audit channel so retrospective rewriting is detectable. - **Governance Inventory API.** Wire shape for user/admin visibility into all Missions managed by a MAS, across all consumers. # Implementation Checklist An OAuth deployment adopting the MAS topology applies the OAuth Profile's [Implementation Checklist](/notes/mission-bound-oauth-profile/#implementation-checklist) across the MAS and consuming AS according to the role split below. **Mission Authority Server:** - [ ] Publishes a metadata document at the profile-defined well-known location. - [ ] Accepts Mission Intent submissions from authenticated consumers at `mission_submit_endpoint`. - [ ] Completes pending approvals at `mission_activation_endpoint` using a bound, replay-resistant activation handle. - [ ] Validates Mission Intent against client registration and deployment policy at the MAS. - [ ] Derives the candidate Authority Set before consent and produces a canonical consent disclosure containing intent and authority. - [ ] Computes and stores `proposal_hash`, `authority_hash`, and `consent_rendering_hash` at activation. - [ ] Commits the generic Authority Set and returns substrate- and audience-filtered projections. - [ ] Answers Mission Status with lifecycle state, integrity hashes, `policy_version`, projection-issuer authorization, and audience-relevant Authority Set entries. - [ ] Exposes lifecycle operations at `mission_lifecycle_endpoint`, enforces deployment-defined authorization for each operation. - [ ] Publishes verification keys for MAS-signed projection assertions and other signed artifacts. - [ ] Publishes SSF Transmitter Configuration and emits Mission state SETs through configured streams. - [ ] Enforces tenant binding at the MAS regardless of consumer. - [ ] Issues audience-pairwise Mission identifiers when deployment policy requires; resolves them only for authorized auditors. **Consuming OAuth AS:** - [ ] Authenticates to the MAS using a method the MAS advertises. - [ ] Forwards `mission_intent` received at PAR to the MAS for validation and storage. - [ ] Issues Mission-bound tokens carrying `mission.id` and `mission.origin` (the MAS URI). - [ ] Gates refresh, Token Exchange, and ID-JAG derivation on MAS state. - [ ] Keeps credential validation and introspection at the credential issuer and obtains Mission state from the MAS. - [ ] (Flow B) Accepts `mission_id` as a PAR parameter alternative to `mission_intent`; rejects requests carrying both. **Consuming AAuth Person Server:** - [ ] Authenticates to the MAS using a method the MAS advertises. - [ ] Maps the native AAuth Mission proposal to the MAS governance submission while preserving the approved Mission blob and `(approver, s256)` reference. - [ ] Preserves AAuth's native Mission reference in resource and auth tokens and exposes or resolves the corresponding MAS projection. - [ ] Gates AAuth operation issuance on MAS state. **Resource AS:** - [ ] Validates or introspects the credential at its issuer, then follows the authenticated `mission.origin` to query Mission Status. - [ ] Verifies that the credential issuer is authorized for the Mission, tenant, substrate, and audience. - [ ] Validates the MAS issuer against the configured trust framework before accepting Mission state. - [ ] (Optional) Subscribes to MAS events for event-driven freshness. **Discovery:** - [ ] Consumers discover the MAS through deployment configuration or the profile's eventual discovery mechanism. - [ ] Resource ASes resolve the profile-defined metadata location relative to the trusted `mission.origin`; the final well-known suffix remains to be standardized. # References - [Mission-Bound OAuth Profile](/notes/mission-bound-oauth-profile/) - [Mission-Bound Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/) - [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls/) - [The Mission is the Missing Abstraction for Agents](/notes/the-mission-is-the-missing-abstraction/) - [Mission-Bound AAuth Composition Profile](/notes/mission-bound-aauth/) - [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749): The OAuth 2.0 Authorization Framework - [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662): OAuth 2.0 Token Introspection - [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414): OAuth 2.0 Authorization Server Metadata - [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417): Security Event Token (SET) - [RFC 9126](https://datatracker.ietf.org/doc/html/rfc9126): OAuth 2.0 Pushed Authorization Requests - [RFC 8785](https://datatracker.ietf.org/doc/html/rfc8785): JSON Canonicalization Scheme (JCS) - [draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) - [draft-mcguinness-oauth-identity-assertion-trust-framework](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-identity-assertion-trust-framework/) - [draft-mcguinness-oauth-domain-authorized-issuer-discovery](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-domain-authorized-issuer-discovery/) - [OpenID Shared Signals Framework (SSF) 1.0](https://openid.net/specs/openid-sharedsignals-framework-1_0.html) - [OpenID CAEP 1.0](https://openid.net/specs/openid-caep-1_0.html)