<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Control Plane by Karl McGuinness</title><link>https://notes.karlmcguinness.com/</link><description>Recent content on Control Plane by Karl McGuinness</description><generator>Hugo</generator><language>en-us</language><managingEditor>public@karlmcguinness.com (Karl McGuinness)</managingEditor><webMaster>public@karlmcguinness.com (Karl McGuinness)</webMaster><lastBuildDate>Sun, 19 Apr 2026 20:05:00 -0700</lastBuildDate><atom:link href="https://notes.karlmcguinness.com/index.xml" rel="self" type="application/rss+xml"/><item><title>Enterprise SaaS Needs OAuth Federation Now</title><link>https://notes.karlmcguinness.com/notes/enterprise-saas-needs-oauth-federation-now/</link><pubDate>Sun, 19 Apr 2026 20:05:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/enterprise-saas-needs-oauth-federation-now/</guid><description>Enterprise SaaS still defaults to app-by-app OAuth islands with their own clients, long-lived artifacts, and revocation paths. The architectural shift is OAuth federation: adopt issuer-mediated federation now for services and workloads, and adopt Cross-App Access (XAA) as the standards direction for user-delegated cross-app access.</description></item><item><title>AAuth Now Has a Mission Layer</title><link>https://notes.karlmcguinness.com/notes/aauth-now-has-a-mission-layer/</link><pubDate>Mon, 13 Apr 2026 11:21:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/aauth-now-has-a-mission-layer/</guid><description>The new version of AAuth (draft-hardt-aauth-protocol-01) materially changes the earlier comparison. Mission is now first-class in the protocol, with PS-mediated approval, mission-aware token choreography, and governance endpoints. The remaining gap is no longer whether Mission exists, but whether the published model is strong enough to support portable containment rather than just mission correlation and governance hooks.</description></item><item><title>Implementing Mission Architecture End to End</title><link>https://notes.karlmcguinness.com/notes/implementing-mission-architecture-end-to-end/</link><pubDate>Sat, 11 Apr 2026 10:30:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/implementing-mission-architecture-end-to-end/</guid><description>The full implementation spec for Mission architecture: how to compile a bounded authority record from user intent, project it into Cedar policies and audience-specific OAuth tokens, enforce it at the host and MCP tool boundary, gate irreversible actions at the commit boundary, and keep the governance model operational through template ownership, revocation SLAs, audit integrity tiers, and an operator console built around decisions not raw artifacts. Includes V1 product contract, sequenced build plan, configuration management, and a complete test appendix.</description></item><item><title>ID-JAG Beyond the Enterprise IdP</title><link>https://notes.karlmcguinness.com/notes/id-jag-beyond-the-enterprise-idp/</link><pubDate>Sun, 05 Apr 2026 12:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/id-jag-beyond-the-enterprise-idp/</guid><description>ID-JAG, also often called Cross-App Access (XAA), is centered in the current draft on Enterprise IdP trust, but the issuer that matters is the immediate IdP the downstream authorization server already trusts for SSO and subject resolution, not necessarily the top-level workforce IdP. The same trust pattern can also extend architecturally to CIAM and platform identity layers that federate upstream workforce login while remaining authoritative for downstream product trust, tenant context, and subject resolution.</description></item><item><title>AgentPass and the Missing Mission Layer</title><link>https://notes.karlmcguinness.com/notes/agentpass-and-the-missing-mission-layer/</link><pubDate>Tue, 24 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/agentpass-and-the-missing-mission-layer/</guid><description>AgentPass introduces an Authority as a separate governance entity that approves and scopes agent access before credentials are issued. The architecture converges with Mission-Bound OAuth in important ways. But the Task description problem, the scope compilation gap, and the thin lifecycle model are precisely where the Mission and Mission Shaping work picks up.</description></item><item><title>Where Mission Lives in the IAM Stack</title><link>https://notes.karlmcguinness.com/notes/where-mission-lives-in-the-iam-stack/</link><pubDate>Mon, 23 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/where-mission-lives-in-the-iam-stack/</guid><description>Mission has to live somewhere as a durable authority record. This post places Mission in the IAM stack as a system of record for delegated authority, distinct from tokens, PDP decisions, the commit boundary, and orchestrator state.</description></item><item><title>Open-World OAuth Still Needs Mission Shaping</title><link>https://notes.karlmcguinness.com/notes/open-world-oauth-still-needs-mission-shaping/</link><pubDate>Sat, 21 Mar 2026 10:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/open-world-oauth-still-needs-mission-shaping/</guid><description>Open-world OAuth can improve discovery, resource binding, and first-contact trust. That still leaves the harder agent problem: how approved intent becomes bounded authority that stays governed across delegation chains, unfamiliar tools, consent expansion, revocation, and task termination.</description></item><item><title>OAuth for Open-World Ecosystems</title><link>https://notes.karlmcguinness.com/notes/oauth-for-open-world-ecosystems/</link><pubDate>Fri, 20 Mar 2026 10:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/oauth-for-open-world-ecosystems/</guid><description>OAuth was built for closed worlds, and that constraint is why it became mature. Agents expose the limits of that deployment model. This post traces what the newer OAuth standards get right and which substrate gaps still need to close.</description></item><item><title>Standardize `act` Across Assertion Grants and JWT Access Tokens</title><link>https://notes.karlmcguinness.com/notes/standardize-act-across-assertion-grants-and-jwt-access-tokens/</link><pubDate>Wed, 18 Mar 2026 10:30:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/standardize-act-across-assertion-grants-and-jwt-access-tokens/</guid><description>The current split between token exchange semantics and JWT access token practice creates avoidable interoperability failures. A common profile for &lt;code&gt;act&lt;/code&gt;, grounded in entity profiles, can align JWT assertion grant and JWT access token processing.</description></item><item><title>Mission Shaping Is Not Enough</title><link>https://notes.karlmcguinness.com/notes/mission-shaping-is-not-enough/</link><pubDate>Wed, 18 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-shaping-is-not-enough/</guid><description>Part 2 turns from the semantic problem to the runtime one. Quiet expansion, delegation, headless execution, stale state, and open-world execution all push Mission shaping past its strongest domain. Containment and runtime governance carry more of the safety burden.</description></item><item><title>The Mission Shaping Problem</title><link>https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/</link><pubDate>Tue, 17 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/the-mission-shaping-problem/</guid><description>This essay picks up from Part 4 of the Mission-Bound OAuth series and focuses on the first hard problem: how approved intent becomes a governable Mission. In structured domains that can look like staged Mission shaping or compilation. Many current deployments still do not do it at all.</description></item><item><title>Why Mission-Bound OAuth Might Be the Wrong Answer</title><link>https://notes.karlmcguinness.com/notes/why-mission-bound-oauth-might-be-the-wrong-answer/</link><pubDate>Sun, 15 Mar 2026 12:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/why-mission-bound-oauth-might-be-the-wrong-answer/</guid><description>Mission-Bound OAuth is a serious attempt to govern delegated agent authority using existing OAuth infrastructure. This post takes the pessimistic view: it may be the wrong answer because it asks the authorization server to become a governance engine, a lifecycle controller, and a mission ledger all at once. A cleaner alternative is to treat Mission as a separate authority service and let OAuth be one projection of that model rather than its home.</description></item><item><title>Mission Architecture on AAuth</title><link>https://notes.karlmcguinness.com/notes/mission-architecture-on-aauth/</link><pubDate>Sun, 15 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-architecture-on-aauth/</guid><description>Mission-Bound OAuth argues for a durable Mission object that governs delegated authority across approval, lifecycle, delegation, and termination. This follow-up asks whether Dick Hardt&amp;rsquo;s AAuth draft is a better protocol substrate for the same model, and where AAuth still appears to need an explicit Mission-like authority object.</description></item><item><title>Client Context and ID-JAG for Mission-Bound OAuth</title><link>https://notes.karlmcguinness.com/notes/client-context-and-id-jag-for-mission-bound-oauth/</link><pubDate>Sat, 14 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/client-context-and-id-jag-for-mission-bound-oauth/</guid><description>Rich Authorization Requests are the natural first instinct for agent missions, but audience-bound access tokens and uneven cross-domain interoperability limit how far they can carry a governed task. Mission-Bound OAuth solves that by making the Mission a durable authority object at the authorization server. This post explores the authentication-layer companion profile: OpenID Connect Client Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.</description></item><item><title>Mission-Bound OAuth</title><link>https://notes.karlmcguinness.com/notes/mission-bound-oauth/</link><pubDate>Fri, 13 Mar 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/mission-bound-oauth/</guid><description>OAuth answers whether a request is permitted right now. Mission-Bound OAuth asks whether a delegated mission should still be running at all. This RFC proposes a durable Mission object at the Authorization Server that governs token derivation, lifecycle, delegation, and termination across agent execution.</description></item><item><title>Agents Don't Need Your Passport. They Need Your Authority.</title><link>https://notes.karlmcguinness.com/notes/agents-dont-need-your-passport-they-need-your-authority/</link><pubDate>Sat, 21 Feb 2026 22:59:09 -0800</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/agents-dont-need-your-passport-they-need-your-authority/</guid><description>Enterprise IAM was designed for human-paced execution. Agents remove the presence, pacing, and natural scope-limiting that made those controls work. The result is a structural gap that stronger credentials, tighter scopes, and faster JIT provisioning cannot close.</description></item><item><title>From Passports to Power of Attorney</title><link>https://notes.karlmcguinness.com/notes/from-passports-to-power-of-attorney/</link><pubDate>Sat, 21 Feb 2026 22:59:09 -0800</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/from-passports-to-power-of-attorney/</guid><description>Tokens, credentials, and scopes tell a system what an agent may do. They say nothing about why execution was authorized or when it should end. The Execution Mandate is the primitive that closes that gap: a signed, inspectable authority record that runtime systems can evaluate and revoke throughout the execution lifecycle.</description></item><item><title>Governing the Stay, Not Just the Entry</title><link>https://notes.karlmcguinness.com/notes/governing-the-stay-not-just-the-entry/</link><pubDate>Sat, 21 Feb 2026 22:59:09 -0800</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/governing-the-stay-not-just-the-entry/</guid><description>An Execution Mandate defines what delegated authority looks like. This post builds the control plane that makes it operational: how mandates are issued and held as authoritative artifacts, how authority is evaluated continuously rather than at gates, how governance crosses organizational boundaries, and where enforcement lands in practice.</description></item><item><title>About</title><link>https://notes.karlmcguinness.com/about/</link><pubDate>Sat, 21 Feb 2026 00:00:00 +0000</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/about/</guid><description>&lt;div class="profile-card"&gt;
 &lt;img src="https://notes.karlmcguinness.com/images/me.jpg" alt="Karl McGuinness" class="profile-card__photo" width="120" height="120" /&gt;
 &lt;div class="profile-card__body"&gt;
 &lt;p class="profile-card__name"&gt;Karl McGuinness&lt;/p&gt;
 
 &lt;dl class="profile-card__facts"&gt;
 
 &lt;div class="profile-card__fact"&gt;
 &lt;dt&gt;Previously&lt;/dt&gt;
 &lt;dd&gt;SVP &amp;amp; Chief Product Architect @ Okta&lt;/dd&gt;
 &lt;/div&gt;
 
 &lt;div class="profile-card__fact"&gt;
 &lt;dt&gt;Standards&lt;/dt&gt;
 &lt;dd&gt;IETF OAuth WG · OpenID Foundation&lt;/dd&gt;
 &lt;/div&gt;
 
 &lt;div class="profile-card__fact"&gt;
 &lt;dt&gt;Focus&lt;/dt&gt;
 &lt;dd&gt;Identity strategy, product architecture, agent-native world&lt;/dd&gt;
 &lt;/div&gt;
 
 &lt;div class="profile-card__fact"&gt;
 &lt;dt&gt;Currently&lt;/dt&gt;
 &lt;dd&gt;Advising identity startups&lt;/dd&gt;
 &lt;/div&gt;
 
 &lt;/dl&gt;
 
 &lt;/div&gt;
&lt;/div&gt;

&lt;p&gt;I&amp;rsquo;m &lt;a href="https://karlmcguinness.com"&gt;Karl McGuinness&lt;/a&gt;, a product and technology leader with 25+ years of experience building mission-critical, internet-scale identity and infrastructure platforms. At Okta, I spent over a decade helping modern enterprises and the broader industry treat identity as foundational infrastructure.&lt;/p&gt;
&lt;p&gt;I specialize in product architecture, the intersection of product strategy and system design. I translate ambiguous requirements into durable product structures: domain boundaries, APIs, platform extensibility, and investment sequencing that keep teams fast today and options open later.&lt;/p&gt;</description></item><item><title>Welcome to Control Plane</title><link>https://notes.karlmcguinness.com/notes/welcome-to-control-plane/</link><pubDate>Mon, 28 Apr 2025 23:22:40 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/welcome-to-control-plane/</guid><description>&lt;p&gt;Identity is getting weird again, and in a good way.&lt;/p&gt;
&lt;p&gt;This blog is where I post hot takes, field notes, and analysis on identity, security, and agentic systems. Some posts will be tactical. Some will be opinionated. Some will be me zooming out and asking, &amp;ldquo;are we solving the right problem at all?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;Lately I keep coming back to one thing: most of our stack is great at deciding who can get in, and still pretty weak at governing what autonomous systems should keep doing over time.&lt;/p&gt;</description></item></channel></rss>