IETF Meeting Minutes

Session Date/Time: 03 Jun 2026 15:00

Justin Richer: Hey, everybody. Uh, still waiting for Oh, there he is. I was going to say still waiting for my co-chair. But there is Pieter, and it is the appointed hour. So I think we can pretty much get going. Uh, Pieter, you there? You got uh connectivity and all that? Uh, I'm not getting audio from Pieter. Can people hear Oh, there.

Pieter Kasselman: I'm I'm getting I'm getting audio from you.

Justin Richer: Yeah. You you came you came through now. I think I think MeetEcho was just having a moment. All right. Uh, whoop. Or, sorry.

Pieter Kasselman: It might It might also have been me not hitting the the unmute button.

Justin Richer: That would never happen. Um, all right. So, hello, everybody. We're just going to dive right in. We've got a pretty meaty topic today. Um, welcome to the WIMSE interim for the 3rd of June 2026. Uh, did get the date right, I think. I hope. Yes. Um, Noah Stride has uh offered to help take notes. Uh, I'm also going to be backing him up on that. Uh, if anybody else wants to open up the the notepad and make sure, you know, key points don't get missed, please uh please feel free to contribute. Um, and uh, whoop. Or, sorry. This is the interim for the Workload Identity and Multi-System Environments. This is an official IETF meeting, which means that any and all contributions are covered by the IETF Note Well. And note that anytime you say something, type something, or uh submit something to an email address or uh issue tracker or anything like that, that is a contribution, whether you intended it to be or not. Um, and uh the IETF policies are and uh and legal frameworks are very clear about this. So, with that in mind, uh make sure that uh anything that you say and contribute is able to do so under the IPR guidelines of the IETF. If you want more information, feel free to dig into here. Additionally, be nice to each other. Don't be jerks. Um, that is just as important as the uh technical engagement and everything here. And um, that's something that uh we try to hold ourselves to uh as a community in general. Um, so uh today, Pieter, uh would you like to go over what we're covering today at a high level?

Pieter Kasselman: Certainly. Uh, so thanks for uh this opportunity. So, uh we're going to talk about the um AI Agent Authentication and Authorization draft today. Uh, we'll talk a little bit about some of the gaps that we have in there and then also leave some time for discussion about the relevance of this work to um to the community in general and this working group in in in particular. So, that is um kind of the topics that we're going to uh do. So, we'll start off by reviewing the draft and uh we'll actually talk about the gaps as we go through the draft as well, and um and then uh leave time for discussion at the end.

Justin Richer: All right. And uh that's all I have for intro slides. Um, this the recording of this will be up on our working group website um once I go and update that after this meeting. Um, and with that, I am uh ready to hand it over. Uh, who will be presenting today, Pieter? You or Brian or

Pieter Kasselman: Uh, I will present, Brian will present, Yaroslav will present, and uh Jeff will present. So, we'll be we'll be round-robining. But maybe just one of us uh need to be able to drive the slides.

Justin Richer: Yeah, I was going to say, if you uh it's probably best if you drive the slides, but uh feel free to work that out amongst yourselves. Um, they should be uploaded. I saw them in the tool this morning.

Pieter Kasselman: They are. Uh, how do I get hold of them?

Justin Richer: Um, hold on. Let me let me do it this way, because I can I can hand you the slides. Ah, to do. There you go.

Pieter Kasselman: I have control. Okay.

Justin Richer: Excellent. Um, also, as a reminder to uh to everybody before we dive in, if you have a question or comment, uh please join the queue. Uh, that's the little hand raise icon on uh on the bottom. Do not turn on your mic or your uh your camera unless you are actively presenting or actively asking a question. If you're just waiting in the queue, you don't have to turn on your mic to anticipate. Uh, you can turn it on as uh as it is your turn. Um, with that, I am going to get off camera because I am no longer presenting, and uh take it away, folks.

Pieter Kasselman: Thank you, Justin. And in traditional uh or in WIMSE tradition, I am now taking my chair hat off. And uh this is a contribution or discussion that uh as an individual contributor or participant of the working group. Um, so uh today we're going to talk a little bit about this draft that uh we published back uh just prior to Shenzhen. Uh, so basically, this is a uh this is the interim meetings are sort of we're sort of midway between Shenzhen and Vienna. Um, so starting with a beautiful picture uh from Brian, as always. Um, and we're going to talk about the AI Agent Authentication and Authorization draft. Um, we've got a a bunch of editors uh or contributors there, so myself, uh Jeff, Yaroslav, uh Brian, uh Nick Steele, and Aaron. Um, and I think that's sort of a good representation of um some of the support and and need for for this draft. So, um so let's talk a little bit about the draft, and I think the first question, of course, is like, um why do we have this draft? Right? And I think one of the things is uh in this age of AI, the idea of AI agents is scary. Um, there's a lot of uncertainty. Uh, there's a lot of anthropomorphizing, right? We think of these pieces of software and they sort of like they have some human characteristics, etc. And so they they really sort of um create this illusion that everything is new, everything is scary. Um, and we don't really know what to do about them. And I think uh one of the observations that we as editors had was that maybe the situation isn't quite as dire as that when it comes to identity, authentication, and authorization. Um, I think, you know, one of the things that we are all sort of agreed on is that in order to, before we can really reason over any of the access or uh authentication properties of agents, they they really do need to have some kind of identity. You need to be able to identify them. And only then can you start getting into some of the um uh more sort of uh then you can get into the authorization discussions and how they authenticate and uh all the other layers in the stack. Um, and so, you know, our our motivation really, right? So, in this age of AI where there's lots of new things happening and and um a lot of sort of uh ambiguity perhaps for folks because of new terminology and capability, uh there is also this tendency to start inventing new AI protocols, um and new uh AI, new authentication, new authorization uh uh systems. Um, now, the good news is that, of course, um if when you sort of take a step back and you think about AI agents, and talk more about this later, um we are not really starting from scratch, right? AI is software. It's an algorithm. Um, and we kind of know how to deal with software and algorithms. Um, I think what's new is maybe some of the predictability of those, and we'll talk more about that. But I think one of the things that we as as editors or authors thought felt was that it would be great not to go and repeat the history of all the mistakes of identity, authentication, and authorization that we've gotten wrong over the years, right? It's it's not a new problem, uh and we've also learned sort of lots of lessons out of that. Um, the other thing is also that there isn't a single solution to any of this, is sort of one of our other things that we've sort of learned over time is um you know, you really have to think about a wide range of technologies. There's identifiers, uh there's credentials, there's provisioning, um there's authentication, authorization, there's monitoring, right? There's a whole set of things, um and right now there isn't really sort of a good organizing framework for folks to think about that or, you know, everybody sort of picks a piece of it, um and we really wanted to to provide some kind of framing to say, "Well, here here is a here here is an approach or a way to think about the AI agent authentication and authorization story." Um, and I think the other thing is, right, uh we I think we're not advocating or saying that we already have all the the answers. I think that is almost certainly not true. Um, but one of the things that we want to be very specific and focused on is to figure out what bits are really missing. Uh, because I think it's very tempting to start sort of go and cut from whole cloth complete new solutions, um but it is very plausible that with sort of a couple of really sort of focused investments, we can actually alleviate some of the challenges uh that's out there. Um, the other thing is also there's that so none of what we are talking or presenting or discussing in the document is to preclude, in fact, it's really to help shape uh future standards work. So, make sure that we can surge surgically address them. Uh, you know, anybody here who's done some work on standards know that it takes a lot of time and and focus and effort, and and so the more focused we can be, the more likely we are to to succeed. Um, so a little bit of the motivation there. Um, and then okay, so how did we think about this, right? Where what was our thinking behind or or how did we approach this, right? What was sort of the simplifying assumption that we made? And one of the things and also why this is a discussion that we felt was relevant to WIMSE, which is focused on workloads, is that in the end, agents are workloads. It's a piece of software that is running somewhere. It may be acting on behalf of a user, or maybe on behalf of another agent, or maybe all by itself, right? Much like we used to have batch jobs that would run. Um, it interacts with one of these large language models, which is sort of where the whole sort of mission planning process takes place and the the model figures out which tools the agent should go talk call, and then the agent sort of calls the tools and services and resources and does this in a loop until an exit condition is kind of reached, right? And so when you start looking at it that way, uh it turns out that um if you think about agents as workloads, uh it gives you a really good basis to start thinking about what existing standards you have, or we have, and then we can reason about what might be potentially missing. Um, okay, so what did we put in this draft, right? So, one of the interesting things about this draft is it is really uh it provides a framework, but it really invents nothing new in terms of new uh new standards. Um, it really maps a bunch of the existing, mainly IETF technologies to a set of capabilities that we typically need when we are thinking about an identity stack. Uh, and so this is this idea of an AI or agent identity management system, which really sort of requires these different uh technical capabilities. Uh, does there are probably more, but these are the ones that sort of helps reason about the identity capabilities or identity properties. And so, the specification itself uh talks about identifiers and what standards are out there in WIMSE, in the Cloud Native Computing Foundation, that is already widely deployed and that can be uh can be used. Uh, we also talk about credentials, the different kinds of credentials. Um, JWTs, X.509 certificates, workload identity tokens, right, another product from the the WIMSE working group. Um, and then we talk about the provisioning step, right, which is sort of very much aligned with the WIMSE architecture. But this idea that there is some kind of posture assessment, uh some sort of collection of evidence about the state of the workload or of the agent before ending up provisioning an identifier and a set of credentials. And then we talk about the existing set of standards that can be used for authenticating that client uh or that agent with uh uh different services, right? Service-to-service or uh also to authorization servers, of course. And of course, once you can authenticate, now you can get into the process of authorization. And so, we also include a section on on authorization, specifically uh on the ways around how some technologies like OAuth can be used. And of course, the other thing of course, the the reality is uh authorization um these things are dynamic, and so monitoring, observability, and remediation, right? Uh, the authorization state may change over time, um and having some kind of set of standards or capability on how to react to that. Um, not going to talk too much about the policy and compliance legs. It's really more about, you know, for every one of these things, there's going to be basically a uh a configuration, right, a policy. And on the other end, you're going to end up measuring and saying, "Well, how are you doing against that?" Right? And that's kind of where you sort of get the compliance piece, right? Are you complying against the policy? But it's really this sort of central stack, right, the identifiers through to the monitoring and observability piece, where we already have a lot of great standards that uh we can uh start using for agentic use cases today. Um, and of course, as we wrote this, we also sort of it became clear where some of the gaps are, and um I think Yaroslav and Brian and and Jeff will talk a little bit more about about those. So, that's what's in the draft. Um, you know, one question is, okay, so, you know, the the too long didn't read do read version of this is, so which specifications, which family of specifications, are we drawing on? And so, it's really this combination of SPIFFE, WIMSE, uh OAuth, and the Shared Signals Framework, uh that is sort of brought together in this document. And we sort of give a framework for how they all play together and how you can use them together when when you're solving one of these uh uh problems. So, uh with that, um I'm going to hand over to Yaroslav, and I'm going to go off screen. And Yaroslav, please tell me when you need me to forward the slides for you.

Yaroslav Rosomakho: Absolutely. Thank you, Pieter. Hello, everyone. Um, so I will cover few uh sections of our uh management uh AI management system that we are describing in this draft. So first, it starts with identifiers. We do need to have a way to bring identifiers to those uh agentic uh AI uh things. Um, so this is obviously foundation for authentication, authorization, delegation, and audit, and as we have discussed on WIMSE meetings many, many times, uh workloads need to have stable, verifiable identifier. So, the proposal here is very straightforward. WIMSE identifiers, and in many cases, SPIFFE identifiers as a subset of WIMSE identifiers, work really well as identifiers for uh agentic AI regardless of what is uh this agentic AI in terms of where it's it's on the network, it's on the potentially end-user device, it's in the SaaS cloud. WIMSE identifiers are quite versatile, and uh the path section could be uh adjusted depending on or construct of the path section can be adjusted depending on specific uh deployment uh scenario. Um, next slide, please. Right. So, of course, identifiers is the foundation for credentials. Authentication and authorization needs to rely on the credentials, not just on the bare identifier, so agent needs to prove cryptographically that it actually owns that identifier. And again, all the WIMSE constructs that we have been working on uh as part of S2S proposal uh project work really well into agentic AI space, so the WIMSE workload credentials and potentially SPIFFE uh suites also work well for agentic AI with uh all the that can be used as the foundation for authentication mechanisms. So, identifier alone is obviously insufficient, and those short-lived uh credentials uh allow agents to authenticate themselves to authenticate themselves to other agents, to LLMs, to uh tools, services, and resources that they need to access. Um, next slide, please. Provisioning. So, provisioning of course on its own is very infrastructure-dependent. Um, so methods that are available for provisioning and any kind of posture assessment when provisioning is happening, that is that platform is the right platform, does it have all the latest operating system patches and updates, is it indeed our platform not some kind of rogue device, that all uh typically happens during provisioning. But as I've said, details of uh that provisioning is very uh platform-specific. Uh, so there are uh there is a methodology that is developed inside SPIFFE that we mention in the draft uh that allows automated uh short-lived uh runtime provisioning, but I would expect that in many concrete deployments of agentic AI provisioning will be very much platform-specific. So, if, for example, agent is operating on the end-user device on managed enterprise Windows, Mac, whatever, then uh most likely some kind of uh proprietary UEM or MDM uh would be used for as a part of provisioning and posture assessment process. Uh, next slide, please. Right. And uh finally, authentication, another construct that is very uh should be very familiar to this working group. So, agents need to authenticate themselves, that is to prove that they have indeed identifier that was assigned to them um with cryptographic proof. They need to authenticate to tools, services, resources. They need to potentially authenticate to LLMs. They need to authenticate to other agents, um and yeah, we obviously here proposing to use all the WIMSE authentication mechanisms that have been developed in this working group, HTTP message signatures, uh WIMSE proof tokens, and uh potentially MTLS, and particularly highlighting the anti-pattern of using static uh pre-shared uh credential or API keys that sadly are very often used in the agentic AI space, especially when it comes to access to uh LLMs. With that, I would like to hand it over to I believe to Brian. Brian, why don't you take us through the most exciting part?

Brian Campbell: The most exciting part. Thanks, Yaroslav. So, there's authorization obviously plays a big part in agentic-style deployments, and any deployment, but especially agentic. Um, but not just authorization, but very specifically delegated authorization, which is something that OAuth provides uh already relatively nicely, uh depending on your perspective. It certainly provides it and has done for so long. So, delegated authorization allows for the expression of what an agent can access, whether or not it's acting on behalf of a user, typically it is, um whether it's acting on the behalf of another agent or itself, and can do so all subject to the policies of of the resource provider. OAuth enables a user, an end user, person, human, to authorize an AI agent to access specific resources or perform certain actions on their behalf, but does so without exposing those user's credentials to the agent. And it enables or allows for, you know, conveying this information, which enables the determination of whether the agent is permitted to invoke a given LLM, a certain tool, resource, or or other service. And how this all works, um is kind of a maze of items in OAuth, although they're defined and many are standard or on their way to being a standard. Um, described some of them here, but ultimately the idea is that um this document provides a bit of a road roadmap about how to achieve certain use cases and certain functionality using the underlying constructs of existing OAuth mechanisms um and provide a facility and and guidance about how to accomplish certain use cases in the hopes of um both reusing and pushing to existing functionality, um where where needed, and possibly then to like providing a a roadmap of existing standards and functionality that is better suited to identify potential gaps or areas where additional standardization work is needed rather than, I think as Pieter said, uh avoiding the sort of cut from whole cloth, let's build it from the ground up uh types solution, and that frankly we're starting to see more and more of. So, a lot of what comes in OAuth is we have this standard OAuth 2 framework, um including and especially the authorization code flow, which is the end user involved delegated access flow, and client credentials, which is a facility to do um authorization directly to and on behalf of of the client or the agent itself. There is uh JWT-profiled access tokens, as well as introspection, which are just facilities to um already deal with and define various ways of profile-specific or deployment-specific needs around how um authorization tokens are actually represented. There is an entire um body of work in and it's a very significant body of work defining security best practices on which uh a lot of folks have contributed uh a lot of time and effort, both um theoretical, academic, as well as deployment experience. Underline that um despite the the simplicity of all this or apparent simplicity of it, there are quite a bit of security type edge cases that can arise, and there's been a lot of work that's gone in to help securing those things into the OAuth space itself, and we seek to, you know, sort of stand on the shoulders of those of that work and benefit from that rather than um throwing it out, if you will. Uh, there is RFC 7523, which we have here listed as the JWT authorization grant, which is uh facility uh to do to convey user authorization across trust domains, but leveraging an existing trust relationship between those domains to facilitate sort of a non-interactive delegated authorization experience, um which is important for a lot of use cases, particularly those where uh like an enterprise workforce might be involved or where there's um contractual type relationships where services are accessing each other across trust domains, but in ways that are um either implicit or transparent to the end user and direct end user interaction and approval is not necessary, rather it's implied. Also in that RFC are some um mechanisms for doing um asymmetric, not long-term uh shared secrets, but asymmetric client authentication, so that that spec provides that as well. Um, token exchange is a very abstract um but useful framework for exchanging one token for another, sometimes multiple tokens in and for one token out. Um, it it is very open-ended and um kind of comes with the curse of solving a lot of problems while not it's not directly solving any on its own, but can be profiled and deployed in ways that are very useful, which brings us right into uh the following item there, the I'm going to struggle to say it all, the identity chaining basically. OAuth identity and authorization chaining across domains, which is itself a description and profile of using token exchange to acquire a token sufficient for the JWT authorization grant, basically linking the two together and describing what is a fairly common pattern for obtaining locally a token sufficient to go cross-domain in order to acquire an access token for uh resources at a at a third party or external domain. Um, and then building on top of that is the uh identity assertion JWT grant, we have some great names, but they're still really useful specs. Also sometimes known as cross-app access or ID-JAG, and this itself is a more narrow and tightly-specked um profile of identity chaining, which describes how this relationship can be achieved um to go cross-domain for cross-domain resource access when there's a specific set of trust relationship set up, uh depending on a single IDP, um single enterprise IDP IDP serving SSO access to two apps, uh where one of those apps is potentially some kind of um AI agent or or chatbot type system. This allows for sort of um what we've started calling um API uh SSO. And then also um arguably this work should have been done here in the um in the WIMSE group, but it it for reasons, uh good or bad, it ended up happening in OAuth. Transaction tokens defines a way to sort of convey user and um external client and authorization and context information through the call chain of backend services within within the system, within a single trust domain. There's a lot of different pieces there, all of which are very useful, and we endeavor within this draft to describe how to put them together and use them. Um, that's right, Pieter. It didn't exist yet, so it was a sort of those were some of the reasons, matter of timing. Um, so all areas we we try to describe and explain how they they can be used effectively for token issuance and management, where specifically that's token issuance to uh agentic AI systems. Um, one area we also are looking at, certainly comes up a lot in agentic discussions, is so-called human-in-the-loop. Um, I like to remind people that the authorization code flow existed, and that exists, and it's sort of the original human-in-the-loop, um where the human is uh authenticating and approving the access to whatever the requested access is. Um, it happens to be very early on in the loop, but it is definitely the human-in-the-loop. Uh, CIBA, um and uh MCP user solicitation also come up, but we are They often come up as proposed solutions when the idea of asynchronous approval is needed, or at least perceived to be needed, although turns out that the message flow and structure of CIBA doesn't actually map very well to how that would occur. Uh, CIBA itself is client-initiated, and that that doesn't necessarily fit very well when you need some sort of mid-execution human approval. Um, so, there's some words in there, but they're largely acknowledging that this is um a bit of a gap in the the structure of the specs and ecosystems currently. I think there's a argument to be made that it's not actually a standards problem, but that these sorts of um latter stage human approvals might be better suited at the application layer, uh but there's arguments to be made the other way. It is an area where this work has sort of helped uncover a an area of potential um work necessary, at least further discussions necessary where we don't quite have all the pieces to to address things. And then there's a lot of work around metadata discovery and registration, um that that really just ways for the various uh components in the system to describe their um metadata, for lack of a better way to say it, both the the authorization server can describe it what it can do, the protected resource, um or the tool can describe what it can do, client ID metadata documents are uh an emerging bit of work in uh OAuth that is going to likely to prove very useful for more dynamic association of relationships between the client, the AI agent, and the um authorization server where it's going to request access later, and of course we have the long-standing um dynamic client registration work that that's been um codified in OAuth for quite a while. I said a lot of words there, and I'm getting the notification that my time is over. But, uh I think let's go to the next slide. I can't remember what that is. I think maybe we're going to give it to Jeff.

Jeff Lombardo: Yeah. Thank you, Brian. And I will try to be quick here because I see effectively that the time is over. Thank you. Uh, so if you understood all of it, uh you see that what we are trying to do is to really get uh the blueprint to get rid of those static credentials, whatever are the workload uh part or are the transaction time when we are consuming resources with everything that just uh Brian just uh told us about. Uh, so all those components uh as you have seen also can be like cross-domain into different uh bubble. And we want to be sure that if each of those components into the way that they are asserting the posture and asserting if the action that they have been requested out uh should be performed, they might do some risk evaluation onto that. They might see some things uh that is no longer accurate, that is maybe out of date, and might change the authorization logic at other places. And they need to communicate uh around those different elements. So, we want to be able to provide also uh this substrate uh to be to have this communication uh happening, and like Pieter said, we don't want to reinvent the wheel. There are some very good progress uh that have been made at the OpenID Foundation with the Shared Signal Framework, uh which currently has uh two very specific set of events uh that have been created, like the continuous access evaluation profile and the risk incident sharing and coordination uh profile onto that, so they both have like specific events that they have already formalized that can be exchanged onto what you are seeing, like for example, session has been revoked or credential uh has been has been changed uh for for a user. And maybe what we want uh to be able to do uh around that is also to see how we can serve uh the workload part. So, being sure that we can audit and we can communicate into anything uh related to a change into agent ID or a change of delegation subject, uh whatever like a decision is no longer accurate because there is like a threat intelligence signals uh that uh that is now contradicting a previous decision that uh has been made to be sure that if we need to reissue credentials, whatever to the workload by itself to be able to interact with resources, or to be able to act on behalf of the user, we can effectively revoke the previous iteration of credential and enter into a new cycle of evaluation for the issuance of new credentials. These things being said, uh passing back the mic to Pieter to talk about policies.

Pieter Kasselman: Well, actually, I think it goes to Brian. But, uh I'll quickly just talk about this um this slide. So, I think one of the things we did talk about or talk about in the framework is this concept of policy, which is kind of, here's your, you know, what is your configuration and rules, and then measuring against that, which is compliance. Uh, this is not a set of things that uh we're pointing to any specific standards. It tends to be very uh deployment-specific, but it is a sort of topic that comes up. And, uh I think again, this having standards on either side of those has been very helpful because at least now you know what you're targeting in terms of the policy uh when when you're getting to thinking about compliance with policies. Um, and then I think final slide, Brian, are you uh going to take this one?

Brian Campbell: I I mean you're already there, so go for it. But our I mean, now I'm talking. So, really uh next steps here and it's an opportunity to say next steps for before Vienna, because that's looming in our future. And uh have a lovely picture from Vienna here. But really what what we want to the questions we want to put in front of the working group right now, um is is asking if there's interest in pursuing this work. Um, and if there is, uh if there's interest in and belief that this working group, WIMSE, is is the right uh venue for that work.

Justin Richer: All right. Uh, thank you, everybody, for that. This is the uh the main question that we want to uh discuss today. Uh, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'd like to open this up for discussion. Um, so with our remaining time, um I'm going to turn it over to Yaron, you're up first.

Yaron Sheffer: Yes, thank you, Justin. Um, to to answer these two questions directly, it's it's a definite yes for me. I think this is very much in scope for WIMSE, should be in scope for WIMSE, and uh we'd better get to it as soon as we as a working group can. And I can say it in good conscience because as the the author team and me personally uh are working very diligently to complete the the existing uh deliverables. Uh, my main concern with this uh document is that section nine, or well, the interaction between the WIMSE stack and OAuth is not clear. Uh, the authorization section, section nine, reads more like a shopping list of standards, and I counted 14 on Brian's slide. And uh I think we would need to do a lot of work to clarify where WIMSE can stand on its own, versus where OAuth can stand on its own, and if the two need to interoperate, exactly how. Uh, so there's a ton of work in this document still, but I very much support it. Thank you.

Justin Richer: Flemming, go ahead.

Flemming Andreasen: Hi, thank you. Yes, so, uh definitely still very interested in this work. I think it's uh very interesting, very promising, very needed. Um, I think one of the main open questions for me would be how the work would relate to what, for example, the ACP group is going to be working on, assuming that that's going to get formed. I know there's been some discussions around that already. And and that relates to one of the discussions we had in an interim ACP meeting as well, and which is one of my comments on this document right now, which is I think there is a need for an overall framework and use case scenarios, so we are clear on exactly what are the kinds of mechanisms that we actually need. Like, for example, if we're looking at let's make sure that we cover multi-chained agent scenarios, is the identity mechanism that's specified in there right now the correct one, for example, or should we look more at using something like the ACT claim? I just as one example. I think that there's a number of different requirements that maybe haven't been called out explicitly, because there's a little bit maybe too much of a mixture in terms of saying we have all this machinery, let's figure out where how we can use it, and I applaud that, right? But I think that there is a little bit more work required in terms of taking a step back and say, well, what what are the actual requirements that we have for solution in this space? So, although those those would be my main comments.

Justin Richer: Thank you. Uh, before we go in, I want to uh raise a bit of context to everybody here. We are not asking if this is ready to go to the IESG for publication. We're asking if this is work is a a reasonable problem space, regardless of the solution proposed. If this is an interesting problem space for us to tackle with sort of this vaguely pointing direction, and if WIMSE is the right place for tackling that problem. There will be a separate call if we decide to tackle this problem space to adopt this draft as the starting point for that. So, yes, there are lots of problems in this document right now. I would expect there to be. Um, this is why we have a working group in order to work those out. So, keep that in mind as uh as we're looking at the comments. This is not expected to uh be complete or final, but if the problem feels like something that we want to do and the direction of approaching the problem is the right direction, you feel, or not, you know, uh plus or minus to any of these, uh please raise those in uh in this discussion. And also questions to to the proposers as well. Thank you. Go ahead, Joseph.

Joseph DeCock: Yeah. Um, so to answer your questions, um yes, I think this is important work to to pursue, and I think WIMSE is is a is a good place and probably the right place to do it. I mean, I see this as not like AI is certainly an important focus and we we want to stay um kind of focused on that. But this sort of thing of how these pieces fit together of authentication, authorization, identifiers, all of these things, is is this is a a big area, and um even, you know, any kind of workload system um AI-oriented or not, will uh will benefit from kind of a little bit more uh structure in this area, because there's a lot of options like we've seen, and and the document goes into like, well, you know, a lot of ways we can do things. Uh, but without some more specifics and a little bit more framework around it for these particular things, we we it's difficult to come up with solutions that interoperate and and are and are analyzable from a security perspective. So, yeah, I I support this as as something we should be doing.

Yaroslav Rosomakho: Um, as a co-author/co-editor, I I'm probably a little bit biased, but I do believe that uh this is a good fit for WIMSE, and this is an important problem to work on. Uh, one point I'd like to make is uh one of current documents in the working group that was BCP and now it's uh the uh workload identity practices, um I believe it's past working group last call, Aaron and I actively addressing points from Shepherd's review and few other uh suggestions that were made on the mailing list. Uh, so hopefully that will uh clear necessary space, and also I think it feels in the same kind of informational draft area specifying uh the right practices for people to reason with their workloads. Um, so uh hopefully that will help.

Paul Carleton: I just want to uh say I think this is a uh super important problem to solve, and I would love it if the um if the WIMSE group took this on. Um, from the MCP side, basically every conversation uh with with enterprises is asking about how do you uh want to handle agent authentication. It it means a bunch of different things, and I think that this draft starts to pin down the specifics of it and gives like a common ground to start from. I think that workloads as the starting point makes a ton of sense, um and like has a good foundation for uh to to build off of. It doesn't have to invent a bunch of new things. And then my my my one request I put in the chat, too, is just that I think for the delegation thing is if we can get extremely specific and have some example um deployments, I think that would help people a lot, just because if there's a lot of optionality there, uh things aren't going to interoperate and there's, you know, maybe a two or three deployment patterns that I think would be super common and and be able to um to cover a lot of use cases.

Brian Campbell: Yeah, so Justin asked to uh put my question to the mic, so so again, one of my uh main concerns with section nine is that it's not clear whether some use cases can be fully covered by the WIMSE stack um or whether I need OAuth uh for for some of the critical pieces of this architecture, no matter what. For example, if I want to call tools, if I want to use MCP and so forth, um in an intra-domain or inter-domain. So, this all would need to eventually be clarified sometime between now and working group last call.

Justin Richer: All right. I jumped in the queue because chair hat off on this one. Um, I think that uh one of the trickiest things for documents uh like this, for pieces of work like this, is making sure that uh it fits itself well with which use cases it addresses and which it does not. Um, leading with the uh assertion that all agents are workloads is going to simply invite people to say, "But actually," and give you a counter-example that doesn't quite fit. So, that said, work like this is very useful uh when framed as things like, "When your agent looks like a workload, which means the following things, this applies, and this is the set of things that you can do." And I think that that's a very powerful set of things that we can do for uh for a collection of work like this. Um, I do, seeing that the queue is empty, uh chair hat back on. Uh, seeing that the queue is empty, I actually want to invite our uh AD, who is on the call today, hello, thank you for joining us, um to uh to see uh your gut take on uh on whether this work sort of fits within uh WIMSE's charter and work program. Again, given the caveat that, yeah, we know we've got a bunch of stuff that we need to ship and is is close to shipping.

Charles Eckel: Yeah. Thanks, Justin. Uh, I'd say first of all, as an individual, I'm supportive of this work and I'm happy to see it being brought up here and, uh but also seems to me like WIMSE's a good place to work on it. Uh, with more of my AD hat on, um couple of things. One, like based on my read of the charter, this more or less falls into the scope and the spirit of the work group already, it's not like you're going off and thinking about doing, you know, something that's really orthogonal or quite different from what the working group's already doing, so I don't have any concerns there. I think it's uh, it's not clear from the work items that are specified in the charter that this would actually be one of them. So, I think that's something where it would be, while maybe not absolutely necessary, it would be helpful to the IETF community to probably add something there and be clear about what it's covering, what it's not covering, and including what you just alluded to there about are all agents workloads? We'd probably need a little bit of discussion there. And the alignment that I think it was Flemming brought up with what might be a new working group within IETF um on Agent Proto or ACP or however you want to look at it. So, I think we can hold off on doing that. I'm not worried about the work group pursuing this, there. But I think a recharter could be uh, to be very helpful. While perhaps not absolutely necessary. And I think there'd be a lot of support for that uh, with the one caveat that you also brought up that, hey, WIMSE needs to deliver on the items that are already uh ahead of this, right? Or that have existed before this came along, right? We can't just keep adding to the workload. Otherwise, we're afraid Sorry, the pun wasn't intended. Um, but, you know, we need to get things off the queue before we start adding more things to the queue, so keep that in mind as well.

Justin Richer: Yeah. We're uh we're good at managing a lot of workloads here, though, Charles. So, I mean, I think we're good. Yeah. That was That was fantastic. Um, thank you. Yeah. I had a similar uh as chair, I had similar take on uh on how this fits into the charter. Uh, I feel like it fits within our current working program, but is not specified as a work item. I believe in the process we can um we can add work items uh, specific work items without doing a recharter, but that's something we can figure out uh offline.

Charles Eckel: Yeah, I mean the work item's kind of like a milestone, and you can add milestones. Right. Exactly. Yeah, so, yeah, that's why I do agree it's like a little fuzzy there. So, yeah, we can work that out.

Justin Richer: Yeah. I yeah, I think that I think that that makes sense, and uh we would need to figure out as a working group what our intended uh landing point uh for this would be. Yaroslav, I think it was Yaroslav mentioned that this would be potentially an informational draft instead of a sort of standards and protocol draft, but that's one of the things that we would want to figure out. Um, so, Pieter, uh chair hat back on, and uh ignoring the fact that uh you're a co-author on this work, um where do you think that uh this fits?

Pieter Kasselman: Well, I think um so to the charter so, I think it actually does fit in WIMSE. I think the um the chart you know, our our charter and our deliverables, we do talk about best practices documents, right? And in many ways or practices, or and this is in many ways, right, it doesn't it's actually not inventing, very explicitly we're not specifying any new protocols. Uh, what has already happened is at least there's been at least two or three new drafts that's popped out as a result of this. There's a new draft on transaction token profiling, or not profiling, for cross-domain access, uh I know there's some work on human-in-the-loop, um and so on, right? So, there's already sort of new work falling out of this spec, and I think that's kind of, you know, it's kind of useful for people to then point back and say, "Well, here's the gap, right? We see that gap, that's a scenario that's not covered properly. There's work." So, I think it actually fills a very useful gap that way. Um, and you know, back and I think so, I I no, so I I think I read the charter similar to you and and Charles, right? I don't know that we really need to recharter. Right. And we can look at whether, you know, if this is a best practices type document, I think it fits. I also feel like we have the right, you know, we've interest, we have the right people, um good overlap, um it's a little bit of a strange document because it spans multiple working groups from from from different parts. But it's kind of the thing I think that's needed. Um, you know, now I'm beginning to sound more like the the editor, right? But I do think it's useful to have a place where people can anchor on.

Justin Richer: All right. I see we have Flemming in the queue, and uh yeah, any any additional feedback about uh about this landing, I appreciate all the uh all the words of support and, importantly, if anybody thinks this this is a bad idea, uh please speak up. This is just as important to hear. With that, Flemming, go ahead.

Flemming Andreasen: Yeah, thank you. No, just uh responding to to Pieter's comments and a few things that were just said. Um, are we presupposing that the work would not necessarily come up with any new proposed protocol machinery changes or anything like that, that it is purely restricted to just profiling what already exists? Because I think that that could potentially be overly limiting.

Pieter Kasselman: I would, from a pragmatic perspective, Flemming, I think, uh given the kind of attention that you need to put into a spec and how specific and deep something goes, you know, if we took all the specs that we talk about in here, we try to write one document, right? That is an enormous amount of text and very hard for people to navigate. Right. And I would and I think we also want to avoid necessarily saying, "Well, there's only like, you have to do human-in-the-loop, the this way," right? Like, there will be multiple ways potentially, or and then it also takes time, and it may be that some of that work is best done in other working groups. Um, so for example, well, let the transaction tokens may be a bad example, right, but the human-in-the-loop discussion may actually be very appropriate to go and have in the OAuth working group, because that is where, you know, because you're at this point you're beginning to deal with having to re-issue access tokens, potentially, right, depending on the shape of the solution. So, I I'm, um it doesn't preclude WIMSE from taking on other work or some of those work items, right? For example, the transaction token um, you know, the cross-domain use of transaction tokens, to Brian's point, right? Transaction tokens was always maybe a better fit for WIMSE. Um, maybe that's something that needs to be discussed and brought into WIMSE uh to progress in the future, right? Also, again, being mindful of the amount of work that's in WIMSE. So, I don't I don't think we want to do all work in WIMSE. I I'm very hesitant about becoming very detailed about a specific solution in this specification, because I think it becomes hard for people to parse um, as well. Okay.

Justin Richer: Um, okay, definitely appreciate that perspective, and that's a really good question, Flemming. That's something that the working group would want to wrestle with if we make a call for adoption of this document in particular, what's the shape of uh sort of the end result of a document like this that we would want to do. Now, we are just about at time. Uh, thank you, everybody, uh for uh for coming today, joining the discussion. What I'm seeing here today, Pieter, is a whole lot of support for bringing this, bringing this into WIMSE. Um, the chairs will um will start a thread on the list to confirm it, as is IETF uh policy and tradition, and um this is not going to be a call for adoption of this document yet. Uh, I think that we need to push a push a few more things to IESG, or at least shepherd review, um before we uh before we commit to a specific document, but I do want to record that there's interest in working in this, in the space. In the meantime, it is very, very applicable to use the WIMSE working group mailing list for discussion of this work and related work. We were explicitly chartered with that type of thing in mind, um and that that is We were very clear about that with our charter, um that uh discussing uh related work that does not necessarily live in the working group is very much on the table. Um, Pieter, any uh anything to add or close?

Pieter Kasselman: Of course, as chair, I'm conflicted because I I think uh doing a call for adoption, I think might help as well in terms of just helping to focus energy. Uh, I also appreciate that we want to get stuff finished and off our plate, and so, co-editors, co-authors, um and other draft uh editors, you're close, please. Uh, let's get this stuff over the line, and then we can start taking on new work.

Justin Richer: Yeah, and uh, Pieter, how about uh you, Charles, and I start up a uh a thread to figure out uh what we want to do for timing. I will uh I will start the thread to uh confirm the interest in the space on the list uh and get uh everybody's comments on there. And with that, thank you, everyone, for coming today. Thank you to the authors for uh proposing the new and interesting and uh very timely work. And with that, hopefully we will see a bunch of you in Vienna. Take care, all.

Pieter Kasselman: Take care.