Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 5 October 2026 Expires: 8 April 2027 Mission Authority Server draft-mcguinness-mission-authority-server-latest Abstract This specification defines the Mission Authority Server (MAS), a standalone service that implements the Mission Issuer role of Mission-Bound Authorization for OAuth 2.0 (the OAuth binding) 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. 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 standalone binding leaves Authorization Servers unchanged and provides no Mission-bound credentials or issuance gating; the OAuth binding provides both, and the issuance-grant companion restores them at Authorization Servers that redeem its grants. This document defines a conformance floor and an Enterprise Mission Authority Profile. 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 April 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. Protocol Overview 1.2. Applicability 2. Conventions and Terminology 3. Mission Submission 3.1. Intent Submission 3.2. Submission Status 3.3. Mission Reference Delivery 3.4. Error Responses 4. Mission Approval 5. Mission Lifecycle and State 5.1. Join Disclosure 6. Mission Join 6.1. Join Rules 6.2. What a Join Establishes 6.3. Acting Credentials 6.4. Instance-Bound Joins 6.5. AuthZEN Encoding 7. Mission Reference Propagation 7.1. The Reference Tuple 7.2. HTTP Carriage: Mission-Reference 7.3. MCP Carriage 7.4. Verification and Conflict 7.5. Forwarding and Privacy 8. Mission Join Assertion 8.1. Assertion Request 8.2. The Assertion 8.3. PDP Consumption 9. Mission Expansion and Child Creation 9.1. Submission Carriage 9.2. Request Binding 9.3. Expansion Semantics 9.4. Child-Creation Semantics 9.5. Expansion Example 10. Mission Authority Server Metadata 11. Limitations 12. The Enterprise Mission Authority Profile 12.1. High-Consequence Binding 12.2. Estate Prerequisites 12.3. The Enterprise Mapping Contract 12.4. Policy View Distribution 13. Conformance 14. Mission Substrate Statement 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. Signing-Key Custody 15.7. MAS Compromise 15.8. Approval Surface Authentication 16. Privacy Considerations 17. IANA Considerations 17.1. HTTP Field Name Registration 17.2. Well-Known URI Registration 17.3. Mission Authority Server Metadata Registry 17.4. Media Type Registration 17.4.1. Mission Join Assertion Media Type 17.5. Mission Denial Reason Registration 17.6. Runtime Denial Reasons 18. References 18.1. Normative References 18.2. Informative References Appendix A. Deployment Guidance A.1. Topology A.2. Connector Patterns A.3. Progressive Adoption Appendix B. MAS-Mode End-to-End Example B.1. Submit B.2. Poll to Approved B.3. Join B.4. Permit B.5. Revoke Appendix C. Document History Acknowledgments Author's Address 1. Introduction Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the "OAuth binding") binds issued authority to a durable, human-approved Mission. In the OAuth binding, the OAuth Authorization Server (AS) [RFC6749] plays the Mission Issuer role: the AS validates the Mission Intent, runs the approval event, records the Mission, derives Mission-bound tokens, and gates issuance on Mission state. Deploying the OAuth binding requires changing the AS. Many deployments cannot make that change, because the AS is a shared or third-party service. This document defines the *Mission Authority Server (MAS)* for those deployments: a standalone service that implements the Mission Issuer role of the OAuth binding 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 6). Per-action enforcement then proceeds under the runtime profile [I-D.draft-mcguinness-mission-runtime], which applies unchanged. The MAS mode does not provide Mission-bound credentials or issuance gating; a deployment that changes its AS obtains both (Section 11). The MAS mode is a peer binding, not a staging area. A deployment can keep governance decoupled from token issuance as its long-term architecture. An enterprise that governs agent tasks across many Authorization Servers, SaaS tenants, APIs, and tool gateways can use a central MAS as the one place that holds the approved task, its lifecycle, and its authority, independent of which system issued a given token. A central MAS can remain in that role after some Authorization Servers become Mission-aware. A deployment that later wants Mission-bound tokens at a particular AS can move issuance into that AS. The record, anchors, and lifecycle carry over unchanged, because a MAS operates the OAuth binding's own definitions of them. The MAS continues to govern the rest of the estate (Section 11). 1.1. Protocol Overview This section is non-normative. The following figure shows the flow for one Mission: submission, approval, polling, and an action decided under the Mission Join. Client MAS Approver PEP/PDP | | | | | 1 submit Intent | | | |------------------->| | | | 2 202 pending | | | |<-------------------| | | | | 3 disclose | | | |----------------->| | | | 4 approve | | | |<-----------------| | | | Mission active | | | 5 poll | | | |------------------->| | | | 6 approved, | | | | mission_id | | | |<-------------------| | | | 7 action, token, | | | | Mission ref | | | |--------------------------------------------------->| | | 8 signed status: | | | | active | | | |<------------------------------| | |------------------------------>| | | | 9 join; | | | | evaluate | | 10 permit | | | |<---------------------------------------------------| Figure 1: MAS-mode flow * Steps 1 and 2: the client submits a Mission Intent to the mission submission endpoint and receives a pending-submission reference (Section 3.1). * Steps 3 and 4: the MAS routes the submission to its approval surface; on approval it records the Mission in the active state (Section 4). * Steps 5 and 6: the client polls submission status and receives the mission_id and the consented authority (Section 3.3). * Step 7: the client acts with an ordinary access token from the deployment's unchanged authorization server, and the PEP supplies the Mission reference from its Mission binding, deployment configuration, or a propagated reference (Section 6.1, Section 7). * Steps 8 and 9: the PDP resolves the Mission through the MAS's signed Mission Status (Section 5), joins the presented credential to the Mission, and evaluates the action under the runtime profile (Section 6). * Step 10: the PEP enforces the decision. After a revocation at the MAS, the PDP refuses the next such action once its state check at step 8 observes the revocation, which happens within the published staleness bound (Section 5). A Join Assertion moves the join's verification to the MAS (Section 8). Mission Expansion and Child Creation use the submission endpoint (Section 9). Appendix B shows the same flow with concrete messages. 1.2. 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. A deployment MAY also 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 OAuth binding. 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). 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 also uses the following terms: Mission Authority Server (MAS): A service that implements the Mission Issuer role of the OAuth binding 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 6). Standalone binding: The deployment mode this document defines: the Mission Issuer role implemented by a MAS, with the deployment's tokens unchanged. "MAS mode" and "AS-optional" are informal names for it. Mapping join: The baseline Mission Join: the PDP compares the presented credential's authenticated subject and client with the Mission's recorded parties under the deployment's documented mappings (Section 6.1). Mapping contract: The documented subject, client, delegate, and instance mappings a deployment's joins apply (Section 6.1); an Enterprise MAS publishes it (Section 12.3). Join Assertion: A MAS-signed JWT stating that one access token, introspected or locally validated, joins a Mission (Section 8). Mission-selection assertion: The Mission reference a requester attaches to a request. It selects the Mission a join is evaluated against and grants nothing (Section 7). High-consequence action classes: The irreversible-action, external- commitment, and privileged-administration classes of [I-D.draft-mcguinness-mission-runtime]. 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 10). The endpoint MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED), following the recommendations of [RFC9325]. The endpoint MUST authenticate the client using the authentication mechanisms of the Mission Status endpoint ([I-D.draft-mcguinness-oauth-mission-status]): mTLS client authentication, a DPoP- or mTLS-bound access token, or private-key JWT, with a token's audience and a client assertion's aud naming this endpoint. The MAS advertises the accepted methods in the mission_submission_endpoint_auth_methods_supported metadata member (Section 10). Client registration with a MAS is deployment-defined. The MAS records the client identifier it authenticates 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 Submission envelope (Section 3.1). * *Submission status*: an HTTPS POST with an application/x-www-form- urlencoded body containing a submission_id parameter (Section 3.2). The MAS MUST reject a request of any other media type with HTTP 415 (Section 15.5.16 of [RFC9110]) and the unsupported_media_type error code, so a client can tell a media-type error from an invalid Intent. 3.1. Intent Submission The request body is a Mission Intent Submission envelope as the OAuth binding defines it: intent plus OPTIONAL evidence. The OAuth binding's validation and Intent Submission Evidence rules ([I-D.draft-mcguinness-oauth-mission]) and those of [I-D.draft-mcguinness-oauth-mission-submission-evidence] apply unchanged. The submission is untrusted client input and never authority. The MAS MUST bound the submission's total size, array lengths, evidence entry count, and evidence verification cost ([I-D.draft-mcguinness-oauth-mission-submission-evidence], Section "Bounded Verification"). The envelope and the Intent are both closed at the top level. The OAuth binding's error outcomes map to this endpoint's error codes (Section 3.4): * If the body cannot be parsed as a JSON [RFC8259] object, is structurally invalid, exceeds the deployment's size bounds, or contains a top-level member the OAuth binding does not define, the MAS MUST reject it with the invalid_mission_intent error code (the MAS equivalent of the OAuth binding's invalid_request rejections, including reject-unknown-top-level-member). * If the Intent is well formed but the MAS cannot derive a valid Authority Set from it under policy, the MAS MUST reject it with the invalid_authority error code, so a client can distinguish a syntax error from an authority-derivation failure. This code is the MAS's single equivalent of the OAuth binding's two derivation- failure outcomes ([I-D.draft-mcguinness-oauth-mission]): invalid_authorization_details for a submitted proposal and access_denied for configured-mapping mode. * If an Intent Submission Evidence entry is of an unsupported type or fails its type's verification, or a policy-required evidence type is absent from the submission ([I-D.draft-mcguinness-oauth-mission-submission-evidence], Section "Required Evidence Is Resolved Before Derivation"), the MAS MUST reject the submission with the invalid_mission_intent_evidence error code. This is the code the OAuth binding registers for the same condition, carried here in the MAS error body. Presented evidence is never silently ignored. The request body MAY additionally carry an authorization_details member: the client's authority proposal, an array of authorization_details objects [RFC9396]. This member is this document's proposal carriage, replacing the OAuth binding's PAR-only carriage rule. The OAuth binding's validation, derivation, recording, and hashing semantics apply to it unchanged ([I-D.draft-mcguinness-oauth-mission]). It is a proposal, never authority, and a submission member, not a Submission-envelope member (Section 9.1): the MAS MUST remove it before applying the envelope validation above. The OAuth binding's intake refusals for a proposed entry map to invalid_authority here. A Mission created from a submission carrying a proposal records proposed_authority and proposal_hash as the OAuth binding's Mission record defines them. A MAS has no derivation event: no token is issued under the Mission, so a requested_derivation_limit member ([I-D.draft-mcguinness-oauth-mission-derivation-limits]) binds nothing here. A MAS implementing the issuance-grant companion ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) has a derivation event per grant minted and applies that companion's counting rule. Where a MAS has no derivation event, it SHOULD refuse an Intent that carries a requested_derivation_limit member, with the invalid_mission_intent error code and requested_derivation_limit as the error_reason, or record the member and ensure the approval rendering marks it non-binding, per the OAuth binding's rule that consent is not given to a limit that binds nowhere. The same treatment applies to any future Mission Intent member scoped to an issuance event. On acceptance, the MAS derives the Authority Set from the Intent, and from the authority proposal where one was submitted, under the OAuth binding'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. interval: OPTIONAL. A positive integer. The minimum number of seconds between submission-status requests for this submission (Section 3.2). The following example shows a submission and its response: POST /mas/mission/submit HTTP/1.1 Host: mas.example.com Content-Type: application/json Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... { "intent": { "goal": "Reconcile Q3 invoices and post adjustments under $500.", "target_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 for the outcome with a form-urlencoded POST carrying: submission_id: REQUIRED. A string. The submission_id the MAS returned on acceptance. A submission is in one of four states: +==========+===========================================+ | status | Meaning | +==========+===========================================+ | pending | Awaiting an approval decision. | +----------+-------------------------------------------+ | approved | Approved; a Mission exists (Section 3.3). | +----------+-------------------------------------------+ | 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 OAuth binding's only-active rule. Every submission-status response carries submission_id and status. A denied response carries mission_denial_reason where adjudication of an expansion or child creation denied the submission (Section 9.1); like every status response, it goes only to the submitting client. The interval in force for a submission is the most recent interval the client received for it, or 5 seconds if it has received none. A pending status response that carries interval replaces the interval in force; one that omits it leaves it unchanged, and a value that is not a positive integer is ignored. The client MUST wait at least the interval in force between submission-status requests for a submission, measured from its receipt of the preceding response for that submission (the 202 or a status response). A client that polls faster may receive the rate_limited error code (Section 3.4). 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. 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. mission_expires_at: REQUIRED. A string. The Mission's effective expires_at. It is the OAuth binding's common Mission-creating response member ([I-D.draft-mcguinness-oauth-mission]): this response is the success response that first delivers the Mission's identifier, and no OAuth credential accompanies it here. authorization_details: REQUIRED. An array. The consented Authority Set, from which the client learns its granted authority. This response is the MAS counterpart of the OAuth binding's token- response authorization_details echo. The following example shows an approved status response: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP", "status": "approved", "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "mission_expires_at": "2026-12-31T23:59:59Z", "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 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. 3.4. Error Responses On a hard failure, the MAS 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, including a refused requested_derivation_limit (Section 3.1); for invalid_authority, the target_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. An authentication failure takes the outcome Mission Status defines for its endpoints ([I-D.draft-mcguinness-oauth-mission-status], Section "Authentication Failures"). A 401 unauthorized response carries the WWW-Authenticate challenges that Mission Status defines for its endpoints, naming the Protected Resource Metadata of the endpoint called. A failed mTLS or private-key-JWT client authentication receives 400 invalid_client, not a token challenge, and an authenticated caller to whom a submission or Mission is not visible still receives not_found. +=================================+====+===========+================+ | error |HTTP|Returned by|Description | +=================================+====+===========+================+ | invalid_mission_intent |400 |submission |Unparseable, | | | | |structurally | | | | |invalid, | | | | |oversized, or | | | | |containing an | | | | |undefined top- | | | | |level member. | +---------------------------------+----+-----------+----------------+ | invalid_authority |400 |submission |Well-formed | | | | |Intent, but no | | | | |valid Authority | | | | |Set is | | | | |derivable under | | | | |policy. | +---------------------------------+----+-----------+----------------+ | invalid_mission_intent_evidence |400 |submission |An evidence | | | | |entry of | | | | |unsupported | | | | |type or failing | | | | |its type's | | | | |verification, | | | | |or a policy- | | | | |required | | | | |evidence type | | | | |absent from the | | | | |submission. | +---------------------------------+----+-----------+----------------+ | unsupported_media_type |415 |submission |The request | | | | |media type is | | | | |neither of the | | | | |two the | | | | |endpoint | | | | |dispatches on | | | | |(Section 3). | +---------------------------------+----+-----------+----------------+ | invalid_client |400 |submission,|Direct client | | | |join |authentication | | | |assertion |(mTLS or | | | | |private-key | | | | |JWT) failed, or | | | | |no credential | | | | |was presented | | | | |where no | | | | |access-token | | | | |scheme is | | | | |accepted, as | | | | |Mission Status | | | | |defines. | +---------------------------------+----+-----------+----------------+ | unauthorized |401 |submission,|Access-token | | | |join |authentication | | | |assertion |failed, or no | | | | |credential was | | | | |presented where | | | | |an access-token | | | | |scheme is | | | | |accepted; the | | | | |response | | | | |carries the | | | | |challenges | | | | |Mission Status | | | | |defines. | +---------------------------------+----+-----------+----------------+ | invalid_join_request |400 |join |The request | | | |assertion |body is not a | | | | |JSON object | | | | |carrying | | | | |mission_id, a | | | | |string | | | | |audience, and | | | | |exactly one | | | | |token form | | | | |(Section 8.1). | +---------------------------------+----+-----------+----------------+ | join_failed |403 |join |The referenced | | | |assertion |Mission is not | | | | |active, the | | | | |audience names | | | | |no enrolled | | | | |PDP, or the | | | | |acting token is | | | | |inactive, | | | | |carries no cnf | | | | |confirmation, | | | | |or does not | | | | |join the | | | | |referenced | | | | |Mission | | | | |(Section 8.1). | +---------------------------------+----+-----------+----------------+ | not_found |404 |submission,|A referenced | | | |join |submission or | | | |assertion |Mission does | | | | |not exist or is | | | | |not visible to | | | | |the caller. | +---------------------------------+----+-----------+----------------+ | conflict |409 |submission |A resolved | | | |(expansion,|predecessor or | | | |child |parent whose | | | |creation) |state or | | | | |serialization | | | | |refuses the | | | | |operation | | | | |(Section 9.1). | +---------------------------------+----+-----------+----------------+ | rate_limited |429 |submission,|Caller is rate- | | | |join |limited. | | | |assertion | | +---------------------------------+----+-----------+----------------+ | unavailable |503 |submission,|MAS temporarily | | | |join |cannot serve | | | |assertion |the request. | +---------------------------------+----+-----------+----------------+ Table 2: MAS error codes A companion profile's machine-readable codes are carried in the members Section 9.1 names (mission_expansion_status and mission_denial_reason), not as additional error values. These responses follow the OAuth-shaped surfaces' shared error idiom [I-D.draft-mcguinness-oauth-mission-status]: a JSON object body with error and error_description, served as application/json with Cache- Control: no-store; error_description is diagnostic and never authorization input. On this surface, error_description and error_reason are OPTIONAL, and error_reason is MAS-specific. The MAS does not carry nonce: that member's requiredness on the status and lifecycle surfaces ([I-D.draft-mcguinness-oauth-mission-status]) and on Mission Management ([I-D.draft-mcguinness-oauth-mission-management]) does not extend here. 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 OAuth binding's approval event unchanged ([I-D.draft-mcguinness-oauth-mission]): 1. Authenticate the Approver; this authentication MUST satisfy the deployment's published approval-authentication floor ([I-D.draft-mcguinness-oauth-mission]). The OAuth binding's direct flow carries a client-requested Approver authentication strength in the acr_values and max_age authorization request parameters. A MAS receives no authorization request, and this document defines no MAS-native carriage for that strength, so the floor alone governs. 2. Establish the Subject under the OAuth binding'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 OAuth binding'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, intent_hash, and, where an authority proposal was submitted, proposal_hash) using the OAuth binding'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 OAuth binding'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: approval at a MAS is inherently deferred. A declined submission resolves to denied. Mission Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) composes unchanged, with the MAS as the committing issuer for any consent- disclosure commitment. 5. Mission Lifecycle and State In MAS mode, there are no Mission-bound tokens, so no token introspection reports Mission state. The Mission Status profile's surfaces are how a consumer observes or changes Mission state. A MAS 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 OAuth binding'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 10) with the semantics those profiles define for the members of the same names. 5.1. Join Disclosure A Mission-joining PDP compares a presented credential with the Mission's Subject and client (Section 6.1). The MAS discloses both in its Mission Status responses, as members of the mission object, which the Mission Status profile lets a companion add ([I-D.draft-mcguinness-oauth-mission-status]): subject: An object carrying the Mission's iss and sub: the Subject the MAS established at approval (Section 4). client_id: A string. The Mission's client_id (Section 3). When the authenticated caller is a PDP enrolled for the Mission's enforcement scope, the MAS MUST include subject and client_id, and MUST disclose each authorization_details entry in the response with its delegation member as recorded. For any other caller, the MAS MUST NOT include subject or client_id. These members describe the Mission; the response envelope's sub still identifies the requesting caller. The PDP reads them from the Mission Status response it resolves (rule 2 of Section 6.1). A PEP does not copy them into context.mission, whose subject member the AuthZEN profile populates only from a verified token or delegation chain ([I-D.draft-mcguinness-mission-authzen]). The PEPs and PDPs enrolled for a Mission's enforcement scope are deployment configuration that the MAS holds. This document defines no enrollment protocol: the MAS authenticates the caller and checks it against that configuration. The same set bounds visibility at the join-assertion endpoint and the audience it accepts (Section 8.1). 6. 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. When no cryptographic binding exists, a permit "under this Mission" rests on the join. This section defines the baseline mapping join. The Mission Join Assertion (Section 8) builds on it. The Enterprise profile requires Mission-bound credentials for the high-consequence classes and Join Assertions on the other joined, PDP-gated paths (Section 12). 6.1. Join Rules 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]), from deployment configuration, or from a trusted propagated reference (Section 7). In the AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]) this reference is context.mission, with authority_hash where the MAS's signed Mission Status response discloses it as OPTIONAL enrichment beyond the required id and issuer; the Mission state the PEP observed travels in context.mission_state_observation. 2. *The PDP resolves the Mission at the MAS.* The PDP MUST resolve the referenced Mission through the MAS's Mission Status operation. The PDP 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. The Mission's subject, client_id, and entry delegation members come from that response's join disclosure (Section 5.1). 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 record the client mapping in its mapping contract (Section 12.3), exactly as for subjects. 5. *Delegate narrowing.* When the joined party is a delegate rather than the Mission's client_id, the PDP MUST narrow the effective Authority Set to the delegable subset under the OAuth binding's per-entry delegation rules ([I-D.draft-mcguinness-oauth-mission]): entries without a delegation member are excluded, allowed_delegates is applied, and max_depth is evaluated from the deployment's actor records rather than from a Mission-bound token's act chain. A delegate with no actor record under the Mission is not recorded as acting under it, and the join fails with mission_binding_failed. 6. *Join failure is a deny.* A failure of the subject or client join MUST be denied with the mission_binding_failed denial reason, the AuthZEN profile's classification of a failed externally- established binding join ([I-D.draft-mcguinness-mission-authzen]): the presented credential does not join to the referenced Mission because 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 PDP MUST NOT fall back to evaluating the action against the referenced Mission's authority when the join fails. 7. *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. 8. *The permit intersects three bounds.* A permit under a join never exceeds any of three independently evaluated bounds: the authority the acting credential itself carries (the token as issued, enforced at the Resource Server or gateway), the Mission's approved authority, and current Resource policy. The join adds the Mission bound and MUST NOT widen either of the other two. A PEP MUST NOT treat a Mission permit as overriding what the credential or the resource would refuse. 9. *Joined-view evidence commitment.* The PDP MUST record a joined- view commitment, join_view_id, as a top-level member of the Decision Evidence ([I-D.draft-mcguinness-mission-runtime-evidence]) of every decision reached over a successful join, including one that policy then denies. It is separate from policy_view_id, which alone does not distinguish a joined decision from a direct one, and it is absent for a failed join and for a direct Mission-bound decision; the AuthZEN response carries no view identifier. join_view_id MUST change whenever the joining client identifier, the join disposition (the Mission's own client_id or an authorized delegate), or the resulting effective Authority Set differs, so a verifier can tell a joined decision's evidence from a direct Mission-bound decision's, and one joined view from a differently-joined one. This document does not specify the commitment's construction. 6.2. What a Join Establishes The join proves that the credential belongs to the subject and client the Mission names, never that the credential was issued for the Mission. No MAS-mode mechanism can prove derivation under the Mission, because the AS issues tokens with no knowledge of Missions (Section 11). No assertion raises this ceiling. For the high-consequence classes, association is therefore not the end state. The issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) or native Mission-bound issuance restores cryptographic derivation. A path claiming the Enterprise profile's high-consequence credential property MUST use Mission-bound issuance: an acting credential satisfying the composition defined in Section 12.1. A deployment without Mission-bound issuance still claims the runtime and join capabilities its paths actually have, and states the difference in its Mission Deployment Profile. No residual_risks entry permits the stronger claim, and a Join Assertion cannot satisfy it. In the baseline mapping join, the PDP compares the authenticated subject and client that the PEP attests in the decision request, not the acting credential itself. The PEP authenticates the credential at the enforcement boundary and populates the decision request from it; the PDP neither receives nor inspects the credential. Baseline join integrity therefore rests wholly within the PEP trust base, and a PEP that misattests the subject or client widens the join. The credential-bound join is the Mission Join Assertion (Section 8): the MAS inspects the acting token when it mints the assertion and binds the assertion to that token's digest and key. The PDP then compares that binding with the digest and thumbprint the PEP reports in context.mission_join (Section 6.5), so it relies on the PEP for the presented credential's identity, as the baseline join relies on it for the subject and client. A deployment MAY move the join's verification from each PDP to the MAS with the Mission Join Assertion (Section 8). That upgrade strengthens the join's verification, not what the join can prove. 6.3. Acting Credentials The join binds identity, not possession. The acting credential's own sender binding keeps a joined permit from being a bearer property. Acting credentials for governed work SHOULD be sender-constrained, with DPoP or mutual TLS at the unchanged AS. For the high- consequence action classes, the runtime profile's Custody rules require a verified sender-constrained acting credential in either establishment mode ([I-D.draft-mcguinness-mission-runtime]). With a pure bearer token, any holder inside the (subject, client) equivalence class joins (Section 15.1). 6.4. Instance-Bound Joins Where the deployment's Authorization Server conveys Instance Context in its tokens ([I-D.draft-mcguinness-oauth-client-instance-id]: the client_instance claim or introspection member), the acting credential identifies a concrete runtime instance once the component holding the credential has validated that context and established its association with the presenter as a Context Consumer ([I-D.draft-mcguinness-oauth-client-instance-id], Section 7.5). In the PEP/PDP split, that component is the PEP. A token digest or key thumbprint alone supplies no instance association. A sender-constraint key unique to the instance ([I-D.draft-mcguinness-oauth-client-instance-id], Section 7.3) establishes that association only where the token issuer conveys context solely from direct Client Attestation validation. Context an issuer may have preserved from an input token also needs a profile that authenticates its provenance, since such a token can carry one instance's context while bound to another's key. Where that association is established, 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. In the PEP/PDP split, the PEP performs the credential, context, and presenter-proof validation and supplies the established instance through the authenticated decision context. The PDP relies on that authenticated attestation under the decision API's trust boundary and applies the instance mapping. The mapping contract states which paths require an instance-bound join and how the established instance maps to the Mission's permitted parties. Where the mapping contract requires an instance-bound join, the PDP MUST deny with mission_binding_failed if the established instance is absent or does not match that contract, without falling back to a subject-and-client-only join. A PEP unable to validate required instance attribution refuses before requesting a decision, using the instance specification's Section 7.6 credential error and the runtime profile's pre-decision refusal evidence ([I-D.draft-mcguinness-mission-runtime]). 6.5. AuthZEN Encoding On a joined decision, the PEP MUST carry the join inputs in the context.mission_join member of the AuthZEN decision request. It is a context member that this document adds under the AuthZEN profile's companion extension rule, so it is part of the authorization binding and the decision cache key ([I-D.draft-mcguinness-mission-authzen]). Its presence marks the decision as joined. The PEP never carries it on a Mission-bound decision, so a join never re-points a Mission- bound credential (Section 12.1). It is a JSON object with the following members: delegate_depth: An integer. The joining client's depth under the Mission, from the deployment's actor records, which rule 5 of Section 6.1 evaluates. Present when the joining client is a delegate. On the assertion path, the assertion's join claim governs (Section 8.3). assertion: A string. A Mission Join Assertion (Section 8.2) for the presented credential. token_sha256: A string. REQUIRED when assertion is present. The presented credential's digest, computed as in Section 8.1. token_jkt, token_x5t: Strings. When assertion is present, exactly one is REQUIRED, matching the presented credential's confirmation method: the thumbprint of its confirmation key or certificate, computed as in Section 8.1. The PEP computes the digest and thumbprint from the credential it authenticated, so the PDP checks the assertion's token binding without receiving the credential (Section 6.2). The PEP reports token_jkt only for a key against which it verified the request's proof of possession, and token_x5t only for the certificate it authenticated on the request's mutual-TLS connection. A PDP that does not consume Join Assertions ignores assertion and the token members and joins under the mapping rules. The following example shows a decision request for a successful join in the AuthZEN profile. The PEP supplies context.mission from its Mission binding, the Mission state it observed in the MAS's signed Mission Status response as context.mission_state_observation, the authenticated client as context.actor.client_id, 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", "properties": { "audience": "https://erp.example.com" } }, "action": { "name": "invoices.read" }, "context": { "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ" }, "mission_state_observation": { "state": "active", "mission_status_issued_at": "2026-11-02T08:14:00Z", "mission_status_expires_at": "2026-11-02T08:15:00Z", "mode": "cached", "freshness_at": "2026-11-02T08:14:00Z" }, "actor": { "client_id": "client_erp-recon-agent" }, "mission_join": {} } } The credential's authenticated subject and client match the Mission's subject.sub and client_id, so the join holds, and the PDP evaluates the action under the Mission's Authority Set. The following example shows the resulting permit: { "decision": true, "context": { "evaluation_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K", "conditions": { "valid_until": "2026-11-02T08:15:00Z" } } } The response carries no view identifier. The PDP records the joined view in the decision's Decision Evidence (rule 9 of Section 6.1), beside the record's mission.policy_view_id. The following abridged example shows those members of that record: { "evaluation_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com", "policy_view_id": "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t" }, "join_view_id": "sha-256:dV7wM3sK9nQ2vL5tR8bY1eG4jF6xH0pC3nT9kV2mZ5t", "decision": "permit" } The direct-client disposition and client_id the commitment binds distinguish this record from a differently-joined decision's (a narrowed delegate view) and from a direct Mission-bound decision's, which carries no join_view_id. A failed join is denied with the AuthZEN profile's own mission_binding_failed classification. The 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]). Where this document is implemented, mission_reference_conflict (Section 7.4) is a member of that set, requiring no IANA action under that extension-by- specification model. A consumer that does not implement this document treats it as that rule requires, so the action stays refused. The following is an example of an AuthZEN denial for a credential whose client_id does not match the referenced Mission: { "decision": false, "context": { "evaluation_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K", "reason": "mission_binding_failed" } } 7. Mission Reference Propagation The Mission Join consumes a Mission reference the PEP supplies, and rule 1 of Section 6.1 names two sources: the PEP's own recorded Mission binding and deployment configuration. When the gateway PEP is not the process that holds the binding (an MCP gateway, an egress proxy), neither source exists at the enforcement boundary. Mission reference propagation is the channel through which the requesting side names the Mission a given request runs under. The carried value is an untrusted *Mission-selection assertion*: it routes the request to a Mission for the join to verify. The Mission Join verifies the referenced Mission and its subject and client relationship, and supplies the authoritative state and anchors. In the baseline same-party case, neither the carriage nor the join proves that this particular request was created under that Mission. The party that attaches the value determines attribution strength. A trusted harness attaching it from its recorded Mission binding ([I-D.draft-mcguinness-mission-harness]) attests more than the agent naming its own Mission. The deployment's Enforcement Scope Statement records which party attaches it. Grading what an established join proves is a join-assurance concern, not a concern of this channel. 7.1. The Reference Tuple The propagated value is the Mission reference tuple: mission_id and issuer, compared as the canonical (issuer, mission_id) pair under the OAuth binding's comparison rules ([I-D.draft-mcguinness-oauth-mission]). The channel carries nothing else beyond the extension members admitted below. State, integrity anchors, authority, and policy data always come from the MAS's signed Mission Status response (Section 5), and a request carrying any of them in this channel MUST be refused, never silently ignored, so ambiguity is detectable rather than absorbed. Each carriage below maps this one tuple, and an additional carrier profiles it rather than defining a second. A profile MAY define an additional member by specification. Both carriages apply one extension rule: a receiver rejects any member that neither this document nor a profile the receiver implements defines. An extension member never carries state, integrity anchors, authority, or policy data; the reference remains a selection channel. The HTTP field names the identifier id and the MCP key names it mission_id; both map the same tuple. 7.2. HTTP Carriage: Mission-Reference Mission-Reference is an HTTP request field [RFC9110] whose value is a Structured Fields Dictionary [RFC9651]. The following example shows a request carrying the field (wrapped for display; the field is one line): POST /call HTTP/1.1 Host: gateway.example.com Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... Mission-Reference: id="msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", issuer="https://mas.example.com" * The field is a request header field and MUST NOT be sent as a trailer field. * The value is a Dictionary carrying two REQUIRED members: id, a String carrying the Mission identifier, and issuer, a String carrying the exact issuer identifier the MAS publishes in its metadata (Section 10). A MAS participating in this profile MUST publish an ASCII issuer identifier (Structured Field Strings are ASCII). The sender copies that published string with no URI normalization of any kind, and equality is byte equality of the exact string. * A sender MUST NOT emit an id longer than 256 characters or an issuer longer than 512 characters; a receiver MUST treat a longer value as malformed. * [RFC9651] parsing keeps the last of duplicate Dictionary keys, so parse success alone is not sufficient. A receiver MUST reject as malformed, before map collapse: a duplicate id or issuer occurrence, a parameter on either member, an Inner List or any non-String value, and any member outside the extension rule of Section 7.1. * A sender MUST send exactly one field line. If the field lines do not combine into exactly one Dictionary satisfying every rule above, or if parsing fails, the reference is malformed. * A malformed, missing, or stripped reference fails closed wherever Mission governance is required: governed work with no establishable Mission reference is refused before evaluation, per the runtime profile's preconditions ([I-D.draft-mcguinness-mission-runtime]). 7.3. MCP Carriage For a tool call governed through MCP, the reference is carried in the request's params._meta object on each tools/call, never in tool arguments and never in session state. The key is com.karlmcguinness.mission/reference, a reverse-DNS-prefixed key in a namespace this family's author controls, per the pinned MCP revision's _meta rules ([MCP-META]); MCP reserves its own _meta prefixes. The following example shows a tools/call request carrying the reference: { "method": "tools/call", "params": { "name": "post_journal_entry", "arguments": { "amount": "500.00", "currency": "USD" }, "_meta": { "com.karlmcguinness.mission/reference": { "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://mas.example.com" } } } } The value carries mission_id and issuer, with the tuple semantics of Section 7.1 unchanged. The value object is closed the same way as the HTTP field: a receiver MUST reject duplicate JSON member names at parse time, a member outside the extension rule of Section 7.1, a non-string member value, and the propagation key appearing more than once in _meta. Unknown _meta keys are extensible metadata that an ordinary MCP server may ignore. A server that silently ignores this key is not a conforming Mission PEP. Where a tool is governed as Mission-required, absent negotiated or configured propagation support the call MUST be refused, never run as ordinary ungoverned execution. An MCP extension or capability mechanism may supersede this carriage; the tuple semantics remain those of Section 7.1. 7.4. Verification and Conflict * The value is a selection assertion, never authority: its presence or content grants nothing, and the Mission is established only through the Mission Join (Section 6). An unverified reference MUST NOT establish the Mission; this is the runtime profile's externally-established rule ([I-D.draft-mcguinness-mission-runtime]). * Where the acting credential carries a mission claim, the credential-carried reference governs, and a propagated reference naming a different Mission is a deny. * Where the PEP's own binding source (a harness-recorded binding, deployment configuration) names a different Mission than the propagated reference, the conflict is a deny, never a silent pick- one. * An attribution conflict, or a malformed or missing reference where governance requires one, is denied with the mission_reference_conflict denial reason. This document adds that reason to the AuthZEN denial-reason set under its extensibility rule. A subject-or-client join failure is the AuthZEN profile's mission_binding_failed (Section 6), and mission_reference_conflict covers reference sources naming different Missions or a reference that is unusable or missing. * If a PEP establishes the conflict before any evaluation, it surfaces the same reason as a coordinated pre-decision refusal, recorded as a Refusal Record with this denial_reason ([I-D.draft-mcguinness-mission-runtime-evidence]). An evaluating PDP surfaces it as the AuthZEN denial reason above. Either way the conflict carries one reason and is never silently resolved. * The selection assertion applies only to the request it accompanies. It selects the Mission the join is evaluated against and does not by itself establish request provenance or attribution. Session-scoped stickiness is a deployment choice recorded in the Enforcement Scope Statement, and per-request carriage is required wherever the runtime profile requires per- action evaluation. * The field is protected by the deployment's TLS, which authenticates the channel endpoint, never which component attached the value. Transport protection therefore does not upgrade self- asserted attribution. Where HTTP Message Signatures [RFC9421] are deployed on the request, the signature MUST cover Mission- Reference. The following is an example of a denial for a propagated reference that conflicts with the PEP's recorded binding: { "decision": false, "context": { "evaluation_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K", "reason": "mission_reference_conflict" } } 7.5. Forwarding and Privacy The tuple is a stable correlator and is recorded in gateway logs. An intermediary MUST NOT copy the field or the _meta key onto a request to an unrelated authority domain. A terminating PEP SHOULD remove the field or key before forwarding unless the downstream recipient participates in the same verified binding. The OAuth binding's Mission Identifier correlation considerations apply to logged values. 8. Mission Join Assertion The Mission Join of Section 6 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 10). The endpoint MUST meet the TLS and caller-authentication requirements of the mission submission endpoint (Section 3). It accepts the authentication methods and client-assertion algorithms advertised in mission_submission_endpoint_auth_methods_supported and mission_submission_endpoint_auth_signing_alg_values_supported. A client assertion's aud claim and a caller-authentication access token's audience MUST name the join-assertion endpoint. For access-token authentication, the MAS publishes Protected Resource Metadata [RFC9728] for this endpoint, identifying its resource, required scope, and accepted sender constraints. That caller token is distinct from the acting access_token that the request body carries (Section 8.1), the credential whose join is asserted. 8.1. Assertion Request The PEP, or the client acting for it, sends a POST request whose body is a JSON object with the following members: mission_id: REQUIRED. A string. The Mission the join is asserted against; its issuer is the MAS. audience: REQUIRED. A string. The consuming PDP the assertion is minted for, as the enrollment configuration of Section 5.1 identifies it. The MAS MUST NOT mint for an audience that names no PDP enrolled for the Mission's enforcement scope. 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. This is a member-named digest construction outside the default prefixed form: the member name fixes the algorithm, and a successor algorithm enters as a new member, never by reinterpreting this one. For the same token, it equals the ath value of a DPoP proof (Section 4.2 of [RFC9449]). token_jkt: A string. The JWK thumbprint [RFC7638], using SHA-256, of the token's cnf public key, for a token whose confirmation is a jkt member. token_x5t: A string. The base64url SHA-256 thumbprint of the certificate a certificate-bound token is bound to: the value of its x5t#S256 confirmation member (Section 3.1 of [RFC8705]). The caller presents access_token, or token_sha256 together with exactly one of token_jkt and token_x5t, matching the token's confirmation method. 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. The MAS MUST NOT mint an assertion for a token without a cnf key: such a token gives the assertion nothing to bind. The MAS verifies the join centrally, as follows: 1. The MAS establishes the acting token's validity, subject, and client: * Where the AS offers token introspection [RFC7662], the MAS introspects the token under introspection credentials it holds there. A token the AS reports inactive fails the request. * Where the AS offers no third-party introspection but issues JWT access tokens, the MAS MAY instead validate the token locally under the semantics of [RFC9068], resolving the AS's signing keys from its published metadata and taking the subject and client from the validated claims. A token that fails signature, exp, or aud validation fails the request. * An opaque token that no introspection surface will resolve cannot be verified, and the request fails. Calling the AS is permitted in MAS mode; changing it is not. 2. The MAS verifies the subject and client joins of Section 6 against the introspection response or the validated token claims, under its own documented account and client mappings and delegate policy. For a delegate, the MAS also establishes the delegate's depth from the deployment's actor records; a delegate with no actor record under the Mission does not join (rule 5 of Section 6.1). The MAS mints an assertion only for a Mission in the active state. It responds in the error format of Section 3.4, as follows: * If the request body is not a JSON object carrying mission_id, a string audience, and exactly one of the two token forms, the MAS rejects it with HTTP 400 and the invalid_join_request error code. * If the mission_id is unknown or not visible to the caller, the MAS returns the not_found error code, preserving the anti-oracle property. * If the Mission is visible but not active, the audience names no PDP enrolled for the Mission's enforcement scope, the acting token is inactive or carries no cnf confirmation, or the acting token does not join, the MAS rejects the request with HTTP 403 and the join_failed error code. Visibility on this endpoint is bounded: a Mission is visible to its client_id, its recorded delegates, and the PEPs and PDPs enrolled for the Mission's enforcement scope. Any other caller MUST receive not_found, so the join_failed (403) and not_found (404) split never acts as a mapping oracle for callers outside that set. An assertion's lifetime is capped by the acting token's, so with short token lifetimes, minting is on the token-rotation path: each rotation needs a fresh assertion and its introspection call, per Mission and per workload. A deployment sizes agent token lifetimes to the runtime layer's revocation cutoff rather than treating token expiry as the revocation mechanism (the token-lifetime trade of [I-D.draft-mcguinness-mission-runtime]). The MAS MAY reuse an introspection result across mintings of the same token within the deployment's staleness bound, so re-minting for an unchanged token does not repeat the AS round trip. Minting is a high-frequency path, invoked on every rotation for every Mission and workload the MAS serves, and is therefore a denial-of- service surface. The MAS MUST rate-limit assertion requests per caller. The MAS SHOULD serve a repeated request from cache within the assertion's lifetime, so a burst of re-mints for an unchanged token costs one signing rather than many. The cache key is the qualified Mission reference (issuer, mission_id), the token digest, and the audience. Before serving a cached assertion, the MAS MUST recheck the caller against the endpoint's visibility set and apply the minting checks above, reusing an introspection result only as the preceding paragraph allows. A cache hit changes nothing in the consuming PDP's own state and freshness checks (rule 2 of Section 6.1). 8.2. The Assertion On success, the MAS mints a Mission Join Assertion, a signed JWT [RFC7519]. Its protected header carries the typ header parameter with the value mission-join+jwt and a kid header parameter resolvable in the MAS's jwks_uri. The MAS MUST sign the assertion with an algorithm listed in its mission_status_signing_alg_values_supported metadata member (Section 10). Exact validation of that typ, with mutually exclusive validation rules for the artifact profiles, implements the substitution defense of Sections 3.11 and 3.12 of [RFC8725]. The assertion contains the following claims: iss: REQUIRED. The MAS's issuer URL. mission: REQUIRED. An object containing id and issuer ([I-D.draft-mcguinness-oauth-mission]). The MAS MAY additionally include authority_hash as an audit anchor; where it is included, the PDP Consumption cross-check applies to it too (Section 8.3). This object MUST NOT carry approval_context_commitment: the Approval Context Commitment profile fixes this descriptor as a must-not-carry site alongside the baseline mission claim ([I-D.draft-mcguinness-mission-approval-governance]). token: REQUIRED. An object containing sha256, the token digest as in Section 8.1, and exactly one confirmation member matching the token's confirmation method: jkt, the thumbprint of the token's cnf public key [RFC7638], or x5t#S256, the thumbprint of the certificate the token is bound to (Section 3.1 of [RFC8705]). join: REQUIRED. An object carrying the result of the MAS's client and delegate evaluation. Its client_id member (a string, REQUIRED) is the joining client's identifier in the Mission's client namespace. Its disposition member (a string, REQUIRED) is client when that identifier is the Mission's own client_id, and delegate otherwise. Its depth member (an integer) is the delegate's depth from the deployment's actor records, REQUIRED when disposition is delegate. iat: REQUIRED. Issuance time. exp: REQUIRED. Expiry. It MUST NOT exceed the access token's remaining lifetime. aud: REQUIRED. A string. The request's audience: the consuming PDP. Audience scoping prevents replay of an assertion to a consumer it was not minted for. mapping_version: OPTIONAL. A string. The mapping contract version (Section 12.3) under which the subject and client joins were evaluated. RECOMMENDED where the MAS publishes a mapping contract, so each join is attributable to the mapping that produced it. The assertion carries no instance identifier. Where the acting token is sender-constrained to a key unique to the instance ([I-D.draft-mcguinness-oauth-client-instance-id], Section 7.3), the jkt binding names one runtime instance, not any holder of a client- shared key, so the assertion's token binding is materially stronger. An instance-bound join on this path takes the instance only from Instance Context whose association with the presenter has been established (Section 6.4). The token digest and jkt alone do not establish that association. 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 following, retained for the audit horizon: * the Mission reference; * the token digest and thumbprint; * the join result; * the authenticated caller; * the mapping version, where one is published (Section 12.3); * the token's Instance Context, where the MAS validated it as a Context Consumer ([I-D.draft-mcguinness-oauth-client-instance-id], Section 7.5); and * the validity window. Context for which the MAS has established only instance participation is recorded as participation, not as proof of which instance presented the credential. The following is an example of the claims of a Mission Join Assertion: { "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" }, "join": { "client_id": "client_erp-recon-agent", "disposition": "client" }, "aud": "https://pdp.example.com", "iat": 1793606400, "exp": 1793608200 } 8.3. PDP Consumption When context.mission_join carries a Join Assertion (Section 6.5), the PDP verifies the following, in place of the mapping checks of rules 3 and 4 of Section 6.1: * the signature, under a key from the MAS's jwks_uri, and the typ header parameter value mission-join+jwt; * that the alg header parameter is listed in the MAS's mission_status_signing_alg_values_supported, is accepted by the PDP's own algorithm policy, and suits the key that verifies it (Section 3.1 of [RFC8725]); * that iss and the mission claim match the referenced Mission's issuer and id; when the assertion's mission also carries authority_hash, that it matches the referenced Mission's authority_hash too; * that exp has not passed and aud names this PDP; an assertion with no aud, or one naming another PDP, fails this check; and * the token binding: context.mission_join.token_sha256 equals token.sha256, and the reported thumbprint equals the assertion's confirmation member of the same method (token_jkt to token.jkt, or token_x5t to token.x5t#S256). The PDP takes the joining client identifier, the disposition, and a delegate's depth from the assertion's join claim, not from its own mappings. It applies rule 5 of Section 6.1 with them, and they are the joining client identifier and disposition that rule 9's commitment changes with. When context.mission_join also carries delegate_depth and it differs from join.depth, the PDP MUST deny with mission_binding_failed. Every other join rule holds unchanged: the PDP resolves Mission state at the MAS under the runtime profile's freshness rules, denies with mission_binding_failed when any check above fails, and draws authority from the Mission. For an instance-bound join, the PDP also applies the instance mapping of Section 6.4 to the validated presenter context supplied by the PEP. The Join Assertion replaces only the subject and client mapping checks. Its signature, token digest, and key thumbprint cannot replace the instance check or satisfy a missing required instance association. For the high-consequence action classes ([I-D.draft-mcguinness-mission-runtime]) in MAS mode, the Enterprise profile requires Mission-bound issuance for the acting credential (Section 12). A Join Assertion strengthens every joined path outside those classes, and that profile requires one on those paths. The mapping join of Section 6 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. 9. 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]) each rest on one abstract requirement, stated normatively by each of those profiles: that the requester prove possession of the predecessor or parent Mission's authority through a sender-constrained proof rather than a reusable bearer refresh credential. On the OAuth wire, those profiles bind that requirement to an [RFC8693] token exchange whose subject_token is the predecessor or parent Mission-bound access token. A MAS issues no tokens, so that binding has no carrier here. This section defines only the peer MAS binding: carriage on the mission submission endpoint (Section 9.1) and an authenticated-client binding in place of the token-exchange possession proof (Section 9.2). 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 9.3, Section 9.4). The capability is OPTIONAL (Section 13). 9.1. Submission Carriage The mission submission endpoint carries both operations as intent submissions (Section 3.1) with the following 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 members are submission members, not Mission Intent members. A MAS that implements this capability MUST remove them before applying the OAuth binding's Intent validation; the remainder of the body is the Mission Intent Submission envelope, validated unchanged (Section 3.1). On a MAS that does not implement this capability, they are undefined top-level members, and the MAS rejects the submission with the invalid_mission_intent error code, the correct refusal for an unsupported operation. If a submission carries both predecessor and either child member, the MAS MUST reject it with the invalid_mission_intent error code: the operations do not combine. If a submission carries parent without child_actor, or child_actor without parent, the MAS MUST reject it with the same error code. The referenced profiles' OAuth error outcomes map onto this endpoint's error surface as the OAuth binding's outcomes do (Section 3.1): invalid_request outcomes map to invalid_mission_intent, and authority-derivation failures map to invalid_authority. Two rules cover the outcomes those profiles express as invalid_grant: * If the binding of Section 9.2 does not resolve a predecessor or parent, whether the Mission does not exist or is recorded under another client, the MAS MUST reject the submission with the not_found error code and a response identical in both cases, preserving the anti-oracle property of Section 3.2. * If the binding resolves the reference but its state or serialization refuses the operation (the expansion profile's predecessor-active and reconciliation rules; the child-delegation profile's parent-active rule), the MAS MUST reject the submission with the conflict error code, returned with HTTP 409. conflict is used only by this section's operations. The profile-defined machine-readable codes ride the MAS error surface in the members their profiles define: * A reconciliation status rides in mission_expansion_status ([I-D.draft-mcguinness-oauth-mission-expansion]). * An adjudication denial reason, for expansion and child creation alike, rides in the shared mission_denial_reason member that profile defines ([I-D.draft-mcguinness-oauth-mission-expansion], [I-D.draft-mcguinness-oauth-mission-child-delegation]). Each is carried as a member of the error response body (Section 3.4) or, for a denial at adjudication, of the denied submission-status response (Section 3.2). 9.2. Request Binding On the OAuth wire, the predecessor or parent is resolved from the Mission-bound access token presented as the token exchange's subject_token, with possession proven against that token's confirmation key, and any named identifier serves only as a cross- check. A MAS holds no such tokens, so the named identifier is itself the reference. The MAS binds the request to that reference 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 6). * 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. On a mismatch, the MAS MUST resolve the submission to denied with the mission_denial_reason value subject_mismatch (Section 17.5). This binding is authentication-based, not possession-based. It proves that the requester is the same registered client for which the predecessor or parent was recorded, not that the requester holds and can prove possession of that Mission's access token. The difference from the OAuth wire is exactly this: a party able to authenticate as the registered client can request these operations for any of that client's Missions, whereas the token-exchange possession proof would limit it to the Missions whose Mission-bound access token it holds and can prove control of (Section 15.3). Where the deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-id]), the MAS SHOULD bind at instance granularity rather than at the bare client_id. 9.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. Its closed reconciliation-status set applies: a refusal at submission carries the code per Section 9.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. The superseded state enters the state space the MAS reports (Section 5). * *Denial reasons.* That profile's Mission Denial Reasons registry applies, including this document's subject_mismatch (Section 9.2); the code rides in mission_denial_reason per Section 9.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 3.3). 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, as it is out of the expansion profile's base: every expansion on this surface is adjudicated by a fresh approval. The policy-adjudicated variant remains with the experimental companion ([I-D.draft-mcguinness-oauth-mission-progressive]). 9.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 5). * *Denial reasons.* That profile's closed denial-reason set applies; the code rides in mission_denial_reason per Section 9.1. The parent_mismatch reason has no analog on this surface: with no subject_token to resolve the parent against a cross-check, a binding failure is refused per Section 9.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. A 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 6) binds the child's ordinary OAuth credentials to the Child Mission through the child's own client_id, never the parent's. 9.5. Expansion Example The following example shows an expansion submission. Mid-task, the agent behind the Q3 reconciliation Mission finds a $1,200 adjustment, outside its approved $500 cap. It submits 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... { "intent": { "goal": "Reconcile Q3 invoices and post adjustments under $2,000.", "target_resources": ["https://erp.example.com"], "expires_at": "2026-12-31T23:59:59Z" }, "predecessor": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-" } The MAS authenticates the client, verifies that it is the predecessor's recorded client_id, verifies that the predecessor is active, removes predecessor, validates the remaining Submission envelope, and derives the successor's Authority Set. The following example shows the MAS accepting the submission: 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 that 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 3.3). 10. Mission Authority Server Metadata A MAS publishes a metadata document at the well-known URI [RFC8615] path /.well-known/mission-authority-server, registered in Section 17. The document is a JSON object served over TLS as application/json. Its location is constructed from the issuer, following the metadata- location rule of [RFC8414]: 1. For an issuer with no path component, the document is served at the well-known path under the issuer's host. 2. For an issuer that bears a path component, the mission-authority- server well-known segment is inserted between the host and the issuer's path (for issuer https://host/tenant, the document is at https://host/.well-known/mission-authority-server/tenant). The document's 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 the MAS metadata 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 that applying the location-construction steps above to this issuer yields the URL the metadata was resolved from. mission_submission_endpoint: REQUIRED. A string containing a URL. The mission submission endpoint (Section 3). mission_submission_endpoint_auth_methods_supported: REQUIRED. A JSON array of strings naming the authentication methods the mission submission endpoint accepts, from the value space of mission_status_endpoint_auth_methods_supported ([I-D.draft-mcguinness-oauth-mission-status]). Here access_token names a sender-constrained access token whose audience, required scope, and sender constraint the MAS publishes in this endpoint's Protected Resource Metadata [RFC9728]. mission_submission_endpoint_auth_signing_alg_values_supported: REQUIRED when mission_submission_endpoint_auth_methods_supported lists private_key_jwt. A JSON array of strings: the client-assertion algorithms this endpoint accepts, with the semantics of mission_status_endpoint_auth_signing_alg_values_supported ([I-D.draft-mcguinness-oauth-mission-status]). mission_status_endpoint: REQUIRED. A string containing a URL. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_status_endpoint_auth_methods_supported: REQUIRED. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_status_endpoint_auth_signing_alg_values_supported: REQUIRED when mission_status_endpoint_auth_methods_supported lists private_key_jwt. 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]. At a MAS, the list also governs Mission Join Assertions (Section 8.2): the MAS signs them only with a listed algorithm, and a PDP MUST reject an assertion whose alg is none or is not listed. mission_lifecycle_endpoint: REQUIRED. A string containing a URL. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_lifecycle_endpoint_auth_methods_supported: REQUIRED. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_lifecycle_endpoint_auth_signing_alg_values_supported: REQUIRED when mission_lifecycle_endpoint_auth_methods_supported lists private_key_jwt. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. mission_join_assertion_endpoint: OPTIONAL. A string containing a URL. The join-assertion endpoint (Section 8). 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: REQUIRED. An integer. Semantics per [I-D.draft-mcguinness-oauth-mission-status]. A MAS has no other state surface, so this bound is the one join rule 2 fails closed against (Section 6.1). 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]. The following is an example of a MAS metadata document: { "issuer": "https://mas.example.com", "mission_submission_endpoint": "https://mas.example.com/mas/mission/submit", "mission_submission_endpoint_auth_methods_supported": ["access_token", "private_key_jwt"], "mission_submission_endpoint_auth_signing_alg_values_supported": ["ES256"], "mission_status_endpoint": "https://mas.example.com/mas/mission/status", "mission_status_endpoint_auth_methods_supported": ["access_token", "private_key_jwt"], "mission_status_endpoint_auth_signing_alg_values_supported": ["ES256"], "mission_status_signing_alg_values_supported": ["ES256"], "mission_lifecycle_endpoint": "https://mas.example.com/mas/mission/lifecycle", "mission_lifecycle_endpoint_auth_methods_supported": ["access_token", "private_key_jwt"], "mission_lifecycle_endpoint_auth_signing_alg_values_supported": ["ES256"], "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 the MAS metadata document from the reference's issuer. Whether a given issuer is a MAS or an OAuth AS is deployment configuration. 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 supplies the capabilities its Mission Substrate Statement lists (Section 14). It does not claim that an unchanged Authorization Server's credential was issued under the Mission or that its issuance was lifecycle-gated. Credential correlation and action-time lifecycle gating compose through the runtime join and PEP coverage, within the conditional scope declared by Section 14. 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-id]); * whether Mission Join Assertions are required, which the Enterprise profile requires on joined, PDP-gated paths outside the irreversible, external-commitment, and privileged-administration classes, the classes it reserves for Mission-bound issuance (Section 8, Section 12); and * which action paths are covered by runtime enforcement, since nothing at the token layer covers the rest. An enterprise deployment carries this statement inside its mapping contract (Section 12.3). *No Mission-bound credentials.* Tokens carry no mission claim and no Mission-derived authorization_details. Nothing cryptographically binds a token to the approval event. 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. 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. Because the mode has neither Mission-bound credentials nor issuance gating, enforcement rests entirely on PEP coverage. The security model's no-unmediated-path condition ([I-D.draft-mcguinness-mission-security-model]) is required for every guarantee this document makes, not only for the runtime profile's agent-compromise-resistant enforcement claim. A token exercised outside PEP coverage is ungoverned: ordinary OAuth alone bounds its use, and no Mission property applies to it. *Weaker expansion and child-creation binding.* This mode carries Mission Expansion and Child Delegation natively (Section 9), so a standalone deployment can widen authority and delegate to sub-agents. The mode does not provide the OAuth wire's token-exchange possession proof. A request is bound to its predecessor or parent by authenticated client identity (Section 9.2), which proves the same registered client, not possession of a held Mission-bound access token (Section 15.3). Offline attenuation does not apply in this mode, because it requires the Mission-bound credential (Section 14). *Upgrade path.* Implementing the OAuth binding 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 OAuth binding's own definitions of all three. The enforcement join becomes unnecessary for tokens issued after the upgrade, which carry the mission claim. The Mission Issuance Grant companion ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) defines the issuance join: a grant the MAS mints for an active Mission and an estate Authorization Server redeems at its token endpoint for Mission-bound tokens, state-gated at minting and at refresh. Where deployed, it removes the credential and issuance-gating limitations for the resources of each consuming Authorization Server, while approval, the record, and the lifecycle remain with the MAS. 12. The Enterprise Mission Authority Profile The conformance floor (Section 13) makes a MAS deployable. This profile is the operating profile for a MAS used as an estate's Mission control plane. It makes several of the floor's recommendations and options mandatory and adds the obligations below. A deployment claims the Enterprise Mission Authority Profile over a declared coverage set: the Authorization Server, resource, and action-class paths the claim names. The estate-level obligations below hold deployment-wide. The per-path credential, join, and runtime obligations hold for every path in the set. A path outside the set is explicitly unclaimed and never inherits the profile from the deployment's name. The profile builds on the Runtime-Enforced level of the Mission Assurance Levels under the MAS binding ([I-D.draft-mcguinness-mission-architecture]) and adds the following obligations: * *Status and lifecycle.* The MAS MUST serve the Mission Status operation and the Mission Lifecycle endpoint with signed responses (Section 5), 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. Where per-class bounds differ, the metadata's single mission_max_stale_seconds member (Section 10) advertises the tightest bound in force, which a consumer may assume without knowing an action's class. The per-class bounds are published in the Enforcement Scope Statement. * *Join Assertion.* The MAS MUST offer the Mission Join Assertion (Section 8). For every joined, PDP-gated governed path not classified as irreversible, external commitment, or privileged administration ([I-D.draft-mcguinness-mission-runtime]), the PDP MUST require one. * *Mission-bound issuance for the high-consequence classes.* For the high-consequence action classes ([I-D.draft-mcguinness-mission-runtime]), the PDP MUST require an acting credential satisfying the composition defined in Section 12.1, with presenter proof of possession end to end; a Join Assertion does not satisfy it, and absence denies rather than falling back to a mapping or asserted join. - Where the Mission Issuance Grant ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) is the issuance path for such a class, the grant MUST carry cnf and redemption MUST produce an access token sender-constrained to that same key. The issuance upgrade thus opens no bearer interval between grant and action, and this profile defines no rotation exception. - Mission-bound issuance restores the issuance gate; it does not replace this profile's runtime active-freshness check for these classes. - When a client legitimately holds credentials for several Missions, issuance does not prove that a particular work item was supposed to run under the selected Mission. Work-item attribution stays with the reference propagation channel and the work-item-bound property. - The Enterprise claim is made per covered Authorization Server, resource, and action path; a mixed estate's weaker paths never inherit it from the deployment's name. * *Instance-bound joins.* Where the acting credential carries Instance Context ([I-D.draft-mcguinness-oauth-client-instance-id]) whose association with the presenter is established as Section 6.4 describes, a join on a covered path MUST bind (subject, client, instance), not (subject, client), so a single workload joins rather than every workload sharing a gateway client_id. Client- instance identity is defined by an individual draft ([I-D.draft-mcguinness-oauth-client-instance-id]). Where a deployment has no instance-identity substrate, such a join binds only (subject, client), and the shared-client_id residual of Section 15.1 remains, stated in the Mission Deployment Profile's residual_risks. * *Runtime enforcement.* Consequential actions MUST be enforced under the runtime profile and its AuthZEN profile ([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]). * *Approval governance.* Where a recording trigger of Mission Approval Governance ([I-D.draft-mcguinness-mission-approval-governance]) holds for an approval event, the MAS MUST record the Approval Governance Record, committed atomically with the Mission's creation and retained for its audit horizon. That document defines the triggers: the Approver differs from the Subject, more than one principal contributes, a non-human assertion contributes, a threshold, veto, or separation-of-duty rule is evaluated, or validating an assertion requires authority standing outside the Mission record. The Mission record still carries exactly one accountable approver, the only principal any projection or enforcement consumes. Direct self-approval by one authenticated human remains the degenerate case, which the Mission record represents completely. The Join Assertion obligation is what distinguishes this profile from the conformance floor, whose join is the mapping join (Section 6). The Join Assertion 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. A deployment claiming this profile SHOULD publish its claims, coverage, and residual risks as a Mission Deployment Profile ([I-D.draft-mcguinness-mission-architecture]). 12.1. High-Consequence Binding The two binding-establishment modes are mutually exclusive per action, as the runtime profile specifies ([I-D.draft-mcguinness-mission-runtime]). A high-consequence path switches modes rather than layering them. The join algorithm of Section 6 assumes a credential that cannot identify its Mission, and it never runs against one that can. The floor and the Enterprise profile differ on these paths. At the floor, a joined high-consequence path needs, each as a necessary part, a sender-constrained acting credential, the join, active freshness, and runtime enforcement. The Enterprise profile additionally requires Mission-bound issuance for the high-consequence classes, so on its covered paths the join does not run for those classes. A Mission-bound acting credential, in this document, establishes all of the following for the covered path, each as the OAuth binding defines it ([I-D.draft-mcguinness-oauth-mission]): 1. a trusted issuer authorized to issue for the Mission (the Mission Issuer role); 2. the canonical (mission.issuer, mission.id) pair identifying the Mission, as an identity condition only; 3. an issued authority projection no broader than the Mission's Authority Set for the target audience (the subset rule); 4. the mapped subject, the requesting client_id, and actor or delegation context where applicable (the approval event); 5. a bounded lifetime plus active-state issuance and refresh gates (the lifecycle gate); and 6. an auditable derivation link to the Mission's recorded Authority Set: the Mission Record, an Issuance Grant jti ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), or an equivalently specified artifact. The presenter also proves possession of the key the credential is constrained to, end to end, with DPoP [RFC9449] or mutual TLS [RFC8705]. An instance association, where a path requires one, is a separate check (Section 6.4). The Substrate's Credential-Bound capability with correlation-only semantics ([I-D.draft-mcguinness-mission-substrate]) does not establish this composition, and a Join Assertion fails conditions 3, 5, and 6. No condition requires a token-carried authority_hash. The architecture explains these properties as the Mission Binding Properties ([I-D.draft-mcguinness-mission-architecture]). For each action, the PDP: 1. classifies the action under the runtime profile's classes; 2. for a high-consequence path in the declared coverage set, requires and validates a Mission-bound acting credential per the issuance obligation above; a mapping or asserted join never substitutes; 3. establishes the Mission from that credential's authenticated mission claim, never from an external selection; 4. where a propagated Mission-Reference is also present, requires exact equality of its issuer and Mission identifier with the credential's mission claim, denying on any mismatch; 5. applies current Mission state, current authority, the subject, client, and actor checks, the sender proof, and, where the credential carries Instance Context whose association with the presenter is established, the instance check of Section 6.4, as elsewhere in this profile; and 6. never uses a Join Assertion or a mapping join to select a different Mission than the credential's own: with concurrent Missions for one subject and client, the credential's mission claim is the binding, and nothing re-points it. 12.2. Estate Prerequisites The profile's mandatory path runs through the deployment's unchanged Authorization Server and assumes capabilities there. They require configuration rather than code, but they are prerequisites. Before claiming the profile, a deployment confirms that its estate AS provides: * *Token introspection or validatable JWT access tokens.* [RFC7662] introspection reachable by the MAS, under credentials the deployment protects (Section 15.2), or JWT access tokens the MAS can validate locally under [RFC9068]. The MAS cannot mint a Join Assertion for a token it can neither introspect nor validate (Section 8.1). * *Sender-constrained issuance.* DPoP-bound or mutual-TLS-bound access tokens for the agent clients on the joined paths that require a Join Assertion, since the MAS MUST NOT mint an assertion for a token without a cnf key (Section 8.1). * *cnf in introspection or token claims.* Introspection responses, or validated JWT claims, that report the token's cnf confirmation, since the assertion binds the key or certificate thumbprint they report. An estate whose Authorization Server cannot provide these capabilities still joins under the mapping join at the conformance floor (Section 6, Section 13), but it does not claim this profile. The digest pair of Section 8.1 also assumes an introspection surface that resolves a token by digest. Widely deployed Authorization Servers do not provide one, so a deployment plans for the access_token form. 12.3. The Enterprise Mapping Contract A join can be coarse or can drift: shared client_id values, many-to- one directory mappings, and workload identity that the join collapses (Section 15.1). Every deployment documents the mapping contract its joins apply, and an enterprise MAS MUST publish it. The contract states, for the joins performed: * 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, which MUST state how the OAuth binding's per-entry delegation rules are evaluated at the join; * 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_binding_failed on any unresolved or ambiguous mapping. A MAS that mints Join Assertions SHOULD carry the version in each assertion's mapping_version claim (Section 8.2), so a mapping change is attributable in join evidence, not only detectable in documents. 12.4. 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. In doing so, the MAS distributes bounded, audience- scoped authority derived from the Mission, not tokens. The MAS serves the view under the Mission Status operation's authentication and anti-oracle rules. The view carries the Mission's authority_hash as its consent anchor and does not widen authority beyond the Authority Set. 13. Conformance An implementation conforms in one of three 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 OAuth binding'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 5; * publishes the discovery document of Section 10 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 9) 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 9.1; * verifies the binding of Section 9.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, a mismatch resolving to denied with subject_mismatch; * applies the expansion profile's rules by reference: predecessor active, reconciliation serialization, supersession atomicity, and the lineage members (Section 9.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 9.4); and * carries the profiles' closed code sets, reconciliation statuses in mission_expansion_status and adjudication denial reasons in the shared mission_denial_reason member, on its error and submission- status surfaces (Section 9.1). *Join Assertion* (Section 8) is a named optional capability of the Mission Authority Server role, which the Enterprise profile requires. A MAS claiming it serves the join-assertion endpoint under Section 8.1 and mints assertions per Section 8.2. A Mission-joining PDP that accepts assertions verifies them per Section 8.3. 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 6); * verifies the subject join and the client join before evaluating authority, and denies with mission_binding_failed on any join failure; * for a high-consequence path under the Enterprise profile, requires the Mission-bound acting credential of Section 12.1 and denies on its absence, never falling back to a mapping or asserted join (Section 12); * evaluates joined actions under the runtime profile's decision contract, drawing authority from the Mission; and * when the AuthZEN profile is in use, emits Decision Evidence per [I-D.draft-mcguinness-mission-runtime-evidence], recording the Mission reference the join was verified against. A *Mission-joining PEP*: * supplies the Mission reference for governed work from its Mission binding, deployment configuration, or a propagated reference (rule 1 of Section 6.1, Section 7); * authenticates the acting credential and populates the decision request from it (Section 6.2), validating the presenter's Instance Context where the mapping contract requires an instance-bound join (Section 6.4); * where a propagated reference is used, parses it under the rules for its HTTP (Section 7.2) or MCP (Section 7.3) carriage and surfaces a reference conflict with mission_reference_conflict (Section 7.4); * refuses governed work with no establishable Mission reference, including a Mission-required MCP tool call without negotiated or configured propagation support (Section 7.2, Section 7.3); * never treats a Mission permit as overriding what the credential or the resource would refuse (rule 8 of Section 6.1); and * does not copy the reference onto a request to an unrelated authority domain (Section 7.5). A deployment claiming the *Enterprise Mission Authority Profile* meets Section 12 over its declared coverage set; its MAS, PDPs, and PEPs conform in their roles above with that section's additional obligations. 14. Mission Substrate Statement This Statement applies to the standalone MAS binding defined by this document and declares conformance to [I-D.draft-mcguinness-mission-substrate]. The contextual-governance kernel maps as follows: 1. *Mission Reference*: the tuple (issuer, mission_id) names one Mission. The MAS issuer URL is the uniqueness namespace; mission_id follows the OAuth binding's comparison, retention, entropy, and non-reassignment rules. 2. *Controller*: the MAS controls approval, Mission state, and the governance record. Consumers establish its identity and keys from the MAS discovery document (Section 10). 3. *Actor binding*: the authenticated submitting client is the Actor, recorded as client_id; the MAS establishes the Subject separately during approval. Later action decisions establish the Actor and Subject through the Mission Join, including the mapping assurance and ambiguity the deployment declares (Section 4, Section 6). 4. *Approved Context*: the Mission Intent, the recorded authority proposal where one was submitted, and the derived Authority Set in the immutable Mission record are the Approved Context. This binding's chosen commitments are the OAuth binding's intent_hash and authority_hash, computed with the MAS issuer URL, plus proposal_hash where a proposal was submitted; they are not substrate-kernel requirements. 5. *Approval ceremony*: the asynchronous MAS approval surface authenticates the Approver, establishes the Subject and Actor, renders the derived authority, computes the commitments, and creates the record active atomically with approval (Section 4). 6. *Governance gate*: only active permits a positive MAS decision; every other or unrecognized state fails closed. The lifecycle endpoint supplies authenticated transitions, including revocation by the authorized parties (Section 5). 7. *Reliance bound*: a positive MAS decision requires current active state at decision time. Standing artifacts carry their own bounds: a signed Mission Status is relied on within its declared freshness window (Section 5), and a Join Assertion within the acting token's remaining lifetime (Section 8). Tokens of the unchanged Authorization Server are not represented as Mission- governed artifacts. 8. *Context propagation*: submission status and signed Mission Status responses carry the Mission Reference. A Mission-joining PDP verifies the reference against the acting credential before using Mission authority. That join establishes correlation, not that the unchanged Authorization Server issued the credential under the Mission (Section 3.3, Section 6). The Mission- Reference HTTP field and the MCP _meta key carry the reference to a PEP that does not hold the Mission binding (Section 7); that propagation selects a Mission and never conveys authority. 9. *Governance record*: the MAS audit log is the ordered governance record. The MAS MUST append approval, positive and negative Mission-dependent decisions, join decisions it makes, and lifecycle transitions in per-Mission append order; MUST protect the log under the same integrity and access controls as the Mission record; and MUST retain both for the declared audit horizon. The capability table has one row per capability. Every supplied row states its activation conditions, and states its temporal and failure elements in its cells or by express inheritance of the Bounded Reliance floor ([I-D.draft-mcguinness-mission-substrate]). +=============+========+============+=========================+=============+ |Capability |Claim |Activation |Scope and defining |Limitations | | | | |sections | | +=============+========+============+=========================+=============+ |Lifecycle- |supplied|always for |A current-state check at |The unchanged| |Gated | |MAS-native |each such operation or |Authorization| |Authorization| |authority |decision (Section 5, |Server gates | | | |operations; |Section 6) |neither | | | |a Mission- | |issuance nor | | | |joining PDP | |refresh; the | | | |for joined | |token-layer | | | |decisions | |residual runs| | | | | |to expiry | +-------------+--------+------------+-------------------------+-------------+ |State- |supplied|always |Signed Mission Status |Consumers | |Observable | | |with the |fail closed | | | | |mission_max_stale_seconds|past the | | | | |bound (Section 5, |declared | | | | |Section 10) |freshness | | | | | |bound | +-------------+--------+------------+-------------------------+-------------+ |Structured |supplied|always |The OAuth binding's |Semantics | |Authority | | |Authority Set, held at |cover only | | | | |the MAS and evaluated at |declared | | | | |the joining PDP |authority- | | | | |(Section 6) |detail types | | | | | |and mappings | +-------------+--------+------------+-------------------------+-------------+ |Monotonic |supplied|native child|The no-broader-than |Enforcement | |Derivation | |creation |relation at child |and expansion| | | |(Section |creation |are never | | | |9.4) | |derivation; | | | | | |unchanged AS | | | | | |tokens are | | | | | |outside the | | | | | |claim | +-------------+--------+------------+-------------------------+-------------+ |Credential- |supplied|the Join |A signed assertion binds |Does not | |Bound | |Assertion |one token's digest and |prove the | | | |endpoint |cnf thumbprint to the |Authorization| | | |(Section 8) |Mission; fact semantics: |Server issued| | | | |verified party |the token | | | | |correlation |under the | | | | | |Mission; | | | | | |mapping-join-| | | | | |only | | | | | |deployments | | | | | |are outside | | | | | |this row | +-------------+--------+------------+-------------------------+-------------+ |Authorized |supplied|always |The mapping join and the |Proves the | |Context | | |Join Assertion, with the |credential | |Correlation | | |MAS and its joining PDPs |belongs to | | | | |as joining authority |the Mission's| | | | |(Section 6, Section 8) |parties, | | | | | |never that it| | | | | |was issued | | | | | |for the | | | | | |Mission | | | | | |(Section 6.2)| +-------------+--------+------------+-------------------------+-------------+ |Independently|supplied|signed |Record and state as of |Proves | |Verifiable | |Mission |the response's freshness |neither AS | | | |Status |window; Join Assertions |issuance | | | |(Section 5) |add token correlation |under the | | | | | |Mission nor | | | | | |current state| | | | | |after the | | | | | |observation | | | | | |window | +-------------+--------+------------+-------------------------+-------------+ |Portable |supplied|Consent |The adopted profile's |The base MAS | |Evidence | |Evidence, a |artifact and verification|audit log is | | | |Mission |procedure |Controller- | | | |Mandate, or | |local | | | |Audit | | | | | |Transparency| | | | | |adopted | | | +-------------+--------+------------+-------------------------+-------------+ Table 3: Standalone MAS Mission substrate capabilities Unless a row states otherwise, each supplied row's temporal elements inherit the signed Status freshness contract: facts are current as of the response's mission_max_stale_seconds window, assertion lifetime is capped by the introspected token's remaining lifetime, and the residual after non-active is bounded by the consumer's declared staleness bound. Failure behavior is uniformly fail-closed. An unresolvable Mission, a stale or failed Status response, a join failure (mission_binding_failed, never a fallback), an unknown or malformed authority-detail type, and an incomparable or invalid constraint each refuse the evaluation rather than comparing best-effort. A PDP that consumes a Join Assertion and finds it invalid denies with mission_binding_failed (Section 8.3), never falling back to the mapping join. The following qualifications apply to individual rows: * Structured Authority includes each supported type's own constraint vocabulary; for mission_resource_access, that vocabulary is the Mission Resource Access Profile's Common Constraints. * Monotonic Derivation covers native child creation only. PDP action evaluation is enforcement, never derivation; a separately approved expansion is a fresh approval (Section 9.3); and tokens of the unchanged AS are outside the claim. * For Authorized Context Correlation, the MAS and its joining PDPs are the joining authority under the deployment's documented mapping contract (Section 12.3), which an enterprise MAS publishes, joining the presented credential, the subject and client mappings, and the Mission. The bare mapping join carries the (subject, client) equivalence-class ambiguity, and substitution protection requires the cnf-bound Join Assertion (Section 15.1). * Portable Evidence is supplied only when the deployment adopts Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), a Mission Mandate ([I-D.draft-mcguinness-mission-mandate]), or Audit Transparency ([I-D.draft-mcguinness-mission-audit]). The referenced profile defines the portable artifact and verification procedure; the base MAS audit log is not portable evidence. These claims have the following composition consequences: * Shaping, consent evidence, audit transparency, the security model, status, and signals compose with the capabilities they name. Where such a profile names the Mission Issuer or issuer AS, the MAS is that party. * The runtime profile and its AuthZEN profile, the harness, and orchestration compose through the runtime profile's externally established binding mode ([I-D.draft-mcguinness-mission-runtime]), profiled here as the Mission Join (Section 6). * Offline attenuation does not apply in MAS-only mode because no Mission-bound credential or offline-minting chain exists ([I-D.draft-mcguinness-oauth-mission-attenuation]). The token- carriage aspects of delegation likewise have no carrier. * On the OAuth wire, Mission Expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) and Mission Child Delegation ([I-D.draft-mcguinness-oauth-mission-child-delegation]) bind their request to an [RFC8693] token exchange whose subject_token is the predecessor or parent Mission-bound access token. Section 9 defines their MAS-native wire, which carries both operations on the mission submission endpoint with an authenticated-client binding in place of that token-exchange possession proof. Their models (supersession, lineage, cascade) apply to MAS-held Missions unchanged. 15. Security Considerations The security considerations of the OAuth binding ([I-D.draft-mcguinness-oauth-mission]), Mission Status ([I-D.draft-mcguinness-oauth-mission-status]), and the runtime profile ([I-D.draft-mcguinness-mission-runtime]) apply to this document. This section covers what the standalone binding adds. 15.1. Join Spoofing A client cannot gain authority by asserting another party's mission_id. The join requires the subject and client that the PEP authenticates from the credential to match the values the MAS recorded at approval, which the client cannot alter. A reference to someone else's Mission therefore fails with mission_binding_failed. Four residuals remain: * *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, with the granularity recorded in its mapping contract (Section 12.3). The client join is coarse in the same way where several workloads share one client_id: any of them joins. Client instance identification ([I-D.draft-mcguinness-oauth-client-instance-id]) addresses this: the join then binds the validated instance (Section 6.4), and this residual remains only for deployments without instance identity. * *Same-party misattribution.* Two Missions held by the same subject and client are distinguished only by the PEP-supplied reference. A faulty or compromised PEP can therefore attribute work to the wrong same-party Mission, bounded by that Mission's authority and visible in evidence. * *Bearer possession.* With a pure bearer token, possession alone presents the credential, so any holder inside the (subject, client) equivalence class joins. For this reason Section 6 requires sender-constraint for the high-consequence classes. * *Same-party self-selection.* The propagation channel (Section 7) lets the requesting side name the Mission. An agent whose subject and client join more than one active Mission therefore chooses which one a request runs under. This is a confused-deputy pattern (least-restrictive-Mission selection), not merely spoofing. The join bounds the choice to Missions whose parties match, and each chosen Mission's own authority bounds what the choice yields. The party that attaches the reference bounds it further: the strong form is a trusted harness attaching from its recorded binding, or a Mission Join Assertion carried with the decision (Section 6.5). The Enforcement Scope Statement records the attachment provenance. The Mission Join Assertion (Section 8) mitigates 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. The join then 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. The exp claim, capped at the token's remaining lifetime, bounds the window in which the proof is live. The PDP checks the token binding against the digest and thumbprint the PEP reports (Section 6.5). It relies on the PEP for those values under the decision API's trust boundary, the same trust the baseline join places in the PEP's subject and client attestation (Section 6.2). The introspection call creates a trust relationship specific to this upgrade. The MAS relies on the deployment's AS for the token's validity, subject, and client, through RFC 7662 introspection or, for JWT access tokens, local RFC 9068 validation of the AS-issued token. The deployment documents that reliance and protects the MAS's introspection credentials accordingly. The assertion concentrates the join: 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 silently widens the join. 15.3. Expansion and Child-Creation Binding The native surfaces of Section 9 bind a request to its predecessor or parent by authenticated client identity, not by the token-exchange possession proof of the OAuth wire. 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; proving possession of the Mission-bound access token would have limited it to the Missions whose token it holds and can prove control of. The mitigations are: * Instance-grade binding ([I-D.draft-mcguinness-oauth-client-instance-id]) narrows the client_id equivalence class to one runtime instance (Section 9.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. * The binding failure surface is anti-oracle (Section 9.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 is that tokens are ordinary OAuth tokens. 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; only Mission-bound issuance removes it, through the OAuth binding or the issuance join (Section 11). 15.5. MAS Availability The runtime layer fails closed when Mission state cannot be established within the staleness bound. A MAS outage therefore becomes work stoppage for governed actions, not loosened enforcement, which is the availability trade-off 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. The Operational Considerations of the runtime profile ([I-D.draft-mcguinness-mission-runtime]) and of Mission Status ([I-D.draft-mcguinness-oauth-mission-status]) describe dependency- specific outage effects, remaining-window ride-through, and recovery observations. 15.6. Signing-Key Custody The MAS's signing key is the estate's Mission root of trust. It signs status and lifecycle responses, Join Assertions, and the issuer-signed artifacts of the companions. A MAS SHOULD hold the key in a non-exportable keystore (an HSM or equivalent KMS-grade custody) with dual-controlled generation. A MAS SHOULD sign high-volume surfaces (status, Join Assertions) and long-lived artifacts (Mandates, Issuance Grants) under distinct kids in one jwks_uri, so custody can follow the consequence of each key's compromise. The introspection credential that the MAS holds at the estate AS (Section 8.1) is secret material of the same tier: its compromise allows forged joins ([I-D.draft-mcguinness-mission-security-model]). 15.7. MAS Compromise Compromise of a MAS is equivalent to Mission Issuer compromise: a compromised MAS 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.8. Approval Surface Authentication The MAS's review surface is the approval event surface, and the OAuth binding's approval rules apply to it unchanged (Section 4). The Approver is authenticated to the deployment's published approval- authentication floor, the Subject is never taken from client input, client text is rendered inert, and derived authority is visually distinguished from client text. 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 The privacy considerations of the OAuth binding ([I-D.draft-mcguinness-oauth-mission]), Mission Status ([I-D.draft-mcguinness-oauth-mission-status]), and the runtime profile ([I-D.draft-mcguinness-mission-runtime]) apply to this document. This section covers what the standalone binding adds. 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 OAuth binding'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. The join disclosure (Section 5.1) reveals a Mission's Subject and client only to the PDPs enrolled for its enforcement scope. A deployment enrolls only the PDPs that enforce that scope. Retention is anchored on the OAuth binding's audit horizon. A MAS retains records at least that long and SHOULD NOT retain them materially longer without a documented basis. 17. IANA Considerations 17.1. HTTP Field Name Registration IANA is requested to register the following in the "Hypertext Transfer Protocol (HTTP) Field Name" registry ([RFC9110]): * Field Name: Mission-Reference * Status: permanent * Structured Type: Dictionary * Reference: this document, Section 7.2 * Comments: none 17.2. 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 10 * Status: permanent * Related Information: none 17.3. Mission Authority Server Metadata Registry IANA is requested to create the "Mission Authority Server Metadata" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for: a Metadata Name in the style of the members of Section 10 and not already registered; a definition precise enough that a client can consume the member from its specification alone; and no overlap with an existing member's semantics (a refinement belongs in the defining specification, not a parallel member). Registration does not require IETF review or a Standards Track document. Each entry has the fields of the registration template in Section 7.1.1 of [RFC8414]: Metadata Name, Metadata Description, Change Controller, and Specification Document(s). The registry is seeded with the members of Section 10; for each, the Metadata Description is the member's definition there, the Change Controller is IETF, and the Specification Document is this document: * issuer * mission_submission_endpoint * mission_submission_endpoint_auth_methods_supported * mission_submission_endpoint_auth_signing_alg_values_supported * mission_status_endpoint * mission_status_endpoint_auth_methods_supported * mission_status_endpoint_auth_signing_alg_values_supported * mission_status_signing_alg_values_supported * mission_lifecycle_endpoint * mission_lifecycle_endpoint_auth_methods_supported * mission_lifecycle_endpoint_auth_signing_alg_values_supported * mission_join_assertion_endpoint * mission_event_stream_endpoint * mission_max_stale_seconds * jwks_uri 17.4. Media Type Registration IANA is requested to register one media type per [RFC6838]. 17.4.1. Mission Join Assertion Media Type * Type name: application * Subtype name: mission-join+jwt * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JWS Compact Serialization * Security considerations: see Section 15.2 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: Mission Authority Server deployments and PDPs consuming Mission Join Assertions * Fragment identifier considerations: not applicable * Additional information: - Deprecated alias names for this type: none - Magic number(s): none - File extension(s): none - Macintosh file type code(s): none * Person & email address to contact for further information: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Restrictions on usage: none * Author: IETF * Change controller: IETF 17.5. Mission Denial Reason Registration IANA is requested to register the following value in the "Mission Denial Reasons" registry ([I-D.draft-mcguinness-oauth-mission-expansion]): +==================+======================+============+===========+ | Value | Semantics | Change | Reference | | | | Controller | | +==================+======================+============+===========+ | subject_mismatch | The Subject | IETF | this | | | established at an | | document, | | | expansion's approval | | Section | | | event differs from | | 9.2 | | | the predecessor | | | | | Mission's subject, | | | | | so no successor is | | | | | created. | | | +------------------+----------------------+------------+-----------+ Table 4 17.6. Runtime Denial Reasons mission_reference_conflict extends the denial-reason set of [I-D.draft-mcguinness-mission-authzen] under that profile's denial- reason extensibility rule (Section 7.4). A failed join uses that profile's own mission_binding_failed (Section 6). 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 them. 18. References 18.1. Normative References [I-D.draft-mcguinness-mission-approval-governance] McGuinness, K., "Mission Approval Governance", 2026, . [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-mission-runtime-evidence] McGuinness, K., "Mission Runtime Evidence", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-oauth-client-instance-id] McGuinness, K., "Client Instance Identification for Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client- instance-id-00, 28 September 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, . [I-D.draft-mcguinness-oauth-mission-submission-evidence] McGuinness, K., "Mission Intent Submission Evidence for OAuth 2.0", 2026, . [MCP-META] Model Context Protocol Project, "Model Context Protocol: Base Protocol", 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, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [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, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [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, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . 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-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-derivation-limits] McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-issuance-grant] McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-management] McGuinness, K., "Mission Management 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, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . Appendix A. Deployment Guidance This appendix is non-normative. It shows where a MAS sits in an estate and how a deployment adopts it incrementally. A.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 profile, drawing authority from the MAS-served Authority Set or a materialized policy view (Section 12.4); * 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. Which Mission Issuer governs a given resource is explicit deployment configuration. Where more than one Mission Issuer operates, the deployment documents the resource-to-issuer mapping alongside its mapping contract, and a PEP treats a resource with no mapped issuer as outside the governance this document defines rather than inventing an issuer. A.2. Connector Patterns A PEP sits 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. A placement is effective only where it has no unmediated bypass. The runtime profile's Enforcement Scope Statement states that coverage ([I-D.draft-mcguinness-mission-runtime]). A.3. Progressive Adoption A MAS deployment adopts the Mission Assurance Levels in the order deployments build them ([I-D.draft-mcguinness-mission-architecture]). The levels are adoption bundles, not a ladder, and each phase is independently useful. The six phases group into three modes, and a deployment's claim is bounded by its mode. *Records mode* (phases 1 and 2) is inventory, approval, lifecycle, and audit, with no prevention claim of any kind. *Enforced-paths mode* (phases 3 and 4) prevents on exactly the paths the Enforcement Scope Statement enumerates and is records mode everywhere else. *Issuance mode* (phases 5 and 6) restores the token- layer gate. "No AS code change" holds in records and enforced-paths modes (phases 1 through 4); what changes is the claim. Issuance mode needs each consuming AS to redeem Issuance Grants (phase 5) or to become Mission-aware (phase 6). Under the Enterprise profile, a high- consequence enforcement claim requires Mission-bound issuance, which is issuance mode. At the floor, a joined high-consequence path requires a sender-constrained acting credential, the join, active freshness, and runtime enforcement, and claims only what the join proves (Section 12.1). Records alone support no enforcement claim. The phases are: 1. The MAS records Missions and approvals: governance and audit of what tasks were approved, with no enforcement change yet (Baseline Issuance under the MAS binding: governance and audit, with no kill switch of any kind). 2. Mission Status and lifecycle publish Mission state estate-wide: the freshness surface runtime enforcement relies on. Under the MAS binding this alone is no kill switch. 3. PEP/PDP runtime enforcement gates consequential actions per the runtime profile and, with phase 2's state surface, supplies the kill switch (the Runtime-Enforced level). 4. Join Assertions harden the join on joined paths outside the high- consequence classes, which the Enterprise profile reserves for Mission-bound issuance, and instance-bound joins narrow it to one workload (the Enterprise profile, Section 12). 5. Estate Authorization Servers adopt the issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), redeeming MAS-minted grants for Mission-bound, state-gated tokens: the token-layer kill switch returns without moving approval into the AS. 6. Where a particular AS later becomes natively Mission-aware, it adds the OAuth binding's own issuance for its 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 remains the control plane of the family's delegated-authority layer ([I-D.draft-mcguinness-mission-architecture]) even as individual Authorization Servers become Mission-aware. A common starting estate runs automated jobs on standing service accounts with broad, durable entitlements. Migration is per task, not per account. Each recurring job becomes a durable Mission whose Authority Set is derived from the entitlements the job actually exercises, with the deployment's entitlement catalog as the derivation policy's input. The service account retains only what no Mission yet governs; the size of that remainder measures adoption. Appendix B. MAS-Mode End-to-End Example This appendix is non-normative. It follows one Mission through the standalone binding end to end, in the order of Section 1.1. Each stage points to the example that defines its messages. B.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). The examples in Section 3.1 show the request and response. B.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; the example in Section 3.3 shows the response. B.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 where the MAS's signed Mission Status response discloses it, and the Mission state it observed in that response. The PDP verifies the subject and client joins (Section 6). The first example in Section 6.5 shows the decision request. B.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-runtime-evidence]). After a revocation at the MAS, the PDP's state check (step 8 of Section 1.1) refuses the next such action once it observes the revocation, within the published staleness bound. The permit example in Section 6.5 shows the decision. B.5. Revoke An authorized party revokes the Mission at the Mission Lifecycle endpoint (Section 5). The agent's token remains valid OAuth (Section 11). Once the PDP's state check observes the revocation, within the published staleness bound, it reports revoked, and the PDP denies the agent's next consequential action with the AuthZEN profile's mission_inactive reason ([I-D.draft-mcguinness-mission-authzen]). The following example shows the denial: { "decision": false, "context": { "evaluation_id": "dec_9tY3sB8zN1eF4jB0K7mQ2sV5rL", "reason": "mission_inactive" } } Appendix C. Document History [[ To be removed from the final specification ]] * Join evidence and the join-failure value (#972 items 27a, 27b, D289). The PDP records join_view_id as a top-level member of the signed Decision Evidence of every decision reached over a successful join, a later policy denial included, and the AuthZEN response carries no view identifier. A failed join denies with the AuthZEN profile's mission_binding_failed in place of mission_mismatch, which this document no longer adds to that profile's denial-reason set; signed records made before the change are left as they are. The AuthZEN examples use the profile's request and response shapes. * Authentication failures (#972 item 18, D289). A 401 from the submission or join-assertion endpoint carries the challenges Mission Status defines, and a failed direct client authentication receives 400 invalid_client. * Assertion audience and submission outcomes (#972, D289). A Join Assertion request names its consuming PDP in a required audience, limited to enrolled PDPs, and the assertion's aud is required and checked by that PDP. The assertion cache is keyed by Mission, token digest, and audience, and a cache hit rechecks visibility and the minting checks. The submission endpoint answers an unsupported media type with 415 unsupported_media_type and a refused requested_derivation_limit with invalid_mission_intent. An expansion Subject mismatch denies with subject_mismatch, registered in the Mission Denial Reasons registry. A missing required reference is refused with mission_reference_conflict, and every submission-status body carries submission_id and status. * Reference and claim consistency (#972, D289). The reference tuple and both carriages share one extension rule. Every deployment documents its mapping contract and an Enterprise MAS publishes it. High-Consequence Binding defines the Mission-bound credential composition inline and keeps the floor and Enterprise requirements distinct; Acting Credentials points at the runtime profile's Custody rule. Join rule 1 names a trusted propagated reference, step 4 compares identity only, Limitations points at the Statement, the credential-holding component validates Instance Context, and approval-surface authentication uses the published floor. * Submission polling and Join Assertion outcomes (#972). The 202 and pending status responses carry an interval; the client waits at least the interval in force (5 seconds by default) between status requests; the status request parameter is submission_id. The join-assertion endpoint mints only for an active Mission and defines its outcomes: invalid_join_request (400) for a malformed body, not_found (404) for an unknown or invisible Mission, and join_failed (403) for a non-active Mission, an inactive or unbound token, or a failed join. Join Assertions are signed with an algorithm listed in mission_status_signing_alg_values_supported, and a PDP rejects none or an unlisted algorithm. * Join inputs on the wire (#972). Mission Status discloses the Mission's subject, client_id, and entry delegation members to PDPs enrolled for its enforcement scope, and enrollment is deployment configuration. The context.mission_join decision-request member carries the join inputs, including a Join Assertion with the presented credential's digest and thumbprint. The assertion carries the join result (join) the PDP narrows with, and supports certificate-bound tokens (x5t#S256). A Join Assertion that fails validation is denied, and mission_max_stale_seconds is required. * Density and OAuth register, with no change to the party, behavior, or keyword of any requirement; two conditions the preceding sentence carried are stated in the requirement itself. The abstract opens "This specification defines" in 129 words; the Introduction states what the OAuth binding answers and what this document answers; no paragraph runs over 130 words; error requirements use the active OAuth form; examples open with "The following"; the Statement's capability table is compacted, with its qualifications listed under it; Security and Privacy Considerations open with pointers to the OAuth binding, Mission Status, and the runtime profile; and persuasive and figurative wording is removed. * Reading order. A Protocol Overview with the MAS-mode flow figure opens the document. The Mission Join, Reference Propagation, and the Join Assertion follow Lifecycle and State; Expansion and Child Creation follow them; Metadata follows every endpoint it lists; and the Mission Substrate Statement follows Conformance. The Mission Join has subsections for its rules, what a join establishes, acting credentials, instance-bound joins, and the AuthZEN encoding. Mission Reference Delivery is a subsection of Mission Submission; the error table names the endpoints that return each code; Terminology defines the join vocabulary; Conformance adds the PEP role, the Join Assertion capability, and the Enterprise profile; Deployment is an appendix; and the end-to- end walkthrough points to the in-body examples and adds revocation. * Corrections. Cross-references name the right sections (the propagation tuple's state source, a client-instance section); Join Spoofing counts four residuals; IANA names both runtime denial reasons; the error table lists join_failed and conflict; RFC 8414 and RFC 9396 are normative references, and the metadata registry uses the RFC 8414 template; the examples show a DPoP-bound Mission-Reference request and classify reads as consequential_read; Estate Prerequisites name local RFC 9068 validation; Progressive Adoption follows the architecture's Assurance Levels; and "the issuance profile" becomes "the OAuth binding" throughout. * Authentication discovery mirrors the Status draft: per-endpoint *_auth_methods_supported and *_auth_signing_alg_values_supported members for the submission, status, and lifecycle endpoints replace mission_auth_methods_supported, and the submission endpoint accepts all three Status mechanisms, including mTLS-bound access tokens. The join-assertion endpoint shares the submission methods but names its own token audience and Protected Resource Metadata. * Specify the PEP/PDP responsibilities for required instance-bound joins and their refusal behavior. Join Assertions continue to carry no instance identifier and do not replace the instance association check; MAS evidence distinguishes participation from presenter attribution. * Client-instance references follow their successors: draft- mcguinness-oauth-client-instance-assertion is replaced by [I-D.draft-mcguinness-oauth-client-instance-id], and the deprecated draft-mcguinness-oauth-ai-agent-instance is no longer cited. The Mission Join binds the instance from Instance Context whose association with the presenter is established (an instance- unique key, plus authenticated provenance for context preserved from an input token) rather than from an act entry; the Join Assertion carries no instance identifier, so an instance-bound join on that path takes the instance from the Instance Context the PEP validated, and the MAS records the token's Instance Context in its join evidence where it received it; and the Enterprise instance-bound join applies where the acting credential carries validated Instance Context. * Pointed MAS Availability at the Runtime and Status Operational Considerations sections for the dependency-specific outage, ride- through, and recovery semantics (#310). No MAS requirement changed. 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