 Welcome folks to the first meeting in September, the September 6th meeting in 2023 for the Aries Working Group. This is a hyperlegical, so the antitrust policy and the code of conduct are in effect. And please be mindful of those and please bring up any issues that you detect that need to be solved if no one else does. The link is in the chat and you're welcome to make any adjustments to the agenda. Add yourself the attendees list or any other changes that are useful for the community. Is there anyone that knew here today that would like to introduce themselves, but we're glad you're here announcements did come uses group is a second, third and fourth Monday. And so this next Monday will be that and there's the link to the schedule with the meeting notes there. And note about did web s Steven is this need to be carried or should we drop it for now since it's been on a couple weeks. Sorry. Let's see. Did web s. Yeah, no, I was just reading the note repo is still there I just, I can announce that we now have a hyperledger labs for an implementation of it. And work proceeds on a weekly basis towards a first release. Cool. So anyone interested can contact me so leave it for today and then we'll group next time. Okay. Indy summit is tomorrow. Yeah, register there. There's the times there'll be all sorts of discussions about all things Indy. Please join if you have an interest in Indy. And October 10th and 12th is IIW. That is next month a little over a month away and please consider that if you are able that's a fantastic place for ongoing conversation on a wide variety of identity related topics. And then one more. The hyper ledger member summit is October 23rd in San Francisco and Tokyo. Yeah, one or the other, don't go to both. Yes. Are you going to be, are you going to be doing that live a jet across to both things, Stephen? Perhaps not. Stephen's going to virtually attend both from somewhere. I'm teasing. I don't even know if I'm attending either maybe. Excellent. Other announcements that we should have an list but don't any projects want to share release status or work updates. There is lots of work going on. Appreciate all of that. And for those new here, there are a variety of sub meetings. For various types of projects for rust and for acupy and for FJ and bifold. There's all sorts of meetings going on. And so this is only sort of the main one where we kind of discuss main topics, but all of the specific code based oriented meetings exist elsewhere. Just to help you be aware of that. We should definitely kill this. You go through here and update periodically. Okay. On the list for discussion topics, a quick marketing update by Alex. A discussion of where we are on unqualified dids and the path to get there. Stephen has some topics are push notification. I would like to talk about did comfy to, and I'll highlight that issue 717 came up and was requested for some meeting time. And that is also on the list for today and for discussion. As part of the unqualified dids transition because of its effect on debt exchange. That is what we have for the agenda. Are there any changes we should be making addition subtractions substitutions. I would say you should flop, flip the did common push notifications, put that together with the unqualified. Yeah, we'll do other changes. All right, Alex you warned us it would be brief. Oh, first announcement. There's a new calendar. There's a new meeting link. This is done periodically. Sean probably has detailed reasons, but there's reasons hyper ledger manages the, the community rooms and it's helpful to have them not collide with each other. We have been using a different link and there is a new link. So if you have, like me, copied the working group call from the hyper ledger calendar to your own. Then please go delete your copy and recopy. And that way you have the new meeting link. And please spread the word. We'll try to be sensitive to that in the next couple of times to tell people find the meeting again. If they, if they followed that same pattern also someone wants to fix that calendaring sync problem for all of the universe would all be grateful things. So that that meeting new links. I should add it here. In case someone reads the notes. Awesome. Alex brief update on marketing. Thank you. We take up the most page basements in the discussion topics and we got the least to say. So 30 seconds, a colleague never showed a work week in North Americans and the high priority stuff means these are the same items from last week. But to what you said Sam subgroups we have the areas marketing working group last Tuesday of every month everyone's welcome to come to that. And if you're interested in exploring more the items are there on the page. I won't take your time now. If you have any feedback, please reach out to handle myself. Thanks Alex appreciate that. Unqualified did this has been a topic over the last couple of weeks for good reason it's it's something that is acting as a blocker for for progress and that we need to just retire as all behavior in the community that we're not doing anymore. I wanted to, to kind of review just briefly what we had talked about previously. And I probably should have left the meeting links and when I summarize, but there's a this is landed into a couple of things. We had discussed previous methods of how to translate dids and appear dids and a handful of other things. And we found our way to a, we believe a cleaner solution. And that is the introduction of the did rotation protocol. Steven I saw your comments but not fast enough to get them edited in today. Here is. Here is that that PR and areas RFCs. And, and I've incorporated some feedback but Steven, not yours yet. What this does is it adds did rotation into did com V1 did com V2 already has this, but we're finding it incredibly useful for a couple of things, including not only solving the unqualified did issue, but also to, because you can notify the other party that you're using a fully qualified did, but also a transition to did com V2, which we'll talk about in a minute. And that is there also worked by Daniel bloom for did peer for. And this was, we covered this last time the goal of did peer for or the sort of the realization was that the combination of did peer two and three was both lossy in the types of information that you could record. So the approach of having a long and a short form, which is an idea similar to what has been done in did I on or the other side tree stuff was a really was a really much simpler way to solve this particular problem in the sense that you can pass more or less a did doc encoded as part of the long form and have a short form that then is more efficient, you know, to include in every message. And then the combination of these two mean that it's pretty easy to rotate away from these unqualified dids, because you can simply include the relevant keys that you're using in a did document, pass a did rotation message. And now those aren't in use anymore for that particular relationship and we have a way to move forward. We, that's a really brief overview. We didn't have enough time, sufficient time for for full questions. Last week against what we talked about. And so I wanted to make sure we had enough air time to to answer any questions or concerns, particularly if folks think this is a bad idea we really need to hear it. Now, given that we had that so hopefully you've had a chance to review the call from last week and or everything else but if you have any questions. Please ask them now about did rotation and did peer for as as advancements that that helps solve specific problems. Timo's comment in on the PR seems to be the most serious issue it sounds like Daniel responded that it's not really a concern but I would. Wouldn't mind getting your view on that I don't think it's a problem but having someone like Timo suggest it's a serious security issue. Is this in. Is this in did peer for I saw it in email shoot. It had to do with the, that he's thinking this means we we transition from key based. We wouldn't be shoot. I don't know what it is, but it basically was implying that you wouldn't have to have the private key in order to take over a, a. You can just issue a did without having the private key and approving ownership of the private key. Yeah. Oh, maybe that was in here. Shoot. No, wasn't that one shoot. I'm sorry. There's a Timo comment. Maybe go to I'm going to search my emails, my trash to see where where that was but I believe the issues addressed I just wanted to make sure people weren't thinking that it was troublesome. Okay. Sorry about that. No, that's fine. I'm going to. I'm going to relink this, I probably should not have dropped a link when I when I brought it over here. This is for did pure for. And here's the did rotate protocol be given how important these are definitely some attention, particularly if you're an implementer or but everyone having eyes on this is a good idea. And while Stevens briefly searching his email for that. The fourth item here. There is a community coordinated update to solve the unqualified dense. It describes the pattern using the old approaches that we were going to use. And so, one of the our steps to completion here is, is, is to have me update that community coordinated update to reflect the new strategy. So that after these are created, we can use the community coordinated update mechanism that we have in order to kind of keep track of where we are as a community on the adoption of this. And that way we can, we know when we're ready to take steps beyond. The implementation protocol is, is fairly simple and did pure for is also pretty darn straightforward. There is an implementation that Daniel has. But even if you're producing a raw implementation, it uses, you know, base 58 encoding and a handful of other very common things that that avoid language issues per things that we've learned in the past. So even a purely brand new implementation of did peer for it should be relatively easy, although you may not have to do that, you know, based on the, on the code that that exists. And then they did peer spec. We are proposing that we deprecate after we add did peer for that we deprecate all of the previous algorithms that are part of did peer. And I saw just briefly and I have just seen this and now can we just define it do a new did method instead of doing this. And, and there's some discussion here that that points to this, the thing that I have an affinity for the did peer spec is that people understand what you mean. And so the while technically having a different did method would work well. It was probably a mistake to call one single did method appear did method. There should have been something like did static or something else. And we could have done that we still can, but then we have to make sure that we cleanly message that that there could there can be a handful of peer did methods. And then specify the exact one that you're talking about and this is something that Daniel bloom and I have debated a lot about the right way to approach this. Just because of that exact issue that that Timo brings up so sympathetic to the issue and I'll have to make sure that I read this thoroughly and common in line on that particular issue but but yeah. Hey, Sam. Yeah. I definitely would argue keeping did peer, and we get to four and deprecate the other ones. The issue 717 seems to be related. Yeah, yeah, this one here. Yeah. That's where the comment is that was posted this morning, and Daniel replied. That last one. Oh, I'm not seeing the response but yet I did see a response. Maybe he replied via email instead of via the ticket. Weird. Anyway, I do, I do want to discuss this and I can give some brief background before we. Okay, good. Before, before we jump to 717. Does anyone have any questions about that. No, yeah, you're totally good. Does anyone have any questions or comments about did rotation or did peer for that we've discussed, and don't worry about asking a question you think that everyone else knows the answer to they probably don't. And so if you have a question, it's, we need to make sure that we all understand this is clear as possible, even if you'd like just a summary or, you know, some more description on a particular topic that would be a very valid question as well. Maybe just a piece of advice. I'll be looking for as, you know, from RSV six rose inflammation perspective. So we, we unlike other frameworks. We did that in did exchange only relatively recently couple months ago. So, you know, historically we've been using supporting only connection protocol. And so, from from I'm seeing right now it seems like the things are kind of moving underneath the exchange right now quite heavily so. What we're thinking is that will probably wait a bit until things settles probably would that it before, and only then we'll kind of, I guess, you know, merge the stuff in a cold base or, I know, if we if we merge it earlier would probably mark it as experimental or not stable yet. So does this make approach make sense as it seems like things are yet kind of finalizing with the components which did exchanges using being the did peer. I think that's wise. I think that I think, given the timeline and the goals that we have the creation of the community coordinated update and agreement upon it as a community. I think is the right signal that things have settled enough that they won't be changing anymore. So, I also recognize that things have been have been moving really fast here. There is some urgency that I'll that'll talk about when we get to did come be to and really what the mistake was is that we didn't apply energy on this earlier, which means that it's a little bit under pressure now to accomplish this and things are moving fast as we try to find the right solution. There's been a lot of debate, both internal to my head but also with other people about the right approach here did peer for versus the other things that we're doing. And, and the one consolation that I have or that I think is the most important piece is that I believe the solution we have now is substantially simpler and less prone to error. And sort of solves more fundamental problems but in a simpler way than what we started from. So, so, that's a little wordy Patrick but I think your approach of of holding off just for a minute on these sorts of things is probably a good idea. In the sense that it will help things sell a little bit, but I don't anticipate that delay being very long. I think that within, you know, a week or two, we can be to the point where where this coordinated update is is locked in all the, you know, changes and there isn't any controversy or major discussion points around around the things that are related. And we'll have a clear execution path around around this effort that will that will bring that together. Yeah, thank you. Maybe maybe one more short one. I'm not that maybe not the not the best meeting for it there's I know there's meeting for a pH but I know what's the, if you're aware of what's the current state of did exchange in a pH if I know that in a cup by I have a colleague mirror who was kind of testing the data exchange implementation against a cup by, but the occupy version was some sort of branch build or something like that. And, and I think AFJ was, I think I didn't have the back to know support for the exchange. I'm not sure about that. So if you know anything about these, these back to know implementations and kind of their status. Um, the did exchange is supported and occupy what's not is it occupy still using unqualified dids and we're in the midst and I think what was being tested was using pure dids and we're in the midst of that one. Yeah, that's right. He was that's what the issue is. We are directly started periods. Exactly. Yeah, that makes sense. So, I thank you for bringing that up because there was a needed item here that wasn't on my list. After we met the community coordinated update, you know, making sure that the Arizona test harness is ready able to support those things will be hugely valuable to the community and in sort of pre testing or individually or I mean not individually but but testing these actions, you know, between different software packages together. That was absolutely needed to be included here and I had not, I had not. So thank you, Patrick for bringing that up. Thank you. This is also going to help put it. There's a handful of blockers that we have kind of ignored as a community for too long, unqualified is another one. Moving to did copy to is is another one, which has a dependency on this. And so the, there's a handful of things that I believe needs some urgent attention. And that's why there's been so much focus on this right now. Because these are the things preventing us from moving forward in really important ways. Other questions. Thank you. Thank you, Patrick for those other questions of any of any nature. Awesome. Please do comment on these. These issues are PRs to help further the conversation around these and we'll continue the work there. As we, as we resolve these, these issues. So issue seven areas are C issue 717 is an important one that that was brought up. And I want to provide some background here. This was brought up in February and we didn't give it enough airtime, you know, prior to this, but it's highly relevant to the, to the moving off of peer dids, or at least unqualified peer dids, I should say, in the manner that is, that is more familiar with did copy to in that in. So this is, this is did exchange and you actually just patch as you pass the did docket as an attachment right within the did exchange protocols when you're using peer dids. And the change that's happening is that did come be to doesn't allow for the direct passage of did documents, but requires that everything be contained within a did itself, which is part of the reason why a peer did to and then now for that was created is to solve that particular problem and not a special have special handling for peer dids as part of the protocol. And so an anticipation of moving to did come be to going to fully qualify dids in the same manner is the is the is the goal that we're going after and we've always allowed for dids to be passed here without an attached did document there is text already that that's been in here for that. But the question that was brought up was that the the attached did document actually has a signature across the in the examples here. You can see that this is an attachment, but that there's a here's the did document itself, and then there's a JWS here as part of that process. And this came historically from the connections protocol which which also had something similar there but but that's been officially deprecated for a while now and did exchange has been the protocol that we've used to establish these relationships. So the question was asked. If we don't have the signature across the did document is it still valid to do it. And I responded in a really short way without an explanation here, some discussion ensued, and I have some. And I have an explanation here. And so, and I have to I haven't read this comment within the last six hours so I'll do that and just I'll take a positive do that in just a second, so that I make sure I understand his argument but what I am and positing. I just want to follow mentioned that the the requirement for a signed attachment is actually mentioned nowhere in the did exchange RFC. It's only present in the examples. And because it was present in the examples. It has been assumed to be required feature. Probably my fault in the sense that I was not careful enough to either include the appropriate language indicating that that that is optional, but not required. But, or to or to address it more explicitly instead of having it present in all of the examples but never actually mentioned a single time. So, it mentions for example that the did doc attachment is optional and that it contains the did doc associated with it. And, and then, you know, it contains a link that the did peer the did doc must be, you know, indicated there, but there's actually no discussion of encryption or which key should be used or anything as part of that. And I have the text here but I want to explain in the exchange of the of these messages. It's important to understand or to have confirmation that the other party possesses the key that you think they do. And so a signature is an obvious way to do that if something is signed by a key, then you can be sure that the party that sent you the message had access to the private key component of the public key in order to produce that signature. And this is this is redundant in the sense that the other way to be sure that the other party is possesses the private key is that they were able to decrypt information that you sent to them. And so if you encrypt something to their private key, you know, using their public key, and they respond to you containing with a message that contains information or that uses information present in that encrypted message. Then you can gain confidence through the fact that they now know the things you told them that they under that you know that they do in fact possess that private key. And so that's what I explained here. I also mentioned the nothing about signature requirements as present. And so the fact that a signature was required at all in either message is actually is actually an error probably on my part that it was left in there particularly unexplained. And I think that's caused some of the confusion. So having said that I'm going to pause for just a minute and read Timo's comment to make sure that I understand what he's talking about. So Timo is mentioning here that it means that the public key in the thread ID is now the basis of trust in the exchange. It's far more than just the thread ID. For example, if they have no idea, the, you know, if I'm responding, if I scan a QR code, for example, or I'm responding to an invitation, then the other party has no idea who I am. And the information about who I am in a message that's encrypted to that key that contains the did, which of course has the my public key and the service endpoint in order to return a message. And so the, the, the information that I'm passing to them, the thread ID, and the, and the service endpoint in fact the thread ID is the weakest of those all provide the assurance that they were able to decrypt the message that I actually sent. So we definitely need to add some commentary and some correction to the did exchange protocol at the end result of this thread to clarify that. But Timo is claiming before that we had the cryptographic assurance previously implying that we don't now. And in what I'm positing is that we, we always had redundant cryptographic assurance, but that we have not, we don't have any loss of cryptographic assurance, because of what's actually happened here. The reason why I'm going this way is that the instead of staying with the redundant cryptographic assurance is that we'd have to produce a deviation from the protocol. In the sense that there would have to be something extra to sign. If you didn't, in fact, you know, pass a did document with a signature on it. And I've also discussed passing the did document with a with a signature on it but now this is introduced new error states where your if there is a discrepancy between the did document that you actually passed with a signature on it, and the did document that is resolved independently. It's an error state where they can differ. And now it's the, you know, which one is being used by the other party can produce some some some variable states that are that that are potentially very hard to debug. And so I haven't obviously yet responded to Timo and I will, and I have no desire to lose to lose cryptographic confidence at all. What I'm asserting is that we we've never actually lost it and never actually needed the signature to require it as part of that process and I will all attempt to do so in a in a more lengthy way here to make it clear to Timo and anyone else that's curious. If you're wrong on this, I really need to know. And so if your evaluation of the protocol is that we do in fact need the signature and that the assurances that I'm arguing already exists are in fact wrong, then please do speak up either in a meeting or in the in the thread so that we can make sure that we don't make any mistakes in the in the processing of this because we really don't need any. I mean, you never need mistakes of that kind, but it's still quite important. Any questions, comments at all about this issue, even if it's just seeking clarification or trying to understand what's going on. I haven't taken a look at the protocol so I'll do that I guess my question would be, is there a reasonable assumption that it's possible, like based on what this protocol is used for and what the message available messages are that would be reasonable to be reasonable to guess the presence of a message, even if you can't decrypt it. Would you be able to determine the thread ID and say okay well I can glean what the public key might be and jump in as as Timo suggests. There are a plethora of messages and there's no jumping off point for determining how to jump in that I think I agree with your assertion. But if you can kind of eavesdrop and even without knowing the contents of the message be able to assume that they must be doing this. And I can learn these other things that I can jump in then there's a problem, but I haven't looked closely at the protocol so I will do that but that's the question, kind of the theoretical question I would pose. I think that's that's excellent. The other thing that we may be able to do is highlight the importance of having sufficiently unguessable thread IDs. The implementations that I wear of use you IDs, which are in all advice I've read are sufficiently unguessable. There's also a timing aspect of this too because there's very little that occurs prior to this exchange. So there's very little to grab on to to even know that a message was actually sent, you know, from from that party in order to make that happen. And so that is the that is the thing there the other thing that's actually kind of missing from this is that we never actually, you know, dropped a flow diagram in here which would be really useful. I may attempt a PR with a just simply adding a, you know, a basic UML like swim lane to to help, you know, show the the actual exchange back and forth to make that more visually clear. But but I would very much appreciate your evaluation of this. And anyone else of course to but but but this is this is an important issue. I think we don't lose anything, but but in which case no implementations actually, you know, are required at all in that process. So, Sam, it would be Teemo outline what he actually means I'm reading this and I don't see what from what I can tell I think he's saying that if a hacker could get the invitation. I don't know if he's going to respond to it but that's always been the case and included whether that signature is there or not. I think what he's assuming is that the this is only possible and not in the request but in the response of the protocol. So this is the message that actually goes from the inviter to the invitee. So from the producer of the QR code in order, yeah, yeah, to the consumer of the QR code. And then if they're able to guess the public key of the invitee and the thread ID that they produced that the responder is is responding to, then they'd be able to convince the invitee that they are the inviter. But that data has been encrypted by the private has the inviter. It has been. So, yeah, so I'm assuming that that encryption is not breakable what he's a certain I think is that they all they would need to do is is guess the thread. And and and guess the the the public key being used by the by the by the he's using different terms here, but by the invitee, meaning the scanner of the QR code. And I think that's a long shot. I don't I don't think it's going to be possible to guess. Unless you are, for example, reusing the same did for every connection that you make. The other party would have to know that, and they would have to guess your. You still have to even guess guess the thread ID because they also have to guess the thread ID. So what he's basically saying is that he's far more comfortable with the idea that we're you're checking a direct signature across data in the message itself. Yeah. Then on then on the information in a previous message being not guessable. My assertion is that the is that the information in the previous message is sufficiently non guessable by like a long shot that this isn't an immediate concern. It's not a concern at all. I shouldn't use immediate that I don't believe this is a concern. And so it's also, and you can in the protocol here, no discussion of a signature across that did documents is present here in any way. And so it's this is kind of a mistake and assumption because of an inconsistency between the examples provided in the documentation for the protocol. I think we've gotten very comfortable and everyone for super good reasons is really nervous about removing a signature. And so when it when it was included in error, then it's, you know, we there's a suitable amount of caution about making sure that it's okay to remove that. And I think that's why the concern is warranted. I'm going to add a comment to Timo's thing here to drown be a little bit more explicit about what I mean. And so, and that'll probably help and then and then Warren, if you even I would appreciate a comment, even if you, no matter what you discover, if you discover nothing or you discover something in that way, I know you've taken a look at it and that would be appreciated. Will do. Thank you. Any other questions, comments, thoughts. Again, to highlight the reason is so darn important is because in the conversion that we're about to execute with did peer for we will not be passing any did documents as part of this, which means that we need to make sure that this is nailed down and we have this done correctly. So where before it was, it was an infrequent possibility it's going to become the the norm on every message on every invitation. And that's why it's listed in sort of this, this March to eliminate and qualify dids. Any other comments about this before I talk about did come V2. Okay. I have to call Daniel bloom out here because he did. He brought up the fact that like, you know, in trying to figure out how to handle handle the unqualified dids that we didn't even have a mapped path forward to actually adopted come V2. It's bothered me deeply to my soul. He was correct in pointing that out. And I'm and I've thought a lot about it. One of the things that I like about about the did rotation aspect that he encouraged me to do was that it not only provides a way to move off of unqualified dids in a relatively elegant way and a relatively flexible way. But it also provides us an onboarding path to to adopt did come V2. Out of necessity, the service endpoints for did come V1 and did come V2 are different. And that allows you to specify which you support and you can support them simultaneously. Even on the same endpoint, although certainly a separate endpoints is another way of solving that particular problem. And, and the ability to to rotate to a did. With it did document that contains a did come V2 endpoint, even in addition to a did come V1 endpoint provides us exactly that on ramp that we need to make that transition. If you are, you know, doing did come V1 only you your software add support for did come V2 being able to message that to the connections that you actually have means that they can become aware and begin to use did come V2 as part of that transition which makes it a much easier transition and it means that it folks can adopt stuff in a much faster, you know, basis without having to necessarily wait for a community coordinated update to come along, which we only, which we only use as a last resort. I think that the length of time it has taken to adopt did come V2 has both been problematic for the areas project as well as problematic for for did come V2 generally. The largest deployment of did come V1 for obvious reasons. Adoption did come V2 within the areas ecosystem I believe will be hugely important. Not only because it helps solve a handful of issues that we that we that we've solved the did come V2 but but not, you know, hadn't solved the did come V1. Adoption means that it gets less awkward when we're talking about protocols that are V1 oriented or V2 oriented. And that is highly relevant even in did exchange protocols. And so my life has become increasingly awkward as I'm striving to both help support the areas community, but also advanced did come and did come V2 is what we're talking about in that in that manner. So it's really awkward. I have I've been requested a handful of times in different venues to teach people about did come and the fact that I have to speak to legacy did come V1 substantially because the the areas project is still mostly in use of did come V1. But it makes that an awkward discussion and really painful and is not an encouraging factor for folks to considering whether did come adoption would be a good idea, which of course such adoption would be helpful for the areas community. And so the, it's become increasingly awkward. And with a solution in front of us that we still have some wrinkles to make sure make clear or iron out, but with a clear roadmap in front of us. I'm feeling a lot of urgency around moving to did come V2. We've partially solved that problem with did rotation. So we've, we've, we're half step ahead further than we were before. But this is pretty darn important. We've, we began the sort of this latest phase of community, you know, efforts, you know, and focus on what we're going to adopt with the discussion of, of a IP three or a IP next right then the next one that doesn't really exist yet and what should be in it. And the more that I think about the urgency around did come be to, I think that we should target the minimum set of things required to adopt did come V2. As soon as possible. And while it may be useful after that to then have another target that advances some other causes. I'm conscious that the larger the target the harder and the longer it is to hit. And that, and that narrowly focusing on the minimum required did come V2 implementation so that we can officially deprecate did come V1 is I think going to be the healthiest thing for our community. What that means is that in addition to the support of of course did come V2, you know, encryption and envelopes and the other things that are going on there. Is that of course we, we have we're done with unqualified dids, but also that the protocols that had to be updated as a requirement of, of the did come V2 attachment changes and any other changes are also adopted. So that includes the, the did come credential exchange protocols, which, which pass credentials as attachments, and those are not hugely substantial changes the code should be relatively minor, but moving to and having those be the current standard for the protocols that everyone implements is a much better story to then go tell people, hey did comes a thing. And here's the protocols that people are supporting and if you build these, you'll be able to interoperate with the other existing software packages including Aries that that also support these protocols. That does mean that some of the other things that we have discussed for adoption may not be included in that in that interoperability effort or in that advancement effort for the community. So that may help us focus in a very real way on getting to to did come be to and over that hurdle. Once we are there, life becomes simpler, because we're no longer living in kind of a two version world that has has been a split of not only attention but but a source of confusion for folks that are trying to approach the community and the technology and understand that. So we've got up today. To sort of gauge feedback or thoughts and about about this, and also to hopefully explain why there's such urgency around solving the unqualified did problem and then and then moving forward with this. So that, so that this becomes a thing that is into source of confusion anymore for for folks that they want to adopt this technology. And that is that this year we've seen a huge ground swell of interest in protocols like the open ID for VC protocols and those. There's a lot of good that can come out of those protocols particularly by helping people feel comfortable with verifiable credentials that have not felt comfortable with them before, but did come and in the areas community. As a as a huge part of that remains one of the few places where the interaction models that we support extend beyond verifiable credentials to other things as well. And I believe that power is important. I believe that having a protocol that is capable of doing more than VCs VCs really well. It's not just about deficiency, but also that goes beyond VCs as an application of that trust or as an application of that of that portable trusted data that VCs allow is a really important thing to do. And we need to be in a better position to both teach and explain and help people understand the power of did come. So that so that as these projects move forward, they understand, you know, better options and they understand better architectures that can that can enable these these sorts of things if done carefully, meaning if you do open ID protocols with verifiable credentials and you involve dids, and you've selected a did method capable of containing a service endpoint. There's a really nice adoption path for did come that allows them to, to extend and add these things even if they've made an initial choice to use a protocol that that that is only solely focused on verifiable credentials. And that's some of the pressure that I that I feel any thoughts or comments, including ones that are in full disagreement. I really want to hear from the community about this about this issue about the urgency and the process of adopting did come be to maybe just a quick check. Not super familiar with did come we to but just to check it did come we to wouldn't have any impact on the other areas protocols like, you know, credentials for verification presentation protocol, this kind of stuff this can this can go whether whether these messages go through did come we want or did come we to doesn't doesn't matter does it. It only matters for protocols that have changes to them and the largest change that affects credential that those protocols you spoke of is how attachments are handled. There's a did come be to has a simplified attachment mechanism, and there is an adjustment to the how those attachments are done. Everything else is as similar as possible. And so one of the things that in the did come be to effort is to make sure that those versions of the protocols are hosted in the right place and are well understood, so that as we target them for adoption, we can we can have them. There's an ongoing discussion about the sense that there's a handful of features in the did come in the version two of those protocols we have the dot one and the dot two release of those protocols that add other features like multiple issuance and verification. And so we need to we need to have a have another pass at those before we're ready. But because there are some fundamental changes to the to the protocol, not a lot. There will be some changes necessary for the protocols that do use things like attachments. Sam, is it possible to have a convert v one to v two, even with attachments or does it fundamentally require that the protocol itself change. If you adopt some conventions, then you can do that but it but it's it's much simpler to not to 95% of the message you can systematically convert between one message format and the other message format. But but attachments because of the how much variability we had in v one makes it hard to systematically. We had three ways of doing attachments and did come be one and did come be to selects one of those ways and makes it the only way. And so, and because the protocols that we wrote for credential exchange didn't use the one way that we selected, and there's a lot of debate about which one to select. Then, then there, there are some adjustments required. And again, they're not very complicated if you're familiar with the one protocol and you look at what needs to be done for the other protocol it's it's not a significant amount of change, but but it is it is some change. Other questions. Sam, I had a question. Did I understand correctly that you're saying because of the adoption of did come or opening the door for did come your extent, people will be able to extend to go beyond credential exchange and the other protocols are focused on credentialing and did I understand that correctly. It opens a door for more, more meaning beyond credential exchange. Yes, well the doors has been open for some time we have like the basic message protocol for example and other product you know the question answer protocols and other one just off the top of my head that that are not protocols focused on credential exchange but can benefit, of course from the trust established in a connection in the data exchange during credential exchange. So, so the answer the answer to the question is yes although it's not a newly opened or this this door has been open for a while which has been one of the fundamental differences between the approach that did come has taken. And, and other protocols that are more narrowly focused on verifiable credentials. Does that make sense. Yeah, it makes sense. So you've kind of answered my, my question so these other things were open already through did come one. So what is did come to and sorry for my lack of knowledge here. So, that's okay so what it's clear that what I need to do and it's been a long time since we've talked about did did come be to is to do a review of what what's new what's changed why etc and we'll do that in a future meeting. We get more official about some things. We are closer. We are we are instead of just being close to a jwe in our encryption format it's actually a jwe. And so there's a there's a handful of things like that that have been done. It's also simpler than then did come be one is in a number of ways that are that are I think pretty important. The other thing is that every, every initial message contains all of the information necessary to set up a connection, which means there's actually no equivalent of the did exchange protocol. And did come be to because that's capable of happening simply by the sending of any, any protocol message at all. And so that that means that that the beginning process of making something happening is more efficient in fewer messages are required and then relationships can persist to whatever length they want. And did come be one we kind of had a full relationship that lasted a long time. And, and, or you had connectionless. And now there's a wider spectrum of things possible with a simplified mechanism. So did come to work has protocols here. We've got, you know, action menu, basic message. Some some data agreement protocols. And here's of course, like the issue credentials. There's, you know, mediator coordination related protocols listed here. And here's question answer. Well, you know, things that can actually happen over here and this is not all the protocols that have been listed but an example of the types of ones that we've that we've created. So anyway, we're over and we need to drop and we'll have time for more questions later. But, but thanks to everyone today. I felt like I talked too much I apologize. But, but please do speak up either in meetings or, or via these other PRs or issues or things like that. If you have both concerns or questions and we will work together to to figure them out and find the right answer. And I appreciate all of you and have a great week. Thank you. Have a good week. Okay. Bye.