 Good day folks. Hi, good morning. Or good afternoon. Good afternoon here. I don't know whether it should be, we should say things as a time related to get a sense of where somebody is or be respectful that it could be somebody's middle of the night. So I just switched to good day. I don't know. I haven't figured that out either yet. I'll start with apologizing. I've got some kind of camera issue that I can't seem to enable the camera. So I am not hiding. I just can't seem to get it to come on. I don't know if I'm pronouncing it right. Is it for cat? Oh, yes, it's hookup. Thank you for coming. I saw with your postings that time is a challenge. So hopefully that, I think that's the first thing on our agenda actually. The fact. No problems. Thanks for response. By the way. No, this has been a long standing problem. It's been a combination of who was willing to take the time to set it up. And then of course, trying to find a common time. And for those that want to keep voting. For now, Tuesday at nine to 10, which is now. No, actually Tuesday, not Monday. Tuesday nine to 10 is the current winning vote. So I'll keep voting and I'll paste it here as well. Yeah, I think someone requested the 10 to 11 Pacific time slot. So I'll add that as well if people want to update it. Oh yeah, did you, is that not on there? We'll be in two minutes. Fair enough. So folks can please sign in. Put the link in the chat session for folks. Hey, does a question about the little, does it show up in my time zone or is this time specific time zone? I had the same question because I thought it was too coincidental. I believe it automatically, it must automatically convert. It shows at the top. Under the title. Just below add to slack. It says what time zone you're in. Thank you. There you go. That's, that's the confirming. Thank you. Thank you. All right. If you access it now, it should have the extra time as well. Okay. Why don't we give folks a moment to update that. And we'll. We'll come back to this one while we'll kind of do a parallel voting thing. In fact, I'm just going to check my calendar. So I can accurately because we've been deferred this for a while. It'd be nice to get this closed. So folks can schedule things. That's interesting. How does this work, Marina? It should be at the same link. Can other people not see it? I can. I see it. I see the new time, but I don't see myself. And I, I'm positive that I put my name on this last time. I'm not sure. Really confused. Do other people see their own name? Yeah, I see my own name. I don't see yours. So I wonder if you didn't get all the way to the update button bottom. That might be the case. I'm clicking myself as others click. We'll just continue in a moment. Okay. At least I see my own name now. Okay. So, um, People have filled in. This is great. Great to see so many attendees. Um, the. So we'll come back to that a little bit folks can just pop on that. And in fact, Marina, do you want to just monitor that and make a call for where the most votes are? Sure. Yeah. I don't see search here. Oh, there he is. If you hadn't been searched because he got the initial one set up, but I'll leave it to you guys to make a suggestion on that one. We'll come back to it. There's a couple of things that were added to one of the things. That came up was some of the, the number of repose. So I think it was Dan that brought that up. So I did spend some time cleaning it up last week. And I was able to do that. And then the main issue was which one's trying to maintain the PR history. So I was able to play a little bit of the rename lever to the rename capabilities. So there was less historical content in the notary project on the. Status reports. So I just copied that content into the requirements. And then renamed require the notary project. And then we had, it's unfortunate that we hadn't planned it out as well at front. Basically we realized that the first repo we created was called requirements. And then we had some clients for the prototypes that we created for NB two and others. And we never actually thought ahead like when we're done with this, which is the route repository. What people look at because requirements wouldn't be it. So that's why we kind of repositioned it to be. Notary notary, the standard stuttering. I should say stuttering as if it's a bad thing. The standard repetitive name is usually the root project. So that's where we wound up settling. And that would be kind of the span to all the other repos in there. There's as the issue that's the first one that says repose this list. In fact, let me just share my screen or walk through it. Sorry, I'm new here. I'm just curious who, who is we in this context. So just trying to understand sort of a way of a project here. When you, I'm sorry, I don't understand the question. Yeah, this is Kim. You just keep saying me and I'm just curious who we is. We are the folks that have been working on notary to. So yourself and Justin Brandon Marina. So I'm just curious who you are. Nia's. Okay. There's been various people that, depending on where they are and their time have been able to come and join. And who do you represent? I'm at Google. Okay. Okay. So definitely in terms of how they get here. Sorry. This one. Let me get back. Okay. Let me get back to the repose one. Interesting. Okay. Hold on a second. So the, I don't know if this. Give me one second while I find. I think when they got moved, the repo names, the numbers got redone. Here it is pre notary projects. Okay. So basically what it was a good opportunity to kind of force myself to kind of go back and describe what we were doing with that. So that's what it was a good opportunity to do. So that's what it was a good opportunity to do. Requirements. I'm actually thinking we should merge, which I can't actually, I did merge. So this was the initial one. So what you actually, let me go through what I did. So this was the thought process when the question came up. So I did merge notary project. Sorry. Requirements with notary projects. And now that is the root. And it's got the history of what we've discussed there. So one is the binaries that we'll have the thought was there's another one actually called notary, which would have the libraries. So the idea anybody that wants to use the notary libraries would have that project to be able to put stuff in. And any binaries, whether it be the docker extension or others, we can put here. Website. I've left it. That's a standard thing that Chris put in. As part of every CF. Project. And I assume eventually we'll use that. So the other repos that we've had have been focused on what are the upstream changes that we want to stage. So that we can. Consolidate instead of it having it being off in the Osprey private repo or she ways or somebody's. We wanted a place where we can merge stuff in. We can build against, we can test against. And because we know we're iterating on it, we would make sure that it was in a stable thing before we did push it upstream and make a request. We could make a request. And that would be a big difference. That the changes actually, you know, we're worthy of being pushed upstream. We probably got a little bit that we made more forks just to make sure they were there in case somebody need them, and it did create more than we needed. So we did trim them back down. Right now we have no re project. As the two, there'll probably be a notary in there as well for the libraries. And then the forks for the things that we're doing upstream will consolidate the two Docker generating Docker and be two into the one. And then we've been doing the demonstrations on distribution for how these the linking the references to artifacts can be done, and both in persistence and discovery to make sure that we can do the full round trip. That work has been done there. And the container B is the staging ground for that work that's happening. And then there's the other one for OPA which I don't know if Daniel is going to make it today but I'll talk briefly what he was talking about. So that's effectively where at now. I don't know if others have any thoughts on the actual repos, but I also wanted to talk about branching conversations as well. So I'll pause there for a moment. No feedback. No feedback other than just the thanks I was one of the people that was saying we're getting a little too clutter with these repos and this is helpful. Cool. Thanks Brandon. Okay, so the next question, there's no more feedback and again, those that join later my my camera is not working today so the visual connection is helpful, but apologize for my the the next conversation is how do we want to handle the branching. We definitely have prototypes that were were not stating is a stated, you know, it's a current state, as opposed to here's something to build against. I think we're getting close in some places and other places will actually getting close close in a couple places. And we'll talk about that. So I was thinking, you know, did we want to create a release one branch where we can start. I'm not sure what I think that was something that Omar was had originally in there. And my let me go back to the envy to one because I think that had some additional branches yet it was prototype one prototype to and the stuff that Marina's been working on. I mean, different people do it different ways where main always retains remains the, the most latest and current, even though it might not be, it's not that stable is not the right word but it's not the current official release and then there's a release that the official release. So that's one idea. So I'm going to put a V1, V2 draft branch, and that can be where things that were probably the signature work is probably the closest thing that we're, you know, at a point of stability, the depending on what happens with the artifact manifest and the new stuff Justin's been working on, which I'll talk about in a moment that might be a stable thing. I'm curious what people how do people want to view things when they come in to see what's the current stable thinking versus what's an incubation and prototype. Yeah, I think that while we're in this prototype phase it might make the most sense to just have a main branch that points to the different prototypes with a quick explanation of where each project is so that somebody going there can just see, you know, what am I interested in and then link to that. Oh I see some main becomes a markdown doc that's a pointer as opposed to there's no actual code in it per se. Oh, sorry, go ahead. No, sorry, finish your thought. Yeah, I think that would just make it so that because especially while the different prototypes are going in different directions people can figure out what the directions are what's, you know, what they're interested in today. Fair, fair. I think the, I think the one related to tough is the one that we have to kind of, we want to work to consolidate that the most because prototype one and two are building a prototype to replaces one. But you're right, the tough stuff is, is a parallel. And I'm hoping that in prototype three we reconcile that. That's the stuff that I've seen with with you and Justin and Nia's and she way talking so that that'll be great. But I think I like the way you're saying that because it's, it allows us to show the branching. Okay. Anybody else. Well, since to me I think the normal branching scheme that we're used to makes a lot more sense once you finally have one of these prototypes that you say a stable so until we get to that point. I think, I think that suggests makes more sense to me. Okay, cool. Anybody else. Yeah, maybe I'll just ask like, did they get it right that this branches for the top one and two will eventually get merged to the main branch. Is that correct. Sorry, I'm feeling a little zoom challenge today. Usually I could see my screen where I can see people. There it is. Okay. Thank you. Sorry. I think it's because my camera's not on it hit it a little bit by default. Who was that talking. It's it's for good. Sorry. Oh, thank you. Sorry. Ask your question again. Sorry. Yeah, I was asking, are these products that one and two branches will eventually be merged with main branch. Is that what I understood or what's there's been, there's been two parallel tracks that isn't going on. There's common work that we've been doing on things like around a signature and how to find linked objects in a registry so that we could sign because one of the things as we've said from the beginning that we did not want to change the digest or the tag of an artifact this way any deployment artifacts like a pod spec or a helm chart or some cloud providers specific deployment technology. They don't have to change the reference just because they're signing something. So that forced us to deal with the idea that we could link signatures to an artifact. So that part we were fairly this working on different implementations of that and how to do that but that one is kind of making a fairly straight progress, including things around the signature that we've got so far so far. The other part that we've been working to resolve is the time stamping and some of the stuff that the update framework brings in that we've been struggling on how to scale it to not just multiple private public registries and software registries but the number of private registries and how we do it in a reasonable fashion. So we early earlier on and I don't know if you remember is like first quarter of last year somewhere around there it's been a while. We agreed that let's separate those conversations, because we want to make sure that we can make progress on a core set of scenarios while we resolved some of how to handle some of those parts of the requirements for things like rollback. So there was a split to allow us to make progress on the tough implementations versus what we're doing is a more core signature signing verification that did not attempt to solve rollback those. So that's how we wound up with these parallel efforts, the one and two are sequential to replaces one three would replace two, but we're hope is tough will merge with three, we're basically using a prototype three to resolve the differences in and how we solve those. And I would just add as another note that the way I see the split I feel like it's a little bit different than the way Steve understands it I feel like it's figuring out the prototypes one and two are figuring out kind of the interaction with the registries and you say image spec and kind of all the existing technologies today, whereas then the tough part kind of figures out the key management and how you actually know which signatures you can trust and kind of that piece of the puzzle. I think we're, I think we have not done a good job of completing the key management I think there's some key management. I think the question is the key management prototype one and two is that even scoped it enough. And that's the question where I kind of bring back the rollback but that is, there's some varied opinions and what we need to do around key management and that's where we have like Marina Justin Diaz she way. And the crypto experts kind of focusing on what is what is the requirements we want to serve is there an optional set of requirements and that's what we're trying to converge them in three. Thanks. I appreciate it. Okay. Marina. One here can can I ask also one thing. So, like, this mainly the same thing that full that was asking. So, are we planning to, in some point, merge these prototypes into the main branch, and at least in many of the open source projects that I've been working with the, the main branch is kind of a development branch and then we have these release branch like Steve was mentioning earlier that maybe, maybe we also in the long run we wanted to have these releases but do you have any idea when could these prototypes could be merged into the main branch and and do you have any any kind of a schedule for that or or idea how far we are from from merging this into the main if we are willing to merge them. Yeah, I think that as soon as we kind of move away from this prototyping it into more of a final product then we'll go back I think a more normal development flow with the main branch. And with these branches makes a little bit more sense. But with this, the prototypes with all the different scopes I don't know that a single release makes sense yet. Well let's see way in as well. Yeah, I agree. We might not be able to do any kind of a release yet but at least it would be, for example, my perspective, if I would like to contribute something in the code wise. It would be easier to at least follow because I'm new with the project. We are interested in in Ericsson to contributing into this and but as long as these prototypes are going like different tracks it, it's, at least in the beginning it feels like a bit hard to to understand where are we going and these type of things but. I think that I think that if having the main branch be kind of more of a pointer to, you know, where you should start as a as an incoming contributor. Do you think that would help you figure out, you know where to where to go. If you had a mapping of what the branches were doing. The key point here is to realize that the prototypes are very much a proof of concept they're not really designed to be the future development necessarily they're just verifying that our ideas are feasible and that there are no issues with that. So, I don't think there's going to be a point where we're going to merge in the prototype in the main I think we're going to hit a point where we say yes prototype looks like it's feasible and now let's start design the final solution. And I appreciate that when you're, it's a good point I just brought up on my screen about add the repo descriptions try to make it more clear prototype one is is basically prototype one is only good if you want to demo what's functional today and when I say functional it's in a prototype phase there's no expectation. Somebody would run it in a production environment. It was strictly a man or can we get a core experience working by hacking something together. And we felt good enough that we proceeded with prototype to to do the linking proposals. In parallel, we've been working to resolve what Marina's we were talking about is how what is the scope of key management. And that's why we weren't ready to make a statement around what notary to actually is at this point to be respectful of folks that are working on various approaches. So the tough proposal is just was, I don't remember why we named it one versus the other is just the way we named it. My hope is I would hope, because two was for hardening some of the things that we knew about in three, I think the reasonable thing is to will be wrapping up in the next week or two. I think we're pretty close if it's not this week. The, as we start three, we, my hope would be that in the next couple of weeks we should be able to have a consolidated effort that we're focused on. And I think the question is, does main become the active thing. And there is no release yet. And then when we have a release, there is, you know, release one and then main continues as the post one development. Is that what folks would like to see. Obviously, after we get to a point where we feel like we've got a common thing working on. I'm at least plus one for for the having the main as a development branch and and when when we hit the certain certain points that we are able to do the releases we do the releases from the current mains and keep the main steel as a development for the development. So you snap from main and then that becomes the release and if you have to do servicing on that release you do it there and the main is always the forward path. Yeah. Okay, that's fair. Yeah, I don't think we'll get to that point until prototype three at the earliest. Yeah, great. I'm totally fine with that one, but I just wanted to, you know, just to discuss how we see the future in this is this project and it's totally fine that we need to kind of wait for to something to be mature enough to be able to be as a development branch. So I'm totally okay with that. I think part of what you're seeing, Jen is a recognition that we kind of rushed notary v one and didn't get it complete and to account for all the various evolutions of what would. I wasn't part of notary v one at the time so I don't want to speak to for Justin and others that we're working on at the time. The, but I think we're taking a more balanced approach or not balance but more pervasive approach on what exactly it could be to span public software registries private registries and private registries in air gap environment which we recognize is the common not not, you know, the oil platforms and submarine kind of scenarios it's pretty much every one of our larger customers has said it's a private network in the public cloud. So how do we support signatures that move and I'm trying to be careful not to call it key revocation anywhere, but whatever an expiry of something means. We want to make sure that is just to secure if not more secure in air gap environments because people go into air gap environments because they want higher security. So we can't say it's a less of a solution in an air gap environment than it is it's got public connectivity. We're taking a more balanced more disciplined timely approach to it to make sure that yes it might chip a little bit later than what we would like, but when it ships, it will at least work and won't be too short sided. So I think we're for those joining us want to throw a little context a lot of stuff that we're working on is based off of things like the artifacts project from our CI that is still in their design phase and there's a lot of stuff that we're working on trying to create their built off of things that are still being built and so there's, there's going to be some effort here that's still in design. Okay, this was kind of the picture that tries to capture like we're not trying to know to review one was like the side sidecar thing that you had to run and we run it on a CR we've gotten feedback from just implementing it from our customers. And it's been extremely problematic so we're basically trying to say what is the right holistic solution to get it right. So that's just the number of projects. It's coming together pretty well like I think we're generally happy with where it is I think we just all wish it was done already. Does it make sense jam. Yes, it makes a lot of sense. Yeah. Thanks. I've also been working this past week as far as repos go is to make sure that I can start making it clear where people can contribute. The issues are just trying to consolidate the issues here, whether it be tag signing for stuff that Brandon was pushing for, or even a container to plug in and we'll talk about this in a moment. And things all the way back to know to be sorry, the repos and everything. So, all of these things we tried to tag. And there's the ones that are in I've also started to move things to some discussions. I try to make some proposals on that is that issues are good for discussing things, and there's a history to it and so forth. But the goal is to close an issue. And what happened is we had some things in requirements that was around. In fact, I don't even see it here now. We had some things around proposals and designs, and it was, it was even title the design discussion, and you can't close an issue like we don't want to close that we want to keep that around for some period of time. So I have enabled discussions and we're trying to keep the pieces here and we've got a couple of them here including you know that this was posted so I moved that one here. Unfortunately, I can't move a PR, but you can move an issue to a discussion. Oh, that's what it was the design discussion was here initial design options. So I ping Sam if he wants to move that over there. I think one of the things is that if you look for and we should probably start doing this is putting, you know, looking for work on some of these items, and that's what happened on the gatekeeper one is somebody was, you know, Dan was looking to help out. He said, Hey, can I help here. So I think Jen either if you want to just let us know if there's an interested area that you'd like to help with there's area you want to contribute to we can make sure that we're giving you guys what you need to and whatever fashion makes sense to you. Yeah, me and for that we are we're working from the same team and and yeah we can discuss this internally and and let you know we have a couple of things that we really want to work on, but once again I need to be more aware of the actual and and and see how can I, how can I contribute or how we can contribute into hearing to notary. Fair enough. Sounds great. So thanks. Thanks a lot guys. No, thank you. All right. Any other discussions on repose and branching releases. The summary is we will have the two prototypes. We get I will I will flag prototype one is being done is the reference this point to is the you know the next evolution of that. And tough is the other ones that's basically two parallels at this point. We'll get that added to the root read me. And that prototype three is shaping to be the consolidation of a focused effort that we would then move into Maine so basically what I'm actually hearing is whether prototype there should be a prototype three branch or does prototype three brands just become main, actually, if if we can get things consolidated on the efforts and in quote three, and there's not two parallel efforts, then let's just put that in Maine is what I'm really hearing. Okay. So thank you so much for your time and releases we hope to have one soon. There I think prototype one is really the best can be done is considered a release because it lets you get a good demo of the experience that we've been targeting. And so it will stop there. Daniel, did he make the call he said he had a conflict. So wasn't sure if he was going to start later not trying to get zoom to show right. Okay. Thank you for being here. So, Daniel's from coming called NT data, they did some entity data, sorry. And they did some work around note review one and open validations. So he had asked if you know they could pick up that work item. So it was great conversation we talked about it last week. I think it was last week. And so I opened the issue around we didn't even have an issue for it. And some of the folks from Harbor were also asking around doing some of the validations around it so they're all welcome to join so I put that one there and I put. I'm sorry I'm looking at my screen. Let me go put this over here. I'm going to try to capture the generalization there's been conversations around what does it mean to have the registry as the C name. So I try to put that I try to capture that information here as well. That basically the first thing is, is the key valid. Again, we've not really focused heavily on key management in prototype to it's really kind of scoped out. The assumption is that there is a way to get a private key for building and a public key for validating. And we defer it to the, however you do that in your cloud today and we will work on the expiration cancellation revocation scenarios will come to some better guidance on that and three. You basically just validate is the one of more of the keys that's assigned to in this case it's is open so it is an image. Is it valid, and not valid is well as the same. Is there a signature that matches on the image to a key that's on the node gatekeeper, the gatekeeper node. And if so, let the deployment proceed. There's a second one that picks up on this idea that each company can resign the content for their environment. In the case that software deployed built by web at networks, it goes to Docker hub there's now two signatures on it in the ingress into acne rockets, the one or either the signatures is validated to determine whether it should even come into this air gap environment of acne rockets, and as part of that ingress they put a third signature on it. So the idea is that here on the ingestion. And one make sure that the key is valid for that, that company, whether it be rabbit or Docker hub, and to these, the C name that's on the cert that is the image pulled from that registry, that is a second optional verification. Once that's done here, once it becomes signed by acne in here in the production environment, they could say well am I, is it the acne rocket signature, and is it pulled from the registry that's declared in that cert within this environment. So that's the conversation point there. I think this is what Marina and I were kind of stuck on last week. The, I think it's more like a design question or challenge but I think the putting that putting that field in the common name of the service kind of the wrong place for it, rather than in the signature payload itself. Especially in this example here where the common name is just a self signed certificate. It's basically just plain text that sits next to that key. There's no security guarantees for that common name field at all. It's just like it's equivalent to any string you find sitting next to the key. So it makes a determination whether the key is valid the fact that it's self signed is because we're trying to not have any affinity to any particular cloud provider any implementation. The idea is that they would be able to use, you know, full x 509 completed search. So this is just a way to get people to be able to stand it up and run themselves. So there is, if it's only signed by the person who creates that signature. I don't think you really get much of a guarantee that that's actually where it came from. Because I don't understand that that model where that would be different. Well, if you're issuing, if a company is issuing x 509 search, that's the premise. So the stuff in the search is supposed to guarantee the cert itself, not the other content. I think maybe it's like a precision thing but we like in front of maybe in number two, you should say cert instead of key we kind of use them interchangeably throughout this which might make it a little Oh, that's fair. That's fair. That's probably that is. You're right I have used that interchangeably. Change it right here. It's easy enough. Did I do that in some other place here as well. I'm not sure. We'd have to go through to see which one we actually meant for each purpose that we can sign it with a key or cert. I mean I can change this to cert as well here. I should be signed with the key I believe. And the next one CNM of the x 509 cert. Okay, this is where I'm getting the select sake of season starts in keys. Yes, you want to speak to the questions on it because I forgot that you were here. Sure. I think the CNM as long as it's included in the certificate the certificate itself is also signed so that can be validated. As long as it's not referring to a CNM being pulled out and attached to the signature separately I think that should answer the question that there was previously but there's any other questions I can answer that to. Does that make sense to you Marina I think. I think I'm still not getting the threat model that putting the common name and the certificate addresses. It could be signed by the key I don't understand the use case for it because I think I would need a better. And maybe it maybe this is I think something we're missing more in general is what is our threat model. And what attacker capabilities are we do we're assuming because if we're assuming. Yeah the tacker is ever going to compromise a key or we're going to compromise a server then I don't know that this is going to give you any additional information. I think we're proposing CNM validation at any point. I think the. The way we described the validation to happen is that there's a root key that you're trusting and essentially based on that route you can chain downwards and determine if like the signing key or the hierarchy of keys that are being used to sign or valid. CNM comes in as an interesting concept for additional validation. If you have a route that you trust that say let's for example a trusted CA. Then you could potentially look at certain fields in that CNM and I think we want to get more precise as we go forward. You can trust for example organizations if it's an organizationally validated X5 and a certificate. There are other other fields in the certificate that have no validation in them so we I wouldn't generally recommend validating on those but. Typically for an X519 certificate the fields in the certificate would also be signed with the key itself. So as long as you have the route to validate and you have the signature or the certificate chain. You'd be able to validate certain fields in the certificate as well as long as you're embedded in the signature. And for me I look at what's the workflow, especially particularly for the clients are doing the verification of this of how they do the verification I feel like. The client side should be saying, I'm going to pull this image and make sure it is signed by someone trusted by this authority. And so there will be some kind of chain of trust and so we wouldn't even need to be looking at things like the CNM in that case. I think that's my confusion to. And we've said from the beginning this was around doing some occupations and experimenting when Chiwei put this together, the CNM associate with the registry became an interesting piece we hear from customers pretty regularly they want to lock down their deployments to only pull from certain registries. So it became an interesting idea to experiment with, whether it survives or not, it's up for you know the group to decide. I wonder if you rephrase the solution to those people if they would like we're coming up with. If they said they want to lock it down to only come from a certain registry. Would they be comfortable if it only came from a certain signer. And it was one of those additive things. Yeah, it was one of those additive things, because you could also say if it only should come from a certain registry you can lock that out for a network rule. You know, that's like saying well if I'm in a network if I'm in a vnet I don't need authentication. Well, hold on, you know multiple lines of defense or always a good thing. We associate certain keys with certain registries you can get the same properties, or if your roots of trust are associated with you know who you actually trust to sign these images, or potentially even more granular. You know and signing on the registry might only send a certain slice of that and that's the only stuff you trust and so, you no longer worry about who might have push access that registry at that point. I think it does definitely comes down to our key management conversation. I mean, it's clearly there's discussions here I was able to merge in some of the content from the PR is that you know kind of had good rules on them, the content the key management ones, basically I'm looking for unions and Justin and Marina to, I guess she way for you guys to kind of consolidate down on what you want to do there. And we can decide what we want to do it. At this point there's nothing tied to validating the scene name. There's nothing limiting that there. In fact, I have to check what the current nb2 client does and how it optionally verifies that or not actually. Okay, as like a potential thought to come back to as we nail down things like our threat model and our workflow, because it feels like right now we don't really know what those are and so it's hard to decide if this is a future we're going to want. Yep, fair enough. Thus, the prototype label. I mean, this goes back to, you know, jazz kind of questions like what exactly are we making statements on yet. We're not yet like where we're trying to make sure that we account for the various scenarios that we're trying to make sure that we have confidence that we are shipping something that has the right bar it'll never be the security answer because you know this is why fire safes never claimed that they are far safe they rated on number of hours. Every security issue can be mitigated it's just a matter of time and effort. So the question is, did we put enough effort to make it secured that it's still usable, because we have to if it's not usable people won't use it and then it's not secure. So, just to kind of be repetitive of that balance that we're constantly shooting for. But we haven't made that determination yet. So, all right so but if we do I think we do have enough to start doing the open like there's there's probably some areas that we know we don't know there's areas that we do know, but we haven't actually done an end to end with OPA. So, I'm hoping Dan, Daniel from NT and TT data, and if the harbor folks are I think this is the first time we've actually had enough in place for people to start doing that validation. We can do it on prototype one, I'm hoping we'll have prototype to working to a point and assume that we'll be able to do it there. And then we'll, we'll learn what we don't know. That's kind of the main things let's keep on uncovering peeling the onion, figuring out what are the things that we haven't accounted for yet. And the same thing with the container be work. I'd love to see some validations there because we don't want to be tied to just Kubernetes. So any communities host, but any container host, if you will. That's the OPA validation. Since we're already on signature format, we can jump ahead and cover that because basically the C name was part of that conversation. So, I'll move this one up here. Yeah, it's all kind of anything else that we want to discuss here. Yeah, it's just the general timeline and which prototype phase we want to start firming this one up in. There's a bunch of feedback for other people here. Is this the one we're going with for prototype three I think it's called out in the demo or script. It's what's we use for prototype one and two we other than questions around. Actually, this isn't this is the feedback on it so sorry I may go back to the actual signature. So there's this question of what does the C name do. Actually, I'm sorry I'm getting too confused. So we're, do we have that. Oh yeah here it is. In fact, I have to double check because I think something changed in the go libraries we had to change how this was done also, but the, you know there's this part of it, you know what is the level of, you know, support we want to give for setting a scene into a registry. And then the actual format would look here and then of course it gets encoded. So, at this point this is our working example we don't have anything new to change to yet, but I would expect some of the prototype three would. I think that we've there've been a couple of concerns up and down about the X 519 format, and I don't have like a particular opinion one way or another, but I don't think we should pick it just because we happen to pick it for the first prototype. You know I think we should have like a discussion where we look at other options and see what the signature format that's going to make the most sense is agreed. We don't have another proposal yet, and it's been working for what we have. So, I think as we can get something more we will. Yes, I basically I'm looking for you guys. Yeah I think the, there's two aspects to the signature right. The, the key information and the certain information like that's one aspect of it the other aspect of it is what's actually being signed. So, even if we can agree on that part I think that's some progress so I don't necessarily think we should block on this and on one aspect of it. Yes I think we're going to want some other type of sign metadata, no matter what like the size of the image and other stuff. And so a lot of the information that's currently in the X 509 certificate like the CNAM for example if that's a shield that we really need. We can just include that in whatever format we're using for that piece. I mean I think the thing. The interesting thing for me the CNAM is it saying that the signature is, or the cert is associated with the registry. So it's not that some image wasn't signed to a registry because we're trying to be very explicit that content should not be tied to a registry. It's a very explicit decision that content can move it's just what registry it currently is in is irrelevant. The question is, is the seal on it, still intact. And the analogy I've been trying to use lately is, if I ship up a thing from from here in Seattle to some place in another country far away I'm trying to save for cut, but I think you're in Germany right. We are in Finland. Finland. Okay, sorry. So Finland, still far away so if I'm shipping something to Finland. I'm going to put put something in a box and I might put a seal on that box you know it's the thing that you sometimes see that the seal is broken, you know, consider invalid. So as it leaves my house and whether it goes to UPS or FedEx and then it goes to some international carrier then it goes to a local deliverer and gets delivered to FERC at he can look at it and say look this thing was shipped from here to here. It went into a registry and went across registries and it came out of a registry and it's still intact. That's what I've been trying to, I think we're trying to say is the scope of what we're trying to do here. I would yeah and that's why I think that the CNAME actually is an exact counter to that. I feel like you just made an argument against including any information about where it first was, but I mean I don't, I don't know I think we need to have more discussion about this, but. Yeah the question I'll put back to Steve is, does the CNAME actually provide what you were just asking for because let's say I just spin up my own local harbor and smell local lab. I'm going to put a CNAME on there and say whatever I want to say in there. And then give that image to someone else instead of the question isn't what's the CNAME it's who really signed this and do I trust the person to sign it, can I look at their, you know, their chain of trust as someone goes back to someone that I trust. So let's say you, you signed it, whether it's you know Brandon Inc or Brandon Mitchell, right it was just either way. But no, put the CNAME in there and say that it's Docker Hub. Because I was actually thinking about exactly that there's the distributor, the manufacturing distributor model of content. So, because you might want to sign it for both you might want to sign to, for instance, but the idea is that if I get your public key. And I trust Brandon to come in front to from content from Brandon, and I'm using that key to trust you. I think the question is, is there something valuable that regardless of where I might have currently gotten the, the artifact from if I got it from Docker Hub or if I got it from other some other registry that I have the option to going back to the registry that specified in that CNAME to go find that content. And basically say look that's fine that I got it from here for some reason I'm a little distrustful, and I can technically connect to back to whatever registry Brandon specified, and I can go pull that content directly. I think that's part of I feel like the CNAME might be the wrong solution to the problem you're trying to solve there might be better to put some kind of reference or whatever within the same church is kind of like you have on the screen there. And have that as a source you can go back to and that's just part of the thing you sign. And that might be the case. Yeah, I think, I think I agree that that would be a better way to go about it, because I guess in my mind if you really want to trust the registry, then the registry operator just implements their own signature right. It could be Hub or Acme they implement their own secondary check. Yeah, they tack on their own signature that's what you. That's what you care about if you want to say I only want from this specific registry right now. That's right. Anything else on that one. Okay. Moving back to the agenda the other one was the the OCR artifact manifest that we've been using that basically we incubated in prototype one, and then we kind of formalized in prototype to. And this kind of goes, I don't know where to look for here in the sense for here. All right. In the artifact manifest proposal here let's just bring it up here. And this was the trim down version from 27 that had the week references, because basically that was considered not not good enough wasn't scoped enough so what we needed for the artifact stuff was actually here. So let me go back to the overview of the overview makes more sense here. So the preferences that the concept is that there's an individual objects that go into a registry that network monitor image. It's got a standard OCR image layout. You can gradually push signatures which is, you know, part of the artifacts and aura stuff you can just basically push in another artifact. But the idea is there is no linking in a registry there's no way to know it without hacking into, you know, tags or otherwise to say that these things are somehow associated with each other. The premise here is that we wanted to be able to get the things linked so that any done in a generic way, so that it would work for things that are signed, or things like an S bomb if I want to associate an S bomb with an artifact. So here what I've got is the network monitor image, it's got its layers notice the downward direction. There's a signature and it also has and technically the signature does not have a config so I've updated that in the examples and you'd update the pictures. But the idea that an S bomb and we're not stating which S bomb it is, there's no commitment to one or the other is just saying there is a document that can be put in a registry that declares the, the whatever the fancy words we want to put around the S bomb from lineage to others. And how it was compiled and so forth. The idea is that you can put this S bomb into the registry and put a pointer back to the manifest that basically says this is what makes up this thing, because things that are in a registry I represented as with the manifest documents that describes the thing, and the blobs are just the content of the thing. The idea is that I can either have a signature directly, I could put a an S bomb that's a link, and then I could put a signature that it's a link to an S bomb which is linked to the image. The, the evolution here is kind of got a long history to it just on what we felt we were able to, we're not felt well we're told we can make changes to back a couple years ago when we did this approach. The premise though is that this would have a more generically useful capability. So we kind of left it on this, and that's what prototype to is hardening to make sure that the APIs and the persistence scale so that we make sure garbage collection would scale to documents lifting to other documents. After that. Justin has been noodling on a larger problem Justin Cormack for not just what we've been trying to do here with the artifacts work. There's been another thread of changes we've been trying to get done that supports generic compression formats on images and the one thought process is it should be so generic that any artifact can generate, benefit from different compression formats, kind of without them having to do anything. That was more problematic. I kind of left it with leaving it to each artifact to decide it how they would handle compression formats or changes to their artifact type. The reality is, there was no clean way to do that even on the image spec, and there was a several months of various efforts on trying to resolve that with star GZ and some others. So I went back to look, can we reboot this in a standard way that allows us to do it generically so not only can we get reference manifests, but can we solve the versioning for artifacts in general, whether it be image or signature or S bombs or NIDIS or anything that somebody comes up with. Because right now we have to manifest in the registry for image, which we've hijacked and use the image manifest for other things by determining the config media type. The, and then there's this image index which also has challenges. The question is, can we make one more change. So instead of the OCR artifact manifest, can we use this other manifest, which would replace the OCR artifact manifest proposal by the way. And this one would give us that ability. So I think it's towards the bottom that he has and this kind of replaced with a PR recently so we can actually do more specific feedback. We believe at least at this point it needs more some qualifications on it but we believe this actually solves what we're trying and what we need from notary V2 and the larger problems that we've had with registry persistence. So, what does it matter to notary, we're trying to not create so much confusion on how things get put in a registry the idea is that this would be a standard that all registries can consistently implement so that content can move across all registries as much as can today. And we want to, if we have one more change that we have to implement in registries that would solve not just the signing solutions, but the versioning of the image spec and compression and the other problems that we've been struggling with for a couple of years but that seems like a good thing to do. So that's kind of where we're at at this point, Justin did kind of come up last minute and says by the way I've got this thing. We'll be reviewing it more, I guess taste Monday this week. I'm hoping there's been more feedback on it and Justin has more time to clarify that. The thought is that we'll take what we learned in prototype to to validating the linkages and just apply it to this design. We can't get more firm in this will probably continue with the artifact manifest because it's a solid thing that we know we can chip. It's got the capabilities we need. But my hope is that this will solidify and we can transition to this one. So that's kind of the sausage factory at that level. So having having a signature having key revocation we've kind of proven is unless there's a way to associated registries that in a way that is generically useful and scales and scales not just from APIs but from general usage, then we've kind of proven that that has not worked out well. My hope is that we can. We're not killing birds with stones anymore we're squashing bugs with one commit was the latest suggestion so we're hoping that this one change will help us solve a bunch of the other problems that we've been focused on. So watching some of the stuff isn't on the artifact work there it looks like there are three different things going on. One is kind of the main artifact proposal a lot of us been looking at. We have this one coming up from just like there was another one out there that was looking at how he can possibly extend descriptor and use it for some other things extending some of the fields. Yeah, so Dan and john, you guys are both here they're have a proposal on adding references on the descriptor. So that conversation is pursuing. From from your impression of what's been going on in OCI is it going to be just pick one or is it going to be maybe a progression where we take the easy one now and get to the harder one later. I know it's hard to say what there's obviously a lot of opinions and passion on this one so I want to be careful not to make any crystal ball guests, especially as we've been pursuing one of them so that it comes across as little tainted maybe. I think the question is the thing for me on this one is to implement garbage collection of registries which has been one of the biggest challenges in a registry. I really don't want to do it in multiple ways owning one one product. You know, so others can make choices for what they want to do obviously. So that that's to me my big concern is I don't want to have to have multiple ways to do it. If we, and I think that there's a timeliness to it also look if we can't if this thing's going to take three more years to do it this way that of course we got to find a shorter term way. I don't think it will. I think we need to make a choice and figure out which one we could proceed with and I'm hoping I would personally hope we don't have multiple ways to do it. Because I think it just becomes confusion to the to the marketplace. I think that's the point of having a standard and a spec. I don't know which one serves the needs and which one can we get done so I think that'll play its way out. Yep. And what's that for a time. The, the other one for short live and long live. And that that's one it's progressing. I don't know what we would talk about today per se. That's part of the prototype three conversations. Yeah, I think maybe we can spend next week figuring out what that prototype do will look like because I think that we're at a point where we can put all these pieces together and really get a more cohesive thing but we should spend some time working that out. Totally, totally. I think the idea was can we get something out on what we know, while we iterate on what we don't know. That's that I think that is what the prototype to was about. Let's formalize what we know and give room for incubating on top of that. All right. So with that, I'll give folks back their day. And we will continue. Thanks, folks. Thank you.