 Yeah, so Chelsea, you know, did a really great kind of tour of, you know, Spiffy and the capabilities that it has and talk a little bit about the problems that we're trying to solve there. You know, there is this other project, which is the sister project called Spire, that is the software, a software implementation of Spiffy. So what I'm here right now to give is just an update on the Spiffy project alone, so not, you know, too focused on Spire. Augustine will give an update on the Spire project next. So this is more just about kind of like the Spiffy specifications and all the things going on in the Spiffy community in particular. So as the Mayor mentioned, my name is Evan Gilman. I'm a maintainer on both the Spiffy and Spire projects. I've been around those projects for quite some time now, almost four years. So effectively the beginning of the projects. And the first update that I wanted to share with you in the context of Spiffy today is about the, what we call the technical steering committee or the TSC. Let me see if I can write. So the TSC, as I mentioned, stands for the technical steering committee. And in the beginning, when we first started the project, the purpose of this group was really to kind of act as like a sounding board to make sure that the folks who were actually writing the code and writing the specs were kind of pointed in the right direction and, you know, ruined all in the right direction, but also kind of going towards this strategic goal. And to fulfill that purpose, the TSC was comprised of folks from the industry who have a lot of experience with this particular problem space. And we've seen them firsthand and understand what is needed in order to solve it well. But over time, the esteem gained in the project. The contributors and everyone else kind of gained a lot of understanding of the problem space and what works and what doesn't work. And so over time, as this happened in adoption, grew, you know, that original role of the TSC became less important. And they became less engaged on a day-to-day basis. But still there, you know, this technical steering committee group is still kind of codified in the project governance. But in this state that they were in, where they weren't being relied on so much, and the purpose that they were originally trying to fulfill is not as important as it used to be. You know, we have to kind of ask at some point, you know, is this body still needed? And if it is still needed, then what is it needed for? What should the responsibilities of that group be? You know, we have some rough ideas of what that group should be. You know, it's first of all, it's the only group with that kind of sits over the top of both the SPIFI project, the SPIRE project, and all the libraries and helpers and other kinds of things that fall under this big SPIFI umbrella. And because of that, they're positioned really well to give feedback to those individual projects, to coordinate across them, and also to do like gap recognition and things like that, where are things not being filled that we need to fill? So, you know, we think that this group is still valuable, but in order for it to deliver that value that we think that it could deliver, we need to formalize a lot of these, you know, responsibilities that I just described. And so what that really boils down to is that we're working on a new charter for the TSC to describe what those responsibilities are, what the goals of the group are, and really kind of write that down and formalize it as part of the project governance. Once that's done, we'll be in a position to evaluate the composition of the TSC. You know, so the group that we have serving on the TSC today is still the kind of original group from the very early days of SPIFI. And once we have this new charter, you know, we'll be in a position to say, look, is this group composition still ideal? And if not, what should it look like? You know, should there be vendors as part of this group? Should there be users as part of this group? Both of those things are none of those things. So all of that is being explored right now. And we're still, we're kind of in the early stages of getting all of this stuff codified in order to push it through the existing TSC group has stepped up their meeting cadence. And we hope to have that work wrapped up by early next year. Next, we have a couple of new SIGs. And SIG stands for Special Interest Group. And these are like long-lived groups of people who each group has their own kind of specific focus. They don't necessarily have a goal, you know, it's not like there's no real kind of like finite life cycle applied to it. It's more to kind of handle the ongoing concerns and areas of focus in the SPIFI-inspired projects and the related sister projects. We have two new SIGs that have formed in the last six months. First, we have one that's called SIG Community. And the focus of that SIG is the nurture and growth of the SPIFI community, you know. So it's everything from, you know, organizing events and webinars, educating people about SPIFI-inspired to, you know, the blog posts and Twitter accounts and all that kind of stuff and all the other outreach tools that we use to communicate with the community. It's also about ensuring that the community continues to be warm and welcoming and that everyone feels that they're welcome to be part of the SPIFI community, to point people in the right direction, point newcomers in the right direction. And finally, to measure that community growth and overall health. So we meet that SIG meets once every two weeks. I didn't mention, but if you'd like to get involved in many of this at the bottom here, I have the link to the Github, the SPIFI Github repo. If you go there on the read me, you'll find information about all of these recurring calls, how to join them, the mailing list, calendars, all that kind of stuff. So if you'd like to join the next SIG community call, you can find information there. Similarly, the TSD that I was just speaking about, those calls are also public and the call information can be found on the read me there. And next we have a new SIG called SIG SPIRE. And that SIG is focused on primarily SPIRE development and not necessarily kind of like day-to-day stuff and not really kind of to be used as a help channel more is kind of like a strategic channel, a venue where we can discuss various proposals to the SPIRE project coming in from the community to give high bandwidth discussion between the maintainers and the SPIRE users to share thoughts and ideas about the roadmap and the things along those lines. So that has been going on for a couple months now. It also meets every two weeks and the call is so far been very well attended. So these new SIGs, these two new SIGs are joining an existing SIG called SIG specification or SIG spec for short. And that SIG is focused on the maintenance and shepherding of all the specific specifications themselves. So including day-to-day maintenance of the existing specs and also development of new and upcoming specs. We meet generally bi-weekly and for the last year, so that group has been working on federation. And we are very, very, very close to finishing that work. There are a lot of questions about federation and Calcius Talk. And this is like a really important concept because what it does is it enables communication to happen across these different trust demands, this concept of different authorities or different sources of trust. There's always going to be more than one and maybe not in the same company organization, but between companies or it can also be in the same company or organization. How you do this is actually like loosely described in an existing specification, the existing SPIFI specification called the trust domain and bundle specification. And SPIRE actually already implements SPIFI federation. So you might be asking like, why do we need a new document for this? And the reason is because the existing definition that we have in the trust domain and bundle spec is not very strong. It likes the path to how to accomplish it and is enough for someone to get going and get it working. As I mentioned, SPIRE already has it. But the language that is currently there is not strong enough to guarantee interoperability between different SPIFI providers or different SPIFI implementations. So that's why we're working on this new doc which has much stronger language and a lot more clarity and detail about exactly how this should be accomplished, what is allowed and what is not allowed. With the goal there ultimately being to enable this interop. But we're going to talk more about how federation actually works in a later talk today. So what's left in this work so far is I would call the existing, like what we've got so far to be feature-complete. It's been feature-complete for quite some time. What we're working on now is primarily like the structure of the document, the clarity of the text, making sure that all the questions have been answered and that kind of stuff. And so we're on kind of like this last push right now to get it out the door and get it done. So we've stepped up the cadence of that call as well we now meet weekly. Again, if you'd like to get involved in that work, you can find the call information at the GitHub repo. And we hope to be done with the spec in fairly short order. And then looking forward, once that's completed out the door, we have a couple things on the radar for SIG spec. We've received a lot of questions from the community about claims. SPIFI currently allows claims to be set on its S-fibs. And by allow, I mean, it doesn't really like forbid them. It also doesn't say that you have to use them. And it also doesn't define them. So what we're exploring now are use cases to try and figure out if that's good enough or not. Does SPIFI need to codify a claim definition at the spec level for any reason? And if so, what does that mean for interoperability between trust domains and between different SPIFI implementations? Or is it okay to just leave it to different implementations to do as they please? Next, there's a fairly strong desire for what is loosely known as token 2.0. And if I were to describe this, it's basically what we're looking for is we're looking for something like a Jot. We're looking for a security token that can be transmitted at layer 7 at the application layer so it can punch through proxies and things like that, like Kelsey was talking about. But we're looking for something with better properties. So I think Jot falls short in two different ways right now. The first is that they're easily replayed. So somebody who sees a Jot can grab it, copy it, and stick it on a different request and replay it and act as if they are the original caller. We would like to prevent that. If at all possible right now, we mitigate by having really short lifetimes so that they expire relatively quickly. But we're exploring concepts around being able to bind a token to a particular request so that if it was replayed, it could only be replayed with the same request that it was originally issued against. Another thing that we're looking at is how we can delegate signing of these tokens right now in order to get a token. You have to go to a centralized authority to get one signed for you. This comes with performance implications. It comes with availability implications and all of those things we manage and inspire but it's not ideal. So we're exploring methods and ways that we might be able to have those minting and signing operations be distributed such that we can get better performance and availability properties out of it. But all of that is pretty hypothetical at the moment. There's still a lot of exploration to be done there and we're not quite sure what that's going to look like. But one thing we know is that there's a lot of interest on both within Spiffy Maintainership and from the community as well. Finally, maybe just speaking for myself a little bit, I think we could take a short break. The last one year of Federation work has been pretty tiring for us or for me in particular, I guess. And so once Federation has done, we're hoping to dial the cadence back a little bit as we go into more of this kind of research and discovery mode of these different things that I've spoken about here. There's always going to be kind of ongoing maintenance overhead associated with the existing specs. So of course, we continue to meet for those things. But the volume there is decidedly quite a bit less than the volume one for developing a new spec. So that's all I've got for Spiffy updates. So I'll stop and see if there are any questions about any of that. Yeah, I know we have a bit tight on time, Evan. So if are there any questions, maybe you can take one. There's one by Sunil. Evan, do you see it? What is the timeline for having development work for Federation development work? Well, I mentioned that the Federation is actually already available in Spire. And the implementation that Spire has is very, very, very similar to what the specs are working on now. And if you go and look at the existing trust domain and bundle spec, you'll see that we actually talk about how Federation can be accomplished. And we point you in the right direction. So this new spec is just kind of about crossing the T's and dotting the I's and, you know, being really, really clear about what kind of what aspects of this are going to be required in order to get interoperability. In terms of timeline as to when that spec will be finished. It's hard for me to say. Like I said, we stepped up the cadence to try and get it out the door sooner rather later. But we are rolling into the holidays. You know, so it would be nice to see it before the end of the year. But we'll see. In the meantime, I recommend you go read the trust domain and bundle spec. You can also read the Federation spec that we're working on if you join this expect Google group. And you can also you can also go and check out the implementation that's in Spire and see how we've been out there.