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 one claim — mission_s256 — to every token in the chain, without changing the signing or federation mechanics. In -11 a mission reaches a resource only inside a PS-issued token: the AAuth-Mission header and its IANA registration were both removed, so the mission is no longer something the agent asserts.

What missions add

Protocol element	Without	With Missions
mission_s256 named at the person token endpoint
mission_s256 claim in the person token
mission_s256 claim in the resource token (REQUIRED once the person token has one)
mission_s256 claim in the auth token
PS mission_endpoint for proposals, updates and completion
s256 verified against the decoded mission blob bytes
Mission log at the PS
Pre-approved tools and resources (optional)
Mission expiry caps every token's lifetime
Audit endpoint (requires a mission)
Person token before any resource token
HTTP Message Signatures
Resource token exchange
PS-AS federation (federated mode)
Proof-of-possession (cnf)
Permission and interaction endpoints

Token claim differences

Without Missions

Request Headers

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

Person Token (aa-person+jwt payload)

{
  "iss": "https://ps.example",
  "dwk": "aauth-person.json",
  "aud": "https://api.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "…",
      "alg": "Ed25519"
    }
  },
  "jti": "pt-32d653"
}

Resource Token (aa-resource+jwt payload)

{
  "iss": "https://api.example",
  "aud": "https://as.example",
  "ps": "https://ps.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "person_token_jti": "pt-32d653",
  "agent_jkt": "tcP75aIbpvVmzZ0P…",
  "scope": "read"
}

Auth Token (aa-auth+jwt payload)

{
  "iss": "https://as.example",
  "aud": "https://api.example",
  "ps": "https://ps.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "…",
      "alg": "Ed25519"
    }
  },
  "scope": "read"
}

With Missions

Request Headers

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

Mission Blob (from PS /mission approval)

{
  "approver": "https://ps.example",
  "agent": "aauth:[email protected]",
  "approved_at": "2026-04-14T17:14:54Z",
  "expires_at": "2026-05-14T17:14:54Z",
  "description": "# Analyze Q2 Customer Feedback …",
  "approved_tools": [
    {
      "name": "FeedbackReader",
      "description": "Read customer feedback records"
    },
    {
      "name": "ReportWriter",
      "description": "Write the summary report"
    }
  ],
  "approved_resources": [
    "https://api.example"
  ]
}

Person Token (aa-person+jwt payload)

{
  "iss": "https://ps.example",
  "dwk": "aauth-person.json",
  "aud": "https://api.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "…",
      "alg": "Ed25519"
    }
  },
  "mission_s256": "7SGTFsuKCcpYJwGRkVBi8vOc1Ssm7NdgnVaAruK87Rg",
  "jti": "pt-32d653"
}

Resource Token (aa-resource+jwt payload)

{
  "iss": "https://api.example",
  "aud": "https://as.example",
  "ps": "https://ps.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "person_token_jti": "pt-32d653",
  "agent_jkt": "tcP75aIbpvVmzZ0P…",
  "scope": "read",
  "mission_s256": "7SGTFsuKCcpYJwGRkVBi8vOc1Ssm7NdgnVaAruK87Rg"
}

Auth Token (aa-auth+jwt payload)

{
  "iss": "https://as.example",
  "aud": "https://api.example",
  "ps": "https://ps.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "cnf": {
    "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "…",
      "alg": "Ed25519"
    }
  },
  "scope": "read",
  "mission_s256": "7SGTFsuKCcpYJwGRkVBi8vOc1Ssm7NdgnVaAruK87Rg"
}

Mission Lifecycle

1.Agent fetches PS well-known metadata to find mission_endpoint and person_token_endpoint.
2.Agent POSTs a proposal: {"description": "# Task…", "tools": [...], "resources": ["https://api.example"]}.
3.PS cannot approve without the person — returns 202 + AAuth-Requirement with an interaction URL.
4.Person opens the interaction URL, reviews the description, tools and resources, and approves.
5.Agent polls the pending URL; PS returns 200 with {s256, mission, capabilities, person_tokens}.
6.Agent decodes `mission`, computes SHA-256 over the decoded bytes, and compares to `s256` (a SHOULD, not a requirement).
7.person_tokens carries one mission-scoped person token per approved resource — each already stamped with mission_s256.
8.Agent presents a person token at a resource; mission_s256 flows into the resource token and then the auth token.
9.Work changes: agent POSTs {action: 'update'} to {mission_endpoint}/{mission_s256}. The blob and mission_s256 are unchanged; the context the PS evaluates against is not.
10.Agent proposes completion: {action: 'completion', summary} at the same URL. The person accepts and the mission terminates, or asks follow-ups and it stays active.
11.After termination, any PS request naming this mission_s256 returns mission_terminated with an optional termination_reason.

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