 Hey, that's a great radio. What time is it for you? For me, it's 1030. That's not too bad. There we go. I'm very jungly today. So I see the tough scenarios that Marina added. There was, it seems like there was some leftover conversation from last week that Justin Kappos wanted to bring up. There's something or some conversations with Sam that he was talking about. Oh, something was nice to add me. Thank you. I mentioned his name and he shares up. Awesome. Hey, Justin. Hello. Sorry for the momentary delay. I had a fun time solving things to prove I am human. So I don't know what we have for an agenda. Sorry for being a few minutes late, but we've gone and produced a bunch of the scenarios, information, other things, which I guess people probably saw because we posted it in the notary channel. So I think at least one avenue of discussion here. We also added a few scenarios that I think we're lacking from the document that are not necessarily the most important scenarios to. They're useful scenarios to have because I think that the next level of questions will be, well, what about these things? I don't know. But they're not. I can understand why they weren't in the original document because they're more of the less common cases, like setting up. Setting things up when they're not already set up. We're actually part of the key management stuff. So they're great to have. We were. I think we were tracking those separately as key management scenarios. I agree. But there was supposed to be a key management working group that was going to focus on those. Yeah. I mean, there are things that have to be handled. They have to be somewhere we put them somewhere. And I don't think, I mean, I think the actual steps you do are very slightly different, but I don't necessarily think the number of steps or the. Like the, the purpose of the step is fundamentally different across different solutions. It's just a matter of maybe you, you know, you put your signature here versus there or you. Like, you know, you click a button on a UI instead of uploading something that has your signature or something like that. Yeah, there's, there's been a bunch of things like the offline key management stuff too that it's come up. So if you guys want to do a, another PR for key management scenarios, that would be awesome. Yeah. Yeah. I think that'd be a good idea to get those in the official repo. And you can restart them from, from one, instead of worrying about double digits, we can just say, these are the key management scenarios. And those there, that'd be awesome. So aside from those ones though, I, if it's okay, I'd like to have a quick discussion about the, this, this idea of targets delegation. Cause I think that in whatever solution we come up with, this will be an issue that we'll want to figure out is kind of like who's in charge of delegating control to who, like when a developer joins a product or is in charge of uploading something, how does the registry know that this developer is trusted for this project? And then, you know, if an organization has a lot of developers, how can they manage that internally so that the registry doesn't have to be updated, you know, every time someone joins a team. So is that something that people will be interested in discussing or? I think I'd want to look more into that. Part of what we were trying to kind of cover is that, that access delegation versus key delegation is something you want to dive more into. Is this just saying that, you know, we're going to provide a PKI, like we're going to provide integrations with the PKI and how you manage that PKI is entirely up to you versus does the registry actually need to track something to kind of enable this track, this delegation of access? So there's a difference between delegating access to keys versus generating keys that kind of are delegated to sort of like a route. And I think we want to dive into that a little bit more to understand the tradeoffs between those two approaches. Okay, yeah. I'd put a note in the doc and maybe it's just me because I don't drill into the details of key management, but I was wondering if there's something written up that says the targets and delegations, there's general terms and I'm not sure if those apply here. So it'd be really good just to clarify if you have some docs or pointers to something. Yeah, I can definitely find some documentation on it. The basic idea is that the, like targets is kind of a name for anything that's in charge of signing images. And instead of actually signing an image or artifact or whatever, they might say, okay, so I have responsibility for this image, but I'm going to pass that off to this developer who actually wrote the project and is responsible for it. And so those are all those targets files delegating that responsibility, but then at the end of the day, it's that last developer who signs the file and says, okay, yeah, you know, we wrote this code. This is what it looks like. And then uploads it back to the registry. Basically the idea is that that way, if you have a complicated organizational structure, that doesn't have to be visible to the registry. The registry can just say, you know, I delegate to this organization and then that organization can then decide who's actually trusted to, to sign individual artifacts. You know, organization or team or whatever. Yeah. Yeah. Marina's completely right. I just want to add one very minor additional point, which is that it also makes it so there's really never, ever a need to share keys, which is something that we say, we see people operationally do a fair amount. And so it just, it gets rid of that, which causes you to have just so much better operational security. So the idea there isn't one master key that lots of people having like the build system had multiple build servers have it. Some individuals have it and somebody's laptop gets compromised and all things are off. You're saying that we would be able to know that that laptop's version, delegated version of the key was the thing that was compromised. And you can just revoke that one. Yeah, exactly. It removes that single point of failure. Yeah. Sounds great. Yeah. We can have some kind of portrait to it because like I said, maybe it's just me, but I think there's a bunch of people like me that are not willing to say anything that are kind of wondering what exactly means by all of us. And it sounds very official and nobody wants to ask the stupid question, but so I am sure we have something written. I'll make sure I'll find it. Yeah. We made progress, but we didn't quite get to a shareable state with the overhead information, but it doesn't look particularly high. So we'll share actual numbers rather than kind of ambushing everybody in this meeting and presenting some numbers. We'll check things again because we put the scenarios together this week. And so we want to, you know, we don't want to flood you with too much. We also want to be sure we're really checking things so that everything's accurate. Yeah. There's certainly a good priority to focus next. I think some questions came out there. There was a couple of people also probably on there. The, on the scalability, it's not one of the things that I'm also, I keep on seeing concerns and questioning is the, the role-based access control concerns. And I think that, that two repos don't have the same permission sets and people that have access to those repos don't. So having a single. Metadata repo is the concern as opposed to the metadata being stored with the artifact. And that is part of what the original notary project was that we were trying to get away from also having. External storage. I'm not sure about that. But I'm not certain I do. Is this one of the scenarios in the scenarios document? I, you know, it's probably a good point. I, there's, I did not call it out because there's just an assumption around permissions of a registry that like any. Storage solution that has multiple storage buckets that could have different permissions. But it's a good point. I don't know if I call it. It's probably worth calling these things are explicitly just. For completeness. I, it's probably more constraint. Maybe call it out because I don't know if it's really a scenario. It's the, because there's a couple of constraints we've had, like, we must be sure that we leverage each cloud providers key management solution. We shouldn't come up with a new key management solution. And then we maybe use hashy corpse for the open source implementation. We assume each cloud, each registry cloud being part of them. And then we have a lot of other things. We have a, we have a lot of other things. We have a lot of other things that have their own, have its own permission. Security model. That they put in. And one of these things is that one of the constraints are. Different registries have different permission models. And even within a registry. There's different permission models. I think a Sarah is one of the few that we're kind of late. We've assumed each registry was the permission boundary, but we're now adding, we've already added, and we'll be adding more repo bound permissions. We can just write it up, but just think of his multiple repos are in. Actually Docker hub is like this also, right? It's like there's Justin and I both have accounts on Docker hub. I obviously don't have access to his private images. He doesn't have access to mine. We can both make stuff public. But those are public is not actually a normal scenario in private registries. In fact, it's the anti-pattern of a pro registry. So two teams that have a collection of images. And that's one of the things that we have to do. We have to make sure that each. In a single registry. Is the permission boundary problem. Yeah. I mean, I think. We, we believe that we cover this well, but the act of like having a clearly written scenario and us clearly write how we cover it. We'll make that. We'll make any talking past each other very clear. Okay. We had a note here too. It's like, you know, if you don't understand something, you've figured it out very quickly as you teach it. And everyone else does too. So. The exposition should be helpful. And I'll take the action for this. So did you want to go through the, how did you want to do this? Did you want to go through that doc that you guys had? Did you want to. Yeah, we, we, I saw it late last night and didn't get a chance to start editing. Putting comments and reading it, putting comments until this morning. I saw a bunch of other people did as well. Did you want to, again, being, we have 15 minutes left because we shifted to half an hour reviews as opposed to. Or half an hour summaries as opposed to discussions. How do you want to use your time? Can we actually have a separate discussion to go through the scenario section? I think as a, as a, as a, as a, as a, as a, as a, as a, as a discussion to go through the scenario section. I think as I was commenting on the doc, I realized some of my questions are actually for the original scenarios that we posted up. And so I think going through the whole document with the changes that have been suggested and addressing questions, there would be fruitful. I think it's a good idea that'll give us time to really delve into it. If we have a separate meeting. Sorry. Sorry, what was that, Justin? I was going to say silence. There was when there was an ask. Do you want to, do you want to share your let Steve. Wait, what, is that what happened? Justin just volunteered me. That's why you're so quiet. You was obviously about to volunteer but you missed that. In fact, what I might suggest is we go back to doing hours. So here's the question. Do we want to have an optional slot for only for agenda items that we have at the same time so that we can allow time, but not have it if we haven't got something agendaed in advance? Like, so we have done, like, Wednesday. And if we haven't settled on something we need to talk about on the Monday half hour, then we don't have it. Something like that. It's a good idea. I guess I wanted to ask the larger group because we do have a good showing today. We were going down this path of having working groups. We didn't really, we kind of paused. There's lots of things that happened, so I don't care about the details of why. Do we want to get back to doing the working groups? Because I think it was, as you mentioned, you were going to start having some time for key management thoughts. And I know at least when the prototype was starting to get some bandwidth available. I worry a bit about that model because I feel like, I feel like if we were all on the same page and we just needed to break up into groups to do things and then make sure the pieces fit, I think that would be a good model. But I worry that we're not, like, doing this is going to cause us to go off and do very different things and get more entrenched and make it harder for us to come together in the end. Yeah, part of the mechanism I think we came up to address that was the 30-minute agenda meeting was also like a forum to kind of share updates from the different working groups. So we'd have a weekly checking and make sure, like, you're absolutely right. Like, we're not going down and checking and going down the paths that are sort of bifurcating, right? So as long as I think we have regular updates within the 30-minute agenda meeting from the different working groups, I think that should address the concern, right? That was the model, yeah. And there's nothing stopping anybody from attending the breakout groups, right? It was just a matter of, Niaz, I'll just pick on you. Like, he was more interested in some of the key management stuff. So how things get signed in that part of it, he'd probably divert to some others and then he'd be focusing on the key management with some other folks. And then we are kind of reporting up our status. But the assumption is there's overlap of people between the different meetings. So it's not like, hey, all these breakout groups happen at the same time every week and you have to pick one. They'd be coordinated separately and then we move this to a half an hour. In fact, we move it to a half an hour. So the first half an hour could be a working group. And I'm just, I'm asking, did that model not work because the world turned upside down and we're now getting used to it or that model didn't work and we should come just make this an hour long conversation and set the agenda up front. I, at least for key management, I can speak to that. Like I just did not go start the group and reach out and kind of get that thing started. So that's something that I've started on and I'll follow up on Slack on that. I think that's definitely something I can drive and see if we can make contributions back to the group and share that. Justin, if we like, does that make, does that work for you? Like if you have these working groups that are providing like updates regularly, does that address the concern you have? It might, it really depends. Like execution is really the thing. And I know that like myself or Marina or someone else will definitely move to, we'll have to have somebody in the different groups and then we'll all have to sync internally to see what's going on. And so it, at least from our standpoint feels, and I shouldn't speak for others, but at least from my standpoint, it feels like we're not necessarily gonna benefit that much from the breaking up into groups. But I'm very often like, this is an organizational thing that all depends on how we as people make it happen. And so it's really impossible to predict with any accuracy how this will go. I'm happy to try whatever others are supportive. Yeah, I think this addresses a much larger concern for us than it does for like, tough for example, because you're right, like tough is gonna have to take part in almost all the different working groups. But from an organizational perspective for us, like we have different people that would weigh in on key management versus different people weighing in on sort of like the registry specifics. And so for us, it just makes sure that we can get the right people for the right working groups and meetings. How about, why don't we do this and make a suggestion? It sounds like I know that there's on our side too, there's some people focused on key management that aren't, they're sensitive to their time. I don't wanna say they're not interested. They're definitely interested, but to respect for their time and commitments that they have, they would like to focus uniquely on the key management aspects. But it sounds like it certainly from the NYU tough in total, notary, I'm not sure what to call the group. That group's perspective, you're probably involved with all of them. So what if we did this? Niaz, what if you set up some of your, the key management working group off to the side? You know, off to the side meeting, whatever timeframe you want. I'll ask Amy to move this back to an hour. I'm Justin Cormack, I'm assuming you didn't already commit your first half an hour trying to overlap your time zones. And then we'll leave 15 minutes, Niaz, for your team to kind of give an update, either at the beginning. So we have a time box that we'll just make sure we time box it at the end either way. How does that sound for folks? Well, we can do this. We will probably end up explaining tough over and over and over again in these meetings. But if this seems like the best way forward, then we can do that. Do you, are you worried that the key management, the key management is so intertwined that you'd have to attend that anyway? Or is the key management just totally a tough thing? My understanding is the key management has a bunch of complex scenarios that we hadn't previously thought of where like the offline keys was the example. And having AWS and Azure and others are invited from other clouds as well, but those are pretty good representations of really complex problems. So just having those folks having a chance to break out on that. Cause I think that they will tie up an hour of their own, just trying to figure that part out. We can do this. It might be easier in some ways for us to come in and say, here's something that we think needs all the needs in other areas. Can we talk about this from a standpoint of what scenarios you have from a key management standpoint that aren't captured and what situations are problematic? Because if we kind of go in and just say, okay, we're doing a V2 on this thing you already do, everybody has their own ideas about like, it's V1 plus these eight features I wanted and these three things removed I didn't want. And then we're kind of battling from a different starting point in trying to get people on board in a more difficult way. So Nia's, I'm not trying to know how much you know about V1, but did my impression was even V1 didn't handle keys the way that are needed for some of, whether the new or the newly aware scenarios? Go ahead. Yeah, I mean, it didn't inherently, it was more on implementation detail. There was no, I mean, I think that, I mean, there was a, and there's awesome PRs to make some changes and that's the thing that we kind of mainly, deferred to V2, but you know, there wasn't anything inherently problematic. It was purely The registry implement practical implementations and where and some things depending on where, you know, where, where keys were, I mean, like the, but yeah, there's nothing fundamentally problematic. So maybe, I mean, if the, I mean, again, I mean, maybe we need to start off with just making sure we have all the requirements down from the people. Sorry, go ahead, Justin. Yeah, just make sure that we are all clear if everyone understands what the requirements actually are. Yeah, I think that's part of why I think the problem, I think I agreed with Capo said in terms of like, if you had a set of requirements, like tough could come in and say how we address them, right? And the problem on the key management side of things is we haven't drafted that requirement yet. So I'll take the action of kind of like starting that group and getting the requirements together and getting that uploaded. Like if we have that documented by the end of June, I think then we can look into sort of like seeing what parts of that tough addresses and what are the changes we'd need for that. Does that make sense? Yeah, it does. So Marina, I wrote what you volunteered. So it's not just recorded, it's written. And you can edit it if you want. That you would put the initial PR for the key management scenarios. And yeah, obviously you review those, edit those, however you guys wanna do and set up. So I guess maybe a show of hands is at work for the little reactions in the bottom there or is everybody okay with a key management hour or whatever Nia's schedules offline and then we'll say 15 minutes in next week's meeting or the subsequent week's meeting. I'll then ask Amy to make our Monday meetings an hour long and we'll do the larger conversations for the tough notary conversations and then have 15 minutes for a recap of where Nia's has been on the key management. Are folks like a thumb up for that or where do the thumbs up show actually? I don't know where it shows. Oh wait. It's on your video. Okay. I got a permanent thumbs up in your forest. Okay, I got Eric and mine went away. It's their time based. I got one thumbs up. Nobody else wants. All right, no one else has found the UI for the thumbs up. Okay, Marina's got it. It's like whack, not whack them all. Oh, yes, there it is. There's no thumbs down. So I can't really do what is it. It's a rigged right. All right, why don't we try that? Cause I don't hear anybody say no either. So since the voting didn't seem to work very well. All right, we're at time. Okay, so moving into an hour going forward Nia's will try to get something scheduled for the next week and 15 minute recap in that meeting. And there we go. I was trying, I think I've been busy, like I'm sure everybody's been busy with their various planning and so forth or whatever it is people do for their day jobs. I'm hopeful that we will start having some resources available to start, you know, doing that notary B2 prototype thing, the NV2 client, whatever that repo we created. So we could start experimenting with everything from an experience to what something might look like. So I won't have anything done by next week, certainly from a PR, but we'll try to get something kind of maybe written up from an experience point of view that we could start discussing and reviewing as well. So I'm hoping we'll start to see more progress as we've been circling around these scenarios. And thanks for the write up with the scenarios that actually get at least having something to discuss. And maybe we can address those comments, obviously in the doc directly and any discussions we wanna have, we can do that next week. Anybody else for the one minute left? Yeah, sorry, just to clarify, meeting next week onwards is gonna be 10 AM PT. Instead of starting at the half an hour where we are this week, we'll start at the beginning of the hour for what everybody's time zone is. 10 AM PT. Thanks. Radu, you're up late. I'd love to hear the stuff that you guys have been kind of spearheading in Siney and how that could accrue to this as well. I'm actually up early. I'm on PT. as well. Oh, okay. We can definitely check in next week or maybe the week after on the stuff we've been doing in Siney as well. Yeah, I haven't got up with you for a year, so it would be good to catch up. In fact, if you wanna put an agenda now, let me just put the template from the bottom to the top. If you wanna sign up for 15 minutes of the Siney update, that'd be great. Not sure if you're gonna be able to do it next week, but definitely in the next two weeks, I think we'll present something. Okay. All right, thanks, folks. Have a great week.