Meeting minutes
Agenda Review, Introductions (5 min)
Special topic call summary (5 min)
<ottomorac> Yesterday special topic DID Working Group focused primarily on reviewing PR 331, a pull request introduced by Will Abramson to establish a high-level scaffold for the DID resolution and dereferencing algorithm. The objective of this PR is defines the necessary steps of the process without initially diving into the complex details of each specific sub-algorithm. The intent to unpack specific steps—such as determining retrieval strategies—in subsequent specialized calls.
<ottomorac> w3c/
<ottomorac> A significant portion of the discussion centered on Steps 4 and 5, which involve retrieving and using the identified resource. Dmitri Zagidulin expressed strong opposition to these steps, arguing that the dereferencing specification should ideally end at returning a URL rather than prescribing how a client should "use" or "retrieve" the resulting data. However, Joe Andrieu and Manu Sporny countered that providing a framework for these final stages is essential because the DID architecture often involves complex retrieval strategies—such as blockchain-based mechanisms—that go beyond standard HTTP GET requests. They cited RFC 3986 to support the idea that fragment processing and secondary resource retrieval are historically part of the dereferencing narrative.
<ottomorac> The meeting concluded with a technical debate over terminology and error handling. The group considered adopting a "signal an error" approach for the algorithm to maintain flexibility across different implementation environments, rather than strictly prescribing a return metadata structure. Regarding terminology, members deliberated on the best name for a DID URL that has had its fragment removed. While "Base DID URL" was initially proposed, the discussion shifted toward "Absolute URI" to align with the formal syntax defined in RFC 3986, though some members expressed concern that this term might be confusing for developers. No final decision was reached on the naming, and the group was encouraged to provide further feedback on the PR before the next session.
<ottomorac> transcriber-bot, resume
Otto Mora: a bit of that, what that was. So, just wanted to provide that, and then I'll enable transcription...
… Now, and I see we have Ted, so I'll acknowledge Ted. Go ahead
… Let me cut
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, just quickly, uh, so you know, those long lines that you pasted into IRC, they're fine for humans...
… But they won't look right in the minutes when you finish them
Otto Mora: Are they getting cut off, or just completely...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, well, they'll get cut off, or rather, they'll get wrapped onto a new line, but they won't have the dot dot dot that starts, so… The minutes won't do the right thing...
… it's easy to clean up if you or Pierre-Antoine can hack on the IRC log later
Otto Mora: Okay...
… Okay, um, well
Will Abramson: Yeah, I think the last thing to say, just on that is, you know, if you haven't already, please take a little bit of time to review 331, um...
… I mean, I think it's pretty fine
… Uh, and hopefully we can merge it soon. I mean, Marcus is having some pushback about this did and did URL
… question, and I do want to just kind of take that out of this PR. I want to get this PR in, so I'm happy to accommodate him, unless people really think we shouldn't. I think we need to put on the agenda
… A call, where we are going to make a decision about that, and then just move forward, but
… I don't want that to derail getting this PR. The only thing I have on them
Otto Mora: Uh, maybe we jump right into the PR? Sound good?...
Will Abramson: Oh, let's jump into the retrieval strategy, I think...
Determine Retrieval Strategy
Otto Mora: Oh, okay, alright. So… okay, so we just...
… Determined retrieval strategy, and uh… you have the floor above
Will Abramson: Yeah, actually, I'm gonna… I mean, I was gonna prepare something, but Stephen, uh, messaged me with some good stuff, so I think I will just hand over to you, Steven, and we can go… Steven's got a bunch of examples that we can just talk through...
… And hopefully get everybody on the same page around, you know, what we mean by this step. Um
… I don't know, it's a good introduction soon
Stephen Curran: Okay, um, sounds good. Um, so what I did was, um...
… I'm gonna share my screen and, um, share a presentation so people can see my screen now
Otto Mora: Yep...
Stephen Curran: Um, so, in thinking this through, I thought it would be really good to go through a combination. So, when you get to bid URL dereferencing. Um, you have...
… A combination of 4 things, any of which may or may not be present
… Um, you've got a fragment, you've got other parameters, and I
… Called them other parameters because they would not include those that were relevant to resolution
… Now, we… I don't know if that… people agree with that, but there… there are certain ones that are, um, like version… version ID, version time, that are resolution
… parameters, and then there would be other parameters, and so I'm separating those into two groups. There's the path
… And then there's metadata, so when you resolve
… A did, a bear did, you get metadata. And that metadata
… comes into play in dereferencing, and the big example of that is did link resources, DLRs
… And they are driven pretty much entirely by metadata. They don't
… um, work on what's in the… in the DID doc, they work on what's in the metadata, so
… Does that sound good to everyone, that we've got these four things?
Joe Andrieu: What about the div document?...
Stephen Curran: Good point, the document is always there...
… How about that?
Will Abramson: Yeah. Yeah, I mean, I think I have this comment too when I was reviewing Steven's thing, um...
Stephen Curran: Okay?...
Will Abramson: I think… I think I agree, the did document is always there, but I… I think...
Stephen Curran: Yeah...
Will Abramson: I think we can still go through this, but I think there is some cases where what's in the did document is going to impact the examples you have here. Yeah...
Stephen Curran: Oh, absolutely. 100%, did not matter. So, this is the style that I wanted to do, which is, I've got...
… each of these in combination, and I just wanted to make sure, and even today, Will and I were talking about it, it wasn't always clear exactly, and Joe's question right there was
… was perfect for what I'm trying to get to, is make sure we're… we're all agreeing that, um, here's what happens when this occurs
… So, in this case, I've got a bear did, no components. The dereferencing outcome
… I'm hoping I can edit… yeah, I can edit this. So, my plan was to go through these and just say, okay, the dereferencing outcome is a did doc, that's not quite the font I want, but hey
… Um, hopefully people can see that. The retrieval strategy, I might call it DIDDOC
… And… I don't really have any notes. Any… so, this is the style I want to go through, and they're going to get a lot more interesting as we go through, and if it gets
… repetitive or doesn't work, we can stop, but, um
… Uh, give me a chance to try this and see if this works. So, did Doc as the dereferencing outcome and retrieval strategy as well. Any
… Any comments on those two, and any notes to add? Oh
Manu Sporny: I guess, Steven, I'm… yeah, I'm fine to go through this, uh, process and see where it gets us. Um, what about the, like, the options? Where do we know things like that?...
<ottomorac> Presentation Link: https://
Stephen Curran: Yeah, um, Will and I had that, so I'm glad you called that up. Um...
… in the URLD referencing, this is… it actually does cause an interesting
… um, break, if… if the did URLD referencing calls
… did resolution, it has to pass the options in, so those options have to come from somewhere
… As far as I understand it, the options are identical. two parameters
… Um, so you could express them as parameters or not. Where I think it gets super interesting is what happens if you pass a
… A… an option that is intended for dereferencing. Um, but… Um, it only
… it only goes into the resolution part of it. I think that's kind of interesting. Um, Joe?
Joe Andrieu: Yeah, I think this touches a little bit on the did URL, um, dynamic...
… Um, because I would think you would have the whole did URL available
Stephen Curran: Hmm?...
Joe Andrieu: But you parsed it out in some weird way that I… I'm not sure why, other than maybe you're following what the current. Uh, Spectus...
Stephen Curran: Sorry, why did you say I've parsed it out in some weird way?...
Joe Andrieu: Because the did URL was not one of the components in your previous slide, you only picked certain options...
Stephen Curran: The did URL contains these things. It contains the did, and these...
… Potential options, and these additions
Joe Andrieu: It also contains… it also contains the parameters that you excluded in off other param...
Stephen Curran: Okay, so, so, um, you would include RP, what I called RP. So, originally, I had 32 options...
… Um, I… I deliberately removed, um, RP just to get it down to 16
… But I get your point, that RP is, um… so, I call those resolution parameters
… and agree that those would probably come through to did URLD referencing, although I can think of a way
… We could make it easier on the world by excluding those from the rest of the referencing. But
… Um… these are exactly the types of things I'm trying to tease out in this conversation
… Um, so, uh, good that you raised that. I agree that, um, and I was very deliberate, obviously, in separating out just not
… parameters, but other parameters separate from resolution parameters. So, I have deliberately excluded those. As we go through this
Otto Mora: Okay, and then Manu has a handout...
Stephen Curran: Yep...
Manu Sporny: Um… let's see… sorry, now I'm… I got...
… distracted by, uh, something that was said. I guess I'm
Stephen Curran: Yes...
Manu Sporny: I'm… so we… yesterday, we talked about, like, these five things, and when we're talking… when you're talking about, Steven, this framework, are you talking about this framework within the framework we talked about yesterday? There are five things, and did URL difference is the… what was it, the fourth thing, or the… Third
thing, I forget...
Stephen Curran: It… well, what I'm… what I'm trying to tease out is what are the retrieval strategies?...
Manu Sporny: Okay, that's fun. I'm just trying to… I'm trying to understand, like, the mental model of what we're going through, so… so we're not talking about...
Stephen Curran: Nope...
Manu Sporny: Uh, step one, preparing for resolution, or step two, resolution. We're talking about steps 3, 4, and 5?...
… Okay, thank you, that's very helpful
Stephen Curran: Yes. And, and… and it… sorry, and yeah, and so...
… We've already done resolution. We have the did doc, which Joe pointed out is not listed here, but it will be in all of them
… We have metadata, which comes from doing resolution
… Um, we've removed, rightly or wrongly, the resolution parameters, and we have the rest of it left. I left fragment in, Joe, um
… Will suggested maybe leaving Fragment out, but I think if interplay with other things is kind of interesting, and I, again, wanted to tease out some things, so I left it in
… Okay. If we just have a fragment, um, again, I think our answers… and if somebody else could take notes in here and do this, that would be helpful
Otto Mora: Mm-hmm...
Stephen Curran: Um, did dock and the retrieval strategy would be the same, did doc...
… I would highlight that we always use, sort of, a VM
… uh, a verification method in the examples, but it can be any JSON LD. Um, ID
… I believe that is correct, that I could put a service in here, hashtag files
… and I would be referencing a… a service. With the identifier files
… Everyone agrees that it's not always just the VM that I'm dealing with
… Okay, and retrieval strategy is in both of these did not
… And then, um, the note would be something like, um
… Uh, result is expected to
… I'm sorry, uh, the caller? I don't want to use another term. What am I going to call? Client?
… Is expected to focus on the
… Identified node of the DIDOC. That would be, for me, the note that would go in. Okay
… Um, now we have a
Will Abramson: I think Benjamin's got his hand up. Oh, he did have his hand up...
Stephen Curran: Yep...
Will Abramson: Do you have his number?...
Benjamin Young: Yeah, I did. It's… it's fine. It was about the fragment identifier thing, um, which maps to the media type. So, for Jason LD...
… Um, yeah, it can be any… any subject, as
Stephen Curran: Good point. Oh!...
Benjamin Young: As Steve was saying, but, uh, if the media type is different, then. That should probably be called out somewhere, that...
… You're gonna lean on the foundational
… you know, the thing you inherited from, which would be JSON LD
Stephen Curran: Um...
Benjamin Young: In this case...
Stephen Curran: So, um, this is...
Benjamin Young: If you were doing application JSON as a response type, then you would not have that, because there's no knowledge of. identifiers...
Stephen Curran: Okay...
Benjamin Young: So it's… it's… it's a… it's a media type thing that might need definition. Um...
Stephen Curran: Okay...
Benjamin Young: But it is dictated by the response type, because clients should have all that in hand before doing anything with a fragment...
Stephen Curran: Yeah, that's really interesting...
… Okay, I'm really sorry about the format of this, I generated it, obviously, and it's a crappy format
… Okay, um, here we have a service type files, um… The referencing
… outcome is, to me, it is the same as the previous, in that I'm gonna get a DIDDOC back and focus on the service type
… Actually, I'm asking that. Um, I'm gonna circuit… focus on the service type identified by file, so it's as if I had just done hashtag file. But that would
… eliminate Benjamin's comment, because it would
… focus specifically regardless of JSON LD
… Um, still did, doc, is the dereference outcome. Um, really looking for comments here from others
Otto Mora: Okay, so Manu was first, Will, and then Ben...
Manu Sporny: Um, I mean, the dereferencing outcome… well, I don't like this feature. I think we should remove it. Um, I… I know we put it in there...
… a while ago, but it really doesn't feel like it's, um, very useful. Uh, I'm sure there are use cases for it, but, like, it complicates things, um
Will Abramson: Um, yeah, I don't know. I wondered, I think really what you're meaning here, maybe I'm just gonna edit this, is, like, service, not service type. Okay...
… Yeah. Okay
Stephen Curran: Nope, nope. I definitely wanted service types, because it brings up the second point, which is what happens if you have two of them. So, yes...
Will Abramson: Yeah, yeah, sure. So, service type… yeah, so, I mean, maybe then I'll just change this to file service, because that kind of confused me...
… Um, but I wanted to talk about this, how it contrasts with, like, Joe's version, like, I think, I mean, I see Joe's on the queue now, but… when I read Joe's PR
… For him, this would turn into, like, a retrieval strategy based on the service. That is identified here
… Rather than in the current spec text
… it is DidDoc as a retrieval, and you are targeting specific, you know, like, I think maybe you're, like, filtering the services. In that document, based on the service type
… I don't have a comment on which way it should be, but that's the current two proposals
Stephen Curran: Yeah, that's what the current spec does, is it would filter it onto that, and then depending on the accept type. It would either be a...
… the URL, or… I don't know what… anyway, I modified the document. Um… Who's next?
Otto Mora: Uh, Ben was next, and then, uh, Joe, and then Marcus...
Benjamin Young: Thanks, I'm on IRC now. I'll use the proper cue. Um, yeah, you said Steven a bit in passing about...
… Uh, this being like the fragment thing I mentioned, um, it would not be, however, because it's a query parameter format, so this is a… Kind of a different animal. Just wanted to call that out
Stephen Curran: Agreed it's a different animal, but what is the result? Is it… is it the same?...
Benjamin Young: Yeah, so… as… right...
Stephen Curran: Or… or is the result actually different? That's what I'm trying to tease out...
Benjamin Young: Yeah, as you just discussed it, I think it's been… Seen as a, like, filtering mechanism. On the… on the DID doc. To, like, sub-select in some… strange-ish way, um...
Stephen Curran: Exactly...
Benjamin Young: And that… and that… that pushes it… I mean, by design, as...
… written here, it's a… it's a quote-unquote server-side action. It's a… it's a query parameter, so
… Historically, those are used in the, like, sub-resource, uh, mental model. Um
… But I, you know, whether or not that's wanted, whether or not that's a good idea, I don't know. But if you were to
… do the same thing with the fragment. It does
Stephen Curran: Yes...
Benjamin Young: It would look different, but it would answer the question about who's doing what, when, and what to respond with, which would be the entire document...
… And then the… whoever's receiving the entire document may or may not use that fragment identifier to. Do whatever that thing is
… That thing being the fragment identifier wants to do, or is pointing to. Whereas here, this is all, like
… Pushed to the quote-unquote server. Um
… And the response is gonna be up to the server for how it implements that
Stephen Curran: Which I read as up to this specification to say...
… Um, Joe. I think Joe… oh
Benjamin Young: Yeah, for sure, but it's more like API design. And then, yeah, I'll show you...
Stephen Curran: Yeah, yeah, agreed...
Otto Mora: Okay, Joe?...
Joe Andrieu: Yeah, I think that the dereferencing outcome here is. A resource...
… Retrieved from one of the service types that have file service. Um, as a type
… According to the retrieval strategy defined by file service
… And if there are multiple, we have two options
… Either you let the dereferencing client here, um, pick one
… It has the DID document, has all the metadata, it knows
… why these different things, uh, differentiate themselves, at least to the extent that the TID document enumerates those differences
… Um, and so they could pick one, so we could enable that sort of round robin issue. I have one issue with that, but that is one way to think about it. The other is to just have an error, if there are multiple
… Um, my concern about the round robin is today we don't have a way to indicate
… That multiple service endpoints should be seen as logically, um
… Uh, pointing to the same resources. So you might… right, a naive, uh
… use of the DID document could put in multiple service endpoints, all of which return on the… whatever
… file services algorithm is. Um, but they are not intended to be the same resource
… Right, I have one file service that has all my pictures, and one file service that has all my. Um, uh… audio
… And those two really aren't interchangeable, so treating them in a round-robin way is probably
… Um, not the right model, but we could add something like a group ID, just to make something up, I don't think it's the right term
… Um, that could say that, hey, these services are all equivalent, and they are meant to be treated as equivalents, and then I think that makes it easy
… or easier, at least, for the client to figure out, hey, which of these should I dereference? Um, which of these should I retrieve, I should say?
… Um, but I think it would be simpler if we just say, hey, if you get back multiple services, that's an error
… But I can appreciate this other use case, it's sort of like a round-robin DNS kind of pattern
Otto Mora: Mm-hmm...
… A… uh, Marcus?
Markus Sabadello: Uh, yes, in the current algorithm, the service type, and also the service parameters, they essentially filter the services in the document, as others have said...
… Uh, so this would select the services with the type of file service
… from the T document. In the current algorithm, you can also use both together, so you could use service if you want to
… identify a service with a specific ID, and you could add service type if you want to make sure that it's also the type that you want
… And what you get, then, is that the document filtered by those
… service IDs and service types, and the result of dereferencing this would depend… in the current algorithm would depend on the
… the accept option, right? So there's a dereference option called accept
… where you specify the media type that you want to get back, and uh… what… and that could be a DID document, so the
… result of the referencing could, uh, dereferencing this could be the document with just the filtered services
… Or there's also the case where you want to get a list of your rice, right? If the accept option is
… text slash URI list, then the result of this would be a list of
… of your eyes. And then… and then after that, the client, or the caller, or the application
… Or whatever we want to call that, we'll do something application-specific or service-specific
… with the… with the service endpoint, right? It could
… it could download a file over HTTPS, it could initiate an OpenID Connect flow, it could
… look up something from the Bitcoin blockchain, in the case of a Bitcoin
… URI. But, uh
… Yeah, in the… in the current algorithm, as I said, the outcome of this depends on the… The accept option
Stephen Curran: Okay, so that's… just to highlight before anyone continues, Joe and Marcus gave very different answers. So, Joe said it's the resource...
… That is referenced by the service
… Marcus said it's a DidDoc filtered
… or a list of URLs from the… from the selected service type. Very different
… Otto, back to you for managing the queue
Otto Mora: Alright, Manu next...
Manu Sporny: Yeah, I mean, a plus 1, I can see how, you know, what Joe said or what Marcus said could be the result of. You know, the algorithm that's… that's run...
… When you have this, um, type of query parameter, um
… it feels like the application could just do this themselves. Meaning, like, I don't think we're really providing a tremendous amount of functionality that the application couldn't figure out how to do it itself, given it did dock, right?
… Um, and the question is, like, why are these URLs useful? Like, we are putting a query parameter in here because we're expecting an application to potentially record this or use it
… Um, uh, when doing a query, it does not seem
… it doesn't seem like something that we need to specify for interop in the spec, because at the end of the day, you're just looking for all the file services, right? And if you have the DID document, more than likely an application can figure out how to do it
… Um, if they know what the… well, I mean, if they have the DID document. So, um
… Unless someone knows of a concrete use case here, or like a real significant deployment
… or a… I cannot implement my application without this feature, I think we should
… Cut it, because we're gonna spend a lot of time talking about what Joe said, or what Marcus said. It's gonna burn time. It's not really gonna have a useful outcome
… At least, I'm gonna assert, it's not gonna have a useful outcome, because I don't know what the… what the absolute
… must solve use cases for this… this feature. Um, I'll stop there
Otto Mora: Give me a second here...
… Uh
Will Abramson: Joe, do you think you could join IRC?...
… It's just… complicated
Joe Andrieu: Um, yeah, I thought it was in there, but maybe not. Hold on...
Will Abramson: Well, just with the queue, it's kind of complicated when...
Joe Andrieu: Oh, right, I'm queuing up over there, sorry...
Otto Mora: Sorry, sorry...
… Okay, did you want to react, Steven, or did we just go next first?
… Dimitri
Stephen Curran: No, uh, go ahead. This is a good conversation. This is exactly what I was hoping...
Otto Mora: Meatri...
Dmitri Zagidulin: Uh, yes. So, a couple of things going on here. One is...
… Uh, that query parameter is not useful by itself. It was put into the spec to always be used in conjunction with
… relative ref. So, the reason we're, uh… the reason it's complicated, and the reason we're confused whether it's a filtered did doc or a list of URLs, is that
… It was put in just to be used with relative ref before we had a standardized pathing algorithm
… So, I agree with Manu that this should be cut. I suspect we'll get pushback from
… Some folks hear that we should keep it, which is fine
… Uh, but in that case, just be clear that it's not a standalone parameter
… But I personally think that, uh, we should drop it and just rely on a standardized pathing algorithm
Otto Mora: Oh, well...
Will Abramson: Yeah, I… I think I could see dropping it being a good path. I mean, I really liked what Manu was saying around, like, why… why are these dig URLs useful?...
<swcurran> +1 to dropping
Will Abramson: And I think the answer is these digital URLs are useful when we want to use them to reference the resource that somebody else can then retrieve. Alright, like, I put a URL in my website
… So that some other client is going to retrieve that resource that I'm referencing. Whereas I think maybe some of these use cases, even when I was managing some of these things
… It's really just, like, me in my system trying to, like, filter or
… process the bid document, but, like, I can just do that, and I don't need the spec to tell me how to… how to. pass JSON
Otto Mora: Uh, Marcus?...
Markus Sabadello: Um, so I...
… I disagree with Dimitri that this is only useful with relative rev, that's, uh, that's
… Okay, so this has been suggested originally
… About 2 years ago, um
… To… to select services by type, and then do something
… With them, and yes, you can use it with relative ref, and you can also use it without relative ref
… I also disagree with Dimitri, unfortunately, that the file service
… proposal is somehow a replacement for this. I don't think it is the standardized path
… processing that we have discussed, I think is something else, as far as I understand it, it
… Doesn't really have a capability to select a service. By type, and uh
… I would like to keep it, I mean, the question is, if people are asking
… is this useful or not? We… we have… we have discussed this, and it has been
… Proposed to add it, and there are a lot of discussions and a lot of arguments in the
… in GitHub, and in meeting notes, and so on, why we wanted to… To add this, and uh
… And so the fallback, I think, should not be to delete it. The fallback should be to just leave it as is
Otto Mora: Oh...
Joe Andrieu: Um, yeah, plus one for removing it, um, and also probably removing relative ref...
<markus_sabadello> This is where serviceType was originally proposed: w3c/
Joe Andrieu: Um, my… my concerns with it is, I think it's… it's a security
… error in our design. Uh, I think to Manu's point, any place that you might use service type, with one exception, which I'll get to
… Um, you could just specify the service by ID, and that would uniquely point to that one. It feels like
… when you have service type, it lets someone who's creating a URL to sort of go fishing around in a DID document when they're not even the processor
… Um, and so that… that feels weird, and that's where we get these possible multiplicities. If we just have servers, we don't have the multiplicities
… And we don't have to deal with the fact that these may not be intended to be the same resource, but the system could be confused into giving
<Zakim> manu, you wanted to say "remove relativeRef" :) and to note that just because we drop something doesn't mean someone else can't support it. and to note "<blink> and <marquee>" was also a good idea at a point in time for HTML :)
Joe Andrieu: The, um, uh, directing a particular resource to the outcome when that's not what was, uh, expected. Um… So that's it
Otto Mora: Mm-hmm. Bye...
Manu Sporny: Um, right. Uh, let's see, uh, I'm also plus one to removing relative ref. I'm in many of these parameters, I think we created them...
… During a time where we were unsure about what the ecosystem
… could look like or was gonna turn into, uh, and now that we're getting ready to kind of lock this stuff in, I'm not convinced that these are useful
… Um… features to have in the specification, uh
… Uh, so to, you know, um, to, you know, make it fairly obvious, like, at some point in the development of the HTML spec, everyone thought the blink tag and the marquee tag were, like, really good ideas. Like, we need to get the person's attention on the site. How are we going to do that? Oh, let's put a scrolling marquee across the top of the
thing, right? Like, we went through a whole standardization process, it was added to the spec
… It was broadly implemented in browsers, and then, you know, 5 or 10 years later, everyone was kind of like, hey, yeah, that was actually probably not a good idea, right?
… Um, I'm not saying that, you know, service type is exactly the same, but it's in the same vein. Like, I still haven't heard anyone say
… What the concrete use case that they absolutely need, you know, this feature for is
… Um, you know, I know it's, it's like, but what if I want, you know, what if things don't have IDs, and I want to get back a service type by type
… and just write an algorithm to go through the did document to do that. Like, we don't need to, you know, specify that in core resolvers
… The other, I think, thing to mention, and Marcus, you know, you said you think we should keep it in there, um, uh, I think it's fine if
… other did resolvers want to keep the feature in there and support it as a thing that they do. That is their right as a software implementer and all that kind of stuff
… But we don't have to specify what the behavior is in the spec, right? Like, you know, the DID resolvers that have implemented it have implemented it in a way that
… you know, achieves the initial thing that we want to achieve, they'll continue to implement it that way. If there's a big push in the market that they're like, we want that feature, then we can revisit it at that time. But, you know, at this point, I'm not
… Hearing too much support, you know, for this feature. Um, uh
… I think, uh… I think that's it
Otto Mora: Mm-hmm. Give me 3...
Dmitri Zagidulin: So I want to clarify the point of the pathing, uh, algorithm, because I think there might be a misunderstanding on Marcus's part...
… It is exactly intended to replace relative ref and file stock. Like, it is exactly that, with just better syntactic sugar
… It is… it was specifically created to be able to
… select in the service parameter by type, or by path, or by any other parameter. But it is a strict superset of relative ref
… I think that's part of the misunderstanding, and I suspect part of your pushback on it. Uh, in terms of
… Having service type be by itself, standalone, be useful
… I strongly disagree. What we're essentially saying is we need a query parameter
… for every single property in the DID document. That does
… Which… what does that save? It saves, uh
… Retrieving the did documents, parsing it
… and, uh, using the dot notation, right? It's a simple property lookup. The fact
… the suggestion that we need a resolver to do a property lookup, I think is wildly impractical. And in terms of, um
… what Joe mentioned about the service ID versus service type
… The reason Service ID was put in there originally was because people misunderstood how ID is used
… in JSON-LD. In all of the examples
… Uh, they were ID equals file
… they… the examples were using it as a service type. So, the issue 85, where service type wasn't… was, um
… introduced in the old, uh, did resolution
… in the original resolution spec was just fixing a misunderstanding. Linking by ID
… to a, um, to a path doesn't make sense fundamentally. The IDs should be opaque anyways and not descriptive. Okay, that's it
Otto Mora: Uh, yes, thank you. Marcus?...
Markus Sabadello: I'm curious if people also want to remove the service parameter...
Stephen Curran: I would...
Dmitri Zagidulin: I certainly would, yes...
Manu Sporny: Most likely, but I wanna… oh, sorry...
Otto Mora: Oh, that's fine. We were just going around expressing it, it's fine. Okay, so the...
Manu Sporny: Um, I wanna… I wanna… well, so, you know, when… when Steven asked the question of, you know, what does this thing do, we got different answers from Joe and Marcus. I'm wondering if we're gonna get different answers for the service parameter as well...
… Um… man, I'd like to understand what the purpose of it is, and then determine if we really need to support that use case
<Zakim> JoeAndrieu, you wanted to mention round-robin
Manu Sporny: That's it
Otto Mora: So...
… So
Joe Andrieu: Uh, yeah, service parameters, interesting. Um, I agree. I think service ID is more clear, and I don't know what we would do with service...
… If we, um, go in the direction it seems like we're going. Um, I wanted to plus one the notion that we should assume that whoever's implementing the dereferencing of a DID URL
… um, is able to do so with some JSON capability. So, I don't think we need to wrap a whole API around pulling information out of the JSON document
… Um, we should just assume that a competent programmer knows how to use
… parse JSON and pull out properties
… Um, but I did also want to say that the… there is a… there is a use case to
… uh, answer manager's question. Um, but I think it's problematic, and that use case is some sort of round-robin ability to specify, hey, there are multiple different endpoints
… And you can… you, the caller, get to choose amongst these. And we don't really have a way to do that if we are restricting
… the query parameters in the did URL to be a specific service. Unless that service somehow allows the definition of multiple endpoints, which might be a better way to do it
… would be potentially just have multiple endpoint properties in that particular service, but no one's defined that, uh, to be how we could do it. But that would be another way to
… address that use case. And it would address my earlier idea about having a group ID or whatever. I think that the file service just allowed multiple endpoints
… any of which are taken to be equivalent, then I think that addresses all of my concerns and realizes that use case about, um, round robin
… So I guess I'm back to maybe there isn't a use case that isn't satisfied in other ways
Otto Mora: Mhm...
Will Abramson: Yeah, uh, I had a couple things. The first thing on Joe's comment there, like, service endpoint can already be, um. A set, you know, a set...
… Right? Like, an array, basically. Uh, so I think that is possible. Uh
… What I wanted to say is, like, I think the service parameter, query parameter is useful, and it's useful if we follow the pattern that
… I think Joe's been advocating for, where doing query service equals some identified service
… Actually means retrieve the resource at that service
… like, retrieve the resource identified by that service endpoint of this service, as opposed to, like, I want to access the service in the did document, and I'm going to use the fragment. With the ID
… for that service. I think they're two different things. Instead of having service be the same as Fragment, then they can be separate and useful, I think
Otto Mora: My notes?...
… Hello?
Manu Sporny: I think that's an old queue?...
Otto Mora: Oh, it was? Oh. Okay...
<Zakim> JoeAndrieu, you wanted to say serviceId is not fragment
Manu Sporny: Maybe, I don't know...
Otto Mora: Okay, Joe?...
Joe Andrieu: Yeah, I think the, the, uh, I think there's some confusion there, Will, that the service parameter is still a query parameter...
… Um, and it doesn't, like, stop the ability to use a fragment, so if you… if you use the fragment and you use the ID of that service, that is referring to the JSON object in the document
… Um, a question mark service equals blank
… Uh, I think the semantics of that are unclear. Is it… is… is what is put in that blank treated as an ID? Then that seems duplicative service ID
… If it's treated as a type, then that's a duplicate of service type
… Um, so I'm not sure what it would do if it's not one of those features of service ID or service type
Otto Mora: Okay. Marcus?...
Markus Sabadello: Um, so, first of all, I don't think we should be removing features that we've already had in...
… Did one, uh, standard, so if
… if we want to remove service type and move that into an extension, I think I could live with that, but I… because that was the discussion that we had originally in this working group
… Like, which ones of the new proposals should be in the specification itself, and which ones should be
… in extensions, um, so service type could also be an extension, but service and relative rev, I think we had that in the DID 1
… Specifications, so I don't think we should remove it now, we should explain how they work
… And, uh, regarding the question of use cases and, uh… And who needs this? There are
… There are existing use cases and deployments, for example, in the area of digital product passports, which use these parameters
… For example, for identifying individual products, batches of products, classes of products
… It was Phil Archer who originally opened the pull request to add this parameter from GS1, who. Which is, of course, very, very, uh, well known
… in the area of product identification, so there are real-life uses of those. And, uh
… Regarding Dimitri's comment that, uh
… Uh, in service, and the path handling is a strict superset
… of the service and service type and relative ref parameters. I think that's not the case. I think I can easily construct some example TDRLs that you will not be able to
… Express in an equivalent way with the… with just the path and without these parameters
Otto Mora: Okay. Will?...
Will Abramson: Uh, well, I just don't know if we spent our call and not got very far, so I think it indicates that we've got a lot to discuss...
… I just wanted to talk, like, I was a bit confused by what Joe said and this conversation about service ID
… like, currently, the parameters that we have defined are service and service type, and the service parameter takes an ID
… for a service, ideally a service that exists in the document that you are targeting. Then the other way you use service ID is through a fragment, right? Like, as a
… identifier for a bit of the JSON LD document. And all I was suggesting is that I think the service. query parameter
… It is useful if that service query parameter is targeting a service
<JoeAndrieu> +1 I thought service query parameter was distinct from serviceId
Will Abramson: With a retrieval strategy, and the expectation is that by using the query parameter, you're not just
… filtering the div document for that service. You are executing the retrieval strategy. Of the service you have targeted
<Zakim> manu, you wanted to move to extension spec. and to ask Phil about this feature again, I don't think he'd say the same thing again and to note "We don't have to define features", we can deprecate them, we can move them into extension specs
Otto Mora: I don't know...
Manu Sporny: Yeah, I'm… uh, sorry, I'm trying to look into the DID spec, um...
… So, plus one to Marcus, you know, if we can't get to agreement about, you know, dropping these features, but Marcus is okay with moving them to an extension spec, then let's move them to an extension spec. Fine, fine. Doing that, if that's what
… uh, we need, at least in that case, it would be defined somewhere, and that spec could, you know, build on top of did resolution, or do whatever it wants to, right? Like, we don't… we don't have to
… uh, deal with in this group. Um… I know that Phil raised it for digital product passport
… many years ago, but things have, you know, changed. Phil's, you know, around. We could ask him, do you still feel the same about this feature? Uh, I think there are other ways to address what he was asking for there
… Um, so plus one, that's a mention of a concrete feature, let's see if that concrete feature can be achieved in some other way. I expect the answer to that is
… Uh, yes. Um, I'm also looking at the DID V11 specification
… Uh, Marcus, you said that we defined, I know we're, you know, you were mentioning 1.0, like
… Yeah, that's fine, 1.0 was there and publish, but did resolution didn't exist at the time, and we're gonna publish the 1.1 spec, which is the latest version, and so I don't know if it really
… like, we can… we can deprecate and remove things in 1-1. Um, I know there's a lot of asterisks and caveats there, but
… Um, I am trying to… I think we moved all the parameters. over… to did resolution. And if we did that
… Then, there is nothing blocking us from removing them from the specification, removing them to an extension specification
… Um, but I'm… I'm trying to see if that… that is… that is true, that we actually did move these and won one out to did resolution. That's it
Otto Mora: Got it...
Markus Sabadello: Yeah, that's true. Sorry for jumping in, but that's true, you're right...
Stephen Curran: Um, my comment is… will be very short, just I was gonna say what Will said, which is, it's fine to put it into extension, but I hope in putting it into extension, it clarifies. what exactly the...
… query parameter is intended to do, and it resolves this difference between what Joe and what Marcus
… have outlined, because I don't think on this call we've done that, so this is, I think
… useful to have a conversation, but if we do move it to extensions, what it would be good would be to have exactly what Will said, which is once we have a
… This, um, dereferencing combination that the. extensions… be asked to
… um, put in how they fit into the, uh, into the algorithm, and where they go, and what they, you know, how they intend to fit into that. So that would be a really helpful way to go forward with extensions. That's it
Otto Mora: I'll just say that even if we are integrating, what you're doing here, Steven, deserves commendation, because...
… Before, we weren't even… at least with, you know, not
… Those of us that didn't have these strong opinions weren't even able to follow what was being said, whereas now
… At least having this presentation here, like, the different opinions, it is very, at least for me
… probably others feel the same way. Like, very illustrative, and it helps us follow the conversation, because before, it was just very hard to… so, thank you for preparing this. Oh. Well
Will Abramson: Yeah, I mean, I think I agree, it's definitely helpful. I'm a little concerned with how long we spent on...
… Um, well, you know, we've not got to the hard part yet, which is, like, the path handling
… and all that stuff, so… I mean, I'm sure we can get that, but I didn't expect this example to take quite so long
Stephen Curran: Um, I… sorry, I think I'm on cue, yeah. Um, but I think this...
… is getting us to the important conversations, and that's what I hoped it would do, and I think it has, so I hope others
<manu> agree, there is value w/ this approach.
Stephen Curran: Are seeing the value of doing it via this approach is
… Yeah, we just went through a really hard topic, and I think we're at a resolution for it
… That's a good thing. Um, and
… I do… am thinking that I could now change it from service type to some other parameter
… And… you know, whether it goes on or not, I picked that one because I knew it
… involve services and could have multiples returned, and I wanted those two added, but, um, I think it is a useful exercise. Hopefully, um, we can go a little further with it
… yeah, it's gonna take time, but it gets us the resolution on topics, so I think it might be helpful
Otto Mora: I don't know...
Manu Sporny: Yeah, plus one to just agree, this was a helpful exercise, and I do think we're tackling some fairly big questions by going through it...
Otto Mora: Marcus...
Markus Sabadello: Yes, I agree, this is helpful, and thanks, Steven. This is, uh, very, very well prepared, and I want to say I...
… really like the idea of the retrieval strategies more and more. I know I'm… I'm opposing a lot of the details and a lot of the specific proposals
… But the overall framework of having these different strategies, depending on what the inputs are, I think that's very clean and very useful
Otto Mora: Well...
Will Abramson: Yeah, see, when you said you thought we got to a resolution, I wonder if you could summarize what that is. Is it that we are...
… Removing service type to a, um… Extension. Right
Stephen Curran: an extension. Um, I don't think we have a retrieval strategy here. Um, I noticed that that was empty. I do think we got that done. Um...
… We do have the question of, okay, what happens if it's service, and we don't really answer the… haven't really answered the retrieval strategy yet
Will Abramson: Hmm...
Stephen Curran: Um, so...
… You're right, we did get somewhat to a resolution. More to go
Will Abramson: Cool...
Otto Mora: Mm-hmm...
… So next week, it would be
… the next one with the fragment and other param, right? I think we just continue that, though
Stephen Curran: I mean, I would like to...
Will Abramson: Yeah, I think let's just continue working through these on the special topic call...
Stephen Curran: I'll, um, I'll clean up the document so that it's useful for taking notes...
… Um, it is open to anyone to edit. Um, so go crazy
… Um, and the… my thought was, um
… that it be used similar to the way the, um, you know, the Google Doc was used. That's what I tried to capture here
… You know, the differences, um, that people felt
Otto Mora: Mm-hmm...
Stephen Curran: So, yeah, anyway...
Otto Mora: Yeah, so folks include your name when you...
… But if you're directly editing, otherwise you can use the comment feature on the side, but yeah. Definitely. Awesome
… Great. Thank you all
Stephen Curran: Excellent...
<ottomorac> transcriber-bot, pause