Session Date/Time: 05 Oct 2026 17:00
[00:00:21] Rifaat Shekh-Yusef: I'm gonna give people a few more minutes. Let's start with 1105. Hey, Hannes.
[00:01:25] Hannes Tschofenig: Hey, Rifaat. Can you hear me?
[00:01:26] Rifaat Shekh-Yusef: Yes.
[00:01:28] Hannes Tschofenig: Perfect. It was you. Hey, Dick.
[00:01:34] Dick Hardt: Hello, Hannes. Good evening. I assume you're in Europe.
[00:01:37] Hannes Tschofenig: Yep. And hey, Deb. Oh, I see a bunch of other people on the call. That's excellent.
[00:01:48] Rifaat Shekh-Yusef: Hello. I'm, also in the midst of making trouble on TLS. So Never ending there. Right? You can read that later.
[00:02:01] Hannes Tschofenig: Rifaat, I'm going to take some notes again.
[00:02:04] Rifaat Shekh-Yusef: Thank you. Thanks, Hannes. Appreciate that. K. We'll stop in a minute here. Sorry. Okay. Let's, get going. So, welcome, everyone. As as a reminder, Note Well applies here. This covers everything that we do at the IETf from how to participate, how to contribute, how to behave, how to respectfully disagree with others, IPR. All of this stuff is covered by Northwell. So if you're not familiar with this, make sure you are. Today, we will be talking about AAuth. Reminder that next week, we don't have a meeting. Like, we we have the series, but, like, at the same time, same day, but, like, not next week. We still have one more week meeting on the nineteenth, and there is still one more that might be coming the '26. So we're still
[00:06:00] Jonathan Rosenberg: kind of
[00:06:01] Rifaat Shekh-Yusef: digging into that. Okay? So that's, our plan. And now if there's no questions or comments, I am gonna stop sharing and share the slides and hand it to Dick and see if you can control the slides, Dick.
[00:06:27] Dick Hardt: Looks like it. Yep. Okay. Thank you.
[00:06:29] Rifaat Shekh-Yusef: Yeah. Drive from here.
[00:06:32] Dick Hardt: Great. Well, thank you everybody for coming. There's some fair amount of material, and, also, this is gonna be kind of more of a high level. What is it? I'm gonna go over sort of, like, what rules, some of the foundations, some of the ways that access is done. I found the talk last week from OpenAI and Anthropic useful, and so I'm gonna relate features that they... Or aspects they talk about there to a auth. And then end with, you know, question for the working group about where... If we do this work. There's sort of the core protocol. There's another document signature key. There's one on rich resource request on events. There's a bootstrap document that's around how you bootstrap up a agent provider, budgets, supervision, and a a related spec that's over over in the OpenID foundation that I just started off around well known binding. So there's a number of new roles in a auth versus o auth. There's a supervisor, what, people also call a guardian agent or a governance agent that, is able to make, policy decisions, that are nondeterministic. You know, since what a human would do, we can now have agents do those things. So that's the supervisor. Do people see my mouse when I move around? Yes? No?
[00:08:18] Aaron Parecki: No. We do not. No. No.
[00:08:20] Dick Hardt: So I won't I won't point with the mouse then. There's down at the bottom, the agent provider. That's sort of backing out a little bit from what's in a op that the age... There's a separate entity that decides whether something's an agent, finds its key to aspects about the agent, which in OAuth terms would be the client. And then there's agent, which is like the client, the resource, which is like a resource server and OAuth, an access server, which is kinda like the OAuth authorization server, but it it may interact with a person but may not. And then there's a person server, which you can kind of think of as mix of an identity provider and manages consent. And so the person server represents the person using the agent, and the access server represents the resource in things where the resource wants independent management of access compared to the person doing things. So here's a, you know, a chart showing sort of the same thing. And the OpenID foundation stuff that I've had, people that are wanting to provide different kinds of, either certification or... I always get these words confused. Conformance and compliance about entities, whether that's a resource or a person server or an agent. And so exploring sort of how trust marks that are an OpenID federation can be bound to those. One of the drivers for this particularly around, resources is that in AAuth... Connecting to an AAuth resources dynamic. And so this would enable this, parts of the system as they encounter a new party to be able to make decisions whether they wanna interact with that party in real time since those relationships are not... Aren't usually set up ahead of time and are dynamic. So what's different from OAuth and Aauth? Everything's signed, whether it's an API call to the resource or it's a call to the person server or the person server calling the access server or the access server and person server calling the resource. Everything has keys and everything can call... Could call everything, although not calling everything is... Makes sense in the protocol. But because of that, a number of things like, token revocation are fairly easy to do because you already know the identifier for, say, access server or a personal server. And so when a resource gets called by them, it knows it's a specific, resource server or person server. So number of things that are hard to bolt on to OAuth are easy. As I mentioned, no registration. Every server has keys and signs. You know, there's a person server and access server instead of just the authorization server. The flow starts talking to the resource and it creating, you know, it deciding what does it need as opposed to starting... You know, OAuth typically starts off of add an app that redirects over to the authorization server to get permission and then comes back. And then once it gets a token, that's the first time the resource interacts here. We've inverted that where you start off at the resource first. And and separate from par, you don't talk... You talk to the resource before you talk to the authorization server. The person is a principal. A person could be either a human or a organization. The token could have identity claims and or authorization claims in what we call the auth token. And, you know, starting off day one, it has call chaining, subagents, revocation, you know, cascading of revocation, are all in core. Every request is signed with RFC 9421. Is it 9421? Yes. I think so. Justin, like, why am I thinking that's wrong? Anyway, HP message signing. So, you know, standard signature input, standard signature. The new thing is signature key, which talks about, you know, where the key does manage its key discovery. And so it says the scheme, and so one of the schemes is the JWT scheme. And so you're passing a JWT in the header. And in that JWT would be the key that was used to sign. And since it's a JWT, you're binding that key to a number of other claims by some other issuer. And so when you receive these, you verify the JWT, and then you verify the signature using the key that was in the JWT. And then that lets you know that the caller is the one that had the private key bound to that JWT that somebody else has made statements about that holder. And so those other claims can be... Oh, we'll see those in the in the token. The other, scheme is JWKS URI where you say, you know, this is from... This is how the PS and the AS, make calls, and they say, hey. Here's my... I'm gonna use the JWKS URI. Here's my ID, and I want you to use this dot well known. So there's... If you look in there, there's a d w k equals a auth dash person dot JSON. That's the dot well known for a person server. So the party at the other end knows, okay. I go fetch the dot well known of AAuth person dot JSON to get the metadata for that server, and there will be a JWKS URI in that. And I will fetch that JWKS URI, and that will be where the keys... The public keys are that were used to sign, this message. And I'm missing in here the key ID, which would say which key out of those keys to use. They all addresses a number of the security issues that came about from Oauth. Right? So there's no token theft because there's no bearer tokens. There's no code theft because there's no authorization code. There's no confused deputy because the resource signs... The the resource signs a resource token that's bound to the key of the agent that called it so that other parties know that it was really this particular instance of an agent that was calling this particular resource. And so, yeah, much tighter binding and and address confused deputy and some of the man in the middle attacks and mix up attacks. You know, client impersonation, The AAuth doesn't move the code back and forth, and and so there's a binding between an specific agent and a person so that, you know, building on sort of the SEBA model that once the agent and person have been bound, when the agent calls a person server, the person server can go out of band, you know, directly with a push or something like that to the user as opposed to requiring a redirect. So the the redirect is... When it does come into play is really just to move the user experience as opposed to part of the security of the protocol. And replication is, you know, initiated by the issuers and and push and cascades down to even through chain calls. In a auth, there's four policy evaluation points. So the agent provider can decide, hey. Does the agent still have all the characteristics? Does it still have the right posture? And it and it can evaluate that to decide doesn't wanna issue another agent token. Person server, if you saw my talk in Vienna, you know, I talked about the mission and consent and nondeterministic policies. And so the person server can evaluate all of those things and has context of what are all the things that the agent has done prior to this particular call and can then use all of that context in being able to make a decision. Authorization server, access server are are similar. There's a little more signal in AAuth because the new agent token... Sorry. The agent posture through the agent token is provided to the access server so it has more context about the agent. And the resource server and resource, you know, similarly are enforcing around the access token, but there's more standardized things than what the resource can do in a auth. So to lower the barrier to adoption of a auth, there's a number of different modes around how you can access a resource. And so the first one doesn't require anything except for, you know, an agent provider, an agent, and the resource. And the agent makes a call, and the resource can decide based off of the agent identifier whether it's gonna let the agent, you know, whether it's gonna enable that call or not. Built into a auth is that all the calls, both the API endpoints and to the person server, can all respond with a two zero two and be able to respond with that they need an interaction. And so the resource could say, hey. I need to interact with your human. You know, it could allow a certain number of calls for... As a resource, say, it's something that's wanting to lower the barrier to developer adoption. You could let an agent make a certain number of calls, and at some point, you decide, okay. I need to know who your human is if you wanna be able to do more things. Sends an interaction URI down that the agent would then provide to the user developer who would then flow over to the resource, do whatever they're normally doing. And then the resource, they would essentially use that agent identifier instead of an API key for managing access to the resource. So row one, I think, could be very powerful in improving the security of just how API keys are used instead of proof of possession. The second one is
[00:20:33] Hannes Tschofenig: set up
[00:20:33] Dick Hardt: so that an existing OAuth, system could be integrated into aAuth. And so server, effectively, a proxy that's acting as an OAuth client gets a call. It can go and say, need to interact with user. It can go through a whole OAuth flow. It would then... Could then store the access token encrypted into an opaque token that it hands down to the agent and that the agent passes that opaque token up to the proxy, which then unwraps that access token and makes the API calls. And so this would be a way for not having bare access tokens in agents, and so you get the proof of possession of agents without having to rework all of the existing OAuth infrastructure. Level three, it's using a, what we call, a person token, which just has an identifier for the person. And so the agent could just say, yeah. I... All I need to know is which user you are, and I can grant access based on that. And the next one is where the resource wants some consent and some additional identity claims about the person, and so it's all just uses the PS. And then the next level is where the... There's an AS that the resource says, in order for you to be able to talk to me, you need to go get a auth token from the AS. I'm just gonna, like, go back to the little picture here just to help make that a little more clear. So that last one is the resource says, I need a token from the... Oh, right. You guys can't see the mouse. So bottom right, the resource says, oh, you need to get something from the access server. That goes back to the agent. The agent goes to the person server and says, hey. I need to go and goes... It talks to the access server to get the auth token, which then goes back down to the agent. The things we we are adding a number... You know, a auth is a little chatty compared to a... O auth. But the advantage of this is that the person server has visibility into all the things the agent's doing, which enables that the... If it needs to revoke things for the agent, it knows where all the things are because it's all... Saw them all. And so the agent might be talking to five different resources that are getting access tokens from five different off access servers. But, you know, if you need to revoke at the person server, you can still drive revocation across all of these other trust domains. So agent identity replacing API keys. We talked about that in detail. Resource wrap. Oauth-token-client. Got that I actually had nice slides for these. Person identity where you're getting claims about the person, and so a auth reuses the OpenID connect claims of, you know, email and the tenant. Some of the enterprise ones were adding role group, things like that. And, you know, you can just go for authorization with an AS, and then here showing the, sequence diagram between agents, resources, PS, and AS. This is the most complicated flow where, you know, the agent goes... Gets a person token, uses that person token to go to the resource. Resource generates a resource token that captures everything. Agent sends that all to the person server that says, oh, okay. I need to talk to this. AS comes back to the PS. The PS could still, at this point, go and look at that auth token, look at the scope of the mission and everything and decide, no. I'm not gonna let that agent have access because it shouldn't be doing this even though everything else said. So enables
[00:25:01] Hannes Tschofenig: you
[00:25:01] Dick Hardt: to have the... Yep. You know, that as yet another policy enforcement point. But if it does give the opt token back, then the agent can make the call. I'm not sure it's useful to look over these, but if you're looking over slides, you can go and map between the different problems Anthropic had and the slides that I've got here going over some of the other features. So there's four tokens. Agent tokens, you know, which agent, person token for what person. Resource token is generated by the resource. Say, hey. What is needed? And the auth token is what is granted. And over on the right hand side, you can see how these map to kind of the closest things in OAuth, well, and OpenID Connect. So the agent token, one of the claims that all the tokens have is a DWK of, like, where is it? It's not well known. They all have except for the resource token. The agent token, you know, has the the key. And so in the agent token, you can have other claims made by the agent provider about the agent, you know, posture, things like that. So the agent trust framework, which is in the cloud security alliance, right, they've got this maturity level of things that people are interested in. And so we've got some demos of code that binds that claim into an agent token that then a resource or a access server can look at that to make decisions about whether an agent's allowed to do something. Person token, you know, issued by the person server, of course, and your regular OpenID Connect sub. And if it's a managed account, you know, that there's a tenant, that's one of the new claims in OpenID Connect. Once again, the... This would be the key of the agent, and then potentially a mission. Resource token, it talks about, you know, who was the user, what was the person server, what was the token it got presented in the call, what was the the thumbprint of the key that was used, what was the scope, all of these to enable the processor of the resource and the authorization to be able to know that it was for sure this one agent that made that call. And then an auth token, you know, kinda like a person token except that it can have other claims inside of it. Another part of a auth is that, you know, at any time... And OAuth has this, but people don't generally use it, is that the resource at any time can say, hey. You need more permission to be able to do this. And so that could be... Oh, you need a new scope that you don't have before. And, you know, so that means that you would go back and have a person authorize an additional scope for that, but also enables you to go down to per call authorization where the resource says to make this specific call, you need to go get permission to make this call. And related to that is also, okay. I made that call, but I'm not gonna give you that results until I get permission to give you those results. So for example, those results might have PII or might have... There might be... You you don't necessarily know what the results are. And so in the mission and then authorization, you don't know whether the agent should be able to get it. So that would enable you to know whether agent should have access to that result. And, also, since you do know what they got, that might actually change the policy around what you let that agent do later on. Mission supervision, the... You know, if you've read some of what I've written and Karl's written, I talked about this in Vienna, is that with agents, you know, the... There... It isn't just the one call. It's a whole context around what are you wanting the agent to go do. And you wanna be able to make decisions in the context of what the mission was and what else you've granted and what else they have done along the way. And that you wanna be able to pull all that together and be able to go and have another agent be able to make supervision decisions on that so you can run at machine speed and be able to make these decisions around, you know, the agent that... Who knows what it's gonna be doing for sure because you gave it a task, and it's figuring out what it needs to do and what resources it needs for that task that you can now manage a system like that. Somewhat new concept that we've come across because as people turn up and enable agents that have access to a resource is the agents say, oh, here's something. That seems useful. And because, of course, it's nondeterministic, nobody wrote the code around what the agent is. It doesn't know that it shouldn't call that a 100 times instead of just twice. And so often, people are making a resource available, and it gets DOS because usage went up by two or three orders of magnitude, and, there was no control. So budgets are concept that they go into an off token, and, essentially, you allocate some budget in the token to the agent. And so the resource tracks how much of that budget was used in that token. So it's only for the period of time that that token's valid, say, for an hour. And so, say, the budget was, you know, 5,000,000 things in an hour. The... Once those 5,000,000 are spent, you've exhausted the access token. The agent needs to go back and get another auth token. And so access is denied when either the token expires or when, the budget's exhausted, and then that enables the rest of the machinery to make decisions whether that agent should be granted should still be granted access and whether it should be granted additional budget or not. Sub agents, once again, you know, part of the core protocol, They're managed by the parent agent. They don't talk to the PS. The parent agent talks to the PS, gets their token for them, but they have their own key. And so they inherently have a subset of access than what the parent has, but enables a parent to delegate to, multiple sub agents. Currently capped at one level mainly because wasn't really clear that you needed more than one level for that. Call chaining, once again, a first class aspect of a auth. So an agent calls a resource. That resource needs to act as an agent and call another resource. So it can go back to the same person server and say, hey. I need to call this other resource. That person server says, oh, okay. Well, I can see which person you're working with, and you need to do that. And so I can go and get you your own auth token for you to call resource two. And so this can chain as far as you want. The PS manages the chain. You don't... You're not having to disclose further down who is up in the chain. And because it all flows through the person server, you can, you know, revoke across and down all the chains, which is what this slide talks about about how you can do revocation and how that cascades down. And so revocation call, the issuer calls and says, here's the identifier of the token, and here's the expiry. The recipient of the call may not have seen the token yet. And so whenever it gets that, it stores it in short term memory because it only needs to hold on to it until that token expires and then, you know, checks any token coming in to see is this one of the tokens that's been revoked. And if so, then says, hey. That token's been revoked. Most of all, this is running in either stuff I've deployed that other people are working with. These are the the the deployments that I have or that people have paid me to build. So there's a MCP server that looks like... You know, runs like an MCP server but talks Aauth. Then there are Aauth resources that wrap Oauth resources. And so here's a bunch of the things that are all behind a proxy. So these are all available as a auth resources. And so once you've installed the MCP server, you can say, hey. Connect to this here, any of these other things. And it says, okay. I'm connected. And if it needs an OAuth flow, it says, oh, I need to get authorization for that, and that authorization flow happens. This is a service I built for a customer around entity analytics, aka, identity intelligence that uses budgets to manage how much usage it has. Here's a fun little one I made for how the agents send messages to other agents called the secret agent co op, and it does call chaining because when you send a message, you send it to an encrypt service that then sends it to the secret agent co op. And when you wanna read a message, you call a decrypt service that then calls secret agent co op flowing through everything. And then the sensing works with an access server and so revocation, you know, sort of tested, seeing how that flows through chains. That is all the prepared work. We could open it up for questions on other things. The big question is is this work of which there's a fair amount of things something that this working group wants to work on because this work... It's within the charter of the OAuth working group. Or, do people feel that we should really create a new working group for it sort of similar to what we did with, Ganap? And, of course, I want to know who all is interested in participating in this. So with that, I'll turn it over to the chair to chair discussion.
[00:37:09] Rifaat Shekh-Yusef: Thanks, Dick. Appreciate that. Okay. So these are good questions. You can keep it here. So thoughts from people, like, about the presentation and and the ideas in general and and where they should work... Where this work should go and... So we'd like to hear from you guys. Anybody has any thoughts? Yeah.
[00:37:48] Aaron Parecki: I have a suggestion for a different option that's, option c, possibly. I think there's some interesting ideas on this and some new... Somewhat new relationships between things, but a lot of this is things that you can do and either are done in OAuth or have profiles that are done in OAuth or could be done in OAuth or, like you mentioned, already described, but nobody actually implements it that way. So I think option c is we try to identify those those elements or, like, figure out what's been working, what's been going on in this that we could bring into Oauth terms using the, you know, existing Oauth ecosystem and infrastructure and just try to slowly build on on that.
[00:38:43] Rifaat Shekh-Yusef: So just just to make sure I understand what you're saying, Aaron, is that option c... If I understood you correctly, you're saying maybe we can take some of those ideas that they all have had and merge it into OAuth and kind of
[00:39:01] Aaron Parecki: Yeah. So instead of, saying that this is a new a new thing that we're gonna do, it's try to identify the actual new pieces because not everything in this presentation is new. Try to identify the new pieces and do those in, building on the existing body of OAuth work.
[00:39:22] Rifaat Shekh-Yusef: Okay. So so then, essentially, you're you're talking about option a and then... No.
[00:39:30] Aaron Parecki: Not not not necessarily. Well, at least not the way that option a is framed here. So it would not be OAuth three. It's not
[00:39:41] Rifaat Shekh-Yusef: Oh, I see.
[00:39:42] Aaron Parecki: It's not a new version of OAuth. It's literally just take Oauth-two, continue what we have been doing, which is deprecating older behavior, like how we've done with the implicit flow and, you know, deprecate old things, continue to pull in new things, and and evolve it. But, yes, in the OAuth working group is the commonality there.
[00:40:05] Rifaat Shekh-Yusef: Okay. Perfect. Thanks. Thanks, Aaron. Hey, Atul.
[00:40:10] Atul Tulshibagwale: Hey. So I thought the HTTP signatures as a way of moving possession of the JWT was an interesting aspect of what you're doing, Dick. And have you thought about breaking that out as a separate, like, proposal that you can then use not just in AI but everywhere else?
[00:40:34] Dick Hardt: It it was presented to... Yes. I saw that as a wholly new type of functionality. Originally, I'd had it in a auth, and then I thought this seems general purpose. I, proposed adoption of that in HDB BIS, which was where HDB message signatures were there. And, you know, Justin, was highly critical of the proposal as it was, and there wasn't, didn't seem like there was energy from other people in HTTP BIST to work on it. But as written, it is a independent document, so other protocols, you know, other things could take advantage of it. Right? It's not AI specific.
[00:41:24] Jonathan Rosenberg: Thanks.
[00:41:26] Rifaat Shekh-Yusef: K. Thanks, Atul. Jeff?
[00:41:29] Jeff Lombardo: Yeah. I second the the the point of, Alan here. Like, into into the comparison, a different point, I was a little bit surprised. Like, one thing that caught my eyes was the... This is client credential for for us. We have more than client credential for for for us. There is, like, there is the private jet. There is, the m t l s client and all those kind of stuff. So we know how to to manage keys if we need to manage keys for how the client can be can be authenticated. Now for the for the connection to the to the proof of position, there is, like, a actively debated element with the call for adoption for HTTP signature for for our endpoint. So so we saw that there is an interest into that and maybe again back porting the rationale that are proposed by AAuth, the good rationale that are proposed by AAuth into that. Maybe a way effectively to to solve it out. There is the last element, which is like, OAuth has no agent post your evaluation. That's true because it's not the it's not the purpose of AAuth. Now, of course, sorry. Start to be confused with the later here. Of course. But in WIMSE, on the other side, through the aims draft that we were talking about, we have described how by associating what WIMSE is proposing and all of this is proposing is allowing to flow the the agent, posture, and in this case, any workload, posture, downstream. So so again, like, instead of trying to create something completely new, I agree with Aaron that maybe we can... We we should look at exactly the good proposal of what is missing into us and and whimsy, maybe also, and and port it over there as a charity.
[00:43:29] Rifaat Shekh-Yusef: Okay. Thanks, Jeff. So, Jonathan.
[00:43:35] Jonathan Rosenberg: Yeah. So I I sort of wanna echo what Aaron said that, you know, I I think the the where question is almost subserving to the to the what question and and whether we approach the gaps we have in OAuth to... With either something totally new, which is what this is, if I'm correctly. I mean, this is almost like a rewrite. Like, I... Half of me thinks, and this is a question for you, Dick. Is this, like, subsumes OAuth? Like, if you... Forgetting the AI agent stuff, you could do in OAuth what you can already do in OAuth. Is is that true? So that was one of your modes. Is that accurate?
[00:44:12] Dick Hardt: I'm glad you brought that up. I I should have had a slide on that because that came up in the, side meeting in Vienna. Yeah. And I've actually found myself going and using OpenID Connect in parts of what I'm deploying as opposed to using a auth for. I... I've... I'm finding that a auth is really targeted at agent oriented workflows and does not work well in things that are your typical web redirect, like, workflow.
[00:44:50] Jonathan Rosenberg: Right. Although it could. Like, that... I mean, my my point is it could. Like, maybe it's not optimized for that, but you you definitely listed it as a mode. Right? I mean, that this is this is a... You know, if you wanted to, it could work that way. Is... That was the question. Yes.
[00:45:03] Dick Hardt: I I think, structurally, it doesn't work well that way.
[00:45:06] Jonathan Rosenberg: Okay. Got it. Alright. Could you... Anyway, fair enough. My point... My meta point was
[00:45:10] Dick Hardt: Yeah. Yeah.
[00:45:11] Jonathan Rosenberg: It's sort of like a reboot. It's a bunch of, like, let's, you know, let's solve a big wide problem and and not, you know, fix a lot of things that maybe we would like to do differently in OAuth even, as opposed to incremental. I I I also favor incremental. I I think if we narrow down... And there's a lot of problems you're addressing in here. I think if we narrow down on, you know, independent small problems that we could tackle with OAuth extensions or or protocols that sit on top of it, I think I think that's probably easier to deploy, and gain support for as others observe. We have a long history of, you know, success due due to a lot of folks in this meeting, like, being successful with OAuth, and it'd be great to try and leverage that. The a auth pro... Protocol that myself and Pat White wrote up about a year back, I'll share the link in the chat, is one such take on sort of an... On top of OAuth rather than instead. So I think that... But my main point is I think the main thing that the group needs to address is, like, what problems do we wanna solve first? And then can we do them with an OAuth extension, or do we need something new? And then where should we do it? I think that's the series of questions you can answer.
[00:46:19] Rifaat Shekh-Yusef: Thanks, Jonathan. Hey, Karl.
[00:46:23] Karl McGuinness: So I just wanna provide some context, which is I've been deep down the other side of the stack, which is kind of building a agent OAuth mission layer that can work that has binding layers that could be, you know, somewhat equivalent to some of the OAuth layers. And, you know, you're looking at, like, 12 or 15 extensions to OAuth. It dramatically shifts some of the roles of OAuth, the role of the authorization server in these multichain with not having a person server as an identified role. I've explored a lot of these areas, and I can talk more in a... In another venue about it. But there's... It's possible to move OAuth forward, drive more agentic first class outcomes by doing incremental extensions. But we will be at a point where the authorization servers will have to be dramatically changed to support these types of use cases where it will look very different at the end of the day. And it will not just be, like, take an existing AS and just sort of increment it out. You'll have to rewrite significant parts of your ASs. And where we get to down the road is is a significant amount of optional extensions that all have to be put together in a profile and compliance, which is just gonna create a significant challenge for adoption because the fragmentation of deployment is gonna be a significant issue. So I support evolving OAuth. I'm spending a significant amount of effort doing that and and bringing a lot of these extensions into it because I think it's necessary. But I also support AAuth because I do, think the simplicity of an agent first native protocol that has everything in core that's needed to do the loops to enable a person server to change what consent has traditionally been modeled inside of an AS to to something that's multi resource is, significantly valuable to, developers starting fresh, moving, fast. And my concern is that by the time we ratify 15 new OAuth extensions, developers would have moved on and, like, we need to kinda move at agent speed. And that's just kinda just where I'm operating as sort of a dual stack approach here, which is, like, let's pull and extend the pieces to a auth from... Or just for agentic outcomes, extend Oauth with whimsy and everything that we're doing, but also having a purpose built narrow that significantly changes the roles, that allows a different implementation to to drive and explore those things is extremely valuable as well.
[00:48:49] Rifaat Shekh-Yusef: Interesting. Thanks, Karl. Okay. So this is a, I guess, the fourth option or, like, work on those in parallel. Is it... Is that is that what you're saying?
[00:49:03] Karl McGuinness: I I was saying... And that's gonna be the reality. Folks are gonna need to evolve their stacks that they have today with use cases. Folks are gonna have net new deployments. And this is sort of like a... You know, this is kinda like, is this I p v four, I p v six? Is this h t v two to h t v three? Like, how do we innate... Like, QUIC was a transformational technology that was, like, you know, built... That kinda built on top of it. Like, there's a lot of different lessons learned. I'm not gonna overly subscribe or apply sort of, analogies, but there is value in moving at where the speed the dick is moving to adopt end to end agent scenarios with budgeting missions. Like, getting this stuff on... In an authorization server is gonna be difficult. And I... Again, I'm committed to it, and I have spent the last nine months doing it on on OAuth bindings. So there's there's there's value on both sides is all I'm trying to say.
[00:49:52] Rifaat Shekh-Yusef: Okay. Thanks, Karl.
[00:49:53] Dick Hardt: But I think... I don't think Karl was proposing a fourth option. I think I'm not. That option a or option b. I think he's against option c of, like, let's not do it.
[00:50:04] Karl McGuinness: Correct.
[00:50:07] Rifaat Shekh-Yusef: But, option c is not saying let's not do it, though. Right?
[00:50:10] Dick Hardt: Oh, yeah. It is.
[00:50:12] Hannes Tschofenig: Yeah. Okay.
[00:50:13] Dick Hardt: Yeah. Option c is, like, let's take those features, and let's let's go and figure out how to go and make a auth do it.
[00:50:21] Rifaat Shekh-Yusef: Okay.
[00:50:22] Dick Hardt: Where option a and option b is there's a new version. Right? OAuth two and OAuth OAuth two was not built on OAuth one. OpenID Connect was not built on SAML. And having been deeply involved in, you know, OpenID Connect versus SAML, the SAML people says, oh, SAML will solve. And we're like, well, no. It doesn't really... It doesn't work the way and do all the things we wanna do. Similarly, you know, OAuth-one people were like, we don't... You know, just build it on top of OAuth-one. And it's like, well, no. Foundationally, it was... Have the wrong attributes. And I have that same view that, foundationally, that the OAuth two doesn't start off with per instance identity. It doesn't start off based on keys. And, sure, we could go and add all of the features in a auth into OAuth, but, really, we just now have a whole new protocol because it doesn't really look like what OAuth looks like today.
[00:51:24] Rifaat Shekh-Yusef: Okay. Okay. Thanks, thanks, Jeff.
[00:51:27] Hannes Tschofenig: Jeff,
[00:51:28] Dick Hardt: OIDC was in contrast to SAML, not OAuth two.
[00:51:34] Jeff Lombardo: I agree with that, but it was written on on top of OAuth. Right. It was an extension to to to us.
[00:51:42] Dick Hardt: Yeah. Of course. Yeah. Which is why it was different than SAML.
[00:51:49] Rifaat Shekh-Yusef: Okay. Atul?
[00:51:53] Atul Tulshibagwale: Yeah. I'm just reading through some of the messages on the HTTP message board. It sounds like there's a few issues that are not still open. I mean, if you're progressing with that... With ART here, wouldn't we... I mean, they could... Do you think those issues are resolved or, you know,
[00:52:12] Dick Hardt: which thing again here. On the HTTPbis? Yeah. I didn't... The the key piece that I got was people thought that they didn't think that there was a need for a general purpose way of signing, which I still disagree with. And so it's like, okay. Well, we'll do one that works for sure for a auth. My coauthor on that is, Pieter Kasselman who is doing web bot auth, and he was very much in favor of let's have a general purpose mechanism. But we didn't have everybody aligned on that.
[00:52:59] Atul Tulshibagwale: So it's in your... You know, I guess you think it's just a matter of opinion and not not a real limitation or something? I
[00:53:14] Dick Hardt: mean, the main thing was there wasn't really interest in doing a general purpose thing, and they HTTPbis. So, I mean, we've got libraries and most popular languages that are all doing, signature key interoperable between each other now. Seems to be working really well. So... K.
[00:53:38] Rifaat Shekh-Yusef: Thanks. Okay. Hey, Pat. Thanks, Atul. Pat?
[00:53:46] Pat White: Yeah. Thank you. So I I tend to agree that that this is a a fundamental protocol rewrite, and it it seems a little bit over the top for things like like this. But but I do have one question, which, Dick, I wanted to make sure I understood. If you're doing a signed message like this, the pattern... I mean, essentially, you said it's a bit chatty, but if I'm reading this right, every single call adds two or three additional calls on top of the primary call. Am I... Did I miss some part of it?
[00:54:19] Dick Hardt: Or No. That's only if you need, like, once you've got a token, you just keep calling with the token the same way you would call with an access token or no auth too.
[00:54:28] Pat White: So the so the signature... The message body... Like, the the HTTP body is not part
[00:54:32] Dick Hardt: of the signature? Oh, you're signing every call. Yes. That's not... That wasn't what I was calling the chatty part. The chatty part agent...
[00:54:42] Pat White: The agent gets a key to sign the calls, or you're you're you're sending your body to the agent server who then signs it, and then you... Then the agent's all forward to sign?
[00:54:52] Dick Hardt: No. No. No. The agent the agent signs all of its own calls with its own key. Okay. Yeah. The the chatty part is that you're not just... As opposed to in, say, the cross app access where the client can go directly to an access server to get a token. In a auth, we say that the agent has to always go back to the person server that then goes to the access server. And so you've got two... A chain... Two calls instead of just one call. The reason we drive that is so that then the person server has visibility into all of the flows. Right? And it's things like that that's, like, completely different than how OAuth works that, you know, makes it effectively a new protocol.
[00:55:43] Pat White: Is... Then the the agent key management is then totally over the top. It's it's, like, not contemplated by this this then?
[00:55:50] Dick Hardt: You're right. That's out of scope. There's there's a... Another document, the AAuth Bootstrap that talks about how an agent provider and agent bootstrap up that key. And so a number of the implementations are where that key actually is just ephemeral within the agent, and it does something else to be able to go and get its key bound to its agent token that it can then use to make calls.
[00:56:14] Pat White: Yeah. Yeah. It's it's a it's a complex protocol. That's my... My comment would just be this is this is... There's a lot of dance here for something that's been relatively well handled in OAuth. So... But, yeah, thank you, Dick. Sure.
[00:56:27] Dick Hardt: Thanks.
[00:56:28] Hannes Tschofenig: Thanks, Pat. Hannes? Yeah. I I was hoping to see a little bit more discussions or feedback on on the features, not so much on where to do the work. Right? It sounds almost to me like people agree that this is a... There is a lot of useful stuff in there that they would also like to see and try to reason about, like, should that be massaged into this sort of protocol or on this extension in this working group or that working group. I'm wondering how to best sort of get an idea from the whole group on what... Where they are with with this with this question. Like, in general, like, if we think there's a lot of useful functionality in there to support agents, then we should do. And then as a second question is we should really think about how we do it. And if you think about, like, we did the SD-JWT and the verifiable credential work, in some sense, you could argue that that's really a deviation from OAuth itself as well on, like, it... Like, the whole pattern and and this this specific model, the holder, the issuer, the verifier model, and so on. So, yeah, we keep we keep changing things, but, of course, not randomly. Obviously, we are seeing some bigger architectural changes now with these agents. So so it's obviously interesting times. Yeah. I think, Aaron, you have an idea. So, Hannes, I think we we probably need
[00:58:14] Rifaat Shekh-Yusef: to take this to the list, Like... But we... You and I, we need to kind of come up with a list of questions to to try to squeeze and try to see what the work group thinks. Right? And and there are
[00:58:29] Atul Tulshibagwale: a number of options.
[00:58:30] Rifaat Shekh-Yusef: So that's... Let's let's do that offline for now. Like, you you might have discussed this.
[00:58:35] Hannes Tschofenig: That... That's true. But there's obviously a lot of good work here in this group.
[00:58:40] Jonathan Rosenberg: Yeah. Like, when I Yeah.
[00:58:41] Hannes Tschofenig: When I talk to other people who are outside the OS working group interested in in the agent work, they really consider the work that you guys are doing as super important for the security of agents. And there's obviously plenty of work that needs to be done to make many of these ancient technologies less problematic. So, yeah, thanks thanks for doing all of this. Yeah. Thanks, Hannes. Hey, Aaron.
[00:59:10] Aaron Parecki: So that's kind of what I was trying to say about, like, let's let's take a look at the actual contents of what's new versus, the way this was presented makes it sound like a lot of things don't exist in OAuth, which they do. Like, even just at the beginning, OAuth, the bearer tokens versus everything assigned. Like, we can just say, we have a profile of OAuth where everything is signed tokens. We have two... Already two mechanisms assigned tokens. We can just do that. But that's not new, and I feel like presenting it that way makes it difficult for people to understand what actually is new in this because there are some genuinely new things in here. But when it's presented as everything has to change, it's difficult to understand what actually is the new part that we could do as an evolution. So I think that's where I'm struggling with this is, like, let's let's try to actually tease out the new things constructively to to to discuss, like, what that could look like if we go that direction.
[01:00:19] Rifaat Shekh-Yusef: Okay. Thanks, Aaron.
[01:00:21] Dick Hardt: Well, I I I disagree very much with that view, but, you know, you you guys can look at it and pull other features in there. I'm gonna work on this because, you know, I think the world wants to be able to move quickly, and we need a solution that is built up on a different foundation. And while you might say, oh, well, there's some things that are sort of there, I would disagree that, you know, there isn't signing in the same way in OAuth, but we don't need to argue about that. And it reminds me of conversations I have with the SAML people. So it's like, well, we can do that. And it's like... But we don't wanna do all the things that you are doing. Right? I don't want most of the... Many of the things in Oauth anymore. Right? We don't need preregistration. So...
[01:01:11] Rifaat Shekh-Yusef: Okay. Thank you, Dick. Thanks thanks, Dick, for great presentation and for for the work group for a good discussion, interesting stuff here. Hannes and I will kind of think about how we're gonna kind of tease out what
[01:01:28] Dick Hardt: the what
[01:01:28] Rifaat Shekh-Yusef: the what the work group wants to do. And we'll we'll do that on the list right after that. Right? So I'd say we don't have time to ask questions at this point, and and and there's still lots of things to digest for us as chairs. So we'll we'll be in touch, guys, on the on the list. Thank you all. Appreciate your time. And we're done.