https://notes.karlmcguinness.com/series/mission-bound-authorization/Recent content in Mission-Bound Authorization on Control Plane by Karl McGuinnessHugoen-uspublic@karlmcguinness.com (Karl McGuinness)public@karlmcguinness.com (Karl McGuinness)Sat, 06 Jun 2026 17:00:00 -0700https://notes.karlmcguinness.com/notes/mission-bound-authorization-conformance/Sat, 06 Jun 2026 17:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-bound-authorization-conformance/Conformance to Mission-Bound Authorization is described along three complementary axes: the six-level Conformance Ladder, the four-tier Resource Server scale, and the three-tier Compliance scale. This post defines valid combinations and shows what each level looks like on OAuth-only, AAuth-only, and cross-substrate deployments.https://notes.karlmcguinness.com/notes/least-privilege-mcp-tool-calls/Sat, 06 Jun 2026 16:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/least-privilege-mcp-tool-calls/Least-privilege MCP has two natural authorization paths: token-side FGA with PRM, RAR, and RAR-type metadata, or resource-side FGA with the MCP server as PEP and AuthZEN as PDP. The token-side path gives the client portable authority but requires the issuing AS to understand or obtain resource-domain semantics. The resource-side path keeps domain knowledge at the MCP server but fragments approvals and audit across PDPs. Both need a durable task object. A Mission supplies that shared governance context while each Resource Server retains its own policy.https://notes.karlmcguinness.com/notes/mission-bound-runtime-enforcement-profile/Sat, 06 Jun 2026 15:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-bound-runtime-enforcement-profile/Mission governance bounds credential issuance and derivation. This profile carries those bounds to the execution boundary. OAuth and AAuth adapters construct one Mission-aware AuthZEN request; the PDP evaluates each consequential action against current policy and records the decision. Optional modules add Tool Binding, Decision Receipt, Purpose Registry, Actor Provenance, Attestation, and Policy Projection.https://notes.karlmcguinness.com/notes/mission-authority-server-profile/Sat, 06 Jun 2026 14:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-authority-server-profile/The default OAuth topology places the Mission record at the Authorization Server. This profile defines a dedicated Mission Authority Server as the state authority. OAuth ASes and AAuth Person Servers become authorized projection issuers. The MAS binds the subject, consent disclosure, canonical Authority Set, lifecycle, and pairwise Mission identifiers. Credential issuers remain responsible for credential validity; the MAS supplies Mission Status.https://notes.karlmcguinness.com/notes/mission-bound-aauth/Sat, 06 Jun 2026 13:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-bound-aauth/AAuth already has a native Mission: a Person Server approves an immutable mission blob, returns its approver and hash through AAuth-Mission, and evaluates later requests in that context. This profile defines only the composition delta: mapping the native reference to a governance Mission, committing typed authority, projecting richer lifecycle state, exposing Mission Status, and optionally sharing one Mission Authority Server with OAuth.https://notes.karlmcguinness.com/notes/mission-bound-oauth-profile/Sat, 06 Jun 2026 12:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-bound-oauth-profile/OAuth expresses authority but not the durable task that authority serves. This profile adds Mission Intent, an Approved Mission record, integrity anchors, Mission-bound tokens, lifecycle-gated derivation, and cross-AS projection. Runtime per-action enforcement remains in the companion Runtime Enforcement Profile.https://notes.karlmcguinness.com/notes/mission-shaper-profile/Sat, 06 Jun 2026 11:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/mission-shaper-profile/The Mission Shaper sits between user input and Mission Intent. It interprets a request against a versioned discovery snapshot, surfaces material ambiguity instead of guessing, and emits a traceable proposal. Its output remains untrusted until the validating server admits it and derives authority.https://notes.karlmcguinness.com/notes/the-mission-is-the-missing-abstraction/Sat, 06 Jun 2026 10:00:00 -0700public@karlmcguinness.com (Karl McGuinness)https://notes.karlmcguinness.com/notes/the-mission-is-the-missing-abstraction/OAuth governs credentials and delegation, but not the durable task those credentials serve. This series makes that task explicit as a Mission, then defines how intent becomes approved authority, how OAuth and AAuth project it, how runtime systems enforce it, and how deployments claim conformance.