Session Date/Time: 24 Jul 2026 07:00
[00:00:17] Hank Birkholz: Alright.
[00:00:21] Nicole Wheeler: It's 09:00. I think we'll get started here. I don't see Hank. Maybe we'll give it another minute or so.
[00:00:42] John Harrison: I'll just drop him a quick message in case he's chatting outside. Hank says he's on his way, so hopefully not too big of a delay.
[00:01:36] Nicole Wheeler: Excellent. I think we should start. We'll get through the note well, and and maybe we'll have to pause a bit before I hang to come. But if he's on his way, that's great. So welcome to the SCITT session. You've made it to Friday of the IETF. Yeah. That's a big accomplishment. Right? Yeah. Excellent. Yeah. Take a pause. Congratulate yourself. By now, you have definitely seen the note well, but it is my responsibility to pause on this slide and ensure that you have read it before we proceed. You've also seen this slide. This session will be recorded. It's very important for the remote attendees to always state your name before asking a question and to use the Meet echo queue. And with that, you'll see that we have a very full agenda today. We'll be covering an update on the current SCITT core group specs, which will be Hank's five minutes if he's able to to make it from his conversations. We'll also start with a an update on the CCF profile and a new joint statements extension by Omri well as an MMR profile, a call for adoption from John. We'll move to the hackathon report and new incoming use cases that we've been seeing in the last, six weeks here in the SCITT Working Group. And, of course, given all of the incoming new requests that we've seen, we'd like to have a pause and discuss the future of the working group. Anything else you'd like to add, John?
[00:04:11] John Harrison: Nope. Sounds good to me. Just a a reminder for folks to keep the time. And if they don't, we'll, we'll curate that, but, let's see. Kraken.
[00:04:41] Nicole Wheeler: In the interest of time, John, do think we should skip to the next session and give Hank a few moments to to arrive?
[00:04:49] John Harrison: Sure. Yeah. Let's do that.
[00:04:50] Nicole Wheeler: Excellent. Alright. Omri, over to you.
[00:05:05] Amari: Hi. My name is Amari. I work at Microsoft.
[00:05:07] Nicole Wheeler: And you wanna speak close to the mic. It doesn't actually pick you up until, like, evening.
[00:05:10] Amari: Hey. My name is Amari. I work at Microsoft. Is this better? Yep. Okay. Great. So I'll talk about two things quickly. One is the CCF profile. This is something that everybody's seen before, probably, presented it multiple times, and it's now waiting for a IESG review. It's a different algorithm for the Merkle tree that you use when you include receipts. So you're you're probably familiar with the COSE_Sign1 format that we use for receipts, the way the payload is detached and is new, and it's the way you have to use the the VDP arguments to reconstruct from the proof elements, you know, what the what the signature should be, and then you can verify the envelope. So this is kinda how you get these signatures over something that needs to go through a tree algorithm or more generally a VDS algorithm before you can, you know, get the binding of of the actual entry that you've you've got in your in your transparency log. So why do we need a distinct VDS profile with for CCF? Why can't we do the same thing as everyone else and use RFC nine one six two? That's a fair question. And so the the reason for that is we can have sublease. So we have the data hash, which is this Git science statement. That's the same thing we get in nine one six two, but we also need a couple extra pieces of information there. So one is we have an internal transaction hash. That's because CCF is quite a rich system, and we capture the governance of the system in in the ledger as well. So all the the transactions that add new nodes, that capture hardware attestation, any any all the governance that basically has to do with the ledger as well as the data is also captured in a tree. We think it's really important that it should be bound together. We've not pushed personalization of that because it's quite it's quite a complex system, and there's not very many like it. So we want that to continue to exist next to the data itself, which is the the statements that are being registered. But if you want to connect a more in-depth audit of really literally every operations that take that that's taken place, this is the way they can do it, you know, using this using this format. The second thing is we have internal evidence. So CCF is a distributed system. You have a set of nodes that are talking to each other, and you're trying to replicate data for a number of reasons. But one of them certainly is durability. You're trying not to lose data. It's really bad if you lose your transparency log entries because you you're effectively doing force when that happens. So one of the ways to do that is to persist stuff to disk very early on, including the signatures. But then the problem you have is this could be this could be misused by people who are trying to issue receipts even though the consensus has not taken place yet. So a way to do that, which is a very old technique, the citation to profile is actually from the eighties. It's less scans typewriter paper, is to include a commitment. So you you have, like, a one way function, and then you reveal what you've committed to afterwards when once the thing is is committed. So that's a nice cheap way of doing this without doing a double signature or doing re encryption or something expensive and more demanding for for the relying parties. So, yeah, it's a pretty simple extension, but, you know, there it is. Yeah. So this is this is sort of like how the leaf construction works. So you've got these these three subcomponents, and then you can you can reconstruct things. And you can you can get to the you can walk up the tree. And in the end, the the COSE receipt at the top looks the same. It's just that you have the proof in there. There's a different VDS value, and the, yeah, the proof looks very similar to RC9162. It's just got this extra, you know, sub leaf sub leaf elements. So that's that's the CCF profile in a nutshell. And you walk up the tree. We've simplified it a bit to make the the writing of the verifier really easy. So we've got, like, boolean bits that tell you which direction you go. You don't even have to do any size calculation. Even my kids have written verifiers for this. This is really easy. Okay. And so with that, I'll switch to a different topic, which is so this is something that we've come up with with Yogesh. I don't know if he's online in the meeting right now. Maybe not. He couldn't make it. He was he was flying back, I think, late last night. So we would like to propose a very small extension to SKIPT. So as you know, SKIPT right now is based on COSE_Sign1. So you can have a single issuer. You send things to the to the ledger. It gets or to the transparency service. Right? It gets made transparent, and and and you get you get proofs back. But what if you want to have artifacts signed by multiple parties? So an example is you have component firmware, and maybe you have a signature by the component manufacturer with whoever's making the chip. It could be a signature by the device manufacturer to say, like, yeah. This is included in my device. You have a signature by the enterprise deployment authority. So if you work at boring big corpse, you know, people sort of like to make sure that everything that's on the network that's allowed to access enterprise network is, you know, signed or or authorized in a certain way. So you end up potentially with, like, a range of signatures pointing to the same thing. Can you make them all transparent separately with their own receipt? Yes. You can. Would it be nice and convenient to bundle them all together and make them transparent at once? Probably would be. And as it happens, we have a nice cozy sign type in RC9052 that already exists for this very purpose. And so we could decide to use this format and to say, oh, actually, you can register those as well. So you do need to make a couple tweaks, but what you'd get is a single transparent statement with multiple authorities. Doing okay for time? Yeah. Great. So this is a strict extension. There is no change. This isn't breaking anything. This isn't, you know we're not going back on anything we've done. This is just saying, like, also, if you want, on top of COSE_Sign1, you could support COSE_Sign. We make it we keep it unambiguous for single issuer statements. We say, like, if you're a single issuer, you gotta stick to COSE_Sign1 like now. But if you want to support multiple issuers, you can you can do COSE_Sign. And so it's pretty short additional document. This is linked in the last slide. Key points are all the signatures must be verified by the ATS. We're not taking stuff in and checking only some of the signatures. That would that would be questionable, I think. And the registration policy that we have now that's defined that needs to pass on the one signature today. It needs to pass on each each signature on on every single one of them, which is signature and signature specific header. So it's a feature of COSE_Sign. So, again, the change is completely incremental. The stuff that's compliant with 9999943 remains compliant, and this is just adding support for multisignature joint statement registration. So in terms of implementation, it's pretty simple. You dispatch on six ninety eight. And then when you see that, you go like, well, instead of doing one step over the signature, I iterate over the signatures during the statement. For each one, I apply the same registration procedure as today for for COSE_Sign1. And then this goes through. The receipt is totally unchanged. There's no change there at all. And key thing to note is that when you get a COSE_Sign1, the signatures kinda exist not necessarily in a particular order. I mean, they're encoded in c word in a particular order because it's an array, but, you know, technically, you could reorder them, and then the the verification wouldn't change. It'd still work. But here, obviously, when you're making things transparent, you're committing to a specific set of bytes in the ledger. And so you're you're encoding. You're making canonical, like, this order of signatures on ledger. So that's that's important to note. If you're if you were to reorder the signatures, that proof would break. Right? I don't think it's a huge problem, but I don't it's a thing I wanna flag in case people wanna discuss it or they're concerned or even if they have ideas on how we could how we could avoid that. So there's a LinkedIn draft here. And if people are willing to go and have a look and give some feedback, that would be great. So that's that's basically it.
[00:12:55] Nicole Wheeler: Thank you. I mean, actually, I'd like to pause and see a show of hands for anyone who's interested in reviewing this draft so we could note that.
[00:13:05] Carsten Bormann: Excellent. Yeah.
[00:13:09] Nicole Wheeler: If you can please use the tool and then your name.
[00:13:23] Carsten Bormann: We
[00:13:30] Nicole Wheeler: have a few minutes. Are there any questions before we move on?
[00:13:48] Hank Birkholz: So this is crypto resilience.
[00:13:55] Amari: No. It's multi issuer statements for SCITT. If you wanna use COSE_Sign with multiple signatures. Yeah. Does that make sense? Yes. Hi.
[00:14:16] Telefonica Representative: I'm also working on a draft
[00:14:19] Carsten Bormann: in Can
[00:14:19] Nicole Wheeler: you can you state your name and organization, please?
[00:14:21] Telefonica Representative: From Telefonica. I'm also working on a draft in ops of which e which uses as COSE. And in this first in this new version that we bring in, we were trying to do multi sign with COSE_Sign, and we also bring it to the hackathon just so if if you were aware for the CozySignature stuff to do multisigning. I don't know if in this use case, you want to sign all the entities at the same time. If you want to do it separate at different points of time, what I encounter is that you need to use instead a COSE countersignatures instead of this. I don't know.
[00:15:14] Amari: I I don't I don't think it you need to sign everything at the same time. I think you can sign things incrementally with this as well. Right? The difference with COSE signatures is that everybody's signing the the same target thing as opposed to signing each other's signatures. Does that make sense?
[00:15:31] Telefonica Representative: But well, because we do it with the JAN data models and we enclose the signature inside the the data, maybe that's why I I need to use the signature. But just to add this information.
[00:15:50] Amari: Thank you. I think if you have a bit of time after, I'd like to talk more about this. Yeah.
[00:15:57] Nicole Wheeler: Excellent. Any more questions? No. Good. Then thank you, Omri. Hank, we're gonna resume.
[00:16:12] Steven: How much time?
[00:16:13] Nicole Wheeler: Five minutes.
[00:16:14] Carsten Bormann: Okay. Bring
[00:16:15] Nicole Wheeler: it on.
[00:16:16] Carsten Bormann: I have a clicker.
[00:16:17] Nicole Wheeler: Yes. That's a bug. You'll have to
[00:16:19] Hank Birkholz: There's been a lot of clicker fun this week.
[00:16:24] Carsten Bormann: Click. Oh, that's bad. Okay.
[00:16:26] Telefonica Representative: You have to go back.
[00:16:27] Hank Birkholz: Oh, have to oh, hi. Let's do the archive time machine thing. Am I really gonna do this?
[00:16:37] Telefonica Representative: No. No.
[00:16:38] Nicole Wheeler: No. Go forward. And
[00:16:39] Hank Birkholz: stop. This is me. I found myself. So we did quite a few of successful logistic work, and we're jumping directly into the problem. So 9493 and 9492 have been published.
[00:16:59] Evangelos: That's great.
[00:17:01] Hank Birkholz: I assume you're all aware. So we can stop with 9493 because we immediately realized that EDN is something we should check multiple times with the interesting change of lane how to do the RPC with XML. There were very many concurrent versions, and we kind of managed to get some version in that has the wrong EDN in it. So our strings are not quoted, and I think our null is in there. So because it's copied from the CTD head, it's not okay for EDN. There are two issues with the EDN examples in the 9493, which is not entirely super horrible. But, also, if you want to go validating examples against the CTG, it doesn't really work. So so that's bad. We were going to issue an errata this week if we had the time. But we will do this in the upcoming fourteen days, and this is a relatively straightforward thing. I think green, correct, and current shows the problem. No quotes around the things that we maybe we have a slide on the. But there's another issue. And then then. So so this is this is relatively straightforward. It is a little bit unfortunate. I know I understand that people that are reading RFCs sometimes ignore the Errata link. I don't know what it means, but here we are. So we have an item going on, and that is going really well. It's in working Google's call. We got a ton of interesting and useful feedback from the ISG, especially to the to the topic of how to deal with operations and process progress. Sorry. There we go finding a service. We're going to have the the the the statements that you actually want to put into the service and then how to get a receipt back when you are already done with registering a thing. Next slide probably is going into the yeah. Exactly. Timeline. Actually, I can make this way better than I can read this downstairs. So so we have been basically through most of the items. We are in the RPC now and which means that everything has been addressed by the ISG. I think the most important part here is that some from some, I wanna say, more intuitive error coding, we all went back to a variance of two o something when this goes to items in progress. I think that's that's actually better. We in the design phase, we would have wish that would have come up with Vulcan Glass call, but the ISG told us what to do. So that happened in a in a stage that's still fine. And I think this is now normatively done, and we are we are doing the editor work. I'm not entirely sure where we are, but I think everybody already approves the submission. So I guess this is just a matter of days now, maybe a few weeks. So that's the state of 9493. That is the architecture. Nine nine four two are the proofs that has been relatively smooth sailing on common seas, I wanna say. There's this unified receipt format. Receipt formats are our prime interoperability place. Whatever you do, if you register something on a very different transparency service with very different data formats, let's call it JSON and maybe maybe some form of JSON that's not even a JWS, and you wanna register all that in a in a transparency service, you can still create a proof that is in our format. So this is our prime interoperability place, and this is why we've took care to include registries for different VDSs, we call them, verifiable data structures. So this is in the middle box here. That's the service, and there's always a verifiable data structure. And sorry for moving away from the mic. And so that is what what what is really the the the nice piece here because when you have a different one, you don't do Merkle trees. You have a hardened, I don't know, MongoDB. And you can prove it is a reliable, verifiable data structure, and you have a specification for that. You can register that as a designated expert, of course, for the VDS registry. But if you can show that's viable and that is the place where you can do this this proof creation, and then then it it gets registered, and you you you're fine. So so I think that is where we can interoperate best because sometimes you sign statements differently. Sometimes in the world, there's established technology or just a common trend. And and here, we have interoperability on the on the receipt sites. We also have, of course, the indirection of signing that is relatively straightforward. Cozy has a detached payload, and we realized, well, that is not really enough. You just have the Cozy envelope without the payload. Now we have a dedicated COSE envelope that says the payload is somewhere else. What we hash is the explicit hash of that payload, and we'll give you some metadata, where it is, what is the media type of the thing where we actually hashed, all the things that you want to really retrieve. But that, again, is was very straightforward, actually, but we there was a gap. We didn't really do this all and all the time. And so that was me, and I'm almost in time.
[00:22:57] Nicole Wheeler: Perfect.
[00:22:57] Hank Birkholz: Any questions on where we are with 9493, 9492, which is done, and the 9995. If not, I can hand over to the next presenter.
[00:23:12] Nicole Wheeler: Thank you, Henk.
[00:23:13] Hank Birkholz: Sure.
[00:23:20] Nicole Wheeler: K, John. I'm gonna turn it over to you.
[00:23:23] Amari: Thank you.
[00:23:26] John Harrison: Yep. So you'll hi, everybody. I have my chair hat off for this one, but Robin couldn't make it. So I'm gonna be a stunt Robin for for this one. I think I'm gonna just ask you for slides. That's alright. So click. So this isn't a new topic for for those who who remember. Way back, five IETFs ago, the CCF profile that Omri was just talking about and this MMR profile were both presented to the Cozy working group for an adoption call. And then through the machinations of the IETF, we eventually came back around to thinking they were better honed in the skit working group than the cozy working group. And somehow, we forgot to adopt this one, when we when we made that switch. So, I don't have many slides here, but I appreciate a number of people in the room are new, so maybe I'll voice over a little more. But this is the same thing that was presented, got a soft, adoption approval way back when in a different working group, and we're just looking to officially rehome it, back here. So it's on data tracker, The old presentation with loads of detail in it is is on this link. And if if you wanna go back to that, then then please do. Slide, please. So why do we need another profile? You know, there's there's the old joke, you know, which of these is fastest? And and the question comes down to, well, are you on asphalt roads or in the desert, and how many of you are there? You know, you always have different technologies and different things, different use cases and purposes. And so this is exactly why we established the VDS, registry and and why we've got that extension point that that Hank just mentioned about being able to have fully interoperable receipts whilst not tying everybody down to exactly one type of crypto infrastructure for for doing those kinds of proofs. So slide, please. So, very quick recap, on on what the Merkel Mountain Range VDS is. So, again, you you just saw what was presented by Omri for the CCF stuff, and that has lots of nice qualities that lean into enhanced ledger operations and and things like that and some of the confidential aspects and and the hardware assistance and everything else that you get from the CCF profile. This one's really about being lightweight and speedy. So, if you look at the the the picture, for anyone who doesn't know, Merkel Mountain Ranges, a couple of nice things about how Merkel Mountain Ranges grow is that you actually start from right to left on on this picture, if you wanna do it that way. So you start with one thing. Oops. That mountain's full. I'll move along. And then you have a Hooray tree. And then when that fills up, you move along and next door to that, you build a threary tree. And you just keep going along and along and along, and every time your tree fills up, you just make another one next door. And those two roots, the purple guys, you can have a second kind of meta tree that puts those together as well. So you take the hash of those two things and put them on an, an interior node. And now you've got a choice of lots of tiny trees that are independently verifiable or one enormous mountain range that is completely verifiable, and that gives you lots of really nice qualities. So one is that it grows, linearly and in time, so you automatically get time ordering. There's also some crypto in the draft, using Snowflake IDs to make sure you get actual real time ordering. But if you only care about order as opposed to clock time, you get that for free. Appends are fast, and you don't need any kind of locking when you've got a lot of writers, especially for a VDS in a distributed system as opposed to a kind of centralized transparency service. You don't need to lock the tree because appends are, essentially, conflict free. Audiences can replicate them, and you've got a lot of options for how you store and chunk up the data. So to answer the question, about why we don't just use satellite logs or certificate transparency basics, There's a lot more flexibility and a lot cheaper operation with Merkel Mountain Ranges for chunking up the log, than even the tiles system that, certificate transparency now uses. So it's just it's super fast. It's super flexible. It's super lightweight. It's super cheap to implement. And yet you still get all of those qualities of the full inclusion proofs. You also get consistency proofs with this free. And so, that all of that leads to the statements from people like Joseph Bono. Merkel Mountain ranges are optimal for these kinds of use cases, and that's why that profile exists. So click, please. So, this is gonna be an adoption call. We're looking to redo what we did, back at 01/21, just make it official. But just to to point out where we're at, there is a o three draft, which has already been reviewed by, a few people, including the authors of the CCF profile. So we're very confident in the quality of that document. It is functionally complete. There are two complete independent implementations of it, and I think five implementations in total that we can lean on for interoperability and correctness. And, yeah, there's just one to do, which is that it's currently based on a single hashing algorithm for generation of the paths, and that doesn't feel ideal. Maybe we want to add a an agility extension point. But beyond that, it's it's complete and implemented already. So, yeah, looking for, firstly, anyone who objects to adopting this, and secondly, a handful of volunteers to review so that we can adopt with with confidence. I think in the interest of impartiality, Nicole, you should make the official adoption call since I present it.
[00:29:56] Telefonica Representative: There we go.
[00:29:57] Nicole Wheeler: Exactly. No. So same thing. So I'll ask the room. Who has read the the draft? Show of hands. Okay. I mean, I have I have read the draft, but good. Then can we do the same thing as we did earlier? Can I please have a show of hands in room and then to add your name in the chat if you are interested and willing to review this draft MMR profile? Thank you, Carsten. Any questions or objections? No. I'm aware there's a show of hands tool, but it doesn't collect names, and I would really like appreciate names for the review of the drafts. Thank you. Hank, does that mean that you are going to review the draft? Hi.
[00:31:32] Hank Birkholz: This is Henk. Of course, the tool doesn't record names, but the minute taker can. And then, yes, I've read the draft, but I was not okay with raising my hand without people seeing that in the hybrid meeting. And that is why I was telling asking for their hands too. So, again, yes, this is a good draft. This is an excellent wait for for optimization. I think we have other optimization we could do here, and there might be upcoming. And I have just convinced certain coauthors. Yes. They're looking at me, and they're now shaking their head. And that we can do. And but this is this is this is great. So so we should do exactly that, and I'm in in full support and review. Thanks, Heng.
[00:32:39] Anton: Alastair?
[00:32:42] Hank Birkholz: Sorry. Wrong wrong hand. It
[00:32:48] Nicole Wheeler: is Friday. It's okay, everyone. I thank you to those three that have agreed to review the draft. Alright. Thank you, John. Alright. With that, we'll move on to the hackathon report. I'll turn it over to Steven. Steven, thank you very much.
[00:33:06] Steven: Hello, everyone. Can you hear me? Good. Yes. Fantastic. Steven and me, excited to be here. Came here a week ago, and I'll go over the hackathon report quickly. The chairs asked me to focus on the proposal, and so we'll we'll talk about that as well, but they fed each other. And, see if I can go forward. Okay. This is about, JSON record becoming a signed statement, and, this is all derived from what we learned during the hackathon. And, I'll go through why that is. This is not anything to do with payload semantics, so it should look very familiar with this working group. And I believe it's all in charter. We also have Anton who was in the hackathon, and Sato san was also in the hackathon, so they might, comment as well. So first of all, we had seven independent parties. They all ran, and they had four code bases that reached by agreement. They had to go through their own layer and find this, and it took us, in some cases, many, many days to figure this out, to to get a a pairwise agreement. And then we were able to get to a place where they're all composing by digest, and that where's where this idea came from and how we're, proposing to this this working group. These are the seven and, a very successful workathon. I think it was it took all week. And so, each party had to rederive, and that's what I realized as I come here as a builder. And I came building my own slots, my own gates, my own verifiers, and, end to end. But then as I started working with others, I found there's dozens of us doing all this. And then to be able to add a transparency service to it, it became a huge battle. And I realized that's the part that is not something we need to compete upon, and it's a simple problem that if we solve in a canonical way, we can unblock a lot of this and enable the usage just in the same way that get solved objects. And if you look at how OCI did images, same stuff. And why is it now? Well, we all know that there's a number of regulations that are coming that are already starting. FCA just started last week, and one of our hackathon partners worked with Rampelli and his slot. And they're experts in compliance and wrote a report on how they all match up. But, again, it took a long time to get to that point. So we know that there's a this is more and more important to be able to know what is what an agent did. Although this is not agent specific, and that can come as we determine where those fit in the working groups. We all know that agents are nondeterministic. Therefore, the evidence layer is becoming more and more critical for that. And we're we're seeing that if we don't do something now, then, well, the industry will start to come up with stuff, and and we think that's less competition overall. That's my personal view. And this is, again, something that we're seeing all around.
[00:36:30] Carsten Bormann: You're gonna
[00:36:30] Steven: hear more about different areas that could be leveraging this tech this approach. So instead of having n number of answers, you just have one. And now this is should look familiar with from some of the previous slides. This was RFC 99, 95, was it, that just, came through twelve days ago. And, so this is about, a similar approach. There's no semantics in this, so the payload is completely separate. And this is deliberately looking like the ninety nine ninety five, the JSON record. It has a canonicalization suite plus the hash, and those are then signed. The COSE signed one, and the receipt is the $99.42. So this identifier is derived, and the hash is over the payload minus the declared self referential fields, and the verifier is best recompile. And that is how it's all trusted. So it grows just by the registry, not by the list. And I think it's, again, a simple problem that if we solve, it opens things up. This is what's not in the in our proposal. There's, again, no payloads and no agent semantics and the transports, no registration policies. So this makes it very clean, and and we think that this makes it very, very common to what we already do today. So it's the statement side twin to the receipt side that you saw. And this allows us to then compete at the layer above, which is the slots. In the case of building agents, which I do, there's slots for who the agent was, identity, what they're allowed to do, that's the may, And then the what, which is what it did do, that's what the agent action capsule. That gets extracted from the this proposal and competes with everybody else just like like everyone else does. The customers get an easy, flexible way so that the auditors can then verify their their the the the ledger very easily, and, this makes it much easier for all. And so this is why this fits within the the this working group specifically okay with cross posting this to the COSE working group like we've done before. And so we think that this is important to solve sooner than later, and, we put it up as consideration. We know a lot have not, read this yet because we're finishing it this weekend. And the coauthors will be Anton, myself, and it's still forming. I appreciate the chuckle, but we've learned this from actual working experience from the the seven different hackathon folks, and it became like, an moment for a number of us at the same time. I do wanna say that, the discoverability was first, which Hank did on the conversation side. And so, we we we found that to be something we wanted to adopt. Okay? And so, again, this is about the, canonicalization of the, the binding profile and, no semantics. If it turns out that, that can go in this working group, fantastic. We can discuss that. But I think this is something we can get going sooner than later. And, either way, we already have that canonicalization that's, all in the repo. You can find all the the the results pen. It's all, on the repo, and, there's all working code. I think that's pretty much covering it and got done with four minutes to spare. Anton has a follow on that will share his perspective on this as well. But any questions? Or I'll turn it over back to the chair.
[00:40:46] Nicole Wheeler: I think we'll go with questions. So thank you, Steven. The number of questions, I think, presented and brought up, and and we're definitely going to discuss a lot of this again in the last agenda item, which is the future of
[00:40:59] Carsten Bormann: the working
[00:40:59] Nicole Wheeler: group. So first, I would pause to ask if there are any questions that was just presented here.
[00:41:23] Hank Birkholz: So hi. This is Hank. We are very happy that the that the payload and you were taking great care of of of maintaining that demarcation line. The payload is opaque, but our charter is very software of material specific. I see a disconnect between the charter goals and what we have done right now because now SCITT is a very versatile sidecar that you can add to any kind of data structure and BDS, obviously, and and and and the existing silos of that are the the nine nine nine five enables us to notarize the whole resources on the Internet in hindsight. It's great. You don't have to move the data. We can just say it's there and and something. But but I think I feel that the the the software consumer part is actually not addressed yet. So so I I I saw the AI bomb and and the bomb stuff. You carefully put that always in the end of the the bottom of the slides because we want to be payload agnostic, which is fine opaque. But but I think Charter kinda tells us not to be in the software bomb side. And AI bombs are software bombs to some extent. And I'm I'm wondering if that is part of a discussion here because we are in support of the software supply chain. And we lost a few participants over the years. They were just coming here to ask, how do I get a notarized statement that this SBOM is the extra SBOM that I want? And they left because we cannot answer the question. And maybe that is because the problem statement of the charter has not really been solved entirely yet, but we have discussion later.
[00:43:17] Nicole Wheeler: Yes.
[00:43:18] Anton: But I
[00:43:18] Hank Birkholz: think your item is an excellent in between steps, so I love it. So thank you.
[00:43:24] Steven: Thank you, Hank. And I think that's a great question posed to the the chairs. In terms of again, there is precedent set, and, we think this is within the charter. There sure could be more, definitional, areas for the working group to consider, and, we welcome any reviews.
[00:43:43] Nicole Wheeler: So with that, I think I'll do another ask. So, if you are interested in reviewing the work that Steven is doing, I think you'll post a draft to the skip mailing list would be the best place for it.
[00:43:53] Steven: That's correct. Do have one? Anton and I will will put that on there. It's a derivation from the agent action capsule, so that will shrink. And, so, it's right around the corner.
[00:44:04] Nicole Wheeler: Then like all else, if you are interested in reviewing that draft spec that will be done, you said, this weekend to be sent to the mailing sometime next week? That's correct. Individual's names in the chat so that we can have that as a record for the meeting for our next working group session in, I believe, this November in San Francisco. Great. So I'll pause for people to put their names down if they're interested in the chat. And with that, thank you, Steven.
[00:44:29] Amari: Thank you.
[00:44:57] Nicole Wheeler: K. Anton, I have passed slide control over to you. You should be able to advance the slides.
[00:45:05] Anton: Okay. Great. Thank you. Okay. Thank you, Steve. Steve just shown 13 slides of things that verified, and I have five minutes on the case. Verify actually has to survive. The case when they have verified. Steve's readout had a row that joined two things, an action record in skip and platform evidence appraised on the remote attestation procedures threats. The negative branch of that row gives one simple rule. Record validity is not is not platform validity. So start on the left. This is the agent action capsule with its SCITT receipt. Three checks passed. The C war object signing signature checks and the content binding holds, so the Merkley inclusion proof verifies. The verifier may conclude one precise thing. This exact action record was registered under the transparency services policy. So that is a historical fact. A failure elsewhere does not erase it. So now when you look at the right, this is rat's appraisal over platinum evidence bound to agent action evidence package. The quote signature verifies the outcome that I just buy binds, but the nonce is stale. So that it doesn't prove that the platform is bad. It means it means something narrow. So there is no platform backed assertion for this verify in this session only now. The two these two legs, left and right, they answer different questions. At band, only inclusion asks, was the record in the history? And notes of freshen freshness asks, is the evidence fresh for me now? So the claim we that is composed, it needs both, which is, which are joined by Digest. And so as Steve said, the digest match alone is is cannot be an authorization success. And here is the operational form. A digest is a join key, but not trust inheritance. So the relying party rule has three steps. Keep the separately verified script record and deny the composed platform back play. The report repo and we report which appraisal, like, failed and why. Pass and fail is fail. So green checks are not really green checks are not contagious. Now the status precisely. The the positive cross run between the agent action capsule and action evidence is the completed interim result. Uh-huh. Now let's look at slide three. This is not just the diagram. It's the European digital identity wallet reference wallet that is running on my phone currently. We issue a machine a mandate credential over open OpenID for verifiable credentials issues open OpenID for VCI. We present it over OpenID for VP, the verifiable presentations, and machine mandate is our research profile. This profile is not is not directly required by EUID wallet credential type is not a required credential type. So the AEP means action evidence package, and agent action endorser is implementation component in this pop pipeline. So the builder's question my question is which inter interoperability seems belong in this room. So the scoping question that Steve ended with has an answer. For for re recharter, Skit could own the interoperable evidence team, and Skid should not absorb agent semantics. This means the mandate, delegation, and endorsement of a caliber, the can, who, what, and audit accountability policy. So my question to the room is can skip through charter the interoperable evidence seem registration policy, receipt portability, and digest bound composition without rechartering the agent. Thank
[00:50:15] Nicole Wheeler: you. Thank you, Anton. Could I ask a question, I guess, slightly as a chair and slightly as an attendee? In in the draft that you both are writing and proposing, is this work captured as part of the draft?
[00:50:35] Anton: Yeah. Steve is So
[00:50:40] Steven: the the part the draft is only focused on the left hand side, which is the nonpayload portions of
[00:50:46] Nicole Wheeler: it. And then I propose that we table the question of whether this belongs in a recharter for the recharter section at the end, knowing that the use cases here do prompt that very question that we've saved for a longer discussion at the end of the session, if that's okay. Perfect. Thank you. With that, I'll move on to, Evangelos. K. Give me a minute, and I'll and I'll
[00:51:17] Evangelos: So this may be
[00:51:19] Nicole Wheeler: You wanna you wanna talk really close to the microphone.
[00:51:21] Evangelos: Hello, everyone. My name is. I'll be presenting work we're doing on the CoVolution EU project. It's about AI and bombs, so that may be a little bit controversial. We'll see.
[00:51:36] Nicole Wheeler: Thanks for the heads up.
[00:51:38] Evangelos: It's just a heads up. What's going so what we're trying to do is provide security, trust, and robustness across the all the all the AI life cycle phases, design, training, testing, deployments, and inference based on the security, privacy, and explainability principles. We have self monitoring capabilities, data detection, and, of course, we have some real time incident reporting. I'm going to focus mostly on what's related to Schiz, so just introductory that was so one of the outputs of the the project is about what we call the AI model builds of materials, which is inspired by software bonds, which may be good for this working group, enriched with data provenance, model details, ethical compliance, legal compliance, the UAA act. We describe datasets, dependencies, owners, security related information, and we want to act it as a carrier of credential for this for the AI model through the that that has been gone undergone under the entire model life cycle in order to provide this kind of transparency to the to the users of these models. So this project was written before agents became a thing. So it's mostly focused on on AI models, but we could probably extend it to AI agents. So we have a number of properties like reproducibility. You can take the AI involvement and reproduce the results. Accountability, who owns it, assessment of it, what kind of assessments have been done, what kind of robustification it has undergone, the ethical and responsible AI information. Each AIM BOM is unique to an AI model and, of course, all the risk assessment that's been done. This is the process of how to develop it. We have a number of engines and a number of reports that are getting out of each of the engines. We have a risk assessment that can also provide you information about your development environment so that you can find any vulnerabilities that could leak into the model and to the development of the model. Security assessment's one that's ready. Then we go to the robustification phase, doing a adversarial kind of assessments and and defenses, and then going through the process again and again until you're satisfied that the model is sufficiently. So all this information coming out of it is going to the to the AIM bomb. So from our perspective, the supply chain example is like, you you create all these AIM BOMs through this coevolution ML DevOps, and then you have the models with the AIM moment. This can be exchanged, And then you you are able you know, when you get information or you get data from one model, you can verify that that model is secure for such a specific you you know who it is, who have done it, what kind of defenses have been applied, all the information that exists in the in the AIMBO. So right now, we have written the AM bomb as a set of interconnected CycloneDX bomb bomb documents. We have one AM bomb document that access the center point and all the other information are linked with that with that document. So where is where is skip place here is we as we say as I said, we want to use the AIM BOM as a as a carrier of credentials that says, I am this model. I have this I these are the defense that have been applied. These are probably some weaknesses, but we didn't care because they are not applicable to the other use case or the legal information, etcetera. So we want to act as, you know, as a as a statement. And it could be exchanged and can prove that the model has been that is secure for specific attacks that has been assessed. So in this the AIM BOM is just a collection of documents. It's they are statements, and we want to sign and store so that they can be verified by the whoever wants to use it or to to to interact with these AI models. That's it. I hope I was fast.
[00:56:21] Nicole Wheeler: I knew
[00:56:22] Carsten Bormann: it. I
[00:56:22] Hank Birkholz: knew it. Good.
[00:56:23] Evangelos: So any questions, comments, or, you know, this is not in the charter yet or something?
[00:56:34] Nicole Wheeler: Well, I see that we do have a queue. Hank, you're in the queue first.
[00:56:37] Hank Birkholz: For the last
[00:56:39] Carsten Bormann: Oh,
[00:56:39] Nicole Wheeler: for the for the last one. K. And then
[00:56:41] Evangelos: Ah, okay.
[00:56:46] Nicole Wheeler: Any questions? Anton, are you in the queue, or was this a previous queue?
[00:56:58] Anton: It was pre previous queue.
[00:57:00] Nicole Wheeler: Excellent. Previous queue.
[00:57:02] Carsten Bormann: Well, I'll
[00:57:02] Evangelos: be here if you need any inform any more information. Thank you.
[00:57:06] Nicole Wheeler: Thank you, Evangelos, for presenting your use cases yet. Next speaker, I invite Gregor. Hi.
[00:57:26] Gregor: I'm Gregor. Nice to meet y'all. I'm today I'm here today to talk to you about software supplies and communication. So first of all, I do apologize that Daphne is not here with me. Minor short term health risks associated with will visiting the electromagnetic field festival last weekend have materialized, and thus she sends more apologies. So let's start. So the idea is that there is questions of compliance coming up on all kinds of open source projects, and, thus, it might be a value based idea to communicate along a software supply chain. There's the cyber resilience act that enters enters into force. It will actually register legislate open and free and open source software. Then there is the executive order that we have fourteen o twenty eight. Then there is the secure software development framework by NIST. And then there is this fiber ruling by the US Security Exchange Commission and cybersecurity risk management strategy governance and incident disclosure. There is SALA, which is a safeguard artifact integrity across software supply chains, which is pushed forward by industry association. And then there is a National Telecommunications Information Administration that also have their thing to say. So that's quite a lot of regulation that's coming down. And then the question is, if you look at the charter, why would do we wanna distance it? Because you wanna publish supply chain data for decentralized that is decentralized globally and interoperably, and we wanna identify compliance critical communications within this ecosystem to help people actually be able to salvage this this information. So imagine you are a prominent European open source project like NICSOS, then you will find yourself that to have to adhere to four market surveillance authorities, which are in NESA, the National Cybersecurity Center of Netherlands, the and the port of Because Netherlands. You have FOS up and downstream project that you wanna interact with because you rely on the Linux kernel. You have other stuff that's built on you, like this wonderful nut bolt that gives you a CICD pipeline. Then there are dependence and manufacturers like Skypilot that allows you to balance AI info AI workloads over several infrastructures and determinant system. That's the enterprise version. Then you have your forges. And maybe you also have people who might want to reveal IT security things to you like white hats, AI hats, and black hats. The middle part will cause problems. So if you wanna publish supply chain data decentralized globally and interoperably, you might wanna identify compliance critical communications within the ecosystem. We gonna focus on the market surveillance authorities, the fast projects up and downstream, and proprietary dependence. So the idea is if you wanna publish supply chain data decentralized globally and interoperable, the first idea is to work with your badges. An idea that was born on Wednesday is get standards badges, have your open source project show which standards they adhere to. Then if you wanna identify compliance particular communication that's coming from your micro surveillance authorities, you might ask them to actually get a PKI. If you wanna identify compliance critical communication by FOS projects up and downstream, you can follow a very short algorithm that goes you write a message, you publish a hash account, offset message within your Forge account, you send an email to security act with a pointer to the hash, and then your project runs some kind of centrality measure, perhaps a Buscany measure, like we have seen in the patch a goocha or something that makes more sense.
[01:01:14] Carsten Bormann: Okay.
[01:01:15] Gregor: Then you can look at the dependent manufacturers who choose your package. They get receipt of properties from a notary with a package that was a unique identifier. Then they send a donation to your beloved open source projects associated with the UID, and then they actually send you some compliance particular information. They attach a list of the UIDs that they sent you, and then you can assess if this fingerprint of the UIDs actually fits with a certain with with donations you have received. Last but not least oh, come on. In scope, steps that we would like to talk about are security and privacy guardrails for all stakeholders, technical soundness, and applicability. Out of scopes are inference with governance of the open source projects and creating obstacles for business innovation and market creation. Questions to what is in scope and which would be out of scope is which software supply chain regulation should be considered. It would be especially interesting to have insights on what's in the making, best practices in which RFCs seem to talk to, and what we did miss. Caveats are trust as a social question. Technology can help not answer it. Malicious fixes can be downstream targets. Fraud might be a really big problem. Impersonation and related attacks, open source software suites might be a vehicle for money laundering. So what did we miss? And this is a double slide. So those are the asks. Are you familiar with those regulations and eventually tooling for compliance? Do you know how to put badges on repositories? Do you wanna talk to orgs, come to code and compliance on the October 27 in Brussels, which is the working group working on with the European Commission? And do you know how to identify AI hackers? Please let us
[01:03:08] Steven: know. Yeah.
[01:03:15] Gregor: Okay. So if your security reward comes from Carson, read it. Yeah. I guess the rest are questions when it comes to the future of the working group.
[01:03:28] Nicole Wheeler: Yes. I would. I'd put them in the next section. Any questions, though? Let's pause. Please add yourself to the queue. Benjamin?
[01:03:37] Ben Curtis: So, Ben Curtis, have you as you're thinking about supply chain integrity and those types of things, have you started to think about some of the other organizations that are actively building software that do this today, such as Linux Foundation has an open GTC project for their kernel developers that that I'm involved with? If you're not, I can introduce you to them to see if some of this work they're doing now would adopt something like this.
[01:03:59] Gregor: We're talking to them in the org working group.
[01:04:02] Amari: Perfect.
[01:04:11] Nicole Wheeler: Thank you, Gregor. Okay. With that, I'm going to turn the next presentation over to John for a discussion of the future of this working group. And, John, give me a second. I'll I'll I'll turn slides over to you or slide control over to
[01:04:33] Carsten Bormann: you. Okay. Thank you.
[01:04:47] John Harrison: Yeah. So this this is what happens every every time we're at ITF, we discuss this. But it feels like we have kind of reached a a point where we can't dodge the question anymore. So we've seen I think it's been a a a good meeting to tee all this up. So we've seen the status from Henk. You know, the the core materials are basically done. We've got a couple of, small extensions that that we wanna put in to sort of fill out the registries and the operational stuff, but pretty much, we've we've finished what we set out to do, but we also have this flurry of new work. We've got all the the hackathon results, and, I think the industry was a bit slower to mature than than than we expected when we started this working group, but, it's mature enough now that we've got all this other this other interest. So, I'm gonna put a poll up, in a second to to canvas these, these three options, but we could just stop. We could say SCITT is done, and all these other things are just use cases of skit the same way that, you know, lots of other working groups just have created a protocol, then other people use that protocol. That is absolutely an an option within our current charter. I'll just say the charter's complete. We can recharter, and I think, we've had this discussion often, but there are some new new faces in the room. So, just to to praising it a little bit, the Charter specifically, limits, the the SCITT things to software supply chain and and even a relatively narrow reading of software supply chain if you really wanna dig into it. But we consistently come up with other things like hardware supply chain with there are other thing here. Supply chain is also about safe handling, and so we we've had use cases in the past come up for things like personnel records or for movement of things that have software in them. Yeah. All of these are absolutely relevant. The question is whether we want to actually legislate them and standardize them in here or somewhere else. But all of those require a rechartering, Or we could have kind of a third way, which is because rechartering is heavy. We'll we'll do it if we absolutely need to, but it's it's a lot of work. And so the other thing we could consider doing is say, well, we keep the charter as it is. And thanks to the earlier speakers for kind of separating out their use cases into stuff that's already in charter and things that might stretch the definitions a little bit. So we could leave it as it is, but establish I don't wanna say registry. I I wrote those words, but that's wrong because I don't necessarily want an IANA official registry as such. But we can always have informative track stuff. We can always have a related work link on data tracker and so on where we put all these things in for conventions for how you create a a payload and conventions for how you do all of these other sort of multistep things that make it easy for people to find. So I think the the interesting question for me here is if we want to take all this extra work in, but we don't want to recharter, the an option would be to just make everything visible. Because I I really hate the fact, like, all all the questions always come up. Are you aware of this other work? Right? We've had that three times in this meeting. And redoing all of this stuff over and over and over again is bad. So I I definitely think it's good to collect all of these in one place. The the question really is how hard do we standardize them and what status do they have when they're when they're connected. So, hopefully, those are are are clear options, but there are two people in the queue, and I'd like to take the queue before I open the poll, just in case there are clarifications. So, Anton, go.
[01:09:07] Anton: Yes. Thank you. Just speaking, it's, someone bringing out, bringing one of those, news streams, evidence about agent actions, rather than software artifacts. Options option three is what new work, I think, actually is first. A registry entry for a payload format is a cheap blending spot, and it would let adjacent groups, agent proto, the audit discussions build against skip now. And option three doesn't really preclude the option two. Maybe the registry the registry entries can become evidence based for rechartered decision later. So I would suggest three now and let it inform option two. Thank you.
[01:09:56] John Harrison: Thank you. Carsten?
[01:10:00] Carsten Bormann: Yeah. I would put the same thing in in slightly different words. The answer is all three. So we do have to finish the code work in in flight, and there will be some maintenance going on starting from a rotary ports, but also filling in things like COSE_Sign in addition to COSE_Sign1 and and all this stuff. So I think we we we do have significant work that that this working group still needs to do. So the wind down is on the horizon, but it's not the thing that will happen next week. The second thing, I think there are several interesting new documents. And Skit is a new new way to do things. And it is pretty important, I think, to establish a number of activities that that show how to use it in specific environment. So Gregor, for instance, just just had an example for that, which unfortunately wasn't is quickly presented, but it it shows oh, the the signed believable, nonretractable statement is actually a useful thing to organize some process flows. And the third thing, I'm not entirely sure what that is. On the one hand, there's a wonderful way to register activities, and that's called Wikipedia. So I'm I'm sure the Wikipedia page for CBOW is is really useful. But the the no. I'm not really
[01:11:35] Hank Birkholz: sure. It is.
[01:11:38] Carsten Bormann: No. That that's not Wikipedia. That's Wiki. Gonna be great. Yeah. So I think we need to to find out what is it that we actually have to register in the sense of reserving a protocol name for something. And I think that's mainly media types, and that registry already exists. We may want to establish a convention so that in the the hundreds of media types, you find stuff that is interesting for for SCITT in in some way quicker than you may be to do do today. But I think we we already have a registry we can use, but maybe there are other places beyond media types where we have to to register something. And that would occur in the normal process of writing the standards that that you have to use this information. So this is not not a separate point here, but it does point out that some information really lives well in in Wiki pages, which is another alternative one option three. So I really have a hard time between the three points.
[01:12:54] Nicole Wheeler: Your your mic is a your John, your mic is a bit close to whatever activities you're doing. Taking over audio in the room, actually.
[01:13:04] Carsten Bormann: Yeah. So I think there is a reason the the instructions talk about talk about headsets because if you're using the original microphone for your laptop, we hear audio typing. We hear it when you touch your laptop and so on. It's not always nice noises being made. Yeah.
[01:13:23] John Harrison: Yeah. Thanks, Carsten. And for Carsten and for Ori's comment in the chat, as I said, I think I I mistyped when I used the word registry. I appreciate that's an official word in in ITF, which I didn't necessarily mean, but still, useful discussion.
[01:13:41] Ori: Hi. Boris Steele. So if we look at the current charter, the problem statement is broken into six sort of pieces. I think after, you know, working on SCITT, you know, stuff for for a while, one of the feelings that I have about it is we have created the potential for interoperability, but we've also created a lot of optionality where, you know, especially for some of the pieces within this charter, you you what you really hope for is for ecosystems to form around verifying particular data structures that are used to secure particular software artifacts. And you'd like to be able to see evidence that, you know, multiple issuers are participating and multiple verifiers are consuming statements about software and then producing more statements about software and becoming issuers themselves. And that sort of ecosystem flow, I think, is currently kind of trapped inside of each of these individual profiles. And it's possible it's doing a fantastic job inside of those profiles, for arbitrary media types with inside of those profile, you know, groupings. But, I'm sort of wondering, like, what is the interoperability piece, for for SCITT to to actually do in the next charter? Because I think right now, we can keep adding more, you know, profiles. That's easy. Actually, it's not making the interoperability problem better. We could keep adding media types, also not making the interoperability problem better. So I think, you know, it's it's possible, you know, media types are out there. Some are getting better. More people are using one of them. More people understand that one. Great. Like, that could be helpful. But I'm a bit concerned around, like, what interoperability work we're doing in Skit that's actually helping secure, you know, software supply chains. I'm sorry I don't have a clear answer for it, but, I think, you know, Amari's draft that he shared shows one example of that where I think, you know, there's some some hope there around multiple issuers, but that's in Charter, like, right now. So that's my thoughts.
[01:15:51] Nicole Wheeler: Thank you. Omar, you're next in queue.
[01:15:59] Omri: Hi. Omari at Microsoft. Just to answer Ori a bit and also to get something off my chest, I've been wanting to say for a while. I think calling these things profile may have been not quite right, and we should have called them algorithms because that's what they are. They're well, they're algorithms for the verifiable data structures.
[01:16:17] Nicole Wheeler: And
[01:16:18] Amari: it's true that it would have been better it'd be nicer for interrupt if everybody was using the same algorithm, but, you know, it's kinda the same as crypto. You have slightly different use cases, and we end up with slightly different algorithms. I don't think we should overstate the fragmentation that this causes because we've done a bunch of interrupt. We have verifiers that implement two, three profiles already two, three algorithms, sorry, all already. And I don't think that's such a huge deal because the envelope format is the same for everybody. You know, in the signed statement, the envelope format, and the receipt is also the same. And so there is quite a lot of commodity around claims around, like, the the the way this stuff works. So I I don't think the fragmentation as it is today is really quite that bad. And I think that if people implement two or three algorithms, you know, and their verifiers, it's not really much worse than if you have quasi statements and you implement a few different crypto algorithms to to verify or or to issue statements. If we start going towards profiles for payloads, then it's true that it's a bit different because there's more semantics. There's more fields. It's not just a sort of, you know, the signature verify at the end, which is a Boolean yes, no kind of situation. So I I would say that there these two things are slightly different in my mind. I hope that makes sense to everybody.
[01:17:33] Nicole Wheeler: Hank.
[01:17:42] Hank Birkholz: Hi. This is Hank. I just left my hands to on the chair. I hope that is fine. This is Seng. Yeah. So the the charter is a little bit the introduction of the charter promise is something that we will help people with software supply chains. And when I have the scrappy implemented and and I'm putting arbitrary response that we do not define, which is fine. So some CycloneDX. CycloneDX was a good example. There are others as as the explanation stuff. Into that, how do we help the community? How did we solve the initial statement and the charter? That's a question to the room. What benefit do we provide today that people have better, more accessible, more believable, and more, I don't know, transparent supply chain support, which is in the first paragraph of the charter. And if we have not done that yet, we have a lot of things to do, I think. And and then some of that has been presented today, and and I I I I think it's not out of scope. We do not define s bombs. Absolutely okay with that because that is something we've done wanna be mixed up and but we have to take them into account, And we have to kinda make them accessible in a way that when a company doesn't exist anymore and has a software, hardware composite, and there's an SBOM for it, we can still tell them this works for you if you have that platform because, hey, it is in our support solution. And I I think we haven't done that yet. And and and that feels to me like there's a lot of work. And and, of course, we do all these three items here, and and and registries are fine, and and and retard training is also fine. But but we have to complete the mission first, I think. This is
[01:20:11] Nicole Wheeler: So you pose a question that we're not done.
[01:20:14] Hank Birkholz: Yep. We haven't solved the initial paragraph.
[01:20:16] Nicole Wheeler: Agreed. What are your solutions or suggestions to the group of what those could possibly be that this group could contain in a chart?
[01:20:23] Hank Birkholz: Take into account existing s bombs, first of all. We do not define them, but we also ignore them. And I think we have to stop doing that because only because we are not defining them doesn't mean that we don't have to delve into the semantics of them and have to create infrastructure to make use of them to understand how which one are scalable for my system, which will help me with my problem. We are in support of software supply chains. That's our our initial charter goal. And I I think there's a lot of things to do there, and maybe the goal sections has to be updated in order to do that. Maybe some new milestones have to be added, and this is the thing that we could call a recharter. I think that would be very in support of that. But I think just having SCITT did not really help the initial stakeholders about the room. And and I think that is what we have to do now. We have to address the needs of those initial stakeholders. We're very happy about it and then left over time. I think that that's our our mission statement now or refactored mission statement, so to speak, from my point of view. And I don't know that I won't be negative about this. I think what we did was great because SCITT can be left on to any structure. It's it's really versatile. It's really helpful, but by itself, it doesn't have anything. So we now have to go into this software supply chain realm and go with some practical solution out there. The the the reference API is is is one very important step towards this goal. But we have to make it actionable, and and we we have to be about specific s bombs that are out there and then other bombs, AIM bombs, and such and that actionable. I think that is in scope currently of the SCITT charter in any case. We just haven't done it yet.
[01:22:27] John Harrison: Okay. So let's take David's point, and then I think I have enough to issue a poll that gets a yes or no answer. So, David?
[01:22:40] David Rogers: David Rogers. I didn't intend to speak, but we'd be agnostic to type of bomb in the file formats and so on because there's multiple work going on. I've just heard the new term AI bomb. There's tons of different AI bombs out there. I think it's just gonna end up in a complete mess. I'm kinda leaning more towards what Jess said earlier about pulling, you know, examples of things out there. But I think if you start to get down in the weeds of different file formats and so on for s bombs, think you're gonna be here a very long time.
[01:23:23] Nicole Wheeler: One response, and then we'll do the poll.
[01:23:30] Hank Birkholz: Yeah. Yeah. We we we can't be too incomplete about this. It's very clear. But we also have a soft problem. There must be some middle ground. Right? You can't just say, hey. This is this thing, and you may use it or not, and then nobody's using it. And the why the way they did it do it in the first place. So we have to help that community with a versatile set of sometimes nonsense, sometimes brilliant things. I don't know. But we have to we can't really make that an opaque blob and assume that it's just working.
[01:24:06] John Harrison: Okay. Yeah. So great. Thank you, everybody, and thank you, David, for teeing up my summary, I think. So so the the summary and where where we're at administratively is, also, as as everybody said in in this session, we've got a really good structure, I think, now for verifying that some cohesive lump of bites existed and was asserted by a specific person at a specific point in time, which is already great in many systems, especially in closed loop systems. And the the question and the renewed energy in the group is all around going one level higher, defining what we've always explicitly avoided, which is what is that artifact. Right? And so I think I'm gonna issue a poll. There we go. I've started the poll. So while I'm talking, you can you can all start voting on the tool. The question really is, yeah, standards, we absolutely David's right. We absolutely don't wanna start redefining what an SBOM is, and I think we'd even be in a bit of trouble if we try to track all of the various changes to how the the various different SBOM formats are working other than just sort of referring to them. So the the real question is that I posed in the poll here is do we think the SCITT working group is the right place to talk about and define and document conventions for using the SCITT building blocks to solve specific problems with a little bit more specificity and perhaps not opaque or or clarifying the the payload? Or do we think that those should belong in other working groups who are explicitly working on those areas of of stuff. And I appreciate there's a middle ground where if the stuff is software supply chain, then it's probably here. But that's the the intent of the poll. So do we think it should be all defined in this room, or do we think this room should support other rooms in defining their own use?
[01:26:23] Carsten Bormann: And the answer, of course, is yes. So there there there is no choice between staying on the left side of the spectrum or going all the way to the right side. So I think what we want to do here is create further reusable building blocks that can be used in specific applications. But we will always be talking to to application specialists that that that have the tools at hand for solving that particular application. So the application I use as a benchmark here normally is talking about cheese firmness. There's international scale for describing the feminist of cheese, and we should be able to to interrupt with that in some way, but we are not going to bring loads of cheese to these meetings. Who are you? I want my cheese.
[01:27:37] John Harrison: Okay. So we've got 90 out of 45 people. So roughly half half turnout is not bad. We'll give thirty more seconds just to collect votes. So I think
[01:28:04] Carsten Bormann: I guess based
[01:28:05] Steven: on what Carson said, I don't know if this question is it's a little bit ambiguous, what Carson was saying against this question. So I don't know if people are saying yes or no based on the interpretation of the question and what was
[01:28:21] Carsten Bormann: just coming. I agree.
[01:28:26] John Harrison: So I
[01:28:26] Steven: propose that we clarify the question and vote again.
[01:28:43] John Harrison: I'm I'm tempted to issue a poll for did you understand the question? So I appreciate what you're saying, but I think the if if if it was an overwhelming no, I think what what you just said might have might have had that impact. It's it's actually a a a majority yes, which suggests that that hasn't hasn't swayed the poll too badly. What I would say so we're not really supposed to speak during the poll because it's it's considered canvassing in one way or another, but I think we're I think we're okay there. I'm gonna stop there. So where we land with all of these comments and the outcome of the vote and the hard boundaries of our charter and Ori pointing out that maybe our problem statement is the problem and all of that is we can just carry on and accept these things in. And the the the sort of constraint that then happens is we have to split out these use cases the way that has been quite well presented in the presentations, today already, and not include certain aspects that aren't strictly software supply chain. But the benefit of that is, well, we avoid a lot of, administrative work, and we do establish some interoperability conventions at that application layer, which several people have have also pointed out is is is is missing. So, yeah, I guess the the as always in the ITF, if there is energy to create work and that work is useful, then we should do it and it will be consumed.
[01:30:29] Carsten Bormann: I would hate it if we left this room thinking that we just have voted for cheese fondness. So I think it's it's really important to keep in mind that what we are doing what we're aiming to do is is create building blocks that specific application domains can use in the toolkit to solve the application problem.
[01:30:55] John Harrison: Yeah. And so, specifically, define it. I think the thing the thing that is different and the thing that I believe we have just voted for is going into the payloads. Right? That's that's the the interesting part of this is that we're now defining what is it that is coming out of that verification, which has previously not been a thing that we did, but it's certainly layered. And we can layer on top of the opaque payloads of the architecture and then be more helpful at the at the application layer. So I don't think that's quite cheese firmness. I don't know if it's cheese smelliness or something something related, but it is a a material change and a material thing to work on that I think is quite clear. So where we'll go as well just to closing comment, and then I'll I'll hand it back to the room to to close out if there's anything else that needs doing. But what we'll need to do in that case is on the list on probably Monday morning, you'll find a number of messages on the email list with official calls for, can you please review these drafts we did the calls earlier? And if you did volunteer, we'll call you out by name on the list reminding you that you volunteered. And shortly when the hackathon work is written up and the drafts are available, we'll also need to be issuing adoption or otherwise tiger team or design team type work to to develop that. So I think we do have some concrete outcomes on this, and then the firmness of of those outcomes will develop when the drafts are actually published and available for review.
[01:32:56] Nicole Wheeler: Right. We are at time, actually. We're over time. I've locked the queue. If you have any other questions or comments to make, please put them in chat. You will see updates to this working group on Monday, as John has mentioned. And, of course, speakers are around if there's any follow-up questions afterwards. Thank you so much. Thank you, speakers, keeping on time. Much appreciated. Enjoy your Friday.