I was on a panel at the recent OpenID Foundation workshop with the chairs of the enterprise specs, working through how they actually fit together as a stack. The 4 of us:

• Atul Tulshibagwale, CrowdStrike (after the SGNL acquisition in January), co-chair of Shared Signals and co-chair of AuthZEN alongside me.
• Mike Kiser, SailPoint, co-chair of Shared Signals.
• Dick Hardt, Hellō, co-chair of IPSIE.
• Me, Cerbos, co-chair of AuthZEN.

A few threads worth pulling on:

The specs are useful precisely because they're loosely linked. Shared Signals keeps the data fresh. AuthZEN turns it into a real-time decision. SCIM Events handles lifecycle. IPSIE is the meta-layer telling an enterprise what "good" looks like across the lot. Atul's framing on AuthZEN-meets-Shared-Signals captured the runtime piece well: when somebody hits your resource you have a few milliseconds to say yes or no, and if the data behind that decision is stale, the whole thing's pointless. Shared Signals is what gets the right state to the PDP before the question gets asked. He and Omri Gazitt wrote that up properly here about a year ago, and it still holds.

The big gap is reference architectures. This was the most practical thread of the panel. Spec docs describe a single protocol in detail. The joins between specs are where every enterprise gets stuck, and those mostly live in tribal knowledge today. Mike and I half-volunteered on stage to put together a docker compose up reference stack with an IDP, a PDP, a transmitter, a receiver, a SCIM endpoint and an IPSIE-shaped wiring of it all. If anyone wants to collaborate on that, find me.

The AI thread is where the panel actually disagreed. Dick's position is that the existing OAuth and OIDC primitives are too constrained for a world of agents that pick services to talk to at runtime, and that we need to rethink some fundamentals. Atul's is that enterprises evolve their stack incrementally, and any new agent-shaped primitives have to build on what's already there. George Fletcher made the more provocative version of the argument from the audience: standards historically existed to spare developers from writing 1000 integrations by hand, and AI just made 1000 integrations cheap, so the underlying ROI case for standards may be eroding. Justin Richer landed a useful frame: successful standards follow implementations, they rarely lead them. Eve Maler pointed at the JSON-SAML to OIDC to Verifiable Credentials path as evidence that the existing layers are stickier than people designing the next thing tend to assume. My own take sits in the middle. AI sharpens the case for standards, because every API call an agent makes is going to look slightly different, and the only way to manage, secure and audit the resulting mess is a uniform shape underneath. The bit we don't have yet is a common vocabulary for what "subject" means when the subject is an agent acting on behalf of a user inside another agent's session, possibly using delegated credentials. Right now every team I'm talking to is solving that differently, and the longer that goes on the harder the cleanup gets.

Standards as paved paths. Mike's closing point is the one I keep stealing. He took a new fintech job 6 months ago and is currently watching AI tools generate increasingly inventive ways to break things he thought were settled patterns. The role of OIDF, IETF and the rest of the bodies in this space is going to shift towards giving enterprises a default safe route through this. Generative tools will absolutely produce 1000 unique implementations on demand. The standards are what make any of those 1000 implementations possible to operate.

If you want the full thing, jump to 3h42 in the recording.

I'm doing a similar panel at European Identity & Cloud (EIC) in May, where Cerbos is sponsoring and I'm speaking. Come find me if you want to keep arguing about agents.