**Session Date/Time:** 17 Mar 2026 03:30

**Justin:** All right, we are at time. It looks like a couple people filtering in, so I'm going to kick off the formalities here. Hello everybody, and welcome to the WIMSE working group meeting at IETF 125 in Shenzhen. I am Justin, and here with...

**Peter:** You are now muted, Peter. And I'm Peter, and we are your chairs for WIMSE meeting at IETF 125.

**Justin:** Yeah, unfortunately neither Peter nor I could make the trip this time around, but a huge thanks to Ory for sitting in in the room to try and keep all you troublemakers in line, as best as he can. So, huge thanks to that, huge thanks to our note taker, and this is the Note Well. Please note it well. I know it's only the second day of the meeting, you haven't seen this a million times yet, but you will. And basically act professionally, treat each other with good intentions, and try to have good productive conversations about the work items. Anybody that is there in person, please use the onsite tool. Please do actually log in because this tells us how many people actually showed up in the room since we don't pass around a blue sheet in the room anymore. This is taking the place of our blue sheets. So please log in. There should be a QR code somewhere in the room, there's usually one on the mic line. Scan that, or Pro-Tip, you can just go to the agenda page and get the links directly from there. Please try to use the onsite tool. Remote participants, of which there are a few of us, unless you are actively speaking or presenting, keep your camera and mic off. This isn't an office Zoom meeting where we need to see everybody. Please keep those off unless you are actively actually presenting and speaking. So, welcome to WIMSE. Getting a lot of mileage off of our radically over-busy AI-generated logo thing. This is all about workload identity in multi-system environments. We have a packed agenda today. Peter, you want to go over how we're going to run things?

**Peter:** Yeah, certainly. Of course we start with our chair updates and then for this meeting we are only focusing on adopted work. So, getting quick updates both in terms of work done but also hearing from authors and editors about the path forward to how we get to completion. We've got a bunch of work we are at the two-year mark now for WIMSE, and so it is time to start finishing things up. And so, not going to read out the agenda for folks. Thanks to everybody who's already contributed their time and prepared presentations for today. And then at the end, I think to wrap up, Justin and I will talk a little bit about... we'll have some time for any other business, but basically starting to think about as we wrap things up, where do we also go next? But certainly wrapping things up before we go anywhere next is critical. So thank you. And then in terms of our working group resources, of course the mailing list is always... please feel free to visit our GitHub and website pages, plenty of links and easy ways to navigate to all of the content that we use in these meetings and that's being developed by the working group.

**Justin:** And speaking of work that's being developed, we have seven active drafts in our working group and have not yet delivered one. You'll hear this theme a couple of times today. We are trying to get these over. We've got one in last call right now and we'll have a presentation on that towards the end. But as you can see, we've got a lot to cover today. We are going to try and keep things pretty tight on the schedule. And as you will notice, with these seven drafts, four of them are relatively new from last time around because if you remember the strange metaphor that we gave you last time, there was this strange elephant of WIMSE credentials just kind of sitting out there and the chairs came along and scared everybody and declared that we are going to break it up into four drafts. And by the way, huge credit to my 13-year-old fox who drew this comic for me the other day when I described this strange scene. He's just like, "I got you dad, we got this." Absolutely love this, it's amazing. So we are going to have presentations for three out of these four drafts. The goal here is of course to turn everything into gazelles, which means we want them to move quickly so that we can actually get things going and get them across the line. Really excited that we have the opportunity here to do that exact thing today. You'll also have noticed on the list that there's been a lot of discussion on other ongoing work. A lot of people are really excited to bring new work on the list but if you want to do something new, you got to help us finish what we've already signed up to do first, right? And we'll hear about the one draft in last call. We've got a few drafts that we are pretty sure are close to last call that we're also going to hear about today. All of this information, the sessions, the slides, recordings from back sessions, all the documents are going to be linked from our working group web page. So please go check that out. And with that, we will have the first presenter up, which is [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/). Wait, is it [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/)? I didn't put these in the right order. It's [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/), right?

**Peter:** That's right, it's [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/), Justin.

**Justin:** Okay, thank you. Sorry, it hid the agenda when I went to pull up the slides on me. Okay, so who is presenting that from the room? I saw Brian walk in, so I'm going to claim it's Brian unless somebody else volunteers. And it's got a beautiful photo on it, so I'm assuming this is Brian.

**Brian:** It is not my photo, as aren't put down there on the bottom left. And I think this is exemplary of coordination amongst an author team that is above reproach. I just found out I was going to do this one a few minutes ago. We haven't been super coordinated, apologies, but I'm going to try to take this one.

**Justin:** All right, fantastic. Take it away.

**Brian:** But I'm not going to finish my peas. It's funny, I enjoyed it. Okay, the [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) draft. Basically, we... yeah, you can tell I didn't spend a lot of time on this beforehand. We recently, as in right around the time of the last meeting, made the decision as a working group and as an editors' team to split up what was the service-to-service authentication draft into its component parts, laid out here. Those are the workload credentials, [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/), [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/), and [draft-ietf-wimse-mutual-tls](https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/). The draft I'm discussing today is just the credential piece which defines basically the workload identity token in JWT format and the workload identity credential X.509 format, which is really just regular X.509 with a little bit of text explaining how you represent WIMSE subject in a SAN, and some security considerations around all that stuff. So what have we done since 124? Almost nothing. Oh sorry, I thought I heard someone speaking. It was out in the hall. We did reference back to the [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) draft and pulled out content where this draft itself was veering into the area of defining the identifier itself and pulled that all out and just directly referenced the [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/), which is a good thing, but we haven't accomplished a lot, my apologies on behalf of the entire editor team for being somewhat remiss in that regard. Yeah, and I'm six minutes ahead of schedule. That's all we got. Kathleen, go ahead.

**Kathleen:** So this may sound like a silly question, but Brian, when you were speaking, you referred to fields within the certificate as the credential. And so, I had been thinking of this all along as the keys are the credential, right? You're going to use your private key to sign content. It would help me as I'm reading through these drafts to understand your usage more then, because I think that might be one of the places where I was misaligned in the language. So just the use of terminology. You're calling a credential the identifiers that are part... that get assigned that are specific to the workload, and I read all of that and I understood all of that, but I wasn't equating... that to me was an identifier.

**Brian:** Okay, I might have misspoken just now a little bit. Are you speaking to the content of the draft or the content of the words that I just sort of stumbled over?

**Kathleen:** The words of a jet-lagged person, I'm sorry.

**Brian:** Okay, I meant to describe it, and maybe this helps, maybe it makes it worse, is the credential is effectively the combination of things issued to the workload through some mysterious magical out-of-band process, but it is the public key pair as well as some kind of binding of that key pair to the workload identifier, either in the form of a certificate where the certificate encodes that identifier in a subject alternative name, or in a JWT where it is... encoded as the subject of the JWT. And I hope that's represented in the draft, and hopefully your confusion was just based on my stumbling of my words previously. But if not, please provide some feedback and we'll try to clean that up.

**Kathleen:** Okay, all right. I will go through the draft again. I did find things like that as I was going through my first pass when all four documents had just split out, but I think they needed another pass, so I'll go through them again assuming the authors have done some work.

**Brian:** We've done almost nothing.

**Kathleen:** Okay, so I'll help. I'll help. Thank you. I'd love to make sure we get these clear so that they're very usable.

**Brian:** Absolutely agree. Thank you.

**Justin:** All right, I am not seeing anyone else on the queue. Thank you very much, Brian, but I think you stay up for the next one if I recall. Are there slides? I don't actually see slides for workload... oh, there it is. There it is. It was just at the bottom of my bad. All right, we're good.

**Brian:** Thank you, Justin. The [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/). This is a picture that I took, let's say it's somewhere near Shenzhen, if not Shenzhen itself. Similar-ish story here, but I have a few more details. There we go. Okay, a little bit of context, kind of the same context. We split these things into four documents. You can kind of see that through the document history stolen from the Data Tracker, but the service-to-service document got split into credentials, signatures, [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) or WPT, and MTLS. I'm trying to show basically we're here in the context of this presentation talking about the [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) itself. And the [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) is the mechanism to take the WIT credential that I discussed in the previous presentation and show proof of possession on an HTTP request, or maybe easily some other type of request, of the private key associated to and bound into the WIT through a sort of simple JWT signature mechanism. So, similar question, what have you accomplished since Montreal? And the answer is not a lot, but a little bit more than the last one. Clarified a little bit of treatment around the JTI claim. The JTI is a standard claim in JWT. We had some confusing language about how to kind of profile and use it. I've tried to structure that just referring to saying it's just a unique identifier. Here's a certain amount of entropy you can put in there to make sure it's unique, and hopefully simplified how that works, as well as the treatment on the validation side, like what you might want to do in checking those for repeated use and some considerations about what that might entail, how difficult that might be in certain distributed environments and what you gain from it. Hopefully, I feel like I just said more there than I actually wrote in the document, but hopefully it's better described and easier to deal with. Fixed some discrepancies between the WPT that was actually shown structured and the example claims. Somehow we got some things out of sync in the examples where the actual encoded content didn't match the decoded content, so that's been addressed. Inlined the ABNF for the WPT... I should follow my own pronunciation... for the WPT header. In the original combined document we had basically ABNF provided for a JWT, which is not entirely necessary but might be helpful both for later reviews of this document from things like the HTTP Directorate as well as some people like ABNF. So we had a single sort of nice definition that was referred to in two places in the original combined document. When we split them out, that cross-reference sort of made less sense to have to go cross-reference two documents just to see a simple ABNF definition, so I just inlined it here for readability. And we added a pretty good amount... and I say that as like one nice paragraph... trying to explain the security considerations around the audience of the WPT, which is really to whom the message, that proof signature message, is addressed and what it might mean in different types of environments where you are addressing that message to the next hop in an HTTP message chain and what it might mean for the recipient of that to know of itself as something through virtual hosting, intermediaries, whatever, as something else and how one might reasonably and securely accommodate those kinds of situations. Hopefully the text that's in there did a better job than I just did of describing it, but that is where we've gotten to. So not a lot, but we did make some changes. What are we going to do prior to Vienna? I note that there are a few issues in the issue tracker. We've tried to label them specifically for the WPT work. Just run through them, there's not a lot here. There's some formatting that seemed a little bit funky that I want to revisit. I would conceptually really be interested in considering transaction tokens as a secondary or even primary example that's being sent in the... not sent but used in the main examples. I think that conceptually that's where we want to see people moving with this stuff rather than passing along access tokens down the chain in a particular context. Either one is legitimate, either one is valid, but I think that sort of even though it's not called out necessarily as the right architectural approach, what people see in examples is often used as examples for their thinking and I would like to steer people towards considering the transaction token for sort of inside downstream communication and there have been some recent changes in that that I think it's now probably stable enough to inline some examples. So that's more a placeholder to consider doing that, but I would like to do it. Feedback always is welcome. There is an issue back to audience which I think this is still maybe carry over and was partly addressed by the audience considerations but we need to look at it. It may have been obsoleted and I notice it's also marked for the credentials draft, which I'm not sure what to do with that. I don't know what the next one is. Flesh out the acknowledgments. All of these drafts are kind of poorly handling acknowledgments and they have big TBDs like acknowledge people, which I always try not to do as an author because I really try to like keep a running list and like properly acknowledge people that have contributed large and small. Like many things, we have been somewhat negligent on this and apologies for that, but please, I'm going to make a request here that if you feel like you've contributed, please add yourself in a PR, drop me a note. I would like to have people properly acknowledged here but we have lost track of it and I apologize for that but please speak up if you feel like you've contributed in any way, not a big deal, but I'd like to see you acknowledged in the document. Including OTH... other token hash format in examples. We added this a long time ago and I'm not convinced we actually want to spend a lot of time on this, so it's just there. And define security goals. As I see my time counting down, this is... I don't know what to do with this at this stage. It's an old issue, I think entered by one of our chairs wearing an individual hat. I think we have in some ways addressed it but I'm not sure we have fully and we've been sort of circling around whether and what to do about it. So just noting it, nothing to do there. And I see the flasher there, so what happens after Vienna? There's another meeting and it was a chance to throw in another picture there. So that's all I got. Thanks everyone for listening.

**Flemming:** Brian, question for you and the author team. So both this one as well as the signature draft depend on the [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) draft, but I didn't really see any extensive plans around what you guys are planning on doing with that draft. There's a bunch of open issues against that draft and it seems to me that it would be important that we get that draft in solid shape before we spend too much time on these other two drafts.

**Brian:** You are absolutely correct in that observation. I think we would like to see them all proceed somewhat in lockstep, but the credentials is obviously the prerequisite for all of that and honestly we've just been somewhat negligent in getting work done on that, but we need to refocus our efforts and get that done. So the expectation is not that these move ahead without that, it's just a byproduct of people being busy and working on other things in the meantime.

**Flemming:** Okay, thank you.

**Justin:** All right, I am not seeing anyone else on the queue. Thank you very much, Brian, but I think you stay up for the next one if I recall. Are there slides? I don't actually see slides for workload... oh, there it is. There it is. It was just at the bottom of my bad. All right, we're good.

**Joe:** I think I might be presenting for Yaron.

**Justin:** Okay, and you're presenting remotely, so I will give you slide control and you should have it. All right, go ahead.

**Joe:** Thank you. Yeah, so we're going to talk about the HTTP signatures kind of proof of possession mechanism for the WIT credential. So, status is we've only made one big change since the last meeting. We're pretty close to working group last call. Of course, like Flemming's point is a good one that really we need to make sure that all of the documents here are kind of in alignment and we don't want to get too far ahead of ourselves. But in general, similar theme, we'll look at this particular problem that we addressed here was in ensuring that we have an audience in alignment with under the signature. This is to kind of prevent this signature, the HTTP signature message, from being reused with some other message in some other context that it wasn't intended. So we've added some text around this. There is a little bit of complexity here in that, well, what we want to put in is the URL that you or the URL that you are trying to connect to. URL's probably not quite the... well okay, URL's probably fine. But the trouble is in some environments that URL that you see is different than the URL that the service thinks it is being addressed by because of rewriting either in the client or on the server or in some place in the middle. So that's the one bit of complexity that we need to account for in the text. But in general, the proposed solution here is that the entire URI including the request target is signed, whereas previously not all of that was signed before. So this takes care of that kind of gap that we had. There are cases where you might have to use a deployment-specific value that you would understand what you would need to do in your specific deployment, but barring that, we would use the request URI. I mean sorry, the entire URI, yeah. And I think that's all we have. So not much change since the last meeting. Brian.

**Brian:** More of an observation than a question, but to say not much is changed and introducing a whole new HTTP header. Okay, other than that, which it stepping back a little bit and just looking at it, it strikes me as very, very awkward. And I have some reservations about that kind of approach. I know I'm sort of divorced from this draft right now, but I would not personally want to proceed with that kind of construct. So I just want to maybe be on record as saying that. It feels real wrong for a lot of reasons that are hard to articulate other than just a general feeling like it's the wrong approach to the wrong problem at the wrong layer with a weird name and I for one will be glad not to try to explain to Mark Nottingham what this new header does but I look forward to watching you or Yaron do it in the most friendly way I can say here on the mic.

**Joe:** Okay, do you have a alternative? Because do you think that audience is important? I mean...

**Brian:** I think that for the things that you're trying to claim you achieve with this signature mechanism, signing some part of the actual authority piece of the request is important. I don't think that introducing a new construct and trying to jam some identifier from a different layer into the signature while still ignoring the authority portion is the right approach. But I know that you guys have talked about this a lot and this is what you've tended towards. I just want to have something that I can point back to on the records here, I guess, in the archives to say that was in fact not a great idea and there are dragons there. Yeah, it just feels real wrong for a lot of reasons that are hard to articulate other than just a general feeling like it's the wrong approach to the wrong problem at the wrong layer with a weird name and I for one will be glad not to try to explain to Mark Nottingham what this new header does but I look forward to watching you or Yaron do it in the most friendly way I can say here on the mic.

**Joe:** All righty. Thank you, I think.

**Justin:** Perfect. Any other? All right, I don't see anyone else on the queue. Thank you Brian, I think that was within the Note Well be nice category. Ory didn't kick you out so I think we're good. Thank you Joe and we will go to the next bit. We do have some time at the end if there are sort of follow-up questions that anybody has here. Next up actually is Joe again with the [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/).

**Joe:** If you pick the one that says the update, I don't know which one it is but it doesn't really matter if you don't. I uploaded two decks accidentally... or not accidentally, on purpose.

**Justin:** Okay, so that is update. There it is. Yep, I got it.

**Joe:** Probably should have just used the same name and it probably would have worked out fine but I...

**Justin:** It does replace it if you use the same name. So I'm going to hand you control, reset your timer and we're good to go.

**Joe:** All right, so I'm here to talk about WIMSE the architecture draft and this is on behalf of my co-authors Yaroslav and Hannes. We're on draft number 7. Lucky number 7, let's see. So updates since last IETF. We've done a couple things. We've completed the move of the identifier text to the [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) document, which was a pretty important thing to do since that document has a life of its own. We've redefined or not redefined but we've defined workload instance in addition to workload. Those definitions are on the next slide. But one of the things we're not going to get into here is what exactly does identifier refer to in these cases. That's something that's more of a topic of the [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) draft which is after this presentation. We also spent a little bit of time revising the bootstrapping section which caused a lot of discussion in between the last IETF and in between times. We tried to improve the text on attestation to really what we're looking at is attestation within the context of this bootstrapping process and it's not the only thing that could be done with bootstrapping and so we've tried to clarify some of those things and show where there can be variations from the diagram that we had there previously. So please take a look at that. This section is still a work in progress. I know that there have been some suggestions made, I didn't get a chance to incorporate those before this IETF but we'll be looking to do so soon after. And thank you for everybody who's made comments and similarly to Brian's comment we do need to make sure that we have people acknowledged for this document. There have been a lot of people contributing, I have a pretty good idea of who they are but if you feel you've contributed either drop us a note or pull a PR and we'll take care of it. Okay, next slide is the text for workload instance. So we have the workload text which is pretty similar to the text we had previously. A workload is an independently addressable and executable software entity. This may include microservices, containers, virtual machines, serverless functions or similar components that initiate or receive network communications. A workload typically interacts with other parts of a larger system. We've also added a definition for workload instance so that we can start talking about these things kind of separately because Flemming and others have made a lot of comments on it'd be important to distinguish what an instance is and maybe other things as well. So a workload instance we have right now is a single running instantiation of a workload at a point in time such as a container, a VM, a serverless invocation. Workload instances may exist for a very short duration of time, a fraction of a second, run for a specific purpose such as to provide a response to an API request. Other kind of workload instances may execute for a very long duration such as months or years. Examples include database services and machine learning training jobs. The number of instances for a workload may vary over time due to scaling, failover or orchestration behavior. So if anybody has any concerns about this text, we can discuss it now, if not certainly can discuss on the list or in the repository as well. Hank.

**Hank:** Hi, this is Hank. I don't want to over-complicate things, but I want to ask if it's relevant for instance that it kind of is aware of or the consumer of the workload instance information is kind of aware of what the platform is providing as a capability to the instance or is that irrelevant to the instance? Some instance can only exist if it's running, it's running on something. Workload itself is very abstract. Instances rely on the capabilities on the thing they're running on. Is that relevant for the definition of an workload instance that it is relying on the capabilities it is running on or is it over-complicating things?

**Joe:** I think that's over-complicating things. I think... but like those details may come out in other parts of the system. But like as far as like what an instance is, it... yes, it is running somewhere.

**Hank:** Because that is a point of attestation, right? I mean if you ignore the thing that an instance has to run somewhere I don't understand the differentiation.

**Joe:** Well, I mean maybe it does need to be in the definition. I don't know that it significantly adds to what we would do. And the other thing is what it's running on can also have an identity, right? It could itself have an identity.

**Hank:** Yeah, that's the point. That's what I was will be eluding to because both will have to be combined for some some other purposes so if you've basically built in a so to speak a semantic interface in the description that is running on something then the thing that it runs on can also in the specifications build a semantic interface to that it has an instance running and then later on we can have documents that don't have to remediate that because they can just point to this. But this is just again maybe over-complicating things just food for thought.

**Joe:** Yeah, okay. Thank you. Kathleen.

**Kathleen:** Just trying to help. So I think it can stay separate. I see where Hank is going and that can be a layer added later I think. So I think there's room for it with what you have, it doesn't preclude what he's talking about coming at a later point in time. So I think that's better.

**Joe:** Okay, yeah that sounds reasonable to me. Yaroslav.

**Yaroslav:** Yeah, I think there are two ways to address this without breaking the architecture. For those deployments where instance location or host matters that can be encoded in path of identifier so you could say VM something something or you could have Kubernetes something something that would identify that but that obviously would be your deployment specific thing. Another way is attestation, I mean you could attest to a platform where you're hosted and then you could have all sorts of wonderful cryptographic evidence associated with that.

**Joe:** Okay. Next slide. So we have some issues that we need to go through. This is a summary of some of the more main ones. A lot of them have to do with aligning terminology between the set of documents we have. There's some text on what happens if workload has multiple credentials that it uses with different parties say at different layer so some clarifications on trust domains. Complete this revision of the bootstrapping section and then think about if we need to talk about key management at all. Probably we need to say maybe a little bit more than we do but it's probably somewhat out of scope of the whole thing unless we decide to bring it in which would probably belong in a separate document. And so then the kind of timeline, so we'd like to resolve the existing issues and align with the other drafts by the next IETF. Question sometimes we have interims, I'm not sure if we need one yet but if we did it would probably be on specifically aligning with particular other drafts or making sure that we're all coherent between our various pieces. Thank you Joe. I'm going to move us along to the next presentation. Yaroslav, you are up next.

**Yaroslav:** Hello everybody, I'm Yaroslav on behalf of myself and Joe. I present workload identifier update. So we're right now at revision 2. So there are few changes that we have done since 00 which we presented last time. So defined workload identifier origin within as a subset of identifier which consists of scheme, trust domain. So sometimes you need to have a hint saying what scheme you speak to and what trust domain you speak to without having to disclose your full identifier. So I will be proposing an extension to TLS that would help facilitate MTLS with with this kind of origin some sure there are other applications for that as well. Removed overlap with service-to-service credentials work. So in previous revision of draft there were some unnecessary text about how you use identifier in credentials, no longer there. I love removing things and added URI requirements as discussed at previous IETF meeting that is how long the URI should be, what the minimum URI you must be able to process and so on and so forth. We've also moved WIMSE URI scheme definition from service-to-service set of drafts. Right now the WIMSE URI is very simply defined by well it exists, you can use it. It doesn't impose any restrictions in terms of how you form path and how you provision. If anybody feels strongly that we should be opinionated in terms of structure of the path or some restrictions there, let us know, but right now it serves really as a kind of fallback mechanism so if you don't want SPIFFE because it's maybe too opinionated for you, too restrictive, you don't want other things, you want some kind of fallback that's what WIMSE scheme is for. And also spelled out that identifier may apply to individual workload instances and logical workloads. Right now again we don't really want to be opinionated in terms of how you construct path there are maybe privacy, confidentiality challenges with if you want to differentiate it in the path or not other deployments might feel strongly about it so it is down to implementor to decide how you want to build your path. So we have received number of reviews, so I'd really want to thank Fletcher, George and Yaron for their reviews and opening bunch of issues on GitHub. We've joined did our best to address some, there are some that are open but are fairly straightforward but there are few that I wanted to bring up to a wider group and since we have 5 minutes and 20 seconds on the clock maybe there will be some comments on those issues. So first, do we need WIMSE identifier scheme registry? So right now we're just using the regular IANA URI scheme so you can use anything you want. One issue that is opened maybe we should have our own registry. So far authors think that the answer is no. If anybody thinks otherwise, add yourself in the queue or give it a little bit more thought. Okay, that's easy. And then next issue is WIMSE scheme schematics. So issue 25 do we want additional WIMSE requirements or should we leave it flexible? Do we want to define separation separate notation for path specific to individual workloads versus services within within WIMSE scheme? So again authors think that the answer is no. We want to keep it flexible but if somebody have different opinion now would be a good time to express it. Okay, that's easy. And then the last one is align terminology. So there is a bit of overlap across our current pile of drafts with service-to-service architecture identifier in terms of where things defined and how they are defined so we have an open tracking issue to align all of that, ideally we want to define everything once in a single place and then refer to that place from other drafts that are reusing this definition. So certain things will certainly be defined in architecture, maybe some other things that are very identifier specific will be in identifier so we again are tracking that and if you have an opinion on what should be defined where let us know, now again is a good time to to share your thoughts. And then finally, we would really like to move this document forwards sooner rather than later. It's fairly straightforward concept and work outside of WIMSE will depend on stable workload identifier especially when it comes to the exciting the world of Agentic AI. So we'd really like to be in a position of asking for working group last call at the next IETF meeting, which means please do read current draft, open issues if you feel there are some, share your suggestions, comments the more we do that, the more mature the document will become, the more chances are that we will be in a position to ask for working group last call in Vienna. Oh, we do have two people in the queue.

**Flemming:** Yeah, I just wanted to acknowledge the updates that were made to both this and the architecture draft. Appreciate those and I think both drafts actually in pretty good shape and definitely on the right track. So kudos to the authors.

**Yaroslav:** Thank you and thank you very much again for for your reviews.

**Peter:** And hi, this is Peter. Actually I just want to say I like the WIMSE URI scheme because you usually I hate to speak about AI agents but applications, you know, considerations are happening everywhere so I think the problem is the public domain is trying to define some kind of global parsing mechanism that's must consider the gaps between the global resolution versus local resolution and consider the global may use DNS or similar infrastructures so the first top-level identifier could be the trust domains of each different administrative domains. So I think this could be a really good design to help connect the global and the private administrative domains. Thanks.

**Yaroslav:** Thank you.

**Justin:** Looks like we're drained in the queue. Thanks everyone. All right, thank you very much and Arnt you are up next. There you should have the slides.

**Arnt:** Thank you. Can you hear me?

**Justin:** Yep, go right ahead.

**Arnt:** This is [draft-ietf-wimse-workload-identity-practices](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/), I'm presenting on behalf of my co-author Yaroslav. Yeah, so this is currently the draft that is in working group last call and since the last IETF we got two reviews, one from Kathleen, one from Joe. I want to quickly go over the review items. All of them are valid. We did not have the time to publish a new version but I would say maybe next week we would publish it. Yeah, so Kathleen found a couple of things. We were pretty much unclear about what's identity, what's credential and there's like mixed those words up in the draft so we clarified that. We also clarified what federation actually produces, sometimes we said credentials, sometimes we said identity. We wanted to have consistent terminology across the credential types. In the draft we mainly talk about JSON web token but we also have X.509 certificates in there and also to tighten a bit the SPIFFE terminology in there. Yeah, Joe also gave us a review. One part he saw is that if you are a workload and you want to federate to multiple identity providers, you always want to have an own token for every one of them, right? You don't want to have one token with multiple audiences, you want to have dedicated token for each of these identity providers you would federate with. So that has been clarified. He also proposed consequences for security considerations. So prior we said you should not do that and Joe added what would happen if you would sort of thing. So that's very good. And he also asked to differentiate from the workload instance document and that is an interesting aspect I wanted to bring up. So workload instance document is a bit undefined here. There is not really a name for it but cloud providers offer instance metadata endpoints most of the time on a non-routable IP and they often issue two distinct types of document. One of them are access credential. AWS IAM roles, Azure Managed Identity, GCP service account, for example. And they those can be used to access resources within the cloud, you want to upload something to some storage bucket, CDN, access a database. You often get those already audienced and particularly for that cloud environment whatever identity technology they may use. On the other hand, these instance metadata endpoints also produce signed documents that contain the metadata about whatever you're running this on. It's a lambda, a GKE cluster or an Azure VM and it contains account, region, type, name, labels whatsoever. And those two things need to be distinguished and it kind of results in two different flows. So for example, if you want to access resources, you use the access credential part and if you want to federate you use the signed instance metadata document. That's at least where I got to. Yeah, it's an interesting part where we don't I don't think we've ever talked about it so I wanted to bring it up. We're still proposing text for it. I also looked at how it looks for Kubernetes, SPIFFE and CI/CD patterns and service meshes. Those platforms don't really differentiate there. It's mainly the cloud providers that do but yeah. Yeah, so this is currently happening and yeah in general this has been in working group last call for a while so please please bring in the reviews. And I also want to acknowledge everyone who has contributed over time. It's a lot of people. I believe this has been the first WIMSE draft even before WIMSE was a thing. So let's get this over the line. Thank you.

**Justin:** All right, thank you very much Arnt. I'm not seeing anybody in the queue. I do want to ask a question of the room. Who here can commit to actually providing a last call review of this document? We had a couple of people volunteer at the last IETF, we got a couple of those in but the chairs would like to see a little bit more wider consensus of like even a just "yes I read it this makes sense this works". We need to see that before we can really feel comfortable kicking this over the line and believe me we really want to kick it over the line. So is there anybody in the room or anybody in chat that would like to put their name out and volunteer to do a last call review of this document so that we can move this forward?

**Peter:** Flemming offered to review. Thank you very much, I appreciate that. We will write that down and remember you. Kathleen thanks for offering as well to do another review once the updates are made.

**Arnt:** What I can offer once we have the new revision out I'll put it on the mailing list and maybe the chairs can issue a re-working group last call based on that to remind everyone.

**Justin:** That would be totally fine. Oh Lucia Rodriguez is also there. Thank you very much. And Brian thank you. Third times a charm. All right, thank you all very much. At this point that is the end of our presentations but we have a few minutes to discuss sort of any other business. So the mic lines are open. I do want to know if anybody has anything that they would like to discuss here. Give folks a second to sign up. In the meantime, as a reminder, the chairs have asked the editors of the credentials and related documents... well the goal of splitting up the documents was so that we could progress them as a loosely coupled independent group. And I personally heard a lot of "there hasn't been a lot of work done" and that can sometimes be an indicator that there's not a lot of work to be done. So my question to the editors as chair is is that the case? Are we basically nearing the end here, should we be looking out for working group last calls all around soon or do you think we need a few more turns around the sun here before we can actually get to that state? And I'll take any and all sentiments from our cadre of editors here. Yeah, go ahead Brian.

**Brian:** Kathleen's in the queue.

**Kathleen:** No, but you're directly addressing his question so go ahead Brian.

**Brian:** To try to address that I think more the former is true although I think we're very close but we have been somewhat negligent in getting around to like just doing the final bits of work which was the former it's 12:30 in the morning I don't know what order I said them in... that there's not a lot of work to do might be an indicator that we're close and I do think we are there while at the same time acknowledging that there's some stuff we just need to buckle down and do. So I think we can get to working group last calls pretty soon.

**Justin:** Okay fantastic. That's great, it was also the impression I was getting but you know good to hear that from the editors. If there's anything that the chairs can do to help that if you need us to scare more reviewers out of the Savannah brush to help you run faster this metaphor went in a weird place we're happy to do that and any way that we can help support. If interims will help I think Joe you mentioned maybe having an interim for architecture doc but if interims will help please let us know. We would like to do anything we can to help things move along more quickly. Yes they will let us put so many interims up. All right Kathleen, thank you for your patience. Go right ahead.

**Kathleen:** Sure, I'm just trying to help you get more reviews on docs so if somebody is newer to the IETF and has been paying attention to this working group who's interested in workloads and identity starting with this first draft would be a really good one once the next update comes out the terminology gets smoothed out because then you could meaningfully walk through all of the drafts for the working group and contribute in a very meaningful way and I'd say anyone that was up at the mic would be willing to answer questions if somebody is new right so reach out to people who are comfortable at mics because they've probably been in a few IETFs and most people will help.

**Justin:** Excellent excellent points thank you Kathleen. Peter you added yourself to the queue go ahead.

**Peter:** You're muted. Of course. Thank you Justin. One other option or one other observation just for the working group in general this time around because we chose to very specifically focus only on previously adopted work. We also offered interims for new topics or topics in the past we had folks come and present new topics in the the meeting the offer is has been made if there are topics that folks want to cover in interims please let us know happy to to schedule if there is interest on the mailing list to explore those further. Thank you.

**Justin:** Yes absolutely if post to the list to try and show that there is interest in a topic we are very happy to schedule an interim around anything specific even if it's not directly WIMSE work as folks may recall one of the goals of WIMSE was to create a forum for discussion around workload and related topics so you know very happy to to create that forum and the interims are a great way to do that as well. So with that I think that about wraps us up. Thank you all for coming and we will see you in Vienna. And thanks to the note taker and thanks once again for sitting in Ory. Thanks chairs. Bye. Bye bye. Bye. Bye.