 Alright folks, welcome to the 23rd of August Aries working group call We have some continuing good and important topics on this call today. Appreciate you being here This is a hyperledger call and so the antitrust policy and the code of conductor in effect With the link in the the wiki link for the meeting agenda You're welcome to make any changes useful to the community add yourself the attendees list if you wish Or make any other changes that would be useful Do we have anyone new today that would like to introduce themselves us are returning and glad you're here announcements by fold this pause for August AFJ is bi-weekly during August and then the The the diff did come users group meets the second third and fourth Mondays and there's the link to the schedule and the stuff there as well Any other announcements we should have on but don't They say I'm all mentioned There's work starting up at trust over IP on a thing called did web s that people may be interested in or maybe not but anyway, it's a did method that is Compatible with did web But adds an S for secure onto but with the idea that The controller of the did Provide at this point a carry audit log of the key events and transaction events That the controller performed related to the did so that adds a measure of History and provenance for the key so that you know That all of the key rotations and so on were done by the controller Including things like a redirect to a different Web website in case, you know two companies merge supports fancy Features that carry Supports such as multi-signature support pre rotation and that also has the concept of Within the web folder of the did web s and using the did URL path capability signed files that might be associated with the did and adds one other thing which is a Tentatively called a who is folder which is intended to contain verifiable credentials or verifiable presentations That for which the subject is the did itself and so the idea there is a Controller of it did say an organization Could publish its public verifiable credentials in a who is folder so that they're easily discovered in a known place and the verifiable credentials can be processed without having to Message or contact the Controller of the did so some interesting features there if people are interested. There's conversations starting up on in trust over IP for that Cool. Thank you for bringing that up any other announcements Stephen if you have a link that would be a great Aside to the notes I added the end of saying all that I realized I didn't have a link handy and but I should So I'll take a look back. Yeah, thank you Excellent any release status or work updates from our various code projects We have on the agenda today a quick marketing update. We have I have a topic about did rotation for did coffee one And then that has effects on our previous conversations including the presentation that Stephen gave last week About the the various options that we have and some related stuff Are there other topics or any other adjustments that we want to make to our agenda before we get going all right? Helen or Alex Whoever's on deck today Yeah, hi. Good morning. Um, so just two notes one is that? We are we sort of were the victim of the five week August and I believe that the calendar invite for our meeting was Set for yesterday when it should be the last Tuesday of the month So apologies to anybody who might have showed up yesterday, but we will be meeting next Tuesday to discuss areas marketing and The link should be the same as in the calendar, but just next week working with ride to get that updated now So it these five week months don't Trip us up from the trip us up in the future on I think a couple meetings ago. We presented the the new hyper light hyper ledger Aries draft page in the wiki It's it's just there kind of in the left hand column if you open up the wiki So the link is there. I believe yep in the notes. So feel free to take a look at it Actually, let me just I'll drop it in the chat here for folks We'd love to get feedback on it. This is the new Some of the the language that's coming out of the Aries marketing working group calls and we're also working with Ben at the With the staff at hyper ledger to get that updated on their main website too since that is this if you If you do a search for hyper ledger Aries, it's the hyper ledger or website that pops up first so we're making sure that It's updated in all places. So we'd love feedback Please attend the meeting on Tuesday if you have comments questions concerns and otherwise Please just take a look at this page and give us any updates and you'll see actually if you scroll down There we're we're also presenting some of the repositories with some descriptions as well So if you have anything to say about How those are represented we'd absolutely love to hear from you and make sure that all your voices are being heard Anything else alex that I missed No, that's perfect Any questions for me from anyone. Alrighty Thank you Helen and alex. I want to add a plug here We're all busy doing stuff and we're all busy building stuff generally And and so marketing is one of those things that we kind of are aware of but don't necessarily Place at the top of our importance list and this is a mistake that's really easy to make and I think we've made far too often In the areas community in the past And so my my plea here is that this is important The the technical quality of what we're building while important is not the only thing that's That's important in our effort rather to have it be accurately represented And and be understandable by those approaching it Is is also critical to the project's success And so if I would encourage you To to take some time to review these these materials the link here is is is in the marketing update section And take a look and offer feedback if there's something that isn't being represented Well, or you have ideas on how something might be explained Then then reviewing that work is is good And and alex and and Helen have been doing a fantastic job with this But they need our Review and effort from a technical side of things to make this work And so I I implore you to to try and make time To to to have some review of this in addition to the awesome technical work that you're doing So that so that we can have our work accurately represented and and be well understood by those that are approaching it So I I very much appreciate their work and and my my encouragement is heavy to to make some time To to dig in and work if you're interested in attending those meetings the marketing meeting. Here's the the link there And that is that is open and everyone is eagerly invited to attend If you are in an organization that has a marketing person then Or or anyone who would be interested in that aspect of it technical writers or or any anyone really Then then that would they're also welcome in that group um So I'll I'll I'll quit soap boxing on that particular topic But but I just wanted to highlight the importance of it And how how effective it can be and helping the work be recognized I appreciate that sam. Yeah, and I would also unplug that any like business development leaders product leaders Folks that are you know doing any frontline customer facing sales roles Those are all good people to bring to this meeting. I know marketing is sometimes a dirty word in some circles So we would love to have a variety of voices who think You know think critically about the business aspect of this project and the uses and we'd love to hear from you Our next fun project we'll be working on is a explainer video for the To be used everywhere, but mostly on the Primarily on the hyper ledger.org website on the areas page there So if you have thoughts about what an explainer video might work look like We that's what we'll be discussing next Thanks Helen Anything else on marketing? I'm good. Thank you Excellent Okay, next topic is uh is is did rotation. Um, this is something that that uh that I was convinced of by both Stevens conversation and In daniel bloom isn't here to defend himself But but also convinced me that that this would Be a good a good thing to do So did come v2 has did rotation as a as a feature of the core protocol and it's handled with headers and uh I began to realize that did rotation In did come v1 would be uh would be a useful feature Not just for solving the unqualified did problem But also for enabling transitions to to did come v2 as that arrives and so I have a I have a link here and I have written up a um A a proposed protocol for rotating dids with feedback And and if it if it's still a good idea, then I'll go ahead and submit this And and we'll and we'll make this work. Um, this I will just I will likely submit this to the areas rfcs Given that this is did come v1 specific. I'll I'll also list it in the um In on did come dot org, but the the main host thing for it will be here Given that it is oriented specifically to did come v1 as did come v2 already has a way of doing this The there are some impacts of of using this on our current conversation that I'll get to in a second But just to quickly walk through There's there's two messages here There's the rotate message and the act message The rotate message indicates the did that should be used in the future to identify the party that sends this message um, and so If you if you have been using a an unqualified peer did The notifying the other party that you are using um A new did for that Is a way of cleaning that up so that so they so they have that And and then the act message it basically comes back in response And then after the act message is is you know, this message sent and the act message is received It's expected that the new uh, the the the keys associated with the new did be used Now if you've followed along with our previous conversations We've talked about the fact that that you can use existing keys to as part of a new did And in peer methods that we're talking of which means the actual keys in play may not change um Excuse me for the for the message is actually being sent but The the coordination of that did is going to be important to enable Number one the qualified dids to not be in use but also to be in place by the time did come v2 arise It also allows if you happen to be using a did method That does not have a did come v2 endpoint to be able to pass a did That that does have a did come v2 endpoint in that way the the discoverability Of of your support of did come v2 can happen via this this normal way And the fact that it would be known from the did that you passed And so this feature here gives us a an easy way to update existing existing connections With with dids that can they can be used to make that happen There's there's a little bit of an open question here There's something that i'm not super satisfied with but i don't have the good answer to And that is and that is this one here The when you send the rotate message because of the asynchronous nature of did come you You may receive messages for the the previous did or against the previous key and did come v1 For some period of time before the receiving party has a chance to receive and process the message And so the the wording that i've used here is that the the the rotating party is expected to receive messages on both the existing and the new The new did and the associate keys for a reasonable period I don't like reasonable period because it's super squishy But i but i don't i can't come up with or i haven't yet come up with a better wording for that And it's possible that we could clarify with some further explanation meaning They should and to expect to receive messages certainly until they receive an ak message But but may want to do May want to do that in excess of the ak message in case there are multiple parties on the other side that may not have All received the the message simultaneously And that's that we don't have very many Situations where you have multiple agents tied to a did yet But in that in that case then that would that would certainly cause a problem And so this is relatively simple In the sense that that there's only two messages And it doesn't necessarily require that the other party update there did simultaneously Although this is this would certainly be a goal that we have So this is relatively straightforward. So and and relatively simple. So why did we why did I do it? One thing is that it enables switching to a did that has it has it did come to service endpoint And that would that's a really useful feature as we adopted come v2 Within our ecosystem to be able to know if the in fact, the other party is capable of receiving a did come v2 endpoint Or did come v2 messages And so that's a mechanism that would enable that anyway, but the main problem that I did it For is that it decouples or at least the most immediate problem is that it decouples the process of Moving off of an unqualified did to a qualified did From the from the decision about which did you actually rotate to? And so What this means is that if we adopt did rotation support As an intermediate step then the need for a larger community coordinated update no longer exists Um for the sake of doing a strict translation between unqualified dids and whatever the new form is I it's uh, I it's probably more efficient Uh as a community for us to still make a general decision about which did method we are moving to Mostly for the fact that that did method could be supported Um and that way there's there's few there's less variability as a community in what we're transitioning to Away from unqualified dids But it decouples that in a way that I think adds the the necessary flexibility and allows people to be compliant in an easy way The other thing that a community coordinated update could still be used to do is to set a sort of a time a time Goal as a community on when this is both supported And and is able to be to be leveraged and the time by which we are all you know Actually rotating off of those unqualified dids so that those are officially deprecated And and and we can in newcomers can begin writing software that that does not contain support for them Which is which is a key thing as as folks end of the community And so that's the goal. Um, I I have a comment about did method support and discover features But before I get there Any comments or questions or thoughts about this protocol and its use Warren yeah, um I was just thinking more about the all reasonable amount of time to support the multiple dids and um I'm wondering whether there is a mechanism within the existing protocols to know Like either message sequence numbers or timestamps or whatever so that you would be able to know that if a message was is Was being generated by a party after it had sent you an act That you would know that Um, or whether it was prior to that and thus you would be able to say yes, I accept this message or no, I don't um, there are Uh, you can include sent times as part of the message um, and and that's uh, that's Going to be at least consistent by the sender right meaning if if sender a even if their clock is skewed a little bit It's likely to be relatively correct to the um, two other messages So you can compare the timestamp of the act they send versus the timestamp a stamp of a Um, you know of any other message they sent it could be one mechanism for doing so I will mention too that this rotation is not And and I don't there's no commentary here on the protocol about it But this rotation is not necessarily an indication that the other did should not Should no longer be trusted or that the key associated with the other did should no longer be trusted More of a sense that here's this other did that I would that I would like to actually use And so it's a little bit more of a friendly rotation in the sense that It's not necessarily a security risk in the in the use of it But rather hey, we're you know, I'm moving over here for a logistical reason To continue the relationship without with having to re-establish that um I don't know if that impacts kind of where you're thinking or not Warren about that about that reasonable period time Well, I'm not sure that this um It doesn't feel right to me that you Send out this notification and you get an acknowledgement and then somebody continues to use the old one Like that doesn't feel right to me that like whether your intention is to You know, it seems that this is saying hey, I'm rotating And if you acknowledge it, then okay, and if you don't well, then I'll accept the old one and perhaps Ad nauseam if if if I don't think it's a risk Right. Um, but then it's up to the receiver to decide But the sender if they acknowledge To my mind, they are acknowledging that they will use the new one from this time going forward um I I I totally agree with that the the wrinkle shows up in software that is is a little bit more distributed than that in that there's various, um You know pieces of code running in a distributed manner that might be sending messages as opposed to receiving them and the receiving party can can Can receive that and begin its own sort of internal synchronization process um, but Uh, but guaranteeing that no messages sent You know without the absolutely most current data information. Um, it's something that I'm a little bit reluctant Perhaps foolishly to impose Um, and the perhaps foolishly is is that I don't think we have very many scenarios yet in our ecosystem where there's multiple agents in play Or there's software that is distributed enough that it's not using a common data store For the dids that it has for other parties Um, and so maybe that's foolish in the sense that that it doesn't really matter Um, it did particularly at this point in the development of the ecosystem Um, and so we could adjust the language if we found it useful within this within this this protocol To say that you you receive messages until the act message has been received and then you you know no longer process them um The the asynchronous nature of message delivery means that it's possible Um, that if two, you know, if if a message was uh was sent um just prior to the act message being sent and then the act message is sent uh that um that the they might be delivered in the In the opposite order that they were that they were sent which means that That message would then be cut off and could create some weird states for the receiving party I think that that is a possible scenario But I think that could be handled with a like a fixed time window After receiving an act that you will accept the old one and you know like five minutes or something like that Right. Well, yes. Anyways It we're the problem is is it's like we're super into the edge cases, right? And there's there's so many weird things we can imagine Um, how probable they are is a totally separate discussion um, I I think that uh If we leave it a little bit loose, it's up to the implementer to decide about how far that really goes and in practicality I don't think we're going to run into very many scenarios where this creates a substantial snarl Um, but steven i'm curious what you have to say about this or are you talking about something else? I had some thoughts on the reasonable time I think there are scenarios where The reason you're rotating is because you can no longer use the dits Or or won't be for very long. So it may not even be in the control Um, so the example I'm thinking of is the mediator you're using goes away Then you need to rotate all of your dits to use a new mediator Oh, that's actually a great use for this Exactly. Yeah, that's now the way this is So did gov2 you actually Send the message from the new did As the step of the rotation Um, and then you can include a signed assertion Using the key associated with the old did that that's allowed to happen and we did that on purpose for for reasons like that Um, for simplicity, I didn't do the same thing here in the sense that you you prerequest the rotating of the did Instead of post authorizing the rotation of the did Um, and so you would have to know in advance Uh, that it's going away But your point is good in the sense that they they may say hey within a week I can't use this anymore. So I'm going to send the did rotation Um that contains the did that references a new mediator in that way This relationship can continue even though that piece of infrastructure is is shifting Um, and so that's a that's a that's a super good use case There and I acknowledge that this doesn't solve all the use cases that the rotation in did combi2 does Partially because I'm trying to help us get there In the sense that rather than reinvent or backport all of those features Just giving us enough to like reasonably get there is is kind of my goal here Does that make sense steven? Yeah. Yeah, I love your I love your example of of mediator rotation though. Thanks for bringing that up yeah, the um Second question I had so I've got a few um second question relates to the next comment you have which I just read there You didn't say that but I wanted to be sure of that so the off cryptid message does require signing by the a key from the old did Because I think that is necessary It isn't in this isn't when you're using off crypt And are we always using off cryptid did convi1? Um in practice, I believe that's true technically you don't have to but I believe in practice I'm unaware of any software that that does not off crypt messages of standard practice Could we not add a signature explicitly to this so that there is a chain? You can but the only case that would be useful is if you're not off crypting messages Well, I mean you just wouldn't know that you wouldn't care Um, I mean it would be easy enough to add a signature over the hash of the to did But but you could but why? um Yeah, I mean if off crypt if we're certain off crypt is used um, that's fine I just this is an area. I don't know enough of so I'm never I'm I don't know enough of when off crypt is used or when it's not So that's why I was going to raise the message, but if you're confident that off crypt is being used in All the time then then that's fine Well, it will be now by declaration of this protocol um in the sense that Right, it is that if you properly rule with this protocol then the message must be sent using an off crypt or signed and either one is sufficient that way Um, and that way you have assurance in fact that that that this is an authorized rotation and can't be sent by somebody else Right, so I would add that to that message the reason it's got to be off crypt and why it's got to be sent that way um Just to that message um, okay You did not include a did and did doc Which means we preclude anything that requires a did doc such as did pier one That's correct Okay, I am totally good with that. So you could use did pier two here. Um, obviously and That would be good. I think It is time we updated the did pier spec to deprecate all that did pier two and three Um, I think as a as a separate activity. Yes, I believe it's time to do that As well as as well as change some of the commentary there There's a historically about some some commentary in there that has not been super useful um, so that It's some of that may be may be helpful to not just deprecation messages But for example, there's there's discussions of of sort of some theory in the did method spec That may not really be needed there. It is long needed to get rid of it and and it talks about using key rotation and This simple message gets rid of all of that crap If you'll pardon the expression, um, and we can just Have it down to did pier two and three and that's it now the only thing I'm worried about I don't know if anyone from afj is on the call, but as far as I know afj has implemented did pier one and um, and so Basically, we would want them to Basically undo that and remove did pier one Support and just go with did pier two and three and I don't know I'd be interested in their comments on that I don't know if anyone's here on that from maybe I don't think they have to remove it But the rest of the community is not going to seek to implement it um Right, so um and and and Daniel hardman wrote did come uh, or uh, the the method one in pier In the period did spec and he has uh, Announced his intentions that it be deprecated In favor of sort of other technologies and in the specific ones he was was mentioning whereas, you know, the development of carrier related technologies there, so So that's fine. Um Cool um any Um, Stephen any any of the comments Um, the last comment was you did talk about simultaneous or anything like that and I don't think that needs to be even mentioned Each party operates independently um So nothing in the in this should talk about simultaneous updates or anything like that any any sort of hint of sort of um Coordinated updates or anything like that that is not needed. What's needed here is a rotating party is saying i'm switching And the receiving party says, okay Um, if if the receiving party decides to do it Themselves for their own that's totally up to them, but that's an independent Um activity agree. Yes. Yep Cool, thanks Um black This is awesome and long long long overdue way to go. This is excellent I was kind of fighting it because I was trying to avoid inventing new things in order to solve this problem But by the time we got deeper into our discussion it became obvious that we're inventing new stuff anyway And that this was probably a far simpler thing to do um, and also Assist the community and in the movement from any did that doesn't happen to support did to to a did that does happen to support or did convi to And and so the two birds one protocol thing kind of convinced me that it was just needed um So I appreciate steven both your previous presentation and in in his absence, uh, daniel bloom for for convincing me that this was a good idea arielle Yeah, not just to to to clarify that Or actually, I think there will be no problem because what we are going to do is to migrate to to deep pier two so We will still be supporting pier deep pier one for for a while But but that were the idea is to just drop it as well Right, so no problems from the fj front. No, no Excellent. Thank you for clarifying and sharing Um, in the middle there steve mccow and I saw your hand up. It was your topics covered or did you have anything you wanted to add there? Oh, I was just going to make a comment about the uh, when do Did's expire? discussion and I think As I thought about that, I don't think it's really too much of an issue because the question really is How long will you accept communications on your old did not how long can somebody Else send you communications using that old did And so I think the problem kind of Minimizes itself based on what the agent is willing to accept and Yeah, that that was my comment as all Um, yes So daniel blue made a comment to me along on a similar vein is that he expected most implementers What would simply upon receiving the information and then sending the act would just Would just overwrite and forget the old did which means it would be effective immediately Which is technically compliant with the spec and the easiest to program And so because that because that way of implementing it as simplest He anticipated that that would be the most common thing done Which which is after the act And then And and is compliant with the spec Yeah, I I think that's awesome. I I think that it will just people will migrate and then dids will drop off by By rapid attrition Um coding it. That's what I would do too. So right Um, excellent Um, any other questions or comments about the rotate did protocol Hey sam. Yeah um This is where Um changing things is where Um risk comes in because somebody Well, the off-crypt is what controls it, right? I'm worried about I'm just thinking about this is Doing things like this is where People try to break into systems that you know, you change your sim card or you change your email address You know, you're kind of doing that um I don't think there's a whole lot of risk there Particularly if we've got that off-crypt Just but have you given any thought to that or or any concerns? The provenance right is what you're getting at is that if you can't prove that this is the path forward Intended by the owner of the of the first did Then this is a risky thing if I just show up and be like, oh, yeah I used to use this did and now I want you to use this did but there's no actual provenance there. That's that's a perfect Uh injection attack that allows, uh, you know another party to to intercept them or to place themselves In the middle of the relationship or simply take it over um That's why in did convie 2 There is a signature across it But the reason there's a signature there and not here is that is that that is uh sent after The the did has been rotated meaning you you don't warn them using the old did that you're going to use the new did You just send a message with the new did and include a link back to what the old did used to be with the signature in place Um, and there's efficiency reasons. We did that. I still believe that was the right choice um, but it's far simpler To to pre-worn In in our did convie one case even though it's not quite as efficient the the the slight lack of efficiency Um is I think warranted for the simplicity of the protocol itself Uh, all I'm going to update this to include a message. It says if you receive a did rotate message that is not signed or was not received With auscript you must discard it Um to to further underline the fact that this has to have be provided in a way Uh, where provenance, uh is is clear In the sense that that that the owner of the of the key associated with the previous did Is authorizing the move to the new did and that way it still relies on key ownership Which is the basic premise of security and didcom anyway. So nothing changes there Does that answer your question to that effect steven? Thank you Yeah So one one final clarifying question if I may Yep, so related to that which is um I'm not familiar enough with the internals of the software architectures that would use this Would the receiver of a particular message which perhaps is registering interest in some message type um Would it necessarily know? that the underlying Thing was auth cryptid or not um Or is it in practice? It doesn't matter anyways. I don't want to be pedantic about this. No, no, uh so in uh the In practice, I don't think it matters In the sense that when you receive a message the first thing that you do is decrypt it and because it's using auth crypt You both of course decrypted using your key And in the process identify the key of the sender and then the key of the sender in didcon v1 Is used to look up the relationship essentially the did but the relationship Of the sending party, which means that if you sent it You you could only send the message if you actually have the key the private key of the sender Which means that I can't fake it. I can't I can't fake that using my key, but say rotate stevens did Because you'll notice that there's no from did indicated in the message here And that's because the from did is actually pulled from the message that was sent in the first place Now the only case would be that if you receive an unencrypted message And and you're just going to believe the from that it presents But that's that's not a thing we that we currently do and I believe all existing software Lines this up and the in the fact that Well, actually it doesn't matter and did come v1 because keys are the or how you indicate that and didcon v2 There's an internal did that's actually represented and there's notes in the spec That that say that you must upon receiving a message Make sure that the key that was used to sign the message is actually the from key listed on the inside if it's present And so I don't believe this is an issue in the sense that If you for example sent an unencrypted message message to acopi or to afj just to pick two common examples here I actually believe they generally fail. That would be interesting to test But but I believe that that that auth cryptid messages is by and far the norm It would be interesting to know Out of curiosity if either of those packages would even operate on an unencrypted message that was transmitted to its end point It's likely going to fail the decryption process because it isn't encrypted and I think they do that for all inbound messages That would that would be worth taking a quick look at but I believe it's a non-issue Is that a sufficiently satisfactory answer or is that still squishy enough that we need to make sure we we understand the behavior? Well, I think just to Steven's point about Like a potential avenue for attack injection We should probably verify that Messages that aren't encrypted are rejected Otherwise some other layer in the stack might just be registering interest in a particular message type receive it And not know It could be anyways. Anyways, that's the only thing so like it's fine to put it in the spec But if the implementations don't actually Do it. Yeah, do it then so So it I could highlight this very very large in this spec and what that means is that It would be really hard for some to implement this without seeing that in particular note And then of course, it's possible for them to do bad things But but but we can we can make this as loud as we can You know for the for this particular requirement that you that you are to discard any message not received either off encrypted or signed And I think that that would be I think that that would be Probably as far as we can reasonably go from a spec perspective to make that happen as a community We can pay attention to all the software packages We use to to make sure that that at least with the implementation of this particular protocol It you know, it ignores, you know unencrypted or unsigned messages So part of that's a spec perspective Which we just need to make it as obvious as we can the other part is a community perspective And then that's something that we that we verify as we're touching the software that we're interacting with So really good Okay So there's a related concept here to did rotation and that it Before you rotate To a did It's would be a really good idea if you knew that the other party was capable of actually resolving that did And Because otherwise you're going to rotate to a did that they're incapable of using which kind of effectively hangs up by like suddenly Yeah, it's the it's the effect of like suddenly switching You know irrevocably to a different language when you're talking to someone if I understand that we're speaking in English and you also seem to be Spanish I can switch to Spanish and it works out If I switch to Spanish without a way of revoking back to that then you don't speak Spanish This is not going to be a long conversation At least not a two-sided conversation And so understanding that the other party supports the particular did method is something that you That we actually need and we've talked about this in did features And and even figured out sort of where to add this over on didcom.org We have that relatively solved the thing that I don't particularly like is I was looking at how to implement this How do you actually indicate which? Which did you actually support uh, Stephen? your hands up I was just going to give an idea at the end of your opening. So I'm queuing myself up Oh, okay So here's my problem What I'd really like to do is simply indicate the did method like did peer or did indy or did web Or did web s to reference the new one being developed The in the reality that is a little bit more complicated. Um, and I switched by uh, for for example here to the configuration file of the universal resolver You can find this by going to dev.universolver.io Hit configuration and it brings up the configuration that this resolver is running with And each of these drivers here indicate Both what kind of test identifiers they are but also a regular expression that actually matches the identifiers that they provide now You could get away with saying well did solve is just a method And and if you look at like uh did indy here we have the same thing where you have You know, you have different actual networks and and subnets In operation And so you can't just say did indy because it'd be really useful to be able to express a more A more complete indication of which subset of that did method you actually support So there's several did methods to do this including ion And uh, and they had to have an indicator for for use on a test net instead of instead of the main production net And so expressing it a little bit farther is actually useful You might want to say hey, I I do did indy sovereign Just doing a prefix which was my next guess Also doesn't particularly work very well because if you say I support did indy sovereign Then it doesn't indicate whether you support just the sovereign main net or you also support did indy sovereign Sovereign a builder in staging as given by the examples here And so a prefix is a little bit insufficient as well in our particular case with with did peer There's a there's an indicator that the algorithm that comes immediately after so you could say I support you know did peer Three or did peer two or did peer one and that would indicate sort of the subset of did peer that you actually support So this is a little bit of like an internal versioning or an internal subset issue That that's actually coming along. There's another interesting one here if I can find it Where did key is actually indicated but did key allows the encoding of a variety of different key types And you may not not actually support them In which case It becomes a little more complicated You'll notice for example that they have so here's did and they actually work with tz pkh web and key But also here's the actual key types that they support Being listed here. And so that is a That's another example of a subset where you might want to indicate that you support, you know did web You know this particular key type as it's encoded instead of the other ones and so That leaves us to the point where that if we're going to do this it needs to be done with a regular expression In order to follow the example and I'm going to I am going to reach out for opinion To marcus sabadello who runs the universe of resolver. He's the main developer there and has lots of experience here I don't really like this Because um, you can run into some really weird things with with with variability of how different languages support the regular expression syntax And a bunch of other weird things And so that that's really awkward It's less of a problem for the universe of resolver because this is the configuration for one particular piece of software But if we're just if we're discussing the use of this within a protocol Then all of the software has to process at the same way as as as provided and that's kind of messy and I don't really like it And so we kind of have imperfect ways of doing this and I'm bringing it up Number one to indicate that I'm Planned on pushing this as fast as I can because it's a relevant piece of the puzzle here But also to hopefully get some advice on how to how to properly indicate which did methods Software actually supports in the discover features protocol and steven I'm ready for you to provide me all of the answers to my questions So I'm just wondering if there might be a slightly easier way to do this If you send a rotation method and The other agent doesn't support it. I think it would its behavior should be to send a problem report back saying I don't rotation That's a great idea. And then as well if it does support Good rotation, but doesn't support the type you rotate to you send a problem report back instead of the act Um, that that is a great idea. I still really want to get did support into uh into discover features Particularly because in didcom v2 There isn't the opportunity to respond back with uh with a problem report because it's it's post rotated not pre rotated So this is still a problem, but you're right I love the idea that there could be a problem report if the if the did being provided is is not Resolvable by the receiving party. So that's definitely something that we can do But but but uh, but I still really want to add it to the to discover features Yeah, I'm not saying not to add it to discover features. I'm just saying For this particular use case. We actually could be fairly okay Yeah, I I think we could it's I think I think we should do both so Sam, um I would be in favor of doing the prefix approach and suggesting those like the sovereign net to Make adjustments in the future to have their prefixes distinguishable between builder staging and main net That's did indy support. We need to get that for sure Uh, did indy would as among those that would need to actually be modified in order to handle that Either by include always including a network name or by just changing a different character so that you know when sort of the The the delimiter between the networks and the actual thing is is different so that you know and you can specify sort of the full name of the network It also means that for example, if we did the prefix Prefix is so much better in so many ways. It is a little more verbose in the sense that if you support um Let's say five out of seven indy networks You're gonna have to list like all five of them as a prefix, but that seems like a pretty uh A pretty decent compromise given the overall simplicity of the prefix matching approach we could also Perhaps in your protocol leave an option for a different method of declaring what Methods you support in the future Um, and so you have your version one method that says Hey, this is what we kind of think we should do for now believing the opportunity for version two of saying I support these in a different methodology at a later time Um, that's a good idea The the other way that I had thought about doing this was do some sort of subset indicator when you so here's the did method And here's the list of subsets I support And that would allow you to sort of restrict that artificially What I think I can do if I do this right uh to your point kim is that if I name this carefully Then it allows for a name to list on a side or in in replacement of That method which means that we can move to a better way if we discover one in the future I was trying to invent something Avoid inventing something new in the case of the subset because that's like not a thing that really exists and so the prefix is kind of like a A default way of doing the subset that doesn't have to actually be declared by the did method owner And so that would be a way to to make that happen But certainly the subset indicators could be could be a way to also make that happen Um, and I'll have to fix that now I think your point is leave room for it in the future so that we can like get smarter as we go and don't have to Tear the whole thing down we can we can just augment it to solve the problem in a smarter way Which I think is really wise other comments So I think this solves the transition problem in that we don't all have to have code That works exactly the same way that translates the dids of other people Which was the original approach that we were discussing it allows you to declare yourself Which did method you're rolling to and with the with the error steven, which I think is a super good idea The the error included into the protocol and and the The in discover features that you can use as a as a sort of a pre-check way of doing this We have a reasonable way to move forward It's still a good idea. I think to not branch out to 16 different did methods Just for the sake of of ease of implementation So we may want to discuss this in a community coordinate coordinated update anyway The update though is going to be a little looser in the fact that what it says is implement did Did rotation as phase one and then phase two is do all the rotations Right actually rotate away from from all of the dids that you own and then In the last phase of the community coordinated update it will be Like, you know, no one receives these dids anymore. It's a little bit of a different community coordinated update I think it's a little bit of a cleaner one in the sense that That that that the approach I think is is less prone to detailed failure And it also sets us up really nicely to to rotate from a did that does not yet support did convi one Or did convi two to a did that does support did convi two Which allows for for that sort of that next progression step to happen anyway and and it's also nice because You'll be able to ideally detect And there's another discover features thing that needs to happen there But you'd be able to detect that that that that someone else's did convi two ready And of course you can always indicate your supportive did convi two Which means that we may not need to hopefully won't need a community coordinated update for that We could simply use the built-in discoverability features that we have in order to to do that particular transition Which is nicer that's always preferred to use some sort of discoverability to make that happen I think the Does anyone else have a have a better idea than using a prefix indicator? I I don't like regex and it's kind of confirmed by the the few voices that I've heard Does anyone have a better idea? Than than using prefix matching in order to indicate support for different subsets of did methods so What are the main things that we need to consider In terms of in terms of matching so there's In some cases you're trying to match a set of networks In another case you're trying to match crypto Sweets that you support right So are there other are there other considerations and did peer we have the the num I'll go indicator So it's did peer one did peer two did peer three So it's did colon peer colon three and being able to indicate that you support did peer two or did peer three Right is a super useful feature to make that happen So some of these things could be handled by like a Maybe that's what you meant by a subset but like by a list right Yeah, yes. Well, what I would do is I'm some of them anyways What I would do is indicate that you you can specify A list of the did methods that you support and if you have a did method that requires multiple prefixes to accomplish your goals Many you wish to indicate that you support did peer and did peer three. There would simply be two separate entries in the list Uh in the prefix list Oh include with exclude prefixes That's interesting kim I will think about that Uh jason bit mask. Can you explain a little further? Like if the list is going to be ever-growing or changing can't we just assign um bits to each thing and someone can just You know Then we're hosting a registry somewhere and that feels ugly Okay, yeah um Ideally this list gets semi-long. I think in practice this list is likely to be relatively short meaning there's going to be like five or six things there um What we may want to include uh is some sort of indicator of um We may want a flag that says i'm unit using the universal resolver version something What that means is that I can resolve anything it can resolve Because I happen to be using it and and that's that's one sort of like splat way of expanding the list Or or sort of referring to an externally defined list of supported did methods Just because you can resolve something doesn't necessarily mean that you can deal with the crypto That that implies right. Oh, yeah, that's very true Um, so i'm going to end up with a pull request For the discoverers feature stuff and then we can discuss I'll I'll circulate It's going to be a pull request against the file over and did com.org and then we can circulate it And I would very much appreciate feedback so that we can be as intelligent as possible um With the with the expectation that we'll be smarter tomorrow than we will be today um, and so um, so that's really good We are uh out of um This is a super interesting topic actually Um We are out of time But uh, but this is fantastic. This is a fantastic session. I very much appreciate everyone doing this I'm going to work hard to to get this option in there with the idea that we have sort of marching orders And we know how to move forward with this. Um, and so that will result in prs against these things um Very much appreciate feedback both now and on and on those prs to to be able to add and clarify things as we need Thank you for everyone for coming and I hope your week is a great one and we will see you next time