<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Identity Chaining on Control Plane by Karl McGuinness</title><link>https://notes.karlmcguinness.com/tags/identity-chaining/</link><description>Recent content in Identity Chaining 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>Sat, 06 Jun 2026 09:00:00 -0700</lastBuildDate><atom:link href="https://notes.karlmcguinness.com/tags/identity-chaining/index.xml" rel="self" type="application/rss+xml"/><item><title>Re-Subjecting Is a Mint, Not an Attenuation</title><link>https://notes.karlmcguinness.com/notes/re-subjecting-is-a-mint-not-an-attenuation/</link><pubDate>Sat, 06 Jun 2026 09:00:00 -0700</pubDate><author>public@karlmcguinness.com (Karl McGuinness)</author><guid>https://notes.karlmcguinness.com/notes/re-subjecting-is-a-mint-not-an-attenuation/</guid><description>Cross-App Access becomes structurally difficult when applications use different subject namespaces for the same user. Workload identity alone cannot supply the delegated user context, and offline attenuation cannot create a target-local identity binding that the artifact&amp;rsquo;s issuer never supplied. When a hop requires subject translation, an IdP or broker trusted for that mapping must mint new audience-scoped identity evidence. The destination Authorization Server still applies local policy and separately mints the access token. The open design question is how that mapping authority is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the same trust invariant.</description></item></channel></rss>