Session Date/Time: 07 Oct 2026 16:00
[00:00:54] Justin Richer: Alright. We're seeing people roll in. Hi, everyone. Welcome to the WIMSE Interim. Fun fact, we had a WIMSE Interim on the 10/07/2025. So until about five minutes ago, that's what this title slide said because I copied them over from the last the last meeting without realizing that I didn't fix that... I didn't fix the year of the date. Speaking of things that haven't changed in the last year, I'm still one of your co chairs. Justin, this is WIMSE Workload Identity in Multisystem Environments, with our gloriously egregious logo artwork thing there. This meeting is covered by the Note Well. So anything said during this meeting is considered an IETF contribution, and everybody is expected to behave professionally, to treat people with respect, and to address the work and the discussion that we are having today. We have a whole bunch of stuff happening in WIMSE right now. We've got a few documents, on the way to the ISG. We've got, some things that are, sort of barreling quickly towards last call and a whole bunch of new work that's, being proposed in and around our forum. So I recommend everybody go follow along on our group website. It has links to all of the different resources for this group, including in flight documents, meeting transcripts, which this one will be up there as well once Meetecho kind of pulls all that together, which also as a reminder, this meeting is recorded like all official meetings, so that, that archive will be there available. Today, we have, Paul Carleton, presenting, and I do see him online there. Before we before we flip over to that, Pieter, did you have anything that you wanted to add before we kick this off?
[00:03:20] Pieter Kasselman: Alright. Thanks, Justin, for that intro. I think one thing to just add for folks here, similarly as we've communicated on the list, we're getting ready for IETF 121. So if you have specific topics in mind, please reach out to the chairs. This time around, we will have an... A WIMSE session, but there will also be another session, a joint Wimse- OAuth session. So some of the, some of the topics might be very specific that... Or there's sort of great affinity between these two areas. They both deal with different aspects of identity, and we would definitely encourage folks to submit proposals for topics for IETF 121.
[00:04:06] Justin Richer: Yep. Exactly. And when you're submitting that proposal, let us know if you think it's better fit for sort of the dedicated WIMSE session or the, joint session, or it could go in either. And the, the chairs of OAuth and WIMSE are working together to figure out what that whole list is gonna be. If you're on the OAuth WIMSE list, which I think most of us are, you'll see that, call for participation there as well. Alright. And with that, Paul, are you ready to go? Alright. Let me get your slides up, and then I need to... Give me a second. There's, like, seven different buttons I have to hit. Alright. You should have control of the slides. Just a quick reminder to everybody in the group, unless you are actively presenting, please keep your video and your microphone off. If you have something that you would like to ask the presenter, please join the queue. Paul, the chairs will help you keep an eye on that. But if you have... If you see somebody in the queue and you wanna just call them up, please feel free to go ahead. And with that, take it away.
[00:05:18] Paul Carleton: Great. Thank you, everyone. Thank you, Justin and Pieter. Yeah. My name is Paul Carleton. I work at Anthropic, and I'm gonna be talking about the workload authorization grant. Here, we had a beautiful picture by Brian Campbell from Vienna where we started the conversations about this this draft. So it's an individual draft that's from myself, Nick Steele, Aaron Parecki, Arndt Schwenkschuster, and Brian Campbell. We're gonna try to... It's not too many slides, so I think we'll try to get through most of them. And then I kind of put questions at the end, and we can we can flip back to different slides. We'll we'll see how that goes, and and may... Maybe we'll need to pause, but, that that was my my initial game plan. Okay. So what are we talking about? The motivating case for this, draft started from... You have a platform with several different agents operating on it, and they need to get access to some third party system. They're, you know, crossing a trust boundary. For the purposes of this, it's not very agent specific. This would apply to to any workload. Like, the motivating use cases was an agent, but for the rest of this, we'll basically just be calling them, workloads since, yeah, there's not not not anything super particular there, but we'll get into that. Okay. So the platform has these workloads. It wants to talk to the... Each of these workloads wants to talk to a third party system, and the the third party system wants to be able to tell those workloads apart. That can be for a handful of different reasons. The, one of them being audit logs to be able to say, you know, which workload took this action in the system, applying different policy depending on, attributes of the workload, assigning ownership to a workload, like, say, if it creates a resource in the downstream system, and then another another reason there might be billing, he might wanna bill things to a particular workload or apply apply different limits or or billing limits based on based on the workload. So a number of different reasons why the third party system would wanna be able to tell the difference. Wag aims to standardize just this part, the workload to the third party system. What is the they are the happens here. So not not, what happens, you know, in terms of, on the left hand side, what's going on with the workload, before it tries to connect to the third party system and then also on the third party system, kind of, like, what's happening after. And we're just trying to standardize this this arrow between them. And then a constraint we have on this is that we want there to be, you know, little to no setup per workload in order for... During this, like, connection to a third party system. And the reason for that is that the high friction, on this, if it was, like, a lot of work to set up, per workload, that means you sort of end up defaulting to a single shared API key across the different workloads, and then you're... You lose out on all that attribution, and and the benefits that we're, we're trying to get in that that previous slide. Okay. So we're talking about workloads. That's why we're we're here in WIMSE. It seems like the right place to to standardize. Great. And then, so briefly... Actually, Aaron, did you wanna talk about these ones, or did you want me to?
[00:09:04] Aaron Parecki: Yeah. I can talk about this real quick. So if you're not familiar with ID-assertion or identity assertion JWT authorization grant draft in the OAuth working group, we did tackle a similar problem for when people are logging into an app and using an app. This is essentially... It's it's it's similarly shaped in that it allows the the client, the OAuth client, in OAuth terms, to access a downstream resource without prior coordination with that resource, when in in the case that both of the both the client and the resource are federated to the same IDP. So it's typical in enterprise environments where there's two applications. One needs to access the other. They're both connected to the same IDP where users log in to both apps to the same IDP. So the... This has been... In the last several months, we've seen actually quite a lot of adoption of this in very real systems, and it's very... It's proven very useful. It's proven to now increase usage of the of the tools, usage of the apps, which is great. It is also referenced in the MCP spec, so it's meant by quite a lot of the authorization servers that protect MCP servers of various kinds. So the idea here is that... You go to the next slide. I don't have slide control. Yeah. So the idea is, this is this is just kinda showing the relationship of both of the, both client and the and the resource. Those are the two different domains. They're both federated federated the IDPs so they can both trust this artifact signed by the IDP. The... It's not relevant how this works, like, from the end to end flow, but the important part to the workload case is that, as far as the resource is concerned, the only thing it sees is a token issued by this IDP. So it's presented to the token endpoint. It it validates the token signature from the IDP's keys. How that token was obtained, is essentially the ID-assertion spec. And... But as far as the resource is concerned, a token is presented, and then it's expected to, issue its own access token for its APIs. So that is the part that we want to build on with this, to make it so that the work that has been done to support the ID-assertion spec and processing of those tokens is able to be reused as much as possible for when the case, in the case of these workloads where the, this token that's based... Presented is not issued from a user having logged into that app. Next slide. Yeah. So, the the ID-assertion pattern is, very explicitly for humans who have single signed thing SSO'd into an app, and that makes it... Like, it's it's fundamentally based on the fact that a user has logged in and the identity assertion of that user is used throughout the the chain. What we want to do with this draft is essentially mirror that, but when there is no user. So it's for workloads explicitly acting on their own behalf. So... And we we want to, again, try to change as little as possible compared to what has already been done. Well, sorry. Let me rephrase that. The the change as little as possible refers to someone who wants to implement this in their token endpoint. The goal is that it's very easy for them to add it to their existing OAuth servers that issue their own access tokens. And that was a very explicit design goal of the IDJI expect itself, which was, rather than telling... Going around telling everyone you have to implement a whole new spec and a whole new trust model, we say, take your existing trust model, take your existing access tokens, and just create this new way to issue your own access tokens. And that was... It was a very intentional design decision, and I think that was a very crucial part to the rapid adoption that we are seeing. So we want to mirror that pattern as well where we're asking people for this workload case to do, a similar similar thing where we're asking them to change how... To add a new method for issuing access tokens from their token endpoint and not have to, also bring in a, a whole new trust model. And Brian's comment in the chat, and that way isn't even totally new. Exactly. Yeah. That builds on RFC seventy five twenty three, the JWT authorization grant, which itself is not very new. So that's the goal that's the goal here. Next. Yeah. So I think that's back to you,
[00:14:20] Pieter Kasselman: Paul. Okay.
[00:14:25] Arndt Schwenkschuster: Some of you may think, oh, I've I've seen this before. It's often referred in some ways as workload identity federation, at least in some some parts of the industry talk about it. We do want... We don't want to boil the whole problem, and we just want to take the parts out of it that we believe are very interesting. Yeah. So similar to ID checks, we also looked into this workload identity federation pattern. That's how it's been called. And... Yeah. So this is very similar. You would have a workload and a platform issuer. Could be a cloud and workload. Could be a Kubernetes workload, whatnot. And a cloud token service and a cloud API where the workload wants to maybe access a cloud database. And the way this is commonly implemented is that a platform issuer would kind of deliver some sort of signed credential to the workload or bootstrap it with it. And the workload then presents that JWT to the cloud token service to receive a short lived credential. Many cases, it's in short lived access token, which which it can then access cloud APIs. So for example, AWS I'm roles, Google workload identity pools, or Azure managed identities are often implemented like this. And that's a very common practice. So we looked at those, and there's a couple of things that we really do like and we want to bring into this work. Next slide, please. So first of all, again, our RC7523 on the wire, the new, not so new standard. We believe that this is the right way to go. And that is the way... That is that standard the way OAuth intended it to be used, sort of. Charts issued by third parties used as assertions to receive access tokens. We also really enjoy central trust establishment so that an admin actually establish trust between two identity providers in a centralized way, and that is then reused on the individual entity level. This way, you have as an admin control over it, and it's not something that, in some ways, workload developers do on a day by day basis, but it's like admin trust establishment. Obviously, we need to have some way to discover signing keys of individual parties for that OpenID Connect has been kind of the standard the industry has been using. And last but not least, but also very important, is that there's patterns where access is given to issue subject combinations so that when you use Workload Identity Federation to a target system, you don't have to create separate entities in the target system for every separate workload. So in that case, if there is a final workload that just spins up, it can directly access something without having to assume another identity which needs another life cycle. And this is something, as Paul said in the beginning, it's kind of a constraint that we have because particularly with agents, we see those ephemeral workloads becoming more and more a thing. And we don't want to create a management burden out of this work.
[00:17:43] Pieter Kasselman: You're on mute, Paul.
[00:17:58] Paul Carleton: Thank you. So with all that, with the the IDJAG and then, looking at the WIF patterns, we drafted this workload authorization grant draft, which I'll walk through now. The... Similar to before, we have the establishing trust, between the Wag issuer and the resource. This is done once, and you register, register the issuer. The workload gets a Wag from from its issuer. It sends the Wag token... Sorry, the the Wag to the token endpoint, and then it gets back an access token. And then it can call that, call the API, the resource entity, whatever it is, with the with the access token. The shape of the token itself is... Has the issuer of the platform. Subject is the individual workload, so that would be different for, each workload. And then the audience is the, is the authorization server. And then out of scope of this, we have, you know, like, how the workload actually gets the WAG. We're leaving out of of this draft the specific claims that the the WAG used to send attributes about the workload, and then any sort of fine grain author... Authorization. We're we're not trying to tackle that as part of this. We're just trying to standardize this sort of green arrow, in the middle there. Great. So that was whirlwind tour. Big question for this group and and for this interim is, like, is this is this a problem for WIMSE to tackle? There's a couple of topics to... That, if we were to adopt it and work on it in Whimse, the, weather, like, claim mapping, tenancy, IDPs, all that stuff would be good to discuss. But the the central question we have is that that top level one first.
[00:19:55] Justin Richer: Thanks, Paul. Just jumping in his chair here. I would like you to be as precise as you can about the, antecedent for this problem, that we're talking about here. We talked about a few different things and a few different technology solutions. If we are asking the question about the problem, I wanna make sure that the question is in fact focused on the problem, not focused on, and is this a solution for that problem? Because those are two separate ones, and I wanna make sure that we are clear on that.
[00:20:24] Paul Carleton: Got it. Yes. You... I think the the the problem statement I'm I'm describing here is, many different workloads wanting to be identified in a third party system without a whole bunch of per workload setup. So is that is that the problem for for WIMSE to talk? Is that is that
[00:20:48] Justin Richer: Yeah. That works for me. I was making sure that made it into the notes. You've got a few folks in the queue. So, Jiyun, I think I got that right.
[00:20:57] Jiyun Yao: Yes. Hi. This is Jiyun. I'm from. I work on a different team, like, trying to do autonomous agents. And so what I want to say that, like, I... We find, like, a lot of customers want to have autonomous agent, and they want to differentiate, like, say, the autonomous agent, like, say, with the user's intention. Right? So, like, there are agents impersonating the user using the user's credential, and then there are autonomous agent who are finding the problems, proposing a solution, taking actions by themselves. So I think, like, I I I would like to see more, like, say like, say, we we we we are solving this kind of issue. So I think WIMSE Like, say, like, say, whimsy and also, like, the WAG, in my opinion, I think is the right direction for us to do that. But, also, I would like to see others', opinions. I do hear a lot of, like, customers are got, likes a concern. Right? So, like, especially when the agent are using user's credential. It works, but, it also, like, say, make it hard for the, like, say, for the admins to differentiate and to set a proper, like, say, and etcetera. But on the other hand, I think I do have one question. That's how are we going to have, like, this is not only, like, you know, the the the one party problem. This is multiple. There's also the agent provider. There is also the the the the the SaaS providers and etcetera. Like, they also need to adopt this kind of stuff. Right? So how we plan to... Or or I I want to see if there is any, like, say, thinking around that. And, also, I want to see in the room, like, if there are other people, like, try... And, like, say, thinking this is the the the the direction we should go, and would that be helping us?
[00:22:54] Paul Carleton: Yeah. Thanks thanks, Jiyun. So, yeah, I think the the idea of, yeah, autonomous agents, like, things separate from from humans being being important and important to do in a low friction way. And then, yeah, I think we'll we'll see from the other folks in the call if they're... They also align with that. Cool. Flemming?
[00:23:21] Flemming Andreasen: Yay. So just sticking strictly to the question at hand whether this is a problem for him to see the tag. Yeah. I think it is. Right? I think we've seen examples of some of this work already in the spiffy space. Right? There has been some drafts that I think are basically touching on the same thing, and I think this generalizes it into a number of different platforms, which makes a lot of sense. I I do agree with the previous speaker that there's definitely a user element to this as well. So maybe the scope needs to be expanded a little bit. I'll refrain from getting into the specifics, some of the technical issues, but there's definitely, you know, some some namespace concerns that I think we have to consider. But we'll we'll leave those aside for now. But, yes, again, I I think this is definitely a relevant problem for this group.
[00:24:10] Pieter Kasselman: Awesome. Thank you, Feli.
[00:24:17] Paul Carleton: Sean?
[00:24:22] Sean O'Dell: How's it going? I... Oh, third, fourth, fifth is... We talked about this in Slack, Paul, many, many, many times. June... The the the assistive agent use case versus autonomous, it's an 80 percentile we're tackling right now because enterprises are moving a little bit slower than than than Frontier Labs. Assistive is now where the new focus is right now. So I'm literally talking with a bunch of vendors and practitioners about it, but smashing in an actor claim into this is, like... It's so essential, and it has to be done before anything happens. So I'm... I can talk about it offline, have everyone talk about it, but it's an active problem that I think I solved yesterday. But reading Paul's WAG draft, I'm like, yeah. K. I'm seeing how it coalesced. So I'm totally in on this. This is actually really exciting, so I'm pumped.
[00:25:20] Paul Carleton: Nice. Thanks, Sean. Yeah. I think the the way we've been thinking about it in, the draft so far is we haven't gotten into act actor claims or anything like that. And I think the... So it... Mostly as, like, a... I think for... As a building block for any of these, I think we need an identifier for this workload to be available, which just seems like a very first step, and then, those other things become a little easier.
[00:25:44] Sean O'Dell: Same thinking. I mean, exact same thing. Exact same. Yeah. Thank you.
[00:25:49] Pieter Kasselman: Mhmm. Thanks, Sean.
[00:25:53] Paul Carleton: Alright. Nate?
[00:26:01] Nate Barbettini: Got it. I... Sean actually just said pretty much everything I was gonna say. I... I'm really interested to see in a, like, plus one to this work. I think this is an important problem to solve. I do think that solving or at least having a path to solve for identifying the workload or, in this case, identifying the agent is an important thing to include. Not... I I know that that's also, like, outside of this group. That's, like, kind of a big open unsolved industry problem as Sean alluded to. It's like a lot of people trying to solve that particular problem. I don't I don't think that this proposal needs to be burdened by, like, solving that for every case for everybody, but having an opinion on how the workload gets identified in in, like, a robust way, I think, is important for this. But I'm sure you're already thinking about that.
[00:26:58] Paul Carleton: Just the... When you say identified in a robust way, do you mean, like, to hardware or to, like, a human or which? I think I might have missed part of it,
[00:27:10] Nate Barbettini: I'm not thinking about identifying it to a human in this case because I think I think it's actually important to separate those cases even though they can compose. I think it's important to say we have... In in Wag, for example, there's a way that we're talking about the workload getting a token. And then separately, there also are many cases like assisted assisted agent cases where the agent is acting on behalf of some human, and so there's maybe existing patterns for getting a token or or identifying that the the the action is on behalf of a human. I think that that can be probably separate, but it seems to me like the scope of this needs to include or at least have a path for, how the workload is identified.
[00:27:57] Paul Carleton: Like that... The... If I go back, number one here. Is that... If I do? Correct. Yes. Yeah. Yeah. Correct.
[00:28:06] Nate Barbettini: Correct. I'm I'm particularly interested in, like, what what is that sub... What is the contents of sub look like? Is that just free and open text? Is it is it something else?
[00:28:18] Paul Carleton: Cool. Yeah. Yeah. That makes sense. Yeah. So far, we've said sub is just opaque, but, yeah, I think it'll be interesting as we, as as we, try it out more.
[00:28:28] Nate Barbettini: That that could be sufficient, but I'm I'm... That's the part that I'm particularly interested in pulling on the thread.
[00:28:33] Nick Steele: Cool. Cool. Thanks. Okay. Pete?
[00:28:40] Pete Resnick: Yeah. So, and part of this, I think, is getting answered in the, in the chat, so you can take a look there. But, I'm sort of new to the space and trying to get my head around the scoping. Can you talk in terms of the aims draft, like, where this fits in? People have been kind of identifying the agent obtains authorization section. But are there other parts that you're taking on here, or is it a limited part of that? I just kinda wanted to get a sense of, scope.
[00:29:13] Paul Carleton: Yeah. So, originally, this was, like, trying to be... Or we had framed it as a profile of AIMS, but that just didn't seem appropriate because we weren't actually super dependent on AIMS, and so we took took that part, out. But the, this is, I think, very, like, kind of copacetic with the ideas in in AIMS, and it's it's just trying to... I think the scope... Now we're trying to figure out is just this this arrow from workload to the the resource authorization server, not necessarily how does the does the workload get that. Like, I think that could be, you know, it could be spiffy. It could be, like, a whole lot of things happening on that side, that, don't necessarily... Like, the downstream resource server doesn't necessarily need to know how that happens. So we're just trying to specify sort of, like, the minimal piece that we need for interoperability between these
[00:30:03] Pieter Kasselman: two
[00:30:04] Paul Carleton: systems. There is, like, a whole lot to happen on on both sides, I think, outside of this, but this was Yeah.
[00:30:10] Pete Resnick: I mean, part of the problem sort of across all of the working groups in this space, is they wanna... And I think at a reasonable level, carve off a really little piece so you don't try and boil the ocean. And I'm trying to kinda figure out, is this smaller piece worth doing alone, or should we combine it with other bits and and expand scope a little? But I I totally get the instinct to... No. No. No. No. Just one little bit, and we'll do something else somewhere else. So I... No. I appreciate it.
[00:30:46] Arndt Schwenkschuster: Thanks, Pete.
[00:30:48] Pieter Kasselman: Go ahead, Yeah. Just as a follow-up, I I commented in the in the chat as well to Pete's question. I see this work as highly aligned with AIMS. It fills a very specific gap a specific... It adds additional detail to a very specific part in the AIMS specification in that, authorization, block, specifically around how the agent obtains its own authorization. Right? So today, there is sort of a sentence or two that talks about, oh, you can use an authorization grant to do this. This specification actually, I think, brings a lot of clarity and specificity to that. And it's act... It's it's sort of exactly the kind of thing that we would like to be able to do with AIMS is sort of reference to and say, oh, go read the WAG draft because that's that's the thing that tells you how to do this. So in my in my view, it's highly complementary.
[00:31:44] Paul Carleton: Thank you. George?
[00:31:47] George Fletcher: Alright. Can you guys hear me?
[00:31:51] Paul Carleton: Yes.
[00:31:53] George Fletcher: Okay. So I've not read it, so, this may be an inappropriate question. But it felt like as you were explaining it that the the draft itself is more a little bit like a framework for for the core ways that you would go about doing this, and the specifics are out of scope, which I think is fine. Right? It sets a a direction and so that things get done in a similar way. I guess my question is, if that assumption is correct, then have you given any thought as to how you want... How you would expect profiles of this draft that then tackle the vertical bits, a lot what Sean was talking about, like, hey. I need to extend the WAG draft to do specific assisted stuff, and here's all these extra claims we're gonna add to make that work. Like, how... You know, is there anything that we need to do in prep for that kind of a model? Because I suspect what we need for assisted might be different than the claims that would be needed for completely autonomous or or other, you know, cases that are outside the agentic framework completely. And, anyway, I just... It feels like if the goal is this to be a baseline and then we build profiles on top of it, that we should at least give a little bit of thought for how we want those profiles to exist and what to do when we get mutually exclusive profiles because that's likely to happen at some point.
[00:33:34] Paul Carleton: Yeah. I think the the... So the... These are... I feel like in terms
[00:33:37] Pieter Kasselman: of it, I don't know
[00:33:38] Paul Carleton: if it's a... I don't if I'll call it a framework or, like like, these are the kind of four bits that we are, like, the most concise summary of what we're trying to to standardize here. I think the, in terms of the profiles, I think the kind of what what you were saying, Sean was saying, I think adding claims from their... You know, like, the, token exchange draft as subs... Or a spec has about actor and subclaims, I think that fits nicely in as as long as we we don't say exactly how that works in this draft. And I think another, other things that I think could build on this, which is part of why I think keeping it, like, very tight, to just this... That, like, one arrow that we've been showing is, things like deferred token response could also work nicely, where if you are... Since we're just doing this flow, if you want to, take some other action before you get the token back, that might work nicely and and wouldn't need a a change here. And then the the other one is, like, if we want to profile how you get the WAG, since we're not specifying how it gets there, there could be a lot of different ways people wanna, sort of specify how exactly that happens. So leaving that open for for profiles as well. Cool. Is Peter up again, or are we down to June? I think we're at June. Okay.
[00:35:13] Jiyun Yao: Like, I I I... Please tell me if, like, this is not the right But, like, say, I I hear a lot of, folks are thinking this is important, and we talked about the details. But on the other hand, like, I'll be very honest. I think, like, in order to... For these to get widely adopted, it's, like, it's... Like, this is part of the solution. Right? So if we go to the last slide, the... Like, post this work, and we do have other piece that we need to get done, like claims mapping. Right? So previously, we talked about, like, say, if we have, like, say, conflicting, claims and etcetera and also IDPs. I think, right now, like, say, when when I work with some of the third party vendors and trying to have them to accept a WAG, Like, one thing they ask is that, yeah, I also need to, like, say, yeah. This would help to identify and to get the access for the grants for the, for this agent, autonomous agent. But how do I know that agent, like, say, is retired? How do I know when should I clean up the grants and, like, the life cycle of the identity and etcetera? So I think, like, when we are trying to make this a reality, like, there is this kind of adoption and when when there is adoption, people require complete solutions. So I'm I'm I'm not sure if this is the right topic, and this is against the principles, like focusing on one specific topic and get it done. Right? So so this may not be the right topic, but I do want to bring this to the table to folks.
[00:36:56] Paul Carleton: Yeah. No. I think it's a fair point. And, like, I think on the the IDPs thing, I think the way we've been discussing it so far is is the... Leaving that as a potentially a separate document, but I think the sort of problem statement... What what is the minimum piece we need to address that that problem statement? It it could grow. I think, currently, we're we're trying to keep the scope as small as possible. But, yeah, as as we as we get more experience, we're, like, working with
[00:37:25] Nick Steele: them. Yeah.
[00:37:26] Paul Carleton: Agree. Those are problems.
[00:37:36] Justin Richer: Alright. Looks like we have... During the queue, there's some... There's a bit of chatter in the chat, but I'm not seeing any sort of big new topics here. Pieter, if I could get you to join on here. Paul, what is you and your coauthors intent for this piece of work? Would you like to... Yes. It is Copacetic in the chat. Thank you, Nick. Anyway, what is the, intent of, you and your coauthors for this work? Are you, bringing it to Whimse- to sort of follow an adoption cycle, or, you know, is this just kind of an FYI of work that's happening? Where would you like to see it go?
[00:38:26] Paul Carleton: Yeah. Happy for other coauthors to to chime in as well. But I think that from from my perspective, I think Whimse-y seems like the right venue for it since we are talking about workloads. And I think it, could benefit from, the folks here's thoughts on how to how to do this well and how to make sure it works with the the rest of the, drafts coming out of of Whimse-.
[00:38:54] Justin Richer: Alright. Sounds good. Looks like we've got Arndt and Brian in the queue. Arndt, go ahead.
[00:39:00] Arndt Schwenkschuster: Yeah. I also... I I believe it fits right into workload entity in multi system environments. Right? This is exactly our different... What we do... What we... What our... What WIMSE stands for. And it is a problem that has been around for a while, but just got much, much worse with agents. And it's a problem that I would love to have solved, at least on a wire level. Right? And this is this is what it is. And there is very interesting conversations, and I believe we can then all debate we can all debate those. And, yeah, that... Us is the right venue for that, in my opinion. Yeah.
[00:39:41] Justin Richer: Alright. Thank you. Nick?
[00:39:45] Nick Steele: Let's see if this works. Alright. Go on. Yeah. So I I do think WIMSE is the right venue for this, and I think it's incredibly timely proposal. I think we started talking about this in Vienna, and, I think Paul and I were discussing some of the same shared issues across Anthropic and OpenAI that could be solved with a token like this. So, you know, on the OpenAI side, we're we're we're, you know, also interested in being able to have this workload of the... Grant that identifies workloads strongly and also allows people to bring bring their own workload identities, you know, to to to Sean to Sean's point and and, you know, to Jiyun's point. Right? It's like I I I love... I I haven't seen... You know, because we're just discussing this now, I haven't seen any working examples of this. But I have seen this... I have seen problems shaped shaped like this that would be filled... That this would be a a a solution for. And especially, you know, I I think we touched towards the beginning, right, that there's kind of, like, these two emerging types of agents. There's the... There... There's this idea of, like, per... You know, personal assistant agent, something that is more persistent along with... That might be managed by us, that might be managed by a user that might exist on a user's device at some point. You know, I think that there's lots of different deployment structures for this. But in all cases, these present themselves as a as a workload identity. And I think that this is gonna be incredibly necessary to manage, in in enterprise context to... You know, not not just from, like, the the access perspective, but, you know, it's like, now you have Muse, Dots, lots of... What's the... Instinct. You have lots of agent platforms that are that are basically saying, like, hey. Not only are gonna have a workload, but that workload's gonna have access to a a, like, VM. And it's gonna go do things on computer, and it's going to need to access other things through through that that interface given to it. So I think that there's lots of ways for this... For for, like, this this grant to be used and and and, enable the agent to to to perform, tasks within within the... Its own given environment and with external resources as well. So I think this is this is a pretty, like, you know, discrete start to something... To to to to approaching the problem. And when it comes to things like scoping, issuing, who who represents the identity and and sort of, like, the life cycle of this, I I, you know, I I I don't think we necessarily need to punt on these, but I do think that there are already, solutions emerging to fill some of those gaps in interesting ways. And this can really meet to to, meet meet those solutions as well in in parallel.
[00:42:27] Justin Richer: Alright. Thank you. Brian?
[00:42:30] Brian Campbell: Sorry. I jumped in and out of queue a few times because I couldn't decide if I had something actually useful to say. Usually, I don't, but I'll try. Building on just some of that a little bit, I... Your point about, like, separating the problem and solution space is is totally valid, Justin, but I do think it... It's hard to do sometimes. As it relates to this, though, I think there's definitely a problem here that's worth looking at. The area that makes sense to look at it, I do believe, is WIMSE for reasons that have been said many times here. And there's a direction of a solution space in this document that builds on OAuth and slots in to existing stuff in a way that we think is an appropriate, like, way to look at solving the problem. And so the the idea of bringing that work to whimsy even though it's sort of based on OAuth solution space feels appropriate. And, you know, without presupposing a solution, there are some pretty... Like, there's been quite a bit of thought into the solution space that's being proposed here and both where it where it manifests and what it's based on. So all all that's to say, like, I I think we are interested in in having this work in this shape more or less adopted, but doing so in this working group even though it's sort of based on large part output of of previous work from a different working group.
[00:44:20] Justin Richer: Alright. Thank you. Alright. So with that, I'm gonna kick Nick out of the queue. I I am going to put up a quick show of hands. I will say that we've gotten pretty strong, you know, feedback here so far for this is an interesting problem space, and Lindsay is an appropriate venue. So I'm going to ask what I don't normally do, and that is a combined question, and that is, are we interested in the problem by this, targeted by this document and this document as a starting point to address it? Because I would like to capture the directionality of that. If people, cannot answer that, with a yes and that needs to be broken down more, I would like to know why. So I'm going to, put up that poll now. Let that run for just a minute. Oh, good. I didn't see anything coming in. I thought I hit the wrong button.
[00:45:24] Pieter Kasselman: I hit the wrong button. You will have to put
[00:45:26] Justin Richer: it up again. No. It's... Is it still up, or did Peter... I'm still seeing things come in.
[00:45:32] Pieter Kasselman: Oh. It's still up. I thought I actually thought I terminated the poll, so luckily, didn't. Excellent.
[00:45:41] Justin Richer: Yeah. There's, like, a hide poll and terminate poll button like that. I swear the MeetEcho buttons change every single time I use it. Alright. So we've got 21 people on the call, 15 responses so far, 16. So... Okay. I am going to... Yeah. I'm I'm not seeing any nos right now. I'm seeing a lot of yeses, a couple of no opinions. I'm going to to terminate this poll. Thank you for everybody. As always, the IETF does not vote on things. This is just to gauge direction and sentiment. Any official calls will happen on the mailing list. But as chair, I can say that I am seeing very strong support from the people who decided to show up for the interim today. That is, of course, not necessarily the whole working group, and this will need to be a wider conversation. Peter and I will, will need to discuss, as chairs whether, the working group has the process of bandwidth for something like that right now, as we've been discussing for a while. Y'all gotta finish your other documents first before you get to have the new ones, but that is happening. We do have things moving forward. So, I, you know, I I I I think that, you know, we... We'll have to talk to our AD who I don't think is on today. No. I'm not seeing him on. And so... Yeah. Just because we've had so many documents sort of in flight, we would... We wanna make sure that we are we are in fact delivering things before we take on new work here. So let this be additional motivation for everybody working on the currently in flight documents. But I will say that by my read, Pieter, we seem to have very strong support for not only this as a... As an important problem space for WIMSE, but also this document is the direction for it.
[00:47:53] Pieter Kasselman: I agree. I think, Paul, thanks for bringing this to the working group. And to Brian's comment, I think... Does... Is that a commitment, Brian, to have all the specs done before 01/27?
[00:48:07] Justin Richer: That's how I'm reading it. Yes. So, yeah, Brian's Brian's gonna finish all of the the documents and, yeah, we'll be fine.
[00:48:16] Nick Steele: K. So...
[00:48:17] Pieter Kasselman: So, yeah, I think then, Justin, maybe we should... Like, let's let's discuss about what call for adoption potentially looks like and whether that's a pre IETF 121 or post IETF 121 discussion. But I I feel like there... It seems like there's really strong support for this work.
[00:48:34] Justin Richer: Yeah. With that in mind, Paul, I'd like to gauge your interest. The the call for presentations just went out yesterday or today. Do do you think that... I would say that there's a clear interest for, presenting this at IETF 121. One, will you be, will you or your coauthors be available, to do so? And if so, which session, either, the pure whimse session or the joint WIMSE session, do you think is more appropriate?
[00:49:05] Paul Carleton: Yeah. Good question. I'm aiming to be
[00:49:08] Justin Richer: This is nonbinding. Don't worry. So
[00:49:10] Paul Carleton: Yeah. I'm intending to be there. Some scheduling constraints there, but I think if not me, I think I'm sure we'll be able to get one of the coauthors there to present. It seems like maybe the Whimse-wimse plus OAuth one would make sense. I I haven't discussed this with the the other folks. So that... But that would be my, like,
[00:49:31] Pieter Kasselman: major. Okay.
[00:49:34] Justin Richer: Alright. We'll we'll keep that in mind when we're when we're slotting all the presentations together. And like I mentioned before, we've got a we gotta sync with the AD to make sure that we're not, taking on too much new work too quickly. But, I I see a call for adoption for this in, in sort of the near future to... Whether that's before or after 01/27, I'm I'm not sure because we're coming up to deadlines pretty pretty quickly here. But... Yeah. I I would encourage the authors to continue to iterate on this, continue to discuss it on the list. Seems like we've got a lot of people excited to what this could be. This this can continue to happen before working group adoption to kind of refine it, especially refine the problem statement, which helps with the the adoption call for sure. And, yeah, that's kind of where I see this, Pieter.
[00:50:30] Pieter Kasselman: Yeah. And I I actually wanna just check-in with the authors as well whether there is a preference on your side for... Would you... In terms of getting a call for adoption out, is there a pressing need for one? Or, like, how how do you think about the... Having the document formally adopted?
[00:50:55] Paul Carleton: I see. I'll let I'll let you all go. Go ahead. I have talk to him.
[00:50:58] Pieter Kasselman: I see lots of people popping on. So...
[00:51:00] Nick Steele: Yeah. No. I I think I think it's a good good spot. I I think we can we can we can sync async on the the the state of it. But, ideally, yeah, this stuff moves very fast. This this space moves very fast, so the the the more... Like, the sooner we can make progress on on this and and have this adopted and should, you know, sing... Signal that for for moving this direction, the better on my end for... With technical and political.
[00:51:38] Justin Richer: Yeah. K. Though I do hope you're not coming to the IETf-four fast.
[00:51:46] Nick Steele: No. No. No. This is this is my this is my vacation. Excellent.
[00:51:53] Justin Richer: Alright. I see you in the queue. Yeah. Go ahead.
[00:51:55] Arndt Schwenkschuster: Yeah. So I personally see... And correct me if I'm wrong. The colorful adoption as in, like, this is a problem the working group wants to work on and not a this is the solution space that we want to commit to. Right? And, ideally, I would like to use 121 already to talk about the solution space and not, again, having to talk about the problem and that it's the right thing to do or, like, that the problem is valid. So personally, I prefer to have the adoption call before so we can use the time in San Francisco to actually focus on the solution space and the various topics that Paul had there on the last slide. Yep.
[00:52:37] Justin Richer: Yeah. So a a clarification call for adoption is a call on the proposed direction as well as the problem. The statement of the problem helps us understand what the direction of the solution intends to be applied to and intends to address and it's not a referendum on the details of the solution because heaven knows we love to bike shed. So with that in mind, I think that, Peter, I think you and I can at least, do a sort of, problem statement discussion thread on the list pointing to this draft as sort of, defining part of that. And then we'll talk with the AD to to make sure things are in shape before we do any kind of call for adoption.
[00:53:22] Pieter Kasselman: Sounds good. I think that is the right... That feels like a good direction.
[00:53:29] Justin Richer: Alright. We have a few minutes left. Nobody in the queue. I think we are good to declare this done. Thank you everybody for joining today. There are... If you haven't been following, there are a couple of OAuth interims that are still also coming up that are also relevant and adjacent. And, you know, there's good reason we're having a joint OAuth and WIMSE session. A lot of touch points here. And, hopefully, see a lot of you at... In San Francisco at IETF 121. Thanks to Paul and everybody for presenting today.
[00:54:05] Pieter Kasselman: Thank you. Alright.
[00:54:07] Nick Steele: Thanks so much.
[00:54:08] Justin Richer: Alright. Take care all.