Karl McGuinness Agents tend to need multiple tools. The tools tend to be provided by multiple providers. They're not all one administrative boundary, one organizational boundary.

Allie Howe In security, we don't always see security advancements also be a win for the user too, which I think is really special about ID-JAG It's super high friction for users to be doing OAuth consent— Yeah, Every single, every single app. And now with ID-JAG, it's just authorized once via your IDP, and they've got access to everything. This also helps your security team be able to have a central place to enforce consistent policy and also solve that OAuth island problem you were talking about

Karl McGuinness I think what's exciting right now with the MCP announcement and the cloud announcement is ID-JAG goes from, Hey, OAuth islands we know. We now have a plan to solve it. We now have a spec that's been moving along. We now have a product that demonstrates end-to-end. And we have an ecosystem of key players that sort of demonstrate the value curve, and It's ready to go for you to join the fun. The last week has been a set of excitement for folks.

Allie Howe Welcome to today's episode of the Insecure Asians Podcast. I'm your host, Allie Howe, and today I'm super excited to have Carl Mclnnes with us on the podcast. Carl was the chief product architect at Okta, and he spent 25 years building identity platforms. I'm super excited to have him and his expertise on the podcast today, where we're gonna touch on OAuth Islands, Enterprise Managed Auth for Claude, Cross-App Access, and ID-JAG, which is something that Carl helped author. Carl, would you like to introduce yourself?

Karl McGuinness Thanks, Ali. Excited to be here. Some major announcements coming out last week. Lots of momentum. I'm excited to be here, and let's get into it

Allie Howe Amazing. Yeah, super cool. Last time we had actually tried to do this episode before we touched on OAuth islands, and then this immediately came out, so we were super excited to cover the enterprise managed auth announcement. But to help us frame that better, what is the OAuth island problem that you were talking about previously, and what is the need for OAuth federation that you were mentioning?

Karl McGuinness Yeah, great intro. So we've had this, you know, deployment model for, for quite some time now, where every application gets to a point where it starts needing to provide, you know, ecosystem level of connections and allowing, you know, multiple connections to act on behalf of their users. And so they start implementing an OAuth stack. And when they implement an OAuth stack, they effectively implement their own control plane governance layer, token layer, credential layer to mint and authorize access to which apps connect on behalf of which users what are the credentials to authorize those applications, what are the scopes that you can delegate. And that becomes a, a, an authorization layer that has to be managed within the application.

And all of this happens sort of post, authentication. So if you think about this from a, a user flow perspective is you've centralized authentication and access management for the end user at your IDP. But when the user signs into the application the application then grants its own access through OAuth. And so the term I was just u-calling as an OAuth island is just from the enterprise perspective is that the credentials and, and, a, a life cycle and policy is sort of managed within the app. And you times that by every single application and every single cross-app, you know, or client connection that, that needs to happen inside your enterprise.

And so this created a significant risk for the enterprise because now they have to think about all these credentials, grants, refresh tokens, long-lived access that's just sort of sitting out there that doesn't go back through a central control plane such as the IDP or some other visibility point. And it's been responsible for a lot of the security breaches in, in sort of the last sort of four or five years. Most recently the, the Vercel was where what, what prompted this, which is attackers, you know, can get a hold of those long-lived access credentials and then do lateral attack from there. And all that happens sort of post-authentication where-- from the end user where the enterprise doesn't see that.

And so that challenge has been there for a while. It's just, you know, attackers have sort of moved to where the, the easy wins are, and sort of lateral attack with long-lived static credentials with refresh tokens becomes the next sort of battle that folks are, are kind of, kind of, kind of fighting. And so OAuth islands and the need for federation really is, "Hey, we've had a successful pattern about this before with passwords and, and user credentials," which is You know, we've long recognized that creating local accounts with local passwords that all have their own lifecycle governance and policies and procedures at the app level creates a credential nightmare for the organization.

So we've federated the app with the enterprise through an identity provider, where the identity provider can centralize credential enrollment recovery, all the policies, assurance and have central sort of revocation and then issue an assertion to the application that the app trusts at runtime and then it moves on and, and can, can log the user in without having to directly be responsible for authenticating users directly inside the app. So that's like a direct versus federated kind of, kind of pattern. So we've had that pattern for a long time widely deployed. This was sort of the, the The backbone of cloud identity and cloud adoption in sort of the last SaaS wave was you could no longer rely on sort of centralizing that through like an LDAP or a, a server on-prem that you had to federate in order to move the apps outside the data center and into the, into the cloud.

And so then with the rout rise of cloud service providers and public cloud we started seeing similar problems with service accounts, right? So we had this idea of, you know, where are we managing the credentials? How do we vault the credentials? How do you start managing that deploying, you know, containers and things at runtime where the scale of, of the, the problem was like, it's not just this one machine that I can predetermine, issue a credential, vault it and then use it for, you know, a service account type, type deployment model and put, you know, privileged account management products around it. We needed to sort of start thinking about, hey, we've-- we're gonna start scaling our, our workloads to be dynamically spun up in these cloud environments where we want to issue them runtime credentials and runtime identity, and then use that to dynamically access, you know, cloud resources.

You know, if my S3 buckets or, or even my application layers, I need to sort of federate my resource layer into my identity layer and not rely on statically provisioned credentials for all these use cases, right? So we call that workload identity federation. It's became sort of in the last sort of five to 10 years, the sort of gold standard for how we think about that from our cloud infrastructure perspective. But we're starting to see this gap where we've recognized it for end user authentication with SSO, we deployed it. We recognized this pattern for sort of our, our workloads and service accounts and started to kind of deploy that.

And the last sort of battle was, okay, well, how do we do this on behalf of in a federated kind of way? And that sort of was the, the exploits that you're starting to see with like Vercel and everything is these are all on, on, on behalf of scenarios. And so we kinda needed to complete the, the journey, the trifecta of like we do it for users, we do it for workloads, and now we need to do it for on behalf of. And once we sort of do that, we can move a lot of this back to sort of a, a federation trust boundary that opens up a lot of new possibilities.

Allie Howe That makes sense. And yes, there were two, like, really big announcements recently, like you were saying in the beginning, the enterprise managed auth, but also the cross-app access announcement from Okta. And it looks like that's a huge part of that as well, the on behalf of the cross-app access. I mean, being able to help different tools the agent may be talking to, be able to take that authorization from one tool and be able to therefore use it with another tool that that agent's already using versus having to have that OAuth token for every single resource that that agent may be accessing. How does cross-app access and ID-JAG specifically help solve this problem?

Karl McGuinness Going from sort of the OAuth layer out to the product layer. So, from the OAuth perspective, right you have a client that needs to get access to a, a protected resource. It contacts an authorization server and says, "I need a token on behalf of the user to access this particular protected resource." And so that was sort of the OAuth island is sort of the authorization server is the implementation of, of sort of a traditional OAuth island is because everything i- is... Every sort of resource provider has its own authorization server. There's not, like, one authorization server for every single resource provider. A lot of sort of architectural and, and, and re-re- you know, realistic problem statements there where each vendor wants to control its own sort of authorization model and have its own control.

So it's gonna have a need to sort of have some element of control of its own authorization server for its own resource graph. And so when we move to tools, tools and MCP sort of rode on top of the OAuth model as a fast route to market, right? And so instead of sort of reinventing a complete AuthN, AuthZ stack to get this deployed, it rode on top of sort of existing identity infrastructure that was already deployed, which was looking around at the market, it was like, okay, well, we have OAuth. It's already sort of generally approved inside the enterprise. So if we expose our MCP server as a protected resource, we adopt some of the more modern aspects of OAuth to make it a little more dynamic, a little more friendly we can allow an MCP client to then get an OAuth token on behalf of a user to contact a MCP server and get that centralized at the I at the OAuth server level at least instead of having to invent a-an-another layer for that.

So that kinda was like the first rev of the problem. But when you play that out, agents tend to need multiple tools. The tools tend to be provided by multiple providers. They're not all one administrative boundary, one organizational boundary. And so you're in an o- more open world kinda deployment model where an agent needs access to N number of tools. Those tools can be provided by N number of providers. Those providers have N number of authorization servers. And I may even need to expose my own tools that wrap other tools and so we have a lot of sort of proxies and gateways that are sort of providing MCP capabilities as well in these flows.

And so what the-- Or from two perspectives, end user and organization. From the end user's perspective, right I want to pro... You know, issue a prompt. I wanna connect, to, you know, my, my graph of tools and, and services that I'm already using. So if I'm using like, you know, Calendar for this, I'm using this for my file storage, I'm using this for my tickets, I'm using this for source control, I wanna bring my sort of tools to my, to my agent, right? And so there's a connection process there that has to first happen in order for the tool to be used by, the agent, which is what you see today with an OAuth flow, right?

So I have to go do the sort of traditional OAuth dance, do a consent flow interactively in the browser, authorize the agent to, act on behalf. and there's a bunch of pre-registration there as well that has to happen, right? So how do the individual OAuth servers know about the agent? There's client credentials and deployment steps there in order to do that. And so you see, for example, for some of these tools, you eventually, punt to a developer guide of go create an OAuth client, copy-paste an OAuth client secret to your config file, and you're trying to manage OAuth secrets inside the client. You're trying to make sure, "Hey, wait a minute, how do I make sure those things aren't, exposed to the LLM?"

So there's like all this already set up friction just to enable it. Then there's an end user friction just to do the consent, just to be able to get the, agent to, access the tool. And then from an enterprise perspective, we go back to that OAuth island problem, which is great. Now there's a long-lived token being issued on wherever the agent's running. So that could be an end user's laptop, it could be a phone, it could be some virtual machine sitting out there, or it could even be some other platform, a SaaS provider, whoever that now has delegated access on behalf of that user to some, API or, tool, that again, is sort of how do I or govern that or even know about it once it's been authorized?

So we have long-lived tokens. We have secrets and provisioning and setup. We have end user consent and friction that has to happen, and we have to times that by every single tool that I need to access. And a lot of organizations as I mentioned, not-- are not just using a couple tools, they're increasingly using more and more tools because the value of the LLM, you know, is proportional to how much things it can connect to. And then from a deployment rollout perspective, a lot of companies are sort of early in their AI adoption journeys, right? And so they wanna roll these things out to their employees in a, in a more streamlined kind of way.

Like it would be amazing to just, you know, have an onboarding flow for a new hire employee where you onboard the employee and you get access to all your tools, all your connections, everything's pre-configured, just like you would expect today as an end user gets onboarded to their SSO portal, right? So, I don't wanna have to have a wiki of follow all these set, set up instructions just to figure out how the enterprise works for my team, for my context, for my role, for what I'm working on. I just wanna be automatically enrolled into everything and have that centrally deployed, right? So that's sort of an IT sort of, sort of way.

So where does this fit into the announcement? From the OAuth layer, we needed to define that federation layer. So how does an OAuth authorization server trust another upstream provider to issue something that I can then trust to, to issue an OAuth access token without having to, to directly authenticate or consent the user inside my authorization server So OAuth forever has had the ability to, to do these types of concepts. It's-- the base concept is just called an assertion grant. It's sort of defined as an OAuth RFC. There's a framework, there's a old legacy binding for SAML, there's a JWT binding for it. And it works very similar to how you expect like an ID token or a SAML token works, which is, you know, somebody issues and signs an assertion, puts some special claims inside there that are meaningful for the federation.

The other side trusts the issuer and if I trust it, I validate signature, the claims are, are valid. I then map that into my application, and then I don't need to directly authenticate the user. There's a trust relationship that I'm using to establish that. The problem with a lot of the base layers is that it leaves so many decisions up for deployment, which creates the interoperability gap. So if you just define a, a generic token format and say, "Here's how you put things in it," you don't get to a deployment model where I can build a c- you know, a, a Claude or a agent or an application and make sure that it works with anybody who's doing the issuing side or anybody that's doing the consuming side.

So just to to put some names, 'cause we're probably gonna have to come back to these, is there's the, the resource authorization server which issues a token to its protected resources. You could think of that as the tool provider or the SaaS company or some other resource provider inside your organization that's first party. And then there's the issuing authorization server which in ID-JAG we had to make a decision on where should that be in the architecture. And so anybody could be an issuer. I mean, if you just have a private key and you say, "I'm an issuer," and then you publish your key, somebody has to trust that issuer and you have to solve, well, what does trust mean?

What, what is the issuer actually responsible for? What's the, the, the, the conventions and the sort of, of ontology of the claims, and how do I ensure uniqueness and all these types of problems which happens with trust mapping. So one option was, hey, we're gonna require every single SaaS provider out there or tool provider out there to effectively build a Product capability, which is bring your own provider, where I'm gonna have to then establish a configuration screen that says, "Here's who I trust, here's the data and the claims, and here's all the claims that come in the token, and here's how I map them to my application."

And then I have to hope that the client then that's configured knows how to get those from the upstream provider, and how do I repeat that across N number of implementations and N number of providers? And so this is again, more analogous to how, like how workload identity federation started, where these sort of claim mapping screens with trust bring a, a custom issuer were sort of okay because the deployment model was a lot more fixed for, like my workloads, my deployments, where I could use CI/CD and a bunch of, you know, code or configuration languages and check that into my, to my Git and deploy and, and manage it in a, in a more controlled way.

When we move out to these sort of, SaaS application scenarios, we're acting on behalf of users, is they already have existing users. They already have existing data. They already have existing permissions for those users inside those applications and identifiers for those users. And what one application calls another a us- a user ID is different than another application's user ID. So there's not, like, a clear way to talk about h- the same user across a series of applications. Email is, you know, a common linkable identifier, but that may not be how how they're identified locally across inside all the different applications because applications have tenants. Each tenant could have its own local identifier.

You get into a lot of these application level concerns. So why ID JAC? ID JAC needed to m- define the interoperable surface area that sort of is how do I know which user it is? How do I make sure that it's the right user for the resource provider when the client that's requesting the application, or requesting access to it, is in a different trust domain? So we call that sort of, of identity chaining across trust domains is a sort of OAuth spec that sort of defines the, the macro problem statement about how to go across these different trust domains. And so the, the key here is an application-- My application sits in one trust domain.

It needs to access a, a, a, a protected resource in another trust domain, which is another application boundary, for the same user that maybe calls something different in each trust domain, and I need some way to broker across those and, and do that. And so we said, "Well, if the SSO provider is already doing this for the user layer, how can we extend that to support SSO for APIs?" And so that's sort of the, the third-- going back to the third pillar, which is like, well, if we are doing on behalf of, if we're doing this across trust domains, and we're doing this in a scenario where it's acting on behalf of a user, the IDP already has the graph of, of user-to-app relationships.

It already knows the identifiers. It already is a, a discoverable or centralized endpoint inside the enterprise 'cause it authenticated the user. So if I know which IDP the user came from, then I should be able to say then, "Hey, why can't I SSO to other APIs just like I could bounce the user to SSO to a, to a deep link or something inside the browser," right? So ID-JAG was the OAuth specification that defined those interoperability layers that needed on top of this cross-domain model that filled in some of those gaps that really was needed in a deployment model where users are effectively deployed in each application and that could be potentially identified with different identifiers that only the IDP knows about.

So that's ID-JAG. Pause there for a second before we get into how that maps into XSAA and some of the other terms.

Allie Howe Yeah, no, that definitely makes sense, and definitely also makes sense now, like setting the stage for how ID-JAG, you know, powers cross-app access and powers enterprise managed auth. One thing that stuck out to me while learning about ID-JAG and also these announcements was, you know, in, in security, we don't always see security advancements also be a win for like the user too which I think is really special about ID-JAG and all of this because like you said, it's super high friction for users to be doing OAuth consent Yeah every single every single app. And now with ID-JAG it's just authorized once via your IDP and they've got access to everything.

This also helps your, security team be able to have a central place to enforce consistent policy and also solve that OAuth island problem you were talking about where you can't tell like exactly like which OAuth tokens are live that a user has consented to, and you also can't revoke those when you need to quickly. So and it's-- I think that's also seen by how the industry has released, you know- Supported both of these announcements, it seems like. So like I know with the Okta Cross-App Access announ- announcement, there was a bunch of like supporters that announced support for that including like Keycard and like Datadog and Cursor, amongst like many others.

So I think like that's a huge win for, you know, both security and users, and that's why we're seeing like so much support from the industry around this. So it is very exciting both for users and for organizations and enterprises like you were mentioning.

Karl McGuinness I think that that's pretty spot on, which was if we kind of, again, I just go back to the previous wave of, of sort of SaaS and cloud adoption, which was SSO had that property, which was great for the end users, great for security. Which is end users don't wanna have to type credentials in and sign into every application. Enterprises don't wanna manage the credentials in every application. And so SSO gave the, the end user a win of these, you know, centralized dashboards, SSO to everything. I don't need to manage accounts and credentials to everything, and the IT organization and security organizations got their central policy decision point to put MFA, put lifecycle and things in win.

And, once it became clear that like that's the v- that becomes the de facto standard effectively for how folks move forward in, so now folks don't think about, "Hey, I, should I implement SSO?" It just becomes like, "Of course I'm gonna implement SSO," right? And so we have that same sort of bootstrap challenge here, which is like we mentioned this OAuth Island problem, is everybody kinda knew this problem existed, but nobody had a real clear way to bootstrap it. And I think that's the magic of what's just happened in, I think, in the last sort of couple of weeks, which was the bootstrap magic. Which is, Hey, the spec's been in development.

We've known this problem for a while. We've been iterating on it. We got a good, you know, foundation for how it might work. Cross-app access is sort of the, the, just to kind of disambiguate some of the terminology. It's both sort of Okta's branding of the thing, but it's also sort of more generalized the sort of pattern. And so we've... I think we updated the ID Jack spec to help a little, add a little bit of clarity, just because I know those terms are a little bit confusing. Cross-app access is, hey, if I'm an app and I need to access another application, it's a cross-app access scenario.

So how should the application get a token and to access another thing? That's sort of like a software pattern type problem. And then ID Jack is an implementation of that particular pattern because you could use probably different sets of protocols to, to achieve the pattern and so then there's Okta's product feature set, which also uses the cross-app access, which is sort of the pattern as a product name. So all of them sort of are all logically the same. You could think cross-app access is just sort of the goal, the end user goal. I wanna do cross-app access. ID Jack's an implementation of it that is sort of ready to go today that provides that key piece.

So from a bootstrap perspective, like what just happened, I think is, is kind of the lesson learned, which is specs take a long time to develop. People have known these problems, but how do you align the incentives to get to critical mass? I remember knocking on doors early in, in ID Jack talking to these SaaS providers and saying, "Hey, this thing is gonna solve a lot of these security usability challenges. It's gonna be great for your end users. It's the right thing. It builds on top of SSO. It's incremental adoption on your side. You don't have to build a whole new stack, like get on board."

And, you know, the product teams were basically like, "Why do, why do I care about this right now? My customers aren't asking for it. It's not needed. I can't get approval. My VP director or whatever isn't gonna get this thing through. It sounds cool, but like I don't have the demand," right? I mean, so we were stuck on a demand side problem, right? Which was until there's enough demand how do you get the ecosystem to care? And then on the opposite side, you have the challenge of supply. So, if there's not enough a customer-- or, you know, applications that support it, either from the client side or the resource provider side, then how do you get somebody to build an implementation?

Because they're gonna be like, "Well, nobody supports it. Why, why would I prioritize this on my roadmap?" So like everything in standards, it's like, how do you align that? And I think what we were lucky from an industry perspective is that agents and MCP really just became the sort of crossing the chasm moment of like, we can no longer pretend that this isn't gonna be something we need to solve. And getting sort of the MVP of like, you know, an identity provider that has a lot of customers a leading sort of model provider that is, that, that is demonstrating the end-to-end value of the, of the use case, and a core set of key applications that the enterprise cares about working, and a core set of integration partners that are sort of providing gateways and solutions, and a core set of, of, of client applications that aren't just model providers, that are sort of platforms.

Demonstrating every one of those roles in the value chain in sort of a, a launch where folks then see the end-to-end being like, "Well, of course that's what hap- that's, that's beautiful. It just works." And so once that, that happens, then what you start seeing is every, you know, VP, product manager, whatever, and saying, "Well, how come we don't have that?" 'Cause that's the right solution. And so you're snowballing into this adoption curve now is because it's so hard to get to that s- initial momentum point, but once you sort of cross that, you start seeing, I think the, the logic to this, which is SSO for users, SSO for APIs.

It all aligns, it's all great, and it all becomes building blocks. The key thing that we need to be clear about is that it doesn't solve everything. Right? This is this is just one part of the larger puzzle. But what it does is it shifts that OAuth island problem from now having to solve all of these concerns in every single island to, hey, at least now I have a central checkpoint, right? I can say these apps can talk to these apps, and these apps, if I don't want them to, I can revoke them. And I know that because everything's short-lived tokens, that the next time it goes to get a token, I can deny it without having to go and do a complex, you know, inventory asset management synchronization engine that then builds an index of everything and re-audits everything, everything.

Sort of like that, that general problems that you wanna TTL these things off versus trying to maintain all the state and try to manage all the state in a stateful kind of way, right? And so we, we unblock that. We give the users a win. We start getting everybody coalescing around this problem. And then I think what we're gonna start seeing is layering on top of that for the next set of use cases, trying to solve the next set of problems. But I think folks now sort of see the aha moment which is sort of the, the EMA announcement. The EMA announcement with Claude implementing it.

Hey, it's part of MCP. It's ready for anybody to implement. Claude implements it from a Claude Code perspective. There's an IDP that implements it. This stuff's real. It's ready to go. It's not, you know, it's not the one drafty where you have to like worry about spending so much of your product engineering cycles just trying to figure out the edges. It's still early. There's still stuff to do, but it's ready to start moving forward to like real world deployment instead of it being more hypothetical, theoretical. And I think what's exciting right now with the MCP announcement and the cloud announcement is ID-JAG goes from, hey, OAuth islands we know.

We now have a plan to solve it. We now have a spec that's been moving along. We now have a product that demonstrates end-to-end, and we have an ecosystem of key players that sort of demonstrate the value curve, and it's ready to go for you to, join the fun, I think is kind of why I think the last week has been a big set of excitement for folks.

Allie Howe Yes, absolutely. Yeah, it was really cool to see the enterprise manage authorization extension be added to, MCP. So now everyone that's building an MCP server can, take part in all of these great, advancements. so yeah, really interesting to see how people start to catch on and realize like the importance of this just because, you know, I know MCP is a very, well-used, protocol now. But yeah, it's amazing to see the industry evolve so quickly and just see how many participants and people we need to move all of this forward, in terms of like, you know, just this one thing that you created, ID-JAG

Karl McGuinness One piece. Yeah. We have like, 30 of these things that need to happen, right? And so I think there's just lessons learned here for folks and, and sort of like a success pattern of how this can happen. And I think there's, you know, more conversations as an industry of just sort of learning from here. And it's still early. Maybe it may not work out. Maybe we're, celebrating our victory a little too early, but I'm feeling pretty, positive about this one. One thing to call out was just another value of sort of solving these problems at the right layers. Like, we could have just made an MCP specific solution, right?

But by layering these things correctly, by, for example, putting it on the OAuth layer, right, folks can implement this in new use cases like CLI tools or other aspects, and it works with REST APIs and other use cases. And so it becomes a broader solution across, again, SSO to API or SSO to tool or SSO to whatever, versus kind of just solving this at the highest level in a, in a, in a point solution kind of way, is that we've, we kind of now get to ride on top of everything that sort of is on the OAuth layer once you, you kind of made the jump to this.

So you start... You hopefully will start to see folks starting to, to, to see use cases of this implemented outside of, of, of MCP as well.

Allie Howe Yes, for sure. I know a lot of people are creating agents that interface with like other agents and also just like tons of tools. You can't really project what your agent will end up connecting to. So to have like one place to centrally manage that, especially from a security perspective super powerful for sure.

Karl McGuinness We, we do have work to do on agent to agent and multi-hop. So just as sort of some limitations today with ID-JAG, just sort of where we are on the, on the rollout and just the problem stack is it works today when you sign into your application and your application wants to talk to another application. When you start chaining multiple of these down the road, like so now that application wants to talk to another app, and then it wants to talk to another app, and sort of wants all of those to be on behalf of user, there's a whole bunch of challenges there, and so we're not quite there yet.

It's early days because just the first hop alone gives a tremendous amount of value to an organization. Again, think of that as just my agent talks to a whole set of tools. Those tools are on a whole bunch of vendors. There's a whole bunch of credentials and tokens and refresh that happens there. Just kind of like moving the needle on that problem is just a major win. There's a whole bunch of surface area to then start thinking about when we start talking about agent to agent, when we start talking about crossed, you know, multi-hop sort of attenuations and challenges just there, which, sort of gets to a, a larger agent discussion just about authorization and, and problem statements there.

And so I just want to be clear that sort of the X AAID-JAG story is right now really just focused on the first win of getting, you know, getting applications that wanna act on behalf of a user to another application where all the applications are owned by one or organization as one sort of way to identify the users across all these things. We can get that sort of move the needle on that problem today.

Allie Howe That makes sense. Yes. And then for sure, it definitely takes like a, a big tent, so to say, to be able to solve all these problems with so many different people involved. And definitely lots more work to do, like you said, but a huge step forward with where ID-JAG is today. And super excited to have you speak at AOF Night next week as well where we're getting together not only you, but Dick Hart and also Herman Eriko from AARM which helps talk to and add that, like, runtime authorization piece around the action layer for agents and deciding, like, what agents can do at what time.

Which is another piece to that puzzle on top of the ID-JAG thing of being able to revoke access because the, the IDP and the enterprise now has access to that, like, token at that point. So yes, this all definitely builds and goes together. How are you looking towards, like, what's next and what excites you about everyone getting together to solve this problem?

Karl McGuinness Yes. So I think, you know, there's so much going on right now, right, in the industry, which is just what are the right primitives where, you know, folks are trying to ride on top of what exists today. They're running into a lot of issues or with, with these advanced scenarios that we're-- OAuth wasn't necessarily built for from day one. There's adoption challenges where even if we do spec these things like who's adopting and how to drive it, which we just talked a little bit about, which is some of the challenges with adoptions. And there are net new problems. And I think folks are just, you know, trying to swi- keep up and swim and stay above right now, which is, you know, there's an identity layer problem statements, there are delegation problem statements, there's multi-chain problem statements.

And then there's just the, what's the right mental model and what's the right protocol layering and where, you know, should we be focusing and what sequencing. So what I'm excited about specifically with AOF Night, for example, is, you know, I've been chatting with Dick for a while here about this challenge to shift to agents And, you know, I fully understand the challenges of, of, of evolving an OAuth stack. We're gonna have to do some of it just because the reality of, again, these applications are being deployed today with what's out there today, and so we're gonna have, have, like, some of these enhancements like ID-JAG move the needle forward.

But we need to have the other conversation as well, which is what's an agent built for agent native stack? And so when we think about the open world challenges for agents and resources interacting with resources for a task and a bounding authority, a set of, of things that we're still heavily in this token model today of, like, thinking of everything as tokens. And when agents move to performing tasks that span multiple servers, multiple tokens and have long-running sort of goals in what they're achieving we have some issues to solve. And, you know, it's nice to see a net new sort of protocol that's kinda built for that kinda world, which we'll talk a little bit about as OAuth.

And we'll start talking about some of the other gaps on the OAuth side as folks get more deployment. But, I think I'm, I'm excited about both sides. I'm exci-excited about sort of moving the, the existing world forward, and I'm excited to get a group of people together and start talking about, well, we know there's these rough edges, and we know there's gonna be a whole bunch of incentive adoption challenges and ecosystem challenges. And so what is built native, and how do we enable organizations to move fast on the right sort of native stack and not to bring some of this baggage forward if, if that's the right use case for you?

Allie Howe Makes sense. Yeah, I'm super excited for AI engineer next week. If you're an AI engineer and you're not necessarily a protocol or identity expert, you're not keeping up on the space you wanna keep up on the best practices for Auth though. Besides the new extension that's available within MCP for EMA, are there any other resources that you recommend AI engineers check out today?

Karl McGuinness Specifically in sort of the identity and access space, you know, a lot of the discussion right now is kind of in these different camps. And so there's gonna be like, you know, there's the IETF camps, which are based on some of the internet standards. OAuth is one working group. There's another working group called WinSE. There's another agent-to-agent working groups. So you'll see a lot of drafts and a lot of proposals and a lot of discussions at the protocol level there. You can see in the OpenID Foundation, more of a taking a higher level view of how do we assemble things together around use cases, scenarios.

There's a AI community working group for there. And then you'll see, you know, at the, the more I guess government level, NIST and organizations like that, that are trying to do submit for, you know, reference architectures and call for papers and trying to assemble more of the sort of top level architectural, similar to what happened with like zero trust, right? Which was like we had a lot of this bottoms up stuff with zero trust. We then fold that into like reference architectures and components. So you're seeing that like community bottoms up, let me go build my own protocol and just be super excited. So the best groups for those are like being in the Discord channels for the communities for MCP and these things.

That's like the fast-moving ring. Then you'll have the s-- the next ring, which is like folks that are trying to think a little bit more about some of the protocol primitives and things like that. Kind of goes into some of these like where the protocols are naturally homed. And then above that is more of these larger, well, you know, standards organizations that are sort of trying to figure out how to put all this stuff together and talk about it in a more broader way. And then the top level is really like the, the larger initiatives that are, are larger organizations like NIST and things like that, that'll be driving some of the, the thesis to it.

And all of them move at different rates, different challenges. They're all not aligned. Nobody has one common picture to this whole thing. But, you kinda can pick which layer is sort of is interesting to, to where your organization, what you're doing. And I think from a developer perspective, the most exciting part right now is really probably closer to that MCP and Auth layers, which is what are the right things I can build today to sort of get time to value and use cases out in line and where is like the edge on like where my use cases aren't quite ready, and I need to better align with some of these other primitives.

And I think those, those will be the places where Auth Night and other workshops like that are gonna be great spots to, to get the dialogue and meet your peers

Allie Howe Yes, absolutely. Yeah, totally agree. Super excited for that, and thank you so much for coming on today. I really appreciate it. I don't know, I definitely learned a lot about ID-JAG and super excited to continue to follow the evolutions in this space. If people want to join you in the conversation, where can they connect with you?

Karl McGuinness Yeah, I'm I have a, a, I have... I'm sure I put it in the notes. There's Twitter, there's LinkedIn put that in the show notes, and then I have a, a blog notes.carlmcginnis.com where I do a lot of writing right now about sort of missing layer for agents and, and governance and delegation and doing a lot of thinking from sort of intent, intent-based authorization and how that plays out and love to, to hear people's thoughts.

Allie Howe Perfect. Thanks, Carl, and we'll see you at AO9.

Karl McGuinness Awesome. Take care. Thanks.