Adding Squish to Identity Standards

I’m making a call right now: the agentic age will soon alter the meaning of the most enduring truth in IAM standards implementations today. This will be a Good Thing™️, I swear.

Adding Squish to Identity Standards
Behold, the dumbest object ever to have been put in this vice.

Current state: Static Set and Forget

When was the last time you or your vendor made a significant changes to a standing federated connection? Was it two years ago? Five? Ever? Other than the predictable betrayal of neglected certificates causing SSO outages every year or two, nothing tends to change about those federated connections, because most of us are not masochists, and because there are always bigger issues on the horizon. The attribute contract, the assertion envelope, the signing algorithms, the query parameters - however they were created, that is likely how they are today.

Now however we have two separate trains bearing down on us. The long-predicted steam engine is getting close: quantum computing. Mathematicians and cryptographers have successfully defined what a quantum safe algorithm is, but standards makers and IAM architects have a further concern - we need not only a set of quantum safe algorithms but the crypto-agility to change those algorithms as the world changes under us. The second train is the Shinkansen of change barreling towards us: the high-visibility wave of opportunity (with or without airquotes, your choice) that is Agentic AI. Whether you like it or hate it, we are looking at a revolution in infrastructure lifecycle automation. Agents are the ultimate chaotic neutral actor - if you give them an easy path to success they will take it. If you deny them that path, they will do their damndest to find a way to complete their mission anyway.

(also: we are today treating those two trains as if they will never meet, perhaps out of a necessary sense of self-preservation. Cue future hijinks.)

Brittle is on its Last Legs

The problem with static set & forget is that when something happens, you have to remember before you act. Issues smack us on the back of the head and we're suddenly scrambling - who actually does own the other end of that connection? Do they even still work for the company? How do we know if our connections have XML signature wrapping vulnerabilities? We uploaded a corrupt certificate by mistake, how do we contact every relying party that consumed from that JWKS url to tell them to manually try again? Wait, a federated relying party is assuming that an unverified email address in an assertion payload is a better unique identifier than the subject of the assertion - how do get our partners to implement their end of the deal?

People got through the above issues (for the most part) because the risk of instant weaponization was low enough that we could manually fix things with reasonable confidence. But manual won't cut it soon. Our direction is clear: every lifecycle of every entity in our federated flows will now be fully automated, and that includes flows that had no previous ROI for full automation. Once agents have a ubiquitious fully automated onboarding flow, we will run headlong into the greatest identity proliferation problem since we all (ok well some of us, not me) got excited during the crazy days of role mining.

From Static to Squishy

If you buy my argument that set/forget cannot continue, then what replaces it? My answer is identity standards that squish, and of course, since pedantry is in my blood, squish needs to be defined. A squishy standard may be be placed under stress in its default state but demonstrate resilience through adaptive configuration, much like that poor little stress ball I stuck into my basement vice. Luckily, the authors of OAuth and OpenID Connect have had plans for these things for ages. We as an industry need to finally lean into the mechanisms that standards authors have written into the specifications but that many implementations have not focused on. Certain things have always been negotiable, but they were never widely implemented in Enterprise for two reasons: a) because we had workarounds, but also b) because the entire ecosystem needs to be ready to squish together before the features do anything useful. That is really the sea change I'm talking about - not any one vendor making changes, or any one new adaptation but all of us as a whole developing the flexibility in the ecosystem to absorb change together in a reliable way. It will take us a bit of time to get the hang of the squish, but we'll get there.

Negotiable elements in identity standards take us from being brittle to having an important ability to intelligently squish around what is happening, keeping everything going as we mitigate new attacks and accommodate new use cases. Also, I hope it is clear that standards without squish will be an issue going forward.

Want to learn more? Stay tuned, we will go into all the lovely ways in which identity standards are designed for squish in the next few posts.