 Hello, everyone. As mentioned, I'm Zach. You can find me pretty much everywhere at Stiza. And I am one of several people working on the integration between NPM and Sixdoor so that NPM packages contain verifiable links back to their source code and also their build instructions. As we've undertaken this work, there's a couple of issues we've uncovered with OIDC tokens. So I'm here to talk about some of those things to be aware of as you work with OIDC JWTs as well as point out some problems and at least one case suggests some possible solutions. I think that lots of people in this room know this better than I do, but just to kind of zoom into the one specific part that we're talking about in the Sixdoor ecosystem, this is the so-called keyless signing flow. So you're in a cloud CI-CD system. You're building your NPM package. And then in order to get your signing certificate from Fulcio, you call Cosign Signed. You include the OIDC JWT from your CI-CD system. And then Fulcio looks at those attributes, burns it into the sign certificate, which it returns to you, and then you can attest to those build properties. So in particular here, we're talking about the OIDC JWT that comes from the cloud CI-CD builder that you send to Fulcio. So what does that look like? I was actually scooped by others at from Sixdoor. I think he was the first one to put the OIDC JWTs up. This particular example is from GitHub, but it's important to note that our implementation in NPM is going to work with any cloud CI-CD provider that supports OIDC JWTs and has specific properties. There's a link on here to the GitHub docs. I should have posted a link to these slides. If you go to coffeehousecoders.org, I've linked the slides there as well, and I'll put them in Slack after this talk. There's a number of attributes on the left that Fulcio is already looking at that we're going to talk about in more detail. And then I've added some additional attributes on the right. In the different providers, these fields have different names, but we're hoping to work with all cloud CI-CD providers to provide this information in one form or another. So the first security consideration I want to talk about is data privacy. This is a very tricky one. So first of all, just to highlight, there's some things in here that you might consider PII. Of course, if you're part of an open source project, this information is probably already in your public source repository, so it might not be considered that sensitive. But some governments are talking about a right to be forgotten that we'll come back to in a second. So I just wanted to highlight here the name of your branch, the name of your account, the name of your repository, the name of your build workflow, and also the name of the file of the build workflow. And so less so for open source, but maybe if you're using this for an inner source or other enterprise application, you want to be careful about sending this information to public servers. Other people will be able to see it. It's not exactly clear what a right to be forgotten means in this context. Certainly people are voluntarily sending this information to Fulcio, but then in the future, if they don't want this information to be publicly available, it's not exactly clear what that would look like. So I think that's going to be an ongoing conversation in the community, how we might support or handle those types of requests. The second consideration is a custom audience. Sixdoor is doing a great job here, 10 out of 10. When customers or when people are provisioning these OIDC tokens in their cloud provider, we want to ensure that they are doing so with a custom audience. This is so that you can't use a token from one compromise system to another one if someone was able to compromise one of the systems that's receiving these OIDC tokens. The cosine already handles this for you. If you're using the workflow instructions, it will call into the APIs to ensure that that custom audience is there. But if you're operating a cloud CIC provider, be sure to allow people to do this customization. And then if you're building some sort of integration, ensure that you're using some sort of unique string so that people can take a token and forward it on to another service. And then the last issue, I don't have a great solution for. So in addition to having the repository name or the organization name, those resources can actually change. Maybe a company gets acquired. Maybe a personal project becomes a company project. Maybe someone just decides they don't want something to be open sourced anymore and they delete it. So the way this is being handled currently in the GitHub OIDC token is that in addition to including the repository and the repository owner, we also include these fields repository ID and repository owner ID. And if the resource is deleted or renamed or otherwise recreated, we guarantee that this value will change. What exactly we do with these values? It's not clear yet. Full CO isn't looking for this information yet. Arguably, this isn't something that six doors should have to solve. Maybe this is something that package managers should consider as they're accepting these signing certificates. And I would like to discourage us from saying that end user should handle it. That they probably already have enough to worry about. It'd be nice if we could do something that more transparently let people know when an underlying resource that an attestation points at changes. And that's really it. Those are three security considerations for thinking about as you work with OIDC tokens. Thanks, everyone.