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

The Mission Join (Section 10) is the newest mechanism in the family and, like every mechanism in this family, has no known production deployment; a deployment that can implement the OAuth binding obtains the token-plane chokepoint (Mission-bound credentials and issuance gating), a capability difference between the bindings rather than a maturity one.¶

4.1. Intent Submission

The request body is a Mission Intent Submission envelope as the issuance profile defines it, intent plus OPTIONAL evidence, and the issuance profile's validation and Intent Submission Evidence rules apply unchanged ([I-D.draft-mcguinness-oauth-mission]): the submission is untrusted client input and never authority; the MAS MUST bound its total size, array lengths, evidence entry count, and evidence verification cost; and the envelope and the Intent are both closed at the top level. The issuance profile's OAuth error outcomes map to this endpoint's error codes (Section 4.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.¶

• An Intent Submission Evidence entry of an unsupported type, an entry that fails its type's verification, or a policy-required evidence type absent from the submission MUST be refused with invalid_intent_evidence (the MAS equivalent of the issuance profile's invalid_mission_intent_evidence); 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. This member is this binding's proposal carriage, replacing the issuance profile's PAR-only carriage rule; that profile's validation, derivation, recording, and hashing semantics apply unchanged ([I-D.draft-mcguinness-oauth-mission]). It is a proposal, never authority, and it is a submission member, not a Submission-envelope member (Section 8.1): the MAS MUST remove it before applying the envelope validation above. The issuance profile'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 issuance profile's Mission record defines them.¶

A MAS has no derivation event: no token is issued under the Mission, so controls.max_derivations binds nothing here (a MAS implementing the issuance-grant companion has one, each grant minted, and applies that profile's counting rule, [I-D.draft-mcguinness-oauth-mission-issuance-grant]). A MAS SHOULD refuse an Intent that carries it, or record it and ensure the approval rendering marks it non-binding, per the issuance profile's rule that consent is not given to a limit that binds nowhere. The same treatment applies to any future control 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 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...

{
  "intent": {
    "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"
}

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

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

This aligns with the OAuth-shaped surfaces' shared error idiom [I-D.draft-mcguinness-oauth-mission-status]: an error/ error_description JSON object body, application/json with Cache-Control: no-store, and error_description diagnostic and never authorization input. This surface's own requiredness stays as above: 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 does not extend here, a deliberate, frozen divergence.¶

8.1. Submission Carriage

The mission submission endpoint carries both operations as intent submissions (Section 4.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 Submission envelope, validated unchanged (Section 4.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 OAuth wire's token-exchange possession proof, the predecessor or parent Mission-bound access token presented as subject_token, does not exist on this surface; the binding of Section 8.2 replaces it.¶

The referenced profiles' OAuth error outcomes map onto this endpoint's error surface as the issuance profile's do (Section 4.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 4.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 4.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: a reconciliation status in mission_expansion_status ([I-D.draft-mcguinness-oauth-mission-expansion]) and an adjudication denial reason, for expansion and child creation alike, 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]), carried as a member of the error response body (Section 4.3) or, for a denial at adjudication, of the denied submission-status response (Section 4.2).¶

8.2. Request Binding

The OAuth wire resolves the predecessor or parent from the Mission-bound access token presented as the token exchange's subject_token, proving possession against that token's confirmation key, and treats any named identifier only as a cross-check. A MAS holds no such tokens, 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 4), 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 10).¶

• For an expansion, the MAS MUST verify at the approval event that the Subject it establishes (Section 5) 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 and can prove possession of that Mission's access token. 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 the token-exchange possession proof would limit it to the Missions whose Mission-bound access token it holds and can prove control of (Section 17.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 12), presented with the submission, strengthens the proof to a named runtime instance holding a sender-constrained credential that verifiably joins to that Mission.¶

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

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

Approval of the successor is this document's native asynchronous approval event (Section 5): 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 6). 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]).¶

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

• Denial reasons. That profile's closed denial-reason set applies; the code rides in mission_denial_reason per Section 8.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 8.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 10) binds the child's ordinary OAuth credentials to the Child Mission through the child's own client_id, never the parent's.¶

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

{
  "intent": {
    "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 Submission envelope, 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 5: 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 6).¶

11.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 issuance profile'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 4.2), and a request carrying any of them in this channel MUST be refused, never silently ignored, so ambiguity is detectable rather than absorbed. The tuple is single-homed: each carriage below maps this one tuple, and a new carrier profiles it rather than defining a second.¶

11.2. HTTP Carriage: Mission-Reference

Mission-Reference is an HTTP request field [RFC9110] whose value is a Structured Fields Dictionary [RFC9651] (shown wrapped for layout; the field is one line):¶

POST /call HTTP/1.1
Host: gateway.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
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 9). 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 enough. 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. Field lines that do not combine into exactly one Dictionary satisfying every rule above, or any parse failure, make the reference 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]).¶

11.3. MCP Carriage

For a tool call governed through MCP, the reference rides the request's params._meta object on each tools/call, never tool arguments and never session state, under the key 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):¶

{
  "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 11.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 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. A future MCP extension or capability mechanism may supersede this carriage; the tuple's semantics stay this section's.¶

11.4. Verification and Conflict

• The value is a selection assertion, never authority: its presence or content grants nothing, the Mission is established only through the Mission Join (Section 10), and an unverified reference MUST NOT establish the Mission, 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, a member this profile adds to the AuthZEN denial-reason set under its extensibility rule beside mission_mismatch (Section 10): mission_mismatch stays the subject-or-client join failure, and mission_reference_conflict is reference sources naming different Missions or an unusable reference.¶

• 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 rides the deployment's TLS, which authenticates the channel endpoint, never which component attached the value: transport protection does not upgrade self-asserted attribution. Where HTTP Message Signatures [RFC9421] are deployed on the request, the signature MUST cover Mission-Reference.¶

Example denial for a propagated reference conflicting with the PEP's recorded binding:¶

{
  "decision": false,
  "context": {
    "decision_id": "dec_2nP4qV9rL3tY6sB1zN0eF7jB8K",
    "denial_reason": "mission_reference_conflict"
  }
}

11.5. Forwarding and Privacy

The tuple is a stable correlator and lands in gateway logs. An intermediary MUST NOT copy the field or the _meta key onto a request to an unrelated authority domain, and a terminating PEP SHOULD remove it before forwarding unless the downstream recipient participates in the same verified binding. The issuance profile's Mission Identifier correlation considerations apply to logged values.¶

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

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

1. It 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, and 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 RFC 9068 [RFC9068] semantics, 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. It verifies the subject and client joins of Section 10 against the introspection response or the validated token claims, 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 4.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.¶

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

Assertion lifetime is capped by the token's, so short token lifetimes put minting on the rotation path: each rotation needs a fresh assertion and its introspection call, per Mission and per workload. A deployment amortizes deliberately: it sizes agent token lifetimes to the runtime layer's revocation cutoff rather than treating expiry as the kill switch (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.¶

That same position makes minting a denial-of-service surface: it is a hot, per-action-adjacent path, invoked on every rotation for every Mission and workload the MAS serves. 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.¶

12.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; exact validation of that typ, with mutually exclusive validation rules for the artifact profiles, implements the substitution defense of [RFC8725], Sections 3.11 and 3.12. 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 12.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:

RECOMMENDED. The PDP or PDPs the assertion is minted for; 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 14.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.¶

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, the mapping version where one is published (Section 14.3), 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
}

12.3. PDP Consumption

A PDP presented with a Join Assertion verifies, in place of the mapping checks of Section 10 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 Enterprise profile requires Mission-bound issuance for the acting credential (Section 14); a Join Assertion strengthens every joined path outside those classes and remains required there under that profile. The mapping join of Section 10 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.¶

14.1. High-Consequence Binding

The two binding-establishment modes are mutually exclusive per action, as the runtime profile fixes ([I-D.draft-mcguinness-mission-runtime]), and a high-consequence path switches modes rather than layering them: the join algorithm of Section 10 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 a consistent authority_hash, and denies 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.¶

14.2. Estate Prerequisites

The profile's mandatory path runs through the deployment's unchanged Authorization Server, and it assumes capabilities there: configuration rather than code, but gating nonetheless. Before claiming the profile a deployment confirms its estate AS provides:¶

• Token introspection. [RFC7662] introspection reachable by the MAS, under credentials the deployment protects (Section 17.2); the MAS cannot mint a Join Assertion without it (Section 12.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 10), and the MAS MUST NOT mint an assertion for a token without a cnf key (Section 12.1).¶

• cnf in introspection. Introspection responses that report the token's cnf confirmation, since the assertion binds the key thumbprint that response reports.¶

An estate whose Authorization Server cannot provide these still joins under the mapping join at the conformance floor (Section 10, Section 16); it does not claim this profile. The digest pair of Section 12.1 further assumes an introspection surface that resolves a token by digest, which mainstream Authorization Servers do not provide; a deployment plans for the access_token form.¶

14.3. The Enterprise Mapping Contract

The dominant MAS risk is a coarse or drifting join: shared client_id values, many-to-one directory mappings, and workload identity that the join collapses (Section 17.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 issuance profile'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 12.2), so a mapping change is attributable in join evidence, not only detectable in documents.¶

14.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. This is what makes the MAS the estate's approved-task authority distribution point: it distributes bounded, audience-scoped authority derived from the Mission, not tokens. The view is served under the Mission Status operation's authentication and anti-oracle rules, carries the Mission's authority_hash as its consent anchor, and does not widen authority beyond the Authority Set.¶

15.1. Topology

A typical MAS deployment runs the MAS beside the existing identity provider and Authorization Server, changing neither:¶

• the MAS records Missions, runs approvals, operates the lifecycle, and signs Mission Status;¶

• a PEP at the enforcement boundary (an API gateway, a service-mesh sidecar, an MCP or tool gateway, a SaaS connector, a workflow orchestrator, or a legacy-API wrapper) presents the Mission reference and calls a PDP before each consequential action;¶

• the PDP runs the runtime profile's decision contract and its AuthZEN binding, drawing authority from the MAS-served Authority Set or a materialized policy view (Section 14.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 deployment configuration the estate makes explicit: 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 this profile's governance rather than inventing one.¶

15.2. Connector Patterns

The PEP is wherever consequential effects can be refused before they happen. Common placements, all non-normative:¶

• API gateway PEP: refuses at the gateway in front of a protected API.¶

• Service-mesh sidecar PEP: refuses at the sidecar for service-to-service calls.¶

• SaaS connector PEP: refuses in the connector mediating a SaaS API.¶

• MCP or tool-server PEP: refuses at the tool boundary an agent invokes.¶

• Workflow or orchestrator PEP: refuses at the step boundary of a governed workflow.¶

• Legacy-API wrapper PEP: refuses in a wrapper fronting a system that cannot itself enforce.¶

Each is credible only to the extent it has no unmediated bypass; the runtime profile's Enforcement Scope Statement is where that coverage is stated ([I-D.draft-mcguinness-mission-runtime]).¶

15.3. Progressive Adoption

A MAS is adopted level by level across the Mission Assurance Levels ([I-D.draft-mcguinness-mission-architecture]), each phase independently useful. 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 every mode; what changes is the claim, and a high-consequence enforcement claim requires issuance mode's machinery or the Estate Prerequisites' AS features (Section 14.2), never records alone:¶

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, without the level's issuance-gate kill switch; phase 2 supplies the state-based cutoff).¶

2. Mission Status and lifecycle become the estate-wide kill switch: consumers fail safe on non-active state (the state-aware half-step).¶

3. PEP/PDP runtime enforcement gates consequential actions per the runtime profile (the Runtime-Enforced level).¶

4. Join Assertions and instance-bound joins harden the join for the high-consequence classes (the Enterprise profile, Section 14).¶

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, and the MAS remains the enduring control plane of the family's delegated-authority layer ([I-D.draft-mcguinness-mission-architecture]) even as individual Authorization Servers become Mission-aware.¶

The common starting estate runs bots on standing service accounts with broad, durable entitlements. The 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, and that shrinking residue is the adoption metric.¶

17.1. Join Spoofing

A client cannot gain authority by asserting another party's mission_id: the join requires the subject and client the PEP authenticates from the credential 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. Three 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 14.3). 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 10), 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, 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.¶

• Bearer possession. With a pure bearer token, possession alone presents the credential, so any holder inside the (subject, client) equivalence class joins, which is why Section 10 requires sender-constraint for the high-consequence classes.¶

• Same-party self-selection. The propagation channel (Section 11) lets the requesting side name the Mission, so an agent whose subject and client join more than one active Mission chooses which one a request runs under: a confused-deputy shape (least-restrictive-Mission selection), not merely spoofing. The join bounds the choice to Missions whose parties match, each chosen Mission's own authority bounds what the choice yields, and who attaches the reference bounds it further: a trusted harness attaching from its recorded binding, or a Mission Join Assertion presented alongside, is the strong form, and the Enforcement Scope Statement records the attachment provenance.¶

The Mission Join Assertion (Section 12) 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.¶

17.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 or, for JWT access tokens, local RFC 9068 validation of the AS-issued token, 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.¶

17.3. Expansion and Child-Creation Binding

The native surfaces of Section 8 bind a request to its predecessor or parent by authenticated client identity, not by the token-exchange possession proof of the OAuth wire, 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 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:¶

• 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 8.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 8.1), so a request against a Mission the client is not bound to is indistinguishable from one against a Mission that does not exist.¶

17.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 13).¶

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

17.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 it 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 differ by blast radius. The introspection credential the MAS holds at the estate AS (Section 12.1) is secret material of the same tier: its compromise forges joins ([I-D.draft-mcguinness-mission-security-model]).¶

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

17.8. 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 5). The submission, status, and lifecycle endpoints reject unauthenticated callers and preserve the anti-oracle property ([I-D.draft-mcguinness-oauth-mission-status]).¶

19.1. HTTP Field Name Registration

This document registers 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 11.2¶

• Comments: none¶

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

• Status: permanent¶

• Related Information: none¶

19.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 Member Name following the metadata naming conventions of Section 9 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: Member Name, Change Controller, and Reference. The registry is seeded with the members of Section 9; 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¶

19.4. Media Type Registration

This document registers one media type per [RFC6838].¶

19.5. 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 10). 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.¶

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

[MCP-META]

Model Context Protocol Project, "Model Context Protocol: Base Protocol", 2025, <https://modelcontextprotocol.io/specification/2025-11-25/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>.

[RFC8615]

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

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

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

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

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

[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 4).¶

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.",
    "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 5). The client's next poll returns the Mission reference and its consented authority (Section 6).¶

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

{
  "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-runtime-evidence]). 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"
  }
}