Missions

With vs Without Missions

Missions are an optional governance layer that works with any resource access mode that has a Person Server. They add mission context to every token in the chain — without changing the underlying signing or federation mechanics.

What missions add

Protocol element	Without	With Missions
AAuth-Mission header on requests
AAuth-Capabilities header
aauth-mission in signature components
mission claim in resource token
mission claim in auth token
PS /mission endpoint for proposals
s256 verification at each hop
Mission log at PS
Pre-approved tools (optional)
HTTP Message Signatures
Resource token exchange
PS-AS federation (federated mode)
Proof-of-possession (cnf)

Token claim differences

Without Missions

Request Headers

{
  "Signature-Key": "sig=jwt;jwt=\"eyJhbGc...agent-token...\"",
  "Signature-Input": "sig=(\"@method\" \"@authority\" \"@path\" \"signature-key\")",
  "Signature": "sig=:base64url…:"
}

Resource Token (aa-resource+jwt payload)

{
  "iss": "https://api.example",
  "aud": "https://as.example",
  "agent": "aauth:local@agent.example",
  "agent_jkt": "abc123…",
  "scope": "read"
}

Auth Token (aa-auth+jwt payload)

{
  "iss": "https://as.example",
  "aud": "https://api.example",
  "agent": "aauth:local@agent.example",
  "act": {
    "sub": "aauth:local@agent.example"
  },
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "..."
    }
  },
  "scope": "read"
}

With Missions

Request Headers

{
  "Signature-Key": "sig=jwt;jwt=\"eyJhbGc...agent-token...\"",
  "AAuth-Mission": "approver=\"https://ps.example\"; s256=\"sha256ofmission…\"",
  "AAuth-Capabilities": "interaction, clarification",
  "Signature-Input": "sig=(\"@method\" \"@authority\" \"@path\" \"signature-key\" \"aauth-mission\")",
  "Signature": "sig=:base64url…:"
}

Mission Blob (from PS /mission approval)

{
  "approver": "https://ps.example",
  "agent": "aauth:local@agent.example",
  "approved_at": "2026-04-14T17:14:54Z",
  "description": "# Task …",
  "approved_tools": [
    {
      "name": "FeedbackReader",
      "description": "Read customer feedback records"
    },
    {
      "name": "ReportWriter",
      "description": "Write the summary report"
    }
  ],
  "capabilities": [
    "interaction",
    "clarification"
  ]
}

Resource Token (aa-resource+jwt payload)

{
  "iss": "https://api.example",
  "aud": "https://as.example",
  "agent": "aauth:local@agent.example",
  "agent_jkt": "abc123…",
  "scope": "read",
  "mission": {
    "approver": "https://ps.example",
    "s256": "sha256ofmission…"
  }
}

Auth Token (aa-auth+jwt payload)

{
  "iss": "https://as.example",
  "aud": "https://api.example",
  "agent": "aauth:local@agent.example",
  "act": {
    "sub": "aauth:local@agent.example"
  },
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "..."
    }
  },
  "scope": "read",
  "mission": {
    "approver": "https://ps.example",
    "s256": "sha256ofmission…"
  }
}

Mission Lifecycle (Before Authorization)

1.Agent fetches PS well-known metadata to find mission_endpoint.
2.Agent POSTs mission proposal: {"description": "# Task...", "tools": [...]}.
3.PS cannot approve without the user — returns 202 + AAuth-Requirement with interaction URL.
4.User opens the interaction URL, reviews the description and tools, and approves.
5.Agent polls the pending URL; PS returns 200 with the approved mission blob (approver, agent, approved_at, description, approved_tools, capabilities).
6.AAuth-Mission: approver="..."; s256="sha256..." header is set on the 200 response.
7.Agent verifies SHA-256(response_body_bytes) == s256 from the header and stores the bytes as received.
8.Agent includes AAuth-Mission on all subsequent requests; when the mission terminates, the PS returns mission_terminated for any mission-bound request.

Mission Proposal Demo End-to-End Lifecycle Mission Completion Permission Endpoint Audit Endpoint