Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 7 July 2026 Expires: 8 January 2027 Mission Authority Server draft-mcguinness-mission-authority-server-latest Abstract Mission-Bound Authorization for OAuth 2.0 defines the Mission, a durable, human-approved, integrity-bound authorization artifact, and binds it to OAuth issuance: the Authorization Server derives tokens under the Mission and gates them on its state. Many deployments cannot change their Authorization Server. This document defines the Mission Authority Server, a standalone service that implements the Mission Issuer role without being an OAuth Authorization Server: it validates Mission Intents, runs approval events, records Missions, operates the Mission lifecycle, and serves Mission state. It derives no tokens. Access tokens remain ordinary OAuth tokens; a Policy Decision Point joins each presented credential to its Mission at the point of use and enforces through the Mission-Bound Runtime Enforcement profile. This is the standalone binding, the AS-optional deployment mode: Mission governance and per-action enforcement with no change to the deployment's Authorization Server, forgoing the Mission-bound credentials and issuance gating that only the issuance profile provides. Beyond a single-AS workaround, the Mission Authority Server is the standalone Mission Issuer for an estate whose task governance must span many Authorization Servers, SaaS systems, APIs, local tools, and agent runtimes at once: a control plane for approved-task authority over an unchanged OAuth estate. This document defines a deployable conformance floor and, above it, an Enterprise Mission Authority Profile for that role. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-authority-server.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-authority-server/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Applicability 1.2. Conventions and Terminology 2. Mission Substrate 3. Mission Submission 3.1. Intent Submission 3.2. Submission Status 3.3. Error Responses 4. Mission Approval 5. Mission Reference Delivery 6. Mission Lifecycle and State 7. Mission Expansion and Child Creation 7.1. Submission Carriage 7.2. Request Binding 7.3. Expansion Semantics 7.4. Child-Creation Semantics 7.5. Expansion Example 8. Mission Discovery 9. Mission Join 10. Mission Join Assertion 10.1. Assertion Request 10.2. The Assertion 10.3. PDP Consumption 11. Limitations 12. Conformance 13. The Enterprise Mission Authority Profile 13.1. The Enterprise Mapping Contract 13.2. Policy View Distribution 14. Deployment 14.1. Topology 14.2. Connector Patterns 14.3. Progressive Adoption 15. Security Considerations 15.1. Join Spoofing 15.2. Join Assertion Trust 15.3. Expansion and Child-Creation Binding 15.4. Ambient Authority of Ungated Tokens 15.5. MAS Availability 15.6. MAS Compromise 15.7. Approval Surface Authentication 16. Privacy Considerations 17. IANA Considerations 17.1. Well-Known URI Registration 17.2. Mission Authority Server Metadata Registry 17.3. Runtime Denial Reason 18. References 18.1. Normative References 18.2. Informative References Appendix A. MAS-Mode End-to-End Example A.1. Submit A.2. Poll to Approved A.3. Join A.4. Permit Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "issuance profile") binds issued authority to a durable, human-approved Mission. Its Mission Issuer role is played by the OAuth Authorization Server (AS) [RFC6749]: the AS validates the Mission Intent, runs the approval event, records the Mission, derives Mission-bound tokens, and gates issuance on Mission state. That binding is the strongest deployment of the Mission model, and it requires changing the AS. Many deployments cannot make that change: the AS is a shared or third-party service, while the need to govern agent tasks is immediate. This document defines the *Mission Authority Server (MAS)* for those deployments: a standalone service that implements the Mission Issuer role of the issuance profile without being an OAuth Authorization Server. A MAS validates Mission Intents, runs approval events, records Missions, operates the Mission lifecycle, and serves Mission state. It derives no tokens, and it requires no change to the deployment's existing AS. Because tokens remain ordinary OAuth tokens with no mission claim, the credential-to-Mission association is established at the point of use instead of traveling in the credential: the Policy Enforcement Point (PEP) presents the Mission reference explicitly, and the Policy Decision Point (PDP) joins the credential to the Mission before evaluating the action (Section 9). Per-action enforcement then proceeds under the runtime profile [I-D.draft-mcguinness-mission-runtime] unchanged. The OAuth binding remains the flagship of the family, and a deployment that changes its AS gets Mission-bound credentials and issuance gating, which the MAS mode does not provide (Section 11). The MAS is nonetheless a peer binding, not a staging area: decoupling governance from token issuance is an architectural choice some deployments make deliberately and keep. Lacking a Mission-bound credential is not the same as lacking strategic value. An enterprise governing agent tasks across many Authorization Servers, SaaS tenants, APIs, and tool gateways needs one place that holds the approved task, its lifecycle, and its authority, independent of which system issued a given token; a central MAS can be that place, and can remain the long-term architecture even after some Authorization Servers become Mission-aware. For deployments that want Mission- bound tokens on a particular AS later, the path is smooth: the record, anchors, and lifecycle a MAS operates are the issuance profile's own, so moving issuance into that AS carries them over unchanged, while the MAS continues to govern the rest of the estate. 1.1. Applicability This profile targets deployments that need governed, approvable, revocable agent tasks but cannot extend their Authorization Server, and that can route consequential actions through the runtime profile's enforcement. It is also a deliberate architectural choice in its own right: a deployment MAY prefer a standalone Mission Issuer even where it controls its AS, to keep governance decoupled from token issuance or to govern with one Mission Issuer across many Authorization Servers, accepting the enforcement posture of Section 11. A deployment that wants Mission-bound tokens and issuance gating implements the issuance profile; a deployment that cannot deploy runtime enforcement over its consequential action paths obtains records but no enforcement from this profile and SHOULD NOT claim it (Section 11). The Mission Join (Section 9) is the newest mechanism in the family and not yet exercised in deployment; a deployment that can implement the issuance profile obtains the stronger, stable binding. 1.2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative. This document uses Mission, Mission Intent, Mission Issuer, Authority Set, Approver, Subject, mission_id, the integrity anchors, and the audit horizon as defined by [I-D.draft-mcguinness-oauth-mission]; the Mission Status operation and Mission Lifecycle endpoint as defined by [I-D.draft-mcguinness-oauth-mission-status]; and PEP, PDP, consequential action, Mission state source, and enforcement scope as defined by [I-D.draft-mcguinness-mission-runtime]. It additionally uses: Mission Authority Server (MAS): A service that implements the Mission Issuer role of the issuance profile without being an OAuth Authorization Server. It is the issuer of the Missions it records, and it derives no tokens. Mission-joining PDP: A PDP that resolves Missions at a MAS and verifies the join between a presented credential and the referenced Mission before evaluating an action (Section 9). Standalone binding: This document's deployment mode: the Mission Issuer role implemented by a MAS, with the deployment's tokens unchanged. The rest of the Mission family cites this mode by this name; "AS-optional" is its informal gloss. 2. Mission Substrate The companion profiles of the Mission suite are defined against the Mission model's substrate primitives rather than against OAuth mechanics. The issuance profile provides all of them. A MAS provides these: * the Mission identifier and issuer; * the lifecycle state space with the only-active rule and its forward-compatibility treatment of unrecognized states; * the Authority Set representation, with the subset rule and Common Constraints; * the integrity-anchor envelope, computed with the MAS's issuer URL as the envelope iss; and * the audit horizon. Each primitive is the issuance profile's, unchanged ([I-D.draft-mcguinness-oauth-mission]); a MAS re-defines none of them. A MAS does NOT provide the Mission-bound credential primitive or issuance gating: no token carries the mission claim or Mission- derived authorization_details, and no issuance event is gated on Mission state. The composition consequences follow from that split: * The shaping, consent-evidence, audit-transparency, security-model, status, signals, and completion profiles consume only the primitives a MAS provides and compose with a MAS unchanged. Where such a profile names the Mission Issuer or the issuer AS, the MAS is that party. * The runtime profile and its AuthZEN binding, the harness, and orchestration compose through the runtime profile's Mission binding establishment step ([I-D.draft-mcguinness-mission-runtime]): their Mission Substrate sections mark the Mission-bound credential binding-dependent, and this document profiles the step's externally established mode as the Mission Join (Section 9). * A profile that requires the Mission-bound credential does not apply in MAS-only mode: offline attenuation ([I-D.draft-mcguinness-oauth-mission-attenuation]) attenuates a credential that does not exist here, and the token-carriage aspects of delegation (the act chain on Mission-bound tokens) have no carrier. * Mission Expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) and Mission Child Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]) define their request wire over OAuth Pushed Authorization Requests; their MAS-native wire is defined by Section 7, which carries both operations on the mission submission endpoint with an authenticated-client binding in place of the OAuth wire's token possession. Their models (supersession, lineage, cascade) apply to MAS-held Missions unchanged. 3. Mission Submission A client proposes a Mission by submitting a Mission Intent to the MAS's mission submission endpoint, published as mission_submission_endpoint (Section 8). The endpoint MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED), following the recommendations of [RFC9325], and MUST authenticate the client using the authentication mechanisms of the Mission Status endpoint ([I-D.draft-mcguinness-oauth-mission-status]): mTLS, DPoP-bound bearer, or private-key JWT. How clients register with a MAS is deployment-defined; the identifier the MAS authenticates is recorded as the Mission's client_id. The endpoint serves two operations, dispatched by request media type: * *Intent submission*: an HTTPS POST whose application/json body is the Mission Intent object itself (Section 3.1). * *Submission status*: an HTTPS POST with an application/x-www-form- urlencoded body containing a submission parameter (Section 3.2). 3.1. Intent Submission The request body is a Mission Intent as the issuance profile defines it, and the issuance profile's validation rules apply unchanged ([I-D.draft-mcguinness-oauth-mission]): the Intent is untrusted client input and never authority; the MAS MUST bound its total size and array lengths; and the Intent is closed at the top level. The issuance profile's OAuth error outcomes map to this endpoint's error codes (Section 3.3): * A body that cannot be parsed as a JSON [RFC8259] object, is structurally invalid, exceeds the deployment's size bounds, or contains a top-level member the issuance profile does not define MUST be refused with invalid_mission_intent (the MAS equivalent of the issuance profile's invalid_request rejections, including reject-unknown-top-level-member). * A well-formed Intent from which the MAS cannot derive a valid Authority Set under policy MUST be refused with invalid_authority (the MAS equivalent of invalid_authorization_details), so a client can distinguish a syntax error from an authority-derivation failure. On acceptance the MAS derives the Authority Set from the Intent under the issuance profile's derivation rules ([I-D.draft-mcguinness-oauth-mission]) and returns HTTP 202 with a pending-submission reference: submission_id: REQUIRED. A string. An opaque URL-safe ASCII string of [A-Za-z0-9_-] characters with at least 128 bits of entropy, carrying no semantic content. It MUST NOT be reused. It is a reference, never a capability. status: REQUIRED. A string. pending on acceptance. expires_at: REQUIRED. A string. An RFC 3339 [RFC3339] date-time after which an undecided submission lapses to expired. Example: POST /mas/mission/submit HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... { "goal": "Reconcile Q3 invoices and post adjustments under $500.", "resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z" } HTTP/1.1 202 Accepted Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP", "status": "pending", "expires_at": "2026-10-16T14:32:11Z" } 3.2. Submission Status The client polls the outcome with a form-urlencoded POST carrying: submission: REQUIRED. A string. The submission_id. A submission is in one of four states: +==========+=========================================+ | status | Meaning | +==========+=========================================+ | pending | Awaiting an approval decision. | +----------+-----------------------------------------+ | approved | Approved; a Mission exists (Section 5). | +----------+-----------------------------------------+ | denied | Declined by the Approver or refused by | | | policy. Terminal. | +----------+-----------------------------------------+ | expired | expires_at passed undecided. Terminal. | +----------+-----------------------------------------+ Table 1 Only approved delivers a Mission: a consumer MUST treat every other status value, recognized or not, as not approved, mirroring the issuance profile's only-active rule. A resolved submission MUST remain resolvable for a deployment-defined window; the reference is never reused. The MAS MUST return submission status only to the authenticated client that submitted the Intent. For any other caller, and for an unknown submission_id, the MAS MUST return the not_found error with an identical status code, body, and headers, preserving the anti- oracle property of [I-D.draft-mcguinness-oauth-mission-status]. 3.3. Error Responses A hard failure returns the matching HTTP status with a JSON object body: error: REQUIRED. A string. A code from the table below. error_description: OPTIONAL. A string. Human-readable detail. error_reason: OPTIONAL. A string. A machine-readable refinement of error: for invalid_mission_intent, the name of the offending top- level member; for invalid_authority, the resources entry no authority could be derived for. It reflects the client's own input and MUST NOT disclose policy internals. A consumer MUST ignore members it does not recognize. +========================+======+===================================+ | error | HTTP | Description | +========================+======+===================================+ | invalid_mission_intent | 400 | Unparseable, structurally | | | | invalid, oversized, or | | | | containing an undefined | | | | top-level member. | +------------------------+------+-----------------------------------+ | invalid_authority | 400 | Well-formed Intent, but | | | | no valid Authority Set is | | | | derivable under policy. | +------------------------+------+-----------------------------------+ | unauthorized | 401 | Request not | | | | authenticated. | +------------------------+------+-----------------------------------+ | not_found | 404 | A referenced submission | | | | or Mission does not exist | | | | OR is not visible to the | | | | caller. | +------------------------+------+-----------------------------------+ | rate_limited | 429 | Caller is rate-limited. | +------------------------+------+-----------------------------------+ | unavailable | 503 | MAS temporarily cannot | | | | serve the request. | +------------------------+------+-----------------------------------+ Table 2 4. Mission Approval Approval at a MAS is natively asynchronous: there is no authorization code ceremony, so no approval blocks a front-channel redirect. The MAS routes each pending submission to its approval surface (a review application, queue, or policy engine) and resolves it when the decision is made. The approval event executes steps 1 through 4 of the issuance profile's approval event unchanged ([I-D.draft-mcguinness-oauth-mission]): 1. Authenticate the Approver; when the Intent's controls.acr is present, the authentication MUST be one the deployment's policy maps as satisfying the named class (the issuance profile's acr mapping rule). 2. Establish the Subject under the issuance profile's rules: the MAS MUST itself establish the Subject's (iss, sub) and MUST NOT take it from unauthenticated client input. 3. Render the derived Authority Set for consent with the issuance profile's rendering rules applied unchanged: client-supplied strings inert, direction-override and confusable presentation mitigated, derived authority visually distinguished from client text. 4. Compute the integrity anchors, authority_hash and intent_hash, using the issuance profile's envelope with the MAS's issuer URL as iss. Step 5 becomes: create the Mission record in the active state atomically with the approval decision. The record is the issuance profile's Mission Record, member for member; its issuer is the MAS's issuer URL and its approval_event_id is the approval idempotency key. There is no authorization code to bind, so the deferred-approval profile's re-sequencing of this step ([I-D.draft-mcguinness-oauth-mission-approval]) is not needed: deferral is the MAS's native shape. A declined submission resolves to denied. Mission Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) composes unchanged: the MAS is the committing issuer for any consent- disclosure commitment. 5. Mission Reference Delivery The client learns its mission_id from the submission-status response after approval. When status is approved, the response additionally carries: mission_id: REQUIRED. A string. The Mission's identifier. authorization_details: REQUIRED. An array. The consented Authority Set, so the client learns its granted authority here; this response is the MAS counterpart of the issuance profile's token- response authorization_details echo. Example: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP", "status": "approved", "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "authorization_details": [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read", "journal-entries.write"], "constraints": { "max_amount": { "amount": "500.00", "currency": "USD" } } } ] } mission_id remains a reference, never a credential ([I-D.draft-mcguinness-oauth-mission]): presenting it authorizes nothing, and no MAS surface derives authority from possession of it. 6. Mission Lifecycle and State In MAS mode there are no Mission-bound tokens and no token introspection, so the Mission Status profile's surfaces are the only way a consumer observes or changes Mission state. A MAS therefore implements them as its state surface, by reference: * The MAS MUST serve the Mission Status operation of [I-D.draft-mcguinness-oauth-mission-status], including its signed responses, authentication, anti-oracle property, and caching rules. * The MAS MUST serve the Mission Lifecycle endpoint of that profile with its full operation set (revoke, suspend, resume, and complete), following that profile's state machine unchanged. A MAS owns its state store, so partial support is not permitted. * The MAS MAY emit Mission Lifecycle Signals ([I-D.draft-mcguinness-oauth-mission-signals]), which compose unchanged, with the MAS as the transmitting Mission Issuer. The issuance profile's token-introspection projection does not apply: there is no token to introspect. The MAS publishes the corresponding metadata members (mission_status_endpoint, mission_status_signing_alg_values_supported, mission_lifecycle_endpoint, mission_max_stale_seconds, and, when signals are supported, mission_event_stream_endpoint) in its discovery document (Section 8) with the semantics those profiles define for the members of the same names. 7. Mission Expansion and Child Creation Mission Expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) and Mission Child Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]) define their request wire over OAuth Pushed Authorization Requests, bound to the predecessor or parent by token possession (predecessor_token, parent_token). A MAS issues no tokens, so that binding has no carrier here. This section defines the MAS-native wire for both operations: carriage on the mission submission endpoint (Section 7.1) and an authenticated-client binding in place of token possession (Section 7.2). It defines carriage and binding only; every mechanism (supersession, reconciliation, lineage, strict subset, fan-out, cascade, and the closed code sets) remains owned by its profile and applies here by reference (Section 7.3, Section 7.4). The capability is OPTIONAL (Section 12). 7.1. Submission Carriage The mission submission endpoint carries both operations as intent submissions (Section 3.1) with additional top-level members of the request body: predecessor: A string. The mission_id of the predecessor Mission this submission expands; semantics per the expansion profile. Its presence marks the submission as an expansion request. parent: A string. The mission_id of the Parent Mission; semantics per the child-delegation profile. child_actor: An object identifying the child actor, in the form the child-delegation profile defines. The presence of parent and child_actor together marks the submission as a child-creation request. These are submission members, not Mission Intent members: a MAS that implements this capability MUST remove them before applying the issuance profile's Intent validation, and the remainder of the body is the Mission Intent, validated unchanged (Section 3.1). On a MAS that does not implement this capability they are undefined top-level members and the submission is refused with invalid_mission_intent, the correct refusal for an unsupported operation. A submission carrying both predecessor and either child member MUST be refused with invalid_mission_intent: the operations do not combine. A submission carrying parent without child_actor, or child_actor without parent, MUST be refused the same way. The predecessor_token and parent_token parameters of the OAuth wire do not exist on this surface; the binding of Section 7.2 replaces them. The referenced profiles' OAuth error outcomes map onto this endpoint's error surface as the issuance profile's do (Section 3.1): invalid_request outcomes map to invalid_mission_intent, and authority-derivation failures to invalid_authority. Two rules cover the outcomes those profiles express as invalid_grant: * A predecessor or parent the binding does not resolve, whether the Mission does not exist or is recorded under another client, MUST be refused with not_found, with a response identical in both cases, preserving the anti-oracle property of Section 3.2. * A reference the binding resolves whose state or serialization refuses the operation (the expansion profile's predecessor-active and reconciliation rules; the child-delegation profile's parent- active rule) MUST be refused with conflict, returned with HTTP 409. conflict extends the error code set of Section 3.3 and is used only by this section's operations. The profile-defined machine-readable code rides the MAS error surface in the member its profile defines, mission_expansion_status for expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) and mission_denial_reason for child creation ([I-D.draft-mcguinness-oauth-mission-child-delegation]), carried as a member of the error response body (Section 3.3) or, for a denial at adjudication, of the denied submission-status response (Section 3.2). 7.2. Request Binding The OAuth wire resolves the predecessor or parent from a presented grant and cross-checks it against the named identifier. A MAS holds no grants, so the named identifier is itself the reference, and the MAS binds the request to it as follows: * The MAS MUST verify that the authenticated submitting client is the client recorded as the predecessor Mission's client_id (for expansion) or the Parent Mission's client_id (for child creation). Both identifiers live in the MAS's own client namespace (Section 3), so the comparison is ordinarily byte-equality; where a deployment maps client identities it MUST document the mapping, exactly as the client join requires (Section 9). * For an expansion, the MAS MUST verify at the approval event that the Subject it establishes (Section 4) equals the predecessor Mission's subject; a successor MUST NOT be created for a different Subject. This is an authentication-based binding, not a possession-based one: it proves the requester is the same registered client the predecessor or parent was recorded for, not that it holds that Mission's grant. The delta from the OAuth wire is exactly that: a party able to authenticate as the registered client can request these operations for any of that client's Missions, where token possession would limit it to the grants it actually holds (Section 15.3). Where the deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the MAS SHOULD bind at instance granularity rather than at the bare client_id, and a Mission Join Assertion for the predecessor or parent (Section 10), presented with the submission, strengthens the proof to a named runtime instance holding a sender-constrained credential that verifiably joins to that Mission. 7.3. Expansion Semantics An expansion submission is adjudicated under the expansion profile's rules ([I-D.draft-mcguinness-oauth-mission-expansion]), applied by reference: * *Predecessor active.* The predecessor MUST be active when the submission is accepted, per that profile's predecessor-active rule. * *Reconciliation.* Concurrent expansions against the same predecessor are serialized under that profile's compare-and-set reconciliation, and its closed reconciliation-status set applies: a refusal at submission carries the code per Section 7.1, and a pending submission overtaken by a concurrent expansion resolves to denied with the code in the status response. * *Supersession atomicity.* In one atomic operation on the MAS's records, the successor activates with its predecessor member set, and the predecessor transitions to superseded with its successor member set. The successor and related_to members carry that profile's semantics and surface through the MAS's Mission Status responses; superseded enters the state space the MAS reports (Section 6). * *Denial reasons.* That profile's closed denial-reason set applies; the code rides in mission_expansion_status per Section 7.1. Approval of the successor is this document's native asynchronous approval event (Section 4): fresh consent for the successor's derived Authority Set, with no authorization-code leg to re-sequence. On approval the client's poll delivers the successor's mission_id and consented authority (Section 5). The successor-expiry rule and every other expansion rule that does not name the OAuth wire apply unchanged. Progressive authorization is out of scope here exactly as it is out of the expansion profile's base: every expansion on this surface is adjudicated by a fresh approval, and the policy- adjudicated variant remains the experimental companion's ([I-D.draft-mcguinness-oauth-mission-progressive]). 7.4. Child-Creation Semantics A child-creation submission is adjudicated under the child-delegation profile's rules ([I-D.draft-mcguinness-oauth-mission-child-delegation]), applied by reference: * *On-switch.* Child creation is permitted only where the applicable Parent Mission Authority Set entry's delegation member carries a children object; an entry without one permits no child. * *Strict subset.* The child Authority Set MUST satisfy that profile's strict-subset evaluation against the parent, with no relaxation. * *Fan-out.* Fan-out accounting and its serialization apply unchanged: the MAS counts non-terminal Child Missions against max_children and serializes creation against the same parent entry and fan-out bucket. * *Parent member.* The Child Mission record carries the parent object constructed per that profile, including depth; with no token carrier, it surfaces through the record and the MAS's Mission Status responses. * *Cascade.* Cascade applies with one simplification: the MAS owns its state store, so cascade transitions are native lifecycle transitions on its own records. The MAS implements that profile's immediate mode, and the cascaded state surfaces through Mission Status (Section 6). * *Denial reasons.* That profile's closed denial-reason set applies; the code rides in mission_denial_reason per Section 7.1. The parent_mismatch reason has no analog on this surface: with no parent_token to cross-check, a binding failure is refused per Section 7.1. The child client identity rules hold unchanged: the child actor is the Child Mission's client, recorded as its client_id; it authenticates itself to the MAS for its own submissions, status, and lifecycle operations; and child credentials MUST NOT transit the parent. The creating client learns the Child Mission's mission_id from its own submission status; mission_id is a reference, never a capability, so conveying it to the child actor moves no authority. At the point of use, the Mission Join (Section 9) binds the child's ordinary OAuth credentials to the Child Mission through the child's own client_id, never the parent's. 7.5. Expansion Example Mid-task, the agent behind the Q3 reconciliation Mission finds a $1,200 adjustment, outside its approved $500 cap. It submits an expansion: a Mission Intent for the broadened task whose body names the predecessor: POST /mas/mission/submit HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... { "goal": "Reconcile Q3 invoices and post adjustments under $2,000.", "resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z", "predecessor": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-" } The MAS authenticates the client, verifies it is the predecessor's recorded client_id, verifies the predecessor is active, strips predecessor, validates the remaining Mission Intent, derives the successor's Authority Set, and accepts: HTTP/1.1 202 Accepted Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_7bD1eF4jB0K9wT2xM5nQ8rL3vZ", "status": "pending", "expires_at": "2026-10-16T15:07:42Z" } Adjudication proceeds per Section 4: the Approver consents to the widened cap, the MAS verifies the established Subject equals the predecessor's subject, and one atomic operation creates the successor active and supersedes the predecessor. The client's next poll returns approved with the successor's mission_id (Section 5). 8. Mission Discovery A MAS publishes a metadata document at the well-known URI [RFC8615] path /.well-known/mission-authority-server, registered in Section 17: a JSON object served over TLS as application/json. Its members mirror the Mission suite's Authorization Server metadata members where applicable, so a consumer reads the same member names it would read from AS metadata [RFC8414], resolved from this document instead: issuer: REQUIRED. A string. The MAS's issuer URL. It equals the issuer of every Mission the MAS records and the iss of its integrity-anchor envelopes and signed status responses. A consumer MUST verify it equals the URL the metadata was resolved from, with the well-known path removed. mission_submission_endpoint: REQUIRED. A string containing a URL. The mission submission endpoint (Section 3). mission_status_endpoint: REQUIRED. A string containing a URL. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_status_signing_alg_values_supported: REQUIRED. A JSON array of strings. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_lifecycle_endpoint: REQUIRED. A string containing a URL. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_auth_methods_supported: REQUIRED. A JSON array of strings. The caller authentication mechanisms the MAS accepts at the submission, status, and lifecycle endpoints, from the mechanism set of [I-D.draft-mcguinness-oauth-mission-status]. A value naming a client authentication method is an entry of the IANA "OAuth Token Endpoint Authentication Methods" registry (tls_client_auth for mTLS, private_key_jwt), following the discovery pattern of the [RFC8414] *_endpoint_auth_methods_supported members. The DPoP-bound access token mechanism is token presentation rather than client authentication, so no registry entry names it; this document uses dpop_bound_token. mission_join_assertion_endpoint: OPTIONAL. A string containing a URL. The join-assertion endpoint (Section 10). Present when the MAS mints Mission Join Assertions. mission_event_stream_endpoint: OPTIONAL. A string containing a URL. Present when the MAS supports Mission Lifecycle Signals; semantics per [I-D.draft-mcguinness-oauth-mission-signals]. mission_max_stale_seconds: OPTIONAL. An integer. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. jwks_uri: REQUIRED. A string containing a URL. The MAS's JSON Web Key Set: the issuer's signing keys, from which consumers resolve the keys for Mission Status responses, consent evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), Mission Mandates ([I-D.draft-mcguinness-mission-mandate]), and other issuer-signed artifacts, with the signing-key retention rules of [I-D.draft-mcguinness-oauth-mission-status]. Example: { "issuer": "https://mas.example.com", "mission_submission_endpoint": "https://mas.example.com/mas/mission/submit", "mission_status_endpoint": "https://mas.example.com/mas/mission/status", "mission_status_signing_alg_values_supported": ["ES256"], "mission_lifecycle_endpoint": "https://mas.example.com/mas/mission/lifecycle", "mission_auth_methods_supported": ["dpop_bound_token", "private_key_jwt"], "mission_join_assertion_endpoint": "https://mas.example.com/mas/mission/join-assertion", "mission_max_stale_seconds": 60, "jwks_uri": "https://mas.example.com/.well-known/jwks.json" } A consumer holding a Mission reference resolves this document from the reference's issuer; whether a given issuer is a MAS or an OAuth AS is deployment configuration. The submission and lifecycle surfaces follow a reference-plus-continuation shape (a request yields an opaque reference the client continues against) that parallels the grant continuation pattern of GNAP [RFC9635]. 9. Mission Join In MAS mode the acting access token is an ordinary OAuth token from the deployment's unchanged AS: it carries no mission claim and no Mission-derived authorization_details, so it cannot identify its Mission. The PEP names the Mission explicitly, and the PDP joins the credential to it before evaluating the action. The join is this profile's load-bearing mechanism: it is what a permit "under this Mission" rests on when no cryptographic binding exists. A Mission-joining PDP and its PEPs MUST observe the following: 1. *The PEP supplies the Mission reference.* For governed work the PEP MUST supply the mission_id and issuer of the Mission the work is bound to, taken from its Mission binding (a Mission-aware harness records exactly this, [I-D.draft-mcguinness-mission-harness]) or from deployment configuration. In the AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]) this is context.mission; the PEP populates authority_hash and state from the MAS's signed Mission Status response. 2. *The PDP resolves the Mission at the MAS.* The PDP MUST resolve the referenced Mission through the MAS's Mission Status operation and MUST treat the MAS as the Mission state source under the runtime profile's state and freshness rules ([I-D.draft-mcguinness-mission-runtime]): fail closed when state cannot be established within the published staleness bound, and use an active freshness mechanism for the high-consequence classes. 3. *Subject join.* The PDP MUST verify that the presented credential's authenticated subject equals the Mission's subject.sub under the deployment's account mapping. Where the credential's issuer and the Mission's subject.iss name the same namespace, equality is byte-equality; otherwise the deployment MUST document the mapping, and a subject the mapping does not cover fails the join. 4. *Client join.* The PDP MUST verify that the presented credential's authenticated client identifier equals the Mission's client_id, or names a delegate that deployment policy explicitly authorizes to act under that Mission's client. Delegate authorization MUST be explicit, an enumerated policy, never a default. Where the AS and MAS client namespaces differ, the deployment MUST document the client mapping, exactly as for subjects. 5. *Join failure is a deny.* A failure of the subject or client join MUST be denied with the mission_mismatch denial reason. The PDP MUST NOT fall back to evaluating the action against the referenced Mission's authority when the join fails. 6. *Authority comes from the Mission.* On a successful join, the PDP evaluates the action under the runtime profile's decision contract, drawing the Authority Set from the Mission (the audience-scoped Mission Status response or a materialized policy view), since the credential carries none. All other decision inputs and invariants of [I-D.draft-mcguinness-mission-runtime] apply unchanged. A successful join, in the AuthZEN binding: the PEP supplies context.mission populated from its Mission binding, with authority_hash and state taken from the MAS's signed Mission Status response, and the other decision inputs per [I-D.draft-mcguinness-mission-authzen]: { "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR", "properties": { "iss": "https://idp.example.com" } }, "resource": { "type": "invoice", "id": "inv_2026Q3_842" }, "action": { "name": "invoices.read" }, "context": { "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active" } } } The credential's authenticated subject and client match the Mission's subject.sub and client_id, so the join holds; the PDP evaluates the action under the Mission's Authority Set and permits: { "decision": true, "context": { "decision_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t", "action_class": "irreversible_action", "class_source": "resource_floor", "permit_expires_at": "2026-11-02T08:15:30Z" } } mission_mismatch: The presented credential does not join to the referenced Mission: its authenticated subject or client identifier does not match the Mission's subject.sub or client_id under the deployment's documented mapping and delegate policy. The AuthZEN profile's denial-reason extensibility rule permits a companion profile to extend the denial-reason set by specification, and requires a consumer to treat an unrecognized reason as a deny ([I-D.draft-mcguinness-mission-authzen]). mission_mismatch is such an extension: where this profile is implemented, it is a member of that denial-reason set. A consumer that does not implement this profile treats it as that rule requires: the action stays refused. Example AuthZEN denial for a credential whose client_id does not match the referenced Mission: { "decision": false, "context": { "decision_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K", "denial_reason": "mission_mismatch", "action_class": "irreversible_action", "class_source": "resource_floor", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t" } } The join proves that the credential belongs to the same subject and client the Mission names. It does not prove the credential was derived under the Mission; no MAS-mode mechanism can, because the AS issues tokens with no knowledge of Missions (Section 11, Section 15.1). A deployment MAY move the join's verification from each PDP to the MAS with the Mission Join Assertion (Section 10); that upgrade strengthens who verifies the join, not what the join can prove. Where the deployment's Authorization Server issues tokens under the client-instance-assertion profile ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the acting credential identifies a concrete runtime instance: the token's act entry carries the instance sub and an instance-specific cnf key. The PDP SHOULD include that instance in the join, so the client join binds (subject, client, instance) rather than (subject, client). This restores per-instance granularity behind a shared gateway client_id: the validated instance joins, not every workload in the client_id equivalence class. 10. Mission Join Assertion The Mission Join of Section 9 rests on subject and client mapping tables that every PDP operates and keeps correct. This section defines an OPTIONAL upgrade from mapping-table equality to a credential-bound proof: the MAS verifies the join centrally and mints a signed assertion of it, so the PDP verifies one signature and one token binding instead of operating a mapping table. A MAS that supports the upgrade publishes its join-assertion endpoint as mission_join_assertion_endpoint (Section 8). The endpoint MUST meet the TLS and caller-authentication requirements of the mission submission endpoint (Section 3). 10.1. Assertion Request The PEP, or the client acting for it, POSTs a JSON object: mission_id: REQUIRED. A string. The Mission the join is asserted against; its issuer is the MAS. access_token: A string. The acting access token. REQUIRED unless the digest pair is present. token_sha256: A string. The unpadded base64url SHA-256 digest of the access token's ASCII bytes. token_jkt: A string. The JWK thumbprint [RFC7638], using SHA-256, of the token's cnf public key. The caller presents access_token, or token_sha256 together with token_jkt. The digest pair keeps the credential itself off this wire, but it is usable only where the deployment's introspection surface can resolve a token by digest; access_token is the interoperable form. The acting token MUST be sender-constrained: a token without a cnf key gives the assertion nothing to bind, and the MAS MUST NOT mint one for it. The MAS verifies the join centrally: 1. It introspects the token at the deployment's Authorization Server [RFC7662], under introspection credentials the MAS holds there. Calling the AS is permitted in MAS mode; changing it is not. A token the AS reports inactive fails the request. 2. It verifies the subject and client joins of Section 9 against the introspection response, under its own documented account and client mappings and delegate policy. A token that does not join is refused with the join_failed error (HTTP 403), in the error format of Section 3.3; like conflict, it extends that section's error code set. An unknown or not-visible mission_id returns not_found, preserving the anti-oracle property. 10.2. The Assertion On success the MAS mints a Mission Join Assertion: a signed JWT [RFC7519] whose protected header carries the typ mission-join+jwt and a kid resolvable in the MAS's jwks_uri. Its claims: iss: REQUIRED. The MAS's issuer URL. mission: REQUIRED. An object containing id, issuer, and authority_hash. token: REQUIRED. An object containing sha256, the token digest as in Section 10.1, and jkt, the thumbprint of the token's cnf public key [RFC7638]. iat: REQUIRED. Issuance time. exp: REQUIRED. Expiry. It MUST NOT exceed the access token's remaining lifetime. aud: OPTIONAL. The PDP or PDPs the assertion is minted for. When the introspected token carries instance identity ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the MAS SHOULD include the instance identifier in the token object: the act entry's sub, and the agent_instance_id where the agent profile ([I-D.draft-mcguinness-oauth-ai-agent-instance]) is in use. Under that profile the cnf key the jkt thumbprint binds is instance- specific, never shared across a client's instances, so the assertion's token binding is materially stronger: it names one runtime instance, not any holder of a client-shared key. The endpoint returns HTTP 200 with a JSON object whose assertion member carries the JWT. Each minting is a join evidence event: the MAS records the Mission reference, the token digest and thumbprint, the authenticated caller, and the validity window, retained for the audit horizon. Example claims: { "iss": "https://mas.example.com", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" }, "token": { "sha256": "rN2kQ4mZ7tP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2n", "jkt": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs" }, "iat": 1793606400, "exp": 1793608200 } 10.3. PDP Consumption A PDP presented with a Join Assertion verifies, in place of the mapping checks of Section 9 steps 3 and 4: * the signature, under a key from the MAS's jwks_uri, and the mission-join+jwt header typ; * that iss and the mission claim match the referenced Mission's issuer, id, and authority_hash; * that exp has not passed and any aud names this PDP; and * the token binding: the presented credential's digest equals token.sha256 and its cnf key's thumbprint equals token.jkt. Every other join rule holds unchanged: the PDP resolves Mission state at the MAS under the runtime profile's freshness rules, denies with mission_mismatch when any check above fails, and draws authority from the Mission. For the high-consequence action classes ([I-D.draft-mcguinness-mission-runtime]) in MAS mode, the PDP SHOULD require a Join Assertion. The mapping join of Section 9 remains the conformance floor: a deployment without the endpoint still joins, and a PDP MUST NOT treat possession of an assertion as authority, per the family rule that references and binding proofs grant nothing. 11. Limitations This section states what MAS-only deployment does not provide. These are structural properties of the mode, not implementation quality issues, and a deployment claiming this profile MUST NOT overstate them. The mode is a *partial-provision binding* in the substrate's terms ([I-D.draft-mcguinness-mission-substrate]): it provides the Mission record, anchors, and lifecycle but not the Mission-bound credential, so enforcement composes entirely through the runtime join and PEP coverage. Among the Mission Assurance Levels this is the Runtime-Enforced level reached through the MAS binding, which provides no Mission-bound credential and no issuance gating ([I-D.draft-mcguinness-mission-architecture]). A deployment claiming this profile MUST state, alongside its enforcement-scope statement: * what the join proves (that the credential belongs to the Mission's subject and client) and what it does not (that the credential was issued under the Mission); * the subject and client mapping granularity, and whether instance identity is included in the join ([I-D.draft-mcguinness-oauth-client-instance-assertion]); * whether Mission Join Assertions are required, which they SHOULD be for the high-consequence classes (Section 10); and * which action paths are covered by runtime enforcement, since nothing at the token layer covers the rest. *No Mission-bound credentials.* Tokens carry no mission claim and no Mission-derived authorization_details. Nothing cryptographically binds a token to the approval event, and no audit anchor travels in credentials: authority_hash reaches consumers only through the MAS's signed status responses and the PDP's evidence, never in the credential a resource actually accepted. Resource Servers cannot enforce Mission authority statelessly from the token. *No issuance gating.* The AS issues and refreshes tokens with no knowledge of Mission state. Revoking a Mission stops nothing at the token layer: every outstanding token, and every token the AS issues after revocation, remains valid OAuth. The Mission kill switch acts only through the runtime layer's state re-check. Because both properties are absent, enforcement rests entirely on PEP coverage. A MAS deployment MUST deploy the runtime profile's enforcement ([I-D.draft-mcguinness-mission-runtime]) over every consequential action path within the scope it claims Mission governance for, and the no-unmediated-path condition consolidated by the security model ([I-D.draft-mcguinness-mission-security-model]) is load-bearing for all of this profile's guarantees, not only for the runtime profile's agent-compromise-resistant tier. A token exercised outside PEP coverage is ungoverned: its use is bounded by ordinary OAuth alone, and no Mission property applies to it. *Weaker expansion and child-creation binding.* Mission Expansion and Child Delegation are carried natively in this mode (Section 7), so a standalone deployment can widen authority and delegate to sub-agents; what the mode does not provide is the OAuth wire's possession binding. Requests are bound to the predecessor or parent by authenticated client identity (Section 7.2), which proves the same registered client, not a held grant (Section 15.3). Offline attenuation remains inapplicable in this mode because it requires the Mission-bound credential (Section 2). *Upgrade path.* Implementing the issuance profile at the AS restores what this mode lacks: Mission-bound credentials and issuance gating. The MAS then serves as the AS's Mission store, or merges into the AS. The Mission record, the integrity anchors, and the lifecycle carry over unchanged, because a MAS operates the issuance profile's own definitions of all three; the enforcement join becomes unnecessary for newly issued tokens, which carry the mission claim. 12. Conformance An implementation conforms in one of two roles. A *Mission Authority Server*: * serves the mission submission endpoint with the validation, media- type dispatch, error, and anti-oracle rules of Section 3; * executes the approval event of Section 4, creating the Mission record active atomically with the approval decision; * records Missions per the issuance profile's Mission Record section and retains each record for the audit horizon; * serves the Mission Status operation and the Mission Lifecycle endpoint with its full operation set (revoke, suspend, resume, complete) per Section 6; * publishes the discovery document of Section 8 with every REQUIRED member; and * issues no token and no artifact that grants access by possession: submission_id and mission_id are references. *Expansion and Child Creation* (Section 7) is a named OPTIONAL capability of the Mission Authority Server role. A MAS claiming it additionally: * accepts the predecessor, parent, and child_actor submission members, with the dispatch and refusal rules of Section 7.1; * verifies the binding of Section 7.2 before adjudicating: the authenticated submitting client equals the predecessor's or parent's recorded client_id, and, for expansion, the established Subject equals the predecessor's subject; * applies the expansion profile's rules by reference: predecessor active, reconciliation serialization, supersession atomicity, and the lineage members (Section 7.3); * applies the child-delegation profile's rules by reference: the children on-switch, strict subset, fan-out accounting, parent construction, cascade, and child client identity (Section 7.4); and * carries the profiles' closed code sets in mission_expansion_status and mission_denial_reason on its error and submission-status surfaces (Section 7.1). A *Mission-joining PDP*: * resolves referenced Missions at the MAS through the Mission Status operation and treats the MAS as its Mission state source under the runtime profile's freshness rules (Section 9); * verifies the subject join and the client join before evaluating authority, and denies with mission_mismatch on any join failure; * evaluates joined actions under the runtime profile's decision contract, drawing authority from the Mission; and * when the AuthZEN binding is in use, emits Decision Evidence per [I-D.draft-mcguinness-mission-authzen], recording the Mission reference the join was verified against. 13. The Enterprise Mission Authority Profile The conformance floor above makes a MAS deployable. This profile is the operating profile for a MAS used as an estate's Mission control plane: it turns the floor's SHOULDs and OPTIONALs into the guarantees an enterprise deployment needs. A deployment claims the Enterprise Mission Authority Profile only when all of the following hold; it is the Runtime-Enforced level of the Mission Assurance Levels under the MAS binding, with the obligations below ([I-D.draft-mcguinness-mission-architecture]). * *Status and lifecycle.* The MAS MUST serve the Mission Status operation and the Mission Lifecycle endpoint with signed responses (Section 6), so state and the kill switch are available estate- wide. * *Active freshness.* For the high-consequence action classes, the MAS-served state MUST be an active freshness source with a published staleness bound, meeting the runtime profile's requirement for those classes ([I-D.draft-mcguinness-mission-runtime]); token-lifetime expiry alone does not qualify. * *Join Assertion.* The MAS MUST offer the Mission Join Assertion (Section 10), and for the high-consequence classes the PDP MUST require one: the mapping join (Section 9) is the baseline compatibility mode, and the Join Assertion is the enterprise mode, because it centralizes subject and client mapping at the MAS, binds the proof to one token digest and key thumbprint, and produces audit evidence rather than leaving each PDP to maintain mapping tables. * *Instance-bound joins.* Where the acting credential carries a client-instance identity ([I-D.draft-mcguinness-oauth-client-instance-assertion]), a high- consequence join MUST bind (subject, client, instance), not (subject, client), so a single workload joins rather than every workload sharing a gateway client_id. * *Runtime enforcement.* Consequential actions MUST be enforced under the runtime profile and its AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]), with documented PEP coverage published in the runtime profile's Enforcement Scope Statement. * *Audit evidence.* Joins and decisions MUST produce runtime evidence retained for the audit horizon ([I-D.draft-mcguinness-mission-runtime]). 13.1. The Enterprise Mapping Contract The dominant MAS risk is a coarse or drifting join: shared client_id values, many-to-one directory mappings, and workload identity that the join collapses (Section 15.1). An enterprise MAS MUST publish a mapping contract stating, for the joins it performs: * the subject namespace mapping (how a credential's authenticated subject maps to the Mission's subject); * the client namespace mapping (how a credential's client maps to the Mission's client_id); * the delegate policy applied to act-chain actors; * whether client-instance identity is supported and required; * a mapping version identifier, so a mapping change is detectable; * an audit record for each mapping decision; and * the failure semantics, which MUST fail closed with mission_mismatch on any unresolved or ambiguous mapping. 13.2. Policy View Distribution An enterprise MAS MAY serve audience-scoped Authority Set views, or the runtime profile's materialized policy view ([I-D.draft-mcguinness-mission-runtime]), to the PDPs that enforce for each audience, rather than each PDP resolving full Mission state per action. This is what makes the MAS the estate's approved-task authority distribution point: it distributes bounded, audience-scoped authority derived from the Mission, not tokens. The view is served under the Mission Status operation's authentication and anti-oracle rules, carries the Mission's authority_hash as its consent anchor, and does not widen authority beyond the Authority Set. 14. Deployment This section is non-normative. It shows where a MAS lands in a real estate and how a deployment adopts it incrementally. 14.1. Topology A typical MAS deployment runs the MAS beside the existing identity provider and Authorization Server, changing neither: * the MAS records Missions, runs approvals, operates the lifecycle, and signs Mission Status; * a PEP at the enforcement boundary (an API gateway, a service-mesh sidecar, an MCP or tool gateway, a SaaS connector, a workflow orchestrator, or a legacy-API wrapper) presents the Mission reference and calls a PDP before each consequential action; * the PDP runs the runtime profile's decision contract and its AuthZEN binding, drawing authority from the MAS-served Authority Set or a materialized policy view (Section 13.2); * the MAS mints a Join Assertion after introspecting the presented token, so the PDP verifies one signed proof rather than a mapping table; and * runtime decision and execution evidence flows to the deployment's audit sink. 14.2. Connector Patterns The PEP is wherever consequential effects can be refused before they happen. Common placements, all non-normative: * *API gateway PEP*: refuses at the gateway in front of a protected API. * *Service-mesh sidecar PEP*: refuses at the sidecar for service-to- service calls. * *SaaS connector PEP*: refuses in the connector mediating a SaaS API. * *MCP or tool-server PEP*: refuses at the tool boundary an agent invokes. * *Workflow or orchestrator PEP*: refuses at the step boundary of a governed workflow. * *Legacy-API wrapper PEP*: refuses in a wrapper fronting a system that cannot itself enforce. Each is credible only to the extent it has no unmediated bypass, which the runtime profile's Enforcement Scope Statement must state ([I-D.draft-mcguinness-mission-runtime]). 14.3. Progressive Adoption A MAS is adopted level by level across the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]), each phase independently useful: 1. The MAS records Missions and approvals: governance and audit of what tasks were approved, with no enforcement change yet. 2. Mission Status and lifecycle become the estate-wide kill switch: consumers fail safe on non-active state. 3. PEP/PDP runtime enforcement gates consequential actions per the runtime profile. 4. Join Assertions and instance-bound joins harden the join for the high-consequence classes (the Enterprise profile). 5. Where a particular AS later becomes Mission-aware, it adds Mission-bound tokens and issuance gating for its own resources, while the MAS record, lifecycle, and authority model continue to govern the rest of the estate. A deployment stops at the phase its risk warrants; nothing above the floor is required to begin. The MAS is not a throwaway bridge but the enduring control plane of the family's delegated-authority layer ([I-D.draft-mcguinness-mission-architecture]), which a deployment keeps even as individual Authorization Servers become Mission-aware. 15. Security Considerations 15.1. Join Spoofing A client cannot gain authority by asserting another party's mission_id: the join requires the credential's authenticated subject and client to match values the MAS recorded at approval, which the client cannot alter, so a reference to someone else's Mission fails with mission_mismatch. The residual is mapping coarseness. Where the deployment's account mapping is many-to-one (several AS accounts map to one directory subject), any credential in the equivalence class joins; a deployment SHOULD keep the mapping one-to-one for subjects that hold Missions and MUST document its granularity. The client join is coarse the same way where several workloads share one client_id: any of them joins. Client instance assertions ([I-D.draft-mcguinness-oauth-client-instance-assertion]) are the standard fix: the join then binds the validated instance (Section 9), and this residual remains only for deployments without instance identity. A second residual: two Missions held by the same subject and client are distinguished only by the PEP-supplied reference, so a faulty or compromised PEP can attribute work to the wrong same-party Mission, bounded by that Mission's authority and visible in evidence. The Mission Join Assertion (Section 10) is the mitigation for the coarse-mapping and shared-client residuals: the MAS evaluates the mapping once, centrally, under its documented policy, and binds the result to one introspected token by digest and key thumbprint, so the join stops being a standing property of every credential in an equivalence class and becomes a minted, audited, token-bound event. 15.2. Join Assertion Trust A captured Join Assertion moves no authority: it names one token by digest and key thumbprint, so a replay without that token and its sender-constraint key proves nothing, and exp, capped at the token's remaining lifetime, bounds the window in which the proof is live. The introspection call names a trust relationship specific to this upgrade: the MAS relies on the deployment's AS, through RFC 7662 introspection, for the token's validity, subject, and client, and the deployment documents that reliance and protects the MAS's introspection credentials accordingly. The structural gain is concentration: the subject and client mappings are evaluated at one audited point under one documented policy, instead of configured independently at N PDPs, where one drifted table is a silent join widening. 15.3. Expansion and Child-Creation Binding The native surfaces of Section 7 bind a request to its predecessor or parent by authenticated client identity, not by grant possession, and the residual is exactly that difference: a compromised or impersonated registered client can request expansion or child creation for any Mission recorded under its client_id, where token possession would have limited it to the grants it actually holds. The mitigations: instance-grade binding ([I-D.draft-mcguinness-oauth-client-instance-assertion]) shrinks the client_id equivalence class to one runtime instance, and a Mission Join Assertion presented with the submission makes that instance a verified, token-bound party (Section 7.2); the expansion profile's fresh-approval requirement means no widening activates without the Approver, so a forged expansion request yields an approval prompt, not authority; the child-delegation profile's fan-out controls bound what child creation can amplify; and the binding failure surface is anti-oracle (Section 7.1), so a request against a Mission the client is not bound to is indistinguishable from one against a Mission that does not exist. 15.4. Ambient Authority of Ungated Tokens The central residual of this mode: tokens are ordinary OAuth tokens, so within their lifetime and scope they work wherever PEP coverage is absent, and Mission revocation does not touch them. Mitigations are short token lifetimes at the AS, narrow scope hygiene for agent clients, and complete PEP coverage of consequential paths; none eliminates the residual, which only the issuance profile's gating removes (Section 11). 15.5. MAS Availability The runtime layer fails closed when Mission state cannot be established within the staleness bound, so a MAS outage converts into work stoppage for governed actions, not into loosened enforcement (the availability trade the security model states, [I-D.draft-mcguinness-mission-security-model]). A deployment provisions MAS availability accordingly and sizes mission_max_stale_seconds to the caching it can tolerate. 15.6. MAS Compromise Compromise of a MAS is equivalent to Mission Issuer compromise: it can forge approvals, alter records, and report false state. One consequence is specific to this mode: the PDP join is the only credential-to-Mission binding, so a compromised MAS combined with the PDP's trust in it yields arbitrary attribution of authority to any credential the join accepts. Consent Evidence commitments ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) and audit transparency ([I-D.draft-mcguinness-mission-audit]) make forgery detectable after the fact; signing-key custody and the status profile's key-retention rules keep archived state evidence verifiable. 15.7. Approval Surface Authentication The MAS's review surface is the approval event surface, and the issuance profile's approval rules apply to it unchanged: the Approver is authenticated to the acr mapping, the Subject is never taken from client input, client text is rendered inert, and derived authority is visually distinguished from it (Section 4). The submission, status, and lifecycle endpoints reject unauthenticated callers and preserve the anti-oracle property ([I-D.draft-mcguinness-oauth-mission-status]). 16. Privacy Considerations A MAS holds task data centrally: every governed Mission Intent (goals, constraints, purposes) and every Mission record, outside the AS that holds the deployment's identity data. The issuance profile's minimization guidance applies: collect only the Intent members the task needs, audience-filter every disclosure surface per the status profile's rules, and treat submission, status, and lifecycle logs as PII sinks. Retention is anchored on the issuance profile's audit horizon: records are retained at least that long, and SHOULD NOT be retained materially longer without a documented basis. 17. IANA Considerations 17.1. Well-Known URI Registration IANA is requested to register the following in the "Well-Known URIs" registry [RFC8615]: * URI Suffix: mission-authority-server * Change Controller: IETF * Specification Document: this document, Section 8 * Status: permanent * Related Information: none 17.2. Mission Authority Server Metadata Registry IANA is requested to create the "Mission Authority Server Metadata" registry, with a registration policy of Specification Required [RFC8126]. Each entry has: Member Name, Change Controller, and Reference. The registry is seeded with the members of Section 8; for each, Change Controller IETF and Reference this document: * issuer * mission_submission_endpoint * mission_status_endpoint * mission_status_signing_alg_values_supported * mission_lifecycle_endpoint * mission_auth_methods_supported * mission_join_assertion_endpoint * mission_event_stream_endpoint * mission_max_stale_seconds * jwks_uri 17.3. Runtime Denial Reason mission_mismatch extends the denial-reason set of [I-D.draft-mcguinness-mission-authzen] under that profile's denial- reason extensibility rule (Section 9). That profile's denial reasons are AuthZEN extension data and are not registered in an IETF registry, so this document requests no IANA action for it. 18. References 18.1. Normative References [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . 18.2. Informative References [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-security-model] McGuinness, K., "Mission Security Model", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-ai-agent-instance] McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth- ai-agent-instance-00, 4 July 2026, . [I-D.draft-mcguinness-oauth-client-instance-assertion] McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth- client-instance-assertion-01, 24 June 2026, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-attenuation] McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-progressive] McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . Appendix A. MAS-Mode End-to-End Example This appendix is non-normative. It stages the standalone binding end to end on one Mission; the architecture's MAS-mode sequence diagram shows the same stages in temporal order ([I-D.draft-mcguinness-mission-architecture]). A.1. Submit The client proposes the Mission by POSTing its Mission Intent to the submission endpoint; the MAS validates it, derives the Authority Set under policy, and returns a pending-submission reference (Section 3). POST /mas/mission/submit HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... { "goal": "Reconcile Q3 invoices and post adjustments under $500.", "resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z" } HTTP/1.1 202 Accepted Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP", "status": "pending", "expires_at": "2026-10-16T14:32:11Z" } A.2. Poll to Approved The MAS routes the submission to its approval surface; the Approver authenticates, reviews the rendered Authority Set, and approves, and the MAS creates the Mission active atomically with the decision (Section 4). The client's next poll returns the Mission reference and its consented authority (Section 5). HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP", "status": "approved", "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "authorization_details": [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read", "journal-entries.write"], "constraints": { "max_amount": { "amount": "500.00", "currency": "USD" } } } ] } A.3. Join The agent works under an ordinary OAuth token from the unchanged AS, which carries no Mission signal. For the first consequential action, the PEP supplies the Mission reference, with authority_hash and state from the MAS's signed Mission Status response, and the PDP verifies the subject and client joins (Section 9). { "subject": { "type": "user", "id": "user_3p2q8mN1a0kV7tR", "properties": { "iss": "https://idp.example.com" } }, "resource": { "type": "invoice", "id": "inv_2026Q3_842" }, "action": { "name": "invoices.read" }, "context": { "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active" } } } A.4. Permit The join holds and the action is within the Mission's Authority Set, so the PDP permits; the PEP executes the call to https://erp.example.com, and both record their evidence ([I-D.draft-mcguinness-mission-authzen]). A revocation at the MAS stops the next such action at this step, through the runtime state re-check. { "decision": true, "context": { "decision_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t", "action_class": "irreversible_action", "class_source": "resource_floor", "permit_expires_at": "2026-11-02T08:15:30Z" } } Acknowledgments This document is part of the Mission-Bound Authorization for OAuth 2.0 work. It profiles the Mission Issuer role for deployments whose Authorization Server cannot change, and builds on the Mission Status and Lifecycle, Mission-Bound Runtime Enforcement, and AuthZEN profile companions. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com