Mission Authority Server

1.1. Applicability

This profile targets deployments that need governed, approvable, revocable agent tasks but cannot extend their Authorization Server, and that can route consequential actions through the runtime profile's enforcement. It is also a deliberate architectural choice in its own right: a deployment MAY prefer a standalone Mission Issuer even where it controls its AS, to keep governance decoupled from token issuance or to govern with one Mission Issuer across many Authorization Servers, accepting the enforcement posture of Section 11. A deployment that wants Mission-bound tokens and issuance gating implements the issuance profile; a deployment that cannot deploy runtime enforcement over its consequential action paths obtains records but no enforcement from this profile and SHOULD NOT claim it (Section 11).¶

The Mission Join (Section 9) is the newest mechanism in the family and not yet exercised in deployment; a deployment that can implement the issuance profile obtains the stronger, stable binding.¶

1.2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

This document uses Mission, Mission Intent, Mission Issuer, Authority Set, Approver, Subject, mission_id, the integrity anchors, and the audit horizon as defined by [I-D.draft-mcguinness-oauth-mission]; the Mission Status operation and Mission Lifecycle endpoint as defined by [I-D.draft-mcguinness-oauth-mission-status]; and PEP, PDP, consequential action, Mission state source, and enforcement scope as defined by [I-D.draft-mcguinness-mission-runtime]. It additionally uses:¶

Mission Authority Server (MAS):

A service that implements the Mission Issuer role of the issuance profile without being an OAuth Authorization Server. It is the issuer of the Missions it records, and it derives no tokens.¶

Mission-joining PDP:

A PDP that resolves Missions at a MAS and verifies the join between a presented credential and the referenced Mission before evaluating an action (Section 9).¶

Standalone binding:

This document's deployment mode: the Mission Issuer role implemented by a MAS, with the deployment's tokens unchanged. The rest of the Mission family cites this mode by this name; "AS-optional" is its informal gloss.¶

3.1. Intent Submission

The request body is a Mission Intent as the issuance profile defines it, and the issuance profile's validation rules apply unchanged ([I-D.draft-mcguinness-oauth-mission]): the Intent is untrusted client input and never authority; the MAS MUST bound its total size and array lengths; and the Intent is closed at the top level. The issuance profile's OAuth error outcomes map to this endpoint's error codes (Section 3.3):¶

• A body that cannot be parsed as a JSON [RFC8259] object, is structurally invalid, exceeds the deployment's size bounds, or contains a top-level member the issuance profile does not define MUST be refused with invalid_mission_intent (the MAS equivalent of the issuance profile's invalid_request rejections, including reject-unknown-top-level-member).¶

• A well-formed Intent from which the MAS cannot derive a valid Authority Set under policy MUST be refused with invalid_authority (the MAS equivalent of invalid_authorization_details), so a client can distinguish a syntax error from an authority-derivation failure.¶

On acceptance the MAS derives the Authority Set from the Intent under the issuance profile's derivation rules ([I-D.draft-mcguinness-oauth-mission]) and returns HTTP 202 with a pending-submission reference:¶

submission_id:

REQUIRED. A string. An opaque URL-safe ASCII string of [A-Za-z0-9_-] characters with at least 128 bits of entropy, carrying no semantic content. It MUST NOT be reused. It is a reference, never a capability.¶

status:

REQUIRED. A string. pending on acceptance.¶

expires_at:

REQUIRED. A string. An RFC 3339 [RFC3339] date-time after which an undecided submission lapses to expired.¶

Example:¶

POST /mas/mission/submit HTTP/1.1
Host: mas.example.com
Content-Type: application/json
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

{
  "goal": "Reconcile Q3 invoices and post adjustments under $500.",
  "resources": ["https://erp.example.com"],
  "expires_at": "2026-12-31T23:59:59Z"
}

HTTP/1.1 202 Accepted
Content-Type: application/json
Cache-Control: no-store

{
  "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP",
  "status": "pending",
  "expires_at": "2026-10-16T14:32:11Z"
}

3.2. Submission Status

The client polls the outcome with a form-urlencoded POST carrying:¶

submission:

REQUIRED. A string. The submission_id.¶

A submission is in one of four states:¶

Only approved delivers a Mission: a consumer MUST treat every other status value, recognized or not, as not approved, mirroring the issuance profile's only-active rule. A resolved submission MUST remain resolvable for a deployment-defined window; the reference is never reused.¶

The MAS MUST return submission status only to the authenticated client that submitted the Intent. For any other caller, and for an unknown submission_id, the MAS MUST return the not_found error with an identical status code, body, and headers, preserving the anti-oracle property of [I-D.draft-mcguinness-oauth-mission-status].¶

3.3. Error Responses

A hard failure returns the matching HTTP status with a JSON object body:¶

error:

REQUIRED. A string. A code from the table below.¶

error_description:

OPTIONAL. A string. Human-readable detail.¶

error_reason:

OPTIONAL. A string. A machine-readable refinement of error: for invalid_mission_intent, the name of the offending top-level member; for invalid_authority, the resources entry no authority could be derived for. It reflects the client's own input and MUST NOT disclose policy internals.¶

A consumer MUST ignore members it does not recognize.¶

7.1. Submission Carriage

The mission submission endpoint carries both operations as intent submissions (Section 3.1) with additional top-level members of the request body:¶

predecessor:

A string. The mission_id of the predecessor Mission this submission expands; semantics per the expansion profile. Its presence marks the submission as an expansion request.¶

parent:

A string. The mission_id of the Parent Mission; semantics per the child-delegation profile.¶

child_actor:

An object identifying the child actor, in the form the child-delegation profile defines. The presence of parent and child_actor together marks the submission as a child-creation request.¶

These are submission members, not Mission Intent members: a MAS that implements this capability MUST remove them before applying the issuance profile's Intent validation, and the remainder of the body is the Mission Intent, validated unchanged (Section 3.1). On a MAS that does not implement this capability they are undefined top-level members and the submission is refused with invalid_mission_intent, the correct refusal for an unsupported operation.¶

A submission carrying both predecessor and either child member MUST be refused with invalid_mission_intent: the operations do not combine. A submission carrying parent without child_actor, or child_actor without parent, MUST be refused the same way.¶

The predecessor_token and parent_token parameters of the OAuth wire do not exist on this surface; the binding of Section 7.2 replaces them.¶

The referenced profiles' OAuth error outcomes map onto this endpoint's error surface as the issuance profile's do (Section 3.1): invalid_request outcomes map to invalid_mission_intent, and authority-derivation failures to invalid_authority. Two rules cover the outcomes those profiles express as invalid_grant:¶

• A predecessor or parent the binding does not resolve, whether the Mission does not exist or is recorded under another client, MUST be refused with not_found, with a response identical in both cases, preserving the anti-oracle property of Section 3.2.¶

• A reference the binding resolves whose state or serialization refuses the operation (the expansion profile's predecessor-active and reconciliation rules; the child-delegation profile's parent-active rule) MUST be refused with conflict, returned with HTTP 409. conflict extends the error code set of Section 3.3 and is used only by this section's operations.¶

The profile-defined machine-readable code rides the MAS error surface in the member its profile defines, mission_expansion_status for expansion ([I-D.draft-mcguinness-oauth-mission-expansion]) and mission_denial_reason for child creation ([I-D.draft-mcguinness-oauth-mission-child-delegation]), carried as a member of the error response body (Section 3.3) or, for a denial at adjudication, of the denied submission-status response (Section 3.2).¶

7.2. Request Binding

The OAuth wire resolves the predecessor or parent from a presented grant and cross-checks it against the named identifier. A MAS holds no grants, so the named identifier is itself the reference, and the MAS binds the request to it as follows:¶

• The MAS MUST verify that the authenticated submitting client is the client recorded as the predecessor Mission's client_id (for expansion) or the Parent Mission's client_id (for child creation). Both identifiers live in the MAS's own client namespace (Section 3), so the comparison is ordinarily byte-equality; where a deployment maps client identities it MUST document the mapping, exactly as the client join requires (Section 9).¶

• For an expansion, the MAS MUST verify at the approval event that the Subject it establishes (Section 4) equals the predecessor Mission's subject; a successor MUST NOT be created for a different Subject.¶

This is an authentication-based binding, not a possession-based one: it proves the requester is the same registered client the predecessor or parent was recorded for, not that it holds that Mission's grant. The delta from the OAuth wire is exactly that: a party able to authenticate as the registered client can request these operations for any of that client's Missions, where token possession would limit it to the grants it actually holds (Section 13.3).¶

Where the deployment authenticates client instances ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the MAS SHOULD bind at instance granularity rather than at the bare client_id, and a Mission Join Assertion for the predecessor or parent (Section 10), presented with the submission, strengthens the proof to a named runtime instance holding a sender-constrained credential that verifiably joins to that Mission.¶

7.3. Expansion Semantics

An expansion submission is adjudicated under the expansion profile's rules ([I-D.draft-mcguinness-oauth-mission-expansion]), applied by reference:¶

• Predecessor active. The predecessor MUST be active when the submission is accepted, per that profile's predecessor-active rule.¶

• Reconciliation. Concurrent expansions against the same predecessor are serialized under that profile's compare-and-set reconciliation, and its closed reconciliation-status set applies: a refusal at submission carries the code per Section 7.1, and a pending submission overtaken by a concurrent expansion resolves to denied with the code in the status response.¶

• Supersession atomicity. In one atomic operation on the MAS's records, the successor activates with its predecessor member set, and the predecessor transitions to superseded with its successor member set. The successor and related_to members carry that profile's semantics and surface through the MAS's Mission Status responses; superseded enters the state space the MAS reports (Section 6).¶

• Denial reasons. That profile's closed denial-reason set applies; the code rides in mission_expansion_status per Section 7.1.¶

Approval of the successor is this document's native asynchronous approval event (Section 4): fresh consent for the successor's derived Authority Set, with no authorization-code leg to re-sequence. On approval the client's poll delivers the successor's mission_id and consented authority (Section 5). The successor-expiry rule and every other expansion rule that does not name the OAuth wire apply unchanged. Progressive authorization is out of scope here exactly as it is out of the expansion profile's base: every expansion on this surface is adjudicated by a fresh approval, and the policy-adjudicated variant remains the experimental companion's ([I-D.draft-mcguinness-oauth-mission-progressive]).¶

7.4. Child-Creation Semantics

A child-creation submission is adjudicated under the child-delegation profile's rules ([I-D.draft-mcguinness-oauth-mission-child-delegation]), applied by reference:¶

• On-switch. Child creation is permitted only where the applicable Parent Mission Authority Set entry's delegation member carries a children object; an entry without one permits no child.¶

• Strict subset. The child Authority Set MUST satisfy that profile's strict-subset evaluation against the parent, with no relaxation.¶

• Fan-out. Fan-out accounting and its serialization apply unchanged: the MAS counts non-terminal Child Missions against max_children and serializes creation against the same parent entry and fan-out bucket.¶

• Parent member. The Child Mission record carries the parent object constructed per that profile, including depth; with no token carrier, it surfaces through the record and the MAS's Mission Status responses.¶

• Cascade. Cascade applies with one simplification: the MAS owns its state store, so cascade transitions are native lifecycle transitions on its own records. The MAS implements that profile's immediate mode, and the cascaded state surfaces through Mission Status (Section 6).¶

• Denial reasons. That profile's closed denial-reason set applies; the code rides in mission_denial_reason per Section 7.1. The parent_mismatch reason has no analog on this surface: with no parent_token to cross-check, a binding failure is refused per Section 7.1.¶

The child client identity rules hold unchanged: the child actor is the Child Mission's client, recorded as its client_id; it authenticates itself to the MAS for its own submissions, status, and lifecycle operations; and child credentials MUST NOT transit the parent. The creating client learns the Child Mission's mission_id from its own submission status; mission_id is a reference, never a capability, so conveying it to the child actor moves no authority. At the point of use, the Mission Join (Section 9) binds the child's ordinary OAuth credentials to the Child Mission through the child's own client_id, never the parent's.¶

7.5. Expansion Example

Mid-task, the agent behind the Q3 reconciliation Mission finds a $1,200 adjustment, outside its approved $500 cap. It submits an expansion: a Mission Intent for the broadened task whose body names the predecessor:¶

POST /mas/mission/submit HTTP/1.1
Host: mas.example.com
Content-Type: application/json
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

{
  "goal": "Reconcile Q3 invoices and post adjustments under $2,000.",
  "resources": ["https://erp.example.com"],
  "expires_at": "2026-12-31T23:59:59Z",
  "predecessor": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-"
}

The MAS authenticates the client, verifies it is the predecessor's recorded client_id, verifies the predecessor is active, strips predecessor, validates the remaining Mission Intent, derives the successor's Authority Set, and accepts:¶

HTTP/1.1 202 Accepted
Content-Type: application/json
Cache-Control: no-store

{
  "submission_id": "sub_7bD1eF4jB0K9wT2xM5nQ8rL3vZ",
  "status": "pending",
  "expires_at": "2026-10-16T15:07:42Z"
}

Adjudication proceeds per Section 4: the Approver consents to the widened cap, the MAS verifies the established Subject equals the predecessor's subject, and one atomic operation creates the successor active and supersedes the predecessor. The client's next poll returns approved with the successor's mission_id (Section 5).¶

10.1. Assertion Request

The PEP, or the client acting for it, POSTs a JSON object:¶

mission_id:

REQUIRED. A string. The Mission the join is asserted against; its issuer is the MAS.¶

access_token:

A string. The acting access token. REQUIRED unless the digest pair is present.¶

token_sha256:

A string. The unpadded base64url SHA-256 digest of the access token's ASCII bytes.¶

token_jkt:

A string. The JWK thumbprint [RFC7638], using SHA-256, of the token's cnf public key.¶

The caller presents access_token, or token_sha256 together with token_jkt. The digest pair keeps the credential itself off this wire, but it is usable only where the deployment's introspection surface can resolve a token by digest; access_token is the interoperable form. The acting token MUST be sender-constrained: a token without a cnf key gives the assertion nothing to bind, and the MAS MUST NOT mint one for it.¶

The MAS verifies the join centrally:¶

1. It introspects the token at the deployment's Authorization Server [RFC7662], under introspection credentials the MAS holds there. Calling the AS is permitted in MAS mode; changing it is not. A token the AS reports inactive fails the request.¶

2. It verifies the subject and client joins of Section 9 against the introspection response, under its own documented account and client mappings and delegate policy.¶

A token that does not join is refused with the join_failed error (HTTP 403), in the error format of Section 3.3; like conflict, it extends that section's error code set. An unknown or not-visible mission_id returns not_found, preserving the anti-oracle property.¶

10.2. The Assertion

On success the MAS mints a Mission Join Assertion: a signed JWT [RFC7519] whose protected header carries the typ mission-join+jwt and a kid resolvable in the MAS's jwks_uri. Its claims:¶

iss:

REQUIRED. The MAS's issuer URL.¶

mission:

REQUIRED. An object containing id, issuer, and authority_hash.¶

token:

REQUIRED. An object containing sha256, the token digest as in Section 10.1, and jkt, the thumbprint of the token's cnf public key [RFC7638].¶

iat:

REQUIRED. Issuance time.¶

exp:

REQUIRED. Expiry. It MUST NOT exceed the access token's remaining lifetime.¶

aud:

OPTIONAL. The PDP or PDPs the assertion is minted for.¶

When the introspected token carries instance identity ([I-D.draft-mcguinness-oauth-client-instance-assertion]), the MAS SHOULD include the instance identifier in the token object: the act entry's sub, and the agent_instance_id where the agent profile ([I-D.draft-mcguinness-oauth-ai-agent-instance]) is in use. Under that profile the cnf key the jkt thumbprint binds is instance-specific, never shared across a client's instances, so the assertion's token binding is materially stronger: it names one runtime instance, not any holder of a client-shared key.¶

The endpoint returns HTTP 200 with a JSON object whose assertion member carries the JWT. Each minting is a join evidence event: the MAS records the Mission reference, the token digest and thumbprint, the authenticated caller, and the validity window, retained for the audit horizon.¶

Example claims:¶

{
  "iss": "https://mas.example.com",
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://mas.example.com",
    "authority_hash":
      "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ"
  },
  "token": {
    "sha256": "rN2kQ4mZ7tP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2n",
    "jkt": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs"
  },
  "iat": 1793606400,
  "exp": 1793608200
}

10.3. PDP Consumption

A PDP presented with a Join Assertion verifies, in place of the mapping checks of Section 9 steps 3 and 4:¶

• the signature, under a key from the MAS's jwks_uri, and the mission-join+jwt header typ;¶

• that iss and the mission claim match the referenced Mission's issuer, id, and authority_hash;¶

• that exp has not passed and any aud names this PDP; and¶

• the token binding: the presented credential's digest equals token.sha256 and its cnf key's thumbprint equals token.jkt.¶

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

For the high-consequence action classes ([I-D.draft-mcguinness-mission-runtime]) in MAS mode, the PDP SHOULD require a Join Assertion. The mapping join of Section 9 remains the conformance floor: a deployment without the endpoint still joins, and a PDP MUST NOT treat possession of an assertion as authority, per the family rule that references and binding proofs grant nothing.¶

13.1. Join Spoofing

A client cannot gain authority by asserting another party's mission_id: the join requires the credential's authenticated subject and client to match values the MAS recorded at approval, which the client cannot alter, so a reference to someone else's Mission fails with mission_mismatch. The residual is mapping coarseness. Where the deployment's account mapping is many-to-one (several AS accounts map to one directory subject), any credential in the equivalence class joins; a deployment SHOULD keep the mapping one-to-one for subjects that hold Missions and MUST document its granularity. The client join is coarse the same way where several workloads share one client_id: any of them joins. Client instance assertions ([I-D.draft-mcguinness-oauth-client-instance-assertion]) are the standard fix: the join then binds the validated instance (Section 9), and this residual remains only for deployments without instance identity. A second residual: two Missions held by the same subject and client are distinguished only by the PEP-supplied reference, so a faulty or compromised PEP can attribute work to the wrong same-party Mission, bounded by that Mission's authority and visible in evidence.¶

The Mission Join Assertion (Section 10) is the mitigation for the coarse-mapping and shared-client residuals: the MAS evaluates the mapping once, centrally, under its documented policy, and binds the result to one introspected token by digest and key thumbprint, so the join stops being a standing property of every credential in an equivalence class and becomes a minted, audited, token-bound event.¶

13.2. Join Assertion Trust

A captured Join Assertion moves no authority: it names one token by digest and key thumbprint, so a replay without that token and its sender-constraint key proves nothing, and exp, capped at the token's remaining lifetime, bounds the window in which the proof is live. The introspection call names a trust relationship specific to this upgrade: the MAS relies on the deployment's AS, through RFC 7662 introspection, for the token's validity, subject, and client, and the deployment documents that reliance and protects the MAS's introspection credentials accordingly. The structural gain is concentration: the subject and client mappings are evaluated at one audited point under one documented policy, instead of configured independently at N PDPs, where one drifted table is a silent join widening.¶

13.3. Expansion and Child-Creation Binding

The native surfaces of Section 7 bind a request to its predecessor or parent by authenticated client identity, not by grant possession, and the residual is exactly that difference: a compromised or impersonated registered client can request expansion or child creation for any Mission recorded under its client_id, where token possession would have limited it to the grants it actually holds. The mitigations: instance-grade binding ([I-D.draft-mcguinness-oauth-client-instance-assertion]) shrinks the client_id equivalence class to one runtime instance, and a Mission Join Assertion presented with the submission makes that instance a verified, token-bound party (Section 7.2); the expansion profile's fresh-approval requirement means no widening activates without the Approver, so a forged expansion request yields an approval prompt, not authority; the child-delegation profile's fan-out controls bound what child creation can amplify; and the binding failure surface is anti-oracle (Section 7.1), so a request against a Mission the client is not bound to is indistinguishable from one against a Mission that does not exist.¶

13.4. Ambient Authority of Ungated Tokens

The central residual of this mode: tokens are ordinary OAuth tokens, so within their lifetime and scope they work wherever PEP coverage is absent, and Mission revocation does not touch them. Mitigations are short token lifetimes at the AS, narrow scope hygiene for agent clients, and complete PEP coverage of consequential paths; none eliminates the residual, which only the issuance profile's gating removes (Section 11).¶

13.5. MAS Availability

The runtime layer fails closed when Mission state cannot be established within the staleness bound, so a MAS outage converts into work stoppage for governed actions, not into loosened enforcement (the availability trade the security model states, [I-D.draft-mcguinness-mission-security-model]). A deployment provisions MAS availability accordingly and sizes mission_max_stale_seconds to the caching it can tolerate.¶

13.6. MAS Compromise

Compromise of a MAS is equivalent to Mission Issuer compromise: it can forge approvals, alter records, and report false state. One consequence is specific to this mode: the PDP join is the only credential-to-Mission binding, so a compromised MAS combined with the PDP's trust in it yields arbitrary attribution of authority to any credential the join accepts. Consent Evidence commitments ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) and audit transparency ([I-D.draft-mcguinness-mission-audit]) make forgery detectable after the fact; signing-key custody and the status profile's key-retention rules keep archived state evidence verifiable.¶

13.7. Approval Surface Authentication

The MAS's review surface is the approval event surface, and the issuance profile's approval rules apply to it unchanged: the Approver is authenticated to the acr mapping, the Subject is never taken from client input, client text is rendered inert, and derived authority is visually distinguished from it (Section 4). The submission, status, and lifecycle endpoints reject unauthenticated callers and preserve the anti-oracle property ([I-D.draft-mcguinness-oauth-mission-status]).¶

15.1. Well-Known URI Registration

IANA is requested to register the following in the "Well-Known URIs" registry [RFC8615]:¶

• URI Suffix: mission-authority-server¶

• Change Controller: IETF¶

• Specification Document: this document, Section 8¶

• Status: permanent¶

• Related Information: none¶

15.2. Mission Authority Server Metadata Registry

IANA is requested to create the "Mission Authority Server Metadata" registry, with a registration policy of Specification Required [RFC8126]. Each entry has: Member Name, Change Controller, and Reference. The registry is seeded with the members of Section 8; for each, Change Controller IETF and Reference this document:¶

• issuer¶

• mission_submission_endpoint¶

• mission_status_endpoint¶

• mission_status_signing_alg_values_supported¶

• mission_lifecycle_endpoint¶

• mission_auth_methods_supported¶

• mission_join_assertion_endpoint¶

• mission_event_stream_endpoint¶

• mission_max_stale_seconds¶

• jwks_uri¶

15.3. Runtime Denial Reason

mission_mismatch extends the denial-reason set of [I-D.draft-mcguinness-mission-authzen] under that profile's denial-reason extensibility rule (Section 9). That profile's denial reasons are AuthZEN extension data and are not registered in an IETF registry, so this document requests no IANA action for it.¶

16.1. Normative References

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

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

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

[RFC8615]

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

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

16.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-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-ai-agent-instance]

McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth-ai-agent-instance-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-ai-agent-instance-00>.

[I-D.draft-mcguinness-oauth-client-instance-assertion]

McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth-client-instance-assertion-01, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-assertion-01>.

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

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

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

A.1. Submit

The client proposes the Mission by POSTing its Mission Intent to the submission endpoint; the MAS validates it, derives the Authority Set under policy, and returns a pending-submission reference (Section 3).¶

POST /mas/mission/submit HTTP/1.1
Host: mas.example.com
Content-Type: application/json
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

{
  "goal": "Reconcile Q3 invoices and post adjustments under $500.",
  "resources": ["https://erp.example.com"],
  "expires_at": "2026-12-31T23:59:59Z"
}

HTTP/1.1 202 Accepted
Content-Type: application/json
Cache-Control: no-store

{
  "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP",
  "status": "pending",
  "expires_at": "2026-10-16T14:32:11Z"
}

A.2. Poll to Approved

The MAS routes the submission to its approval surface; the Approver authenticates, reviews the rendered Authority Set, and approves, and the MAS creates the Mission active atomically with the decision (Section 4). The client's next poll returns the Mission reference and its consented authority (Section 5).¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "submission_id": "sub_4qV9rL3tY6sB1zN0eF7jB8K2nP",
  "status": "approved",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://erp.example.com",
      "actions": ["invoices.read", "journal-entries.write"],
      "constraints": {
        "max_amount": { "amount": "500.00", "currency": "USD" }
      } }
  ]
}

A.3. Join

The agent works under an ordinary OAuth token from the unchanged AS, which carries no Mission signal. For the first consequential action, the PEP supplies the Mission reference, with authority_hash and state from the MAS's signed Mission Status response, and the PDP verifies the subject and client joins (Section 9).¶

{
  "subject": {
    "type": "user",
    "id": "user_3p2q8mN1a0kV7tR",
    "properties": { "iss": "https://idp.example.com" }
  },
  "resource": { "type": "invoice", "id": "inv_2026Q3_842" },
  "action": { "name": "invoices.read" },
  "context": {
    "mission": {
      "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "issuer": "https://mas.example.com",
      "authority_hash":
        "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ",
      "state": "active"
    }
  }
}

A.4. Permit

The join holds and the action is within the Mission's Authority Set, so the PDP permits; the PEP executes the call to https://erp.example.com, and both record their evidence ([I-D.draft-mcguinness-mission-authzen]). A revocation at the MAS stops the next such action at this step, through the runtime state re-check.¶

{
  "decision": true,
  "context": {
    "decision_id": "dec_7mQ2sV5rL9tY3sB8zN1eF4jB0K",
    "policy_view_id":
      "sha-256:kP3xR9sQ7nM2vL4tY6bD1eF8jC5wH0pV2nR3kQ4mZ7t",
    "action_class": "irreversible_action",
    "class_source": "resource_floor",
    "permit_expires_at": "2026-11-02T08:15:30Z"
  }
}