Meeting minutes
<ottomorac> transcriber-bot, connect
<ottomorac> trasncriber-bot, pause
<ottomorac> transcriber-bot, pause
Agenda
<ottomorac> transcriber-bot, resume
Otto Mora: Okay… Okay, so… yeah...
… Excellent. Um, okay, so, uh, for the agenda today, uh, just wanted to
… look at a PR related to the date working group charter, which was put in by Pierre. have a new issue that was moved up from Lit Resolution, uh, about video uniqueness
… So it's a new DIT core issue. Then we want to deep dive into the DIT URL dereferencing PR, which should probably
… Take most of the call. Just parsing through some of the changes and
DID Working Group Charter PR
<ottomorac> w3c/
Otto Mora: Uh, feedback. And then if there is time we will discuss that resolution issue processing. With that, is there anything else that folks want to add? Okay. So, first topic… is the… PR, which is this PR
… And I'll also paste it in Zoom for those of you that may not be on IRC
… Uh, so this PR, uh, puts in, uh, some corrections related to the… status of the working group in particular to debt resolution
… And, uh
… I think Badr had voiced some
… Some comments as well that he wanted, and I think he
… I think this also corrects the status of that, so… uh… it just addresses a few of those things, but uh… wanted to see if anybody else had any… Observations on it, um
… Either now or later today, but if not, my plan is to merge this by the end of today. Unless anybody has any observations
… Okay. Oh, yeah, Manu, go ahead
Manu Sporny: Uh, yeah, I just… the one thing that I was concerned about is whether or not the re-charter allows us to continue developing DID resolution until it's completed in the event that we are not able to get it into a recommendation by the time the new charter picks up. I think… It does mention it. But it does not say it explicitly...
Otto Mora: Yes...
Manu Sporny: It says, you know, the new wording is to maintain the specifications produced so far by the working group, and that could be misread as a, we never said that you could take it to recommendation, right? Which has been...
… you know, there have been objections in the past around charters, uh, related to that. So, um
… It doesn't say that, and it needs to explicitly say that, that the group will continue to drive the specifications that they have to become global recommendations and maintain them afterwards
… Um, or some… some kind of language, uh, to that. Otherwise, it puts us in a… a potentially challenging spot
Otto Mora: Mm-hmm. Okay, so… Would you, uh, prefer that, uh, Pierre amend this, and then we...
… Merge it or create another PR specifically with that
… I think that works. That's fine
… Makes sense. Okay. I don't think there's anybody else in the queue
Manu Sporny: Yeah, yeah, I'll try to put some language in here. Sorry, I haven't had a chance to put this in there, but I'll put it in there. So hopefully PA, and I can't think of the language, but hopefully PA can think of the appropriate stuff...
DID Core Issue: DID URL Uniqueness
Otto Mora: But yeah, OK, so great. Yeah, I just suggest those changes, and we can get those with Pierre next week. Okay, perfect...
… So the next topic, we will be discussing the URL uniqueness. Uh, so there's a new issue that I, uh, opened up here. This new issue
… is migrated from this other issue
<ottomorac> w3c/
Otto Mora: Um… So let me just paste
… issue here
… And on Zoom as well, for those of you on Zoom. uh… And it it addresses this question about did URL uniqueness. I kinda used AI to help me out, summarize a bit of the discussion
… from the existing issue in the resolution, and it just summarizes the changes that we discussed, meaning permit reuse. warn clearly about the implications of reusing an identifier
Markus Sabadello: Sure. Basically, I just wrote, I think...
Otto Mora: Recommending key derived identifiers is good practice...
… And at security consideration, covering the risk of identifier reuse, which I think was
Markus Sabadello: This summary makes sense. We should not mandate uniqueness. Sometimes it makes sense to have unique identifiers for keys, and sometimes it makes sense to reuse identifiers for keys. We should not...
… Trick that, and we should have warnings and security considerations, as you mentioned. Sorry
Otto Mora: another one of the elements there. So that's the that's the goal of this. I think I see Marcus has. Uh, also add as a comment here, uh, maybe, Marcus, if you wanna...
Markus Sabadello: I think it's fine the way it is. I'm not sure if we need to do much in the spec other than maybe clarifying some of the considerations...
Otto Mora: Uh, comment now, we can… Ah, okay...
… Understand a bit more about your feedback if you want. Okay, I'm scrolling
… Good. Yeah. And then, yeah, like what? What I did with the other issue is, I I marked it as pending close since the the agreement from the group was to
DID URL De-referencing Discussion
Otto Mora: open a corresponding issue in, in did core. So, the idea being that we would close this
… I don't know, sometime after, a couple weeks after, if there's no additional observations, this will be closed. And then we'll just address all comments going forward and the other issues
… Any other observations?
… Otherwise… Okay. Looks good. Okay, so, um, let's move on to the… Main topic for today
… Which is the TIT URL dereferencing discussion
Joe Andrieu: The… I think walking through the changes is not the right algorithm, but...
Otto Mora: Um, so I know that there has been, uh, some updates on the PR here from Joe. He's been going through some of the feedback...
Joe Andrieu: Uh, a lot of these comments, I believe I've resolved. The ones that I think we still need to discuss, I marked further discussion needed...
Otto Mora: So...
Joe Andrieu: Um, so we could filter based on that and just go through an order. If that works for folks...
Otto Mora: I don't know, Joe, what is the best way? Do you want to walk us through your changes? You want to screen share and walk us through your observations? Do you want folks to maybe clarify some of their comments? What do you prefer?...
Joe Andrieu: Um… you can...
Otto Mora: Okay...
… Sounds good
Joe Andrieu: Since you're already there. Um...
Otto Mora: Do you want to share your screen, or do you want me to just go through here and the ones that are still open?...
Joe Andrieu: The first one, I think that I say still needs discussion...
Otto Mora: Okay...
Joe Andrieu: is...
… Well, it's complicated. I don't know how to refer you to it. Maybe I should just share screen
Otto Mora: Okay, okay, yeah. Sorry, go ahead...
Joe Andrieu: No, it's all good. They don't have clear identifiers in the comments, unless you get the whole URL, which… You know, it's not very speakable...
w3c/did-resolution#344
Joe Andrieu: Um… Okay. So this section here. Is about repeating the, uh, processing… Of the, um
… Well, let me… we need to pull it up in context, in fact, so let me… It's taken out of context, so it's a little hard to understand. 2, 2, 1, 6
… Right. So this is at the top end of the DID URL dereferencing algorithm
… Uh, these lines don't line up anymore
… All right, let me get a different reference and we can go that way
… Okay, so… This is the URL I'm using to pull up the preview from my branch
… Over at Ledge Rec, which is the merge branch, you can see at the top of the bit. And this is, um… about repeating
… So, in this section, um, we are resolving the DID URL
… And we have a bit of repeat as necessary until the final resolution result is returned. And that is because we know of at least one DID method, which even the need to have more information is not known until you begin resolution
… So it is a necessarily iterative process whereby resolutions can respond back with, hey, I need some more information. You may provide that information and the resolver may again reply with, hey, we need some more information. And that needs to repeat until you get through that. Um
… Steven did not find that clear, uh, Marcus agreed with him, and so I flagged it for discussion and tried to explain, uh, what I just said in a more shorter respect
… Um, to which Steven replied two weeks ago, and I just added a bit this morning
… Um, which Stephen disagrees with So let me hand it over to Stephen and try and understand what he's disagreeing with
Stephen Curran: Okay, um...
… When there's… so if this is strictly to do with version time type
Joe Andrieu: It is not...
Stephen Curran: Things. Um… Okay. Where it is version time, um...
… That would be handled by the resolver, and so the resolver… that need not be in the URL dereferencing. In the second example, you… so the bit
… Bitcoin example, did WebVH example, those are handled within. the DID resolver. Um
… where where there is your example you give of a unknown
… version time, where the client… the person invoking the DIB URL dereferencing may not know
… The right time they want, because it's not clear enough, they would
… Simply do another dereferencing, an entire pass through the whole algorithm, passing a different version time. Um, value
… And that would also… so that would be outside the scope of PID URL dereferencing. My belief is that… Resolution must give you the DID doc that you're supposed to deal with
… And it's up to a resolver to have a way to specify a specific version of a DID doc. That's why those parameters are up in the
… did resolution section, not in the… and so
… it's that first step of the… of this subsection that handles those types of iteration and things like that, when there's multiple versions of the DID doc, and the correct one is needed
… Um, if you've got other examples, um, I haven't seen those yet, so open to hearing about other examples where you would have to iterate through, but I don't think the Bitcoin one or the
… Did WebVH or any other version time one holds up to scrutiny? That's it
Otto Mora: Mm-hmm. Uh, Joe?...
Joe Andrieu: Right. So version time is a parameter you can pass into resolution. But when that version time doesn't give you back the result you need, it is calling, you have to call that step again, which is what you described, Steven, is that you said it requires another dereferencing...
… This is the language that says, hey, go try it again. So this algorithm is doing what I think you're asking it to be done, but I'm not sure why you don't like the way that it's being said this way
… The… the… the… if the version time you have is not granular enough as the caller, as the client, to resolve, then you may need to call resolve more than once. And so resolve cannot, in its own process, deal with the fact that it might need to be called more than one time. This step is repeat the resolve as necessary
… Which is, I believe, exactly what you said is it's another dereferencing
… So I'm a little confused on that. The BTCR2 example has nothing to do with version time
… It is… there is a parameter that needs to be passed into Resolve as an option
… I shouldn't have called it parameter. It is an option that needs to be passed and resolved called sidecar data. That sidecar data may not be known that it is even needed until you're into the process, and that is what I've tried to explain here several times. I'm not sure
… where the disconnect is, but there definitely needs to be an iterative loop for that situation
Otto Mora: Okay...
Stephen Curran: So, my struggle with this… sorry, I'm on the queue...
Otto Mora: Yeah, yeah, go ahead...
Stephen Curran: Yes. Um, my struggle with this is that you're implying this is incurring within DID URL dereferencing versus multiple DID URL dereferencing processes. Um...
… that… I mean, I just find it… very confusing that in the middle of this algorithm, somehow something is… and this is why I question what you were calling a client. Like, I had thought we… a… an external party of some type invokes a DID URL dereferencing algorithm. And gets a result back. Um
… I think you're saying halfway through it, it might get
… additional things coming in and need to make other decisions, so there's this sort of callback mechanism or something like that. Is that
… the… the process, like, I would have thought that
… you know, certainly I did WebVH, it's all handled within it. Bitcoin, I… the greed I've got is… is all handled within the Resolve. Operation
… Which is step one of what you're saying
<Zakim> JoeAndrieu, you wanted to say yes. this is within the dereferencing of a given DID URL
Joe Andrieu: So I don't know how I can tell you, except repeating, BTCR does not behave the way you still seem to claim that it behaves. So all I can say is that you're wrong about how it behaves, and I want you to trust that I understand how that algorithm works...
… You cannot do it in Resolve, because all Resolve can do is tell us that we need more data. So it comes back from the Resolve function that your Resolver has executed, and now we're back in the
… The referencing algorithm, which the client is executing
… So we are not defining a function that someone calls that therefore needs calling parameters and return results. We are defining an algorithm that must be executed by the client. And we're dealing with all the
… craziness that we've enabled with our decentralized architecture, that we can have all these arbitrary properties at different places that affect how dereferencing happens
… And so we can't just rely on particular simplifications that some methods use. We have to come up with an algorithm that can handle
… as many of the ways that different people have decided to enable dereferencing as possible. And I think that's what we've been trying to do with this for the last… you know, I don't know how many months
Otto Mora: Okay, Marcus, who's on the queue?...
Markus Sabadello: I I agree with show that there are definitely situations where you have to call, or where you have to execute an algorithm multiple times. If additional information is needed. For example, in did Ptcr, 2, yes...
… I agree that sometimes the case that you try to resolve it, and then you find out you need additional information, and then you have to try to resolve it again
… similar also with the version time example that was given. Maybe maybe you try to resolve a deed with one version time, and then you find out you want to resolve it with a different version time. I think the only question is, is that part of the
… algorithm itself, right? To me, I think Steven's viewpoint resonates a bit more, I think, in situations like this, you basically execute the algorithm once, and then, depending on the result, okay, maybe you then execute the algorithm again with different
… data, but I don't think doing that is part of the algorithm itself, right? That would feel like
… I think it's not a recursive, nested execution of an algorithm, it's multiple executions of an algorithm in a sequential way, so I don't think it should be part of the algorithm itself to say that you have to now recursively call the same algorithm. Again
Otto Mora: Okay...
Stephen Curran: Um, to ask it a different way slightly, and maybe this would help, Joe, is...
Otto Mora: Uh, Steven?...
Stephen Curran: a DID resolver can be called with a DID. Are you saying a Bitcoin VTTR2 DID cannot call a resolver and get a DID dock back?...
… Um, without an iterative process
Otto Mora: Okay, uh, Ted, next...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Forgive me for going a bit meta at the moment. I...
… I am struggling to be looking at the right part of stuff that is being discussed right now. I can see the conversation there between Joe and Steven in the
Otto Mora: This part, right...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): In that page that was just on screen, um...
… when I go to the source itself
… I cannot find that conversation because the original line that was commented on
… It has been changed, and so it shows up as outdated in the conversation thread, as was on screen. um
… The current iteration of the document is very different
… And part of the challenge here is what I commented elsewhere about these steps not being
… Not being numbered and or bulleted
… And that leading to some very strange logic
… that does not seem to be logic. The particulars that I'm talking about were iterations of. If X… then
… do ABC. If not X, then do DBF
… Otherwise, which means if neither X nor not X
… then do this other thing, which never happens, because you can't be both X and not X
… So, or rather, you can't be neither X nor not X
… And I'm still having the problem of not being able to see the rendered and pretty document because of some problem with either CSES or Respec or both that I haven't been able to narrow down enough to tell CISREC, fix this. All I can say is it's broke. Um… I'll leave it at that
<Zakim> JoeAndrieu, you wanted to say the entire algorithm need not be restarted for btcr2
<JoeAndrieu> https://
Otto Mora: Good. Thank you. Go ahead, Joe...
Joe Andrieu: Yeah, so a couple of things. So here's the URL where you can see it rendered. Because that's what I put my branch to...
… Uh, if you want to see the local files, you have to pull the clone and render it locally. Um
… But this is what I'm showing on screen, in which all the steps are in fact enumerated and bulleted and there is a big fat graphic. That explains all the steps
… Uh, I could go in and add numbers to all these if you want to track these individual diagrams, um, to the individual steps
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): I'm sorry. Do you have a hash link to the exact part of the document that you're looking at because it's huge?...
<swcurran> What we are discussing is before the diagram and not part of it.
<JoeAndrieu> https://
Joe Andrieu: Um, sure...
… So that will get you to that top level diagram that we had walked through before. Which I think has some of the logic you were looking for. Like, if that, then this
… And then the rest of the steps are pros, explanations of what each of those, uh, processes are
… questions and processes
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): And if you'll indulge me for a second, I want to share my screen so that you all see what I'm seeing. Uh, come on, do the thing. Here we go...
… There's current share. Yes. Chrome. They keep changing the damn interface
Joe Andrieu: Yes...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Okay, do you see the flow chart?...
… Okay, I'm scrolling up a bit now
… This is what I see. I don't get the pretty page
… And I'll scroll down a bit from the flowchart now. I do see the numbered steps, so that's helpful
Joe Andrieu: Yeah...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): And I will try and review that...
… At a later point, but this is what I'm getting for everything
Joe Andrieu: Yeah, that's super weird...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): And so now you know, and I don't have to share anymore...
… Pity me as you will. Oh
Otto Mora: Is there a specific browser that you're using? Because on mine, I use it on Brave, and this renders correctly, but...
Joe Andrieu: Yeah, I'm… I'm...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): In this case it's chrome, and it does have a bunch of extensions. But I've tried it in private windows. I've tried it in multiple browsers that don't all have the same extensions running, but do have extensions. I will try it again later today, if I can make a non extended. Chrome...
… work. I'm not entirely sure how to make that happen on this platform, but we'll see
Joe Andrieu: Yeah, it definitely seems like your CSES at a minimum isn't getting pulled in, but… I… yeah, I don't know why...
Otto Mora: Mm-hmm...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, if I looked around a little bit more, I could find you one of the triple square brackets or double square brackets that also don't get processed, which points to respect, so… I don't know...
… But it's super frustrating. I'm sure you'll understand
Joe Andrieu: Could you add an issue to the repo? And I'll try with staff to see if they can take a look, like… Because I've definitely… I'm just not seeing it, right? So… I don't know how to debug it. Um… But you should be able to see it...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, well, it's not just… it's not just here, it's in every spec that I'm working on in all of the groups I'm involved in, and so it's...
Otto Mora: Yes...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah. I'll leave it there...
Dmitri Zagidulin: Go ahead...
Otto Mora: It's almost like you disabled JavaScript on your computer. Sorry, Dimitri, you wanted to...
Dmitri Zagidulin: I was just going to say it's got to be individual settings and extensions because I like...
Otto Mora: Mm-hmm...
Dmitri Zagidulin: I think everybody else can see it on Chrome. Okay. On Linux, on Mac, etc...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): And JavaScript is running, other things are doing fine, all kinds of other sites are working fine. The only error that I can find when trying to render this is a CORS error on respec...
Otto Mora: Yeah, okay...
… What is it?
Joe Andrieu: Yeah I've I've seen similar things but not on a fork like the the fact that I changed my GitHub pages to use a particular feature branch...
… Got past what looked like this problem
… Where the MIME type of the CSE isn't being provided by GitHub
Otto Mora: Okay, but...
Joe Andrieu: But I think that's a different problem than what you're dealing with. Um...
Otto Mora: Perhaps we can get back to the...
Joe Andrieu: Sure...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, I didn't mean to turn this into a debug section, just to show it...
Otto Mora: Sorry, yeah. Okay, so I think, to go back, there was a question from Marcus about whether it should be explicit in the steps or not about the...
… a recurring call to the function to. Right?
Joe Andrieu: That's right. And the last question that Steven had asked...
… And his time in the queue was, is he correctly interpreting that BTCR2 needs this iterative loop and it does
… Like, if the algorithm ends
… Then, um… BTCR2 fails. It will not work
… And we're not dereferencing a different URL. It's the same URL
… The same DID URL
… And we need this iterative loop with the resolver
Otto Mora: Okay...
Joe Andrieu: So, this step, uh, to… Um, repeat as necessary...
Otto Mora: Steven's back on the queue...
Joe Andrieu: Is a null operation for all the methods that don't need it...
Stephen Curran: And that to me would suggest that that is part of the resolution step, not part of the URL dereferencing...
Joe Andrieu: And so… I don't think there should be any opposition to supporting methods that are out there that do need repeat when it doesn't interfere with anyone's process that doesn't need to repeat...
Stephen Curran: That it would, that that iteration would have to occur during resolution, which is step one of those, of this three step process...
… to try to get past this. I guess I will try to. I would like to propose trying to rewrite that paragraph if we really have to keep it. I don't think it belongs, but it does not
… it's very confusing to an implementer to have to understand that, and so I think it could at minimum be
… rewritten to be better to try to deal with that. Um, and definitely removing the… version of the DID docs, since we're saying that's not the issue
… Um, that would want to be… that should be refused… removed, because again, that would be taken care of in the resolve function, not the expectation of it
… I think at minimum. It should say that… and I'm not sure how the… Caller of the, um, the algorithm. Would get involved at this point, but they might… somehow be… Checked to see if… The DID doc that was returned was the one that was needed
… before continuing on with the determining handling strategy. It's… that's my big concern, is
… you know, this is happening before we determine handling strategy or anything else. Suddenly, we've got to
… Outside of the resolve operation, call back to figure out
… whether we've got the right DID doc after we've resolved the DID doc
… And that's what I'm struggling with, so I'll leave it at that
Otto Mora: Okay, and I know Marcus wanted to also chime in...
Markus Sabadello: Yeah, we should. We should totally say this. We should say that for some deep methods you have to repeat or execute an algorithm multiple times. But I don't think that saying that should be...
… said as part of the algorithm itself, not the resolve algorithm and not the dereference algorithm. It's weird if an algorithm says
… uh, call… call the… the same algorithm again, right? That… that leads to some weird nesting and… and loops. So we should say that, uh, yes, for some DID methods
… In some cases, you'll call the algorithm again. We should say that, but we should not say that as part of the algorithm itself
Otto Mora: But so just just to put a fine point. So you would say...
… that statement would be, like, at the beginning of the… before we get into the details of the algorithm, there would be, like, an explanation saying certain DID methods require further processing, something like that, or
Markus Sabadello: Yes, say somewhere outside the algorithm itself...
Joe Andrieu: Um...
Otto Mora: Okay. Okay, cool...
Joe Andrieu: Yeah, so sadly, I disagree with both of those comments you guys just offered...
… The… one thing I'm… I keep getting confused by, from your comments, Steven, is this is the step where we resolve the DID URL
… So this repeat is about calling the resolve function, and it is not something that can happen within the resolve function. It is not possible. It is topologically impossible because the resolver does not have the data
… The point is, the resolver responds saying, I need more data, and we need to process that and repeat until we get a good DID document. There is no good DID document when we have this intermediate request for more information
… Um, and the version ID does not address this either, because the fact that the caller may say, hey, I think this is the right version ID I need, and the resolver says, nope, there's nothing there
… Then you don't have a did document. And so the caller needs to look at its business rules and understand well is there another way to interpret the version time or the version ID to maybe get a result because the one that I had isn't working
… And this is a point of we're just trying to get to the did document. That's the entire point. Like we we cannot. have a DID document because the failure is happening because we can't get the good DID document, and so we have to retry until we get a good one
… And I do think it is very much a part of the algorithm that must be executed in order to support BTCR2 and other methods that have a similar pattern. So we know that we have deployed systems using this. approach
… there's… there was never been anything that said you can't do it this way, and if we enshrine an algorithm that doesn't support BTCR2
… You know that's that's not gonna be cool. So I I do think just like 39 86 describes how you deal with secondary resources and how redirection allows you to go get another resource and like the the algorithm of how you deal with what comes back from resolution is
… is absolutely within scope. And I think if we don't explain this, then we are not going to have, um, interoperability across DID methods, because people aren't going to know that you can't just take the first response. So we should… I think we should make it very clear that if you can't get a good DID document
… Based on your initial parameters, it may be appropriate to adjust those options and try again
Otto Mora: Okay. Uh, Steven?...
Stephen Curran: So, again, you're… I'm pretty sure I'm understanding you, Joe, but you're saying that it is impossible with BTCR to simply...
… call the resolve algorithm and get a result. That the only way to resolve
… to get a DID doc from a VTCR is to DID URL dereference
Joe Andrieu: Hold on. I have to interrupt you, Steven. It is in the resolve section...
Stephen Curran: And there, all I'm saying is that repeat is necessary. I totally supportive of it being in the document. I'm suggesting that it needs to be in the resolve section, which we've got an entire separate section on...
… And
Joe Andrieu: 6.1.2 that is on screen is the resolved section for the dereferencing algorithm...
Stephen Curran: No, sorry...
Otto Mora: Yeah, Steven, go ahead. Sorry. Sorry. Yeah, sorry...
Stephen Curran: Uh, auto, uh, yeah...
… I mean, sorry, I… let me specify, I mean it needs to be in Section 4 of the document
… It needs to be, particularly in section 4.4, did resolution algorithm. The did resolution algorithm should state the repeat as necessary belongs there
… This resolve the did 6, 1, 2. I would say the URL should be dropped off that. But this section item one has a click, the resolve function which links back to did resolution. It's saying, use did resolution, which includes use the did red resolution algorithm
… Part 3 of this that we're seeing on the screen should be placed in section 4.4 of the DID resolution algorithm. I'm not saying remove it, I'm saying it belongs in DID resolution, not in DID URL dereferencing, because DID resolution. can be called without… dereferencing a DID URL. It can be just called directly, and if that is necessary for
BTCR to resolve the DID and get a DID doc back, it needs to be part of the DID resolution 4.4 algorithm
Otto Mora: Mm-hmm. Uh… Joe...
Joe Andrieu: The 4.4 algorithm is what happens when a resolver receives a resolution request, a resolved function call...
… It has nothing to say about what you do beforehand. That's what the dereferencing algorithm does
… Right? So if if we look at the the DU the
… dereferencing algorithm. We prepare for resolution, we resolve, we determine the handling strategy based on the information we have, then we invoke the handler, and we use the handler result
… The resolution function is just what happens when you call resolve within step two. And the server has this function invoked
… There isn't a process here in four for calling this thing multiple times. The context in which you would call it multiple times is exactly what is described in section six. That's the point of section six
Otto Mora: Uh, Stevens...
Stephen Curran: I would end with, I mean, I give up, but I think you're...
… missing… you're… you're not reading the VTCR2 spec correctly, in that it says, during resolution, you have to do it iteratively, and the purpose of resolve is independent of the URL being referencing, and it should be complete, and if
Joe Andrieu: So...
Stephen Curran: if certain DID methods require iteration, they should. I give up, you know, I'll try to reword it, or just let it go, because I just… I think it's a...
… A crazy discussion, but if you
… So believe it, I'll just let it go
Otto Mora: I'm… I'm confused, though, just whether...
… Marcus, you also… you agree with the suggestion from Steven to have it on 4, or you're like, no, it should just be
… Even outside of that
… I'm trying to understand that part too. I don't know, Marcus, if you can… Chime in on that other… Suggestion
Markus Sabadello: I think it should be outside of… Yeah, either algorithm...
… And I've implemented the BTCR2 independently. I don't
Otto Mora: Yes...
Markus Sabadello: it needs to be part of the algorithm itself to say that sometimes you have to execute it multiple times...
Otto Mora: Uh, let's see...
Joe Andrieu: So, what… I… I think...
… So I'm not sure how to address what you're suggesting, Marcus, which is to define this thing, but don't put it in either algorithm. I think if we're defining it, it should go in one of these algorithms
… Either it's part of how you dereference a general DID URL, which is the framework of prepare for resolution, call resolve, use the results, you know, figure out the handler strategy, etc
… Um, or it's something the resolver does, which is in Section 4. Um, I don't know where you would put it
… In the spec, such that we define it, but it's not in these two sections. Um… And, and… I I guess trying to reframe what I said before to Steven
… Um… The dereferencing algorithm is the logic around which you make sense of calling resolve. Right? It's how you prepare for it, it's how you execute the call, it's what you do when you get the response back. It is the meta layer where we are explaining that you may need to call this more than once. Um… If we start putting information in
the resolve algorithm
… about how you call it. Now we have two places where we're describing how you prepare for resolve, how you call resolve, and how you deal with response. To me, this was… this was a fairly clean, um
… separation of responsibilities. One is how you prepare for resolution, and then you call resolve. And then there's this other function that we've clearly defined with inputs and outputs, and we have an HTTPS binding for it. And that function is what happens when that endpoint is hit
… And the resolver deals with it. And so the fact that that might return
… An error state that the client can respond to
… And call again with different parameters. That can't be in the result. Uh, function. It's how you call the resolve function
… Which is the point of this framing of the dereferencing algorithm
… So, I'm not sure how to address what either of you want in a way that's coherent with this modular approach we've been trying to explain what a client needs to do when they resolve a dereference of DID URL, which includes. In one step, resolving
… Um, and to your point, Steven, about looking at the BTCR2 spec. Um, so
… I can't speak to what the folks driving that now are doing. But when I was involved, we didn't have this algorithm
… We didn't have the clarity that this resolution would would produce. So they didn't know that there might be something that they should better call that it's dereferencing
… So the fact that they use a particular form of language shouldn't impede us from trying to clarify for everyone when you get a did URL of any kind of method. Here are the steps you should go through as you resolve it
Otto Mora: Okay. Uh, Marcus?...
Markus Sabadello: So I don't think it should be in the resolution algorithm, because then the resolution algorithm would somehow weirdly call itself in a nested, recursive way. And I don't think it should be in the dereferencing algorithm, because sometimes...
… I just want to resolve a date, I don't want to dereference a date URL, so this consideration with the PTCR2. This needs to be handled and enabled properly
… also just for deed resolution alone, without dealing with the dereferencing algorithm. I think it could go, for example, into the… section about, uh, deep methods, right? We could say that some, some deep methods, uh, have this, uh
… property that methods may require multiple resolution attempts with
… additional inputs and different metadata and error situations and things like that. It could be in the methods section, it could also be in the
… Deep Resolution Architectures, uh, section, which talks about how clients and resolvers and dereference, uh… dereferencing how that all fits together. It could also be in the implementation guide, where we could mention that some. Did methods behave like that? I just don't think
… The fact that sometimes we need to execute a certain algorithm multiple times should be part of an algorithm itself. So that feels a bit strange to me
Otto Mora: So I got the part about the architecture, which is Section 8...
… But when you're saying did methods, are you referencing which specific one?
Markus Sabadello: Oh, sorry, that's, uh, that's...
… that's indeed core, right? So, um, I take that back, it should not be, uh
… in DID methods, because that's in DID core, but it could be in the DID resolution architectures or in an implementation guide
Otto Mora: Okay, so your suggestion is, yeah, either Section 8 or Implementation Guide. Okay, um… Now, Steven… yeah...
Stephen Curran: Um, this isn't a hill I want to die on, so I give up, as they say. Um...
… I hope we can get slightly better wording to make this not confusing to people, like
… myself and Marcus, um, that have dealt with
… you know, bids and implementations in the past. Um, but other than that, let's move on. And it can stay
<Zakim> JoeAndrieu, you wanted to say BTCR2 is complete on the process for resolution
Otto Mora: uh… Okay, Joel?...
Joe Andrieu: Yeah, to Mark's goal of being coherent across all different did methods. The BTCR2 spec does explain how you resolve that. As it must...
… And so it does talk about this option that you have to pass sidecar data and the response that you might get if you need more sidecar data. And so the spec itself does in fact address resolution. Um
… What the gap is, so that's all method specific. Which happens within the resolve portion
… But trying to understand and document what happens at dereferencing, if we want interoperability between how you process a BTCR DID and a DID key or a DID WebVH, then I think the algorithm, which
… Um, is a dereferencing algorithm, where we prepare, invoke, and then use the response, should deal with the fact that if the response is of a particular nature, you may need to, uh, call resolve again
… That said, I agree that maybe this language can be cleaned up. I don't I don't mind finding language that makes it maybe more clear why or when that would happen, like saying that some did methods have this like, I appreciate that language that you suggested, Marcus
… Um… But the point of these six steps in the dereferencing algorithm is to explain what the client should be going through
… And if we leave out that step, then, people are going to build architectures that don't understand that they might need to do that sometimes. And it's going to decrease our interoperability across different methods
Otto Mora: This is...
Joe Andrieu: Is there anything that breaks, Marcus?...
… With that language, I think that's one of my other concerns, is like, there is a DID method that I know needs this. And I don't think it breaks anything else
Markus Sabadello: I don't think it breaks anything, but I disagree that...
… BTCR2 would be broken if this wasn't there in this place
Otto Mora: Yes, it is...
… Maybe just to get to the more meta… oh, sorry, Juan, go ahead
bumblefudge: Um, to the disagreement about whether. PTCR2 breaks...
… Would an adverb help? I mean, it seems like Joe is arguing that the language is misleading, or it implies atomicity
… to a step that might be multiple or iterative or something, and Marcus is saying that isn't implied
… the language could just as well apply to an iterative process. It kind of feels like the difference
… is a difference of interpretation of the status quo language. Not so much of a difference of what… how much more complicated the algorithm should be
Otto Mora: So, of how it works today, then, right, Juan?...
… like they're both understanding it differently. You're saying right
bumblefudge: Yeah, I mean, Marcus is saying this change isn't needed because the way BT… the way I implemented BTCR2 applies… this language applies to my implementation of BTCR2. So I think the, uh...
… Maybe a smaller change would be enough to make more explicit that this is not necessarily always an atomic step, just because it is one step in the algorithm
<Zakim> JoeAndrieu, you wanted to say we could replace call resolve() with perform resolution according to the DID Method
Otto Mora: Hmm. Thank you. Sure...
Joe Andrieu: So, one way we might be able to, um, take Marcus's suggestion...
… Um, into the spec would be to change the step in dereferencing from calling resolve. To perform resolution as defined by that did method. Um
… That would certainly invoke BTCR2's specific handling. Um
… But I think this also highlights
… The, um… The non interoperable nature of that feature. Um… Because rather than repeating until we get a good result, regardless of what the method is, we're now being method specific in the middle of dereferencing
… And so it felt much cleaner to me to say, before you call this function that we have rigorously defined called resolve
… Here's how you prepare for it. Here's what you do with the response
… So that seemed to be, to me, to be more clear and have better interoperability than just passing on the resolve part and say resolve according to the did method. Because now we're very method specific in an area where we're trying to get interoperability
Otto Mora: Okay...
… Um
… Anybody has any reactions to that? I mean, I saw Juan thumbs that up, so I think he agrees with that. I don't know if, uh, Marcus, you… That satisfies your… That's right
… I thought you were on mute, Marcus. Super. Oh, sorry
Markus Sabadello: I'm not on mute. I'm thinking about this, I think...
… I think I'm also ready to give up. Oh
… I don't know. I don't think it's
… I don't think everything is always about dereferencing. I think most of the time, you just want to resolve it. I don't know why
… Why we're talking so much about dereferencing? We just have to, for some DID methods, uh, yeah, that DID resolution algorithm has to be
… executed multiple times. That's what we should be saying somewhere
… And, uh, nothing else, and we don't… we don't have to build this into an algorithm, we just have to say sometimes the algorithm
… needs different inputs depending on the metadata, depending on the error codes, maybe you can execute the algorithm again to then get a better result. And that's that's what we should do. We shouldn't
… built this into any of the algorithms themselves
… It's an iterative thing, it's not a recursive
Otto Mora: Mm-hmm...
… Okay, well, um, I think we should pause it right now, but I just wanted to check, Joe, is it best just to schedule the special topic call next week, and
Joe Andrieu: We may as well. It feels to me all these options for discussion are going to take weeks. So...
Otto Mora: And try to just, uh, you know, maybe have steel and… Yes...
Joe Andrieu: Double up our meetings, because it seems like everyone wants to fight about every single proposal. I don't know how to resolve that. Other than push through it...
Otto Mora: Yes, so we'll have the special topic call to deep dive on it and maybe look at some other options...
… Any closing words, Joe, on this, or… You know
Joe Andrieu: Just engage on GitHub if you can. That is helpful...
Otto Mora: All right. Perfect. Thank you. I appreciate your comments...
<ottomorac> transcriber-bot, pause