<tallted_//_ted_thibodeau_(he/him)_(openlinksw.com)> Another weird jitsi-ism to note and track... I joined before the host, and the "waiting for host" display persisted after the host joined, with only "cancel" and "i am the host" buttons, which forced me to drop from the meeting and then rejoin.
Mike Prorock: There we go I think we're officially kicked off now so hello all and welcome to the main weekly ccg meeting the today the topic is the supply chain Integrity transparency and Trust group from ietf talking about what's going on there and some overlaps are joined by three wonderful people at least from that group will be talking to the work going on over there just a quick reminder that this meeting has with all meetings at w3c. ✪
Mike Prorock: Will conduct put a link to that in the chat the agenda for today is in the link that I am pasting here from the mailing list archive for the announcement just a quick note that anyone can participate in these calls and the one kind of key item is if you're planning on contributing to acct work item you must be a member of the ccg with IP our agreement signs we don't get ourselves into any intellectual property fun stuff later on. ✪
Mike Prorock: Just take recordings and post them and those are archived up on our GitHub the we do also manage the queue either by I think the raise hand button is now Linked In all the way but in the chat you can just type the letter Q followed by the plus sign and it will add you to the queue or take you off. ✪
<mprorock> In IRC type “q+” to add yourself to the queue, with an optional
Mike Prorock: Constructions there just in case you need them because sometimes explaining something that's being typed versus seeing it as a little bit different quick pause for introductions any aside from our speakers anyone new to this call anyone that hasn't been on this call and quite a while. ✪
Mike Prorock: Call on people like Wendy who haven't seen all in a little while. ✪
Wendy_Seltzer: Sure great to see if folks I'm Wendy Seltzer I left the w3c name at the end of 20 22 and and now with two cows looking into broader questions in the identity space so looking forward to catching up on the work here. ✪
Mike Prorock: Awesome great to have you so any other intros new to the group not new to the group. ✪
Mike Prorock: Right with that I'm going to jump over to any announcements and reminders and then I'll touch on the work item a new as well after that but any broad Community announcements Manu Europe. ✪
Manu Sporny: Yeah just two of them one of them is that there is a new kind of proposal I think that's going to be circulated at the verifiable credentials working group around the specifications around the verifiable credentials ecosystem so we're calling this the verifiable credential specifications directory right now it's just a personal repo but it's going to be kind of discussed as a thing we might. ✪
Manu Sporny: Adopt in the VC w g just giving this. ✪
Manu Sporny: Up that that works happening what we're trying to do is be a bit more decentralized with how we run the Registries one of the big issues with the decentralized identifier registry is that one there a normos number of decentralized identifier methods in there and then to the maintainers of that registry had to repeatedly make judgment calls on whether or not to allow something into. ✪
Manu Sporny: Kind of a gatekeeping exercise some people didn't like the fact that the editors had so much say about what gets into the registry or not in so this is kind of our second attempt at making it a bit more quote-unquote fair to get into these Registries basically if you are extending the verifiable credential specification in any way we want to be able to kind of point to your specification whether it's at in a w3c. ✪
Manu Sporny: Or ITF or whatever you should be able to at least list your specification there so that's the first item just be aware that that conversations going on right now around how to make process of registering specifications that extend the core data model more fair and easy the second item do you want me to go into as well it's the it's the test suite for verifiable credentials 20 or like do you want to pick that up at. ✪
Mike Prorock: We'll Circle back to the test Suite just if there's any other announcements that way we can get them up and then come back to the proposed for cutting there any any other community announcements here. ✪
Mike Prorock: All right well cool well then may proceed okay still linked to the issue there so. ✪
Manu Sporny: Even great thanks and I'll just do a quick screen share so the idea here is that the verifiable credentials version 20 specification is going to be going into candidate recommendation probably sometime during the summer one of the things we want to be sure that we have kind of lined up is a good test suite for that. ✪
Manu Sporny: For we go into Canada track you don't have. ✪
Manu Sporny: A good idea to do that and so this proposed work item is a test suite for the verifiable credentials 20 data model right now it's partially complete we are looking for other supporters from other organizations basically this is a you know it's a we need it we need something that tests the the specification and we're trying to learn from the version 11 data model tests. ✪
Manu Sporny: Something that has tests that are more repeatable so that we can run tests on a regular basis like a weekly basis against the the specification to make sure that we can write new tests and understand how the ecosystem is going to do with that new test before like publishing it and getting a whole bunch of hate mail that implemented a test that you know breaks the ecosystem and so and so forth so we're trying to do a better job this time around with the more you know see I see. ✪
<pl> Pleased to share that the paper on Composable Credentials via LInkedClaims and
Manu Sporny: That lets see it is based on the verifiable credentials API that is being incubated in the ccg that might be viewed as controversial by some so pay particular attention to that we already have 13 implementers that have demonstrated interop at a higher level through the jobs for the future plugfest number two that happened last November and then again. ✪
Manu Sporny: We will have another one happening in May so. ✪
Manu Sporny: But tried-and-tested approach that resulted in really good interrupt demonstrations a couple of months ago so we're trying to apply that same those same learnings to the verifiable credential 20 specification so the work item proposals there we're looking for a couple of or other organizations to support it and I think that's it. ✪
Mike Prorock: Excellent please add commentary to there to the issue there and I'll repost the issue just in case you needed I think there's obviously very strongly supportive of testing I think it would be great to get some broader input from the VC working group and from the chairs over there as well as well as I think input from those of us who have worked on test Suites also I know or he's already done some commentary there so with that. ✪
Mike Prorock: Yes please Brent thank you sorry that's my bad. ✪
BrentZ: My cat that is myself to the queue if that's okay no worries my question. ✪
BrentZ: How does this ccg work item differ from the work described in the VC working group Charter to produce a test Suite. ✪
Manu Sporny: It doesn't the the idea is incubated here check to make sure that we've got the iron you know wrinkled the wrinkles kind of ironed out and then the V CW G could decide that they want to pull this test Suite in or point to it or that kind of stuff so that that stuff is just kind of like we're going to have to figure that out later on but the the the idea is that this. ✪
BrentZ: Thank you for explaining the reasoning behind bringing it to the ccg as a work item I would encourage rather than doing that bring it to the VC working group as a work item since that's where it's intended to be anyway and that's where the conversation really ought to be had and held. ✪
Mike Prorock: Yep and chair hat on and obviously this is my personal coach are opinion Harrison and Kimberly could way otherwise is if we already know that it's going to try to go somewhere I think we should just take it right there so I'm very much in favor of runs commentary. ✪
<bumblefudge_> minor announcement: some RWoT papers got finalized this week. The one Martin Riedel, Egidio from Nym and I worked on will hopefully follow in another week or two!
Manu Sporny: Plus one I can do that I guess we have a couple of other work items that are I don't know if they're taking that path like this I guess credential schema was already a part of ccg I guess we just need clarification from the chairs in CC G and B CW G what the intention what we should be doing now that we're like getting really close to feature for he's going directly to V CW G or incubating here first just. ✪
Manu Sporny: Be cwg I was falling what I thought was you know the process we had always been following. ✪
Mike Prorock: Yeah no worries there I think Brent you and Christina and myself and Harrison and Kimberly can just do a quick Circle up on the email and decide a good path forward there yeah and maybe I can give you my quick read which is that if it's already listed as a deliverable and was not incubated at ccg and it's planning to go to the VC working group it should go straight to the VC working group if it was already in ccg being incubated then you know that's obviously a different case. ✪
Mike Prorock: Yep all right well with that let us move on to the topic for the day and so I am going to hand the ball to the Steve Hank or a combo along with anyone else they may choose to put on the spot and let them talk about skid a bit I will be monitoring the queue but I do want to get them to at least get a quick overview out for the group before we start actually calling into questions there so with that. ✪
Orie Steele: Excellent so I'm I'm always steal one of the contributors to skit also involved in dids and BCS with me today Steve Lasker who weave on weave omitted from the title slide I'm sorry Steve we'll get that fixed for you anyone else when I give quick introductions before we Dive In. ✪
Stevelasker: I guess I'll just say hello but we've been making great progress on skit and is just working across the various groups it's been pretty impressive to see all of the homes that are already in place they were trying to make sure we put in a group. ✪
Orie Steele: Hank if you're introducing yourself you're muted. ✪
Mike Prorock: Start fraunhofer network connection. ✪
Orie Steele: Apologies if you hear me coughing or wheezing during this presentation and I was I'm screen sharing I have not muted myself in fact let me go ahead and do that really quick before. ✪
Orie Steele: Essentially there's been a number of cyber security incidents that have raised the eyebrows of folks specifically related to solve for supply chain incident so most recently the executive order 14 028 on improving the nation's infrastructure and there's been a lot of work that's happened as a result of that executive order to try and increase the. ✪
Orie Steele: All these for organizations that consume software or especially software that might have complicated open-source sort of dependency graph to kind of keep an eye on what what what dependency is go into your software how to how confident are you in those dependencies and in the case of an instant you know how can you trace through various pieces of software that could be involved in that particular incident. ✪
Orie Steele: Else you want to say on this slide ski. ✪
Mike Prorock: There is that wonderful familiar always. ✪
Nis Jespersen : Okay now I get why you don't see anyone yeah I was using the Gypsy app that was an enormous tremendous experience which typically works well but well not in this case I'm sorry I heard nothing I was wondering when the science does. ✪
Orie Steele: You have not missed anything we've just gone to your slide and I said incidents happen and that's basically it you're welcome to take over. ✪
Nis Jespersen : Okay I read it that said I'm so sorry for this extra technology works right snafu so my name is Hank Hank Buchholz located in Germany at fucking at The fraunhofer Institute for secure information technology and sometimes struggling this technology so yeah we are probably you had already some things I'm some context I'm working and started position one of my hats. ✪
Nis Jespersen : Is standardization the ietf and TCG. ✪
<mprorock> ha, steve should be on that slide, why am i on there ;)
<stevelasker> amend the ledger...
Nis Jespersen : And I'm very familiar with the work of the w3c of course and next like this I guess re and austie for really going into some details here we are going to talk about today V get skip is the supply chains Integrity transparency and Trust effort at the ietf and this is motivation slides of course incidents at my hurt that's correct a lot of things like Supply chains are spending the globe some other people call it. ✪
Nis Jespersen : Value creation graphs whatever you. ✪
Nis Jespersen : It's moving data it's moving data between stakeholders and that sometimes gets blocked unintentionally or intentionally so there is no 40 no 28 on improving the national cybersecurity there's also the National Security thermal Creations an advisory committee that is advising the president's office about how to counter some of these threats and I think. ✪
Nis Jespersen : As a u.s. Centric a little bit because both of these examples are from the US but it's kind of highlighting this arrived at a level where people care about things and now we want to fix some parts of it so next time please and that comes to what is skit and I've been told maybe I shouldn't spoil everything at the beginning so I will so skit is basically a set of building blocks that one this is intended to increase Trust. ✪
Nis Jespersen : In the authenticity and the for example. ✪
Nis Jespersen : He of assertions about supply chain products artifact statements and and that is for a long time so exceeding typical lifespans of certificates and I'm talking about the old ways that a certificate could last for like two years like I don't know it'll be fun they are section death ID and not like six weeks as we might be having approaching in the future so so it's about. ✪
Nis Jespersen : And these statements about in the ITF about software first because when we approached the ITF and said hey let's try to do something very small in this very very big context people got very scared about the big context so so the first thing that happens is that like scopa Town Supply chains very big word you can't do all the supply chain that is prone to error because all the use case it was somehow very and the devil is not. ✪
Nis Jespersen : Details and yeah so software pretty. ✪
Nis Jespersen : Everybody booking besides he and the ietf and the CC and so on so supply chain for software was our initial chartering starting point and it includes all the things like about the software component Z good old switch from the good days firmware descriptions all the package repositories out there container Jesus's very own VOC and we argued for chartering that we would use some building blocks from the ietf that are already there but are not only the eyes. ✪
Nis Jespersen : I have of course that's why we're here so next. ✪
Nis Jespersen : Yeah this is just some examples I'd say to talk about things that are originating from supply chain entities the first thing of course is an ITF example it's a concise reference Integrity manifests basically for trustworthiness aspersions created by remote at the station so this is this is this the item for example this artifact would explain at tested to verify to verify us that they want to check the trustworthiness of a test. ✪
Nis Jespersen : Very Co driven context that is the softer bit of materials I think SPD X is one of the examples that others are going to X of course and you could vote split if you count that in to that mix and and of course there are very very useful things out there that are can be used on a daily basis can be used at Hawk and that's contain initiative here you're all these are statements about software in the end and we want to. ✪
Nis Jespersen : Here you that is this is a mesh obviously you know and my mesh my time I'm using my phone so maybe maybe it's that I don't know so we have you lost the these artifacts we're talking about those we try to increase the believability of the things we State about them and these statements I mean Quorum as bombs or either service configuration they are all statements about more complex software setups deployments or packages next I please. ✪
Nis Jespersen : So that of these things in these statements and the could go into all the vulnerability versus packaging versus built rules becoming the actual problem that's all nice and fine I think that's very important content and a lot of people defining that we're not doing that next slide please. ✪
Nis Jespersen : What we do as how to the issue to add some again believability to these statements to these artifacts we are talking about products they were talking about so if you're talking about artifacts in software disability artifacts typically in in other supply chain artifacts are already the statements about the product so artifact is a kind of a interesting term all over the place but let's go with that right now so we add some proves. ✪
Nis Jespersen : To these statements and make them. ✪
Nis Jespersen : I'm statements for called claims and now basically next slide please you can already forget everything I said about what we're talking about because that's opaque opaque to the skit concept we are taking in a certain transparency servers a signed statement and how to sign it that's something we specify in the igf put it into a service and the service has an append-only lock all. ✪
Nis Jespersen : Again that is a tent only locks so how to use that building block and a bigger system is currently actually otoscope you do some reference application they're going API with rest but that is not the core solution the cost solution is how to uniformly signed integer statement and then you add it to an append-only log how to get a receipt back and also trust that one that's called transparent claim or transparent statement and our world right now so that's actually true things. ✪
Nis Jespersen : We are going to standardize here in the ietf and want to talk about here. ✪
Nis Jespersen : Is someone useful or relatable and next idea. ✪
Nis Jespersen : And that's basically what we want to have us fissures need to identify themselves have to be identified after the fact to some extent especially if they're participating in critical supply chain applications and we need this transparency service and can argue about the name but there's a note interpolation function in there and it's working like a real world notary it does not read the contract it just says you said that at this point you can trust me I have the time. ✪
Nis Jespersen : I have the identity is verified I put this into my append only law. ✪
Nis Jespersen : And you get back this receipt with a proof that I just notarized this and that's basically it both of these things are very very tiny because we're using again ITF technology we can talk about that later but it is Seaboard so that's I don't know Vic's a good and it warrants and it guarantees some things or whatever and said is sure something's going to use a very hot rod it assures that you have long-term accountability and you can detect if some statements became Falls over time. ✪
Nis Jespersen : I mean some things are product in good intent and 20 years later you realize well. ✪
Nis Jespersen : Doing the job that they're doing other things also and they're not very good at that and maybe even harmful so we want to express that that's true with I don't know building materials like Asbestos and it's true of libraries used for ages somewhere and then at some point you will detect a weakness and vulnerability and have X that goes for on forever because never been resolved conceptual problem and you also want to have accountability and auditability for who says it and why he was allowed or she or the data tier sorry to to state. ✪
Nis Jespersen : That on the ledge and that's basically it and that's where I hand over to Ari and he met Ed whatever. ✪
Nis Jespersen : So this points are okay I think I don't know questions really work if it's in chat are Auto oil but I'm both now. ✪
Mike Prorock: Yeah watching the Q man who I see you on the computer. ✪
Manu Sporny: Yeah thank you for all this I think it's good I've been wondering how all these pieces fit together you know for a while I guess the thing that I'm still a bit fuzzy on is exactly what is the skit group standardizing in what parts do you feel you're going to pull in from outside of the skit group like ietf or w3c. ✪
Manu Sporny: Now is you know as you know the there's a verifiable credentials working group at the w3c we you know have spent a lot of time on how to express have you know Express claims about a credential subject in Secure that you know statement what pieces do you feel are your going to pull in from external sources and what pieces are you defining in the skip working group itself I know you already went. ✪
Manu Sporny: Could you call out some specifications that you're pulling in and in which specifications are you are you actually working out that might help. ✪
Nis Jespersen : Of course let's start with the biggest answer first we are for this small things we are actually creating specifications for people in tons of context even for the supply chain use case rolls all over the place statement examples like we see for example are selected to slogan as a use case for example and and that is that is pulled in with a lot of text I have to admit but then you're asking also what we re using. ✪
Nis Jespersen : So of course the civilization that is sibo. ✪
Nis Jespersen : Basically it'll look at the future and express constraint node environments as well as large skating systems for every kind of system industrial iot or cloud services from The Edge are called internal basically all the scope that is why we are looking at the circulation that is very likely to be future proof you can't always be sure but that's what we are currently going with and I think it's a good choice person. ✪
Nis Jespersen : Then we are pulling in based on seaboard. ✪
<mprorock> cose_sign1
Nis Jespersen : The concise object an encryption working group output the Cozy working group which basic defining a possible of course assigning an envelope that includes a protected header will put you all the important metadata attributes that have to be also signed provide space for unprotected header where you can for example Put a receipt to render it with a like counter signature with metadata transparently in the payload or maybe even a detached payload and the signature. ✪
Orie Steele: Hank we have some slides that cover some of that I think we should wish it advance and then if it doesn't answer the question please ask you again. ✪
Orie Steele: Stealing classic tank stealing Thunder these are my slides you had your chance. ✪
Nis Jespersen : Okay yeah I'm so sorry I couldn't see into the future but wonder if you stay with us here I think I'm stealing already content from other slides maybe we could defer the question a little bit Yeah okay this is good. ✪
Orie Steele: Awesome felt so the slides that were about to share with you all are from ietf on 115 so they're a bit dense but they're going to sort of recap some of the basic introduction that Hank is given this particular slide is a high-level architecture overview you have verifiers they want to know whether an artifact is authentic that artifact could be a binary could be container it could be firmware. ✪
Orie Steele: There could be other parts of the software Supply. ✪
Orie Steele: And the notary when the notary furnishes a transparent claim to the verifier the verifier can you use that transparent claim to gauge the authenticity of the software artifacts and on the right hand side you have the issuer is making statements about the artifacts and they're submitting those sign statements we call claims to the notary for inclusion so this is what Hank was already sort of getting ahead to. ✪
Orie Steele: That are relevant to software supply chain and there's lots of different serialization formats that are an important component of software supply chain so if you think about it the issuer has lots of soft of artifact types that they want to secure today so there's Json there's XML there's s Palm formats like SPG X and cyclin D x-- their salsa and each of these formats usually has some you know. ✪
Orie Steele: Associated with it because these are formats that software has to make use of today already and so there's usually a media type that describes them so for example Helm chart has a media type and a Helm chart is an important part of deploying software within kubernetes so one exciting point of overlap is decentralized identifier so you can see in this case the issue or is identified with it decentralized identifier and you know the Hope here. ✪
Orie Steele: Is basically what Hank was mentioning before we're hoping to bridge the gap. ✪
Orie Steele: The world of x509 and oid see that exist today and the future world where decentralized identifiers might play a better role in providing identity for issuers the other sort of components of what goes into a skit claim so as Hank mentioned is cozy sign one but there's some parameters in the header that are important the issuer parameters important so that we can identify the the issuer the key that was used to sign the. ✪
Orie Steele: Algorithm that was used to sign these are all. ✪
<bumblefudge_> feed ~= topic ?
Orie Steele: Looks you've been working with verifiable credentials the feed is a new header claim that we're proposing and that's to identify you know basically information about the artifact type itself and then the content type this is again a field that's familiar to folks within the verifiable credentials working group because we spent a lot of time talking about media types and in fact there is support for using the same cozy sign one. ✪
Orie Steele: Sure with verifiable credentials with a content type that. ✪
Orie Steele: You application slash credential + LD + Jason so just pointing out the use of the CT y parameter here you can see in the example its application xc9 10 firmware image but it could be that that confident type could be other information that's relevant to solve for supply chain hopefully that's starting to answer some of your questions man you about how this work might fit together. ✪
<henk> feed is basically like a broker topic, yes
<bumblefudge> toll, danke
Orie Steele: Important component of skit which hasn't been you know there are no formal work items around it but it very often comes up is this question of policies and standardization so you know first of all when the issuer wants to make a claim transparent there's a before they even can register that claim the issuer might have a policy that they're going to apply so the issuer might rebuild the software artifact run some automated. ✪
Orie Steele: Ruling on it to decide whether it's ready to be. ✪
Orie Steele: About it so some of that tooling could say you know all right am I ready to sign over this information let me review before I sign am I ready to accept responsibility for this do I feel confident in the process that was used to create this artifact my sure this is the format that I'm wanting to sign because I'm about to sign it and that's signing B so maybe I want to change some part of the representation before I do that and then you know what does the artifact what artifact does it refer. ✪
Orie Steele: Were too so in the case of a binary you know am I being clear about. ✪
Orie Steele: Identifier for the binary in my claims or maybe I want to use a different one or maybe I'm maybe I'm trying to protect a particular Helm chart or an SPD excess bomb so the issuer has to sort of make those decisions before they can create their their claim but once they've managed their issuance policy they are going to bring that sign claim to the their transparency service or the notary and then there's a registration policy that the notary or the transparency service is going to. ✪
<stevelasker> A feed is a collection of statements around a particular artifact.
Orie Steele: Require that all issuers be two Factor authentication and all from email addresses on a corporate domain in order to have their this claim certain Claims can only be registered with that policy for example so if you're in a corporate environment you know certain transparency Services might only accept artifacts that are from that Corporation from issuers who are strongly authenticated bound to that Corporation Etc another transparency service might operate in an open source environment where they're taking artifacts from. ✪
Orie Steele: They're just using open ID connect so the registration policy is the policy that the transparency service uses to evaluate whether a given claim should be made transparent and usually you know the minimum that the registration policy will have is that it's going to authenticate the issue or in some way. ✪
Orie Steele: Right and then on the other side with the verifier accepting the transparence claim you know verifiers might have different requirements in terms of which kinds of transparent claims they'll accept and from which issuers or from which notaries so it could be that you know as much as I love Hank I don't trust him to make claims about software products that my company produces and even if he's able to make those claims transparent with a notary that's really will trust it. ✪
Orie Steele: To Walter you know myself as a verifier or folks who rely on my software and so the validation policy for the transparent claims is another dimension so these this policy Dimensions important to think about although like the specifics of how the policy languages are built and enforced are currently there are no work items that are actively underway about policy language is just an important component to understand. ✪
Orie Steele: Balls of like water what is the problem that we're trying to solve here and there's two ways to think about it there's the sort of malicious issuer scenario and that's you know where a bad issue or tries to serve malware to Alice but not too Bob so you can imagine you know maybe Bob is you know trying to run a threat analysis platform analysis going to consume software and if Bob catches the the malware he's going to warn everyone. ✪
Orie Steele: The issuer you know they want to serve the mount the the package without malware in it to Alice but they but they want to serve the package with malware to Bob and you can see the little bug in the malware in the bottom part of the image so this bad issuer is basically they're trying to create two claims for the same lib Acme x86 one of them has malware in it the other. ✪
Orie Steele: Them both to the notary and because the notary is recording both of them a an auditor can see that there are duplicate claims that have been registered so the notary in this case is honest but the issuer is malicious but because the issuer is required to make their claims transparent and auditor can review the notary and see that there's these conflicting claims for lib Acme x86. ✪
Orie Steele: Another angle on this is to consider bad notary so imagine that bad notary tries to roll back Bob's version with a receipt from Fork registry so in this scenario incompatible receipts and this comes from the structure of the notary itself which can be implemented in different ways as was mentioned those incompatible receipts means the notary endorsed inconsistent Registries and so that that is also detectable because of the the nature. ✪
Orie Steele: Only Ledger and so if you find that a notary is doing that kind of thing you're probably never going to trust them ever again. ✪
Orie Steele: All right so I think at this point we are essentially done I've got this slide to leave up as we take questions Mike are we on time on my head of time. ✪
Mike Prorock: I think now is probably a good time for questions especially knowing that Hank responses can sometimes be informative. ✪
Mike Prorock: I can't help it give I see what first I think. ✪
Geun-Hyung Kim: Hi ya thinks this is a great presentation I think my my questions and her little high level so well first one is this is ietf that were talking about this would be a work item for right. ✪
Orie Steele: This is a working group at ietf with with several documents that are intended to be worked on by that working group currently the architecture document is the only formal work item ITF I believe. ✪
Geun-Hyung Kim: Okay that's helpful so yeah the first one was just sort of it was my expectation that ietf needs things scope down a lot more but the working group makes sense I think the main thing where I'm still sort of struggling is maybe it's just a terminology thing but around the notary transparency service like depending on what role that might like what form that might take it just really stands out as an unnecessary like it sounds. ✪
Geun-Hyung Kim: Like it's easy to just sort of not. ✪
Manu Sporny: +1 To Kim... feels like unnecessary centralization? Have same question as Kim -- what purpose does that role play in the ecosystem? ✪
Geun-Hyung Kim: Too much action to that role or too much of it like investment in a single kind of centralization point because that looks very clearly like something that can be openly audited Noah guess the governance of all of this and sort of like there's probably use case specific things that I could see some form of curation going into it but I'm just curious to poke into to get more information on that because that just really. ✪
Geun-Hyung Kim: Lee maybe it's a term service maybe I don't know just more. ✪
<bumblefudge> is there a package manager usecase to map the roles to, maybe?
<manu_sporny> ooooh, much more clear now via "Mapping ietf terms to W3C ones"
<mprorock> Regs mandate a central point in many cases unfortunately
Orie Steele: Sure so one thing I'm not sure if I go ahead this slide here just I prepared this in case we needed to have a terminology discussion the transparency service in quotes is sort of like the the concept of verifiable data registry in decentralised identifiers and verifiable credentials so the log part of it is like the verifiable data registry. ✪
Orie Steele: Of it is a little bit different it's like an independent role sort of like an issue or in a verifier combined. ✪
<bumblefudge> exploding-head-emoji
Geun-Hyung Kim: Okay that's that's helpful and all of that said I think I'm really even though supply chain software Supply chains one of the first focuses I do think that this pattern will be really interesting beyond that so interest like it's great that you're focusing on specific use cases just to get somewhere but I'm also eager to follow along to see how it can inform other efforts so. ✪
<stevelasker> The notary's purpose is to verify the credentials and assure the registration policy is met. For instance, what types of IDs are acceptable.
Mike Prorock: Yeah can that was really helpful and I think two notes one because the centralization thing I think is something that tugged a bunch of us right up front but unfortunately there are certain regulations in certain countries that mandate like there must be a single you know repo for XYZ right for certain types of use cases so we have to be able to meet that plus more flexible use cases right as you can imagine the and then regarding the other use cases and applicability. ✪
Mike Prorock: Be a good one to reach out to who's on this call but there is a skit community formed to look at how do we handle things like reference implementations or exploring other use cases with this pattern as it evolved so if you're interested in that side that's definitely something worth taking a look at I believe Dimitri is up next. ✪
Dmitri Zagidulin: I was going to ask about which pieces on this architecture diagram are likely to be standardized by the working group and or image inserted partially in that only the architecture itself apparently I was curious specifically about the notary transparency service we've run into need for that use case in VC edu context the notion of and it's a that transparency service that audit log if you will is a roll. ✪
Dmitri Zagidulin: So that I think we're not talking about enough. ✪
Dmitri Zagidulin: LBC working group are old all that is to task is the format and the API of the notary transparency service likely to be standardized by this. ✪
<mprorock> physical/cyber-physical supply chain needs as well for a clear append only notary (at least the interface)
Orie Steele: So the the first I'll do the easy ones the the format of the claims are definitely to be standardized by this get working group at ietf the format of the receipt is definitely to be standardized at ietf although there's a separate document that tracks the structure of receipts today there's some rest sort of API interoperability components around interacting with a transparency service that I think are going to be standardized and. ✪
<manu_sporny> What, IETF isn't going to start standardizing blockchains!? :P
Orie Steele: The question that you're asking the specifics of like the internal mechanism for building an append-only log I think that is probably a there's a probably a boundary somewhere around that where you know ITF isn't going to get into the specific you know disk layout you know format that you've used for your service but generally speaking there's like a pendulum Lee log or Merkel database. ✪
<kerri_lemoie> @orie - do you know timelines of the IETF standardization work?
Orie Steele: Component of getting the receipt object so there is work that's planned with in ietf to standardize some components of that sort of similar to the certificate transparency work but a little bit more generic but that's intended you know stuff that hasn't fully landed yet. ✪
Nis Jespersen : This is Hank may I add something to this while again to Cozy types of cozy envelopes the core of all the specifications here and yes the the way how you create a inclusion proof sometimes maybe part of that receipt on they have a lot of attendees that are actually pretty new to the ietf of the w3c all together they're actually coming from supplied. ✪
Nis Jespersen : Chain stakeholders I want to say. ✪
Nis Jespersen : And when they arrived at the new place they come with a question and then you need to reply to the question in sometimes in the form of a protocol so that's why we actually doing the rest API because without at least a reference guidance that is this rest I pi and the ietf is not prone to do a lot of them but without it you wouldn't be able to answer simple questions like can could you please give me all vulnerabilities that are known to this thing. ✪
Nis Jespersen : I think people want to be have an answer to but but if you would just build a building blocks they will drag you out you've thrown into them and they won't work by themselves so there has to be a small compromise here through to provide some reference API some some not a reference system because the ITF does not build systems its building blocks and and then go from there and that is I think why we are also here to to to to make. ✪
Nis Jespersen : More use of these building blocks and and find out how. ✪
Nis Jespersen : Match them with existing work and again or if I can probably more my experts on this topic that this inter connected use but I think that's that's what this is about we can't solve this alone the people that were the supply chain stakeholders said that the people that were those and this use some of this case the software creators all of them are like yeah and the probably not we should give it to keep it and that's why we are here. ✪
Mike Prorock: I saw a quick question from carry which was just on timelines that ietf and then I'll call on Bumble fudge. ✪
Mike Prorock: So standardization timelines that ietf Hank if you've got a quick comment. ✪
<kerri_lemoie> Thanks :)
<bumblefudge> famous last words?
Nis Jespersen : So I don't want to nitpick at the ietf but I think the standard latency of hitting a milestone in the ayat if across all Collective Milestones is 1.5 years late we are better than that moment so at the moment we are hitting our marks pretty very was only 2 months latency and actual timeline is that we have a consistent. ✪
Nis Jespersen : Year terminology means that we label them in a way that everybody can compromise and grudgingly my probably around but the definitions are actually pretty much in order and that is the important part so the labels of the definitions of the things people are worrying about at the moment then again the we have to kind of create some generic - to this we are coming this from the skit point of view to the eye. ✪
Nis Jespersen : ATF and we have just one requirement on this receipts for. ✪
Nis Jespersen : But we realize whether plenty ways to do this trees of hashes in all Merkle trees parse trees level trees unbalanced ones and there might be a generic part of this has to go to Cozy anyways so their deadline that's very the Milestones will also be some some cozy Milestones because we would add essential cozy elements I think in the future but our current road map that tells us that in the with the start of. ✪
Nis Jespersen : Stones are set that's an ambitious goal and we can't pick our about two things too long we tend to bicker about naming things but the size we also defining the structure of things so I think we are paralyzing the bickering with the construction of a contribution a little bits and that is the Mantra of the ITF I think not to serialize better paralyzed. ✪
Mike Prorock: I think that was very helpful and I think about as clear as we can get and ietf context and I think one note that is probably a little bit different than we see in w3c sometimes that we do see this in some working groups at w3c is there's very much a home for certain places so like if it's a very cozy specific thing maybe skit related work but it's going to take place in the coast a working group as opposed to it. ✪
Mike Prorock: A up on the cue probably the last word. ✪
Juan Caballero: Actually that was a it was a it was good that carry got it before me because I was going to ask something related with the which was are their language wide package managers that have expressed interest and like at what level of sophistication for you know of like you mentioned like V1 of all the building blocks built as a tight as a milestone like would it be premature for people to be thinking. ✪
Juan Caballero: Gale before then or are you already trying to get input from those types communities that run package managers. ✪
Nis Jespersen : So nobody's jumping that one I think now is the time to put in requirements if you are interested in having your favorite or your own or your stakeholder Pax Romana system addressed I think that's a that's a statement type so effectively whatever the requirements About Management your statement is would go into the requirements of an API will go in through the requirements of the messages we actually want to Define here so it might be. ✪
<dmitri_zagidulin> to ask a different way, are there package managers in the working group?
<bumblefudge> ^^ :D
Nis Jespersen : With some layers coming from a explicit application but there's no better than real data right so I assume we hope to have audience including stakeholders from that domain and best case scenario some heart requirements that are bashing the current Concepts like no this won't work because and then go from them. ✪
<greg_bernstein> NPM, PyPi?
Mike Prorock: Yeah and into that note also call out that there are some pretty large players that deal with distribution of software very heavily engaged in this and showing up to meetings and discussing what they're doing and how it overlaps so you know I think you're going to be seeing whether you may are directly impacted this or otherwise right it's going to be out there as a thing it just might be a little bit behind the scenes unless we look at things like. ✪
Mike Prorock: You know education or physical Supply. ✪
<bumblefudge> get the crates.io people in there hehe
Mike Prorock: It might be a little more visible pipe I'm not 100% sure on Greg seeing your comment on there we are doing stuff directly with machine learning and web crawling input for machine learning stuff so there's interesting stuff going on there so. ✪
<kerri_lemoie> Thanks for the presentation!!
<bumblefudge> amazing presentation!
Mike Prorock: Cool well with that I just really want to thank Steve and Hank and or in for their time today obviously we could have a lot of fun conversations certainly those folks in the working group probably recognized. ✪
Mike Prorock: Commentary around things like cty. ✪
<stevelasker> Happy to continue the conversation through the IETF SCITT discussions and/or the SCITT Community: https://github.com/scitt-community
Mike Prorock: Meeting because this is important to a lot of us so and helps if expand use of verifiable credentials into other serialization formats uses over time so with that Harrison would probably kill recording once again thanks all really appreciate the great questions today in the great presentation from the. ✪