Session Date/Time: 20 Jul 2026 12:00
[00:00:06] Justin Richer: Like, have some idea what we're doing. I'll speak for yourself. Yeah.
[00:00:12] Aaron Parecki: Alright.
[00:00:13] Justin Richer: Hello, everybody. Welcome whimsy enthusiasts to IETF 120 here in Vienna, and thanks to everybody else everybody else who's joining us online. So this is Monday. So please note the note well well and make sure that it is noted. This basically describes everything, how we're supposed to treat each other, how we're supposed to approach the work. You know, don't be a jerk. Focus on the technology. Work well with others. Pretty simple stuff, really, but please do it. It is very it is very important. If you are here in the room, please make sure that you scan that QR code or follow the link from the from the data tracker agenda to open up the the Meetecho local tool, the on-site tool, it's called. And that's how we actually get a record of how many people attend any given session so they know what size room to get us. So we could have 300 people in a room, but if only two people scan, they're gonna tell us, no. You get a tiny little room next time. Let's not do that. Clearly, we have a lot of people to fit in here, which is awesome to see. Remote participants, do not turn on your audio and video unless you are actively presenting or actively asking or responding to a question. If you have something to say both here in the room and and online, please make sure you join the queue.
[00:01:43] Peter: Alright. So we've got a packed agenda. Hello. I'm Peter, your co chair.
[00:01:48] Justin Richer: Oh, yeah. I should. Hi. I'm Justin. I forgot that part.
[00:01:51] Peter: So let's take a quick look.
[00:01:54] Justin Richer: Agenda.
[00:01:54] Peter: Okay. So pretty full agenda. We're broken it into two parts. So first part, we're gonna focus on existing work, hopefully all heading to working group last call or there already. And then in the second part, we're going to focus on some of the new work that has been identified and that folks on the list has been enthusiastic about. Alright. And then directing you to the working group resources. There's the mailing list, of course, Git, and we've got an amazing website that'll help you quickly find drafts that's in flight, mailing list archives, etcetera. So check that out.
[00:02:36] Justin Richer: Alright. So we have a lot of documents that are currently in process right now. Very happy to say that workload identity token is
[00:02:44] Kartik: currently in a d review.
[00:02:45] Justin Richer: So we were able to ship that off to the ISG, and it's going through its next stages. The workload credentials or workload identity token or whatever we're calling it is, has just finished its, working group last call. We will hopefully hear some updates about where that landed today and get a feeling from the authors about whether this is gonna be ready to ship upstream. That leaves three presentation drafts, architecture and identifiers still to work on, and we'll be hearing updates about all of these today. And I wanna remind folks that we have part of the reason that we have so many drafts is that we blew up our elephant a while ago and turned it into four fast running gazelles, one of which is crossing the finish line. So the metaphor worked. And I just also wanted an excuse to share this awesome comic that my kid drew in, like, five minutes when I said that I needed an illustration for this. So it's just he did a great job. Anyway,
[00:03:49] Yaroslav: we have two two particular topics that we
[00:03:52] Justin Richer: have shares, wanted to highlight. Peter, do you wanna talk about this one?
[00:03:55] Peter: Sure. So we had an interim meeting where we talked specifically about the AI agent authentication and authorization draft. I think there was a lot of interest on the mailing list as well, so very lively discussion. There was no call for adoption yet, but I think we'll hear more about that later today. There is a recording, and I think that will be we'll leave that for that session. And then Workload Identity Federation, Justin. Oh, yeah?
[00:04:28] Justin Richer: We didn't practice the handoff at all. So Workload Identity Federation or WIF, which by the way, that's what you get when you Google WIF images, water and fuel monitors. This is a topic that is coming up a lot in industry right now. I'm seeing it all the time at work. I know a lot of people are. It's not something that we are directly tackling here in WIMSE, but it's something that, if we have time at the end of this meeting, we might chat about it for a bit to see if this is a, a space we might wanna jump into. There is a ton of work that has been proposed for this. We, as a working group, still have to finish our vegetables and ship stuff. We are doing that, but let's keep doing that, and make sure that we get that moving forward. And with that, we are, you know, please check out the website. We are ready to hand over to the first presenter. Oh, I forget who it is. Yep. Go ahead and take the clicker. Wipe it down. Yes. It's nice and dry now.
[00:05:44] Brian Campbell: Alright. So I have very, very little time, which I apologize for. So I'm just gonna take some of that time to tell a little story. I arrived this morning early on a flight, took the train in, forgot to get off of the train, took the train back out to the airport before realizing that I needed to take the train back into town. So that's about the state of my mental condition right now, so bear with me. Let's talk about WIMSE- workload credentials. And here we are in beautiful Vienna.
[00:06:17] Justin Richer: There's too many monitors, and this doesn't work. Is is the clicker not clicking?
[00:06:21] Yaroslav: Not clicking.
[00:06:22] Justin Richer: Oh, okay. Well, let me take it back to say next slide then.
[00:06:26] Brian Campbell: Just next. Okay. Real quick. Kind of what we've we've got in this document is a single document that defines the credentials that workloads, imagine that, use to represent their identity and also bind a public key to that identity. We've got a workload identity token, which is a JWT, and workload identity certificate, which is an x five zero nine certificate. These are for use in various protocols meant to authenticate workloads to one another, typically one calling the other, but sometimes it goes both ways. And the use requires proof of possession mechanisms, but the mechanisms themselves are out of scope for this document. That's part of what Justin talked about with gazelles running over antlers eating elephants or I'm not sure. I lost track of it. And the time is already yelling at me. I love it. So since Brisbane, we've published two drafts and taken it to working group last call. Thank you all for participation. And next slide, maybe. This is awkward. Sorry. Working group last call. It ends in a few days or yesterday depending on your meeting travel perspective. And there's been quite a bit of discussion on this. I tried to capture some of it here. I went through it. Honestly, I'm not entirely sure that all of these are fully on topic or, you know, actionable in the scope of this work, but they're all there. So we need to but there is intermingled in that some very meaningful useful feedback that the authors need to take into account and deal with. And I think I have two minutes left. This is awesome. Here's a list of the open issues. Tried to label them. In five minutes, we don't really have time to go through these, but they are there. Many of these are from the previous email, but not all of them, so we need to reconcile that as well. Authors are working on it. Give me the next slide.
[00:08:16] Justin Richer: Okay.
[00:08:17] Brian Campbell: There we go. Five minutes doesn't give you a lot of time for detail, but hopefully, the road ahead ends before San Francisco. It's a visual metaphor here. You have a road that ends in San Francisco, but we don't wanna take it there. God. Ahead of time. One minute
[00:08:33] Yaron Sheffer: Yeah.
[00:08:33] Brian Campbell: Twenty five seconds.
[00:08:34] Justin Richer: Fantastic. We have time for If one or two not, I have one from the chairs. Do the authors have a feeling for how close this is to being able to ship? What was the nature of the last call comments like, oh, we need to burn everything down, or is it we need to clean up and and push it?
[00:08:54] Brian Campbell: I think it's definitely more of the latter. Although there's there's work involved in sorting sorting through the the variety of comments, but the general feeling is definitely more of the latter.
[00:09:05] Justin Richer: Alright. That's fantastic. I would love to see this out, before San Francisco. I think we can do it. I'm not doing the work, so I really think we can do it. Thanks, Brian.
[00:09:16] Brian Campbell: Alright. I think I'm still here for another thrilling, engaging presentation.
[00:09:22] Justin Richer: Yeah. This looks like a you presentation.
[00:09:23] Brian Campbell: Hey. Look, Vienna. So one of those protocol bindings use of the WIMSE identity token in the context of HTTP presentations is the WIMSE workload proof token, otherwise known as WPT. I didn't get a picture of a dog here because we get us a lot prettier, but WPTs are also a type of dog. Yeah. It's not working. It's give me the next one.
[00:09:49] Justin Richer: Yeah. I need to take control back and then hit next. It's a
[00:09:52] Paul: bad thing.
[00:09:53] Brian Campbell: Anyway, real quick context for the tourists out there. This I think, basically, like I just said, specifies the workload proof token, which which is a mechanism for workloads to prove possession of the private key associated work with the workload identity token. And the WPT itself is just a signed job that binds the workload's authentication to a specific HTTP request, providing application level proof of possession for workload to workload communication. Next slide, That's a visual metaphor too. Oh, here's another one. Here is a list of everything we've accomplished since Brisbane. You'll notice it's empty. Next slide, please. And what we need to accomplish before San Francisco or even sooner than that. This is a list of the issues. Honestly, there is not a lot super meaningful here. One that is sort of keen to my heart is wanting to it's not even on here. Oh, consider putting a transaction token in the WPT examples. So right now, the WPT examples show proof token in conjunction with h request that's using OAuth access token as sort of the authorization layer. I'm sort of of the opinion that a better pattern is to have OAuth functionally on the outside of your systems doing the outside stuff for authorization. Something at ingress or right after ingress validates that token, exchanges it for a transaction token, and then everything on the inside of the call chain happens where you're doing whimsy style authentication from workload to workload and a transaction token that traverses the entire call stack down through there. And so while the examples are not at all normative as we all know, I think it would be really useful to put that as sort of the the marquee example as just showing that this is sort of a hopeful pattern to use. So it's non normative, but I think it would be super helpful, and somebody needs to do the work. Aren't usually does all the work, but I think I might do this one. So oh, and then there's an old email we haven't responded to that Yaron was kind enough to point out. Basically, this is in a similar state to the workload credentials, but not quite as mature. There's a significant amount of cleanup work that needs to be done. And then, hopefully, following that, we can take it into working group last call. So on a similar state, just a little bit behind it. Next slide, please. And what did I say there? Oh, yeah. We need to get our act together so that, hopefully, this draft can progress, and you won't have to listen to either of us, Art or me, although Art's more fun to listen to, talk about this at the next IETF. That might be a little ambitious, but we can try. And there's a arrow there somewhere pointing to the hotel that the San Francisco meeting's at or thereabouts. Look at that. Four minutes left.
[00:13:07] Justin Richer: Laser pointer works if you wanna use that. Sorry. Folks online don't get the laser pointer.
[00:13:14] Brian Campbell: San Francisco. Yeah. Alright. That was fast. Thank you. Okay. Yeah. It's it's hard to, like, get into meaningful context in a short amount of time, but that's the status we're working on it or we hope to work on it soon.
[00:13:31] Justin Richer: Alright.
[00:13:31] Peter: Hey. Chair hat off. I like the idea of using transaction tokens Yeah. And the examples. So I'm very supportive of that. Thank you. Chair hat on. Thank you for committing to getting this work done before San Francisco.
[00:13:52] Justin Richer: Yeah. Likewise, with the chair hat, do you guys think that this will be ready to put through working group last call prior to San Francisco, or or will we be talking about putting it into it by San Francisco? Like, which which side of the divide are we probably gonna land on?
[00:14:11] Brian Campbell: I would like to defer to my distinguished colleague and coauthor, Arndt Schwenkenscher. Can't pronounce his last name.
[00:14:19] Arndt Schwenkenscher Schwenkenscher: I'm gonna make you try. Go
[00:14:23] Justin Richer: ahead, Arndt Schwenkenscher.
[00:14:25] Arndt Schwenkenscher Schwenkenscher: So I do believe we're gonna get it through because we've so far focused a lot on the credential stuff, right, and kind of neglected the WPT, which makes sense because the credential stuff needed to go first. But now focus has swift shifted to this one, so I I think we're gonna make it happen. Okay.
[00:14:44] Justin Richer: You heard him. Excellent. Was that what you got in the q four, or did you have something? Okay. Excellent. Anybody else? Alright. Thank you, Brian. Minutes ahead of time. Don't say things like that. Alright. Yaron.
[00:15:07] Yaron Sheffer: So while still using Brian's two and a half minutes, I think that I totally agree about transaction tokens. I also think they need to go into the architecture document. Having said that, let's let's talk about the the second application level mechanism, HTTP signatures. Next slide.
[00:15:34] Justin Richer: Please. I'm trying. There we go.
[00:15:39] Arndt Schwenkenscher Schwenkenscher: Thank you.
[00:15:42] Yaron Sheffer: Two significant changes between 2002 and zero four, so from the last IETF to today. And we're going to ask for working group last call. To those of you who are really, really following, we're now at five, which was published today and I'll say a word about it.
[00:16:05] Yaroslav: Next. Okay.
[00:16:10] Yaron Sheffer: So there's an ongoing discussion about the audience signal, basically. So how do you how do you allow the recipient of the message to make sure the message is indeed targeted at it? And, we tried, different ways of doing it. Between zero two and actually, I think zero three, we we switched from an HTTP header to an HTTP signature signature parameter, which avoids defining a very, very specific kind of weird http header and puts it where it belongs much better. But the content is still the same, still the request URI. And the motivation is there may be a proxy on the way or there may there may be some sort of translation of the request URI on the way. So you want assigned component to keep it all the way through to the recipient. Next slide. Second thing that we figured out is that we signed the request. We sign we optionally signed the response with HTTP signatures. But there was actually no binding between the request and the response, which means that a malicious proxy could cut and paste, one response into a request that it does not belong to. We discussed different ways of handling that and ended up by simply copying the nonce value from the request into a signature parameter, another signature parameter on the response. So now we have two signature parameters, two new signature parameters being defined here. The note says that the draft examples are still not up to date with version 0.5 published this morning. The examples actually are up to date. And thank you to I forgot the name who opened an issue about it. Next. We believe it's time to call for working group plus call up to distinguished shares. And I believe this is it. Thank you.
[00:19:19] Justin Richer: Think it works. Alright. Thank you. So we've got a couple minutes. Any questions or or anything? Not seeing anybody in the queue. Oh, sorry.
[00:19:39] Yuning: Yes,
[00:19:41] Justin Richer: please. If you could say those at the mic, that'd be great. Jonathan, did you wanna bring yours to the mic? I know I saw him. There he is. Alright. Alright. Go ahead, Kathleen.
[00:19:53] Kathleen Moriarty: Kathleen Moriarty, I'm curious. Is this aligned with the web bot auth and their use of HTTP signatures?
[00:20:02] Yaron Sheffer: Showing their assets. No.
[00:20:06] Kathleen Moriarty: Alright. Just more to track.
[00:20:09] Jonathan: Mhmm. John from. If the signature is optional, does that mean signature stripping is an attack vector?
[00:20:23] Yaron Sheffer: It's well,
[00:20:25] Yaroslav: it's
[00:20:29] Yaron Sheffer: optional in the sense that it's a deployment decision. I don't think it's a per signature decision. The deployment decides whether everybody signs and everybody verifies responses or nobody does.
[00:20:46] Jonathan: So does that mean in the signature, you commit to the deployment mode?
[00:20:54] Yaron Sheffer: No. You do not.
[00:20:56] Jonathan: Okay. So you but you so in theory, you could strip every signature?
[00:21:02] Yaron Sheffer: Again, it's it's basically a configuration parameter.
[00:21:06] Jonathan: But if you don't commit to configuration?
[00:21:09] Yaron Sheffer: Of course. Yes.
[00:21:10] Yaroslav: Okay. Thank you.
[00:21:11] Justin Richer: Can I clarify here? This question was about the response signature specifically? Yeah. Yeah. Yeah. Oh, okay.
[00:21:16] Jonathan: Yeah. I was just trying to understand how it works.
[00:21:18] Justin Richer: Totally totally. I was making sure I was following that. Thank you. Alright. So there has been a call for for last call. I just would like to get a sense of the room here. Who has read the draft? I'm not even gonna say version five because apparently that's, like, thirty minutes old. So who has read a recent version of the draft? Alright. If we could get a couple more people to commit to, reading it. Thank you, Kathleen. Thank you, Jeff. Alright. I can't see whose face that is, but oh, hi. Thank you, Jonathan. And alright. Excellent. Thank you. That's a lot of hands that went up. Appreciate it. Could always obviously use more. Please read that over. It does seem like we are getting pretty solid. So shall we issue last call in a couple weeks perhaps?
[00:22:08] Peter: Yeah. I was I was actually gonna say I think we should issue working group last call following this week. Okay. Let's start it next week.
[00:22:17] Justin Richer: No. Give give people a week to, like Okay. Turn their brains back on. Well, the chairs will decide when we are going to issue a working group last call. It will be in the near future, though. So great work to the authors. And, everyone who committed to review, please read the current draft, and, we will put the official call for, last call up on the list soon. Oh, I saw somebody in the queue very quickly, and then they disappeared. Okay. Oh,
[00:22:50] Kartik: Hey. I'm joining online. My apologies for this. I would like to contribute to both of them, like, for for the draft. If there's any open issues, please feel to refer to me. I'll be more than happy to spend some time on it. That that was that was about it. Sorry. I didn't mean to take up much time.
[00:23:08] Justin Richer: No. That's great. Thank you. Alright. Next. Yeah. It's I gotta it's a whole thing. It should be Joe. Joe. Yes. Do you need the clicker for this, or can I just hit next?
[00:23:29] Joe Salowey: You can you can there's not too many slides, so we should find out. I noticed. I'm Joe Salloway, and I'm presenting on behalf of Yaroslava and myself about the MTLS draft, which is how you do proof of possession when you're using a workload identity certificate. This draft has been pretty stable over time. We did make, an update to kind of describe, some complexity in server name validation. Namely, you can use both a WIMSE identifier and a DNS name depending on what tie what type of you can have both of those identifiers in your certificate depending on who the verifier is. They may be more used to verifying a DNS name than a WIMSE- identifier. One thing that did come up from your own was maybe we wanna make this a requirement to have the both of these identifiers in there. I think that's something probably we need to discuss a little bit more. But other than that, we don't really know of many open issues in this document. So I think we should be pretty close to working group last call as well. And that's all I have.
[00:24:49] Justin Richer: Alright. I am hearing a theme here, and I like this theme. Any any questions, thoughts? The queue is empty. Just giving people a second to jump in. Art, yeah, go ahead. I
[00:25:12] Arndt Schwenkenscher Schwenkenscher: was just asking Brian or discussing with Brian whether the DNS name requirement is not just a actually a working group last call item for the credentials draft.
[00:25:28] Joe Salowey: Yeah. It might be. Yeah. It might be. K. I I I think it kinda crosses both of them, but, like, here, we just describe what you do, but the credentials draft would describe what goes in it. So I think that you're probably right. It is a
[00:25:46] Arndt Schwenkenscher Schwenkenscher: Wait. Like, we're all in the same boat and we meet, so let's just discuss it there.
[00:25:49] Justin Richer: Yeah. Okay. Alright. Makes sense. Thanks, Art. Alright. So I think like with the last draft, the chairs will call for working group last call on this one in a couple of weeks, let everybody get home and decompress from travel. And yeah. Peter really wants to do these all next week. So
[00:26:14] Peter: No. I think we given the number of them, let's let's talk about how we schedule them. Yeah.
[00:26:19] Justin Richer: Yeah. Yeah.
[00:26:20] Peter: Everybody get a chance to look at everything.
[00:26:22] Justin Richer: I said in a few weeks. It's just there's a few it's it's expands. Alright. Joe, I think you're up here for the next one.
[00:26:30] Joe Salowey: I think so. Okay. So here we have WIMSE- architecture. These authors are Yaroslav and Hannes as well as myself. And let's go to the next slide. And we've made some updates to address issues that were in our list. We've kinda cleared out the issues. Some of the things we've added in, we've added some text on a layered authentication model. We've done some work on discussing the intricacies of workload versus workload instances. We've separated things to an into an identifier draft. So some text was removed and put in that draft, and Yaroslav will talk about that. We've talked some about taking some information from the creds draft and put it into the architecture draft, put in some more description of key management and identity binding and some improvements to delegation impersonation. I do think we do talk some about transmitting context. I don't know if we explicitly talk about transaction tokens or not. And I think, yeah, that would be an excellent addition because that is kind of surprising that we don't. So that's something we should do before next slide, please. We go to working group last call. I think maybe there's a little bit more review that needs to happen with this document. I I feel like it's it's in pretty good shape, but I would like to see a little bit more review probably before working last call. Although working group last call is a great motivator to get feedback. So alright.
[00:28:25] Kartik: Okay. So
[00:28:30] Peter: couple of folks in the queue. Is there any questions? Mark.
[00:28:35] Justin Richer: Yeah. Mark. Go ahead.
[00:28:37] Mark: So, yeah, excellent document. I would request just one change, figure five. And, actually, your wording is actually seems correct, but figure five misses an a possibility that the workload itself is doing remote authentication. The two sorry. Yeah. Remote attestation. The two arrows you have is between the agent and the server and the agent and the, like, verifier. But there are, in some cases, the workload doesn't trust the agent and will need to do its own attestation. So if you just simply add a possibility of that happening.
[00:29:09] Joe Salowey: Okay. Yeah. Thanks. I I got your message on that too, and I think that that we should be able to accommodate that. Thank you.
[00:29:16] Peter: Thank you. Fleming.
[00:29:19] Fleming Andreasen: Thank you, Fleming, Andreas. Yeah. So I have not done an interim review of the latest version, but just skimming some of the changes from the previous one. I appreciate all the updates, right, with the identifier stuff. It's not obvious to me that it's consistent now with the credentials draft. Oh, So that might be something to take a
[00:29:35] Joe Salowey: closer look at again. Okay. Thanks.
[00:29:41] Peter: Alright. Any other questions?
[00:29:46] Justin Richer: Alright. So I do wanna just remind the group of something real quick about this architecture draft. When we set out to create this architecture draft, one of the things that we said was that it was going to be reactive to the other parts of the system as they were being built. And so instead of putting in a whole bunch of work upfront to agree that we were all using the same words for the exact same thing and then go figure out how to make those into reality, We are building the reality first and then reflecting it in the architecture. I'm bringing this up in case anybody's wondering why architecture seems to be lagging behind all of the things that are supposed to be, you know, defined by the architecture. And I just wanted to say, do think the authors are doing a really great job in capturing that. And when you are taking your reviews, look for those kinds of consistencies that and inconsistencies that Fleming just brought up because that's exactly what this type of document really is meant to do is really sort of, you know, call out, like, this is the common way that we wanna make sure that we're talking about things. Also, since we have a fair number of documents that are gonna be finishing up in relatively short order, Please read more than one document and make sure the authors are using the same words to mean the same thing in the different documents because that'll really help implementers. So, you know, please keep an eye on things like that. And yeah. Thanks, everybody. And next up is.
[00:31:19] Yaroslav: Hello, everyone. So today, I will be talking about workload identifier draft that Joe and I have been working on for a little while. Next slide, please. Mhmm. It's frankly a little bit embarrassing how long time things take because it's a very, very simple construct. Workload identifier is a URI. That's basically it. But words are difficult. Terms are difficult. So it does take some time to polish everything that we want to say about that. So we've done a number of small but important changes in the latest revision based on the feedback that we've received. Thanks, in particular, to Fleming who opened, I think, 15 issues or so. So really, really appreciate your careful reviews. So we've, I believe, addressed all of those. Particularly particularly, what stands out is softened information security disclosure configurations. Previously, we were probably a little bit harsh about potential risks of information disclosure. Obviously, we still mentioned them, but we now use slightly more rounded language. We clarified various definitions, things that were either not defined or were inconsistent with other WIMSE- and non WIMSE- documents. So, again, we took few passes to make sure that we are aligned. There is always a chance that we missed something, so please take another look and, yes, addressed all other small to medium sized outstanding issues. And then unsurprising next slide is I believe that we are ready for working group last call. There are no open issues remaining. Few people read through the draft or at least somehow figured out what the issues are maybe without reading it. The document itself right now became, well, quite important dependency for other work within WIMSE- and perhaps outside of WIMSE-. So we kindly ask chairs to consider working group last call and maybe somehow expedite the process. Thank you.
[00:33:43] Justin Richer: You'll go on the list. Alright. Thank you, Arndt Schwenkenscher. I'm not seeing anybody in the queue. Did you have something, Peter?
[00:33:52] Peter: Yeah. Was actually curious if I how many folks have read the latest draft of the workload identifier draft spec? So you aren't yeah. Couple of these maybe a few more. Yeah. So I think that would be one thing, is get a few more people to review it. That would be good. If we can get some some hands go up. Yep. Thanks, Fleming. Nick.
[00:34:15] Justin Richer: Thank you.
[00:34:15] Peter: Andrew, Kathleen, thank you. Excellent.
[00:34:19] Justin Richer: Pam, you're in the queue. Yeah.
[00:34:21] Pam Dingle: Somebody pass me that mic because I don't think I can get out. Oh. Yeah.
[00:34:26] Justin Richer: They're they're wireless this time.
[00:34:28] Yuning: So Thank you.
[00:34:33] Pam Dingle: This is a question for maybe everyone who's presented. I don't know who has the right answer to this or if there is one. I think since the last plenary, the OAuth SPIFI client authentication specification has has come alive,
[00:34:49] Yaroslav: and
[00:34:49] Pam Dingle: it specifies a an a WIT token as one of the represented credentials. Does anything about that change what's happening in WIMSE as far as dependencies? Is that a spec, for example, that would be a dependency for something that's just been presented?
[00:35:08] Justin Richer: So the client the client identifier and credential spec would take a dependency on WIP and and probably identifier, I would guess. So those two together, but not the other way.
[00:35:27] Yaron Sheffer: Aren't
[00:35:33] Justin Richer: yes. And aren't you telling me why I'm wrong?
[00:35:37] Arndt Schwenkenscher Schwenkenscher: So there are dependencies in some ways, I would say. The other thing is that SPIFI has adopted the the the work, and the so we're kind of going from IATF to CNCF SPIFI back to IATF. So there's CNCF in the middle with SPIFI. So there's some ways we can like, I guess it's up to us to decide whether how it works, but I don't see its strict dependency on it more like soft ones, I would say. Yeah.
[00:36:07] Peter: Yeah. And I I think the width is the Yeah. The the big one in that. We're at working group last call. I there's I didn't see anything that suggests that there's a meaningful change in the token format. So, yes, there's a dependency, but I think it's fairly well contained.
[00:36:23] Arndt Schwenkenscher Schwenkenscher: Yeah. And the with work is in working group last call here, and I do believe we're still gonna need one more season in all for that work so we can just align that. Yeah.
[00:36:33] Yaroslav: Great.
[00:36:36] Justin Richer: Good question. Alright. Thanks.
[00:36:39] Yaroslav: Thank you.
[00:36:40] Justin Richer: So with that, I wanna take just a minute to say we've got a whole lot of drafts that are asking for working group last call in the very near future. Not next week. I need to keep Peter away from the chairs email. So, anyway, the in the next in the very short future, there's gonna be a lot of stuff coming to the mailing list. The mailing list is where the working group last call is debated and decided. So please keep an eye on stuff there. Please send issues and discuss them on the mailing list. The reason for this is so that we have a record of that. These are also available in GitHub. So if you have a specific bit of text that just needs to be changed because typo or weird wording or something like that. Yeah. Go ahead. File issues. Do it that way. But substantive discussion, we we do wanna see that on the list. And that also tells us, you know, during these last calls, it's also important for people to say, yeah. This is pretty good. It's ready to go. Here's my nits or here's you know, I didn't find anything wrong with this like that ever happens in the ITF. But it's important to get the positive reviews as well during any of these last calls. So if you even have something nice to say about any of these documents, you are allowed to say nice things on an IETf mailing list. I know revolutionary. Regardless, keep an eye out for that coming up. Thanks to all the hard work for the from all the authors. There's been a lot of stuff going on, and I think that we're all seeing just how important and foundational this work really is in the outside world. And with that, we are going to shift to part two. The next suite of documents that we're gonna talk about are not whimsy documents. This is all work that has been that is being brought to the group for either consideration of adoption or it's consideration of discussion even. I don't know. We don't know yet. So with that, who do we have first?
[00:38:46] Peter: Arndt Schwenkenscher's up next.
[00:38:47] Justin Richer: Oh, Arndt Schwenkenscher's up next. Okay. Alright. I'm gonna give you the clicker because you actually have a lot of slides this time.
[00:38:58] Peter: Alright.
[00:39:01] Arndt Schwenkenscher Schwenkenscher: You should be good to go.
[00:39:03] Justin Richer: K. Alright. I'll reset your timer now.
[00:39:05] Arndt Schwenkenscher Schwenkenscher: Okay. Yeah. So this is a submission following a end of business item from Montreal where we wanted to ask the room whether there's interest on trust domain discovery, key discovery, and all sorts of, like, kind of trust establishment of trust domains. Yeah. So in the architecture draft, there is the section that says the secure mechanisms for obtaining the trust anchor and JWK set mapping is out of scope for this document. And that's quite substantial for this whole thing to work because without trust, there's very little. Yeah. So in the current situation, you would have, for example, Bob and Alice, both our Rimse trust domains. And Bob calls Alice, and Alice would be like Bob who. Right? There's no way. It just says Bob, and everyone could be Bob. So as of as of today, there needs to be some sort of out of band establishment that, for example, maps pop to a JWKS, maybe served over HTTPS or a local key bundle or anything sort of out of band to kind of establish that trust. And then with that, Alice can fetch the keys of Bob and validate that it's actually bob.io that is. Yeah. So this works amazing in closed environment enterprises. If you have prior established business relations and they offer, like, a small set of trust domains. But the moment you go into open environments and there's no prior trust establishment, the whole thing does not work. And we are particularly seeing that also in OAuth with c I with CBOR Web Token (CWT) where things may not be established at the moment beginning, and they are only established at runtime. And same problem exists in WIMSE and also in SPIFI. Yeah. So in this draft, a possible solution would be to say that trust domain identifiers can be fully qualified DNS names. That's just one proposal. But the more bigger question is whether this is a problem and we want to work on it. So in the draft that is currently submitted, it kind of introduces a well-known endpoint for WIMSE Trust domains, and that well known endpoint very similar to IDC and OAuth. Authorization server metadata contains an endpoint to a bundle where in there would be signing keys, public parts, obviously. Yeah. So the draft at the moment defines a bundle. All pretty standard. If you read through it, if you see it, it all looks very familiar. And it also defines that defines that trust domain metadata document. Just a minute. One minute. Yeah. So I'm gonna skip that because we don't have enough time. The questions to the working group is, most importantly, do we agree on the problem space? I'm not opinionated about the solution. It's just to get something out there so that they could discussion. And then secondary opinions maybe about the current proposal, whether it's one document, two, and so
[00:42:19] Hannes Tschofenig: Yep. Hey, Ant. This is Hannes. The question I have is whether a unique discovery mechanism is needed for different application domains. You already mentioned OIDC stuff, OAWA specific stuff, and so on. Is is there something in there that is fundamentally different or or in in the use of WIMSE that requires a different mechanism or different approach or not? That's the first question. The second question is the key distribution is is an relatively it's probably the the easiest part. Like, we learn we look at we do a DNS lookup. We connect using HTTPS. We get that file in in JSON format, and then we we know what the public key is, and there's probably something else alongside that helps us to chain it back to something. But then the diff the tricky part is, which is something we know from Kerberos, is the authorization aspects because in just because you can connect to another domain, and that was already an discussion topic back in the in the OS working group with the cross domain work is, like, what do the authorization decisions in one domain mean for another domain?
[00:43:49] Arndt Schwenkenscher Schwenkenscher: Yeah. Both both good comments. We need to figure out. But, like, maybe question back, do you agree on the problem space? Because that's, like, the primary questions we're trying to go and how then we solve the problem and what's the scope of this whole thing and so on. That's that's all secondary in my opinion. More importantly, it's like yeah.
[00:44:08] Hannes Tschofenig: Yeah. I I think Aaron?
[00:44:11] Justin Richer: Yeah. Hannah, sorry. We're we're trying to keep the we've got so much all on of those, I will say, are great questions and discussions for sort of figuring out what this document should and shouldn't do. Aaron, go ahead.
[00:44:26] Aaron Parecki: My question is about the overlap between this and the OAuth space of you mentioned client ID metadata document CBOR Web Token (CWT) because there's a lot of things you could do to kind of use that as the bridge to do the, like, public facing public federation like side of it as well. Have you thought about that? Do you see that as an option, or do you think that there's totally no point in bridging those worlds?
[00:44:53] Arndt Schwenkenscher Schwenkenscher: There's definitely value in it because those systems, they need to work hand in hand together. In WIMSE, you may have other credential formats like x five zero nine certificates, which you tend not to find in auth. So that's a bit of a thing. So in there, there would also be x five c. In JWKS, you would also find x five c certificates. Okay. Yeah. But, again, great question. Let's work it out.
[00:45:18] Justin Richer: Alright. Jonathan, very quickly. We are over
[00:45:20] Paul: time.
[00:45:21] Jonathan: Yeah. Yeah. This this is this the same problem as the WebPodAuth problem? Like, they seem to be completely the same.
[00:45:30] Arndt Schwenkenscher Schwenkenscher: Yes. I also had conversations with you with WebPod off folks. It is very similar. My understanding is that WebPod off likes the technology of Spiffy, and that thing, what this one would solve is what's currently preventing WebPod off to actually cross that bridge. So, yes, 100%. Yep. Thank you.
[00:45:52] Justin Richer: Alright. Thank you all. And the chairs will be issuing a working group last call for this document within the next coming weeks.
[00:45:57] Peter: Can we do can we do adoption first?
[00:46:00] Justin Richer: Like No. Takes too long. Alright. Next up, we have aims. I'm not sure which one of the far too many authors is gonna present. Yaroslav.
[00:46:12] Yaroslav: Is clicker clicking?
[00:46:13] Justin Richer: Clicker is clicking.
[00:46:14] Peter: Oh,
[00:46:15] Justin Richer: wow. Yeah. Meetecho came and fixed it. Meetecho awesome. I just and I'm not just saying that because they're listening.
[00:46:22] Yaroslav: Alright. Hello, everybody. Me again. So today, I would like to, give an overview of our AI agent authentication and authorization model framework that we've put together. So for those who attended the interim apologies for deja vu, that will be pretty much complete overlap, but it will be a refresher. And I guess a good thing that in the time between interim and now, we did not completely rework to the model. That would be a bit alarming. And thanks very much, Brian, for providing wonderful, fresh imaginary for for this presentation. So AI agents are scary. They can be intimidating. They hard to reason with sometimes. And sometimes, natural reaction, defensive reaction is let's invent new protocols to deal with these things that we don't quite understand. And some some practitioners, for all sorts of reason, treat agents as humans because they are kind of human human like. One thing that is though common is AI agents require identity. Otherwise, they all look the same. They might again resemble humans, which is quite confusing, and we do need to do proper control of what agents are doing, accounting of what they're doing, and all sorts of important security and nonsecurity related things. We need to provide them identity. So their motivation is that, again, we don't want to reinvent new AI protocols unnecessarily. We have been through blood, sweat, and tears and security vulnerabilities in many, many decades when it comes to authentication, authorization, and identity. And we should be leveraging that experience, going back to the drawing board and create things that will very likely have some of the problems that we had in the past. There is a wide range of technologies involved.
[00:48:45] Brian Campbell: When you look
[00:48:45] Yaroslav: at modern authentication authorization frameworks, you have to read dozens of different RFCs and standards from different bodies, not just IETF. It's very hard to wrap your head around it. So if you want to build a new AI agent and you want to build it in a secure fashion so that it would support modern authorization, authentication techniques, you need to do a lot of background reading. Or alternatively, will rely on agent AI to help you with that, but how do you verify that they did the right job? So we need to also locate missing pieces in the existing standards and surgically address them and see what are the pieces that already exist and are applicable and what are the things that needs to be added into the puzzle. So I think this is the most important illustration when it comes to agents. Agents are complex. They can live on different devices. They can live on personal laptops. They can live on the network. They can live in magical cloud and be multitenant. But at the end of the day, they have three kinds of interactions. They interact with users or other systems, typically the ones that giving them tasks and expecting some kind of outcomes, some kind of results. They intimately interact with large language models, normally via some kind of proprietary APIs. So large language models is what really drives them, tells them what to do. And then they interact with tools, services, and resources. It could be a public web, like browse Wikipedia and steal some of the or derive some of the contents from there, or communicate with some kind of, I don't know, GitHub or orchestration platform, drop the database, or do other interesting exciting things. So the idea of the draft is to project existing set of technologies that, again, we have been working on as a as a as a in the standards community into building blocks and build the model. Starts with identifiers, going into credentials, going into provisioning, authentication, authorization, monitoring observability, policy, compliance, how that can all tie together to agentic AI use cases. So there are a set of set of standards that we looked into to put together these consistent models primarily include when it comes to agent identity authentication and credentials or when it comes to authorization, especially when it comes to human delegation, and SSF, a shared signal framework, when it comes to audit and logging. At the moment, IETF doesn't really do much in this space. Peter, you have a burning question? Okay. Right. So a few building blocks, and you, again, will have a little bit of deja vu with previous presentations. Identifiers, I've already talked to you today about workload identifiers. Surprisingly enough, they can be applicable for Identify identifiers. So WIMSE or SPIFI identifiers apply really well to those things, which brings me to credentials. Again, agents need to have their own credentials so they would be able to prove that they have identifiers so that they would be able to, again, with cryptographic evidence to to to to confirm that they are who they say they are. And with agents, that becomes particularly important because agents can hallucinate. Agent wants really to please their user sometimes, and sometimes they they cut some corners in order for that to happen. So having some kind of cryptographic binding is important. That brings us to provisioning. So we need to have provisioning of those credentials, provisioning of identity. We need to validate device posture or some kind of compliance requirements that agents are running where they're supposed to be running, that they haven't been in jailbroken or compromised in in some ways that is typically part of provisioning. With authentication, all the authentication mechanisms that we discussed today, HTTP message signatures, MTLS, they apply really well to agents. We should be leveraging them. And then we have an ocean of different lovely, standards when it comes to authorization. So pretty much everything that is related to OAuth applies to agents really, well. And, of course, special mentioning of transaction tokens here. For monitoring observability and shared signals, this is something that is primarily outside of IETF domains as of today. Most of building blocks are in place with OpenID shared signals framework that we reference in this draft. And then policy and compliance really needs to apply to all the layers in the AIM stack so that you know what you're doing. So, as of next steps, no working group last call yet. We are, at the moment, would like to request for consideration from the chairs to request that the working group consider adoption of the work as the work item. So adopt us, please. We believe that WIMSE- is by far the best place in IETf and even in the broader standards community for this work.
[00:54:31] Justin Richer: Oh, I thought you were saying something very sweet, and then you added for this work to the end there. Peter, go ahead.
[00:54:40] Peter: Yes. Hi. This is Peter. I'm here to express an interest because, from, several ITS before, we have submitted a similar draft. It's called Winzy Dash AI identity. Basically, it's a very simple motivation from so as you said, if it's a burning question, it's actually a burning question from our customers that they have very growing concerns of having invisible endpoints that, you know, they they they look like regular endpoints, but they're actually agents without individual identification. So they're leaking data for, like, PII or some sensitive business data. So we have proposed a solution to that, and, actually, we it's just a express of interest. And, also, we have some considerations of the agents who inherit its owner's identity because, usually, those your AI agent must to reside in some kind of device, either it's your phone or is on a big inference server, but eventually should have some kind of representing you or representing your department. So this can inherit some a little, like, a role based access control for additional authorization contacts. Right.
[00:55:56] Yaroslav: Thank you. So so few things there. I'd like to respond. First of all, again, this is we're not proposing new standards here. It's informational document showing how existing things could should be used. When it comes to and then there are some missing building blocks and perhaps a special identifier for agents that would fall within WIMSE- identifier framework is something that should be considered, but it it would be outside of this framework that would be a new work that might be interesting or not. And when it comes to inheriting user identity based on experience, I would highly recommend consider it as authorization. So user authorizes agent to do something. Agent still has its own identity, so it's authenticates as a piece of software, as a workload, and then it provides authorization evidence that Peter authorized me to drop the database or, you know, whatever.
[00:56:55] Justin Richer: Okay. I wanna point out we've got seven people in the queue, and that round took two and a half minutes. So if the next questions and answers could be a little more to the point, that would be great.
[00:57:07] Speaker 18: Yeah. I'll be quick. So have you thought about or maybe think about separating the agent from the workload? This is something I'm seeing from customers of you know, sometimes there's a workload that might be multiple agents. There are scenarios where the agent is the nondeterministic thing, and the workload around it is the deterministic thing. Just something to consider.
[00:57:26] Yaroslav: Thank you. Just again to answer that, yes, we've considered that. At the moment, again, the the the the part of the of this framing is that agent is the workload. But when it comes to identifiers, keep in mind that identifier can apply to a single workload instance, or it could apply to a service. So I think the same approach can work here. Okay.
[00:57:48] Justin Richer: Paul, go ahead.
[00:57:50] Paul: Hi. Yeah. So I think with with agents, we see them wanting to connect to a lot of different services, and a lot I think a lot of those today probably don't support workloads or workload identity federation. And I know earlier we're talking about whether, standardizing workload identity federation would be in scope for this. Is that something you're considering?
[00:58:09] Yaroslav: Yes. Of course. I mean and, again, WIMSE-y today is not as widely deployed as we'd like it to be. And these together with other WIMSE- work will help make world a more secure place, if I understood your question correctly.
[00:58:26] Paul: Yeah. I guess I just I
[00:58:27] Arndt Schwenkenscher Schwenkenscher: think people
[00:58:28] Paul: will hopefully be adopting more things, and maybe this might be a good opportunity to standardize on that federation. Right. Thanks.
[00:58:36] Justin Richer: Okay. Art?
[00:58:38] Arndt Schwenkenscher Schwenkenscher: Yeah. I'm supportive of this work. I think it's the right approach of doing it to kind of look at it, what's there, what can be used. And if this gets adopted, I would advise to be really strict about that scope because otherwise, you're gonna be opening Pandora's box, we'd be only talking about this. So I think it's like, yes, but let's make sure that it gets framed as this and not more.
[00:59:03] Yaroslav: Yeah. Absolutely. Thank you.
[00:59:06] Justin Richer: Yeah.
[00:59:06] Henk Birkholz: Hi. This is Hank. And while I understand why you're trying to do this, I would not recommend adopting the work at this stage, conflating users and systems and not agents to agents and and and priming this to whimsy seems to be a little bit biased. Also, I think some of these diagrams, there are some laying diagrams here on this thing that is looking a lot of, like, redundant work to other STOs. So maybe talk to those also and align with them because, otherwise, we have, like, like, subtle differences because like, the the ITOT s u seventeen working party one thing is is all covered there. Right? So so that had probably to be aligned, or we're just reproducing yet another thing? It seems to be
[00:59:57] Yaroslav: Oh, I had a chance to present it at s j seventeen meeting.
[01:00:01] Henk Birkholz: I saw that.
[01:00:02] Justin Richer: Yeah. And you
[01:00:03] Yaroslav: were in the room. I don't think there was a conflict or opposition to that, but let's take it offline. If see If if there is some there is some problem, we should resolve it.
[01:00:11] Justin Richer: Sure. Okay.
[01:00:15] Brian Campbell: I'm somewhat redundant to say so, but I'm definitely supportive of this work. I wanted to give a little bit of context about that. I believe it was Peter originally asked me if I would take a look at it and maybe get involved. And my first reaction was, oh my god. Like, the world does not need another draft about AI agent authentication, etcetera, etcetera. And it wasn't until I understood the framing of this being sort of a blueprint for how to compose other standards and where to look at the functionality and not that I that I understood the real value in it. And as a result, I'm I'm very supportive. So Thank you. Right? I think that context is is important to understand. Again, like, what our Arm was saying, like, keeping the scope to that, keeping it that, and moving forward just with that. There's a ton of value in that. So
[01:01:03] Roberta: Just to say that I'm also really supportive of this work. I think it's an amazing work that has been developed. I've been seeing since, I think, the beginning, the the agent that we have in in IETf, and it's really I I knew that something stable and that we could start doing the the real work would come from, when we see and all that, and I'm really happy to to be on this presentation. I hope this is adopted that because we really need this space to be able to work in into it and exchange ideas. Thank you for the presentation.
[01:01:42] Justin Richer: Alright. Thank you. Go
[01:01:44] Aaron Parecki: ahead, Nick. Be quick. I yes. Just wanna reiterate the point that
[01:01:48] Yaroslav: I think
[01:01:48] Nick: other authors make, which we are supportive. But, specifically, hi. I'm Nick. I'm from OpenAI. We are very interested in this flow and, basically, the composite of, like, using what is outlined here, for the purposes of identifying agents, users, workloads, and and, a lot of these tests in here. So I think this is a really good approach. Hopefully, we'll have more to say from with the open AI head open AI head on suit, but, it's a
[01:02:13] Paul: good start.
[01:02:13] Yaroslav: Thank you. Thank you.
[01:02:14] Justin Richer: Alright. Thank you, everybody. Similar to the interim, there's a lot of really positive energy around this work. And, with a bit of bookkeeping and chatting with our I AD, the chairs are gonna figure out when it makes sense to do an official call for adoption of this work. It seems to be general support for that process in general. So keep an eye out for that. No. It's not next week. Damn. You opened yourself up for these bloody gags now. Okay. Thank you, Yaroslav. And Paul, come on up.
[01:02:54] Yaroslav: Alright.
[01:03:00] Paul: So hi. I'm Paul. I wanted to talk about this is a sort of predraft presentation where I wanna see if if folks agree on this problem and if WIMSE is the right place to to try to solve it. The the short version is giving a workload offline access to user data without refresh tokens. So to set the scene, what I'm imagining is this is I'm imagining an agent use case, but it it is can also apply to other workloads where you have a a workload. It's running, let's say, on a cron job. It runs on a Saturday when the user is not logged in, and it's trying to access that user's calendar. So the workload runs on, one domain, say a.com, and it's trying to connect to the calendar in, b.net. User is not present, and it's not currently signed in. The easiest, like, most, typical way to do this would be with the authorization code, flow plus a refresh token. So the user goes through an interactive flow, grants the, the application access to its calendar. And when the workload wakes up, if its access token expired expired, it can use refresh token to to get access to the calendar. The issue with this when we are talking about agents, sorry. These slides are slightly out of date, but I'll just give the the voice over is the if you are we want to avoid a a refresh token in this case and also want the token to be specific to the workload itself and without having to do an interactive authorization flow for each of these workloads. So if you're running, let's say, five or 10 agents, you want to have the calendar service be able to understand which of the agents is is taking the action in the, the calendar service, but without having the user to have to authorize each of these, go through a redirect flow for each each of these. K. So one option for this, is the the OAuth ID JAG flow. It's a a new draft where we use the enterprise IDP. In this case, you do get to skip the authorization flow by letting the enterprise admin be the one that's granting access here. So in this case, the agent uses the user's identity token to go back to the IDP, get the IDJAG, and then use that IDJAG to get an access token and then use that access token for the resource server. That solves part of the problem and that you can use you you don't have to have the per user, per resource redirect flow and per agent as well. So you get to cut down on the the number of redirect flows while still being able to keep the keep the oh, wait. I might have lost.
[01:06:00] Justin Richer: One second. One second. I have your updated slides if you need those.
[01:06:06] Brian Campbell: Magic. Great. Okay.
[01:06:10] Paul: Yes. Okay. So here's our goals. I wanna avoid a long lived refresh token, have the individual agent be legible in the resource, and then, yeah, end of avoid the interactive per agent per resource flow. Okay. So we're back to IDJAG. That helps with the getting rid of some of the interactive consent flows, some of the friction in order to get this per agent token. Otherwise, you would probably end up just getting one token for the whole platform. The challenge here, though, is that now you have a you're using a single ID token and refresh token to talk to the enterprise IDP, and that's not workload specific. So you're back to using, like, a single shared token on the platform side. And so you we need some way to be able to get, one token per agent here. This might just be, a profile on top of the IDJAG flow, might be a profile on top of of WIMSE-y to to get this to work, but the what I'm basically trying to see is who else sees this as a problem and and wants wants to work on it. So in IDJAG, there is the actor token. You could put a, wit in there. Then currently, subject token is required to use the the shared refresh token, and we don't currently have a a way to sort of store and code at what point did that user say that this agent can act on behalf of them, for this, for this resource. Okay. So that's that's the the gist here where we we have a workload that wants access to user on resource, user's not present. We're gonna avoid along the refresh token, have individual agents eligible in the resource, and then avoid the interactive per agent per resource flow.
[01:08:03] Justin Richer: That's the last slide. That's it. Okay. Alright. I we have a rapidly growing queue. Art, go ahead once you get there.
[01:08:17] Arndt Schwenkenscher Schwenkenscher: Yeah. I'm curious where
[01:08:20] Justin Richer: Pick the mic up, please. Sorry.
[01:08:22] Arndt Schwenkenscher Schwenkenscher: Okay. I'm curious if you've looked at transaction tokens and whether the the they are something that could help you transfer that user context, particularly as you're kind of trying to split the user off, which happens kind of out of band. And then at runtime, you want to just transfer that user context from workload to workload in some way. Yep.
[01:08:47] Paul: So my mental model of transaction tokens is that's mostly useful within a trust domain, where the main thing I wanna, solve here is across the trust domain. So having to, you know, sort of standardize the few fewest number of things across these two parties that have them agree on how do we how do we get access to that user data.
[01:09:06] Arndt Schwenkenscher Schwenkenscher: Okay. Yep. That's fair. Thank you.
[01:09:11] Hannes Tschofenig: I think I'm next. Paul, thanks for the for this contribution. I was wondering whether this would be something that it should actually be discussed in context of the mentioned OAF work, the OAF check work, because it sounds like directly related one very end or one additional use case that we or the authors the group hasn't covered yet. So it looks like it's definitely something some of the authors are probably here even in the room. We should discuss that also on the OAuth mailing list whether that's that's whether this is something that we should pick up as an additional feature.
[01:09:54] Paul: Yeah. I think that makes sense. I think it's kind of at this intersection of, like, of OAuth and then but it's workloads too. So what you know, where exactly does it fall. Yeah.
[01:10:04] Yaron Sheffer: Arun?
[01:10:05] Aaron Parecki: Yes. Hi. One of the authors of the the mentioned IDJacks back in the OAuth working group. Yeah. I I think there's this might be an entirely OAuth problem unless you are trying to bind it specifically to whimsy artifacts, in which case then there's maybe some sorting out to do of where the work best lives. But, like, as a if you are only talking about the refresh token problem, that feels more like it's just an OAuth question.
[01:10:36] Yaroslav: And
[01:10:39] Aaron Parecki: the I'm I'm I'm I guess I'm struggling to figure out the precise problem that you're trying to solve here with, by mentioning workloads. So is it that you are trying to have a workload cluster clustered under the concept of an OAuth client and then identifying each workload in particular for these outgoing calls, in which case that does seem like it should fit into the whimsy space? And then I agree that we're missing something that binds that better to the the OAuth artifacts like refresh tokens. Yeah. I think the that's a
[01:11:17] Paul: better description is is yes. A single client, multiple workloads, not having to do a consent, like, full interactive flow per, per workload, but having that be legible in the the resource in the calendar of which which workload was doing it or which which agent was doing it. I think the the particular challenge is, like, I think you could do this in a couple of places. Like, you could record that delegation's okay in the resource, in the calendar. You could record it. You the calendar could just start trusting the workload, IDP to do this delegation. Or in the case where you do have an enterprise IDP, you could trust the IDP and and try to figure out where which one makes the most sense. If we're already using IDP, just give some consent screens and having the IDP, do it helps.
[01:12:02] Aaron Parecki: So so, like, really quick, I know we're on a long list. It sounds to me like this is not actually, either also tied to the IDP. Like, it it's also a problem whether when there's not an enterprise IDP for there's a regular OAuth case. Yeah. Yeah. Okay. And then the other thing is this also may not be a problem about refresh tokens. It feels more like it's a problem of how do you link a OAuth client to a workload cluster. And if we can solve that, then I think a lot of these things would naturally be solved.
[01:12:30] Paul: Yes. I think that's true.
[01:12:32] Jonathan: Yeah. Okay.
[01:12:34] Justin Richer: Peter and note we are short on time, so let's let's roll these.
[01:12:39] Peter: Interestingly, you said there's no cross domain transaction tokens. Actually, we just proposed the cross domain transaction tokens and that would two different models of designs. One simple combination of an entity training plus existing transacting tokens, and one is a direct request. So I think it's it's just mentioning that this might be a similar work. Maybe we can work together. Great.
[01:13:02] Paul: I'll take
[01:13:02] Yaroslav: a look at that.
[01:13:05] George Fletcher: George Fletcher. I'll just say that what I heard here, if I understood it correctly, is the desire to preauthorize a workload to do something. And so in that context, not saying necessarily go use the spec, but this is exactly what user managed access did. So the Ooma works. So I think this it's useful to go look at what they did in that context and see are there principles or other things there that could potentially be leveraged because I mean, I the that sort of preauthor you know, the the fact that something shows up and it's been preauthorized, like, you know, user isn't present, but it's running on the weekend kind of a thing is exactly those kinds of use cases that user managed access was trying to solve.
[01:13:56] Paul: Cool. Thanks.
[01:13:58] Justin Richer: Brian.
[01:13:59] Brian Campbell: I'll be real fast. Just you mentioned maybe a profile on top of IDJAG. I'm I'm starting to wonder if maybe it's more, like, underneath IDJAG and something that builds on top of identity chaining, which is has a lot of the same constructs, but not the same constraints necessarily as the IDJAG works. So maybe just think about that as a layering aspect.
[01:14:23] Paul: Yeah. That makes sense. K. Thank you.
[01:14:26] Peter: Thank you. Thanks, Paul.
[01:14:29] Aaron Parecki: Alright. Next.
[01:14:30] Justin Richer: Alright. Next up, we don't actually have any slides for this that were uploaded for this next one. So.
[01:14:41] Peter: No. There are slides.
[01:14:42] Justin Richer: There are slides for this one? Yeah. But don't do that. Alright. I didn't see them.
[01:14:56] Peter: They they were mislabeled. They were the ones that was mislabeled. Did I send you a note about?
[01:15:02] Justin Richer: This one? Yes. Yeah. It's it's if
[01:15:04] Peter: open that. It's that one. It's miss it's been mislabeled.
[01:15:07] Aaron Parecki: Oh, okay.
[01:15:10] Justin Richer: That's what you meant. Okay. Alright. We're good. Sorry about that.
[01:15:15] Yuning: Oh, it's okay. Hello. It's Yuning. So I'm I'm I'm here to present some joint work, actually part of the series of work of secure agent communication in Huawei. And today, I want to understand if this is interest in this room to also work on kind of credential management and particularly heterogeneous credential verification for workload and agentic systems. And I also want to get opinions on the problem they have, especially the scope of this problem. So the goals the scope is that we are looking at the receiving side of this workload architecture. So the question is that when a workload or a agent take request carries multiple pieces of security evidence, how could the relying party handles or pro processes this whole series of evidence altogether to make a one request handling decision? And if you look at existing specs, those specs could answer how we could validate or handle one credential family. While in workload and agentic systems, this evidence usually distribute across different credential families. For example, we have the workload identity token that shows whether this workload identity is valid. We also have user dedication token to express whether we have valid user constant or dedication. While the relying party wouldn't just ask in isolation if this or if each credential is valid and then make the decision separately for each credential. So the missing piece we find is that we need to have multi credential request handling mechanism for the receiving side or the relying party. We also find existing use cases in the existing specs or deployments, for instance, if I understand correctly. In OS token exchange 2.0, we have required subject token and the optional actor token to be used together to the authorizing server. And then OOS SPIFI, we could combine the wait suite work like the token and also the client attestation proof of position GWT together for the client authentication. And then for the service mesh policy, we could combine MTLS work identity and also the JWT request that they need together. So we see that multiple credential handling is the reality. And here, we want to clarify that we are not proposing a new credential handling mechanism because there are already stable and multiple deployments for each credential such as for OS. It already has its specific token validation and introspection mechanism. What we're that is missing is what would happen after or around these credential handling procedures. For instance, if we are if we are able to validate already the work token, would that be sufficient enough if the request also is expecting a valid user dedication token, also capability credentials or capability evidence, which is commonly seen in agentic systems. So what we want to do is to have this multicredential handling mechanism or process. And why we think this this is relevant is because we are not trying to standardize multi credential handling for the entire Internet while we are working on multi credential handling when workload identity or identity is used as one part of this whole multi credential bound request. And this is failure mode if we don't have such a common model or a common mechanism. For instance, there could be a silent ignore, meaning that when a gateway or a relying party couldn't recognize a credential type because there are so many existing credential types in the specs, and it may just drop it. And in those cases, though that specific security credential could actually begin ignored in the relying party. Yeah. So what we propose is actually pretty straightforward. So the relying party would receive a whole credential set that is bounded to the request. In this credential set, it contains multiple entries, and each entry carries this credential with that is by value or by reference. And those credentials could contains actual information that is binding to the request, and we could have, like, also set digest to indicate to the relying party whether this credential is just added or removed or replaced. And this call mechanism then includes five steps or could could could it could be more. So the relying party enumerates this whole credential set. It identifies the type of the credential and further determines the corresponding or appropriate verifier or verify class so that it could route the credential to the corresponding or appropriate verifier for checking. And the checking results could be normalized into common verification results so that the relying party or the receiving side could make a decision accordingly. So it's pretty straightforward. And among these steps, we think that type identification and verifier selection are important as something worse to be standardized. Because if we have type confusion and verifier miswrotein, it could lead to kind of, like, verify the fate in the downstream policy that we actually see in our actual implementation process. And we also have a common verification result model. That is because for different credential families, it would have, like, very different formats and for these credential results. However, the relying party or the receiving side needs to see, like, a stable input to be able to make the decisions. So we have defined, like, a minimal set for this common verification result, including, like, the status of the credential and also reason for the status, whether it's valid, invalid, or inter in indeterminate. And they have the credential type and also the verify ID that is either for the following accounting process. And they also have the time window to show when this credential produced and the firstness window. The decision function consumes the verification results from different verifiers and also the decision context. And decision context refers to, for instance, the request type, the risk level, the expected credential types, and also request attributes. This is because a low risk read operation may require fewer credentials compared to a high risk to invocation or task delegated execution. And then it would generate a decision accordingly. So we think what we could or what could benefit from standardization in ITEP could be that we have we could have a credential set modeling, including, like, the binding digest entries and also the credential type identifiers and the registry. We could also define this common verification result model accordingly. They have also implemented implemented this whole mechanism to show that the logics are valid, and we're trying to implement it at different request types. And we are interested to implement different workload and agentic use cases to understand the benefits for other operators. And thank you.
[01:24:27] Justin Richer: Alright. Thank you, Jonathan. We're in the queue.
[01:24:33] Jonathan: So this looks really interesting, but sorry, Jonathan. On for the ages. Do you have to worry about some kind of crazy Oracle attacks where I can see, oh, this this many things failed to this layer, and you'd, like, try and use that to because, you know, complex errors from merging multiple protocols is, well, yeah, Oracle attacks.
[01:25:01] Yuning: So so you're saying if, like, we already have multiple credentials and we are sending them to different verifies, one of the verifies could be attacked?
[01:25:09] Jonathan: Well, so let's say I'm trying to do some, like, guessing of a non no. I'm trying to guess if I've got the right format. And by seeing whether it was this kind of error or that kind of error, I can, introspect into how far it got through the chain. And so by having really specific errors, you can lead to people being able to, like, bite by bite guest keys and that kind of stuff.
[01:25:33] Yuning: That's really interesting, but I think it's it could be, like, more implementation specific in terms of errors in verified identification?
[01:25:43] Jonathan: K. Yeah. It's just a chain all the errors together. That's fair.
[01:25:46] Peter: On time, Pam. Can you hand the mic to Pam, please?
[01:25:49] Jonathan: Yeah. Yeah. Because yeah. One second.
[01:25:57] Pam Dingle: Hello. I'm Pam Dingle from Microsoft. My concern about this is that this feels like credential replay and that many of the credentials you have in that list, how they're how they're sent and who they are sent from are part of the security model. Do you have
[01:26:12] Yuning: that already discussed in in your proposal? Credential replace is definitely part of the security considerations we have, but we we haven't written the draft yet, but we will add that part. Yes. Definitely.
[01:26:25] Yaroslav: Thank you. Thank
[01:26:26] Justin Richer: you. Thank you very much. And our next presenter, please. Kartik?
[01:26:38] Paul: Hello?
[01:26:40] Justin Richer: Here. Let me give you control so you can move the slides. There you go.
[01:26:46] Kartik: Check one check. Am I audible, visible?
[01:26:49] Justin Richer: Yes. You're good.
[01:26:50] Kartik: Awesome. Good evening, everyone. Sorry. Good afternoon. I'm dialing in from Tokyo. It it's, like, 10:30PM here. Got stuck here for some customer deployments and to sort of other issues. I'll I'll be there in in SF. Peter and and Justin, thanks again for allowing me to present here. Sincerely appreciate the slot. So hello, everyone. I'm Kartik. I'm the founder of of GlipZero Labs. We're building something based on pedigree on on agentic AI authentication and authorization and governance and all those layers. I'm happy that in in the first presentation, Brian called it the whippet because it's it's a dog breed, and and pedigree is is dog food. Let's quickly dive in to this. Oops. Oh, yeah. Oops. Alright. So so so the problem here is there the big agents or the meta agents, they end up spawning a lot of sub agents dynamically, and the same agents act on the orchestrators like ambient credentials. So in in this setup, what usually happens is an orchestrator takes, like, one human consent then spawns, like, multiple sub agents at runtime per task. Each sub agent, like, inherits the same credentials, and every hop carries the same authority as the first hop. So to a relying party, every request looks like the same orchestrator, same credential, same authority. So it cannot distinguish between, which agent acted under whose delegation and with what limits. So, the shared credentials fail, three tests. Right? The first one is attribution. Like, which agent did this? The second one is attenuation. Like, how can we narrow the scope of, you know, the credentials and permissions that are getting passed down to these sub agents? Actually, Descartes, a auth protocol rejects, attenuation in in in appendix, b dot three dot seven. And the third test is is enforcement. So, if you look at it, you know, AIP, differs aggregate budget enforcement to the orchestration platform, in its section 7.4, which means that a compromised orchestrator defeats the single layer guard. And I wanna underline that these gaps are stated by the proposals themselves, not inferred by me. If you could take, like, one slide away from from this presentation, it would probably be this one. So here's, like, a quick use case where you can see all three tests in action. Let's say I have a a business trip booking agent that I authorized, with one agent, cons sorry, with one initial consent. This one trip requires, like, five agents. They all share the same credential. Let's say there's a bad charge that appears on my credit card. So the attribution test fails here. Like, the incident response cannot tell, which of the four agents, made the error. Then you have the attenuation problem. Like, for example, if the calendar sub agent gets compromised, right now, it's only supposed to read and write to the calendar, but it also because of its, you know, like, overarching credentials that it received from the orchestrator agent or the ambient credentials, it can also book flights and file expenses. So anything any compromise here can, you know, like, lead to compromising the entire system. And finally, enforcement. Like, for example, any aggregate, trip budget is funded to the runtime. If the orchestrator get gets compromised, it defeats the single layer guard. So what I'm proposing is, you know, this sits right on top of the WIMSE-wimse identity. Like, in pedigree's model, each agent is a workload in the sense of the draft, and it holds exactly one workload credential like a WIT or or a WIC. Pedigree does not re modify or reissue this credential. Like, if you look at my, you know, like, allergy inhaler for a bit, this is the WIC or the WIT. What we're doing is we're we're adding, like, another application layer delegation token on top of it, which narrows down the scope of the tasks. So the SIT is an application layer delegation token that sits, alongside it or on top of it, so that a relying party evaluates three separate inputs, you know, like the workload credential, the SIT chain, and the local policy, together and, with with an operator ceiling, of course, so that, you figure out so the delegation identity answers on whose authority did did the agent make the, action. Here's a quick comparison, across, like, other protocols. I think, most, agent authentication protocols, work on sub like, they they solve the sub agent identity problem, but most of them partially solve or don't solve the scope attenuation, per hop audit or dual enforcement problems that that pedigree addresses. Here's the mechanics on on how things work. I've kept this light. The SIT is assigned JavaScript web token type pedigree plus JWT along with the EDDSA algorithm. It carries a parent chain. It carries, like, scopes, mandates, and they're written in SEDAR by default, a seeding ref, consent chain, and a delegation depth. And the identifiers are are are two they come in two schemes. One is a named identifier. The other one is a self certifying key. And sorry. Wait. Check one, check one. It's still audible and visible?
[01:33:06] Jonathan: Yep.
[01:33:08] Kartik: Awesome. Yeah. Sorry. It just looked like, my screen force, froze for a bit. Yeah. You can find most of this in the draft, so I'll maybe quickly, skip over this. And we're deferring, revocation because, the way we've defined revocation inside this draft is is that when when you're trying to revoke any credentials, it's just bounded staleness and fail closed. It's not explicitly real time. And we're also not, you know, like, doing a lot of work on root anchor key rotation continuity because it looks like Iman Shrock and and Emilia Protocol are trying to work on this. So, yeah, the questions I have for for the working group, are simple. Is is per hub delegation identity for agents, you know, of interest to WIMSE-, because it's like a layer on top of the workload credentials? Do attribution, attenuation, and enforcement capture the gap, that you see right now in in in WIMSE-y. And, of course, you know, like, the drafts, need reviewers. You know, fit and companion work are definitely most welcome. Would love to, you know, like, I would definitely, you know, like, ask the chairs to implore the possibility of, you know, like, adopting this as a part of, like, the working group. So, yeah, that's that's about my time.
[01:34:33] Justin Richer: We have comments. Yeah. We have three people in the queue and eighty seconds. So be quick with the questions and
[01:34:40] Nick: the answers, please. Hi. Hello. It's Nick again. I'm very interested in reading about attenuation. I haven't seen anything yet that really sparks joy for me. So, hopefully, this will do it. I'm I'm I also think this problem is not doesn't necessarily need to be constrained right now to sub agents. I think
[01:34:56] George Fletcher: this is agent to support
[01:34:57] Nick: right now. The lack of ability to edit orchestrator based Apex, level agent model right now, there's really not a lot of an idea around, like, caveats and constraint unless you're using something like biscuits or macaroons, which provide those attributions by default. But even then, it's like it gets a bit dodgy. So, yeah, I'd I'm happy to review. Okay. Bye.
[01:35:18] Speaker 23: Jeff, what else? So your your assumption at the beginning was, like, the orchestrator share the credential with the sub agent. But if there is a proof of position, how does the sub agent can use those credential into the first place?
[01:35:33] Kartik: So that is something that requires, like, a lot more explanation right now, and I don't think I can cover it in, like, the next twenty seconds. We'll be happy to, you know, like, help you out help you understand that on on over email or Yeah.
[01:35:48] Justin Richer: Please please drop that discussion on the list. That'd be a great question. Go ahead, Aaron.
[01:35:52] Aaron Parecki: Yeah. I didn't see any mention of the links between this and OAuth, so I would suggest including that in some of your analysis. But, also, just back to the canonical example, I feel like there might be a different way to model this canonical use case of Orchestrator and sub agents where the sub agents are the OAuth clients, and then you don't
[01:36:11] Arndt Schwenkenscher Schwenkenscher: even have
[01:36:12] Aaron Parecki: problem in the first place of sharing credentials. So there's, I think, some building blocks you could put in place using stuff in the OAuth world that might make this problem go away already. But I'm Got it. Thank you. I'm looking forward provide some feedback.
[01:36:28] Kartik: Awesome. Yeah. Looking forward to all that feedback. Would be happy to take this offline. Justin and and Peter, thanks again for the opportunity. Have a great day.
[01:36:37] Justin Richer: Alright. Thank you very much. And next presenter, please.
[01:36:51] Presenter: Good afternoon, everyone. I'm through. I'll be talking about WIMSE workload attestation. The workload work workload workload calls addresses two security issues. One is who's the caller, and can the caller be trusted? The first, who's the caller is already addressed by Wit and WPT. The the other issue is the can the can the caller be trusted? Right? For instance, a workload can hold a valid identity at running a compromised environment or where the private key is not securely stored, for instance, stored in TPM or HSN. So there's work happening in SCITT where evidence could be bound to a specific TLS connection, but it does not work when proxies are involved. And especially in WIMSE, there are multiple workloads involved, and the request traverses multiple TLS connections. So in this case, that restriction cannot traverse beyond the TLS proxy, and the final back end which receives this request has no cryptographic evidence of the caller's platform or the key street. And that's what this draft is trying to address. Right. So just picking on the existing work of WIT and WPT, this draft introduces two new HTTP headers. One is for workload evidence, which basically carries the evidence in CMW format, and the workload attestation result, which carries the attestation result, basically, to carry both the conveyance models, either the background or the or the passport model, which is defined in the RATS working group. It requires no changes to TLS, proxies, or WIT, and WPT. So these headers can be carried along with the other headers being defined in this working group. The workload evidence will be signed by the platform's attestation key. The workload attestation result will be signed by the verifier, and and the workload public key will be the binding element. It will be asserted in the WIT, proven by the WPT as part of the proof of position, and attested in the evidence or in the attestation results, depending on the convinced model being picked. So a simple call flow just for the background model, generate the key pair within TEE, collect the evidence using JTI as a knowns because evidence requires freshness, and send this evidence in the workload evidence, and basically send the evidence JTI, the WID key to the verifier, which validates the evidence along with the proof of along with whether the public key is also being part of the evidence or not. Right. And and the key binding is the most important aspect just to check whether the the key is being part of this evidence and whether the key protection properties are in place. For instance, the key is non exportable, is generated locally, and those profiles could be leveraged by the verifier to indeed see whether the key is being compromised or not. This is initial version of the documents that we want to see if this problem is relevant for the working group, and we request more comments and suggestions. Thank you.
[01:39:59] Justin Richer: Thank you. Samat?
[01:40:01] Samat: Samat, you addressed it. We have discussed in the SCITT working group. We also submitted a CV, which exists, and it's not sufficient to only relate to that specific public key. Right? It has to be connected to that specific session which we are talking about. And if it's not connected to that specific session, it can come from anywhere in the world. So that's a critical issue. And a CV 202633697 already exists, and a multiple number of CVs are under disclosure. So this is a critical issue that one has to look into before just binding over to the public key. That's clearly insufficient.
[01:40:41] Presenter: So it's not binding just to the public key. It's also binding to the request?
[01:40:45] Samat: Yeah. I mean, request is just like a nouns. Right? So it's what is it? What is the request?
[01:40:50] Presenter: The request has a unique nouns within that. Yeah. So the idea is if it's tied to the request, it cannot be tied to some of the request.
[01:40:59] Samat: It's just a request
[01:41:00] Justin Richer: This sounds like a great conversation for the list. Hank?
[01:41:09] Henk Birkholz: Hi. This is Henk. Workload evidence needs a key. That's right. But platform plus key is very complicated in most cases, especially if you're on a nice set of environment. It is literally impossible, so we have to work on that.
[01:41:25] Presenter: Yes. Agreed. Thanks.
[01:41:27] Justin Richer: Alright. Awesome. Thank you very much. And this one, we don't have slides for, or did I get that wrong too? No. I think this is the one that happened. Okay. Imamshak is up next. We do not have slides in the tracker for this one. Are they online? I don't see anybody by that name. They said they were gonna be presenting remote. I don't see anybody by that name online, so nobody in chat is claiming to be them because identity verification is easy. Okay. So we will do See, I love it that jokes like that kill in a room like this. Alright. So we are going to move ahead to the next presentation. Tom Seto.
[01:42:24] Peter: Seto?
[01:42:31] Justin Richer: I'm just getting the slide clicker for you. There you go.
[01:42:35] Kartik: Okay. Alright.
[01:42:38] Tom Seto: Thank you. Yeah. Good. I thought can get this down a bit. Thank you very much.
[01:42:49] Justin Richer: This is Get right up
[01:42:50] Kartik: close to the mic. You have to Okay.
[01:42:52] Justin Richer: Excellent. Thank you.
[01:42:54] Tom Seto: Right. Sound like repeating everybody's presentation mainly because what we have found is pretty much the same gap people have been working on. So this is a sort of a contribution little contribution I can make. So source mandate JWT and cross principal transaction ID. Okay. So these are the four previous presentations here today. And what we are looking at is one gap, sub agents inherited inherit ambient authority and nothing narrows it nor binds it against operator ceiling. That's a shared problem we are working on throughout this session. So how do we do this? We have dual enforcement system in place. First enforcement is every delegation hub is signed. Each mandate, whether it's route mandate or a human issue or any child mandate is issued a cryptographic signed JWT ED25519 via host library in actual code and not in plain text so that it's not a forgeable claim. Each child mandate narrows one before it and narrowing property is checked at issues, not just the verification time. A child mandate is CEDA action and must be subset subset of immediate parents and never equal in a way that adds anything and never broader. Check it is check against a root grant mainly because if you have multiple hops, you are dependent on the correctness and you are going to be dependent on each hop's trustworthiness. And so you have to check against the parent as well as the root of the grant. The second enforcement is constitutional AI protocol I have, which has three tiers. Tier zero is absolute and constitutional. Tier one is jurisdiction law. And tier two is operators operators own regulation. And critically, every tier is prohibition only. No tier can grant more permission or widen. It can only narrow. CAPS tier are completely separate policy from MJWT delegation chain. It's not derived from not dependent on anything particular mandate says. J w MJWT answers, is this action within what was delegate to this specific agent? CAP answers, is this action permitted at all for anyone regardless of delegation? Two independent gates and no one system feeding each other. So CAP is still independently blocking it and the mandate being valid doesn't mean the action clears caps tier. Both have to say yes. So what I what I want to say is is this what I have created is something everybody else is working on and what I want to do is to contribute rather than to, you know, assert my working. Thank you very much.
[01:47:14] Justin Richer: Thank you very much. Alright. Any questions or comments?
[01:47:19] Tom Seto: K. Thank you.
[01:47:21] Justin Richer: Yep. Not seeing anyone in the queue. Thank you very much. Alright. That brings us to the end of the scheduled agenda. We we managed to get through it, everybody. That was that was a lot. So yeah. Well done everybody and apologies to everybody that I cut off, but as you can see, we kinda needed it. We now we now have ten minutes on the schedule for any additional comments, questions if you wanna cycle back to anything that was brought up and propose sort of a deliberate specific follow on or something like that. There was a lot of proposals for new topics and new work this week and or today, the last two hours. What is time? I think that there's gonna be some really interesting conversation or at least I hope to see some really interesting conversation on the list because of this. Alright? Art, go ahead. Oh, sorry. Yeah.
[01:48:21] Peter: Art, you're up.
[01:48:24] Justin Richer: I want George to
[01:48:25] Peter: go first. Okay.
[01:48:28] Justin Richer: It's Okay. George, you go first.
[01:48:31] George Fletcher: Alright. So I I think there's a lot of really important concepts that have been presented today. I just wanna make a very sort of maybe narrow point about one piece. When we talk about, like, attenuation and narrowing scope and crossing just domain boundaries, you will not get pure attenuation. And we need to be really careful about how we manage that and how we're realistic about it. That's all I wanna say.
[01:49:01] Peter: Hi, George.
[01:49:02] Justin Richer: I was gonna ask
[01:49:02] Peter: you, and what what should we do about it?
[01:49:07] Justin Richer: For the notes, George just laughed and sat down.
[01:49:12] Samat: Sam, what do you address then? I would like to I would like WIMSE to focus a little bit also on the security part, and I would bring out again the issue that we had a long time ago on the list about attestation and how it is bound to the session and all that and the draft that was just presented by also on the same directions. As I mentioned, like, the CV three three six nine seven is a concrete evidence of how one can actually utilize that, and it has a CVSS score of 7.5 in the high critical range sorry, the high severity range. And we have three more CVEs which are in the range of 9.1 being responsibly disclosed, and then two more on the score of 7.5. So I think this is concrete evidence that WIMSE and other working groups which are actually utilizing attestation need to pay some attention to the CVs which are actually now in front of the world already. So I would like WIMSE to not only consider, like, the other things, but but the security part is also others not in the sec area, that that's for sure. But people, when they need to use it, that security is one important part for implementation and, like, to get it out in the world and to be used in some deployment, people do need security. It's not something that we can just put out everywhere, like, that, hey. We are not in the sec area, so we don't need security and so on. I don't think it's a good argument, and I would like that we focus on the security part as well.
[01:50:54] Justin Richer: I just want to address that last comment real quick. We are not in the security area. However, we were founded very specifically to bridge between art and security, and we have a
[01:51:09] Jonathan: maybe
[01:51:10] Justin Richer: that I I forget what the official term is. Was it tech Technical advisor. Technical advisor. Thank you. But yeah. No. This is all very deliberately very security focused work. So if there are, for example, CDEs that speak to the call and not a deployment or implementation, then those are very relevant to bring to the list. If somebody screws up a deployment in their private key on a URL somewhere, we we can't solve that. But the things that are relevant at the protocol level and at the document level, which because those, you know, protocols and document formats, that's that's the bread and butter of the IT hub. Yeah. Definitely bring those up for for discussion on the list. And I do think that it is a a gross mixed characterization to say that anybody here would ever say that because we're not in the sec area, we don't care about security. This is a very security focused group from the very beginning. Thank you.
[01:52:12] Samat: It should show up also in the, like, the the the discussions.
[01:52:19] Peter: Thanks. Armed.
[01:52:22] Arndt Schwenkenscher Schwenkenscher: Okay. I wanted to go back to that initial questions you had in your welcoming slides about work identity federation. You don't need to show it. It's fine.
[01:52:33] Justin Richer: I got it.
[01:52:33] Kartik: I
[01:52:33] Arndt Schwenkenscher Schwenkenscher: do I do see value in talking a bit about it or, like, kind of bringing something up about it. I see it much more being used in the industry. I'm seeing this name being used much more often. It's never been this name before with actually three letters starts to become a thing. I also believe it somehow some sort of matches fits into our charter because we talk about token exchange or exchange in there. We've had a couple of attempts, and there's never been anything substantial coming out of it. But I'm curious when we're whether it's worth framing it or looking at its scope to work identity federation. Yeah. Just putting out there.
[01:53:17] Justin Richer: Really great question. And like I said at the beginning, wanted to highlight this because this is a conversation that is happening out in the world. I had a conversation with one of my PMs who was very excited that three major providers announced with support and then I went and dug into their docs and it was three completely different protocol implementations based on different parts of the o o auth stack, completely incompatible with each other but all branded with. That that's it's a bad whiff. It smells funny. Okay. Thank you. Anyway, to me that speaks to the fact that that is something that our community should be talking about because if we're not, industry's not waiting for us. So, you know, it would as as a not chair, I think that this is a really good idea for us to dive into how deep and what we wanna do with it. I think that we gotta figure that out.
[01:54:13] Aaron Parecki: Charles.
[01:54:13] Charles Eckel: Charles. Yeah. Charles Eccall is your kinda recently become a responsible AD. Just a couple things I wanted to say. First, part two, a lot of great new work proposals there. It's nice to see people looking at those and and interest in those. But I wanna remind everyone of part one and all the this working group last call is going to be happening soon. Please do focus on those because we're you know, we need to finish that work first. Second thing as being involved in the responsibility for the agent proto, buff. Right? We, the proponents there are very interested, very keen in reusing technology that they hope to see coming out of WIMSE, including I know there was a lot of interest here in the KLRC draft, and that topic is of interest to those folks. And so but then also to you here, I hope a lot of you can participate in in that BOF and and see what's being, you know, thought about and proposed there as well.
[01:55:14] Justin Richer: Can you remind us when that boff is happening?
[01:55:17] Charles Eckel: That is Thursday, 9AM.
[01:55:19] Justin Richer: Thursday, 9AM. Thank you. Alright. Pam, can you get to the mic, or we're gonna pass it? Okay.
[01:55:30] Pam Dingle: I guess I should have tried. Hi, Pam Dingle. I I just wanna say absolutely to the comments that we either have to take that turn back or find something else. We also need to find the opposite of it because I don't actually believe that all agents are workloads or that, you know, whatever that relationship is holds. I think, for example, if you have a client ID, a secret, and nothing else, are you a workload? Maybe. So maybe credentialed identity federation, for example, as a as a I don't care what it is, but we need to be able to contrast.
[01:56:08] Justin Richer: So credentialed named identity federation, so we can we can have WIF and SNF.
[01:56:14] Yuning: K? Yeah.
[01:56:17] Roberta: I vanished from the I vanished from the list again. Sorry.
[01:56:21] Justin Richer: That's okay. Go go ahead.
[01:56:22] Roberta: Yeah. Hi. Roberta here. Just to say that it was one of the best sessions related to AI, works related to agents, and and specifics related to authorization and authentication that I've seen in a while. I think what I wanted to say is that I wanted to help. Actually, I I don't know how that process works. I I know that you have, like, technical folks that usually helps to on the research. I wanted to put my name in here. I really believe that some of those works will be fruitful. And I also have an issue with sub agents onto the, you know, the pedigree protocol was was cool addressing this. Those kind of stuff I'm I'm seeing live on day to day. And I just wanted to say thank you for the session and for everything that has been presented here and the the work of so many people. And, yeah, that's it.
[01:57:22] Justin Richer: Thank you. I will say best way to get involved, join the list, read a document, have opinions, tell people them. And, and really at this point, especially since we have so many live drafts that are going through sort of their their last push out the door, really great time to get involved with that. Any new work coming in, there will have to be a a formal call for adoption. That's its own review process as well. Plus, if there's just specific topics you wanna raise one thing I wanna remind the community of, WIMSE-wimse was explicitly founded as a forum for discussion for things that the working group is not actively working on because there needed to be a place for that. We love that that is happening. Absolutely love that. So yeah. Mailing list is is where that centers around.
[01:58:10] Roberta: Another following question. I'm from security as well, and I usually do architectural designs, reviews, and those kind of stuff about threat modeling and all that shebang. Do the this might be useful for, you know, the protocols? Uh-huh. Okay.
[01:58:27] Kartik: Okay. Thank you.
[01:58:28] Justin Richer: Yeah. Alright. Yes. Absolutely. Alright. We are out of queue and nearly out of time. Thank you everybody, and we will see those of you who can make it to San Francisco. And we will have published all of our documents by then. We'll have an empty queue, and there'll be nothing happening. Alright. Thank you all.
[01:58:50] Kartik: Thank you all. Sincerely appreciate the opportunity. Have a great week.