Meeting minutes
<ottomorac> transcriber-bot, resume
Otto Mora: Okay...
Will Abramson: Okay. Welcome, everyone, to today's...
… Good working group special topic call
… Um
… So today we are just going to be focusing on the PR Stephen raised about the algorithm for determining the handling strategy. In the dereferencing algorithm
… Um, so that's PR335. I don't know if everyone's had a chance to read it, but hopefully people have at least had a little glance, and we're just going to dive into it. Um
… Yeah, so before I get into that, just, like, tomorrow, we are gonna… Be having this, um
… proposal, I'm gonna do a vote, and then hopefully we're gonna get through this
… discussion about the inputs to the DID resolution algorithm, so we'll start the call with, like, 10 minutes. I think Marcus wants to present some things to get them on the record, and then
… um… Yes, that's just a flag for that
… Okay, so… topic this
… You know, if people want to respond to that, we can do that, but we'll be taking a vote by halfway through the call, at the latest. No, no, no
DID URL Dereferencing Algorithm - determine handling strategy
<Wip> w3c/
Will Abramson: Okay, uh, yeah, so this is the PR. I don't know, Steven, if you had anything prepared, I didn't, like, check if there's anything, I mean, we could just… um
… Have a look at the
Stephen Curran: Yeah, the only...
Will Abramson: um...
… the text, like, I could even share my screen, or
Stephen Curran: Um, do a pass through the extensions. things that I've got other than just the text. I didn't prepare a presentation or anything, but um… the text is pretty short and to the point, so I think it might be reasonable just to go through it that way, but I did...
… registry, and found all of the extensions that were relevant, and that might be worth looking at. Um, we also have that question that you and I. We're batting back and forth in the comments about
… Um
… you know, there's different parts to DID URL dereferencing, and… how
… Um, different parameters apply at different places, and so there's the question of
… Um… Um, you know, our elements… I should include path in that, so there's the parameters of path, and our elements
… there's no global picture of the parameters that actually get consumed and impact things. Like, there could be parameters that just get completely ignored
… And I don't think there's a way to notify of that. So I did want to get the group to discuss that. So those are the things that I want to go through
Will Abramson: Okay...
… Great. So, I don't know if everyone has read it, so maybe I can share my screen, and we can just… I'll just sort of roughly go over what the algorithm says today. Um… I see Joe on the queue, so I'll let you go, Joe
Joe Andrieu: Uh, yeah, thanks. I do want you to read through it. Um, this inverts quite a bit of the strategy that, um, or the algorithm that I had put together, and I think it's broken for some important reasons. For example, if I have a version ID query parameter...
… And it builds backwards. It is it needs to be a bid document, retrieval strategy. So the very first step, like, that's usually in the other algorithm I did, that was the fallback. If you didn't find any other strategy, then the only strategy left is did document. So this is put first
… And I think the same thing happened in the in the next spec which is it says hey if it's did method specific then it overrides stuff. And I think did method specific should be a fallback if the other things don't apply. So I think there's some order of operation here that I think are not quite right
Will Abramson: Okay, thanks, Joe. Yeah, I will note that I saw that… I mean, yeah, well, I'll pass it to Stephen...
Stephen Curran: I mean, I guess he did put it out. I… Joe, I don't understand how you...
… Say that the, you know, the first step says if it's a fair URL, did you get it?
… then you return the DID document. I don't think that's… If the DID URL is a bare DID, has no parameters, no path
… Too controversial, maybe, in having it there, as opposed to a fallback
… I've also got the fallback, which is also returned the did docs. So I'm confused as to why that would be problematic, but that's okay. Let's take a look at it
Will Abramson: Yes, okay. I mean, I'm just going to walk through the top level things. I mean, so, right, we're going into this algorithm We have executed a resolution request. So we have a did URL...
… We execute a resolution request, and we get back a DID resolution result. And then the purpose of this algorithm, 5.1.3, is to determine the, like, handling strategy, we're calling it here. So, like, how are we going to handle this DID URL? to retrieve a resource, right?
… um… Well, algorithm we're going to use, I suppose
… And then
… Yeah, so there is this question of, like, if it is a bad DID, I don't think this is wrong, like, so if it's a bad DID, return the DID document, but I do question… I think I'm more on Joe's point, where if we have this fallback
Stephen Curran: Okay. That's fine...
Will Abramson: Like, it's not… you don't need it, right? Like, it's gonna fall back anyway if it's embedded, is my sense of that, but… Um, okay, then there's this question about did method specific, um, so...
Stephen Curran: Yeah...
Will Abramson: Can you give an example of what this would be? Or is this something undefined that we don't know about?...
Stephen Curran: No, I think this… I mean, there's a very real one. I mean, CHEPT went through a lot of work to define...
… Um, however, at the end of the day
… When you have a check DID, and you use a DID
… links resource. What you want to do is. a generic, non-DIDMET-specific thing called DID-linked resources, and that's great
… process a data from the checked blockchain and retrieve a resource off the blockchain and return it. Well, to me that is did method specific
… And so I'm very much talking about where
… you get to that. So they give another example, and let me… they give another example where you can have a DID web with a DID linked resource
… And the way that example works is you have a DID web, the example they use, you have a DID web DID link resource, so you get that back and then you would then process the resulting DID because the result of that is the DID. dereference that
… And that did is a did checked resource. Now if you do that again, dereference it again, you're just in an infinite loop. So you eventually have to stop at that point and you have to say, oh, this is a did check
… resource, and I need to use the DID method-specific code. and did chat, or at least I think that is implied. Um, because
… That is the
… resource you're trying to get to, and the only pointer to it, the only reference to it, the only identifier for it, is a DID. Is a DID URL, not a DID. A DID URL
… So that's the example that I use for that one
Will Abramson: Okay, well, I see there's a queue, so we can go through the queue, and then keep going on. Uh, Manu?...
Manu Sporny: Um, yeah, this was on the previous statement about, like, you know, having… doing all the generalized stuff early in the algorithm, and then falling back to the, you know, DID method-specific one, uh, towards the end. Uh, plus one to that, so I think I'm agreeing with Will and Joe's general statement...
… But, you know, looking at this algorithm, I'm kind of like, is it in that order already? Um, so, so just light feedback on, I too would prefer that we do, you know, as much of the generalized stuff up front as we can, and then go. Drop back to the DID, you know, DID-specific or extension-specific stuff. um
… Uh, towards the end
… And, and I realized even that it's complicated, right? Because, um, okay, so, so that was the first statement. Second statement is, uh, it doesn't really matter
Stephen Curran: Could I just quickly respond to that, Menu? Just real quick...
Manu Sporny: Sure, and I've got a second thing after that, but please go ahead...
Stephen Curran: Yeah, yeah, but my… the reason I put it there is because...
Manu Sporny: Mmhm...
Stephen Curran: If you keep doing this algorithm over and over, you never get to the DID method specific. And so that's why I put it at the top. That's it...
Manu Sporny: Yeah, yep, yep, yep, yeah, yeah, that, that, that, um, it makes sense to me. I, I think the, the other, the other comment is it...
… Doesn't really matter. Like the algorithm doesn't really matter as long as the outcome is the same, meaning that we just need an algorithm that that works. It doesn't have to be pretty or perfect or, you know, and whatever we can rearrange
… the algorithm in CR, as long as the output isn't changed, right? So
… So I want to make sure we don't get wrapped around the axle too much about like, oh, well, you know, step three should happen before step four, unless there's a bug, because we can always make this nicer in CR if we want to, understanding that we want to get it right the first time. I don't think we should get too wrapped around, like
… You know, um, the design philosophy, if the outcome is the same
<Zakim> JoeAndrieu, you wanted to discuss how did linked resources is a property-based retrieval strategy usable in any DID Document
Manu Sporny: no matter which way we order the steps. That's it
Will Abramson: Okay, thanks. Bye. Joe?...
Joe Andrieu: Yeah, sorry, Manu, I don't agree, actually. I think the point of this conversation is to figure out the steps. I construct a very different set of steps. I'm seeing a bunch of holes when I compare the two of them. Um, one of them is, I...
… firmly disagree that DID-linked resources is a DID method-specific, um, algorithm. It is a property-based algorithm in the metadata document, and I could create another DID method that uses that. And so, you're not going to know from looking at my
… Did method specification in the did whether or not I have a property called did linked resources. So the did method specific is also in the forefront here means we're going to have interoperability problems with any did method
… Um, that defines things differently. So this is an anti-interoperable strategy. I believe the DID method-specific stuff absolutely needs to happen at the end, and that we should be processing the query parts and the parameter parts before that, so that we can use these interoperable mechanisms that we have come up with in our conversation, such
as having
… An object has type path handler. Right? So I think we've come up with mechanisms that are not gonna be exposed with this algorithm
Will Abramson: Okay. Thanks, Joe. Steven?...
Stephen Curran: I'm gonna try again...
… DID linked resources is not DID method specific. However, in the example where it is used with DID checked
… It is… the handling of it is specific to chat
… So while I completely agree that linked resources can be used in a variety of ways with different
… did methods, and I gave an example of one earlier
… I would assume that… If it's used within checks, the behavior is intended to be that you go to the blockchain ledger and you pull a resource off it. And what I'm wondering about, and I'm
… If you need to pull something off the did check ledger, that would be handled by the did checked method and that's why it's there
… If there's some other way to handle it
… I'm open to that, but I don't understand another way to do it. But that's why I put it there, is because
… If it falls through, it'll never get down to did method specific because it'll keep being interrupted by identified object
Will Abramson: Uh, yeah, I put myself on the queue to respond to that, because. My sense is...
… if the, you know, like, if a DID-linked resource is also an identified object, like we kind of discussed, right? Like, there's DID-linked… currently, we know of DID-linked resources, we know of linked resources, and we know of these services with a specific type
… And I believe, in our previous conversation, we discussed defining a type, right? So all of these things would
… add, or any… anything that wishes to handle paths would add to itself, and say, look, hey, I handle paths. And then, you know, you do this algorithm, which I think is here, to select
… the object that you are going to use to handle the path. And for me, the did method specific part that you're kind of referencing is, okay, how do I handle this object that is a did link resource, right? I think you are right. There is, you know, if that's a
Stephen Curran: Okay...
Will Abramson: for, right? Like, this is just saying, identify the object. if that's a did-linked resource stored on check, like, I'm gonna have to interact with the checked ledger. But that is encapsulated in the retrieval algorithm, or whatever we're calling that now, which is...
… that is going to define how I… how I handle the path and retrieve the object, how I… used it. And I think we can say
… that there are no did method… well, I think we really should be saying there aren't any did method-specific approaches. If you want to handle path, you should be using this path handling object type
Stephen Curran: Okay, and so… and so what you're saying is...
Will Abramson: Uh, well, let's do the queue, Steven, if...
<Zakim> JoeAndrieu, you wanted to say that is a handling strategy invoked based on the property in the DID document metadata
Stephen Curran: Okay...
Will Abramson: Cool. Uh… But maybe that's too far. Joe?...
Stephen Curran: I'm happy then. Okay, that makes sense...
Joe Andrieu: Um, yeah, my point was mostly the same as what Will just said. Um...
Stephen Curran: Okay...
Joe Andrieu: The retrieval strategy of a did link resource may in fact need you to talk to the checked, ledger. But at the point here at step two we don't even know we don't have the information to know if that strategy is the one that we need to use. So, I can't look at, uh, did WebVH, um… Ah, ah...
… uh… set of data. Like, I can't look at the URL and know if, somewhere in the process, I'm gonna get a DIDLINK resource attached to it
Stephen Curran: Okay...
<Zakim> manu, you wanted to ask about "property specific" handlers?
Joe Andrieu: So we don't have the information at this point to make a determination. I think it's part of if you have a did linked resource property in the metadata, then we have to invoke this this strategy as defined by did linked resources, which may need you to talk to the ledger...
Stephen Curran: That explanation makes sense to me. Good...
Joe Andrieu: Cool...
Will Abramson: Great. Uh...
Stephen Curran: So I'll take out… I'm taking out 2… oh, I'm taking out 1 and 2...
Joe Andrieu: Well, hold on, let me… I guess the other half of that was… wait...
Will Abramson: Ah, you got it. Alright, let's do a queue. Let's do a que...
Joe Andrieu: Sorry Will. We do have the expectation that of our two hundred plus did methods that there may be some that have method specific path handling...
… Um, so I do think we should still have a fallback. Um… Um… and we don't have a way to even inventory that. We don't have the resources to actually go and find them. Because it… to… to
Will Abramson: But...
Stephen Curran: But you're saying we… sorry, I was just saying we take it out of where it is now...
Joe Andrieu: Okay, fair enough. Okay. Yeah. I think two should be, like, maybe the last one or or the last one...
Will Abramson: Okay, Stephen, let's do the queue, if you can jump on the queue...
Stephen Curran: We haven't, yeah, we haven't gone through the rest of the algorithm, so 1 and 2 are gone. Yeah, sorry...
Will Abramson: Hahaha...
Manu Sporny: Okay, and by gone, we mean move further down in the algorithm, not delete it entirely, right?...
Will Abramson: Uh, but yeah, I think I agree, one and two are gone. Manu, sorry...
Manu Sporny: Okay, all right, that...
Stephen Curran: Yes. Perhaps, yes. I'm just saying, let's… we're going through this in order, and so right now, the first two are… are out from where they are...
… Yes
… Yep
Manu Sporny: Yeah, let me strongly assert they're moved down in the algorithm somewhere, we haven't determined where yet, because they do need to exist somewhere in the algorithm. So, are we also talking about adding a path...
… uh… sorry, a property-specific, like, step? Is that what I'm hearing, Joe, you say, and Steven, you agreeing to?
Stephen Curran: Well, I think 3 is now step 1, and now we're going to continue on with. discussing the rest of the algorithm...
Manu Sporny: Okay. Okay. All right. Yeah, let's just go. I'm just… I'm wondering if there is an additional step here in that you've got some kind of...
… property-specific processing based off of DID extension, or extension-specific property… uh, uh, processing, right? So, like, you know, the resolver knows of a variety of different extensions, and in, you know, step
… whatever, uh, it is allowed to use those to… to do, um, you know, dereferencing, and then
Will Abramson: Mm-hmm...
Manu Sporny: If it's not that, then the the one after the step after that is the did method specific processing. Is that what others are thinking?...
Will Abramson: Well… Well, I put myself on GitRoot to talk, like, to get us back into that algorithm, and I think you're right, right? Like, this… to me, this identified object is about the property...
… to me, this identified object is, like, we're trying to select some object in this DID resolution result that is going to tell us the handling strategy. And… And currently, I think how this algorithm works is we are selecting, uh
… we are going to look at our query parameters, right? Like, our query parameters might be like service. The service query parameter is identifying a specific object by an identifier that we should use, right?
… And then there is some question about any other query parameters that might be extensions that we should… that also target specific objects
… like, for example, maybe in the future there's some like linked resource query parameter that acts similar ways that that could happen. And we should allow that. Then I think there's this, you know, like, so we've we've applied all the query parameters that we understand
… And then we have to decide, okay, which one of these objects, based on the things that we've applied, which might be none
… do we select? And I think that is then using the path, and this path handling object type
… Right, so we collect all the pass handling objects left in the DID document that
… you know, that we need to select from, and then we use this… this… the path in the DID URL to
… identify one of these objects. And if there are multiple, it's an error. That was my reading of the algorithm. um
… I mean, maybe it would be good to have like an example here. Together. Um
… So, that is all of the properties for me. Like, these identified objects are what we're now calling, like, path handling objects, and the DID resolution result is expected to have
… some objects in there that say, hey, I'm a pass handling object, I handle. Ah
… But then this part would just… I guess the DID URL might not have a path
… Like, you would just fall through here, and probably go to default, unless
<Zakim> JoeAndrieu, you wanted to advocate for service query parameters first
Will Abramson: One of these query parameters are explicitly targeting a. Joe?
Joe Andrieu: Um...
… Yeah, I'm looking through the PR preview for that process object section, which maybe would… Answer what I'm looking for. But in this this. Oops
… In this process, I'm not seeing the properties pulled up
… Um, as an invocation. Nor am I seeing that if there's a service query parameter that that takes priority
Stephen Curran: That's in 3. That's in 3...
Joe Andrieu: Um...
Will Abramson: Okay...
Joe Andrieu: Right. My understanding was our consensus in previous conversations was that if the service query parameter is presented that that has priority. Um...
… This doesn't seem to suggest that. Um, but I, I get
Stephen Curran: It's the first step in the algorithm...
Joe Andrieu: So we got rid of 1 and 2...
Stephen Curran: Yeah. So, 3...
Joe Andrieu: Right? So… so you're saying if there is only… only a service query parameter, then...
… What if there are multiple query parameters? And what about query parameters outside the specification?
Stephen Curran: So that's… I don't have a joke...
Will Abramson: Yep...
Stephen Curran: Please read step three...
Will Abramson: Well, no, I can switch that, because I...
Stephen Curran: I'm sorry, I'm frustrated...
Will Abramson: I… I also...
Stephen Curran: Yeah, um...
… Yeah
Joe Andrieu: I'm frustrated too. So, like, go ahead, Will. We got a queue to manage, and I don't want to be disruptive...
Will Abramson: In the comments around this. I'm not on the queue, but I will imagine I'm on the queue and put myself on it. My comment was similar that I mean, we did say service query parameter takes priority. I mean, I have some, there's some commentary, good commentary on the issue...
… Processing all query parameters that you understand. Uh, I do think, really, step 3 should be about
… That are… you know, and then this is another thing that we don't really have well-defined, but that are about selecting objects in the… Um
Stephen Curran: Yep...
Will Abramson: In the document. I don't know what I tried to name it. I didn't name a very good job. I think there are like three types of query parameters that you could have in a DID URL, right? There are DID resolution parameters. We don't care about these, and we also don't even know which ones are them, right? Like maybe we know version ID
and version...
Stephen Curran: Yep...
Will Abramson: time, but there might be others in the DID URL that we don't understand, but we're just going to pass on to DID resolution, and it's going to do some stuff and return back. And then there's these ones that are about targeting a path handling object. I had in here, I mean, we can come up with a different name, these are like
service...
… And I think service type, and even though currently we've said we're not going to standardize service type, that is an extension that, you know, we're going to move it to extensions, we need to have a way for our algorithm to handle all of these extensions that might be about targeting path handling objects
… And obviously, you know, people doing dereferencing might not understand service type, and I think they're just going to ignore all the query parameters that they don't understand
… Uh, but service should be processed, and it should be processed first, before you get into the actual path handling bit. Um, you know, for me, like, processing service is, you are identifying a specific object in the
… document, and if you don't find that object by that ID, then it's an error, right? You've got a not found error or something
… there is no path handling that happens here, right? Because
… Path handling is just about filtering from the set of objects, if there are more than one. Uh, and then I'll just go, and then there's
… query parameters, which are kind of like… I mean, we went a bit back and forth, me and Steven, but they're, like, strategy-specific
… Uh, which is about some transformation to the… the result. And all of these, or maybe not relative rep, but these are about… these are only specific to, like, the DIV document strategy. Um
… Which is… And then, Stephen mentioned one more
… uh… result parameters, so these are applied at the end. But I think the main thing for this step, where we're at right now, is there are some parameters which are about targeting a path handling object
… And those parameters should be applied first, right? For me, as a client executing this algorithm, I need to apply all of the query parameters that I understand are about targeting a path handling object. I think that's not quite in this algorithm yet
… Uh, sorry, that's long for me. manner
Manu Sporny: Yeah, I think a plus one to that, Stephen, what might help here is to break it into those categories that, or some subset, I don't care about what the categories are, but having examples where we're like, you know, um...
… I think that would help
… process, you know, these sets of parameters first, process these types of parameters second, and maybe these types, you know, third. I don't know if we can cleanly do that. But then giving examples of, like, version ID and version time, and then service and service type, and
… clarify, you know, what step 3 is doing. Because right now, it's, you know, it's good, but it's vague, it's a bit vague, and I think adding those kind of classes of parameter processing would
… Clarify if the implementers on like, you know. They should be thinking about, you know, these things
Will Abramson: Hey, thanks, my name's Steven...
Stephen Curran: Okay, 3 things, um...
… On that last bit that Manny just said, I think it would be a good idea to put before, long before this, as part of the dereferencing, to talk about those classes
… of parameters and how different aspects of this algorithm will process
… different subsets of the parameters, because
… like, a version ID, version time that you just mentioned, well, they've got
… a place above this. those have been processed and would be ignored in here, because we've already done the DID resolution by the time we get to here. So, anything that applied the DID resolution. So, I think that… that classification that Will put into the comment, that should go into the document, but in a
… I think I like what Will said. I agree with it that the we've got to broaden the I've got to broaden the wording in the identified object paragraph. Um, to include that
… You know, all parameters get processed. Those identified that would identify a specific object would take precedence at this point
… And then the last thing I wanted to say was
… I think when… once we get past this and into the handling
… I think we do want to pass in the DID URL, because
… A service object that is also a path handling object, and you've got a path. In it, um, the
… identify object strategy would still need the DID URL, because it might say, oh, well, this service type is a
… you know, I picked it out because I selected the service, but I also passed in a path, and I want to use that. So, um
… Even though we, what we don't wanna do is have a path passed in that gets ignored. Um, so the
<Zakim> JoeAndrieu, you wanted to the primacy of service is to bypass query parameters you don't understand. and we need to search for path handlers even if the path is "empty"
Stephen Curran: handling of identified object would have to take into account the DID URL, not just… Wouldn't be limited to that. Um… That's it
Will Abramson: Steven? Uh, Joe?...
Joe Andrieu: Uh, yeah, two things. One is, I do think the primacy of service was in part to bypass...
… Um the query parameters that, uh the caller may not know
… Because if there is a service endpoint then this is this means invoke that service. And I think
… So I just wanted to anchor that. Like, I think it's an important separation from the rest of the processing of the other query parameters. Um, the other thing I wanted to point out is that, um
… Path handling algorithms may work just fine with an empty path
… Um… if I put a domain name into the browser, it works
… Um, and so there is, you know, an architecture for, hey, you don't have a path, but because your DID document has a path handler, we should use that instead of just returning a DID document. Um… So I'm I'm not sure
… um… We moved away from a property-based analysis here, Steven, and I'm not sure what we're getting from it
… So, that confuses me here
Will Abramson: Uh, I'm sure… Steven?...
Stephen Curran: Uh, could you explain what you mean by...
… That… like, if you just pass in… the last thing where you just… there's a… task handling in the DID document, and we're supposed to handle it
… How would that work? I've been reading the extension called resource
… Um, the parameter, and it had this similar concept that if you have the parameter resource
… And it was just there as like resource true. You were supposed to infer something from the did
… the doc to get an object, to get a resource, and I just wondered what that meant
… Like, how would you do that?
Will Abramson: Yep, sure...
Joe Andrieu: So, um, I'm not sure, um...
… Uh, I was specifically talking about properties, not parameters. I can… in the algorithm I put together, I specifically walked through the information that was available, and I structured it in a way that I felt, uh, a
… A dereferencer could walk through and say, oh, there's a service
… query parameter. Let me handle that first. If there's not a service query parameter, then I need to look at the properties in the DID document. If there's nothing, no properties in the DID document that trigger me, then I need to look at the properties in the metadata
… Right So I'm not seeing looking at the properties in the did document or the metadata here. And so it's hard to map this particular algorithm to how I had understood a reasonable flow
Stephen Curran: So that's the question I had. Sorry, Will...
Will Abramson: Yeah, go for it...
Stephen Curran: What do you mean, look at the properties? Could you explain how that would work? I saw that in your algorithm, and it didn't make any sense to me, so I didn't understand...
Joe Andrieu: So, you're...
Stephen Curran: I would think there would be rules around that. And yet so that's what I'm looking for is understanding what you mean by that...
<ottomorac> could we view Joes alg in preview mode like this?
Joe Andrieu: What I mean is you look in the DID document, and you see if there are any properties in the DID document that, um...
… Uh, should tell you to work with them. Um, because
Stephen Curran: Like what?...
Joe Andrieu: Like like a linked resource property...
… For a did document that hasn't upgraded to this new path handling approach
Stephen Curran: Okay, so...
Joe Andrieu: We have linked resources as a way to do path handling. I'm trying to not break it...
Stephen Curran: Right...
Joe Andrieu: And if we don't look at the properties in the did document, then we're gonna break it. And so...
Stephen Curran: But… so, Joe, just… just one sec. I'm trying to say...
… how do I look at those? What… like… like, if I have two linked resources, what do I do then?
… I don't… what I'm saying is, saying that… Doesn't tell me what to do
Joe Andrieu: So linked resources of property at the top level of the document. So you go...
Stephen Curran: I understand that...
Joe Andrieu: So you use regular JSON parsing algorithms, you index to that property, and you read the value. There might be a dozens of linked resources all behind the linked resource property. And what you're looking for is the property linked resource, which you would handle according to the algorithm defined in the linked resource
specification...
Will Abramson: So I'm on the queue to have some things about this...
… I do hear what you're saying here, Joe, but I felt like we moved past that, because your algorithm, as I remember it, was a
… series of ordered steps, right? Like, first look for the properties, like linked resource, then fall back and look at the service, or something like that. There was an order of doing things. And my sense was, what we decided last time is. It's really this step, 4.1. We're gonna
… That is the path handling object type. we're gonna collect all path handling objects, really, yeah, in the DID document and the DID document metadata, and how are we gonna know they're path handling objects? Because they have a type
… Right? Like, my… I think the problem with calling out specifically linked resources or anything like that is that's effectively referencing a
… non-normative thing, isn't it? Like, I don't think we wanna
… bring those references into this spec, we would just want to create a common way that any extension can say, look, I fit into this pattern, I am
… gonna handle paths, and do it in a way that I define, but in a way that the dereferencing algorithm can
<JoeAndrieu> order was service, service type, property, document metadata, method specific . missing how you handle query parameters
Will Abramson: work? That was my understanding. So, I mean, I
… I agree with what you're saying about having service. We should do all service stuff for all query parameter stuff first and see if we get an object. If we don't and there's a path, we're going to
Will Abramson: Do some path handling, or maybe what you're saying is we should, even if there's not a path in the URL, I think I could agree with that, we should do some, we should check to see if there are any path handling
… objects. But then the problem, I think, with that approach is, say, I have… I am just dereferencing a… a DID
Joe Andrieu: Wait, could you just repeat that last bit, Will?...
Will Abramson: When I want to get the DID document, like, how do I do that if there's a path handling object in there? So, I'm dereferencing a bad deed, right?...
… And I'm going through this algorithm, but the DID document in this BEDID has some path handling objects. Like, if we go through this algorithm and we target those path handling objects. uh
… That means that there will be no way to dereference and get back the DID document
… um
… Maybe that doesn't make sense, but anyway. Also?
Otto Mora: Is it worth just pulling, um… because I really like this here, like, this is...
… I don't know if it's just me more visual, and then just, like, as we discuss things in my head, I just, like, lose path, because… lose sight of, like, what it is, because I'm just obviously not as familiar with the spec as you guys are, but, like, this has been really helpful, like, even, like, for
… I think, like, folks on the call tomorrow, to just, like, share the preview of the PR like you're doing here, like
… way, way more easier to follow, and for people to have an opinion, I feel like, you know, like
… Would… could we pull… I see that Joe had shared his here, um
… Uh, his preview link, is it worth pulling it now, just to see
… What the difference is that I believe evens oh, yeah. There that one. Is this helping… clarify Steven's… question around. That one part where he wasn't clear on
… the aspect of how Joe had thought about the retrieval strategy
… Or maybe, Joe, you could walk us through this. I don't know. Just my two cents
Will Abramson: Yeah, I'll let you go first, Joe...
Joe Andrieu: Sure. Yeah, so the ordering I had put in chat here, I think we've agreed that service type doesn't make sense...
… And then the one thing that is missing here is how do we handle arbitrary query properties? And so I appreciate that Stephen's trying to figure that out. um
<swcurran> path is also missing
Joe Andrieu: Then you look in the did document for any property that you know that contain that, affects the retrieval strategy. But the the idea was here is if there's a query parameter that is specific to a service do that first because this URL means to invoke that service. um
… this is going to be property specific, and it is for those properties which have this function. I do not think we have decided that there… I don't know that we have consensus, we might be able to get there, but that if you have defined a property
… Um, and it did document produced by software before there was a path handling type
… Um, then we should be able to handle it. Or someone tomorrow comes up with a new property, which is ex… we have this extensibility mechanism, and either we get rid of the extensibility mechanism, or we need to be able to process these future-looking properties that we may not even know about today, or properties that are in use
… that affects retrieval strategy or handling strategy, then that it must be a path handler, and that there is no other way for you to get your property to be legible to the system. This is a mechanism that if you have a property that is legible to the system, such as linked resource
… By any of the deployed 200 plus did methods that we just don't know about. Part of what I'm fighting for is we have these mechanisms for extensibility. I'm trying to make sure that we retain our respect for that extensibility because we built the architecture to not require a centralized registry
… And so, it's important to me that this sort of extensibility is still supported. Um, if… if you still don't have a… a
… Uh, handling strategy. I'd call the retrieval strategy in here. Then you look at the document metadata, um, which includes the, the, uh, resolution metadata. And then finally, you fall back to, uh, method specific. So if we haven't already found a, uh
… a handling strategy, then you might hope that maybe the DID method has some way to do it. And if, after all that, you still don't have a way that you know how to retrieve it, then you just return the DID document. That's the essence of that algorithm
Will Abramson: Okay, thanks, Joe. Manu?...
Manu Sporny: Um, uh, yeah, plus one, Joe, that's very helpful. Um, and I do like this, I mean, looking at this algorithm, it's, you know, the order of operations is pretty clear, also plus one to the, we have this, you know, decentralized extensibility mechanism, let's make sure that we...
… You know, keep that in there. I guess, Stephen, would it be possible to merge this into the algorithm that you have? And if not, where are the problems? Meaning, like, I think Joe already said, like, step two, we're taking out. Right. But with the stuff that's remaining, do you see a place where it, you know, augments or fits in? Uh, to the
algorithm you have
Stephen Curran: So yeah, I don't see them radically different. The two differences now that did meth, you know, one and two got moved down...
… And and, as I said, I didn't quite know where method specific
… belong, so I'm good with that. Um, the fallback, I
… The two differences are property. and document metadata that I don't have in mine, and path that Joe doesn't have in his
… As, you know, my
… I'm trying to get… struggle with property and document metadata is I think of it as an implementer. What's an implementer gonna do? I just
… rules around that. And it just didn't make sense to me just to say
… look for properties that might impact things, and especially where
… And having that before, well, before path handling anyway, where
… You don't have a way to… you don't know
… I just don't understand how to process that. So I get it now that there's no trigger for it. You just sort of, oh, there's not like a service parameter that says linked resources as a parameter that triggers the use of that property
… or the path to trigger that property. It's just… it exists in the DID doc, therefore you use it. That… I struggle with. That… that's the only difference. I'm happy to… if… if
… If people want this in there, easily, it just goes in, we just pick one. I think property and document metadata can be combined into one, that's fine, or kept as two, doesn't really matter. Um, but I… I really struggle as to what an implementer is going to look at that and go, how do I do that?
Will Abramson: Thanks, Stephen...
… Yeah, I put myself on the queue to kind of talk about
<JoeAndrieu> +1
Will Abramson: My understanding of when we last discussed this, and it was in two weeks, was, I mean, we were kind of going to encapsulate both of these steps in this new type that we defined. And I think what you're saying, Joe, is we do still want to do that, but we also want to support these sort of legacy systems. But. That might not be using that new
type
… My sense is that we really do want folks, if they want to extend
… their DID documents and define new extensions and new ways for doing pass handling. We want them to have a way to signal to any client that they are a pass handling thing and should be taken into account
… And maybe that is the way that
… Like, otherwise, what we get is, like, you know, I'm a client, and I understand linked resources, so I… I mean, maybe that's fine, and I know linked resources are a property that handle retrieval, so I'm just going to look in there
… And they're both targeted. that we address that, and then different clients just understand different properties in the DID document, but I don't think we're going to get interoperability in that way, in that, you know, my client only understands linked resources, and your client only understands some other retrieval strategy
… differently, then they might get different results for the same URL
… Question mark. Uh, I do think also in here, there is not this concept of using the path. to target specific
… Objects. So like this property, let's say there is a linked resource And that linked resource is an array of resources, right?
… Are you assuming, Joe, that this retrieval strategy is like the linked resource retrieval strategy, which takes in an array of resources, and does the path handling
… uh, you know, selection in that algorithm. Because for me, we did kind of get to this, this sort of
… consensus, I thought, that we were going to have this type, and then we were going to collect all of the path handling objects, like including the services, the path services, the linked resources, and any object in the DID document that kind of claims to be path handling, and then apply the same
… matching algorithm to select which one of those objects is the object that I should. trigger on
… If, assuming I understand the retrieval strategy
… So that was my understanding, and I can't see the argument for having some legacy
… Bye. But I think it just makes things more complicated
Manu Sporny: Uh, yes, it makes it more complicated, but it's worth putting in the algorithm, right? So, you know, um… Uh, I think we can say, like...
… please, please, please, implementers, use the path handling object approach. Like, if you want to do path handling and you want to do some, you know, custom, please just signal to the implementation. You're much more, you know, it's much higher likelihood that
… We will reach interoperability through that mechanism than implementers implementing potentially random DID extensions at different points in time, right? So please, please, please use path handling object
<ottomorac> +1 to suggestion from Manu
Manu Sporny: But for those of you that, for whatever reason, have a good reason not to do that, you can use property and document metadata as well. But we're just warning you that property and document metadata might lead to less interoperability than the path handling thing. So, you know, plus one to merging
… all of these into, Steven, the algorithm that you have, minus, you know, service type. I think the argument is, you know, legacy support and allowing for, you know, extensibility in ways that we haven't thought about
<Zakim> JoeAndrieu, you wanted to say 3, 4, 5 are "legacy support" for extensibility mechanisms other than path handling type
Manu Sporny: But we can nudge people towards, like, please use the path handler object. Like, that is… that is your best path to… to getting, you know, broad-scale interop, um, uh, with your… with your, um… a path handling strategy. That's it
Will Abramson: Okay, great. Thanks. That makes sense. Joe?...
Joe Andrieu: Yeah, plus one to that. 3, 4, and 5 are really about legacy stuff. We know, for example, that IXO has deployed...
… physical stoves. In fact, they're… it's… it's a significant effort to create carbon, uh, credits, smart contracts, and NFTs, and they're deployed in the field
… Um, with families in Africa using these devices that are using linked resources in this way. The cost of updating those stoves is probably absolutely not worth it. Um, I don't know particularly if they have a nice update mechanism that's secure, yada yada yada
… But my point is, there are people who are not in these meetings who are using these technologies in ways that we don't know how, and I really think we need to continue to support the notions that we had enabled when we first put this through
… So plus one to the general sense of merging and and trying to sort of add these fallback mechanisms. We do sort of have an open question about how do we handle other, query parameters
… ah. And I don't have a good solution. I think it's not clear to me what you should do if you have a service parameter that
… is not service, and therefore you don't know to go look for a service property to find the ID for it, and then invoke that service according to the service type
… So I do think there is a gap here about, like, do we handle query properties, query parameters before we look at properties in the DID document? I think we should for the same reason I like service being handled first. It's explicitly in the DID URL
… So, uh, I would imagine that the person who created the DID URL is trying to direct the flow in a way that's hopefully, you know, helpful, as opposed to an attack. Um, but I'm not sure how we fit that into here. I think it's an open question
Will Abramson: Okay, thanks, Joe. Uh, just knowing the time, I'm gonna close the queue, uh, so we'll just run the queue and hope that's enough. Uh, Steven...
Stephen Curran: Yeah, to get a concrete example of my...
… concern about property and document metadata as they are here and without rules around what you do. Um
… Would it not be the case that if you put a linked resource in a DID document, you would never get the DID document back? You could never see it because you would always hit three and four and say, oh, there's a linked
… resource in here, therefore I return the linked resource, and I never get… oh, there's no way to ever get the DID doc back
Joe Andrieu: May I answer, Will?...
Will Abramson: Yes, go for it...
Joe Andrieu: Um, the...
… The handling strategy for linked resources includes finding the particular linked resource that matches to the path
… So if there is not such a math, a match, then that retrieval strategy will say go use return the did document
… It falls back to when I don't have a match to a specific resource. Uh, go to the document
Stephen Curran: So, this approach works...
… based on the extension doing the right thing. So that's the rule around it. Okay
<Zakim> manu, you wanted to speak to "what would implementers do?"
Stephen Curran: I'll try to figure out… yeah, I'll try to figure out a way to word it
Will Abramson: Okay, thanks. Uh, Manu?...
Manu Sporny: Yeah, I think plus one to that, the algorithm is dependent on these extensions behaving well. And if they behave badly, it'll just break, right? And then people will stop using the extension as kind of, you know, the outcome to that...
… Stephen, you asked, you know, as an implementer, what would implementers do? That totally resonates with me. But in some of these cases, especially the legacy support cases, or the ones where we're like, you know what, we have no idea what kind of innovation is going to come out of this
… I think in those cases, we've gotta trust the ecosystem to figure it out, right? So it is going to look vague in the spec. I know that's not like ideal, but we're trying to strike the right balance between being overly prescriptive
… And allowing there to be enough decentralized innovation where neat things might come out of this. And the downside to that is that things will also break. They'll be not well specified, people will make mistakes in their extensions, um, and uh, and hopefully
… Uh, the blast radius of that is going to be, um, uh, kind of limited to the extensions and who implements them. Um
… So, all that to say, I think it's fine for us to be a little vague with property and document metadata, um, in, in, you know, when we're dealing with extensions
… It's about hitting the right balance between pointing people towards the extensions and then trusting the extensions to do the right thing. That's it
Will Abramson: Yeah, thanks, man. Um, okay, I just want to try and… I mean, first I'll say I'm a little concerned about our timeline, but I just want to try and summarize what I think we kind of got to on this call, because I think it was useful. So, the determining retrieval. Strategy, or whatever the algorithm we called it, is gonna…
really...
… handle service first. I mean, I still have a question about whether we want to, like, make service, put service on this pedestal, but it's certainly going to handle query parameters that
… Ah, okay. it understands to be about selecting retrieval strategy, right? Like, each client is going to understand different things, and one of those that all of them should understand is service, so certainly service is different in that sense
… And it's gonna, you know, use those query parameters to select an object and execute that retrieval strategy, right? And then, after that
… You know, if it doesn't find an object, it's gonna go into this sort of, like, uh
… thing that we're trying to define here, like, in that we're saying, you know, ideally you should use this type, and we're… that's the first thing we're going to check for, um, objects with that type
… And then we're going to use the path to select that object and execute the retrieval strategy. If that fails, we're going to fall back to you're the client, you understand the DID document, however you decide to, and you understand that some properties are relevant for your use case, right?
… did linked resources, you might understand the did… the linked resource metadata property, and you should handle that. And we're just basically saying, like, these things exist
… the XO case, they're going to understand linked resource, and they can handle that however they have been programmed to handle that, right? And then, similarly with the document metadata, like, if you are working with linked. If you haven't found something that's using this sort of more standard pattern, you might want to look in these other
places
… And then failing that, we're going to fall back. So I think that does kind of combine these two together, right? Like, we can see a pathway where it's, like, query parameters first. This sort of standardized path handling object approach. And then these properties
… We're just saying it's not allowed, I think
Stephen Curran: Yep...
Will Abramson: And we don't really need to say much about these properties, just that, you know, you're an influencer, if you understand these properties, feel free to use them, that's not...
Stephen Curran: I think that sounds good, Will. Good summary...
<JoeAndrieu> we should probably also special case versionId and versionTime
Will Abramson: Great. Okay, uh...
… With that, yeah, I mean, I guess, Steven, you're gonna take another pass, and I appreciate that. We will have another call
Stephen Curran: Happy to pass it on. Happy to pass it on, but I will take pass if otherwise. Yes...
Will Abramson: Yeah, well, we will have a call on this again probably on Wednesday, but I would appreciate folks, like, taking time to review the review and add comments to the PR beforehand. It just helps us get a bit more on the same page in this call. Because we are in a bit of a time crunch, right? Like, we're, like, one and a half months
through our...
<ottomorac> Thanks for your service Stephen
Stephen Curran: Wow...
Will Abramson: Six months extension. And the biggest concern for me is we need to get this algorithm done so we can get it reviewed by TAG and then address the TAG...
Stephen Curran: Um, but...
Will Abramson: Yes. Concert in time, right? So that's the time pressure here...
… Uh
Stephen Curran: Well, sorry. One more thing in in the changes. Do we want to put in the that commentary about the different parameters, and how they might be in different places, be used in different places. I think… Yeah...
Will Abramson: Maybe in this section it goes, though. No problem...
Stephen Curran: Do you want to do a PR about that?...
Will Abramson: Okay...
Stephen Curran: Sorry, I think it should go in the dereferencing algorithm, but higher up...
Will Abramson: Um… okay...
… Yeah, I'll have a think about it. Yeah, okay, great. Yep
Stephen Curran: Okay, let's talk about that. Yeah, let's offline, let's talk about it. One of us will do a PR. Yeah...
Will Abramson: Yep, perfect. Okay, um, and with that in mind, I'll see you all tomorrow. Hopefully, it's going to be an okay conversation, and then we can move forwards and try and get this whole algorithm complete as soon as possible. Thank you...
Otto Mora: Thank you...
<ottomorac> transcriber-bot, pause