Mission Authority Server

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

• 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).¶

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, 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:¶

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

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; 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.¶

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

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 (Section 8.1).¶

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]) or from deployment configuration. In the AuthZEN profile ([I-D.draft-mcguinness-mission-authzen]) this reference is context.mission; the PEP additionally populates state, and authority_hash where the MAS's signed Mission Status response discloses it, as OPTIONAL enrichment beyond the required id and issuer.¶

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_mismatch.¶

6. Join failure is a deny. A failure of the subject or client join MUST be denied with the mission_mismatch denial reason: 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. A decision reached over a successful join MUST carry a joined-view commitment (join_view_id) separate from policy_view_id, which alone does not distinguish a joined decision from a direct one. 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 mission-credential-bound composition of the Mission Binding Properties ([I-D.draft-mcguinness-mission-architecture]).¶

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, acting credentials for governed work MUST be sender-constrained. 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 PDP 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).¶

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 the PDP has validated that Instance Context and established its association with the presenter, 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 PEP under the decision API's trust boundary.¶

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_mismatch 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 populated from its Mission binding, with state (and authority_hash where disclosed) taken from the MAS's signed Mission Status response, and the other decision inputs per [I-D.draft-mcguinness-mission-authzen]:¶

{
  "subject": {
    "type": "user",
    "id": "user_3p2q8mN1a0kV7tR",
    "properties": { "iss": "https://idp.example.com" }
  },
  "resource": { "type": "invoice", "id": "inv_2026Q3_842" },
  "action": { "name": "invoices.read" },
  "context": {
    "mission": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "issuer": "https://mas.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "state": "active"
    },
    "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": {
    "decision_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "join_view_id":
      "sha-256:dV7wM3sK9nQ2vL5tR8bY1eG4jF6xH0pC3nT9kV2mZ5t",
    "action_class": "consequential_read",
    "class_source": "resource_floor",
    "permit_expires_at": "2026-11-02T08:15:30Z"
  }
}

The join_view_id member accompanies policy_view_id because this decision was reached over the join (rule 9 of Section 6.1). The direct-client disposition and client_id it binds distinguish it from a differently-joined decision (a narrowed delegate view) and from a direct Mission-bound decision, which never carries join_view_id.¶

The AuthZEN profile's denial-reason extensibility rule permits a companion profile to extend the denial-reason set by specification, and requires a consumer to treat an unrecognized reason as a deny ([I-D.draft-mcguinness-mission-authzen]). Where this document is implemented, mission_mismatch and mission_reference_conflict (Section 7.4) are members of that set; neither requires IANA action under that extension-by-specification model. A consumer that does not implement this document treats them 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": {
    "decision_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K",
    "denial_reason": "mission_mismatch",
    "action_class": "consequential_read",
    "class_source": "resource_floor",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  }
}

7.1. The Reference Tuple

The propagated value is exactly 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. 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.¶

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 exactly two members, both REQUIRED: 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 other than the two defined here. A profile the deployment adopts MAY define an additional member by specification. A receiver MUST NOT act on a member it does not implement.¶

• 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 exactly 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 other than mission_id and issuer, 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 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, beside mission_mismatch (Section 6). The mission_mismatch reason remains the subject-or-client join failure, and mission_reference_conflict covers reference sources naming different Missions or an unusable reference.¶

• 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": {
    "decision_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K",
    "denial_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.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.¶

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 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 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 repeated requests for the same (token digest, audience) pair from cache within the assertion's lifetime, so a burst of re-mints for an unchanged token costs one evaluation rather than many.¶

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:

RECOMMENDED. The PDP or PDPs for which the assertion is minted. 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"
  },
  "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 any aud names this PDP; 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_mismatch.¶

Every other join rule holds unchanged: the PDP resolves Mission state at the MAS under the runtime profile's freshness rules, denies with mission_mismatch when any check above fails, and draws authority from the Mission.¶

For 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.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.¶

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 closed denial-reason set applies; 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).¶

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. 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, and, where both convey authority_hash, a consistent value too, denying on any mismatch;¶

5. applies current Mission state, current authority, the subject, client, and actor checks, and the sender proof, 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 acting in the high-consequence classes. The join requires sender-constraint for those classes (Section 6), and 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). An enterprise MAS MUST publish a mapping contract stating, for the joins it performs:¶

• the subject namespace mapping (how a credential's authenticated subject maps to the Mission's subject);¶

• the client namespace mapping (how a credential's client maps to the Mission's client_id);¶

• the delegate policy applied to act-chain actors, 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_mismatch 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.¶

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_mismatch. 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 acr mapping, 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]).¶

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.5. Runtime Denial Reasons

mission_mismatch and mission_reference_conflict extend the denial-reason set of [I-D.draft-mcguinness-mission-authzen] under that profile's denial-reason extensibility rule (Section 6, Section 7.4). 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.1. Normative References

[I-D.draft-mcguinness-mission-approval-governance]

McGuinness, K., "Mission Approval Governance", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html>.

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-mission-runtime-evidence]

McGuinness, K., "Mission Runtime Evidence", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime-evidence.html>.

[I-D.draft-mcguinness-mission-substrate]

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

[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, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-id-00>.

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[I-D.draft-mcguinness-oauth-mission-submission-evidence]

McGuinness, K., "Mission Intent Submission Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-submission-evidence.html>.

[MCP-META]

Model Context Protocol Project, "Model Context Protocol: Base Protocol", 2026, <https://modelcontextprotocol.io/specification/2026-07-28/basic/index>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[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, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[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, <https://www.rfc-editor.org/rfc/rfc9325>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9651]

Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/rfc/rfc9651>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

18.2. Informative References

[I-D.draft-mcguinness-mission-architecture]

McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html>.

[I-D.draft-mcguinness-mission-audit]

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-harness]

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

[I-D.draft-mcguinness-mission-mandate]

McGuinness, K., "Mission Mandate", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>.

[I-D.draft-mcguinness-mission-security-model]

McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-attenuation]

McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-attenuation.html>.

[I-D.draft-mcguinness-oauth-mission-consent-evidence]

McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.

[I-D.draft-mcguinness-oauth-mission-derivation-limits]

McGuinness, K., "Mission Derivation Limits for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-derivation-limits.html>.

[I-D.draft-mcguinness-oauth-mission-issuance-grant]

McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-issuance-grant.html>.

[I-D.draft-mcguinness-oauth-mission-management]

McGuinness, K., "Mission Management for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-management.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[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, <https://www.rfc-editor.org/rfc/rfc8126>.

[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, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[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, <https://www.rfc-editor.org/rfc/rfc9449>.

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). A high-consequence enforcement claim requires issuance mode's machinery or the Estate Prerequisites' AS features (Section 12.2), never records alone. 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.¶

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 state (and authority_hash where the response discloses it) from the MAS's signed Mission Status 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": {
    "decision_id": "dec_9tY3sB8zN1eF4jB0K7mQ2sV5rL",
    "denial_reason": "mission_inactive",
    "action_class": "consequential_read",
    "class_source": "resource_floor",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t"
  }
}