KSWG did:webs Task Force - 2026/09/15

Hello everybody. I'm just pulling the meeting notes up and then we'll get started. And I am looking for Daniel. We usually hand the first half an hour over to him. And so we'll give him a minute to show up. And if he doesn't, we'll just jump into did webs. There he is. Morning, Daniel. >> Good morning. >> So would you like to take the first half of today for the dossier spec as usual? >> Yeah, sure. >> Okay, go right ahead. I'll get a meeting notes up in the background as you're going. >> Okay. Um, thank you to several people who have um, helped us over the last um, days and weeks because uh, we have several substantive things to talk about on the dossier spec. Let me um get my screen up here um ready to share. So um we had first a kind of a mechanical PR from um core. Um this is related to the specup T uh evolutions. um a few days ago um or raised this nice PR. Well, actually it was only a couple days ago raised this nice PR about um how to help the um the spec use all the latest spec upd uh features. I had done a change how long ago? I don't know a week or two ago. Um and core followed it up to make sure that things were being done right and added a um dependency on a new version of specup T1.9 I think. So um there's that PR and then um here we go. This is the right thing to share. Um well that's uh PR28. Um and then um last time we had this meeting, somebody, it might have been Sam suggested that I talk uh to Kevin about some of the stuff Gly's been doing related to uh regulatory filings. And uh Kevin sent me a bunch of information about how Glyfe wanted to solve a regulatory filing problem um using dossas. And so there's now this is uh authored by me but but um nod to Kevin for helping me find um some of the details here. Uh PR29 is sort of about um a use case for the dossier spec which added a couple of requirements to the u um to the spec that we hadn't been talking about. That's what close the gaps meant. Um, so there's basically a new section at the end in the use cases about um, a regulatory filing with the dossier. Um, and a few other sentences here and there that changed because of that. Um, so that's PR29. Um then I wrote um this one because PR30 because I started implementing um the actual operators that the dossier spec starts uh it talks about and uh I had promised I would do that. There's a draft uh PR against Carrie PI for those operators, but it's just a draft. I'm not asking for anybody to look at it yet, but at least it tracks what I started doing if if you're interested. But it was a useful forcing function and I found a couple of things as I was doing that. Um, and this also contains some things that were forced by PR29, which is why it's stacked on it. Um, so in order to address all of the um requirements that I got from um the regulatory filing uh use case, there were a couple of uh things that I needed to add to the dossier spec, not to carry pie. So that's uh PR30. And then lastly, um we have PR31. um which addresses some more of the things from um these are like loose ends from course specification or course uh PR where as [clears throat] I was processing course PR and doing a review on it. Um I realized there were a couple of other things that we ought to be doing. So um four ways that uh the specification has really moved forward since last month. I think um I would be inclined to just merge KOR's uh mechanical PR right here. Um even during this meeting I've already done a careful review of it and logged my review, but um nobody else has and it hasn't been open that long. So, I think maybe I'll leave it open a little bit longer if anybody wants to um review it. The other three are not just mechanical, and I'd really love um feedback on them from anybody who um is in there and feels interested. Um I think Kevin might be particularly interested in PR29 if he's on the call. I don't know if he is. Um, it's it's a generic regulatory filing use case, not specifically uh his, but I think it's close enough that um it covers what Kevin is interested in. Anyway, um, anybody have any questions or would you like to discuss any of these PRs in more detail? So is the PR30 verification outcomes authority binding self-contained packages and the profile regulatory PR are those just taking the operators that you have a open PR to carry PI for and then pulling them into the dossier spec. >> Well the dossier spec declared these operators um first >> first. Okay, gotcha. Yeah, it basically in order it's so the operator work is partly just pure operator work but it's also um joint issuance. Um so there's a section of the dossier spec that talks about an issuance paradigm where um uh person it's you could compare it to multi-IG issuance. In multi-IG issuance, somebody uh you know creates the event and then asks others in the multi-IG group to join it and um the escrowing process in carry pie is managing whether those signatures accumulate and make a single um valid event um when all of the you know signers have joined um in joint issuance. We're pushing uh some of that complexity off to uh the AC/DC layer. We're essentially saying um everybody who um wants to be a joint issuer of this should endorse the action by uh creating their own AC/DC of it. Um, so there's we're not um trying to manage this through a multi-IG process, but we're rather saying whenever you want, however you want, uh, just go ahead and issue an AC/DC saying that you endorse this joint action and um, then uh, well, there's a couple of ways to do it, but the way that we describe most carefully in the spec is that a kind of like a convenor um, goes goes around and monitors this and gathers up the evidence and says, "Look, we got to our threshold." Um, Sam, >> yeah, if I could if I could add something to that, um, the the multi-IG requires tight coordination between the parties. So a multi-IG group, you have to assume that the the parties involved are working closely together because they're managing one Kell and the security constraints on that Kell and the detectability of key compromise all of those things um you know impose you know uh you know a a tight coordination window on on on managing you know the the that identifier Whereas in joint issuance, the idea is that there are real world governance scenarios where tight coordination just doesn't make sense. It's it's too much of a constraint. And so and so uh with AC/DC's and edges you can you can create a governance structure with schema an ecosystem governance framework that says this is how we're going to govern this thing and we're going to govern it and these are the parties that are going to be the governors and and there's going to and they're going to essentially vote to change you know the the to to make changes and and that's and So they're and and and what they're governing it are documents, you know, AC/DC's that are, you know, it might be it might be uh like one of the examples is I think in is in the spec is like um you know this a judiciary that has you know like five members on a court, right? [snorts] And they're going to make they're going to issue court decisions and they have to have a majority. Um but but they but they they don't all share, you know, this the same key event log, right? So they're so they each have their own key event log. They each have their own uh key key management system, their own key key infrastructure. Um but they need to coordinate together on some on on on the court decisions. And so they so we need a a a cryptographically verifiable governance structure and AC/DC's provide that because of the edges allow you to you know contribute AC/DC's to a to to a uh a graph of ACDC's and and you can evaluate the truth of that graph by evaluating its edges and the truth of that graph is the results in the governance decision. So it's a so it it extends the idea of automated reasoning to a cryptographically verifiable uh construct. So it's not just a graph that you traverse. It's a it's an authenticatable graph that you traverse. And and I don't know if that helps. So, so it it really, you know, expands the uh what what you can do now uh in, you know, in modeling real world government structures. Um, you know, just like delegation, you know, allows you to model chains of authority, you have other other ways other ways that authority is expressed that aren't delegation chains. >> Yeah. Um, I the flexibility of this is um the the first reason why I started pursuing it. I I think that there are absolutely situations where you want um people who don't have the ability to coordinate tightly to nonetheless govern something. And uh so I I see it as a really exciting option. The the thing to note here is that although this is the we call it the dossier spec, joint issuance is a major feature and um the only reason we're not putting it in like the AC/DC spec or the carry uh spec or something is that um it's uh we didn't want to introduce yet another spec or yet another reason to um you have something new that has to mature while the a bunch of other core stuff that people are already eager to get uh is also trying to mature. Let let the specs in their current forms carry the features that they have to carry and um describe this joint issuance concept in a new spec that has a little bit more relaxed um you know timing. So um but that doesn't mean that it's just uh purely about dossas uh joint issuance and dossas are somewhat separable. It's just that dossas need need them or needs it. Would that be a true statement Sam? >> Yeah. Yeah. It just it just when you look at what it when you looked at the operators for dossier they a a set of the dossier applications required during issuance. So, it just made sense to put it here. I mean, down the road, you know, in the IETF, you'd probably separate all of these specs into small specs. So, you know, so you the dossier spec might split up into at least two maybe three specs or, you know, or you know, cuz they because they want things to be smaller and the AC/DC spec would be half a dozen specs and the carry spec would be half a dozen specs. But but you know uh but but uh not putting it in the AC/DC spec is a good move because as it is already people that are complaining about AC/DC's you know say that it's too complex right and and it and it's and they'll go yeah it it we we want simpler stuff and I go well if you if you look at the set of specifications that that are normative references is for a did um that set is is is big and and you have to understand all of those. So so so it's a false it's a false way to think about complexity. Um but it does make it easier to manage um small parts of the specs and to implement the specs in in in part. So, so I I don't disagree with the IETF's approach. I'm just I I'm just sensitive to the fact that people complain that Kerry is in AC/DC's are complicated and we just made them even more complicated by adding um adding joint issuance and dossas. >> Yeah. And the the defense against that charge I would say is two points. Point one is um this is uh modeling real world situations and >> yeah it's the it's the simplicity that is that you need right >> that's that was going to be my point too is therefore um this is loadbearing you there is no other way to do it except acknowledge that the world is this complicated [laughter] >> yeah [clears throat] it's like Einstein's famous quote make things as simple as possible but no simpler right well If if if it's loadbearing to to you know to quote you then you can't you have to have it otherwise the building falls down. >> So so you can't you can't model real world processes with something that's too simple to model them. Right? All models are are are wrong and some models are useful and models that aren't aren't complic complex enough to model to be useful are are are are useless. So, so, so you know, I I get frustrated, you know, you know, I'm letting a little bit of the discussion coming out of the SETI thing and I appreciate your your thoughtful response to that, but it's just like we've been trying for years to model these things and and we don't have the tools to do it because the W3C is not interested. And and their response is, well, it's too complicated. we we need to stick with things that we know and and we we shouldn't be trying things that we don't know. And I'm just like, okay. >> Yeah. So um maybe to put a bow on this part of the conversation, I'll just say part of the outcome of the dossier spec uh should be a wellsp specified behavior that isn't only useful in dossas but is generally useful which is how do you um do joint issuance and um I intend for that to be a mainstream feature. in Carrie PI very quickly. Um, this is part of why I'm uh I started a draft PR on this topic is because I think that's a very useful thing for Carrie PI to have as a a feature. So, um, the the the PR that I started is mostly at this point about operators. It doesn't yet have all the stuff about how you would do a verification of such a thing or or whatever. But eventually um I'll I'll try to contribute all of that. It won't just be writing a spec. It'll be contributing a feature that goes with it. >> Yeah, that'd be great. >> Um Sam, while we have an opportunity, I want to talk about one concept that um I wrestled with in um the PR thus far. the PR that I wrote against the AC/DC spec thus far. >> Okay. >> It came out of um uh uh you'll laugh a dumb conversation I was having with an AI. The AI said, "Well, this is a a joint issuance is completely useless because you have a circularity problem." And I said, "What do you mean?" And the AI said, well, you know, if you have to issue uh a dossier and you use pending status or basically meta data uh AC/DC's uh as placeholders in slots where um somebody will eventually endorse something. So let's go to your Supreme Court use case. Um, when you first create an AC/DC, you a a dossier AC/DC, you say, um, you know, here's the the pending decision of the court. And now, um, we have, uh, I'll take your number, five justices that have to vote on it. So you create an AC/DC um that has five metadata um edges where each of those edges is in pending status waiting for um one of the contributors to make their endorsement or their decline decision. Um and you can setify that. But the endorsement AC/DC uh says that it has to have an edge back to the thing that you're endorsing and that edge has to be a said. So um you have this circularity problem where you have edges that have to point back to um the original AC/DC. How do you solve that problem? Does that [clears throat] make sense? In essence, it's the placeholders have to point back to something by said, and the thing that they're pointing back to is um uh not setifiable until you know what the placeholders contain. So, you've got two >> two ACDCs that you know is a circularity problem. Yeah. So, I'm not I'm not I'm not quite sure I'm pictur picture picturing the the uh because I'm not I'm not I I guess you'd have to show me the example. So, one of the things one one of the things that that gets that sometimes the AI gets confused about is that um I if is that you have a you might have two different points in time. And so >> yes, that was this was what it >> so so the fe the feedback loop is is not is not continuous time. It's discrete time. And so you can point to something at time equals K at time k + one and and they're not and it's not it's not circular because they're because one one one was in an earlier state and the other one was at a latter state. So there's so so they so it still works. Um >> yes, this is what I essentially told it. It comes down to this section of the spec as it's currently written. Um when you write um the dossier and you say, you know, we're going to be embodying a Supreme Court decision here. Um when you first create it, um you have all the endorsements are in a pending status. >> Yeah. It's the meta ACDC. A meta ACDC is a different AC/DC has a different set, >> right? And when you and when and so and so you're you're pointing to the meta one, but then when when it gets issued, you will everything gets updated to new sets at at the at the the point because you're they're placeholders, >> right? >> So it's not circular. >> That's right. That's right. But I I this is a something I wanted the community to hear. I think it's a a good point. So, the way that you issue a dossier is kind of in a series of snapshots. Um, if you're doing joint issuance, that is, you don't have to do joint issuance with dossas, by the way. Like, if you're an investigative reporter or an academic and you're just building a dossier of all your research, you can just do it and and in one go, you just issue the whole thing. But um if you're doing something like the Supreme Court use case then what you do is you create a dossier where all the edges um are meta ACDC's and those meta ACDC's um just represent the possibility of a decision from party X and they're in a pending status. Then as the decisions actually accumulate, they accumulate in the form of justice one issuing an endorsement AC/DC, um, adjustment two, justice 2 issuing a decline ACDC and so forth. And so these meta ACDCs are replaced with concrete ones, uh, concrete status. And each time one of these decisions gets recorded, or if you wanted, you could record three at once or whatever. You don't have to do it one at a time, but each time there's a progression in the status of the AC/DC, you issue a new snapshot of the AC/DC that says, um, you know, this one points back to that old one, but this one now has new state in it because um, you know, slots two and three now have endorsements in them. >> Yeah. And that's why I use the example of discrete time. The the dossier itself is a discrete time state system. So it's a discrete event system. At time k equals 0, everything is pending. Everything's a metadata acdc. All the sets are essentially replaceable. And then at K equals 1, one of the one of the decisions come in and now you have a different state with with the the the origin set is different. And then at K equals 2, K equals 3. And so so the state evolution of the dossier can be mapped precisely because each time you change some some attribute in this in the in the graph, you get diff different sets. Yeah. >> Um that's just a different I just think of things that way because I'm a control engineer, right? So I think of discrete, you know, but you have a feedback loop, right? That's always the problem in discrete time is that you have a feedback loop. And the way feedback works is that is that um the output at K + one is a function of the inputs at K and the state at K minus one. Right? So, so, so you're you're you're you know, you you have three different times that you're tracking to do a feedback loop. >> Yeah. [clears throat] Okay. Well, um I think that's enough uh time uh focused on the dossas. Uh like I said, I'd be grateful of anybody's uh feedback on these PRs. Um if I don't get feedback, I'll probably merge um uh after about a week. Um uh but I would like I would prefer it if I got some feedback especially on my PRs on cores I'm already pretty confident but um so >> yeah I'll try to look at those. >> Okay thanks everybody. Um over to you Kent. >> Great. Thanks Daniel. I will jump in quickly to the did webs portion. It's actually going to be quite short as there were no no work was done on the spec or the implementation since last time. So I'll show the seven items that I summarized from your comments, Sam, so everybody knows what be done next and then if we want to talk over them, we can or we can just give everybody a bunch of time back. So I'll share my screen here. >> Oh, Daniel, will you unshare? >> I'm trying to find the unshare button. I have the share button, but the unshare doesn't let me do anything except share again. And what what's the deal? >> Um, sometimes that happens. You have to find the there's an upper menu bar on one of your screens and then you find that and it says stop share there. I I know the exact problem. You're like, I want to stop sharing. >> I think it's on the this the screen that's being shared, I think, is where the control is not. >> It's usually that control. And it's a like it's a poppy down thing. >> Yeah. Sometimes you have to hit escape to show. Well, I tell you what. I'm just going to close my browser. That ought to um that ought to make it stop sharing. Right. >> There we go. >> It did. There we go. >> One of the reasons why I like Zoom is because you can do this. You can share just a portion of the screen. All right. So, we went through today is September 15th. We just finished the dossier spec section. I will actually mention the antitrust policy notice and I should ask a question. I'll actually say this before the dossier meeting if you want me to Daniel but I didn't think that I didn't know whether or not we had actually pulled that into the car sweet working group. Have we actually made a task force for dossier spec? >> Yes and um the the URL for it is a KSWG URL also. Um, so yes, it's it's all official and hopefully all of that conversation felt antirust aligned. [laughter] >> Usually does. >> Yeah, we did that some time ago. >> Yeah, I'll mention this then at the beginning before I hand it over next time. So, just as a reminder for everybody here, attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of the trust overIP Foundation who have signed the necessary agreements are permitted to participate in this activity beyond an observer role. So anybody is welcome to observe. If you'd like to participate substantively, you need to be a to member. All right. And so we had the dossier spec discussion from Daniel. Thank you. We've got a bunch of PRs that are essentially going to be merged in in a week or two if there are no comments. And so we'll move on to the the data web portion. So we have some open action items from last time. I'll quickly read through those and then we'll get to the announcements which there are none and then reports and discussion and we'll read the open action items at the end and move on. So the action items are I was going to address your comment Sam on version 01013 of the web spec. It what it amounts to is six corrections and one open question that we'll mention in the discussion section. So, seven overall parts and some of the work that remains to be done that has my name on it includes performing a reconciliation between the normative spec language and the Python reference implementation that did say in progress but I haven't worked on it in a month. So, I changed it from in progress to TBD. I do have some work papers that I need to get back to. I've been put on other things at Glyfe and the last little bit plus a little bit of vacation. There's a TBD with Jonathan. It says that he will report to the diff diff recommended methods working group that we are ready to resume the process. This is actually going to be just delayed. I'm going to say delay dash on this because that's waiting for everything else. I'll go ahead and put this at the bottom of our open items list because that's going to be essentially the last thing that we do. All right. And one other thing that's for me is I know Carly brought this up. I have not yet taken a look. So it's still open. So Kent will take a quick look at the trust task framework to see how dead webs might be leveraged for this. Have not had time to get to anything on dead web the last month other than a little bit of the spec reconciliation. So we'll just jump right into reports. So the spec was reviewed by SAM and those review comments need to be factored into the spec. That's where we were last month where we're essentially in the same state today. the implementation and the spec have not had any changes since the last meeting. And so what I'll do is I'll quickly review any uh the the seven changes. Well, there's six corrections and then one open question. So that's why I'm saying seven items. And if anybody has any questions about them, we can discuss them here. Otherwise, we will be done in just a couple of minutes after I'm done reading the list. Okay. Anything before I jump into the list from anybody? Great. I'll jump right into it. All right. So, the review comments and Sam, feel free to stop me or correct me if anything sounds off. One of them was we need to add a explanation of the interoperability bridge as an informative section. Another one was to correct the direct mode and indirect mode descriptions. Let me pull this up to the center of the screen. Third, expand the permitted aid syntax and correct the associated explanatory claims. So the spec currently says that the aid always equals the said which requires every aid to be derived from its inception event. But it actually there are other cases we need to account for including inception event beds with transferable aids, public key derived non-transferable aids and public key derived transferable aids. And we didn't explicitly call each of these out in the spec. We need to do that. >> Yeah. you you have a you you have a um a bo a BNR form for for the aid and and so it's not it's incomplete. So >> so that's what I was calling out. You can you can say and that's that's one of the things I said you could decide that for did webs you're not allowing the other forms but I'm I don't I think there are use cases where you would want the other forms like like if you wanted to emulate did peer then you would want to use um non-transferable aids public key derived non-transferable aids or public key derived transferable aids which are more like did peer constructs but um so so they're not the main use case but um but but you but you can't say that the BNR for an aid according to Carrie is only the in uh said der said derived version of it >> right so just as a side note for me things like that were seemed like a good idea where we can emulate other digital methods with did web s because if we've got the capability and it's just a little bit more to add I think it's a really good idea to add it in just makes us look really good. So yes, we'll make sure to update the BNF form. I've got a little comment in here for that and then I have your review comments as well. Uh anything else on this line item before I move on? Okay, next one is to qualify the rule for divergent carry event streams. Divergent streams should only be considered invalid until a recovery rotation unambiguously reconciles or removes the duplicity. Right now the spec uh the datab spec is a little bit too conservative and it says that they are it declares them invalid and does not if they diverge and does not mention the recovery exception. So we need to clarify that in the event of duplicity a a did web s did can actually become workable again or usable once duplicity is reconciled. We need a deactivation path for non-ransferable aids. We didn't explicitly call that out. The existing did websp spec is favors transferable aids. We need to be explicit about non-transferable aids and this is one of those instances. So we also need an informative W3C VC usage example and I've built those. So I should be able to add that in rather rather straightforwardly. Then there was an open question. We wanted to ask whether we want to have support for complex nested fractionally weighted thresholds in the DBS spec. And right now uh this is a deficiency of the spec. This is that the this deficiency actually helped me realize that we need a proof spec as a separate spec. Right now the did web spec only supports flat weights. So we need to close the gap. I think we should close it now to where we fully support complex nested fractionally weighted thresholds. And so in my mind this question is answered in saying yes we should support complex nested fractionally weighted thresholds. Yeah. And you should you should show how to do that in in the spec [clears throat] because that's not trivial for people to infer, >> right? Yeah. So, we're that's these are essentially what I'll do is I'll say that we talked about this today. We talked about this on uh today and agreed the answer to I mean are there any dissenting voices to having this spec support complex nested fractionally weighted thresholds versus just a simple flat list. >> Okay. >> Um I don't desent. Um but I just want to note um the I would like to descent but I'm not I can't because um this is a feature of the uh aid world uh entirely and and every aid I want to have expressible in did webs. Um uh if we said no then we would um we would be making it um less expressive and did webs than uh the world it's coming from in a way that I think would be hurtful. So you know I'm in favor. Um but I think this might be something that people would complain about. So what I'm tempted to do is can we write it in such a way like we say you know go look at the uh I don't know the the appendix or something so that you can see an example of this more complicated thing so we don't um load the complexity into the body >> of the absolutely yeah I completely empathize with that. Yeah, I agree with that. We can put we can put put the put the complex examples and work through things in an appendix, you know, uh for the the the for that stuff just so but that's why that's why I suggested adding the informative sections because people reading did webs a lot of them are reading it because we're telling them look you don't you have a you have a bridge between the simple did web world and the carry world and they they they want to read the spec to to see what that bridge looks like, >> right? >> And they're going to and they're going to get frustrated and lose interest if they if all of a sudden as they're reading the spec they're having to understand Carrie too much. Right. Right. So So the so so they want to be able to say, "Oh, okay. I I just do this and and I don't have to care that much and and and the did resolver will spit out a did web and and I and I'm good, right? Um so so that's the balance. The balance is understanding that a lot of people reading did websp spec are people who don't really want to know that much about Carrie. >> Yeah. See, I have two thoughts on this and one thought leans towards the people that you just mentioned, Sam, which is they don't want they want to minimize the amount of carry they're forced to ingest. And so we we probably want to have two normative sections on multiig. One where it shows you here's a a or at least two worked examples. One shows you here's a flat list. There's a simple way to do multiig with web or to represent it. the other way so that they can mentally check out or go somewhere else if they don't want to look at the complexity say here's where you do the really cool stuff which is the complex next fraction of the weighted thresholds I think we need a worked example for both maybe it makes sense >> yeah I would I would move the second worked example I would just reference it in the spec and move that to an appendix because >> okay >> bec because basically you can you you know carry is is a normative requirement for did webs so you can refer refer to you know this is in carry but you don't but but you [snorts] know but but that's only for people who you know want that complexity right you you tell people you don't need to have you don't you don't need to support that complexity right if if all you want is a single sig you know did webs it's as it's it's as simple as did key you know >> well actually I want I I I have I might differ with that statement in this regard does a did resolver Does does a verifier that's using did webs need to be able to parse and understand a complex nested fraction weight loaded threshold? And the reason why I would ask that is is that something at the bare minimum that a did resolver has to understand. I I need to think through this maybe that's just a verifier library. Maybe it's not actually a resolver problem because if you have a lot >> if you ask if you ask the resolver to verify the the the kell then it has to be able to do that. >> Yeah. And I guess that's more of a carry thing than a did webs thing. Did webs is more of a representation of it. >> Okay. >> But at some point at some point someone has to verify that the did do matches the key state and that's part of the resolver's job. >> Yeah. Yeah. And the resolver will have to do that. Yeah. Yeah. But the point is is that they don't really care what's under the hood. >> If the resolver if you have an implementation of the resolver that that that they can just download and install and they don't have to look at the details, the the point is they go, "Oh, well, I can get a did [clears throat] web did out of this." Right. >> Yeah. >> Right. and and I didn't have to write code for it because somebody already wrote a resolver that I'll just I'll just run. >> Yeah. I'm just trying to think of what consuming situation where somebody might and we don't have to belabor this point too long is if if somebody that's not a carry consumer, let's say it's a W3C consumer gets a multi-IG that has complex nested fractionally weighted thresholds and and they actually have some business requirement to parse that and understand that. I I wonder if that tips the boundary towards having to understand carry or if we can actually try to provide a whether conditional proof 2022 or something else or >> if they're a W3C person they won't touch that there won't be any application where they would ever ever want to be in a bridge to somebody who's using complence fractionally weighted multisig. It's beyond their their it's beyond all of their tooling to even contemplate what that looks like from a verification perspective. They they want the simple single SIG temporary use uh credential that h that that that the keys expire and the and the thing you expires after 30 days. That those are their use cases. >> Yeah. And so and so we need to we need to feed them something that allows them to to see, oh yeah, that will work. Mhm. >> Um and and as opposed to them going, "Well, you guys were intellectually dishonest because you told me that I could use did WebS, but really I have to do all of these other things to be able to use it or they're confused about all the other things that they have to use and and so they they they you know so so so part of the did websp spec in my opinion is the informative sections are basically uh uh reassuring people that yes you can you you can have a bridge from Carrie to you know to to the did web world and as long as there's a resolver out there that that that you have access to right um uh and you trust the resolver either you run it yourself or you trust somebody running it, then then you have a bridge. >> If they want to implement the resolver, then then they're going to have to then then they're going to have to dig in a little bit more. But most people aren't if if one's implemented, they're not going to implement it. So, >> yeah, I won't take too much time to brainstorm here. I believe I just came up with what seems to be to me a reasonable use case. At the very least, we need to do what you said, Phil, which is make sure that if somebody gives us a DID document that has this complex nested fractionally weighted threshold, we have to be able to verify that the DID document was deterministically generated from a Caesar stream, which is essentially what the uh existing spec says. So, we need to make sure that the very least that that did document verification works. But imagine this scenario. So you're presenting on behalf of somebody and you're forced to interoperate with W3C and you have to present from a multi-IG identifier to a W3C verifier and you are presenting on behalf of somebody. So you have signing authority and you can sign because you're anchoring something to a presentation registry. So you can sign something on behalf of the multisig. Well, they need to at the very least be able to understand, okay, I can parse the nested fractionally weighted threshold expression so that I can ascertain that you have appropriate signing authority for this credential because if it's a W3C credential, you're going to send a signature with it. So, I'll think through this as because we already have a line item here that says add an informative W3C VC usage example. So to make sure that we've actually covered the full needs of the spec, since we're going to add since we agreed to add nested fraction weighted thresholds, then we need an example at least reference from the spec or in in an appendex in an informative section that actually walks people through here's how you would verify a credential being presented by a multi-IG that has one of these complex nested fraction weighted thresholds. It >> I I don't even think it's that complicated of a use case. If anyone wants to resolve the did of the glyph root of trust, they got to be able to resolve one of these, right? >> Okay. >> Right. If you want to look at the did of the glyph of trust of trust is is a flat weighted. It's not a nested. >> Yeah, it's not nested. >> Well, it's supposed to be. It was supposed to be, I think. >> Maybe we never got there, but I thought it was supposed to be. >> Okay. >> Well, it it is weighted multisig, but it's not nested weighted multisig. We added the nested weight later. >> Regardless of that, if you look at the the work that Marcus did on this, which I thought was really good, the conditional proof 2022, uh, a condition of the condition weighted threshold can point to another condition proof 2022. So, it's really just a recursive definition based off of the nested structure and the carry thing. I don't think it's that complicated really. >> Yeah, that's that that's what it seems like. >> I mean, he has an example here of a simple fraction weighted threshold. If you just start nest, you know, just add recursion into there. all based on the nesting structure of the carry threshold. It's really not that complicated. >> It's verbose, but I think Yeah, like you say, I don't think it's that >> Well, of course, it's verbose. It's >> Well, I I agree with you, Phil. It's It's It's not that complicated, right? [laughter] Nothing in Carrie is that complicated. It's just more complicated than what W3C does. and and so their tolerance for complication is pretty is pretty shallow in my opinion. And I I don't think that that's entirely uh entirely honest when they say that, right? It's not not like that. It's not like that. A uh an art uh um an integrity proof or an RDF graph isn't extremely complicated. Yet, they don't bock at that, right? They they don't have a problem throwing that out there and saying yes, right? But they'll they'll b at simple things in carry that aren't that complicated. So, so it's a perception problem. It's it's it's not a it's not a it's a political problem. And and I'm, you know, it's almost embarrassing that we have to we have to mess with that. So, I I agree with you that it's not that complicated. It's more it's it's more the politics of of of of [clears throat] how >> I mean maybe just in the in the in the normative section underneath the existing example of a flat structure, you just put a sentence that says a more complex structure can be developed that supports the carry nested fractionally weighted thresholds because proof 2022 supports referencing other proof 2022s in their condition field and then if you want go ahead in the informative section build one out but um I think that's all you need to do. Yeah, at that point as long as we can point to the reference implementation and like an integration test that does it, that's probably enough. A note like you mentioned and then an integration test under the existing example or complex uh way scheme is possible and supported. Okay. Oh, good. Well, that's a great discussion. I think we've got everything else is somewhat clear at this point. So, thank everybody for contributing to that. That's pretty much everything we had to go over today unless there's anything from anybody else or any open questions. There's a great discussion on the fraction blade thresholds. Okay, so just to review the action items before we close out and give everybody about 8 minutes back or seven. I'm going to address your comments Sam on the version 01013 of the dead web sspec when I'm able to. There are six corrections and one open question that is now closed. So I'm going to say seven corrections. I will add a version two example to the dead web spec. And I'm going to have a carry ACDC version two. We'll per I will perform a reconciliation between normative spec language and the Python reference implementation started just in my workpapers. Jonathan will report to the diff recommended DID methods when we're ready that a working group that we are ready to resume the process. So I'm going to go ahead and put this delayed at the bottom again like we did earlier and I will take a quick look at the trust test framework to see how data web might be leveraged. Those are all the open items. Are there any is there anything we missed that anybody wants to point out? Hearing going once going twice hearing nothing we'll call this meeting over. Thank you everybody for your time and you have seven minutes back to your life. >> All right. See you the next week.