Internet Engineering Task Force Interim Meetings, 16 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-SCITT-20220616-1600

Description

SCITT meeting session at IETF
2022/06/16 1600

https://datatracker.ietf.org/meeting//proceedings/

A

We have badonged uh the top of the hour. We will um give people just a few more moments to come in.

A

While we are waiting.

B

Do we have the um someone taking meeting minutes.

A

Yes, we do, who is it let's see here, and that person is I'm from.

C

Doing up uh hannes.

B

A

A

Though, with our meeting tool with our note-taking tool, brian doesn't have to be alone. If you'd like to help him with the minutes, it's all done very nicely online. So you can, you can join in the fun.

B

Yeah, I hope um folks know where to find the meeting minute tour.

B

It's actually on the top of the bar. If you look around.

D

Hi everybody um just for a few people who might not know how the data tracker, also the meat, echo and vitaco works, so the hand at the top left under your name at the screen is is if you want to uh speak out, then you enqueue.

D

If someone else presses the hand before you I'm pressing the hand right now and I'm in queue now, so if somebody else presses his hand, um they get in queue, and so exactly so now the chairs know uh what what's the order and you can still talk by not being first, so you can talk over each other. It's like a real room, so this is meet echo101.

B

Some people asked um there's also a chat panel, uh which is next to the participants list. On the left hand side, uh so you can, if it doesn't open for you, um just click on it. That should be, should do the job. You should see that and you can send some messages to the chat window.

A

All right shall we um go ahead and get started yeah so welcome everyone to the skit buff. um This is a a non-working group forming buff and the first thing I would like to draw your attention to is the notewell statement. Now I am aware that there are a number of people who are new participants to the itf processes.

A

To you, I want to say, on behalf of myself and my co-chair hannah's, a special welcome um welcome to the ietf.

A

uh So the way we start things off uh at most of our meetings and prac, pretty much all of our meetings is by you know letting you know about our policies um and uh like any standards or organization. We've got a lot of them, um so uh I'm not gonna read this out. I know at some standards organizations they read out their policies in the beginning, but this is the notewell statement. It will be in the minutes.

A

Please take a moment because what it basically says is if you're going to make contributions to this meeting, then you're agreeing to uh certain rules um and both in terms of ipr in terms of code of conduct, which I'm sure won't be a problem here uh and uh in terms of understanding our processes.

A

um Now um we have uh a couple of ways that we go forward uh in in these things, a couple of traditions of in the first tradition when we present the agenda is to agenda bash.

A

So, um first of all, we can congratulate ourselves that, having gotten through the first agenda item, so we can't bash that one off the agenda. Everybody has gotten to see the note. Well, the agenda that we have planned for the skip off is as follows: we're going to take a few moments just to give a brief introduction to the ietf processes that that you might encounter.

A

Then yogesh is going to spend some time on a problem statement and kate is going to talk about an initial use case. Then hank is going to give us some view as to what we think the the scope of standardization is and then there's going to be some discussion.

A

Now, if you scroll along the the participant list, you will see people with various colored dots, and I want to just point out a couple of things. The the first is that there is an area director who uh arranged this buff he's online, that's roman!

A

There are a couple of members of the internet architecture board I think uh on on. They have the red dots, um roman, has a yellow dot for the iesg, and then people who are working group chairs have blue dots and you'll see an occasional. I don't know if that's purple, pink whatever you want to call it. Those are members of the internet, research steering group. This is the irtf side of the house. Those are the researchy people, and so occasionally you might hear interjections from from these. These leaders of the community.

A

Now, uh once we've gone through discussion, we'll spend five minutes of wrap up, and then this is the time when you get to change the agenda.

A

Now the rules about anything that we do in in our discussions is we tend to do things by rough consensus, so that doesn't mean everybody has to agree, but it certainly means that most people have to agree.

A

Does anyone anybody want to bash the agenda.

C

A

Hannah's, do you want to uh add any comments on the agenda here, or should I just press.

C

A

Yeah all right moving on so I've created just one slide um and I'm going to talk up a little bit about some text. That's not there too, so you know like any standards process. There's you know a lot of things you do to create a standard, um but it all starts with a good idea and the good part about that is you're, probably past that part now. The other thing that it's really important to have throughout this process is a community of interest.

A

Look at this. There are 52 people on this call, there's a good chance you're beyond that as well, but we're going to test that over time.

A

um So this is a non-working group forming both it's pretty much a discussion, we'll talk about some desired outcomes in a little bit, um but we're not going to start this. uh The the process of forming a working group which is sort of your first step into creating a standard at the ietf until the next buff and exactly when that happens is still a discussion and it's up to the internet engineering uh steering group to decide whether that will happen in philadelphia later or not at all.

A

That's up to them, but they take their cue from the community and they'll talk a little bit about what they'll want in that process. I see roman has his hand up roman. You probably want to say a few words.

E

Probably only uh only a few words yeah, I just wanted to kind of jump and say ellie, I mean you're you're, laying us out great uh elliott, hotties gotta. Thank you for agreeing to share this. uh Just as a procedural thing. You've already mentioned that this is a non-working group forming buff, but just to bring everyone up to date. The isg was discussing today at the telechat. What would be the upcoming boss for philadelphia and ietf 14.? So if it helps structure the discussions we have tentatively approved this buff also to convene in philadelphia.

E

So if again, if we want to stretch figure out how to stretch the conversation between two meetings, that's really what we have here. uh If it turns out that we end up with something that we can't manage out of this meeting, uh and I gotta I don't wanna prejudice or kind of presuppose how it's gonna go. But you know if it doesn't go well, we can potentially pull it back, but we can plan for being able to convene in philadelphia.

A

Thank you, roman, um so uh you could probably plan, therefore, to get on to the to get into the next birds of a feather session, where we do have that working group forming buff and that takes a slightly different structure than what we have today.

A

There are specific questions that will need to be answered in the working group forming buff and we can get into that as we plan for that, once above has had the iesg and the community will discuss and debate the charter of a working group and then once the working group is formed there, some chairs are chosen, everybody joins a mailing list and discussion happens. Drafts are written, uh some are adopted into the working group process and then those go through the approval process.

A

How long this takes largely depends uh it's very dependent on the topic and the level of interest. If there's not much level of interest, it might take forever. If there's a lot of interest, things tend to get pushed along, but it also depends on the complexity of what's being standardized and that and and the shared vision of what people have so what's very important in the second buff will be to develop that shared vision in terms of a work plan that can be uh executed in some.

A

You know relatively fixed period of time. uh I won't get into any more process at this point, because I think people are really dying to get into the the meat of this buff other than to ask hannes. Would you like to add any comments here.

B

Oh, I think it's um I think you laid it out quite well, and I think we should jump in straight into the into the meat of it.

A

Okay, before I do that, are there any questions at this point.

A

All right, very good, everybody's really excited to get into the meat of it, which isn't me talking, but it will be uh yogesh talking so before I do that. Let me just stop sharing for a moment, um let's see here and I will bring up your slides yogesh. I.

F

Am sorry I.

A

Had difficulty um with the the the share, what what what what slides are in there so just give me just a moment to go. Pull this up.

G

And taking a chance to do a brief mic check yeah, it works awesome.

B

And as we go through, um write down your questions or note them somewhere um because we try to get through them, we have allocated uh roughly an hour uh for those and then we have a big chunk of discussion time. uh So I I hope uh you guys have come along with a lot of questions. You've seen the slides being posted to the mailing list already, so some of you may have had a chance to take a look at them and think about some easy or difficult questions for the speakers and for some discussion points.

A

Right now, I'd like to invite yogesh to uh guide us through the first part of this discussion, which is the problem statement.

B

Yoga is just saying next slide when you're ready to advance elliot. Wasn't there one slide before that talked about like what um I.

H

Think that's what I want: yeah yeah, yeah, okay, okay, so great um at the outset. I would like to welcome all of you all of you here who have taken out their valuable time and come here to participate on a healthy discussion about supply chain security, which is a major challenge faced by industry today. So I really uh appreciate your time and we look forward to a great discussion uh today.

H

So here is a brief uh kind of uh agenda.

H

uh Basically, here is the um core of the intent of this non-working group forming both that we really want this outcome, that people review this the material and in generate that generates explicit interest in solving the illustrated problem statements, and we work towards a goal of standardizing this in the itf yeah.

H

So I will be covering the first section of the slides which is problem statement. So we hear what what the aim is to clearly define what the problems or what the challenges we face in the industry today and then we'll go to the subsequent sections. So next slide, please so to to introduce the problem. uh We we present here uh notional supply chain workflow.

H

What I'm trying to present here is that this is a very simplified model, because the real world industry is much more complex, but to just to kind of focus on simple thing. First, uh here we show a simple supply chain: workflow, where a producer a is involved in producing us a component. It could be anything we can for the moment. We can assume it as a software component or something, and that has been designed, then test build, built, tested and produced.

H

It creates a product, a which is then used or acts as a basis for creation of two more products which forms as the basis and used in two more products, which is produced by two pro producers b and c, and it is eventually manifest itself as product b and product c, which is consumed by consumers b and c.

H

So that's how simplified and we will see on the next slide, how that can manifest itself if we add some kind of a workflow of supply, chain, security, transparency and trust into picture where we briefly want to show here that the producer a which is producing a design or whatever deliverable it produces some data about it, which then gets signed and a notary validates it who identifies the producer who identifies the claims about it and notarizes it, and let it allows the producer to introduce that the claims into a store which then can be taken forward and utilized by the producer of items b and c, and subsequently the same process is followed and is creates items with consumer b and c here.

H

What we are trying to emphasize is that there is a open transparency in the framework, and things are designed can be presented in a way that that is much more auditable, much more accountable and in open fashion. Next slide, please, and subsequently there is a mechanism of multiple auditors at multiple level who can check the data store to check for the claims, verify the claims and then reintroduce something about the auditing report back into the data store to say that, yes, I want so, and so they they have audited this. It all looks good.

H

It all complies to the standards which they were looking for next slide. Please.

H

So what challenges we face in the industry today, so looking from different actors perspective- let's say I'm a producer of a product, so I don't know how to uh gather compliance evidence of um how. How can I produce evidence about what I'm producing?

H

How do I share it in a uniform fashion across the industry so that people can inspect it and because there are so many different formats, there is no standard way where to put it, how to put it and what to put it in a homogeneous manner, because there are so many different clouds and so many different formats, so it's extremely complicated and consuming complicated and confusing next slide, please, on a similar scale, thinking from consumer's perspective, he is utilizing the end product. He is ultimately the user of the end product. How does he verify that?

H

Okay, whatever I am, is receiving today as a product which is a combination of multiple sub products? How do they meet compliance? Is it safe to utilize safe to use? Is it secure? Does it meet my quality bar quality requirements? Is it sustainable those kind of things? How do I check it? Because there is no standard way to promote this, this kind of quality checks in the consumer's environment.

H

There is no standard way to check the compliance of these things and subsequently once assumed that the product is utilized and after say a certain amount of time. I want to check that. Has it developed any vulnerability?

H

Do I run what malevo scan or anything? I don't have a standard mechanism to run that and introduce that back into the system to say that, yes, I have done this check. It all still looks good, so I don't have an subsequent verification techniques to the already shipped products yeah next slide. Please.

H

Sorry, one yeah auditor, so as a subsequent, it is not just uh the uh consumer and the producer and the consumer in the ecosystem that needs to act in a certain fashion. There are auditors as well, which do check about the compliance to make sure that um the everything is in place. The evidence is generated in the right format. The claims are validated and the claims can be validated in the way it should be validated.

H

So the whole process of auditing is not in a standard fashion, so because there are so many different solutions and so many different ways of doing things, so there is no standard way to audit the claims as well.

H

Next slide. Please.

H

So here, basically what we have come up with a with a definition on terms which we would be extensively using it in the subsequent slot of slides. So this this slide introduces these terms, and I will try my best to explain what this term means and how they are related to the supply chain scenario which we have a problem to address.

H

So the claim is basically any any producer produces an artifact or a product. A claim is something which which describes that who has produced it. What are the ingredients, what it comprises of what quality assurances or what? What testing has been done? Anything related to the which describes the describes the product in a way that can be verified is a claim generated by the issuer, which then can be introduced in a system where there is a registration policy where not anybody can submit these kind of claims. Only authorized actors whose.

F

H

Can be established are allowed to submit these claims into a system, and there is a notary in here which checks that the identity which is submitted is genuinely the correct identity. I know the person I can validate that before letting it go into a system known as transparent registry, which is the next one in the slide. So basically, what is transparent registry?

H

The transparent registry is effectively a store for a data structure which is consistent. It is append only so it can. You can only add things. You cannot delete it.

H

It's a cryptographically, verifiable record of things which, which you can subsequently query and make sure that they are all present and you can verify those, because, once you enter your claims into the transparent registry, you get a receipt which is effectively a verifiable proof that so, and so issuer has introduced so and so claim, and the receipt will have all the documentation which will be returned from the store or the registry, so that, subsequently, that offline verification of registry can be done next slide. Please.

H

So this is just a sample example. We have tried to explain how the notary would kind of notarize the stuff before it gets into the registry. Is it can mention that it has audited this type of document s bomb document it has? um Who has done this introduction and how? I can add additional notes about what he wants to add about the identity or specifically about the claim it can add what security standards it has followed, or whatever additional metadata it wants to introduce, can be done next slide. Please.

H

So this slide basically what what is the motivation behind doing this? Well, we understand that we want to do things in a transparent manner so that, basically we can audit it any in a closed ecosystem designated actors can verify that, but that doesn't necessarily mean that anyone cannot any authorized supply chain. Actor may not uh can will not act in a rogue manner or it will not generate false games.

H

We admit- or we acknowledge, that that is very much a possibility, but doing this stuff in the way we are trying to trying to stay here makes them accountable that if anybody detects the such kind of a claim they can be attributed to, and they cannot contradict later that they were not the ones who did that, so they cannot even contest the uh roles played by auditors who have audited it or the notary who has not raised it. So this makes it more secure in a way that the transparency adds more security to it.

H

It doesn't stop it from bad actors acting it, but once it is detected, it can be quickly. Action can be taken and remedial.

F

H

Can be made in a very rapid manner next slide. Please.

H

So here are the challenges and pinpoints we face in the industry today is that we don't have a consistent methodology to identify and attribute the persons who are issuing the or producing the claims or person who who is producing the supply chain entities. Neither.

H

We have a consistent method to notarize the stuff or counter sign to say that, yes, we have seen, who is the actor, what it is producing and the linkage between the actor who is producing the stuff and the actual product which it is producing and because the pain is aggravated, because there are multiple data sharing platforms and different protocols for various artifacts and claims.

H

Next slide, please.

H

So what we are proposing is a draft problem statement. This is not a final statement, so to speak. This is open for discussion and we are.

H

It is that's why it is called as draft feel free to uh once we have a discussion floor open, feel free to debate on this and try to improve it, because we believe that it is a collective community effort where we would land up in the defining the right problem statement, and once we have the right problem statement will lead us to finding the right solution, so the challenges according to us.

H

The challenge is that, because of supply chain digitalization and the vast increase in the complexity, the size and the scale of the supply chain, the traditional methods of normal auditing or securing the supply chain is no longer applicable.

H

This is primarily the problem now, once you increase the scale the problem is there are. There is no um no proper way to uh attribute this or to formulate the supply chain data and generate claims to associate to that data, and then there is no standards for defining how the data stores and how how we can align the data stores and how we can make this transparency work. There is no defined standard, so this aggravates the problem.

H

So what we are trying to propose here is simple set of building blocks that could guarantee long-term accountability and interoperability of the software components, so that when the supply chain crosses different regions and boundaries and different organizations, there is a consistent method to verify everything about the supply chain, so that the community is greatly benefited next slide piece.

H

I think um I have covered the problem statement. um I would lead it back to the organizer so that uh how he wants to frame that. Thank you elliot.

A

uh Thank you yogesh now, before kate presents, we have a another tradition um at the at the itf, which is, if you, if you need to ask a clarifying question about what yogis presented. In other words, if you were confused about something he said or if you just didn't understand something he said now is a good time just to ask. If it's a clarifying question not for discussion, just a clarifying question: does anybody have any of those.

A

Actually yogesh, you did a great job apparently so congratulations on that and now um kate uh kate. If you will take the floor, uh you will then present the the supply chain use case. Okay,.

I

Sounds good next slide and please, okay, so software supply chain is what we're all focusing on these days and as yogesh has pointed out, it is very complex. It's dynamic. There are places that are transparent. There are places that are obscure, but we've all got to work it all together, so um open source. Certainly a large component of this and the rate of change of open source is.

I

uh I wish I could give you a good stat, but um I'm gonna say it changes very frequently uh to the extent that certain projects um like the linux kernel have something like you know: nine changes per hour going into them and those are bug fixes and things like that. So we've got a fair amount of velocity and, quite frankly, when his patches come in as releases come out as dependencies are tracked, all of this is happening so quickly to do it. Accurate tracking of it is no longer possible manually.

I

um We need to basically get to the stage uh that we are moving it forward in an effective fashion.

I

However, um as is being pointed out, the um having some degree of transparency to the contributors and the composition is one of the areas that we need to figure out how to build up the trust from and there's all these different participants players and you might go by. Oh, I know this company. I trust this company.

I

Oh, I don't trust this company we've that sort of intuitive knowledge is effectively still manual and we need to be able to put the right checks and balances in place so that we can look at risk in a more systemic fashion.

I

Be it you know, components coming from third parties, be it components coming from open source.

I

All of these, you know have different judgments associated with it and having a same language where we can assess these is a missing piece, um so we've got various. um You know, standards for conveying the software materials format. You know like spdx, which is there today, but how people share these documents is one of these open questions that you know that community isn't trying to define we're looking for things to emerge outside of the spdx scope.

I

So next slide. Please.

A

uh Kate, before you advance to the next slide, if you feel comfortable doing so, um this goes to all other speakers when you're taking the microphone. If you don't mind, turning on your camera so that we can see you that would be appreciated, it's not required, but if you, if you'd like to do so, it is appreciated. Thank you.

I

um Just a second then.

I

Okay, you got me now.

I

What is it coming through clearly and yeah.

J

Okay, we can see you now: okay, thanks.

I

Okay, so um the team has been working on this problem and skid has been doing some market analysis and um just to give a bit of a lie of the land, we're hearing more and more um from various governments and industries that they are going to be mandating having sufferable materials.

I

That's a key building block for the transparency, but, as is indicated, we need more than just these building blocks.

I

We need to have a way of linking them all together and looking at things through time, and so um this various s-bomb formats have ways of you know tying themselves back to the software that they are describing, but how you can sort of trust, the aggregate that the person is presented you know has created it, and that goes back to the identity and do you trust who has made it so having standard ways of capturing identity and capturing how we can move this forward um is obviously going to be the challenge.

I

We need to figure out how we can sort and because there are so many people creating products, so much churn on the products fixes for vulnerabilities.

I

These are where we're going um and again there's a drying need for being able to do this at a scale in a machine reproducible way next slide.

I

So some of the requirements that have been discussed by the others- and I completely agree with I'm- not going to take credit for this. For some of this, um this is pretty much uh things that I completely agree with, but the statements made by producers must be identifiable, they have to be authentic and you know you'll be able to track them and know when someone says oops. No, I made a mistake here. Here's the update this is all has to be.

I

We need a way of being able to do this and there's been multiple attempts to try to get to this in various projects up till now, but we just don't have, I think, the language that's missing, that we can all sort of rally around and build the tooling around um auditing the provenance.

I

You could take an s-bomb today and you can go and match it up to the software, and you can you can make you know, there's certain things you can do with the hashes and so forth to verify, but the um city is who's had it and how it has flown through parts of the supply chain, maybe opaque um in certain cases.

I

Deliberately or they may be transparent when they're going back up to open source so but there's no visibility and the claims um and the proof that's going forward with these today and so getting these things together um and then effectively again. So we can operationalize and take the scale of our supply chains. um Is the challenge next slide.

I

This slide um is something that came out of the ntias bomb effort or parts of it did anyhow and have been augmented since then, but the initial diagram was looking at the software life cycle and, as you can see, various parts of artifacts come into play at various parts of the cycle. There are certain types of material that will come in during your producing when, as you're, basically sourcing and planning for something and doing requirements, you may want to look at what source s-bombs are or if you have binary analysis.

I

You may want to look at that. um What binary and you know what binaries have you? You don't have the full. You don't have the transparency you really want. So you try to do third party binary analysis or someone just gives you a binary for my product and that's all you've got that would all come in um potentially with the software as people go in and look at developing and building and then as they're, developing and building people are going to take and look at hey. I've done these test results.

I

Sometimes you may want to keep that, and you know track that forward or hey.

I

I use this build chain build tool chain for some of the safety work, uh you're going to need to have your full traceability all the way through this stuff and hooking these things in and having it linked in a way that people can find and then do the right level of analysis after the fact is going to be um key for having effectively a built s bomb, which is the output of a build for a product and ideally that will track trace its way, all the way back from beyond the components back to the sources in white, so that we can, because that's where the vulnerabilities are vulnerabilities happen in sources.

I

um But you know these are where areas that the supply chains will be growing into right now, if we can get to components, we're doing well, um but putting infrastructure in place so that we can catch what's going on from the builds and then, quite frankly, as you deploy um as products into your system, recording and tracking. Exactly what configurations you've used will also tell you whether or not you're vulnerable, because um all the vulnerability, you know certain vulnerabilities.

I

If you're, not config, you know deploying certain functionality, that's part of your config you're, not vulnerable, and so you don't need to remediate. If there's a patch, I don't know if there's a vulnerability in a patch, that's there. um So you know you don't want to be remediating all the time. You only want to do it and you absolutely need to, and so we need that level of transparency as to how all the stuff is pulled together.

I

It flows so that we can do the right level of analysis, and you know minimize the false positives and just patch what we really need to do. But you know, um as michael's saying critical infrastructure is going to need this type of information. Anything that has a safety critical function is going to need the full build flow of information and the build tool, chains and the environment where things are built and then, quite frankly, what is actually being expected to be deployed and configured on a running system.

I

So one of the things I want to highlight out of this slide is the term s-bomb can be used for all of these phases and all these different deliverables and there's gonna be different content in them too. You know um it's not just a set of components and relationship between components at the top level of what's there we're also potentially looking at okay, here's how I've deployed this component, so there's a lot of work to be done on the s-bomb side to expand into the space.

I

However, how we can trust this s-bomb and the chain of custody and what's happened over time- is not being necessarily tackled there. If you go to the next slide, um you know to illustrate and to go back to yogesh's points.

I

You've got a product x, the zero version comes out, have an s bond published with it, and then some user is going to take it or, quite frankly, multiple users are going to be taking it potentially deploying it in different ways and recording that in their systems, and then we hear oh there's a vulnerability, that's happening at some point, um and then you know someone from either a supplier or you know, comes up with a patch makes a patch available. Well, there might be an s bomb coming out with that patch to say: hey.

I

This applies to this product and it might apply to 20 other products too, because it depends where, in the source that vulnerability was and has that source been used in different places. So we've got, you know a very multi-dimensions on you know, inputs coming in and things can be reused in different places and on the output and being able to have that clarity that okay, yes, I'm going to one specific supplier has released this product.

I

You know x with that patch in it and there's a new s bomb out, and then you know some user wants to go in and update to it. We're going to need to be able to track that type of stuff and as a user you're going to want to know whether or not you've applied the latest and how what you've just applied potentially relates to what was there before and you may need to have.

I

You know, be able to have to roll back at some point in time, because there's some other issue and auditors are going to need to potentially come in. So all of these dimensions are in the software side as they are in. um You know, in the physical side, as our aries just is pointing out and so how we can get ourselves to that stage where um we have a framework around working with s-bombs as well as working with deliverables of software and then letting people audit and apply appropriate risk assessment.

I

I think, is a challenge going forward. So next slide, I think, is pretty much restating the problem yeah. So um in the discussion, we can probably further talk about it, but, as you can sort of see getting these types of building blocks articulated like identity of individuals. What are the elements we want to try to share like s-bombs, and you know, products and so forth, and having that language that we're also working towards, I think, can help us with this part of the problem.

I

Next slide there we go.

I

Hey any clarifying questions.

A

Thank you yeah clarifying questions. Please just clarifying questions.

A

Oh, my goodness, we have like professional presenters here there you guys were super clear. Oh john, go ahead! Please.

A

John gator, hello,.

F

Yeah sorry, there was a pause while I had to authorize my microphone. um So thanks kate, uh just on this one here and some some of you know know us. So we deal specifically with legally meaningful evidence trails of state over time. um So do you have a good handle? Does the community have a good handle of what legally meaningful means in terms of sort of regulatory submissive, or just it's good enough to pass a sniff test so I'll put it into a lawsuit, or is that also undefined.

I

Well, you do know that I am coming from the spdx community and our with the legal team. That's very active about a lot of these types of hp's, which is um uh so yes um taking it to the standards of proof for risk and various policy engines. um A lot of companies will not make their policy engines visible, um but I think we will be seeing having a common language for these engines to consume will help with the authentication over time. And yes, it does need to be at this stage like right now.

I

um Spdx has you know: hashes, okay, expect to see not all elements, so we have some degree of verification that, yes, this s-bom element here compo corresponds to something physical, however, the overall s-bomb um and how we can make sure that's signed and it has been tampered with and we can get these supply chain issues yeah. We need to get to that stage and that's why I think this is a abuse, very useful discussion.

F

Thank you yeah, so cabo cabo, just put in the chat forensically ready that answers my question so yeah. Thank you.

D

Yeah. Okay, so then my answer.

A

Is um continue, sorry, uh just one comment on questions if it when you take the microphone just any time, you take the microphone. If you don't mind showing your face, it's not required, but if you don't mind showing your face, please do uh it hank. Is this a clarifying question for for for kate? No.

D

Actually, uh someone put my uh his words off my whatever it's been said so so legally meaningful is a scary term and and forensic.

F

D

Is a is a nice term and so so in support and that's it.

A

So I was gonna say: let's be careful to you, know, clarifying questions. Thank you all right. Any other clarifying questions for kate.

A

Right then, thank you, kate. um I was surprised it took that long for somebody to come up with that question about illegally meaningful, uh but there you have it hank. I think you are now up to talk about the proposed standardization scope.

D

Very carefully clicking buttons. It just crashed on me when I was clicking too fast, so yeah, um so I am hank um trying to uh scope this down a little bit. So what we heard at the first presentation from yogesh is that um there's a lot of supply chains out there.

D

They share a common problem and that does not really um scope well, because it's all the things right, all the supply chains is a little bit too much, and then we um had kate present to us the user scenario, the use case they want to focus on.

D

That's that's well understood and I think highly important because it might be even more complex than a few of the other supply chains and that's that's the software life cycle problem so um and I'm gonna challenge, of course, but it's a problem actually, so so that's there and now I will present three things that sorry six things that we will um talk about about scoping here, so we can vote them out. We can vote them in.

D

We can also talk about them and understand what they mean and I'm going to try to uh to convey some meaning here. For these six things and one of the things is um when you are working in supply chains and are a supply chain entity, you want to talk about your artifact, the thing you're supplying. Actually so your supply chain, issuer and- and that requires some common method of to identify and not all of these are traditional identity documents.

D

Maybe so um it's very important, it's verifiable and you can't take that back what you said and the really important thing here that has to be valid for a long time for auditability, so there's the the phrasing here indefinite period.

D

That means more than two years.

D

I think that's a very important thing to to to focus on so so that what what I think we should propose to be in scope, and then there is this thing, you're saying so now: you're the issuer you're the entity, and you want to state something about your supply chain, artifact again in this case and they're just kate, they don't look very well there's a software life cycle. This is a statement about your software, for example. I think it's a very good use case.

D

Now. Everybody knows that supply chains are not fixed in difficult times, especially so what you do is to have some interoperability on these statements and this supply chain claims. We call them here claims and now is an overloaded term, but just stick with me here for right moment. So these are surprising claims you want to be them uh interoperable, so homogeneous is key and, and also you want them somehow to be in support to be to to check them out about the authenticity you just signed them, but they're just the claims now.

D

No, no, no, you want to make it transparent that they happen actually, and you want to uh be simple for the things you want to apply to the iot simple things you want to apply to large scaling things, so that requires a certain standardization scope on the claim set itself and it requires a burden on the. um This is called supply chain. Claim.

D

Storage here is the third item, some burden on the store of these claims and- and I think, there's uh there are some qualities to these stores that should be in scope of standardization, so that you cannot take something back. That you said you can add something that says, I'm not of that opinion anymore, but you should not be able to take something back. It should be again like more than two years long term accountable, for which you should see that this is a literally um not only.

D

I made this statement, but some entities on the supply chain really want to say no, no, no, I was aware of the thing you said they want to be able to have a proof that they understood and read that statement. So this is what we gave you. A statement made and statements read from the store here on this slide and next slide. Please the other three items so this comes. This boils down to some kind of receipt.

D

You know when you interact with the central unit um um you want to have uh probably want to have. I have to mute this. uh I want sorry. I want to have a validated um piece of data. That tells me actually I trusted that transparency service. I trusted that store that entity that retains these statements and I've written to that.

D

I want to prove to you I've written to that, and also I want to prove to you that I read from that and and for the convenience of this was a slide back somehow for the convenience of conveyance. I'm still talking to slide 26.

D

Oh sorry, no! No! I'm I'm I'm sorry! Okay! So there was a glitch on my screen. It's probably it's just just a mid echo! I'm sorry! So we are 12 25 now so um so I want to have a um some validated reproof, even offline. If I'm not connected to the internet, that I have read something from the story and have that vote written something to the store.

D

That's that's relative, rather than to to people who who really work with supply chains, especially software, because sometimes software goes into critical spaces, and sometimes software goes to a lot of things.

D

And then you can't get back to the store and inquire in order log right, if you're in a small item, you just believe what have been said. So the the the trust in the store is important, not especially the trust into the statement. If you are smarter, if you're bigger you go, come back to the store and then check the order, trade and just somehow become- and this is the fifth item become a auditor you can- you can really trace back all the claims being made have been made over time over years.

D

Effectively and- and I think that's also something we want to have in scope here for for standardization- so all of these things sound very um mighty, very powerful, but I think you can boil them down to very specific things that are just counter signing things, but where this is a solution thing, I'm not going there. um The the very important thing that uh you have a choice here and there's a sixth item.

D

I think we want to enable the choice for you to decide whom I'm presenting to the opportunity to make their claims, whom I'm presiding the opportunity to presenting to the um the the choice of of checking and reading the claims, and that is under a certain control. We are saying public notary here for this role, but what I think what we want to do here is to enable everybody to decide for themselves who will access which data and that we want to make it very easy to check the validity of the data.

D

Has it been stated? Has it been read? Is it there and then it can be global? It can be super confidential and small. The statement itself can be confidential.

D

It can be transparent to the world that is up to the implementer. The building block, I think we are focusing on here- is the the the choice of system. You want to build with this, and and again it can be that the publicity, so the transparency of your of your thing is, is under, and this is to be scalable here. So I think that's a sixth item and I think all of these six things are in scope, I'm looking at the timing, and we are good with time.

D

So, let's go with the things that- um and this is all going to be bashed. This is all up for discussion. That is try the next type. Please that's that's the next slide and that's that's the thing that we think is probably out of scope, because we don't again we are already trimming down generic supply chain problems to a very specific problem.

D

That is the s permanent software lifecycle world and still we want to have something more out of scopia, and one of the things that should be out of scope is how the exact component of the storage looks like how a query language for that storage looks like and how actual protocol looks like to get something from these entities that can do the read and write proofs right.

D

So that's our protocol, but I think we have to start with the core and I think a lot of people agree with that, and that is that is one of the out of scope decisions here. I think that we want to present to you as a proposal and then, of course, you know when you think about who shall access what and when and where that's policy? That's compliance, it's okay right, but we can't deal with this on step zero.

D

I think we really have to provide the basis here so yeah at some point, probably maybe, but not for now, that's out of scope.

D

We think as a proposal and, of course, and that's that's- we have to really underline this. We do not want to reinvent any wheel here, so we want to you, make use of technology already being approved and even not only proposed or standardized by the atf. So we want to do this to be applied to all the things and most of the things today. If you count them thoroughly are tiny, so maybe it's cozy to be something here.

D

Maybe it's cozy that might help us here and then we want to inherit lessons learned from the certificate. Transparency things that's vital. We are not doing transparency of certificates here, but there are lessons learned from that that should apply here. We think, but we don't want to redo the certificate transparency that has been done and then, of course, you know if I build a system that basically, when you get a receipt phone, says trust me that's more than endorsements, so we have a working group for that. That's rats, the remote association procedures, remote is brilliant.

D

Can literally give you evidence about the actual thing the entity did. It did everything it should do and nothing else with it right. So so that's technology being developed in the iit. If you're not reinventing that, we want to pull that up, but at some point, maybe not initially, so that is out of scope, of course, because that has been defined.

D

And then, when you talk about trust on the reds level, you could add trust on a consensus level right. There are something that says as good experiences and bad experiences. I think the consensus protocols, but if you replicate that same thing over and over again, if you have the resources to scale that horizontally, um there's the the of course the idea arises that you might want the consensus protocol to check on that this. This. This is node out of line you everything is doing the same way, but you so.

D

Why should we trust you so so that is interesting, of course, but initially not in scope, maybe, and then uh sk just said s, bombs are tackled hard and intense. Simply today a lot of places, and I think we don't want to pull that into here. So the payload, the statement I was talking about about statements about artifacts right, the artifact itself, that is, you described like the last bomb. That's out of scope, we want to use all the s-bomb stuff. We want to do all the metadata stuff about the s-bombs.

D

We want to do all the provenance and the connectiveness about them, and while it works, that's nice, I think people are already solving this. We're not want to interfere with that. um What we want to do is add this layer of interoperability for all the participants in a concise and meaningful manner. That applies to a lot of small things into very critical, big things, and so uh so I think the format of of this uh various bills of materials uh might not be in scope right now.

D

We might look at this again helping with the encoding helping with the protocols later on, but this is like far in the future, so when the people that are really expert in this uh have set it on something that is uh viable and they endorse, so that that's the uh three slides I wanted to present today- and uh I hope that makes a little bit uh more sense. Now, it's all all tied together and- and uh I think the next slide is going already into discussion- isn't it.

D

Yeah it is, and if this is the least oh so now, let's let's go for the next slide. It's fine because the next slide actually all right, wait. Wait! Okay,.

A

Okay, um the same question for you um for uh the the related for everybody who's on the uh in the meeting do. Does anybody have any clarifying questions for hank.

A

uh Okay, we do.

C

A

All right uh so uh ice, uh let's, let's see um I see hannes has taken the floor. Hannes, do you want to say something? First, as a chair you get to do that.

B

No, no! No! No. I think we should uh jump straight to questions okay, because.

A

B

Next part is also the discussion slide, so we might nicely transition over.

A

Okay, um so k: uh let's start with the clarifying questions and we will get into that discussion.

A

Kate williams, you should uh un unmute yourself and, if you'd, like turn on your mic, turn on your camera,.

D

Which is uh top left of the screen? There are a lot of strikes through images.

K

Yeah I I unclicked the wrong button, but I know I I think I've got them all it's great to see everyone here. Thank you um yeah. So my question is on the clarifying question is on the scope uh slide and I asked this in the chat. There are some things that are listed as out of scope here that I think are very important for interoperability across this the supply chain, which was identified in the in the problem statement.

K

um So I'm I'm wondering- um and I don't know if we can answer this right now, but if there's a way, I do think it's important to say there are certain things that we'll start with and certain things that we'll get to later. So I think of it as potentially a more of a road map kind of question. um So it might just be more of a clarifying question from from me about you know: how do other groups do this in in the ietf?

K

My preference would be to say some of these things are in fact in scope, but but uh in a future time frame.

D

um Yeah that sorry make sure to.

F

D

Okay um yeah, so the uh the goal here is to agree on the the core problem and, as you said, I think, the right term roadmap.

D

So there are additional problems, of course, but we have to solve the first problem. So first they take small steps. Yeah- and this is this- is basically just to to uh um fence off all the scope creep, because all of this is interesting. Of course, all this people want to do, but in order to be successful here in the iatf, you really have to scoop down to the call and then, when you're doing this, there's create. This will be the next four weeks.

D

If you get the chance to to create some shorter initial charter takes about this. That would be this out of scope. Phrase statement here will be for the first charter iteration and if you're successful in fulfilling the duty that we promised to the isg here with each other, that we produce something that solves addresses core problems, then I think we get the benefit of doubt. Okay, you might.

I

D

Able to reel in the remote attestation you might to reel in the other things right, um you don't reinvent, really you're just using them and and so that becomes a road map along the way. Maybe the chairs have to add to that.

A

No, I I would be, I would say, there's no firm answer. It's up to the group to decide, but what will help things along, I think, will be as you're defining sort of the the architectural building blocks. um What you can pull in will become more obvious, and uh that will help you scope uh so that you don't redo other people's work or, if you do, you know why you're doing other people's work.

B

Roman put um said it quite nicely on the on the chat, so I think that's also a good thing. You mean.

D

The rs it's an art.

B

Yeah, um but he also says uh it can um this question: I don't think this question can be answered in the abstract and I I also agree with that. This. It is a little bit tricky, but I I think in general, like the scoping, helps a little bit in um informing others like what what's going to be done.

B

First, what's the main uh focus um and what I it's a group not planning to work on, um I think those uh is useful information for those who come in and participate right so that they are not at the wrong place and think.

K

K

Yeah, thank you.

A

Okay, thank you kay, um ori welcome. What's.

G

Your ques, what's your clarifying question, so uh it's essentially on the same bullet point uh I feel like storage, query and retrieval are.

G

I can see very strongly the applicability for the storage layer, but I worry about interoperability without the ability to speak to some of the query or retrieval parts so like, while the internal storage mechanisms, I could see that being great to keep as a as a black box. I do see some potential harm and there not being some sort of externally defined interface for getting access to.

G

You know statements in a particular format, so I wanted to just ask: could you maybe separate them out a little bit and kind of how you're thinking about it or just take another swing at it?.

D

Yeah, okay, can I take another swing at this, so the uh itf is reluctant and not very, very suited to due to the api level, but what the itf can really do is talk about. The messages conveyed, so the conveyance type might not be uh fully specified, but the conveyance format uh on this specific level for a query, retrieval and statement- might have some prescription to it.

D

I'm not sure how far and how deep again we are not trying to uh just disrupt the force with the s-bomb faults right, but um but but on on some. Maybe everybody is there's a thin metadata level that we want to have uh on on the storage screen. Retrieval. That's that's up to the discussion. I think for chartering, um if you're worried about that, I think uh we have to uh um fence the the the the point of concern a little bit more and make sure what what's the actual problem we are solving.

D

If we would go there, um I'm really reluctant, but I can feel that yeah. If you have no guidance at all, then it's also not very useful right. So, okay, maybe the middle ground here- is the part that has to take next. uh It would be the next steps to find it out.

A

Okay, thank you hank and thanks all the presenters, thanks to all the presenters for introducing the topic. um uh This next part of the discussion um is not presented right. It's up to you um to discuss uh to to here are some questions. These are what I would call starter questions right is the itf the right place to do this work, and I saw something in the chat um from at least one participant who said well what here's?

A

What here is not done, and um I just wanted to make sure I'm giving the appropriate uh credit- that's ned smith, who said that, and I I I think, that's a good question.

B

um Very quickly, jumping in based on what I said. Obviously lots of questions on on on the chat that uh we could discuss, but I just see one from ori in response to to what hank said um and there's unfortunately like when he said um the idf is not good at specifying apis and that's true for the old definition of apis right, not the restful http apis.

B

So so you need to be careful um here, so something, for example, a protocol that sort of http based thing that talks from some client to some server asking for something and the response comes back. um I I I don't see why that would not be in scope of uh you.

D

You're correct, I I I feel I feel strongly uh corrected and you're you're right. Thank you.

B

But uh jumping back to you elliot sorry uh interrupted you on net's uh comment.

A

No, it's fine. I just wanted to make sure that uh if the point wasn't to try and get ned's question answered necessarily, but simply to say, this is everybody's opportunity to ask not only ask questions but to state their views about these. These are good questions that we could look at, um please feel free uh to to jump in. um I hope that new participants um feel really comfortable about speaking with you. You know you you you're more than welcome to to ask questions presenters who have presented. Please feel free to ask your own questions.

A

You may have your own questions in this, um so with that, um I think we'll just start with the cue hanus and go down. Definitely my clients are open: um okay, michael uh michael perrick, and- and please, if I.

L

A

Your name, please tell me.

L

Okay, yeah, no, you got it right, so thanks so much um and I'm sorry, apologies keeping uh um video off just because of rural internet issues, um but I just wanted to get a bit of clarification um around the api side and I think the last thing I heard helped me quite a bit which was that things like defining a restful api seems like it might be in scope, because I think if we look at validating and testing interoperability between different implementers of the standards, that has been a very helpful thing in lots of areas and and so, if that's not in scope, I would have some strong concerns on that, uh at least having you know, a very basic.

L

Yes, I send this message. I expect- and you know in this format- and I expect this and it's happening over http, etc. Or you know something similar uh is it so is? Is there a little bit of clarification that could be offered around like a restful api from a test, suite standpoint, etc?.

J

I can take that harness if you want go ahead, so you're correct, you have to remember what we're trying to lead here is what scope we think needs to be solved in in a working group. We're we're perfectly acceptable expanding it out, but you know we don't want to turn this into a massive massive amount of boiling ocean, we're really trying to target some things that we think are lacking that are stopping us from building this.

J

If the consensus is that we kind of need some standard restful, api for storage and retrieval- and we want to extend to that- then that's totally within the purview of defining what the problem statement statement is here- and I think that's you know we're looking for feedback here is how much appetite there is and how far to go.

J

Did that answer your question.

L

Chad as well, but I mean I would definitely be interested in helping to specify a restful api on that and you know in commit tests, etc.

L

It's something we've been doing a lot of lately on our team and uh it has been extremely helpful to be able to be like yep, all three or five or ten of us are all actually speaking to this standard in a testable way, which also helps with industry confidence right, we're looking at adoption issues right, and so when I, when I think about customers, we deal with out in the wild um that ability to say. Oh, yes, and if you want to plug into this. This is how we can do this in this demonstrable fashion.

L

So if that api is not defined, what ends up tends? What tends to end up happening is there's no common ground to meet on and you wind up with all sorts of weird stuff and people saying they're doing something in relation to a spec and then in reality, they're not, and that um that's just a danger. I've seen in other standards type stuff, and I wanted to avoid that here so.

A

Thanks to add a comment there, please, um like the pretty much the highest ideal we have in this organization, is interoperability, um and I think what you're pointing out is that you know at the at the 10 000 foot level, it's very difficult to perceive where the interoperability will be, and so, as we begin to zoom in in the next buff, and and as we begin to read the drafts right, the the obviously the the really the big test will be. Can people build interoperable uh implementations?

A

That's like the numero uno goal of of the the standardization process at the ietf. In my opinion, um uh roy roy did you want to say more. I apologize for for stepping over there.

J

I know it was perfectly fine. The the other half of this is one of the things you did put in scope is standardization on what the first level auditability against an electronic equivalent of notary is. If we can't automate it and there's a status of the apis, then we're in a real world of hurt right. So there's a level of how far we standardize surface area and how much we can automate and test and I'm willing to take to change where that bar is and discuss with people.

J

What all has to be solved here, but yeah there's definitely going to have to be some standardization on on ways to test this thing and how to to to prove it. Otherwise, it's going to be a huge amount of manual uh legal discovery and all the rest of it, and that will never work.

A

Thank you. Roy um christopher wood, with a bouncing baby new rfc under your belt.

M

uh Yeah thanks, um I have. I have three questions um in no particular order, um the first of which is uh kind of a question about the assumption that the architecture makes um uh or or the claims that it makes not to that's a bad. That's a bad choice of work because claim is overloaded in this particular document, um but it focuses pretty heavily on the this append.

M

Only data structure, that's used by the transparency service, as it's called um to actually like store claims, and um I don't know if receipts are also stored on that particular data structure as well.

M

I I'm wondering if this is actually a necessary requirement for all known use cases of this type of technology or if it's really something that's more like a nice to have feature for um uh various applications, and I asked that, because um uh anecdotally and historically running these types of data structures is not simple, um especially at scale like certificate.

M

Transparency turns out to be quite challenging um to operate a log, uh and if these are going to be used a lot more than you know, certificate transparency logs it you know calls into question whether or not you can actually deploy this type of technology.

M

um So I'd like to better understand um why this is being sort of proposed as a like an essential requirement, as opposed to sort of an optional piece of the architecture.

M

Second, question is, on the the I guess, the type of identity, that's sort of fundamental to the design as well.

M

um uh I think the draft of the architecture draft says that the ids or decentralized identities are going to be like sort of the the interoperable type of identity for everything um they will be the identity that, um like the producers, I don't know if that's the right term, but the people who like make claims they're going to sign with some gid associated key material, ledgers and transparency services, will also have some sort of did associated with it and I think, like historically icf protocols and systems sort of like punt on this, like how identity is handled in systems like tls, for example, sort of just puns and says you know like there exists a certificate first in some pki, you figure out like what pki is relevant.

M

We haven't used the web ppi for a lot of things, um but that's just a that's just how it turned out to be in practice so mandating um a particular type of identity seems kind of problematic. Here um I'm wondering if that is also something that we could punt on, um because this is already a quite complicated thing.

M

I mean it's quite large um and that folds into my third question, which is uh really on the uh I guess, the more practical side of things like who is like interested in like actually building out the stuff testing it and experimenting with it, um because it is pretty significant in scope and scale um and uh something like this to succeed through the standardization process. Obviously, these people to, like you, know, write code and and test it out. um So I'm wondering if those people are here and can speak up.

M

um That seems quite relevant to not the working group, not the boss. uh Now, because we're not forming a working group, but that seems relevant too.

I

M

I

Can I chime in on that one um there's actually a bit about uh three definite efforts that I'm already aware of independently start have been happening. There's one that started about three or four years ago, called sports out of wind river, which was logging things onto a ledger that was aiming towards doing some of this type of information with using an envelope.

I

um The d-bomb effort has been trying to work after going after this as well, and then there's another group of people who are looking at controls and risks and how to work with this in this flame. That's overlapping into this space. We've got a lot of people looking at this space, but we don't have the standardization of the terms and metrics, and so I think, coming up with here's, how all these tools need to work and interoperate. I don't think there'll be one necessary solution. I think there'll be multiple solutions.

I

I think it's going to be key to build up the vocabulary of art, of of concepts and building blocks, that we can. All these tools can use, because it won't be just one. I think.

M

um If I could reply to that real quick, so I yeah I'm aware of these other efforts. But what I'm asking is like, um I guess more direct like: are they here or are they interested in doing this like? Are they willing to move away from what they're doing to this thing, I'm getting a thumbs up from someone which is great, um so I hope I'm just hoping. That would be the answer but like if we don't go. Do this thing in a corner and no one cares about it. That's not really useful.

N

Yeah, I'd love to respond to all of your points uh with at least my perspective. uh I think they're excellent by the way, so I'm gonna I'll do it in reverse order, if that's all right uh in terms of interest, so uh my name is silvan klepsch, I'm at microsoft. Research and microsoft is deeply invested in this, so and in research.

N

This is something that we've been keenly interested in for years now, and we've been working in the space and publishing in this space, but this is giving us an opportunity to actually reify that work to actually work with the the community and and the world at large to make this happen. So we are actually investing significant full-time head count into exactly this into spinning up these systems into doing research into new ways even to service these systems.

N

So I'm in the confidential computing group, I'm highly biased in in favor of uh hardware trusted execution environments and the kinds of interesting guarantees you can get out of that. But that's just my bias. I think something that that kate said just now about multiple solutions is really really key. We want to make sure- and it ties into into something that folks were were saying in the chat as well about who runs this service.

N

Ideally, many providers run this service in an interoperable way and they don't necessarily all run the same software in order to provide it. Certainly, microsoft will have an implementation that will open source and make it available to everybody and allow anybody to use. We don't want any kind of ip getting in the way there, but if folks have other approaches, I think that's even better.

N

This is too big a space for microsoft to address it alone, then, going to your did point, which I think is really important. Identity is fundamental to what we need to do here, because we need an idea that claims originate with some identity, but we don't want to go off and solve the identity problem. That's a huge space.

N

To my mind, using did is giving us a level of indirection to identity systems. We're not saying you must use some existing did method, we're saying when you define an identity method, define a did and a resolver that lets us figure out who you're talking about and please do introduce new did methods. It's a it's a very open standard. I know ori steele's on the call it's an it's an area where you can really innovate and provide new solutions, and it allows this kind of work to be flexible as the identity provider.

N

uh If you think that there's a better way to get that level of indirection awesome, let's talk, I would. I would, I think any other approach to indirection over identity is also on the table.

N

I think going to the log question here. I'm afraid I have incredibly strong biases. My apologies, I think, having the ledger is only part of the log problem and the other part of the like the log problem is having independently verifiable receipts, because what we don't want is to introduce online checking of a ledger as part of people's deployment and checking and security policies.

N

So you need to be able to say that the ledger is used for creation of claims only never for validation or distribution, so that those independently verifiable receipts can be packaged, sent you know put in in container registries, sent via ftp put on a dvd, because apparently it's the 90s again whatever it is that people need to do to distribute this stuff and that we're never online for that, and in order to do that, we need to be able to generate good cryptographic.

N

Proof such that we have not just tamper evidence but tamper proof where the holder of the receipt has uh of the of the counter signature of the the independently verified receipt has evidence against the ledger.

N

The ledger has evidence against everybody, and everybody can can support their position if you think that there's another way to do that to achieve independently verifiable receipts and that kind of tamper-proof guarantee again I'm super interested, I don't want, I don't mean to say that there's only one possible implementation, but as an as a property having that tamper-proof profit, property and independent receipts, I think, is critical.

N

Sorry for taking so long.

M

No, that that was great, um uh exactly sort of the clarifying uh answers I was looking for um on the um the last one, the keeping things offline and being able to uh ensure that, like things, weren't tampered with, um if there were, you know deployments of this that were willing to compromise.

M

uh You know the complexity of running this log for an online check like would that be a reasonable, like instance, of skit or like like? This is a trade-off right like, I think, that's a great question.

A

And and just um if, if I may, uh while it is a great question and all chris's questions are great, I'm going to ask chris uh that there are other people who may also have some great questions after this. So uh but but please do uh if, if.

N

If you'd like to still then answer that one great I'll try and give a short answer this time- my apologies, uh my honest answer is: while I don't think right now that that would be a good implementation.

N

uh Please come convince me that it would be uh if we can, if we can get the kind of security properties out of such an implementation that we're looking for and and we can make sure that that stays interoperable with with implementations that do provide those guarantees. Well, let's talk about it. Let's figure out how it works.

N

My bias right now is ah you can't do that, but come come. Show me I'm wrong. I would love that.

A

All right, thank you chris thank you. Sylvan um ned smith has been waiting patiently, ned.

A

We can see you, we can't hear you.

C

Can you hear me now.

A

Yes, we can thank you. Okay,.

C

So um thanks for taking my question, I'm looking at the scope slide mostly and trying to understand really what it's saying in terms of what ietf needs to do, that that can't be done somewhere else uh and in the in the case of the the auditor it mentions the word workflow, uh but it doesn't mention. You know things like defining restful interfaces, so I'm trying to understand better. What's what's?

C

Is there something more implied by you know workflow as opposed to restful uh and then the other, the other one talks about defining processes and procedures for for a notary.

C

So I'm not I'm not immediately seeing what's the interoperability problem that needs to be solved. It seems like this is focusing on an internal process for a notary.

C

So not getting. You know the context here why that's even relevant, and additionally, it was noted on the chat that that a notary is just essentially providing support for the identity of the participants. But if we're using something like this did already provides mechanisms, for you know believability of the identity of the entity. So is there something that did doesn't do that?

C

We need to do sort of in the along the lines of notary, or we just uh it does know to refer to something else that we haven't haven't defined it very well uh and then, and then, of course, just the receipt itself uh seems like you know, a bunch of groups are already defining the receipt, and, if they can't agree is ietf is that the purpose that ietf wants to be involved is to help them agree on something, or is there something specific that isn't defined yet in the context of defining a receipt that that applies to an interoperability, some kind of interaction.

A

Is there some who would like to take a swing at that question? Is there? Is there somebody who would like to just jump in on that? On that question? From the the presenter side of things.

H

I can take the receipt when I.

J

I was supposed to.

H

J

I was going to suggest already take a swing at this, but I can take it if he doesn't want to.

G

I might need a quick refresher and the chat is very distracting and awesome. Okay, well.

J

Let me answer the.

G

J

To what I understand so that the thing that's missing here is uh we've: we've got plenty of options of what to to move for uh in the ietf for identity right now we have a lot of infrastructure built on ca issues, certificates and we're opening it up to a discussion of. Should we pick a subset or something new in the supply chain, and if so, what it? What's the opinion? Should it be ssh keys? Should it be did web?

J

Should it be dandy, a new new one, because we keeping it open it and saying hey we're going to support 100 things. It's not going to work too. Well, we kind of need a vision of. Do we want to move off of x509 right. The second half of this is today we don't have a way to know what your historical identity uh certificates are right. You can say: hey, that's a did document. Well, perfect.

J

Okay, that's one way to solve the question, but is that the way we want to solve it for the secure supply chain? And how do I find that document is part of this discussion?

J

The reason we use the notary here is: it is historical that that I'm going to use ori here that ori's signature at a five-year-old is still ori when he's 35. um and when he's 100, it's still ori's signature, and how do we represent that uh in a supply chain? Point of view, because we have products that live 10 15 years um and that's why we're opening up a discussion to say: hey what should we pick out of the plethora that have been opened up as the way to solve this?

J

um Did that answer your question completely, or did I miss if.

C

I were to translate that I would say the the digital equivalent of that is. uh Do I maintain control of my key throughout the the my lifetime as a as a person?

C

So it sounds like you were saying we needed to do some work to try and maintain you keep track of key life cycles and ownership and something of that nature, but maybe I'm reading in.

J

Fair, the other concept here is: is it's an entity potentially not necessarily a person like it's the companies or the the science project in github that that is, is generating the signing on the package versus a specific person. If you look at uh organizational based mail for for asia, it's the the security guard at the corner. It's not the that roy williams that actually making claims or you sent email to and it's those sorts of things we need to work through.

J

um The other aspect of this and rory has screwed me many times in this is: do we want to use the id document uh as a way to to track, revocation or compromise, or is that all based on claims, or is there a combination of endorsements, negative endorsements on a product and the entries in the dig document? That's where it becomes a little bit fuzzy for me as to what the industry wants and what is there a better way to solve this problem.

C

I know they did. Groups and w3c are. Are you know you know trying to address the the problem of? How does a? How does a user maintain control of their identity throughout you know their lifetime and and establish? You know that their identity is trustworthy without using some centralized authority.

C

uh If the goal is to essentially build on top of dids, it would be helpful to know what's wrong with dids such that we know what problem we're solving.

J

Well, a picking dizz is is the decision and the second one here is: if and I'll continue using orion in this case, because he's cut his camera on if or he passes away and his his electronic collateral disappears.

J

We rely on human notaries for contracts to say that ori purchased this, and so, where does it transition from your responsibility to maintain your list to a fiduciary capability to say: hey, here's all the things that already signed over his lifetime.

A

J

A

This is a good question uh for discussions um uh in terms of what needs to be covered. um I'm gonna. Actually I was gonna ask a question, but I think there's still a lot of conversation that people want to have. So I'm going to take myself out of the queue just for the moment and say: roman go ahead.

E

Hi everyone uh just to be clear: I'm asking this question as no hat so for those kind of new to the process, not as kind of the ad, but just as a participant in the group. So I'm kind of intrigued by this this level of specificity, we're talking about in terms of verticals but at the same time really trying to talk about abstract solutions, and you know some of what I heard as well was like. Well, we want lots of options uh and this is applicable to s-bomb and kind of other things.

E

So my first question is: are we actually expecting an end-to-end solution that everyone adopts? Are we going to be providing a number of building blocks that someone else is going to have to take and assemble for their particular verticals and then a related question? If again, we're back to saying we're solving supply chain versus having some adjective in front of kind of supply chain? Do we have a sense for where we're making the demarcation about the guarantees we're providing so like, for example, a reaction of what's in scope?

E

Was you know, I read the first one which is about the supply chain issue and we're using the word verifiable. So there's a lot of ways to take that, for example, I can say verifiable in just the crypto sense, which is you know it's a certificate but like even in the certificate space. You know there's a lot of nuance, which is: is it like acme style, where you know, let's encrypt like I can ask for one and I get it. Who cares?

E

Who I really am or are we gonna, do high fidelity verification like show me your articles of incorporation and that's what vera verifies kind of, so I'm wondering where we're trying to land in the level of kind of abstraction and ultimate ability to have an end-to-end system.

J

I guess I'll take that one. um When we started down this this journey, we tried to keep it thinking about supply chains in general and and say hey. This is a systemic problem, but you know that's why the slide deck talks.

O

J

Producers and consumers in a generic sort of way, because we do manufacturing as well as software. um The issue here is: if we take it too far down that road, and we were looking for common elements that we're missing that we can't represent. Today, we said hey.

J

This is going to get too complicated too fast, so we kind of distilled it down to if we wanted to solve the software supply chain issue, which is a huge focus at the moment, other verticals may be able to pick up some of our work and go forward um onto broader stuff, but their primary focus.

J

Given the impetus by governments to go and mandate, things is kind of pushing us to work on solutions to here that in microsoft for years, that have had a solution for code signing that is proprietary to windows, authenticate and we're going hey that doesn't scale well and we'd rather open this up and work through a better solution and the us government, with their executive order, have also pushed the issue saying hey. We want you to hit here and here, and we realize that this needs some better solutions.

J

The trying to do it with certificates that expire and roll over and keep track of this is is super super tough without some of the military blocks that we have that you expect today, when you purchase the house, you, the human neuter that comes to your house and signs off and records in the book. Well, the state can come back where the the province can come back and say. Hey show me, prove me that ori signed this and we don't have that sort of functionality that we we see.

J

We kind of need for these longer term things. Your your your question is correct, is: could it be used for other things? Yes, but right now we're saying hey: let's focus on software supply chain issues.

N

So one of the things I want to add to that roman, if it's all right the two pieces that I think particularly I want to talk about, is you mentioned solutions versus building blocks and, to my mind, of course, at microsoft, we're going to build a full solution and, of course, we're going to open source it and offer to everyone.

N

That's not an ietf effort, that's an open source effort and we want to make sure that what we're doing is working for interoperability such that there are standards for this, such that anyone can go and build something we can interoperate with our solution. If we're the only thing out there- hey, maybe that's a nice open source project, but it's not uh it's not really a proper standardization effort, and I think the other one that you mentioned, that is close to my heart is verifiability.

N

I think that saying that we provide cryptographic. Verifiability is a great start. I think.

N

Moving on to, I know, I keep harping on it, but independently verifiable receipts such that you have actual offline trust is, is another huge part of this, but another huge part of this, to my mind, is in fact tied back into the rats, work and attestation where, particularly in software, when we can have hardware attestations of what actually happened, that isn't a human claim and use and take those hardware attestations, make those transparent and make those part of your supply chain ledger with independently verifiable receipts.

N

Now we're starting to build fully automated solutions with humans out of the loop, and I think that, to my mind, that's that's where we want to be headed. We want to allow for all of the intermediate steps along the way. We don't want to say you have to do all these things straight away, but being being mindful that this effort needs to incorporate that kind of long view of hardware attestation where verifiability is not just a statement I think is. It is an important part of the work. To my mind,.

E

Sure I appreciate that clarification. I think. As part of this, uh you know effort putting the hat on is laying out what those assumptions are for for kind of you got to be.

E

This high to kind of ride is going to be what we need to make sure we have a success criteria on the back end to say we got to where, where we needed to go, and that's going to entirely depend on the community of parties that want the interoperability as they come to the ietf, because I think you know to channel a little bit of what uh what chris said to editorialize uh is uh is just kind of some degree, it'll be what the people that come to the ietf who ultimately want, and we shouldn't jump to being kind of something generic above and beyond, without having the validation uh that we know we're building something for for that community.

E

B

Do you want to go next.

G

Yeah, I I was sort of- um I guess, cue- to respond to sort of part of that trade-off. Between the you know, generic applicability of standards um versus some of these vertical specific use cases like for software for physical supply chain.

G

I think at the core what at the heart of this there's this common sort of problem around this transparency service and the representations of that service- and uh you know my background's in cyber security- so apologies if this is taking us too far deep into the cryptography, but one of the things that's exciting about certificate transparency is that it it uses these merkle proofs.

G

It gives us some new standard interfaces, but the domain is very focused and we would love to be able to build on those same capabilities but because of the way certificate transparency was designed. It's not exactly. uh You know easy to directly port that over. So I think that certificate transparency as an rfc does it's an excellent sort of example of you know when you make that trade-off, you can get something.

G

That's narrowly focused and solves a problem really well, but some of those common building blocks can can actually work for a lot of other cases and maybe there's a bit overfitting in that particular use case like, for example, with posey and cozy. Those are common building blocks that you can use to build very many things and I think certificate transparency is on the edge of giving us those tools that we need.

B

Thanks thanks um anthony.

O

Antoine, yes, so spend that. uh Still on that topic um of, uh I think there is uh we're almost getting into a chartering question and uh the the core of the issue is: how can we technically qualify the property that we provide as a standard, and I think steven mentioned his aspiration for the property of the end-to-end solution, but we also agreed that we need to narrow down the scope, because we cannot standardize a full end-to-end solution.

O

We have to standardize the precise mechanism that are required for interoperability and for allowing people to be to build their own solution.

O

So currently, if you look at the current skits drafts, the decision is to focus on the technical property of transparency, which is this idea that you have offline verifiability and um that you, you prevent the ability for equivocation um by recording everything in immutable logs and relying on the cryptographic verifiability of the log. So currently, this is exactly the technical scope that is defined in the current architecture.

O

Draft and part of the question that will appear for the for the shuttering buff is whether this is acceptable scope or whether this needs to be expanded or possibly reduced.

O

So one direction that steven was mentioning for expanding the scope, for instance, is trying to also bring at the station in the technical scope of the security guarantee that will require interoperability, for that would probably be a controversial decision, but that that's the kind of topic that would have to be addressed for the short-term part.

B

Good elliot you prepared some questions, so we can run them.

A

uh um I do have some questions, but I have one of my own first, um which is uh just as a no hats. um My one question is uh relating to the people who are using this, the these uh logs or ledgers um that we we mentioned that there might be a way to uh limit access limit, read access. I take it to to these logs.

A

So one question about scope is: do we need to define the the identity forms or a means to communicate those identity forms in order to handle the authorization uh for accessing logs and um keep in mind right that that products tend to travel from manufacturers to you know through rather lengthy supply chains? This is a whole supply chain thing. So uh do we need some sort of of of a standard for? Does the standard need to to include that access control? uh You know particularly identity forms for that. Thank.

O

You yeah, I think that's uh that's a great question, maybe I, uh as the author of the architecture draft we said like we can probably try to answer what we think about this.

O

So um in terms of the transparency, property is based on the idea of something that is publicly verifiable, but this has to be a little bit refined uh to understand what it means, because verifiability uh is possible without having a full view of all of the contents of the ledger.

O

So when you have a merkle path or a merkel proof it's possible to verify that proof, even if the hash of some of the nodes in the merkle tree are completely opaque to you.

O

So, based on this observation, it's possible to maintain verifiability and even offline verifiability of receipts without having to give full access to ledger to everyone.

O

And then the consequence of this is access. Control is a mechanism that is can be implemented by the transparency service in terms of providing access to the ledger and there there are two possible approach that we can take. So one approach is to say that in in the standards we only define the apis that skid compliance service should expose, and in that case, if we want to add access control to some of these apis, that would have to be specified in the draft.

O

Another approach is to decide that we don't even try to solve that problem at all and that we essentially said that the public distribution of the ledger is up to the operators of the transparency service and they can decide to distribute the ledger in any way they want uh like just putting it on a public website or distributing it over ipfs or in the ethereum blockchain if they want or whatever else so then, access control becomes completely out of scope and it's completely up to each operator of the transparency service to decide how to implement access control.

O

So that would also be a possible approach.

H

I think I would like to add to anton is that it could be a very transparency service policy decision and whether to bring that policy standard discussion, how we want to operate the transparency service as a fully um whether how much degree of access control you want to enter into that.

B

But let's try not to go too deep into the technical details, because we are still quite early in the process uh if that's okay, uh elliot prepared some questions that are really high level and and we try to settle on the on the issue on some of the more basic issues like uh uh elliot. Do you have a question about the uh question for the group about the uh whether they understood the problem statement.

A

Yes, and so uh thank you, hannes and thank you, I'm gonna ask hank and cedric just to hold your comments for now, um one of the success uh factors from off whether there's a shared vision around the problem statement. Now in this lovely neat echo tool, we have a poll mechanism, I'm going to start a poll, I'm going to ask two questions at the beginning, which is how many people think that the problem statement is clear and then I will ask the reverse question, which is how many people don't think the problem statement is clear.

A

So, let's start with the first question, and you will see that the poll will have popped up in just a moment and you'll see ray's hand and do not raise hand. So all right. Do people see the poll.

D

A

Yeah looks good we're seeing a lot of people raising their hands, saying that they.

A

They they do think. The problem statement is clear um they're. This is good.

G

A

Everybody it looks like no, no, I won't say everybody's voted, but a good percentage of people who voted okay uh last call uh I'm going to close the poll in just a moment.

A

Okay- and here we have the answer to that now, I'm going to ask the opposite question.

B

I think next time you only need one. We just have the other people who disagree to not raise to him.

A

You know, generally speaking, uh yeah that's a fair point, but I'll just ask it in in. In any case, since I said I would.

A

Sometimes people aren't participating and they they wake up and all.

D

Right, I'm in the second quarter.

C

A

So um I'm going to give it just another moment.

A

Okay, first of all, uh I think that this I I don't know the area director should be very pleased here, um because if you just look at the results there, there are a lot of people who like who, like the problem statement, that is a big big win right there. Now I have a different question: let's stop sharing um my uh uh my presentation for a moment. um The the different question is a classic sort of um working group forming boffy question, uh which we, let's see here. Why wouldn't let me type here.

B

uh There we go actually I'm trying to get to.

E

I see a bunch of people and well a few people in the queue do they want to comment before we jump to the next question.

A

Hank, did you want to comment yeah yeah, so I.

D

Tried actually, roman, I tried to address one of your comments. I have to scroll way back in the time machine here to understand what your question was. I think it was something of rats.

A

Is the question about? Is your comments about the poll that we just did? No, okay from.

D

From roman about the rat's applicability and I'm scrolling up so hard because the chat is live, okay hold it.

A

Nice comment for just a few moments: hank we'll come back christopher is it about? Is it about the poll.

M

Yeah um I uh so um I I I voted. uh I I put my hand down and thinking that it was a clear because I wasn't sure how to answer it in particular, like I think the problem description um was clear, um but it's not clear to me that it is the right problem to be solving. It seems like sort of what roman was saying or kind of getting at that it's a bit too generic in many ways what the problem statement is, um and so I'm I'm and and elliot when you interpreted the results.

M

You said something like it seems like everyone likes the problem statement, which was not the question that was being asked, the question was: is it clear? um That's a fair point, and, and and I would I would like to understand that people think it's the right problem to be solving.

A

I think the way I would phrase it if you don't mind is: is this the pro? Is this a problem that people uh uh wish to work on.

D

Yeah, that's a good point and we can take the time to make that poll before I do anything else and any comments. Is it the right problem.

E

D

E

When we say problem, what is the origin text? We've talked quite a lot.

A

About this, I'm not exactly proposed just a moment.

E

A

Me share my the sliding in just a little bit.

D

In just a sec.

D

So so the problem is liked. That is that the right problem is a discussion about the problem. Am I correct here so the problem? Yes, but working on it? Yes or no, so how ho? How? How close it to to to the actual problem space is that the question.

B

Yeah, the next question we're going to ask yeah because, like you, may feel that there's a problem but you're not interested to work on it. uh That's totally fine, because you have so many other things to do right. Okay,.

D

Got it makes sense.

D

A

And please forgive my grammatically incorrect english.

A

Hopefully it's an understandable.

B

It's yeah, I think you you're trying to say like is this a problem you want to work on.

D

Yeah the people in the room right, not somebody else, yeah.

A

Is really, um are you willing to to contribute uh to the process, but that's a separate, that's what would be a separate.

D

Question be a that's a working group problem forming problem. I guess yeah.

B

Well, but it's still uh crest raced it, and- and I know this is a difficult question- even for uh both to ask them whether who who is interested to implement or deploy something uh even at that.

F

B

When you don't actually know what exactly you would be implementing and deploying it precisely because we haven't developed it right, okay,.

D

Just notice that down 20 people rough about so this is not the initial room but yeah we can do this.

A

Okay, so um these are all good um answers. um This is good feet, good feedback. um Now I want to reopen the queue hank. You wanted to respond to roman and oh actually, before we go before we go there. um Just be very brief, because in about a minute, I'd like to get into next steps, so um just be very brief.

D

I can talk very fast. uh Roman was asking: what's the difference between the supply chain claim and the claim evidence in rats architecture? So yeah, that's a discrepancy.

D

The claim we're talking here in skit is the statement about the supply chain. Artifact.

D

You are issuing that by signing it and putting it through the thing and you get the receipt back with your claim and then with the receipt it becomes a transparent claim because everybody you want to see it can see it. That's a transparent, that's a that's! uh That's a proof basically added to the claim. So that's definitely not the rat's claim claim is a term to be improved.

D

But for the sake of the argument, we were going with claim right now so yeah. That is not a good choice. It is causing some confusion. We are aware of that. So again, the supply chain entity makes the statement signs it put it in there get the receipt back, that's a transparent claim. Now so yeah, you know you're right.

D

We can be better.

A

Okay, roy very briefly, you get the last word.

J

I had a question first, which is you know this is a draft problem statement. Christopher's question is: is it the right statement? How do we morph this and make it better is, is is the question I have for you.

B

I think the answer is the mailing list. uh We will have to sort of discuss this on the mailing list and fine tuning chris, uh any anything to add.

M

Yeah, that's a perfectly fine way to do it and I think, just focusing on a specific use case um rather than saying we're going to solve all the the supply chain. Problems that look once is perhaps a good way to start going about refining things.

M

A

um Start summing up here, um first of all, um thanks everybody for the great conversation um thanks to the presenters um and and thanks to all participants, um we should. We should talk a little bit about next steps.

A

um So in doing this, um what I want to say is first of all, the next step is. I think people should continue to discuss this on the mailing list. If you haven't joined the mailing list, it's skit s-c-I-t-t at ietf.org, and if you go to ietf.org, you can find your way to the mailing list manager. Where you can add yourself, then there will be a hopefully working group forming both and I do see the area director in the queue.

A

So I think, rather than me, talk I'm going to let roman talk about this part of the next step. Roman, are you okay with that.

E

Yeah sure emily, yet I mean it's a great question to say god: what are we going to do next? I mean what I heard here and kind of thank you for you as the chairs and thank you for the proponents and the community to kind of debating this kind of around that we have a lot of interest in kind of supply chain and we may even have a lot of interest in software kind of supply chain, which was not in the problem statement.

E

uh We are going to have a buff at kind of 114 and the hope is to turn all this energy and interest into supply chain into being something specific enough that we can get to a charter. The skip mailing list is absolutely the place uh we kind of need to start. We would like to have that conversation in the concrete at ietf 114., so kind of things like you know, what's in, what's out, how do we talk about what we do now versus what the roadmap kind of is? How do we sequence things?

E

I think that's all all in scope here, but we have a positive result here in that you know, there's an interest here around supply chain. I think the big question for us- and that is the chartering question. What specifically do we want to do here at the ietf and do we have the critical nasa folks to do it? Yeah.

B

Yeah, the buff um sort of uh not under the charter decks that we need to prepare for the buff. We obviously have to answer those type of questions, because we have to put something as milestones there and ned um raised it quite nicely when, when he talked about the slides for the uh standardization scope and was asking some questions about, it sounded to me like what do those items?

B

Bullet items and graphics actually mean in terms of documents that we are going to deliver as a group, and I think that's definitely something that needs to be discussed on the list. Other things, in my opinion, um there have been a lot of good questions flying by I saw some of them didn't saw all of them, so I'm planning to go through the list and then bring some of them up on the mailing list, because and also some of the questions that were asked. I think the there is some uh room for more discussion.

B

We are obviously limited in time on this corner.

A

Okay, so um that's a, I think that uh hannes, you stated it well. um We are really to the point on. There was one thing we didn't put on the agenda slide, but we should cover it anyway. Is there any other business that needs to be covered today, and I see that there are no there's nobody in the queue right now. Is there anybody who thinks they need to make an additional comment before we close the meeting.

A

All right, then, I want to thank you all for participating. um Please participate in the mailing list. If all if there's no conversation, that's taking place in the mailing list, that sends a very strong signal to the area director that there may not be.

I

A

um And so please, please do sharpen your. uh You know. What's going to be built right that that that part of the charter, what are you going to cover? What specifications do you think need to be written? What problems need to be solved? I hannah you said it as as well as anybody there and um I look forward to seeing you all on the mailing list.

A

Final comments dennis.

B

A

You thank you all right.

E

Have a great day, everyone.

H

Thank you. Thank you. Thank you.

D

Thank you, yeah thanks, bye-bye.

D

Good night.

C

Tank good night.

H

Can someone please stop recording.