The architecture chapter carries the argument, the Building Mission-Bound Authorization chapter carries the controls this appendix accompanies, and the Field Reference carries the definitions. This appendix carries the bytes: the running example, Alice’s Q3 board packet, as the protocol exhibits an implementer would actually see. Exhibits follow the draft family’s editor’s copies as of October 5, 2026, and the drafts are the normative text. Standard OAuth parameters that carry no Mission semantics are elided. Identifiers, keys, and digests are illustrative, with two exceptions: intent_hash and authority_hash reproduce byte for byte from the test vector, and the two parameter_digest values are real SHA-256 digests over the JCS form of the parameter objects the exhibits name.

1. The proposal: Mission Intent via PAR

The shaper turned Alice’s request into a candidate Mission Intent (From a Request to an Approved Mission), and the client submits it through a Pushed Authorization Request. The mission_intent parameter value is the UTF-8 JSON serialization of the Submission envelope, {intent, evidence}, form-encoded on the wire. No Intent Submission Evidence rides in this example. The envelope’s intent member, which intent_hash covers, decoded:

1
2
3
4
5
6
7
8
9

{
  "goal": "Prepare the Q3 board packet for the audit committee",
  "purpose": "urn:example:mission:board-packet",
  "target_resources": ["https://finance.example.com",
    "https://docs.example.com",
    "https://workflow.example.com"],
  "task_bounds": ["Q3 2026", "Example Corp", "confidential"],
  "expires_at": "2026-10-15T18:00:00Z"
}

target_resources is the requested ceiling on which resources the derived authority may name. task_bounds are human-readable strings for Alice to read at approval, with no machine semantics. The Intent’s top level is closed: the AS refuses any member that neither the OAuth binding nor a companion it implements defines, with invalid_request.

The client MAY propose concrete authority as standard authorization_details alongside mission_intent, an untrusted proposal committed by the conditional proposal_hash and only ever narrowed. Alice’s client proposes none. It proposes a task, and the Authorization Server derives the authority.

2. The pivot: the approved record

The Authorization Server validates the Intent, derives the Authority Set (query_financials, create_doc, notify_reviewer), renders the disclosure, and on Alice’s approval commits the Mission atomically. No authority was proposed, so the AS derives the set in configured-mapping mode: the mapping configured for the board-packet purpose binds the current reporting period (Q3 2026), the board-packet template, and the audit-committee group, within the Intent’s target_resources. The task_bounds are shown to Alice beside the result; the AS does not read them. The concrete record lives in the Reference. The two anchors it commits stay on the record: later exhibits identify the Mission by id and issuer alone, and an authorized introspection caller can receive authority_hash.

AnchorValue
intent_hashsha-256:yTr3AQ0Yz9H2e8QQE9IbLV96mlQ4tGZvpDfQrbkk-Gw
authority_hashsha-256:4hRwrGkW9Jdjbkj1oHJ3opg9HRvmRe30k7TQmUfiIpY

3. The projection: a Mission-bound token

The agent asks for authority to read the financials. Issuance is a derivation, gated on the Mission being active, and the response echoes the narrowed grant, the mission_id reference, and the Mission’s effective expiry as mission_expires_at, which expires_in does not report. The entries use the mission_resource_access type the Mission Resource Access Profile defines:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "DPoP",
  "expires_in": 300,
  "mission_id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
  "mission_expires_at": "2026-10-15T18:00:00Z",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } }
  ]
}

The decoded access-token claims carry the projection: a subset of the Authority Set, a sender-constraint key, and the mission claim that binds the credential back to the governance record. The claim identifies the Mission and carries neither anchor. The Resource Server enforces the carried authorization_details, and checking them against the complete approved set takes Mission Approved-Set Verification. The token’s exp is minutes away, and the Mission’s expires_at is weeks away. That asymmetry is the Durability law.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "iss": "https://as.example.com",
  "sub": "alice@example.com",
  "aud": "https://finance.example.com",
  "client_id": "s6BhdRkqt3",
  "iat": 1790787780,
  "exp": 1790788080,
  "jti": "at_3Vq8nK2xT6mR9sY1pZ4d",
  "authorization_details": [
    { "type": "mission_resource_access",
      "resource": "https://finance.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" } }
  ],
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "mission": {
    "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
    "issuer": "https://as.example.com"
  }
}

4. The gate: an AuthZEN permit, bound to parameters

By 18:05 the review draft is done, and the agent notifies the audit committee, with a final pass on the packet queued for overnight. The notify is externally visible, so the PEP at workflow.example.com asks the PDP before acting (Mission-Bound Runtime Enforcement, AuthZEN Profile). The audience rides in resource.properties, where the PDP matches it against the approved entry’s resource. The parameters, their digest, and the idempotency key a non-idempotent external commitment requires ride in action.properties. The Mission, its state observation, the actor, and the credential ride in context, the credential with the key confirmation the PEP verified, which the permit binds. This deployment places state establishment with the PEP, so the PEP supplies mission_state_observation, its state and freshness in one snapshot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

{
  "subject": {
    "type": "user",
    "id": "alice@example.com",
    "properties": { "iss": "https://login.example.com" }
  },
  "resource": {
    "type": "notification",
    "id": "notif_board_packet_q3",
    "properties": { "audience": "https://workflow.example.com" }
  },
  "action": {
    "name": "notify_reviewer",
    "properties": {
      "parameters": {
        "group": "audit-committee",
        "message": "Q3 board packet is ready for review"
      },
      "parameter_digest":
        "sha-256:DCTAlrBUhQwW_t1EDxHCjdNkLbrT_Bc6nCLYkQubRU4",
      "idempotency_key": "idk_4Tn8wQ2mR6vX1sK9pB3zL7"
    }
  },
  "context": {
    "mission": {
      "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
      "issuer": "https://as.example.com",
      "policy_version": "deploy-policy:v17",
      "policy_view_id":
        "sha-256:CMcisP1vVPsdDxWs336YmmKoBLFgMro1SYVJJEK4sV8"
    },
    "mission_state_observation": {
      "state": "active",
      "mode": "fresh",
      "freshness_at": "2026-09-30T18:05:00Z"
    },
    "actor": { "client_id": "s6BhdRkqt3" },
    "credential": {
      "issuer": "https://as.example.com",
      "expires_at": "2026-09-30T18:09:00Z",
      "confirmation": {
        "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
      }
    }
  }
}

The permit comes back bound to exactly those parameters, and limited to one use because deployment policy classes the notify as an external commitment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "decision": true,
  "context": {
    "evaluation_id": "dec_2FpQ8kV5nR1tX7mB4sJ9eL6wYc",
    "conditions": {
      "parameter_digest":
        "sha-256:DCTAlrBUhQwW_t1EDxHCjdNkLbrT_Bc6nCLYkQubRU4",
      "valid_until": "2026-09-30T18:06:00Z",
      "use_limit": 1
    }
  }
}

The response echoes no class label and no policy view. The PDP records the class it applied (external_commitment, assigned by deployment policy) and the view it evaluated in Decision Evidence, joined to this permit by evaluation_id. The executing PEP recomputes the digest against the parameters it is about to use, so a message changed after the permit mismatches the digest and the PEP refuses, which closes the TOCTOU gap.

5. The refusal: parameter_violation

Steered by a prompt-injected document, the agent tries the same notify (same message) against a different audience, the press-list group. The attempt is a new intended execution under a fresh idempotency_key, so the PDP evaluates its parameters rather than refusing a reused key. The Authority Set’s constraint names audit-committee, so the evaluation succeeds and the decision is no:

1
2
3
4
5
6
7
8

{
  "decision": false,
  "context": {
    "evaluation_id": "dec_6JwN3xT9rQ4mV8kP1sB5eZ2yLd",
    "reason": "parameter_violation",
    "next_action": "none"
  }
}

A denial is a successful evaluation, not a transport error. The response names the reason and marks the refusal terminal. The request carried the digest of the changed parameters, sha-256:_0sG_Vm6EFHvqL5MMNYp-iL1KXXW5CGMr3NLXcXbKrc, and Decision Evidence records it with the failing group constraint in contributing_constraints, joined by the same evaluation_id discipline as a permit.

6. The stop: revocation by mission_id

At 23:00 the board meeting is cancelled and an administrator ends the task at the lifecycle endpoint (Mission Lifecycle and Change). One authenticated call, keyed by the Mission, touching no token. The administrator’s console presents a DPoP-bound access token carrying the mission_lifecycle scope, audience-restricted to the lifecycle endpoint, with its DPoP proof:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

POST /as/mission/lifecycle HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

mission_id=msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p
&operation=revoke
&reason=Board+meeting+cancelled
&nonce=nonce_8Y3vN0sM6tP1xR9bQ5

7. The announcement: a lifecycle event

Subscribed consumers learn the transition through the Signals push, a Security Event Token whose strictly monotonic version makes replayed or reordered events harmless. Its required expires_at lets a consumer that only receives events fail safe on the Mission’s expiry without a Status fetch. The registered event type URI keys the events member, and mission.lifecycle-change, the name the prose uses, is the Signals profile’s short name for it. Decoded:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "iss": "https://as.example.com",
  "aud": "https://workflow.example.com",
  "jti": "set_5R8wQ2kN7mX4vT1pB6zJ3e",
  "iat": 1790809200,
  "sub_id": {
    "format": "opaque",
    "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p"
  },
  "events": {
    "https://schemas.karlmcguinness.com/mission/lifecycle-change": {
      "mission": {
        "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
        "issuer": "https://as.example.com"
      },
      "state": "revoked",
      "prior_state": "active",
      "version": 2,
      "committed_at": "2026-09-30T23:00:00Z",
      "expires_at": "2026-10-15T18:00:00Z",
      "reason": "Board meeting cancelled"
    }
  }
}

8. The check that stops the resume

At 02:00 the harness wakes to run the queued final pass and, before dispatching anything, establishes current Mission state (The Agent Runtime and Audit). It needs state, not audience-scoped authority, so it omits audience and the AS addresses the state-only response to the requester, the agent’s client s6BhdRkqt3. The response’s version, 2, is the state counter the lifecycle event carried. The signed Status response says the one thing no credential in the session can: the approved task no longer exists.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "iss": "https://as.example.com",
  "aud": "s6BhdRkqt3",
  "sub": "s6BhdRkqt3",
  "nonce": "nonce_K9pV4nT2sR7mB1xQ",
  "iat": 1790820005,
  "exp": 1790820065,
  "mission": {
    "id": "msn_Y89D4gqD9lDfw2cn6qqSO4C9j8o63Z2p",
    "issuer": "https://as.example.com",
    "state": "revoked",
    "version": 2,
    "expires_at": "2026-10-15T18:00:00Z",
    "fresh_until": "2026-10-01T02:01:05Z"
  }
}

The harness suppresses the resume and emits the evidence record the agent runtime part shows. Session continuity was recoverable. The authority was not, and the Mission, not the session, decided.

The signals beside the exhibits

The OAuth binding and three of its companions name signals for the paths these exhibits cross. None appears in the exhibits above, and a reader wiring this up should know they exist:

SignalWhere it ridesWhat it saysDefined by
mission_errorToken endpoint errorWhich gate refused the request, so a client can tell mission_revoked from mission_expired from mission_superseded, a resume-able mission_suspended from a terminal mission_completed, or that derivations are exhausted (derivations_exhausted)The OAuth binding (revoked, expired, superseded); Status and Lifecycle (suspended, completed); Derivation Limits (exhausted)
derivations_remainingIntrospection, to a caller granted that member’s disclosureThe derivations left under the Mission’s derivation_limitDerivation Limits
mission_denialWWW-AuthenticateWhether a resource denial is insufficient_authority (more needs a new approval or an Expansion) or constraint_unrecognized (the resource cannot enforce an applicable constraint, which no retry, step-up, or approval repairs)The OAuth binding
mission_constraints_supportedProtected-resource metadataWhich constraints keys, Common Constraints and deployment-defined names, the resource understands and enforcesResource Access Profile

A partial derivation needs no signal of its own: the granted authorization_details echoed in the token response (exhibit 3) state exactly what was granted. A weak or stale user authentication is not a Mission denial either; the Resource Server answers it with RFC 9470’s insufficient_user_authentication challenge. Exhibit 3 also shows two token-response members: the mission_id echo, a SHOULD, and mission_expires_at, which MUST appear on the first response that delivers a new Mission’s identifier. The mission claim can carry an OPTIONAL expires_at member, a bounding commitment with no liveness, so it never extends reliance and current state still comes from a freshness source.

Where each exhibit is normative

The OAuth binding owns exhibits 1 through 3 and the integrity anchors, and the Mission Resource Access Profile owns the mission_resource_access entries they carry. The runtime core and its AuthZEN Profile own 4 and 5, the runtime’s OAuth 2.0 Profile maps the validated access token onto the decision inputs, and Mission Runtime Evidence owns the Decision Evidence they cite. Status and Lifecycle owns 6 and 8, and Lifecycle Signals owns 7. Where an exhibit and a draft disagree, the draft wins, and the Field Reference is the citable summary of the whole model.