KSWG did:webs Task Force - 2026/08/18

Welcome to did web s everybody did webs and dossca I should Hey, Kent, have you talked to Jonathan? Has he come in today? >> Haven't heard from him in the last day or two, but what he did say is that we finished the current draft of the spec. So, but I haven't heard from him. No, not in the last day or so. >> Okay. I'm going to So, I promised to review the spec last week and I did and I but I reviewed it yesterday morning when GitHub was um had [snorts] an outage. >> So, I I emailed him my comments. I should have copied you. So, I'm going to send you a copy of of my review. Let's see if I can find it the email. I appreciate it. >> If he's not going to be here and he may have not seen that. Let's see if I can find There it is. >> All right. I just send them to you. >> Great. Thank you. So you Daniel, would you like us to hand it over to you as we have been doing? >> Sure. Um it'll be relatively fast. We had um a nice pull request from um from Hank uh against the um dossier spec and um that's now been merged. Um this was uh about 10 days ago Hank raised this poll request. Um other than that the other thing that's happened on the dossier spec side is I actually started trying to implement the dossier spec. uh like the the two operators though well there's four operators but the two that are the most interesting ones and um uh it was a good exercise for me but I failed initially because there were a couple of questions that this raised um that I didn't know the answer to. So uh I immediately realized that I'd uh speculated about features in the uh operators that I didn't quite know how they were uh going to be implemented. So implementation uh you know they say no design survives a tangle with implementation or or with the real world or whatever they say. Um that's been my experience the last few days. Um the um spec itself has been at version 0.6 six for quite a long time. Um I think with Hank's PR I probably should have [clears throat] incremented it a little bit. Um it was nice and I think Hank's still planning to do more. Um and then I think the implementation will push it to maybe a 0.8 um if we actually have code that we know that works that demonstrates everything that's in the spec. Um, one of the things that I've seen in the spec um, stuff in all the other ones is worked examples. And so that's going to be my next priority is worked examples of dossas that will tell me whether the implementation's actually doing the right things. Um, if anybody has any opinions about which specific dossas would be good worked examples, I would be glad to hear that. Um, that's really about everything to say about the dossier spec at this point, I think. Um, unless others have comments or questions. >> Yeah, I do. So, is Hank's PR to this subsense or the body of the dossier spec? kind of show what was the what were the changes? >> Um he um well let's actually pull it up and look at it. Um he changed uh a little bit about um how the terminology was hooked up. Um he rewrote some um paragraphs that he felt were confusing. Um mostly it was editorial stuff. Um, just a minute. Pulling it up here. Trust over IP Ky specification. Okay. Share my screen. Um, okay. And this is the one. So, this index.html HTML is just regen stuff, but um it still shows the you know he's he's editing uh what's the challenge in aggregating verifiable evidence. He liked that title better here. He's um you know adding words. So these are uh hand adding a better handling of the term temporal pinning. It's just a bunch of kind of editorial things um to make things more clear. Um one of the things he did is he added a place where the I had had an abstract but it wasn't showing up in the right place in the document. So he moved it um and made it show up in the right place. Um, it was largely stuff that he he told me he felt like the spec um was a little bit confusing, so he was trying to make it clearer. >> Got it. >> I just arrived. Daniel, >> you just barely got here. would um we were uh people were asking about your uh poll request which uh I merged a couple of days ago. So um I was explaining that it was editorial mostly that you had changed stuff to be >> y >> to read clearer. Anything else you want to say about it? >> Yeah, that I I I'm still I was still struggling with the the comments that I had in general on the doi spec. Um, and I I merged them into a a branch on my personal GitHub username um where you can read the comments, but I will also add them to uh as a comment to the PR which we uh discussed last week, but I haven't implemented that yet. >> That's the only thing I wanted to add. >> Okay. Um, overall I feel like the dossier spec um is making steady forward progress. Um, but it's not getting a lot of um people to participate. Um, that's not necessarily terrible. It's a little bit of a specialized topic, but um it'd [clears throat] be great if anybody um really wanted to um play with it. But I think what [clears throat] I'm hoping is that if I raise the PR with operators um now that we have a uh 2.1 um place to put it against Carry Pi and um I kind of talk about what I learned from the implementation and make it available to people that people will have more fun and get more engaged. um once there's code that they can play with. >> Cool. Yeah, I would love to play around with that. That'll be pretty fun. So, anything else you want to cover as far as the dossier spec? Say we're good to move to the next part. >> I'll say one other thing that um is relevant here. Um Nico's on this call. I've been doing some work for Nico on a different topic, but it's actually connected to the dossier stuff a little bit. Um, and I don't want to steal Nico's thunder by jumping into it in detail, but um, basically uh, [clears throat] governance that's um, really robust where the the governance is actually provable. um you can ask whether a particular action um is supported by the governance rules that you have and stuff and all of it is anchored in the kell. Um and um this relates to uh the dossier in certain ways. Uh like I said, I don't want to drag the conversation uh too deeply into that topic right now, but I'm just really excited about it. I think it would provide a way for Car's superpower of um verifiability and uh verifiability specifically against keystate to um deliver value on the governance front as well. Um, Nico, do you want to say any more about that or I I this isn't the meeting to go into it in detail, but I I can't resist saying how cool it is. >> No, no, it's uh it's great. Um I appreciate you um you broaching it. I also don't want to distract um and the intention is to build on um precedent set by the Kerry space, including of course the verifiable dossier. So it it is um it is related. Uh I think uh yeah the the sort of um you know working working with type seals and the ability to actually um um embed these sort of um bilateral channels of of governance which doesn't actually need to phone home is something that um is really I think it's a really cool notion. Um I think it's going to appeal to a lot of different um types of organizations and uh and really once it's more mature I would love to start discussing um what it looks like to extend the verifiable domain of keystate beyond just uh vanilla carry pie. So can I ask a question? If you're using type seals then um for interoperability sake those types need to be defined someplace and publish so that um uh everybody's using the same types for the same types. >> Yeah absolutely that's the intention. I I think we're just kind of proving um the the vi of the of the architecture. Um but 100% the goal is for this to be I don't know if Daniel made this clear. Um the goal is for this to be open open source. >> Yeah. So so but are using the types as types of algorithms because that's what they're meant for. Uh if you use them for types of seals as in the semantic of the seal then that would be a misuse of the type. Well, well, I was thinking in in terms of like encoding um evaluatable predicate sets uh with type seals. So, I guess you can construct algorithms um relative to you can break it down I think atomically or or compos. >> Okay. Yeah, we may we may have a discussion about that because the the intent is is that the the type is the algorithm by which you generate the hash >> is in the seal, not h not the semantics of what the seal represents. >> Is is that what you intend to represent more in the our field? Well, if you read the spec on the if you read the documentation, it's not a lot on the type seal is that right now we have like a seal that is for um uh Merkel trees, but we don't specify the Merkel tree algorithm. There are there are uh dozens of Merkel tree algorithms. And so so uh the problem is is is that that is not enough specificity to say it's a Merkel root. Everybody would have to agree what type of Merkel tree it was. So, so the type seal would then allow you to say, "Oh, this this anchor is generated using this algorithm. Is it a is it a trillion tacera or is it a uh a new you know there's dozens of sparse Merkel tree algorithms, right? So, so you would be able to say here's all the different you just for Merkel trees. There are other ways that you can generate a cryptographic commitment that is a hashlike, right? There's dozens of of uh blockchain like structures that people develop. There's even a a new RFC in IETF for a a a hashlike data structure. I mean, every every cryptographically verifiable data structure has an algorithm that that has some sort of cryptographic commitment that you could anchor. And so the the that's what a type seal is meant for is so that we know how to cryptographically verify the seal, not that we're we're putting type putting semantics in the kell starts to leak um correlatable information in in a in a in a way that we have that we have assidiously avoided in the past. Right? You put the anchors in the kel, not the semantics. the semantics or when you disclose what the anchor is anchoring, then you say, well, it's meant to do this and it's meant to do that. So, I >> that's that that's extremely informative. Um, and I and forgive me because this sort of construction um Daniel's helping me refine previously was using um type seals um and now that I know what it is, it will most certainly be not type seals for that function. >> [clears throat] >> I think we are actually using the anchor field to actually um um um embed these sort of evaluation statements. So I think we've avoided that. But now that I know what a type seal is actually meant for that's really useful. Thank you. >> Yes. Yeah. We just haven't discussed it at length and then when I heard that you were use when you just mentioned that you were using it then it triggered my >> Anyway, I hope that >> useful. Thank you. didn't cause too much uh uh conrnation anyway. >> But that's interesting that this interesting applications be interested to see when you guys publish it. >> Uh Kent, um I'll turn the microphone over to you. As I do that, I'll just mention that I just raised a PR against uh did webs spec yesterday or the day before. Um [clears throat] and uh it's because I decided to try to implement uh the did web s spec um and as soon as I got into the implementation um I ran into an interesting question. So um [clears throat] that's the genesis of the PR that I raised against web s >> against the result the implementation or the spec >> the spec. >> Okay I'm not seeing the pull request for some reason. >> Um I thought it was against this. Maybe it's okay. Maybe um okay it had to do with the um - fab um >> I do see a issue 212 the worked examples AC/DC proof uses an attachment that no imple verifies >> that's that's it I it wasn't a yeah it wasn't a PR sorry it was a qu I I I thought about raising a PR and then I decided no I better just ask a question first that's what it was >> gotcha okay all right what I'll do then is I'll go ahead and pull that up. We can start from there and I guess just show everyone knows what we're talking about and then we'll jump over to the regular agenda. So we'll come back to this. This is a good question. Okay. So this is part of the Linux Foundation the trust over IP and so there's an antitrust notice that attendees have to adhere to the meeting agenda and not participate in activities that are prohibited under the current site governance framework using typed seals and other things that are probably probably being prematurely disclosed. No, I'm just I'm just kidding, Nico. I'm just trying to make sure I understand what's being done here from a governance perspective and since it was committed to in the kel that we can understand. All right. So, as far as announcements or reports, okay, this is actually the copy from the last time the reports. Did did I I think I put it down here. Oh, that was the dossier spec discussion. Sorry, I need I need to jump to the dead web s section. We do have some action items from last time. I did review the big pull request 209 that was Jonathan's Jonathan's revision to the spec and two main parts were added I'll talk about in the implementation now needs to catch up with the spec report. So we did review that we we got that merged there's an in progress reconciliation of the normative spec language and the Python reference implementation. There are a couple of things that the the D did webs implementation does not yet do and I'll get to that in the report down below. So Jonathan is waiting on the final approval of the by by you Sam and you Phil of the spec language prior to us >> sending this to the did methods working group and then once once we've got that in I I did get your email Sam and so >> okay yeah so so I think the spec needs some changes uh we can go over them if you'd like in this Um >> yeah yeah yeah I'll we'll make that'll be our first discussion point. Okay, >> needed spec changes. And then the last action item from last time is that I will take a quick look at the trust task framework to see how did webs might be leveraged for this. Did not do that yet. So that one's still open. So I'll leave these two open. I guess these three. There's the I did start the analysis on making sure everything that's new in the spec or that's been implemented has a we have an inventory of it and we have open issues for it. So that's that's in progress. So now what we'll the we'll move these three forward to action items for this meeting and then we'll see if we add any more based on our discussion. Okay. So announcements, we're now in the final review phase for did webs and once we get through this final review phase for the spec then we'll be moving forward in the diff recommended in methods process and part of what will come out of this final review phase will also be some updates to the implementation. And I think if there's anything else that we should probably announce, we're going to break the connection in our repository to the upstream repository which for a time we had in the Hyperledger Labs GitHub organization, we had a did webs repository. I don't exactly recall what the rationale was for moving it there, but essent the the upstream repo has been archived for a while and we got the all cleared to sort of un unhook the the glyife it fork right now is going to become the new upstream and so that will be likely done between now and the next did web s meeting >> just for posterity it was in hyperledger because that's where Steven Curran wanted the implementation. Thank you, Kevin. Let me actually put that in the That's kind of fascinating. I'm going to put that in the notes. >> So, I don't think that requirement exists anymore, right? Since he's no longer part of the or uh um effort >> or does it does it matter? >> Yeah, we can pull it out as far as I can tell. Well, does anybody Well, I mean I mean the question is does anybody want it there? >> Is there a reason to keep it there? >> It hasn't actually been developed under Hyperledger and I think we asked them a long time ago to archive it but it's just confusing now when you look at the web of trust repo it says forked from and then you click on the fork from and it's an archived repo. thinks the idea is try to make the life it branch. I'm not sure why it's not web of trust either, but whatever. Um to make that the the default implementation. I can take a look at the repo and live it and see if we can break that connection. It's a feature that GitHub added. So that's it. Anybody else know a good reason why we should stay in Hyperledger Labs or ask them to unarchive the repo if we wanted to. Okay, we'll just proceed forward with that then. All right, so the quick reports and then we'll get to the discussion. As I mentioned earlier, spec is ready for final review and approval. And some of the things that were added by by the final review were things that are common to other dead methods including the authentication and the authorization key section. And that's essentially a you take the keys that are currently authorized to sign and you add them to the authorized keys and the authentication section. Now what this what fell out of that is me realizing that we need another spec and there's something a proof spec kind of like there's the data data integrity proof spec for different parts of the W3C space. So what's missing that is not in the DID web spec and that should not be in the DID web spec is a clear algorithm or mapping of when you use weighted nested multi-IG groups how you take the leaf keys and map them to leaf authorization when you're verifying things and map them to leaf author author authorization keys or authentication objects in in the DID document. So that when you're performing a verification, you can deterministically go from your authorization key to a specific multi multisig participant or a multisig key. And so because you can you can have it be pretty complicated and you can have weighted nested groups and they have different weights. Conditional proof 2022 is sufficient by itself to describe the multi-IG group, but it's not sufficient to describe the proof format. And I'm I think I'm butchering it a little bit here, but the essentially we we we conditional to proof 2022 and the did webs spec by themselves are not sufficient for what will need to be a proof spec. And so whoever runs into implementing this first. So so essentially here's what works today and what works really well. single SIG works just fine and a flat multi-IG works great with the existing uh work that we've got because if it's just a single layer conditional proof 2022 is it's pretty simple to just pull it out and use the the order the index order from what's there in the multi-IG key array to to do signature verification. where it starts to get more complicated and where we're going to need a new spec in the future is when we have the nested groups. So I'll in a in a future when I have the time to actually thoroughly describe it and give some visuals then it may be the feature did a best call I'll show what that spec could or should look like with with an initial draft but when it when it's time for this community to have a interoperable proof spec that that is for for sophisticated multisig then we will need to make things interoperable will want another spec but that does not belong in the web s spec cuz the did webspec is just for key resolution and just for a couple of other things like the the you've got the delegation service witness service the services section the the key distinction key listings and itemization and the designated aliases that's the only job of the web spec so just not noting that that's what fell out of this final review that I something was in the back of my mind as we were go revising the spec and then I finally and they realized, okay, we needed we need approved spec. So, that's what fell out of this final review and approval. And maybe something else will fall out of your review, Sam and Phil. That's that's goes beyond that or maybe it'll just be changes to the spec and the reports, the last report. Okay, so the implementation we did because we decided to add the authentication or the authorization and au authorization keys and authentication sections to the spec then we need to go in and change the implementation and add those and those won't be too hard to add. That's actually what drove the the realization for the the need for the proof spec is because I was thinking well how do we add the authorization keys in a way that's easy to map a specific authorization key in a nested weighted multi multisig group back to a specific participant in the multisig and that's what sort of show that we need another proof spec but for single sig and simple multiig we'll be okay for Anyway, that's that's everything. So, implementation needs to catch up. Spec is pretty much there. And I I if I don't think there's any other reports, Jonathan, I actually did check my Discord. He said he won't be here. Won't be able to be here today. And I don't think we have any other reports. And so, we can just jump right into the discussion. So, with the discussion, Sam, I did get your email. would do you want to just >> Yeah, I'll just review it and then if there's any any questions. Um um I yeah would have been better be be in comments, but like I said, GitHub was having an outage at the time, so I didn't want to fight with GitHub for for a couple hours and so I just finished it. Um uh uh >> do you want me to pull it up here or do you want to pull it up? >> Uh yeah, why don't you pull it up? That way I can uh you can [clears throat] >> Okay, let me increase my text size. >> Yeah. >> Okay. Is that text size? >> Well, I'm going to read from my email. You have to ask other people. It's probably not >> Okay. >> I can read it, but I don't know about other people. Every Can everybody read that? >> Yep. >> Okay. >> Yeah. Okay. So, um, I mean, you know, in general, specs great. I'm not I'm not I'm just going through some things that struck me because I basically did a I'm going to read the whole thing from start to finish and and see where it lands. And one of the things that the the the introduction goes to great length to describe why DI web s is necessary because you know the web is the web security guarantees you know are are are u problematic right there's certain things you just don't get if you if you rely solely on the web and I think that's that's a good message to to say but I I thought it might help in that narrative to explain why somebody would want to use the DID web portion of DID webs and it's primarily an interoperability um interoperability constraint and certainly in the discussions that we're having in SETI for SETI interoperability people from the other verifiable credential community in the W3C3C they would like to have an interoperability path or a bridge to carry without having to support all of Carrie and everything in all of their tooling. And so explaining how uh adding a paragraph that that that mentions that this is the reason, you know, is one of the reasons for for that u might might tell somebody when they're reading the spec, oh, this is why I should read to the end because you don't really get to the did web part of the spec till you get to the end of the spec. Um, and so that I just thought that might be helpful. Maybe not. Um, uh, in terms of technical things, the first place, uh, there's some definitions in the glossery that are that are incorrect. Uh, the definition direct mode is incorrect. Uh, direct mode, um, does not use witnesses, but it may use a kell and it says that direct mode does not use a kel. That's not true. It's just it's just that the kell has to be provided directly between the two parties or if they're both using kels that uh you know whichever party is doing that um uh the witnesses are what define indirect mode now anybody can get can get the kell without having to talk directly parties have don't have to be online that's what makes it not the not the presence of a kel um so so that that was a drift there um and then in the in the section where you defined the AB and F for um for a for an aid that is incorrect. Um aids are not limited to being the SDS of their inception events and so you only so the spec only defines aids that are SS of their inception events. There are two other forms of aids, non-transferable aids and transferable aids that are in Caesar encoded public keys. So the question is does the spec want to support those other two? I think it at least has to support non-transferable aids because witnesses use non-transferable aids. So I think that's just an oversight. Um, the third one is a a corner condition, but I think in general if it's an aid, you support all the ones that carry supports and not a subset. So, so I think that's that needs to be fixed. And I don't know how that bubbles out into the implementation, but um >> yeah, I'll we should support all those for sure. >> Yeah. Okay. And then in section 8.4 four. Um, it it has the phrase, "If the carry event streams diverge from one another, both the carry event stream and the DDS must be considered invalid." Well, that that's too strong of a statement. Um, they're invalid unless and until a recovery rotation unambiguously reconciles or removes the duplicity. And then they're then they're then the um then at le one of them is is valid not both of them right >> is there is there a way in which you can consider it pending rather than valid or invalid like under like adjudication or is that not really >> well well when there's duplicity um a verifier or a validator must not trust. That's that's how that's how the verifier protects themselves. Um and then if it sometime later gets reconciled, then they can decide to to trust at that point. But but trust is earned in this case. And and if if there's duplicity, then you stop trusting until it it's reconciled. It may never be reconciled. So you don't know that it's bending. You just know that there's duplicity. You don't know that it'll ever be fixed until it is >> right. The the reason why I ask is because uh in in our uh governance encoding mechanism, we kind of have this four-fold logic where there's an intentionally um pending uh uh period where um you can have the evidence of duplicity and kind of adjudicate the actual um adjudicate what you perceive as the canonical uh fork of a given uh uh >> Yeah. But I think but I think you're talking about a different form of duplicity. This is this is duplicity with regards to key state which is very narrowly defined. There are lots of types of duplicity and and so if you've you've got a governance mechanism that is using the dossier spec to to determine whether or not a group of loosely coordinated entities are in agreement or acting duplicitously. That's a that's a completely generalized expansive definition. >> Forgive me. Forgive me. I'm I'm taking us away from the topic. I I I apologize. >> Yeah. Okay. >> Um so that needs to be fixed. Um uh and then uh in the there's a definition in 8.6.4 on um what deactivating and um that works. defines abandoning through a rotation to null as a way to deactivate. I'm not sure how you deactivate um the the corner cases where you're using a non-transferable aid. I I mean if you're using did webs with the non-transferable aid, that's that's an abuse of why you would use did webs, but somebody could use it that way because that's a valid carry aid. And so you have to account so the spec needs to account for those corner cases and deactivation is one of those corner cases. And I'm not sure how how the spec should account for that. >> Seems like you could >> you can't deactivate a non-transferable aid. There's no deactivation mechanism because because it it's crypto period is indefinite, right? uh the the only way you you don't know that the keys have been compromised. There's no mechanism to signal that your keys have been compromised. I mean this is so so this is one of the places where you know somebody who is used to the W3C world of did methods who's used to using bare signatures where crypto period doesn't appear anywhere in any discussion on anything that they're doing but they're issuing perpetual they're issuing credentials that have lifespans of 5 years right this is where interoperability is dangerous Because somebody might say, well, the closest thing to what I'm doing with my keys or my did web method is that a non-transferable aid looks like it. And and a non-transferable aid doesn't need a cal. So I can actually be perfectly interoperable by just using did webs with non-transferable aids because now the security models match. And so while you can do that for interoperability, that should be heavily caveed that that here here's here's what happens when you do that. Now the fact of the matter is people using did webs will do that. They will use DID webs and create DID web and they will ignore all of the security caveats and they will do it because that's what interoperability need means to them and that's and and that may be desirable that that level of interoperability may be desirable because it's a temporary bridge um to allow other ecosystems to to to um hang off from uh you know like like in the case the SETI and we've had discussions on temporary use credentials. So I've got a I've got did web s that's got carryback stuff. Somebody wants to issue a temporary use credential that doesn't have any of those protections other than the the only protection is the credential has you know it's it expires within 30 days. That's the protection right so I could do that. I could issue a 30-day credential using a bear signature from my did web using the assertion, you know, public key from the current key state. And if I rotated my keys sooner than 30 days, I would be no worse off than if [snorts] they didn't use carry at all. The the fact that somebody who knew Carrie would say, "Well, wait a minute. You rotated your keys before the 30 days expired, so it shouldn't be verifiable." But from their perspective, 30 days it's verifiable regardless of your key state. It doesn't matter that you've been totally compromised. All of your keys are in the wild. That credential is still verifiable if the signature verifies against the key state when it was issued. There is no provision anywhere in any of their system to account for the fact that your crypto period may have been aborted prematurely before the 30 days. And we can't fix that. If we want to interoperate with people that have that that basis of security, which is the web, then then then it's just, you know, user beware and and and and that sort of thing is a very rare occurrence, right? 30 days is a reasonable period for a crypto period for a key to expect that it would still not be compromised, but it could be compromised like 30 seconds after you issued after you issued something. It could be compromised that fast. But likely it it doesn't get compromised for one or two years. So 30 days is a is a reasonable thing. That's why the that's why DNS is is going to a 45day crypto period. I mean uh expiration date because they understand that crypto periods are much shorter than than two years and they know that they have to move in that direction. Um which is okay. I mean that's the point of interoperability. I I I know I went on at length, but I I just wanted to explain that the point one of the main advantages did webs is to bridge this gap. And so people need to know how to use did did web with did webs with all of the bad stuff that they're going to do because that's required by interoperability because they don't care. They honestly don't care about those things. that their answer is well there's 300 million you know W3C verifiable credentials out there using did web and everybody's just trust them right so how are you guys going to interoperate with those and the answer is well we're going to allow people to use did web just that in the same way >> that's a really important case for us to consider because in in my mind I've thought about non-transferable aids as being derable from really any public key out there that's that's defined in the Caesar code tables and any any public key really could be added as it's just a single key non-transferable aid just add it to the Caesar code tables and so it's actually really important for us in the did web spec if the goal is interoperability with all those keys out there the people that care differently about security we definitely need a spec language describing how to do that right >> well and you can do it both ways you can have a transferable aid that creates a DID web at the moment that it creates the DID web. It's the current key state which means the the public key of the current key state is is your assertion method. It's the aid is still not is still transferable but but your assertion method is that public key and you and so you can issue something with that public key and sign it and then that issuance is just just like everything else that somebody issues with the did web did. >> Thank you by the way for mentioning that. I was saying the wrong thing earlier when I said authorization method it's assertion method like like you just said. >> Yeah. Yes. Yes. And I was a little bit confused when you were talking about authoration methods earlier in the discussion, but okay. So that's good. I'm glad you clarified that. Okay. Um, so so I I I went to great lengths there, but I I I I just wanted to point that out. Um, and then I guess somebody else already pointed that the fractionally weighted thresholds, the examples use the simple form, not the nested form. So I I think yeah, you need to solve the nested form. And then my final comment is that in the informative section, I think it would be helpful to show how somebody would use did web the did web portion of did webs if they come at it from the point of view of they don't have any carry infrastructure. Somebody who ha who created the did webs in order to create it has to have carry infrastructure. But let's say that users of the DID web port don't depend on the carry infrastructure. They just depend on the web. What would that look like from an example point of view? How would somebody use did web in an interoperable mode where the the constraint on them is they don't have any carry infrastructure. All they have is a DID doc that came from say a trusted a trusted uh uh um did resolver and now downstream of that it's just did web and and their only verification is what did did web gives them. They've got a public key. They can sign stuff with the public key. They can verify the signatures with the public key. What does that look like from from a user perspective? because that's how people are going to be reading the DID web spec as an interoperability bridge. So explaining what that interoperability bridge looks like will really help the adoption of did web in my opinion. >> I'd be happy to add that. We actually built one at Glyfe and >> essentially anybody who has the DID resolver libraries if they receive a credential that's being presented to them that has a subject that is a DEBS did. As long as they use the existing diff libraries for they did resolver and did VCJWT, they can verify the credential. >> Yeah. So those are my those are my comments on um Anyway, >> is that the sort of story that you you'd want in there is just sort of what I described. >> Yeah. I mean I mean Glyfe did the did the did did did did for what is it Border Patrol this um this this web VLEI right which was a way for them to use did web um without having to touch carry right >> we did build yeah we built that so that you could not have to use carry at all and yeah just be able Yeah. And and so all you do is you just caveat it and say here's all the security caveats when you do this. But if you're already using did web, you've already you've already you've already come to terms with the fact that all of those caveats are okay by you. And so you're not any worse off by using the did web portion of did webs. If at some point you decide that you want to elevate your security policy with did webs you could. Whereas with did web you can't. It's impossible. Right? So, so, so that's the story is that it's a bridge. You start out with people who don't care about security. And I use that term strongly. I know it's it it it's offensive to people if I say you don't care about security. Everybody cares about security. Um, so sorry for using strong language, but you don't care about security in the way that that that we care about security in the in the carry world. um then and you don't want the over overhead of having to support carry then what does that look like and then and then at some point hopefully they they will go well okay we need to support better security and carry is is the path to that instead of half measures like other did methods that are that implement parts of carry right um >> so that other did methods I'll I'll leave this point of sale vendor unnamed but there's a point of sale vendor whose docs I'm familiar with where in version one of their security you would transmit a private key in an HTTP header. >> Yeah, there's [laughter] >> so not everybody cares about security the same way. That's for sure. I was really surprised when I saw I had to double check I triple check their documentation like what who designed this anyway? Well, the the key compromised impersonation attack is is a thing because many uh people who thought that they were going to be more secure created um created uh custom web browsers and custom browser apps to interface with web portals. And when they publish the app, they put um the public key of the client side um certificate in the app and so that anybody that downloads the app now knows um no not the public key, the the private key is in the app. So anybody that downloads the app can find the private key and so they can then do an a key compromise impersonation attack on the secure host because the private key is in inside the app code because they they could because they they distributed the private key by distributing the app. That's how they distributed it. And and numerous private uh these are like secure file trans secure file transfer browsers that you download from a a website from a company that is selling secure file transfer versions of browsers like Safari or or Chrome. You would download a version of the browser that had the private key of the client side search in it. Huh? Just crazy. Well, with that, that's kind of a fun tangent. Would would you add anything else to the comments we've got here or have we gone over them sufficiently for today? >> That that's all that I had at the time. >> Okay, great. So, we've gone over the the needed spec changes. We'll go ahead and just move on here and feel free to stop me at any point if we if there's anything I missed. So we how do we we've got this question open question. How do we get the did webs diff recommended div methods process restarted? That's what we asked last time. Jonathan's going through that. We're going to go through the final spec process. And so what I'm going to do is I'm going to take these comments. We're going to make some changes and I'll tag you Sam. And once we get >> okay >> these approved by you then we'll just look also for your final review uh points Phil if you have any or just your your final thumbs up. And then we'll be taking the spec to to diff to the diff recommended DI method. >> Now Daniel said he had a question. Did you did you get his question answered? >> I don't think I did. Daniel, what was your question? >> Yeah, it's um issue number 212. Basically um [clears throat] the uh there's a worked example in the spec. Um and in the spec that worked example um it uh attaches the um designated aliases stuff as a - fab um uh group in the Caesar code >> and that um does not actually work. So, the worked example, and I tried this in a bunch of different pie branches to see if maybe it's because this spec was written against a version of Pi that I wasn't, you know, using or something like that. But I tried a 1.1 branch, a 1.2, a 1.3, and a 2.0 branch. None of them actually support a - FAB used the way that the specs worked example says. So um my best guess is that um this particular example was written a while back and was using the Caesar proof signatures um credential export stuff. Um, but uh I think what we need to do is either change the worked example in the spec to use some other uh prefix code or um we're going to need to go back and and change carry pie's behavior so that you can actually use what the worked example claims you can use. >> Yeah. Well, what we'll do is I'll just make a unit or integration test that actually generates valid Caesar. And if whatever carry pie generates today, that's what we should have in the spec instead of something old. And if I mean, thanks for catching that. I I definitely haven't caught that. So, I I didn't try to validate all of the Caesar myself. We went through a revision a couple months back where we were trying to add annotated Caesar to everything, but then we we decided to revert that. And I think we were probably going to overwrite this old stuff, but since it's there now, we just got to go fix it. And I think the best way to do it is just to have an integration test that always generates valid Caesar and verifies that the spec has only valid contents. >> Okay. Um, the other thing that kind of came up as I was writing this particular thing down is um, you know, I I went and tried all these different pie branches because it wasn't clear to me what our intentions were with respect to the specific version of carry pie that this spec targets. Um, uh, I think we're intending for this to be like a 1.2 1.3 um, version of pi that this spec targets. Is that accurate? >> Yeah. I mean, we we we want it to be able to work with main, but essentially what I've got. You've got >> It's not going to It's not going to work with main with your worked examples. You have to pick one or the other. >> Oh, okay. Or you'll have to add work examples for >> Yeah. >> for the two different versions. So I think you're better off to to start with the version one maybe 1.3 branch. >> Yeah. >> Um because that's version one of the group codes and the primitives don't change but the group codes are what are changed and so the serialization formats you can only you can't serialize in Caesar in version one. You can serialize in Caesar in version two. So you may want to start the spec with the version one stuff and then upgrade the spec to version two. The point is is to get it get the spec through the process the first time around and then and then restart the process because we don't have full support for all the version stuff for all the version two stuff in carry pi yet. So I you know so you would run into a problem of delaying the spec till all that's done and that would be I think that would be a delay you don't want to take right now. So I think you should target like the version one the version one ver of the specs I mean of of carry pie which is the pre version one of of like the group codes. Um the [clears throat] the trick with that Sam is that um we've got code for SETI that um needs the 2.x generation of >> um >> yeah so so we'll have to we'll have to do that. >> Yeah. I don't know. I don't know. May may I Yeah. I don't know how to I don't You're right. I mean, if you want to delay the spec and do all that, but then that delays the did webs spec until till till that stuff is done. >> Um, let's let's say that it's not a question of timing the spec. We just do whatever's pragmatic. But my practical question is um if we're going to be doing a demo at uh you know the SETI conference in November and we want to have [clears throat] um working uh guardianship examples and all these other cool things from uh that require uh you know bulk issuance and and uh aggregate support and whatever. And at the same time, we want to show interoperability and we want to use did web s. How do we uh do that from a coding perspective, not from a spec perspective? Cuz I think it'd be fine to, you know, have a spec that uh was in flux a little bit or whatever, but but I don't know how to solve it from a code perspective. Well, what I would suggest is that is that we um is that the code that supports the did WebS method get versioned so that you can release a uh a code version with the working examples that that is labeled as version one and then you can then you then you version the DID web spec and and then that new version the spec has worked. worked examples with the new code that is in development, but it doesn't slow it doesn't slow the review and release of the the original did web spec. >> I see. Okay. >> Well, if we want to just minimize the scope here, it's really the difference in AC/DC that is going to be the primary difference. And that's even it's the >> No, that's not the primary difference. the pime the the the the AC/DC difference is actually a minimal difference. The the the big difference in the work example is the group codes in Caesar. Those those are not backwardly compatible. So if you're doing a worked example of a Caesar stream, then you're going to have group codes that are that don't that don't map between the two versions. >> Yeah. And um >> there is a there there are some minor differences in the AC/DC, but it's it's like one field. >> Yeah. Well, what I'm getting at is that we don't get into so from the Caesar perspective, that's entirely accurate. We don't get to that level of description in the in the did WebSpec itself. [snorts] In the worked examples, we do. And we definitely need to have worked examples for version one and version two. And what I'm what I'm getting at here is that there's it's probably going to be easier than we're we're talking right now because it's yes, there are changes, >> yet the usage of those group codes and the usage of AC/DC is for the self-issued AC/DC's, it's it's not terribly complicated. And so it pro probably could be easier than we're thinking. Yeah, you you could implement all the worked examples with version two of the specs without waiting for all of the changes to Carry Pi because you can manually create those with the code that's currently in Carry Pi, but you just have to you just have to do the leg work to do that. >> Yeah, what I'll do is I'll add this as a comment here and >> but the worked examples are an informative part of the spec anyway. So you could you could you know h have an have an informative you uh you could either decide that you're going to delay the spec moving forward until you get those working examples done and then you put them in the spec. Or you can fix the the things in the spec and leave just the version one working examples and then start the spec moving forward because the version two work worked examples are informative. You could add that later as an informative section in the in the spec or in a version of the spec. I I I just I'm I'm trying to be sensitive to the fact that there are time delays that happen because you have waiting periods for the spec to move forward and if you so so those waiting periods then start to you know do things like uh you know delay you from getting the spec to a certain point and maybe that doesn't matter. What if we um released the spec only with a thing that said for worked examples go see the following uh location and then the worked examples were moved out of the spec entirely. Is that uh too radical of a move? >> No, I don't I don't think so. They're forbiddive, so they don't have to be in the spec. >> I like that. Go ahead. >> Uh, people don't like it in general because if they download the spec, then they have to go to some other repo to go look them up. But I don't think that's a but I think people who don't like that aren't, you know, that's not a requirement. That's just some people don't like it. Um, but if you if you really do a good job, what tends to happen, and the reason they don't like it is it tends to happen that when people decide to move the informative examples outside the spec, they tend not to get supported because if they're in the spec, then lots of lots of eyes look at them and people go, "This doesn't work, that doesn't work." Right? And so it gets it gets attention that it wouldn't get when it's outside the spec because what what often happens, you move it outside the spec and then nobody works on it. And then it's sitting there, you know, six months later and people are reading the spec and they go, "Well, where are your worked examples?" And everybody says, "Oh, well, we moved them here, but we never got around to finishing them or supporting them or making them work well." And so it's it's more a laziness enforcement mechanism to put them in the spec because the spec can't get released unless you do it. So it makes a hard requirement to do it. So, if you have the discipline that says you're going to do the worked examples and you have the resources to make sure they're happen, then nobody's going to complain. If the worked examples are done, you know, at [clears throat] the same time that the spec is, >> I like the idea of keeping them in the spec because some a great engineer told me a number of years ago that that which is not automatically enforced tends to degrade. I like and and to me it's we've got a full example section here. We could say there's version one and then have version two just have it be in the spec. I like the idea of separating it too, Daniel, but if I had to think of the tradeoffs. It seems safer to keep it in. >> That's fine. I wasn't really advocating. I was just speculating. >> Mhm. [clears throat] Yeah, it would make the specs shorter and easier to review if they were taken out, but keeping them in does force us to have more discipline. So, what I what I'll do then is I'll just start it as a version two part in this in the spec here. We'll have a full example for version one and a full example for version two. Even if some of the ver version two stuff hasn't fully settled, which I I think it already has, but I'll just put in there what we currently have and then we can review that and see what we think. Is there anything else we should add before we close? I know I know it's 4 minutes over already and there's a carry set foundation setup call after this. If there's nothing else, just last call. I'll add one more action item. I'll let everybody go and then I'll write an action item here for me to respond to this. So, I already made a comment here, Daniel. I'll I'll put a response here and I will put a action item for me to add the version two worked example. >> Great. >> That's all for me. Anything from anybody else? All right. Have a good day.