Meeting minutes
Agenda Review, Introductions (5 min)
<ottomorac> transcriber-bot, resume
Otto Mora: Okay, so, uh, for agenda review today, uh, we have a brief update on the charter situation...
… Uh, we also have, uh, just a brief discussion, uh
… decide whether we have a call next week, due to IIW being there
… Uh, also a debrief on the special topic call
… You want to try and finish that discussion on the URL dereferencing?
… And if time permits, we make it to other items on the Google Doc that we've been reviewing with, uh
… Uh, Joe, and discussing with the team. Is there anything else people want to bring up?
DIDWG Charter Update (5 min)
Otto Mora: Okay, not seeing any hands raised. So
… Uh, first item, then, uh, DID working group charter update
… I think on this one, I wanted to yield the floor to, uh, Pierre
… To, uh, just provide some commentary on that
Pierre-Antoine Champin: Yes, thank you. Uh, so, uh, we did request a charter extension, because it's now clear that we are not gonna...
… Finish on time. We got a 6-month extension, it's been approved
… maybe not yet announced, but, uh, so that's, uh, that's done. I was
… hard to say a bit surprised when, uh, Francois daustre told me… because I told them, okay, we need a 6-month extension, the goal is, at this point, not to reach out her, but we need more time to finish what we have
… In stock, and uh… Francois told me, well, you will need to reach out anyway to go to maintenance mode
… And I was a bit surprised because I didn't know that maintenance working groups were now mandatory
… Uh, I understand that having a working group, even if dormant, uh, is more convenient, if we need to apply errata to the spec and so on
… Uh, but I didn't know that it was, yeah, uh, required or mandatory in that, uh, in that respect. So, I will
… Uh, starts working on a very simple new charter, which basically says
… the group will just maintain the spec, uh, the spec that are there, and I'll loop with the working group about that. I don't want to take too much group time for this, because, again, our focus should be on
… getting those two recommendations through. But, uh, this will be, um
… Uh, this could be on the, on a few, on a few agenda, and hopefully we can. We can make this, uh, straightforward enough
Otto Mora: Yep. Uh, nope...
<TallTed> Mandatory maintenance is good! Should be trivially chartered.
Manu Sporny: Uh, plus one to that. Thank you so much, PA, for getting that, um, pushed through the process. Um, I guess, uh, what I've seen other groups do, um, is that when they go into maintenance mode, if they don't have some of their items at REC...
… the charter says we will continue the work, you know, towards rec for the items that are not complete, and then those items will immediately go into maintenance mode, and for everything else
… we'll be in maintenance mode. Was that your expectation of the text that you were gonna write for this, um, maintenance mode charter?
Pierre-Antoine Champin: I guess I'll wait and see how much progress we do, but yes, I mean, if, of course, if by the end of the charter extension, uh, the recs are not published, then...
… there is… there is a risk, let's face it. Then, yes, uh, I will adopt this kind of text so that we can, of course, uh, finish this, uh, in the… in the next charter
Otto Mora: Well...
Will Abramson: Yeah, I guess I wanted to speak to that as well, like, PA suggested something that, you know...
… Maybe it's crazy, maybe it's not, but there is some failure state here where we don't… in fact, we don't
… get through this digital URL dereferencing discussion. And I think the failure is we… almost like we would remove that from the spec
… So we can still publish the thing that we have consensus on, which is did resolution, and then this
… whole discussion would get pushed into the next charter. Like, I definitely don't want that to happen
… But we have 6 months. That doesn't mean we have 6 months. We have, what, 2, 3?
… and then we have to be wrapping up, right? Like, because there's still a whole bunch of stuff, like, probably Manu can talk about more on the timeline concretely, but
… We don't have that much time, and I'm just concerned that there's still a lot of things that we are not making. Program
Otto Mora: Manu...
Manu Sporny: Oh yeah, plus one to all that. We still have negative time, right? Meaning, like, we… we blasted right past the end of our charter. That is not good. We need to finish as...
… quickly as we can, and we need to make some hard decisions, right? So, just because we got a 6-month extension does not mean we let off the, you know, let off the gas and think we have, you know, um
… we can relax. So, plus one to that, I would be a very strong minus one on us feeling like, you know, we can spend, you know, weeks to months more discussing some of these contentious items
… Um, I think we need to… we need to very quickly come to closure on that, and
… and move forward. Um, my hope is that within the next month at most, we have all of these contentious issues, at least, you know, proposals and resolutions on exactly what we're getting ready to… what we
… you know, have consensus to do and move forward with it. So, yes, totally agree that it would be a failure mode to drag this out for 6 months and still not be anywhere
… Um, I don't think any of us intend that to happen, and I think
… Some of us will start becoming louder and louder about
… not allowing that to happen if the group looks like they're going that direction. Um, that's it
Otto Mora: Okay, I'll let Pierre close this topic, and then we can go ahead, Pierre...
Pierre-Antoine Champin: Yeah, yeah, so I raised this, uh, this possibility with the chairs. Now, of course...
… that means that the re-chartering… the charter would be slightly more involved than what I described and Manu described
… Meaning that if we want to defer Did URL dereferencing to a further version of did resolution, then we need to have this as a charter item. That means that the future
… The next charter of the working group would not be pure maintenance
… And so that might create its own friction, but, uh, but with this caveat, I think, uh, considering, uh, having a reduced, uh, dead resolution 1.0
… Out there, and defer something to a future version might also be a graceful degradation mode
Otto Mora: Okay...
… Uh, next
IIW Next week. Should we have calls or not? (5 min)
Otto Mora: So, for this one, uh
… I guess the question to the group would be, do we have a meeting next week?
… Or do we feel, given IAW, uh, most
… The people here would not be present, and we should just take a week off. Now here, consensus… Uh, on that
<JoeAndrieu> I'm going
Otto Mora: I am definitely not going. Just heard that you aren't going, Manu
… Uh, let's see who's calling
… Uh, okay, Marcus just joined, maybe we should ask Marcus if he's going to IAW
… Um, but I see Will has his hand raised, so go ahead
<pchampin> FWIW I'm not going to IIW, but I'm away next week
Will Abramson: Yeah, I mean, it'd be great to know if Marcus is going. My...
… the initial sense is maybe we just have the Thursday call, and we don't have the. Special public call. Um… well
… There is a lot of things to discuss. I'm a bit wary without Joe being there to discuss them. Gonna be slower, but
… Uh, if Marcus was there, hoping we could get things done
Otto Mora: Kind of looking at you there, Marcus. Alright, uh...
… I think you're going, right? I think I heard you
Markus Sabadello: I'm here and I'm planning to go home...
Otto Mora: You're planning to go. Okay. Uh, so...
… I mean, it seems that, um… We would not have Marcus and Joel. then we'll, I think, maybe… Let me just… skip the week for me? I don't know
… Go ahead
<swcurran> How about Joe and Markus hold an IIW session on the issues?
Will Abramson: Yeah, I mean, without Max and Joe, like, all of these discussions are kind of blocked. I mean, I'm wondering if there are other things that the group could be. making progress on… Independently of that. Um… we...
… Yeah, that's a good idea
<swcurran> And then come back to the group.
Will Abramson: Um
… Yeah, I don't know, what does the group think?
… I'm happy to cancel, but we do have a lot to be working through. Oh
Otto Mora: Zero?...
… Go ahead, Joe
Joe Andrieu: I just want to say, it might be useful to talk without us...
… I mean, seriously
Will Abramson: Mm-hmm...
Otto Mora: Manu?...
Manu Sporny: Yeah, well, I, um, I, I, uh...
… I think I disagree, Joe. Like, I appreciate the yes, maybe, but like, you know, if it's something that either one of you, you know, vehemently disagree to, then it's just kind of like we just spent an hour talking about something that
… we could have skipped talking about, because you could have told us right off the bat that you were like, no, that doesn't work for me. That's the only concern. I did really like Steven's idea that
… Um, you hold an IW, uh
… session about it. The, you know, danger there is, like, these are very involved topics, and, like, it would take an hour just to get people up to speed. Um, you could
… you know, I mean, we… but it's… but it, you know, it's kind of nice to get people to understand what these working group meetings actually look like, like, you know, passers-by at Iowa
… be a part of, like, this was an actual working group meeting where they were trying to discuss some pretty heavy things. Um, you know, if you couched it as that, that might… that might help, and, you know
… two IW meetings where we do that would, you know, could be… could be useful
… Um, but again, it's
… Yeah, it's not… we're not necessarily supposed to do that, because this is supposed to be a, you know, semi-closed W3C meeting. I don't know. It's… it was a
… I think it's a really interesting idea that we should consider, that's it
Otto Mora: I might suggest that...
… Marcus, Joe, and Steve McCown at least sit down for a beer
<swcurran> F2F meeting would be helpful, I think.
Otto Mora: Just my suggestion. Uh, Will, were you gonna
Will Abramson: Yeah, well, I mean, definitely, it would be a great chance for Marks and Joe to kind of sit in the same room and hopefully get on the same page, because my sense is still that...
… The disagreement is less than it seems, and hopefully there is a
… You know, maybe by being in person, that would help
… Uh, I guess, I don't think anyone's proposing that this is, like, a proper working group meeting, but it would be a meeting that discusses, like, working group topics, right? And then that would feed back to us the week after
Otto Mora: Perfect...
Will Abramson: And, you know, maybe it's really just Mark and Joe who attend, but it could be on the agenda for people to fit in...
… chime in. Uh, the other thing I was going to say is, to Joe's point of maybe we just hold the meeting anyway, like, I actually think
… I am… I do think that could be valuable, just because, like, yesterday we had a special topic call, and it was just
… Joe, it was like, you know, there was a few people, but it wasn't, like, Joe and Marcus, there wasn't arguing, but while there was, I think
… Was really useful is, like, increased shared understanding of what we were actually talking about
… And the question is whether that can happen. I think that… I think that could happen without either Marcus and Joe, at least us who are here
… Together, trying to make sense of the, um
… Questions under discussion, because it does feel like the group at the moment doesn't have enough people. Who feel confident that they have
… you know, like, that they can make a claim to, like, this is the way we should go, right? Like, it feels like Marks and Joe have very strong positions
… And then, while the rest of the groups are, like, you know, zero ambivalent
… So that's the only argument, I think that maybe doing one session, and it's more just trying to understand maybe both sides of the argument, and
… Just having a more open, sort of, educational discussion
Otto Mora: So it'd be more like, uh, just a… we don't make any decisions, more just understanding the various opinions and the intricacies of each...
… in more detail, which I think you're right, Will, we did achieve that yesterday. So
… under that understanding, I think that might make sense to at least have Thursday, but I see my own, which is… Go ahead
Manu Sporny: Yeah, I'm plus one, leaning more towards having a meeting, um...
… Uh, I think the ideal would be, like, a meeting with Joe and Marcus and Steve McCown on the other side of the phone, you know, at IIW
… with observers, uh, so we can talk through, you know, a few things. I think if not
… then talking about what the compromise positions could be, like, for example, I forget where I read this, but, you know, someone was like, well, what if we make a non-normative statement about the API and say that this is… oh, it was, um, I think, uh, Alex
… from, uh, checked, uh, chimed in and said, well, you know, what if we have non-normative text down at the bottom saying that, hey, you know, people do implement it this way, um, but it's non-normative, and the group's probably gonna go away from this in the future
… It would be a compromise. I don't necessarily like it, but I wouldn't object to it
… So we could talk about compromised positions for each one of the items
Otto Mora: Okay. Does this require a resolution type thing? I think not, right? It's just not...
… Okay
Will Abramson: No, no, I think we should have a call. I think it's the… we should have one call, let's not have two, because I think it would be too much, but...
Otto Mora: Right. Okay. So Thursday, regular holidays...
Will Abramson: Yeah...
Otto Mora: Okay… let's see...
Debrief from the Special Topic call for 22nd Apr \[1\] (5 min)
Otto Mora: Yeah. Okay. Uh
… So, on the debrief from the special topic call. Uh
… So, what I think we did was, uh
… sort of, um, understand is, uh, DDRL dereferencing
… as an abstract function, uh, that was part of the conversation, versus a more flexible logical algorithm, that was part of the conversation there, and I saw some conversation between Pierre and
… Um, Joe on this, then we debated the role of the dereferencer as sort of a distinct component, right?
… Um, Joe kind of argues the current specification conflates the rules of the resolver, dereferencer, and client
… Uh, Pierre here was emphasizing the need for a more unified interface
… Um, then we also got into, um, a little more conversation around, uh, this topic
… Uh, Ted suggested to resolve these ambiguities, we should maybe adopt
… A, uh, compound nouns, uh, resolver client to explicitly define
… the relationships, and reduce the linguistic blurring, I guess the words kind of
… Uh, being confusing, uh
… So that was another proposal there. We also reviewed Joe's proposed PR. Um, a little bit more
… Um, I don't know, Will, am I missing anything else? Uh, maybe you… yeah. Go ahead
Will Abramson: Uh, I would say two things, like, there was that discussion with… there was this discussion about, like, our terms in the spec, like, there is some confusion around...
… the use of client, and sometimes, I think in the spec, it talks about the client being a client to the did URL dereferencer
… and sometimes it is a client to the DID resolver. And sometimes the DID resolver is the DID URLD reference, but
… So, Ted proposed, you know, maybe we should have explicit namings for
… you know, resolver client, or dereference a client, but the sort of discussion also was like, well, maybe there is just one client, and it is the client of the resolver
… If we agreed that the URLD referencing happens on the client
… Which is, uh, at least Joe's position. The other thing that I wanted to ask Joe, really, to share is Joe shared an example of, like, a
… Um, dereferencing happening in a way that, you know, doesn't realize the function signature
… Um, and it's for a very specific case, like, the client is dereferencing a did URL within a verification method… within a proof on a VC, for example. They know
… what that URL is. I found that useful, maybe Joe can talk to it a bit more, but, um
… But then it's an example of how you might implement dereferencing without conforming to that function signature
Otto Mora: Yeah...
Pierre-Antoine Champin: to clarify what I was saying yesterday about the uniform interface, I think the value proposition of the deed resolution spec...
… is to hide the complexity due to the variety of, uh, did methods
… from the client, well, some, some client, uh, to be, uh, to be more precisely defined. Uh, and so, uh
… So, it seems to me that did resolution is definitely doing that, because the resolution is absolutely method-dependent. It is not entirely clear to me whether. dereferencing
… Is or needs to be method dependent, and which, uh, which argues in favor of allowing the dereferencing to, to, to, to happen
… Well, to be separate, which it is in the spec, to be separate from the resolution and the importance of, uh, talking about a dereference
… Versus, uh… versus just explaining what you can do with the result of the resolution, which is the document
Otto Mora: Okay. So, before we go any further, because that was just a...
… summary. Let's actually
… That's the key
DID URL Dereferencing
Otto Mora: Oh, okay, okay, I guess Sakim has. Uh, let me just change the topic
<Zakim> manu, you wanted to ask if we talked about it in terms of conformance classes.
Otto Mora: that you're already referencing, is what it is. And… okay, it's captured properly, and Manu is first on the queue
Joe Andrieu: All hail are AI overlords, that's all I gotta say...
Manu Sporny: I know, that's the first time I've seen Zakim being like, nope, sorry chair, not gonna listen to you...
… Um
… Uh, did have… did… in that discussion that happened, apologies, I have not been able to read the minutes yet, um, did we talk about this stuff in terms of conformance classes? Because usually when you talk about these things, these classes of things
… you usually talk about them in conformance classes. Like, if you talk about a client, then the expectation is the client follows a normative part of section blah blah blah of the spec. If you talk about a server, or you talk about a document, you usually refer to a normative section of the specification
… Um, so, for example, Otto, when you said, like, well, you know, the client may or may not do this, like, that's confusing from a conformance
… Standpoint, because you want to be very clear about what the conformance classes entail
<Wip> We did not
Manu Sporny: Right? So, you know, um… I don't know if we talked about it in that case. I would be pretty hesitant to start
… breaking these things out unless we expect them to become conformance classes. I do understand that it's easier to kind of refer to them separately
… But there is a reason we're referring to them separately, right? We are expecting to act… we're expecting them to act in certain ways
… Um, and usually, it's not a good idea to have, you know, definitions like that in the spec, and then not really tie them to normative statements explicitly
… in the conformance class section. Um, so that's my suggestion, is if we do break these things out into different, different things
… We think about, okay, what are… what's the conformance criteria for that thing? Right? That's it
Otto Mora: Yeah, we honestly didn't get to that level of how we would implement it, but uh… That's a good suggestion. Joe?...
Joe Andrieu: Um, yeah, so to your point, Manu, I think, actually, we do have, um, reasonable conformance classes for everything but the client...
… Um, the client's the least defined element in the architecture. Um
<pchampin> the current spec does not use the term "conformance classes"; but it does define them: https://
Joe Andrieu: like we talk about a dereferencer with or without HTTP, and a resolver with or without HTTP, and I think we do talk about it in terms of conformance classes
… Um, but I want to touch on a couple of things, including bringing in that algorithm that I mentioned on the other call
… Um, the hope-for thing, uh, that I want to share, that I also shared on the special topic call
<pchampin> not for the client, though
Joe Andrieu: is… on some levels, I agree with, um, Will that we're not that
<JoeAndrieu> Markus: If you have a DID-enabled application which dereferences something -> you have a dereferencer :)
<ottomorac> Minutes from here: https://
Joe Andrieu: as… maybe we're not as far apart as it appears, I'm going to share a statement from, uh, Marcus in the signal chat on that
<ottomorac> (yesterday special topic call)
Joe Andrieu: Um, which is that if we have a DID-enabled application, which dereferences something, then we have a dereferencer
… And that is absolutely my position, that it is the client that is the dereferencer
… And the separation between the client and the referencer is the source of most of our challenges. Um
<JoeAndrieu> Section 7.2.3
<JoeAndrieu> "Specifically, when a DID URL with a DID fragment is dereferenced, then Dereferencing the Resource is done by the DID resolver, and Dereferencing the Fragment is done by the client."
<JoeAndrieu> And yet, the client is defined as
<JoeAndrieu> "Software and/or hardware that invokes a DID resolver"
Joe Andrieu: Um, and an aspect of where that becomes a challenge in the current spec is just an example of this sort of conflation
… That I've tried to point out and get some help with, is these two definitions of, um
… Well, Pierre Antoine, exactly, that's right. Who's client? And it is not clear in the spec. Um
<TallTed> "whose client is it, anyway?"
Joe Andrieu: Um, but in section 7.23, we say, in a particular circumstance, when it did fragrance the reference, the references is done by the resolver
… And yet, a client is that which calls the resolver. So, in that case, the client is calling… I just don't understand how this works together
… Um, and it's an example of where it's confusing. I thought the client was doing dereferencing or calling a dereferencer, but now a resolver is doing the dereferencing
… And it sort of becomes this Spider-Man meme of everyone pointing at each other, so sometimes that's confusing
… Um, the algorithm that I shared on the other call was just an example of how I today can implement dereferencing
<JoeAndrieu> function checkProof(didUrl, proof) {
<JoeAndrieu> let baseDid = removeFragement(didUrl);
<JoeAndrieu> let fragment = getFragment(didUrl);
<JoeAndrieu> let didDoc = resolve(baseDid);
<JoeAndrieu> let key=getKey(didDoc,fragment);
<JoeAndrieu> let result = checkProof_(proof, key);
<JoeAndrieu> return result;
<JoeAndrieu> }
Joe Andrieu: Without implementing the… that function, that's… that's
… The thing that's getting me caught up with specific inputs and outputs, because I don't… I don't need to do that
… It's quite a burden for my DID-enabled application to be considered a conformant dereferencer to have to have those inputs and outputs, especially the
… highly burdensome content and resolution metadata. Like, I just don't need that stuff
… Um, so I put some JavaScript with an unknown library behind it, um, that is just checking a proof, and I've got a did URL, and I've got a proof
… And I pull out the fragment to get a base ID, and I get the fragment so I can work with it a few lines down
… I resolve to get the did doc, sending in the base did, and then I have a function that gets the key out of that did doc, and all I get back from that is the key
… And then my result is then I pass to a second check proof
… Um, uh, the proof and the key. And all of that can happen in my client, and I'm dereferencing that did URL into my current context so that I can use it
<manu> agree with what Joe just said
Joe Andrieu: And I really don't need the overhead, and it would be very frustrating for that use. To be something that is considered non-conformant
Otto Mora: Hmm. There was something else before we...
… You had shared an example from Checked, right?
… Or was that just
Joe Andrieu: Um… I don't think so...
<TallTed> "logical" client is not necessarily the same as "actual" client
Otto Mora: During the call yesterday? Like, some piece of code. Was that just from this same code that you just showed us?...
Joe Andrieu: Yeah, this is not from check...
Otto Mora: Oh, okay. Oh, okay, okay. Maybe I got confused...
… Okay, uh, Marcus
Markus Sabadello: Sorry, I couldn't make it on yesterday's call...
… Just want to say again, I fully agree that there are definitely
… Some improvements we should make about language and terms and term definitions. Uh, maybe we need to
… Maybe we do need some new terms, as I think Ted said, or someone
… and improve existing definitions. I also agree that there are
… some sentences or some statements in the specification that are wrong, so when… if there is a sentence that says
… the resolver dereferences something, then that's a mistake, and we should fix that. I think there are
… some open pull requests which fix some of that, but I fully agree that there are some. Some more mistakes, probably, that
… That need to be… that need to be fixed, um
… My wish would be, going forward, what I hope we can get to is that everybody tries to understand everybody's use cases, um
… Because when we talk about DDRLD referencing, there are quite a few different ways how that can go, right? If you
… if you just have it did with a fragment, and you're dereferencing that, which I think is what. what Joe has been talking about
… then, uh, life is relatively simple, right? And then you can do exactly what Joe said. You just have a client which does the dereferencing, and you
… just get the verification method out of the document, and you're done. So that's
… That's simple, um… and it should be simple, and nobody should… we shouldn't change anything about that
<TallTed> mermaid diagram tracking logical flow might also be helpful, especially in comparison to implemented flow (where 3 logical clients might be implemented within one software "client")
Markus Sabadello: But the fact is that there are also other ways how the URL dereferencing can go when we have parameters. Like, the service parameter, or when we have a
… path, uh, which sometimes is absolutely method-specific, right? There are DTRLs
… Uh, which used the path in a certain way in DataIndy, or in DataChecked. Um, then
… dereferencing is not that simple anymore, and it's not just something you can always do locally on just the Tit document
… And that is what I've been trying to point out, and I hope that whatever changes we make
… Uh, will accommodate all the use cases, and not just, uh
… Individual ones, and we shouldn't… we also shouldn't
… Declare existing functionality and existing use cases as, you know, hacks, or legacy, or
… of fallback, so I wish that we're all aware of what everybody's trying to do
… With the URLs, and improve the specification based on that
Otto Mora: Mm...
… Well
Will Abramson: Sure, um...
… Yeah, I wanted to talk about the conformance classes a little bit, but first, Max, just to what you said then, like, I think you said, like, the fragment is to simplicate your case, and it should be simple
… So, would you say that that, you know, dummy algorithm, Joe, presented. is a conformant. The reference, sir. Uh, there's a question, like, I'm interested, because
… I think it… you know, it definitely doesn't implement the function signature
… But it does do dereferencing in a way that… is valid. Um
… The other thing I wanted to say is about the conformance classes. I think actually reading this, like, a conforming digital or LD referencer, is any algorithm realized as software or hardware that
… Complies with the relative normative statement
… So, in 5, and the relative normal savings include both, like, the, um
… Dereferencing the resource algorithm, and the dereferencing the fragment algorithm
… But I think we often talk about in the spec, like, a dereferencer is really something that implements. The dereferencing the resource algorithm
… Or sometimes we talk about it like that, right? Like, and not the dereferencing the fragment at the moment
… So again, I think it's just where we draw the boundaries around this thing that we're talking about. Um… that's all
Otto Mora: Mm-hmm. There...
Pierre-Antoine Champin: Yeah, very quickly, uh, first, Joe, my comment on IRC was also your… when you say client, you don't specify which client what, and… and I… from your example...
… I seem to, uh… well, it seems that you're talking about the client to the resolver, because you're calling the resolve function
… That is clearly not a dereferencer client. Uh, it does some dereferencing, and I… my second point was basically to ask Marcus the same question as, uh, as we'll just… Did, uh
… I understand that Marcus' argument is that
… Us defining a function with a function signature doesn't mean that people cannot apply the algorithm
… in a bigger… in a bigger context, and not necessarily separate it in a separate component of function, but in Joe's case, the problem is that he doesn't produce all the metadata that is required by the authorism, and so that's
… In my opinion, what raises the legitimate question, is it compliant?
Otto Mora: That?...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, um...
… Joe, I think that what's going on here
… Is that your drawing, or seeing drawn
… A significant differentiation between the logical client functionality and the
… for lack of a better label, software client functionality. Um
… in other groups, in other focuses, and actually, I think it was even in this group, on this focus
… You've done some significant work with Mermaid and drawing the logical path of
… Uh, uh, execution and information
… From start to finish, and I think that's what's here, is that there's a logical path going on
… And for your specific software implementation, which I do not think is general purpose, I think it is specific purpose for your. implementation need
… Um, or rather, for your deployment need, this is your implementation
… you don't need some of the fuzzy bits around the edges. And that's fine. You don't have to have those fuzzy bits around the edges. You're making a special purpose implementation deployment
… That is just for your deployment needs. It's not to give to anyone and their cousin who wants to do something similar
… So, the specific path that goes from A to B with only 3 turns is fine for you
… But the general path is from A to B with 17 turns
… 14 of those don't matter to you, and that's great, that's fine. Special purpose implementation
… Nothing to worry about. You don't need to make a, uh
… Compliant declaration, because, again, it's not for general purpose
… And if it is for general purpose, then in fact, you do need to implement some of those fuzzy things that you don't see a need for, because you're making it general purpose, those things need to be around, so someone who uses your stuff
… For their general purpose, is gonna need that fuzzy thing
… And hopefully I've used enough fuzzy words that that's clear. That's it
Otto Mora: Alright, uh, Marcus?...
Markus Sabadello: So, to answer this question, though, I think what Joe is doing is a compliant dereference...
… I think it absolutely is, or it should be considered one, um
… having a DTRL with a fragment, dereferencing that the way how Joe has described it, I think should be… Considered compliant and
… in my mind, I… it feels already compliant, because I've always thought of the functions that we have in the spec. I've always thought of them as being abstract, logical
… functions that can be implemented in many different ways. I think even in the way how Joe has implemented this, the way how Cho has implemented it
… there is still an input and a result. You still start with the TDRL, and you get the verification method
… Uh, out of it, so in a logical sense, I think there is, that is an implementation of
… That function in in a way, um, we've found, we've already identified a sentence
… in the specification that feels wrong, right? There's a sentence which says you must not alter the exact signature of the function
… So that feels wrong to me. We can remove that, and we can
… weaken some of the language around these functions even even more, so we could say, for example, that
… that the support for the options and support for the metadata could be… could be optional, right? Joe, he doesn't want to… or he doesn't need
… to deal with options or with metadata, he doesn't need that. So, let's say that you can implement that logical function also in
… in a way where these additional things are optional, right? So I think maybe a way forward could be to
… To make all the language around these functions more flexible and
… And, uh, weaker, but in a logical, abstract sense, I think we still always have these functions in some way. It has been
… Really useful to have these functions when we then talk about local and remote and
… Clients and things like that and I, I looked up the
… the reference function that has been in the specification since 2020. I know that doesn't mean that it's
… that it's right, but I think this has always been useful, and if we can just
… Expand or make the understanding of these functions
… flexible to the point where also Joe's implementation would be considered
<Zakim> JoeAndrieu, you wanted to say yes, there is only one client that we need to specify
Markus Sabadello: compliant, maybe that's… that's a way forward
Joe Andrieu: Um… yeah, I think… I think what we don't have consensus around is that we should define more than one type of client. Um, I think...
… Our job under this charter is to figure out how resolution works. Um, and I think it is the
… Introduction of a different client that we now have to specify in a different way. That is the source of this problem
… And so… that's sort of where I get hung up, because we don't
… We don't… if my implementation here is a legitimate dereferencer. Then, uh
… the definition and the specification is incorrect, because I don't gather or return any of that metadata
… and yet the spec makes it very clear that I have to have a function signature that does that
… Um, I realize, thanks to Marcus's comment, that, uh, I should have made one more change to that algorithm, which is I don't need to return a result
… I could call a function that updates the state in my database
… Um, so I… what I need to do is check the proof. And in checking that proof, I need to dereference the did and the did URL, so I can get to the verification method to do that
… But there's nowhere in here where I need to implement that function, and that's my challenge
<TallTed> Function signature could maybe just make some return variables optional, instead of required.
Joe Andrieu: I think, Marcus, what you just asked for was, hey, we could define this process in a more flexible way. I believe that's what my PR
… does. I mean, that was the intention, is, you know, I went through the spec, I tried to understand what it was doing, I modeled the system and documented how I understood it in the
… in the threat modeling context, and said, oh, hey, I think this breaks down into 6 steps. I think those are easily understandable and describable
… And it doesn't depend on a third-party resolver or some other, I'm sorry, dereferencer
… some other function that has to have these inputs and outputs. So I think the right answer
… I know, for many of us, I'm just repeating myself, is that what we need to specify is an algorithm. And… and not a function
<Zakim> manu, you wanted to note it's not special purpose -- the weird thing is that the spec breaks dereferencing into two parts -- that's the weird thing. and to note that the spec has defined a "convenience function" that breaks dereferencing into a server-side algorithm and a client-side algorithm. and to say if it's abstract, we probably shouldn't have a function signature -- we should just name inputs and outputs.
Otto Mora: Manu?...
Manu Sporny: Yeah, plus one to that last thing Joe said. I think that… that is the… I think, Marcus, you said, hey, we can make the… we can weaken the language, make it more abstract...
… Um, and what I heard Joe say is, like, hey, this function signature is really to
… concrete, it's, it's too restrictive, let's, let's, uh, you know, make it more abstract. I'm hoping I heard both of you say the, let's make it more abstract and less
… you know, uh, restrictive, um, and I do think that's the right, right thing to do. Um, so working, working back, you know, back towards that. Um, I think it's
… So, I found myself, as an editor, um, you know, editing the spec and having people argue against, you know, certain things in the spec
… Um, and I'm like, yeah, but… and people are like, yeah, but there's a sentence that makes that, you know
… not true, and I'm kind of like, yeah, but like, pretend that sentence does exist. It's true then, right? And people are like, yeah, but you need to remove that sentence, remove the sentence, right? And I think that's what we're talking about, like
… there is very restrictive language in the specification, Marcus. I think you've said, yeah, let's remove that restrictive language. So, let's remove this restrictive language so that, you know, we can get on to the next thing, right? So, you cannot change the function signature
… Let's remove that language. I think that's what we're saying. Once we do that, all of a sudden, we will have accomplished at least
… you know, something towards making that function more abstract. Um
… Okay, so, uh, sorry, I have to find
… where I put down the things I was gonna say, um
… Okay, so the reason the dereferencing function is weird, so I think I disagree with you, Ted
… Um, I think the… with something you said, I can't put my finger on it, the
… The reason the dereferencing function is weird in the spec is because it is written
… it is written to be a convenience function. It's like we have written a convenience function into the specification. We have written this thing where the server side does one half of it, and the client side does another half of it. The server side retrieves the resource, you know, can potentially do a bunch of stuff, and then maybe the fragment processing
… you know, happens on the client, or maybe it doesn't, maybe it happens on the server. And I think, like, that's really confusing. Dereferencing
… dereferencing is supposed to be a complete process that does include fragment processing. And when we write it such that it's not like that, and I don't think it's like that in the spec right now, could be wrong
… that's what makes it, like, super weird, right? So, let's not make it super weird. Let's… let's make the dereferencing function
… truly abstract, right? The function signatures are throwing people off. People look at the function signatures, and they look at a sentence that says, you cannot change the function signature, and they're like, okay, that's not abstract, that's a very concrete function signature, and I can't change it. I can't mix in information that I need to,
… I can't decide that I don't, you know, need some of the return values there
… it is a very, like, rigid, quote-unquote abstract function. It's confusing people. So let's… let's change… we don't need it, right? An algorithm
… All an algorithm needs, especially if it's abstract, is a bunch of inputs and a bunch of outputs
… We can do that. I don't think we absolutely have to provide a function signature
… And that'll make it, you know, more abstract, and then let's loosen the requirement for some of the return
… uh, you know, properties. I think that, potentially, Joe, I don't know if that… it gets us to where
… you would be fine with it, right? So again, let's not split the dereferencing function up into fragment processings done on the client, and you can do a whole bunch of other stuff on the server. I think we can just be silent about it, but just unify it. Right? Um
… Uh, and then let's get rid of the concrete
… function signature, because it's confusing people, like, it is. Um
<TallTed> I think manu is actually agreeing with much of what I was (trying to) suggest(ing) yesterday.
Manu Sporny: We don't need it in there to accomplish the task of at least putting in a concrete, you know, algorithm, and let's make sure that concrete algorithm does the full dereferencing
… Uh, process. It doesn't split half of it into the server and half of it into the… into the client. If that still exists. That's it
Otto Mora: Marcus?...
Markus Sabadello: Yeah, let's make it more abstract and remove that sentence that you cannot… Change it in any way, um… And then, I mean...
… an algorithm that has inputs and outputs, that's… that's what we can write as a… that's written as a function right now, right? It's just maybe
… Not clear enough that it can be implemented in very flexible ways
… Nobody's saying that the reference or the function needs to be a separate component. Nobody is saying it's
… It's a remote service, and nobody should be saying that it. It has to have that exact
… Signature, but still, it's a process, it's an algorithm that has certain inputs and outputs, and that's
… That's what we should be emphasizing a bit more. If we
<TallTed> The function is the algorithm is the black box, each with the same list of (required and optional) inputs and (required and optional) outputs.
<manu> if we do all those things Markus just said, I think it would address a number of concerns.
Markus Sabadello: if we want to remove that function the way it's written right now, then I think that's not a good idea, because it just captures the inputs and outputs of the algorithms, that's… That's what it does, if we
… If we say we want to remove that, then we could also remove the resolve function, right? Because you can also resolve these by just, uh
… By just following an algorithm, and by just doing what a method specification says, and we
… We chose to write that in the form of an abstract function, and we do the same with the dereferencing. That's all it is, it's just a way of
… Writing the… writing down the inputs and outputs, but let's make it as… As flexible as us, absolutely
Otto Mora: appear...
Pierre-Antoine Champin: Okay, so I'm with Marcus on this idea that function and algorithm maybe are not that different, but I'm hearing that a lot of people disagree, so I could definitely leave with...
… changing the language and maybe getting rid of function and, more importantly, signature. I wanted to come back also on something Joe said about clients, and the fact that we are defining too many clients
… I may be wrong, Marcus, correct me if I'm wrong, but it seems to me from what you said and wrote that you would consider that anything that applies, that follows the
… resolution algorithm can be called a resolver. Anything that follows the different dereferencing algorithm can be called
… a different cell. That being said, sometimes a piece of code will follow that algorithm for its own sake, and that for its own usage, and that's Joe's example. And in other cases, a piece of code will execute that algorithm
… for the benefit of somebody else, and that's where it's a separate component of the general purpose thing that Ted was talking about. And the term client is very confusing in that respect, because it really focuses on the second use case
… Uh, I think we all agree that, uh, um
… dereferencing will… uh, sorry, resolution will very often be performed by a separate, uh, separate component, because that's the… that's the boundary that I was talking about between the
… thing that understands the complexity of diversity methods, and the things that… and the thing that don't want to understand this, but the dereferencing, we all agree also, I think, mostly, uh, the dereferencing can be done, uh, on either side of this boundary. Uh, so
… I know that the term client is defined also in a very generic way in the spec, but still, it has a lot of connotation, and even with this very generic definition, I think it's hurtful to talk about
… a dereference client. Because, again, it seems to exclude those cases where the application is doing the dereferencing, is performing the dereferencing algorithm
… Just for its own usage, um, that, that, that doesn't quite fit, so I think the, uh
… I'm now quite convinced that the term client in this scenario is harmful
<Zakim> manu, you wanted to note I don't think people are saying "remove the guts of the algorithm" and to "any other algorithm that achieves the output of the algorithms in this document are valid."
Otto Mora: Okay. Um… I know...
Manu Sporny: Um, just going back to one thing you said, Marcus, uh, about, like, you know, just leaving it out as kind of a black, you know, a black box, uh, algorithm. I don't… I don't think anyone's saying that. We're not saying remove the guts of the algorithm...
… Um, so just wanted to note that, like, again, that would be a very, um
… a big change, and I… I don't think anyone's arguing for that. Um, the other… the other part is, specs like this, algorithm sections of specs, usually say, like
… This is one way to solve the problem, but anything else that you do that gives you the same output is totally valid
… Like, anything that takes a totally different set of inputs and a totally different set of outputs and whatever, but gives you the same, you know, end result
… Totally fine. We should say that in the spec, right? Because we don't right now, which makes it seem like you have to
… explicitly implement, you know, everything in that… in that algorithm. Um, so that's some language we should consider
… adding. Um, it… it helps implementers. That's it
<Zakim> JoeAndrieu, you wanted to talk about necessary inputs and outputs
Otto Mora: Okay. So...
Joe Andrieu: Yeah, um...
… So, I think PA that, um, actually client is very specifically defined as the software that calls the resolver
… And I think that's the tension, is that it became software that calls a dereferencer
… But if my dereferencer is a legitimate client of the resolver, now
… that's the source of the confusion. So I think… I think we have consensus that we need to define how a client calls. resolution. Um
… I don't think we have consensus about defining any other kind of client. Um, but I want to talk about this difference between algorithm and function, and specifically why resolution is different. Resolution, we are talking about
<manu> agree with Joe... clients usually have HTTP APIs they call (not always, but usually).
Joe Andrieu: a formal interface that goes over the wire that is the source of interoperability. So that has specific inputs and outputs that are… that we are binding to HTTP
<manu> (or remote APIs)
Joe Andrieu: for this purpose of interoperability. And I don't think we've met the threshold of buy-in to go to that trouble for a dereferencer. Um, the dereferencer
… As we turn it into an algorithm, we need to pay attention to what are the necessary. inputs and outputs
… And I believe the only necessary input to dereferencing is the did URL. And the only necessary output is nothing
… the function can entirely operate by side effects. It doesn't have to return a particular value of any particular kind, because the function may just apply the results of resolution
… and immediately dereference into the context of the application. And so, uh
… That is what I attempted to do in that PR, is define the algorithm in a way that did not restrict
… the implementers from what sort of inputs or outputs they do or do not have to use, other than, hey, you've got a DID URL. Here's how you dereference it
… So
<manu> we shouldn't align the algorithm to a corner case where you don't get a resource back.
Otto Mora: Okay. I know that both Marcus and Joe wanted to jump here, but...
… Yeah, forgettingably, we are nearing time, and I wanted to get, uh, Will
Will Abramson: Yep...
<manu> we can say the resource can be null
Otto Mora: Uh, kind of the closing word on this, and then, obviously, we will have the session next week...
Will Abramson: Yeah, well, I see we're closer to time. I won't say anything more on this topic. I will just say I...
… I think this conversation was very positive, and I really appreciate people continuing the dialogue
… I mean, Otto messaged me saying that the vibes were good. I do agree, right? Like, it's hard
<TallTed> I think the transcriber-bot needs to be taught to limit its IRC line lengths. (In the minutes, look at the lines following the line containing "convenience function into the specification").
Will Abramson: Sometimes, but I feel like we are… you know, this is a real problem, and we are working through it, so
… No, thanks. Hopefully we'll get through it soon
Otto Mora: Thank you for the civil discourse. Really. It's...
Will Abramson: Yeah, for sure...
Otto Mora: It's not easy, I know...
… Okay, well, uh, I guess, uh, we'll have a session at IIW next week? Um… yeah. Virtual slash
Will Abramson: Yeah, I look forward to hearing how that goes...
Otto Mora: Impress. Cool. Thank you...
<ottomorac> transcriber-bot, pause