Meeting minutes
<Wip> transcriber-bot, resume
Agenda Review
Will Abramson: Okay, um, welcome everyone to today's working group call...
… Just go to the agenda
… Yeah, so today, the agenda, we are just going to continue off by we'll quickly review what happened in the special topic call yesterday, and then we're going to
… continue working through the did URL dereferencing algorithm. I think we made great progress yesterday, so
… Hopefully today, we will be able to clarify any last things, and move forward with some PRs
… Is there anything else folks think should be putting on the agenda for today?
… Um
… Okay, I'm not seeing anyone on the queue, so
… I won't move forwards
Special Topic call Summary
Will Abramson: Okay, so, special topic called summary. Yeah, so yesterday, we continued working through Steven's
… slide deck of example, uh, dig URLs that we would be dereferencing
… And, in particular, we were focusing on a DID URL with a path
… And I think we came to a pretty good, um
… consensus on that, at least at the high level, which is, if a did URL has a path
… The steps involved are, first, collect all the. past handling objects in a did resolution result
… And secondly, um, use the path in the digurl to filter or select
… The path handling object that you
… Uh, targeting, and will use to retrieve the identified resource by that path. Um, if there are duplicates, so if a DID document contains multiple path handling objects
… But are targeted by the same path, then that is an error. That's my understanding of where we're at
… Please correct me if anyone thinks I've misrepresented that
… Joe?
Joe Andrieu: Sorry, uh, we also had some consensus about service, and that that would, uh, be handled before the path part...
Will Abramson: Right, yes, great...
… Yes, we did talk about service first, and so the query parameter service, and if you… I think we decided if you're using that query parameter service, then you are targeting a specific identified service in the DID document
… Um, the result of adding that query parameter to a DID URL
… is, by the result of dereferencing, that did URL is to retrieve the resource. Target, you know, identified by that
… Uh, Steve?
Stephen Curran: Quick question on that, Joe. Does that mean if there's a path and a service parameter, you're ignoring the path?...
Joe Andrieu: It depends on whether or not the type of the service processes that path and its retrieval...
Stephen Curran: Okay...
Joe Andrieu: But yes, I would let the service decide how to interpret the path...
Stephen Curran: Okay, so it may ignore it, or it may use it, depending on which service you actually select. Okay...
Will Abramson: Mm-hmm...
<swcurran> +1 to the summary
Will Abramson: Anyone else have any comments on that, before we, um… Continue on
… Great, thanks. Um, okay, let me just stop again
DID URL Dereferencing Algorithm
Will Abramson: So, I mean, we're just going to keep working through this. I think, Steven, you have a few more examples. I feel like we're pretty close to
Stephen Curran: Yeah...
Will Abramson: having...
… Um, so let's just go through that and try and get a little bit deeper. I got… I guess
Stephen Curran: I agree. I think we're pretty close to being done...
Will Abramson: Yeah, that's great. I guess the caveat I will have is...
… Um, maybe I should have done this in a separate topic. We want to merge this PR
… 331. There's some back and forth, so 331 is the outline of this algorithm, which we're trying to define
<Wip> https://
Will Abramson: Now, like, and the idea is we'll get this outline in, and then we can independently define the separate steps
… Uh, I was hoping to get this PR merged, I mean, there's some back and forth with markers, but also
… Um, I was looking at the PR today, and it looks completely different. I don't know what's changed, but
… This PR is now saying every single line in the spec has changed. It definitely didn't used to say that
… So, I mean, maybe we can take this offline, but I need to figure out what's gone on here, because
Stephen Curran: I think… I think you merged that other PR, the cleanup PR, after? After you put in this one...
Will Abramson: Oh, maybe it needs rebasing. Okay, yeah. Okay, so I'll look at that...
Stephen Curran: Uh, yeah, it may be ugly. It may be ugly...
Will Abramson: Nah, it should be okay...
… That's why I haven't, but yeah. Okay, I'll look into that
… Yeah, good
Stephen Curran: Yeah, I noticed that as well today. I was gonna make a comment, but then thought, oh… that's so ugly. Okay...
Will Abramson: Okay, so let's keep going, yeah. Thanks, Steven...
Stephen Curran: Yeah. Okay, I think this… I don't think this is gonna take long, because I think we've got most of it, but let's keep moving on. Let's see, I think we were… we have gotten through this. You know, we've gotten through it there...
… Um, there did one with just a fragment, one with just a parameter
… And recall that, um, we're only including in this assessment, um
… parameters that don't affect did resolution itself, so version time, version… Um… Uh, version ID
… Um, so here's one where we've got both the parameter and, um, the fragments. And I think we got to that one
… This is where we only got a path, so we got through that one as well
… Um, now we're at… I don't think we got to this one, so… the
… path plus the fragment, and I think the consensus is
… You would process it with, um, the path exactly the same as the previous, with just the path, and then
… The, um, fragment would be processed by, um, the recipient of the output
… No… no dispute there
Will Abramson: I was trying to get the… Uh, I'm not seeing anyone on the queue...
… I… I think I agree with that
Stephen Curran: Okay?...
Will Abramson: If anyone doesn't...
<Wip> Slide deck being presented is here: https://
Stephen Curran: So, this is the example we just talked about, uh, on the call. So, um, service takes priority over, um, the path...
… But the service that is selected out of this process may or may not use the path that's up to that service, so
… Um, if there's a conflict there, the service would, um, have precedent. And use the path as it sees fit
Will Abramson: Uh, I put myself on the queue just to ask about… to say this service doesn't handle the path...
… do… I mean, I guess we talked about this a bit, are we just ignoring that, or should that be an error?
Stephen Curran: Uh, Joe?...
Joe Andrieu: Yeah, it's a really good question. Um...
… I mean, it… in that type of error, what you have is the author that did URL
… Misunderstood what the service was going to do
Stephen Curran: Yep...
Joe Andrieu: Um...
… But there are paths where they don't necessarily
… apply in a meaningful or useful way. Um, for example, if the service endpoint is a DIDCOM endpoint
<pchampin> -0.5 in silently ignoring something
Stephen Curran: Nope...
Joe Andrieu: then actually applying the relative ref on that… well, we're not using relative ref, so I'm… I'm conflating that, so let me… let me get that out of there...
… Um, but I don't know what to do with the path with the DIDCOM, uh, service endpoint, for example
Will Abramson: Mm-hmm...
Stephen Curran: As one who uses DivCom a fair amount, I would say you just ignore it, because it doesn't make any sense...
Joe Andrieu: Yeah, I'm good with ignoring, I think trying to be strict here...
… uh… I think there are different parties who are making the error, but I don't know why that doesn't feel as bad as other times. I want to be strict, so
Stephen Curran: Yeah. Yeah...
Joe Andrieu: I'm a little...
Will Abramson: Uh...
Joe Andrieu: I wish I had a clearer answer based on first principle, but… I don't think it's a problem to just ignore it...
Will Abramson: Let's see, I see PA on the queue...
Pierre-Antoine Champin: Yeah, I'm hearing things that I find strange, uh, hearing this...
… this URL doesn't make sense, and we return something anyway
… doesn't quite feel right. In general, I'm… I'm
… minus… not minus 1, but minus 1.5 on silently ignoring something. I think I would be happy with returning something
… Together with an error or a warning that something was ignored
… Uh, but if it's re… if it really doesn't make sense, maybe we… maybe then the result should not return anything at all. I don't know
Will Abramson: Yeah, I put myself on the queue to mention, like, in the future, maybe when we add it to the spec, we could return a warning. Like, currently, we don't have such a concept, but we do have it as a planned thing that we would like to have in the future. Similar to how VCOM does it, so errors are...
<Zakim> JoeAndrieu, you wanted to mention query parameters in http
Will Abramson: There's no did result, right? Like, the did document is empty, but a warning would be an error message while still returning a result
… Uh… Joe
Joe Andrieu: Yeah, I think we… we should not require any particular handling. Um...
… To me, this is like query parameters that you may send to an HTTP endpoint that it is not looking for and doesn't deal with
… Um, there's nothing in the HTTP spec that says that servers who get a query parameter they don't understand have to return an error or a warning or anything
… Um, if they want to, they could. They could say, hey, you gave us a query parameter we don't understand
… But I think it's important to leave it up to the service, just like we leave it up to the web service. To figure out
<Zakim> manu, you wanted to note things are ignored regularly on the Web (HTTP query params on servers that don't understand them, HTML, etc.)
Joe Andrieu: How it wants to handle, potentially, invalid parameters or components
Will Abramson: Yes. Hello?...
Manu Sporny: Yeah, plus one to, uh, what Joe said, that was definitely one of the things I wanted to mention...
<pchampin> JoeAndrieu, agreed, but such a HTTP URL does not "not make sense", it could be interpreted by the server
Manu Sporny: is the HP query parameter stuff. Um, you know, we also have examples of other specs that quietly ignore, like JSONLD quietly ignores terms that are not defined when it's not in safe mode
… Um, HTML quietly ignores, you know, improperly nested, you know, HTML and tries to do its best job to render it. I think this is another
… kind of, um, example of that. So, plus one, the implementation should decide, leave it to them. We don't need to specify. it. That's it
Will Abramson: Okay, great, um… Steven, and I'm hearing kind of conflict...
Stephen Curran: Just one… one quick final comment. The… I suppose the service could say, oh, and if you get a path with it, return an error...
… And then, it's really up to the service to decide
… what it could do, so it could be explicit about what it does, but I don't think the spec… this level spec should do it
Will Abramson: Mm-hmm...
<pchampin> fair enough
Stephen Curran: So, plus one that Joe and Manny...
Will Abramson: Okay, great. I mean, it sounds like we… Have consultants. It's good...
Stephen Curran: Okay, next one, let's see, we've got a fragment...
Joe Andrieu: Oh, hold on, I hopped on the queue, if you don't mind...
Will Abramson: Oh, sorry, yeah, I didn't see that...
Stephen Curran: Oh, sorry...
Joe Andrieu: I want to say, it might be useful to...
… Um, specify… make sure we have errors that the server can respond with. Um
Stephen Curran: Oh, interesting...
Joe Andrieu: So, you know, if it is a path error, if it is a query part, we may want the service to respond with something better than invalid did URL...
… But I haven't looked at what errors might come back, just since we're at this sort of level of granularity of going through all the possibilities
… Um, we might want to define the kinds of errors the service might return
Will Abramson: Um, I would just say on that, I mean, I think currently the way we have, like, problem details of that error, like, it's possible to...
… Kind of add a detail to, like, an arrow, like
… invalid URL. Um
… So, like, that information could also go there, like, why is it an invalid URL?
… But yeah, maybe that's something to discuss later in the future thing
Stephen Curran: Nice...
… Okay, um, here we've got a path, we've got a service, we're gonna change this again back to service
… And a fragment, again, I think that's the same with the fragment applied after
… the dereferencing result has been retrieved, so I think this one is a quick one. Any other… any comments on it?
… Okay
Will Abramson: Sure...
Stephen Curran: Okay, here's one, um, that's kind of interesting when you think of… so the only… this is where we've got metadata, so we've got… and when I talked about metadata in this, I said relevant...
… to dereferencing metadata. So, the major example is did link resources. So
… I have a didoc, and I've returned, um, metadata that includes a bunch of did link resources
… But I didn't have any trigger on it. Uh, I would say the outcome of this is simply the did doc, and the retrieval strategy is the did doc
… strategy. Um, even though there's metadata associated with it. Uh, the URL didn't
… trigger any processing be done on it, so we just ignore it. Good?
Will Abramson: Yep. Sounds good...
Stephen Curran: Cool...
Joe Andrieu: Yep...
Stephen Curran: Same...
… Uh, same as before… Um
… Yeah. Same as before, the metadata wouldn't… doesn't come into play. So we don't do anything with it
… Okay
Joe Andrieu: Uh, I would just clarify, it could come into play depending on the service type's retrieval algorithm...
Will Abramson: No...
Stephen Curran: Explain that...
… Mm-hmm
Joe Andrieu: So, I'm gonna have a service object in my did document, right, that has an ID of files...
… that's gonna have a service type. That service type could use the metadata
Stephen Curran: Okay, I see...
Will Abramson: I guess my comment on this is, like, I don't think the method, like, based on the fact that we've said, like...
… The handling algorithm aggregates all these path handling objects, including the metadata
… I don't think the fact that there is metadata or not makes any difference to how we are
… Handling dereferencing, because there are other things that
… And they just take over all that stuff
… Like, the fact that something… a Didriage solution result contains metadata or not
… it doesn't help me, like, I'm just going to dereference this digurl using the existing rules we've talked about, and if there's metadata that contains a path handling object, I'm going to handle it there
… maybe, as Joe said, if the service tells me to look in the message, I'm gonna do that
Stephen Curran: I mean, that's exactly the nuance I was trying to get to when I said the metadata in this case is relevant. Like...
… Much of the metadata is just, oh, time of dereferencing, how long the dereferencing, or the, sorry, the resolution took
Will Abramson: Mm-hmm...
Stephen Curran: and things like that. Obviously, that's not going to affect anything. The particular metadata is where it affects it. And so, you're right, when there's DID-linked resources, and did-linked resources is the elephant in the room when we talk about metadata. As far as I know, it's the only thing that is trying to. impact...
… Resolution by using the metadata
… Um, or impact the referencing via metadata
… And so, when we get to the one that is the path. That includes the path
… Yeah, there it is. The path and the metadata, that… this is where the metadata comes in. The metadata, the relevant metadata. That impacts path up
… Path handling objects within the metadata come into play
Will Abramson: Uh, I see Joe, I think, is on the queue? Joe?...
Joe Andrieu: Yeah, I think you eventually got to the nuance I was arguing for, Will, which is...
… Um… if the service uses the metadata, then the metadata is relevant
Will Abramson: Mm-hmm. Mm-hmm...
Joe Andrieu: But it may not. But if… but you don't know that until you've looked at the service type of the service that. Made it through your selection algorithm...
Stephen Curran: But just to be clear, with resources, there is no service type, right? There is no service...
… Yeah
Joe Andrieu: Correct. Yeah, this one's trickier, the one you have on screen...
Stephen Curran: Yeah. Yeah...
Will Abramson: Yeah, actually, I promise I could talk about that. I mean, I don't understand linked resources fully...
… But they don't have a type at all, but my understanding is, like, a bid-linked resource as an object
… is… that's the type of it, right? Like, that's how you don't understand the type. It is a didlinked resource, not the only kind of thing that it could be
Stephen Curran: So, what they do is, when they resolve...
… So the example they've got is, you've got a checked
… You've got a check ledger, you've got an idea… a did on it, so a
… they call it a collection ID, and then that collection has a bunch of other
… ledger transactions that are resources. And so, rather than putting all those resources into the DIDOC
… At resolution time, it calculates… it goes and looks at the ledger, finds all of the resource identifiers
Will Abramson: Mm-hmm...
Stephen Curran: associated with that collection, with that did, and puts them in the metadata, because it can do it at runtime, and it can be dynamic...
Will Abramson: Mm-hmm...
Stephen Curran: So, I mean, I… I don't like the pattern. Um, but...
Will Abramson: Mm-hmm...
Stephen Curran: it's been used. Like, I… so I put in an issue a while back saying, wow, does everyone realize that's exactly what's going on? That… that...
… The metadata isn't just, oh, the time it happened, and so on, this useful information that you might display and use, but actually
… is completely relevant to how it goes. Uh, I don't like it, but that's what
Will Abramson: Hmm...
Stephen Curran: already exists. And that's kind of why I wanted to highlight it out, is this special case of you have a path, but you also have this...
… Metadata that's relevant to it, but only in the case that
Will Abramson: Mm-hmm...
<Zakim> JoeAndrieu, you wanted to say it is weird
Stephen Curran: The metadata's relevant, that you know that metadata's there...
Will Abramson: Uh, Joe?...
Joe Andrieu: Yeah, I just...
… I just want to chime in. I also think what's going on at did link resources is weird. Um, I mean, we are trying to support it. I think it's important that we try to support it
… Um, but they've created this side bundle of information for which there's no way to, um, index or point to
Stephen Curran: Yep...
Joe Andrieu: Um, they've got a really interesting and weird, um...
… HTTP range 14 problem on their resource URI parameter, which is basically the equivalent of the path parameter. In other words, the resource URI
Will Abramson: Mm-hmm...
Joe Andrieu: is what the did URL should look like in order to select that, uh, entry in the linked resource metadata...
Stephen Curran: Yep...
Joe Andrieu: Um, but I don't have a way to have a URL that has a fragment that points into that metadata...
… Because we don't have a URL that gives us the primary resource that is metadata for them to index with a fragment
… So, there are some weird things going on here. Um, I think we're doing the right thing by trying to incorporate it. I just, you know, it is… there's
… Some weirdness here. Um, and it might be helpful for us to give them feedback, um
Will Abramson: Hmm...
Joe Andrieu: But I'm not sure the most productive way to do that...
Will Abramson: Yeah, I think we've asked them to participate in this for a number of times. They have not really shown up that much...
… I put myself on the queue to raise a different thing, which maybe we talk about after we've been through all these examples, but it's relevant here
… Which is… I mean, I think Joey talked about this as well with Bob. We need some way for objects to signal
… that they handle paths, right? And… and there might be different ways that we do that, but
… do… did URL… people handling did URLs, like the clients of them, need to be able to look in the resolution result
… and be like, ah yes, these 3 are things that I care about. And I guess, obviously, part of that is, like, maybe these clients aren't going to know all of those objects, right? Like
… I think that's fine, right? A client can only
… handle, you know, only accept these things as path handling objects
… For the ones that they understand, like, there might… there might be this new thing that the client just doesn't understand, and they're not going to treat that as bad. I think that's just the nature of it
<Zakim> JoeAndrieu, you wanted to say the problem is novel approaches
Will Abramson: Uh, Joe's on the queue
Stephen Curran: Any ideas on that? Um, this came up yesterday, at the end of yesterday, so… oh, good. Yep...
Will Abramson: Yeah, Joe?...
Joe Andrieu: Yeah, I want to say I think the real problem here is, you know, we have 3 approaches that we know of...
… Um, there are going to be novel approaches, um, because of our decentralized architecture. Someone could come up with a new
… Mechanism to do it, and they don't think it fits within our current architecture, so they invent their own, and so now we have a fourth way
… Um, and the challenge with the fourth way is that clients written today won't even know that they are doing it wrong
… And so… for example, right, linked resources is just a top-level property
… And if you didn't write your client to look for that property, you're not even going to be aware that the path is supposed to be interpreted that way, and you may fall back to some other approach, which isn't really what you should be doing
Stephen Curran: Mm-hmm...
Joe Andrieu: Um, but if we had a mechanism...
… Um, and uh, you know, I have proposed one, and I'll get to it, but if we have a mechanism whereby any given property self-labels
… that, hey, I'm a path handling thing, then that client that doesn't know how to handle linked resources would at least see, oh, they've got a path handling thing I don't understand, and so they could throw an error rather than silently believing
… That they are correctly processing the path, when in fact there is a path landing object that they should have evaluated, which did not get evaluated
… Um, the technique I think we can use to do that is JSON-LD type
… So, we can just add a type to the type specification, that can be an array
… Um, and so the service type could be both, for example, path service or file service, um, and it could be, um, path handler, or whatever this new term might be
… Um… and I think that would address it. And that would mean, for example, for linked resources
… that property is linked resource at the top level. Sean wouldn't have to change that
… All he would have to change is add the type to the linked resource definition so that it has
… path handler, or whatever the term is we want as a type, and then any client would be able to say, oh, there's a path handling object that I do or do not understand
<manu> +1 to what Joe said as a way to future proof this thing
Will Abramson: Um… let's see… yeah, yeah, go for it, Steven...
Stephen Curran: Uh, so, just to understand that. So, type would become an array, or would be used as an array, I guess...
… an array? Is that right? And you would have multiple, including
… for example, path service, comma, path handler. Links resources would have
<JoeAndrieu> ["pathService", "pathHandler"]
Stephen Curran: a type of path handler. I don't know if it has a type already. Um… Is that what you're saying?
Joe Andrieu: Yeah, that's exactly right...
Stephen Curran: Okay...
Will Abramson: Oh. Manu? Yeah...
Manu Sporny: Yeah, plus one in, uh, general to that approach. Joe, are you thinking… I forget, in linked resources, is this an extra type that goes on the service, or on the, like...
… some other place in the DID document. Like, it could be any arbitrary place in the did document
Joe Andrieu: Um...
Manu Sporny: Path hand, uh, yeah...
Joe Andrieu: Correct, it could… because, uh, linked resource is not a service...
… Because it does not have a… it is not guaranteed to have a URL service endpoint, so we could not use that. So
Manu Sporny: Yeah. Okay, so we're basically just signaling anywhere in the did document, hey, did resolver, if you don't understand this, then you might not be doing this. You know, you might… you might...
… incorrectly interpret the path. And then in that case
… Are we saying the did resolver should throw an error if it doesn't understand one of the. Path handlers
Joe Andrieu: I think that's right...
Manu Sporny: Okay...
Joe Andrieu: Some sort of unrecognized parameter, unrecognized something...
Manu Sporny: Yep...
Will Abramson: Uh… sorry, my, um… IRCs...
… Don't know what it's doing, it's crashed. I think I was next, and I did want to just voice something that Marcus has been saying, at least in the chats that we have
… I mean, I know he's not here, which is frustrating, but he, he said something like, he said, I'm worried that
… that we use the service type to mean, on the one hand, the type of, like, the API protocol EQC that you find at an endpoint. So, like, you know, DIDCOM messaging is defining
… You can use this service endpoint for DIDCOM messaging, and then also defining it as a processing instruction for how we transform. Or handle the path
… I mean, I don't know if that's a problem, but there is two different… you know, you can imagine using that
… I just wonder what people think about that, and maybe somebody else can help me manage the queue, or I… Figure out what's going on, I see
… I think I'm back, actually
Stephen Curran: Manny's on the queue, I think. Oh, yeah, menu...
Manu Sporny: Um, and I'm… I took myself off the queue, racked myself, um...
… Uh, yes, that's fine, right? Like, you know, JSONLD uses duct typing, you know, if the object
… Quacks like a duck. It's probably a duck. Um, and that means that you can mix and match
Stephen Curran: Mm-hmm...
Manu Sporny: completely, you know, crazy things together if you want to. Not that this thing's crazy, right? I mean, like, you know, we're saying, hey, there's a path service. And by the way, it's also got information that you should pay attention to with respect to path handling...
… Um… I think that's totally fine, um, and is expected. The only thing people might complain about is, like, you know, the SID spec is not JSON-LD, or you can do it where it's not JSON-LD, and
… People might get cranky that you can only do this thing for did documents, but it's kind of like
… use dids then, right? Like, um… and I think it's… it's probably also fine to duct type the… the non
… uh, the SID document as well, like, you're really just looking for a type. Um
… that matches something pretty strict. Um, and I think we're gonna end up putting this path handler type in
… the core did spec, and I would recommend we put it in the SID, um, you know, the SID context as well, uh, so it's just globally known. Whether or not you're using JSON-LD or not, this is a thing you should be looking for. Um
Will Abramson: Mm-hmm...
Manu Sporny: That's it...
Will Abramson: Thanks, man. Uh, Steven?...
Stephen Curran: The thing I really like about this is packed service, um...
… Has, to this point deliberately avoided doing things that did Linked Resources and linked resources have, which is have
… some sort of verifiability in the service, so things like, oh, here's the hash of the… of the resource, um, so that
… there's some verification on it afterwards. This certainly opened the door to that, because now you can say
… Something like verified path service is a path handler, and now you can add additional things to it
… And… and get that, um
<Zakim> JoeAndrieu, you wanted to talk about CIDs
Stephen Curran: that additional verification, so I really like this. I think this is great
Will Abramson: Great, thanks. Uh, Joe?...
Joe Andrieu: Yeah, I just...
… I want to bring up the elephant in the room around CIDs, and I'm not
… I don't even know what I want to advocate about it, just that it's a mess. Um, but we should start to socialize amongst ourselves some approaches to deal with it
… Um, did resolution doesn't apply to SIDS
… Um, and so we've got a very complicated set of things that you would do to interpret a did document
… that I think make a lot of sense to also use to interpret if you get back a SID document. Um
… But, you know, these have sort of bifurcated, and I don't know how to heal that
… Like, just get it tractable for us to manage
… Um, so, I'm curious, many of you have any thoughts about it?
<Zakim> manu, you wanted to agree with Joe's trepidation
Will Abramson: Um… yeah, Manny, you want to go? I mean, about different things...
Manu Sporny: Sure, I mean, I think I've said this before, I hate that spec. Like, I wish it never existed. I think we should burn it with fire, but I don't think...
… we're gonna be successful in doing that. I totally agree with Joe and his trepidation, um
… you know, it exists, you know, and it's gonna… it's just gonna bifurcate, like, the things you can do with SIDS is just gonna bifurcate from the things that you can do with DIDS
… And I would like us to just focus on dids and making dids really great and useful, and
… Um, and if people want to, you know, backport features and whatever to Sid, like
… join the group, become an editor, fight for it, you know, that kind of stuff, but I don't think we should pay too much attention. I don't think we're making any decisions, so let me clarify. I don't think we're making any decisions
… that would be impossible to implement in the SID spec. And I think that's fine. Uh, I don't
… think it is our job to go and try and put all of these, you know, features and try to, you know, align DID resolution with the SID spec, like
… let the community that really wants to use SIDS do that, right? Um… That's it
Will Abramson: Thanks. Um, yeah, I put myself on the queue, so I wanted to talk about something else, which is...
… How does this work with, um
… like, digital resources, for example, are they going to have to add a type property? Because they do not currently. I have one, I don't believe
… Um, and then the other question that I had is, for this path handler type
… Is the path handler type defining
… Also, the way in which you match past
… Right, or is it the other type that says, okay, this is how I trigger on specific path?
… Like, basically, is there going to be one way that's consistent across all of these different path handlers? Let's say this is how much pass, or… All people allowed to define their own. hour. Steven
Stephen Curran: Okay, um, first one, I think, yes, they would have to add that, or we have to put weasel words to say, this already existed, and...
… So, it should be included, but I think they should have to add it. Um
Will Abramson: Mm-hmm...
Stephen Curran: I think it is, you know, this...
… This core step, which is collect the objects, find the one with the longest matching path
Will Abramson: Hmm...
Stephen Curran: And that's it. That applies for any path object. You… you have a path in the DID URL, you have a...
… You need to have a thing that is the path in the, um, in the object you're matching, because as soon as you have multiple of those things, as soon as you have multiple did link resources
… Uh, you have to select one, and… and the way you do that is… is this… calculation of the management, so I don't think that
… That's inherent in what you do with a
… uh, path handling object. It's… it's after that that the second type comes into play
… And, um, and that could be
… Both the kind of object it is, or the type of… so that gets a little, a little bit
… flexible, because you've got service, um, and then you've got other things, like linked resources. So, but that's all
Will Abramson: Mm-hmm, mhm...
Stephen Curran: after you've made the selection. The path handling...
… Um, type just says, oh, you, you adhere to this method for finding the path
<Zakim> JoeAndrieu, you wanted to say I do think they will need to add the type
Stephen Curran: For find… for selecting the object. That's it
Will Abramson: Okay, thanks. Thanks. Joe?...
Joe Andrieu: Yeah, I… it's more complicated than that in a couple of dimensions. One is, um, if we already use a path property and have...
… a common path matching algorithm, which I'm willing to consider, but I have some concerns about
… Um, then, uh, did link resources would need to add both the type and the path property
… because they don't currently have anything called a path. They use something else for that. Um
… Uh, but I think, at the end of the day, the service… The type of the service
… Um, needs to deal with how that path is processed
… Um, in particular, um, linked resources, it always points to a specific resource
… for which we have data integrity mechanisms. It is never an entree into a folder
… So there's no amalgamation of what's in the path to, like, construct a longer path
Will Abramson: Hmm...
Joe Andrieu: So that I have a folder that has a bunch of images, and the did URL can point to an image within there...
… Um, all the entries in the DID document for linked resources. Um, are individual
… Um… I think we can
… use the… I think we can use the path algorithm that Steven's presented
… But the way it gets used, in terms of selecting which one we're going to use
… But the way it gets used by each service, I think, is necessarily going to be bespoke
Will Abramson: Mhm. Thanks, Steven...
Stephen Curran: Which is exactly what the algorithm says, so I think we're in alignment. The… all that this...
… When a data algorithm can take a path, this algorithm only says, here's how you select the object
… This is after selection, and it's bespoke to whichever
… object was selected, so I think we're totally in alignment on that
Will Abramson: Uh, yeah, I put myself on the coup to say, I think, exactly, I mean, like, talking about the 5 steps, right? Apart from the bottom step. This step is, uh...
… uh, what do they call, like, determine retrieval strategy
… Right? And then that bottom step, which is just taken off, is, like, execute the strategy and retrieve the results, basically
… Like, I think in the outline. Um
Stephen Curran: Yep...
Will Abramson: And I guess the only thing that's missing from this, if we're talking about that step 3, is, like, above it, there would be this service handling. Thing that would happen first, right?...
… First, if there's a query promoted service, you know, do that. Otherwise… If there's a path
Stephen Curran: I think it's… I think what we're saying is you don't even get to this. So, yeah...
Will Abramson: Yeah, but I'm talking about, like, that step, right? Like, in the higher-level algorithm, step 3 is gonna have to handle both. of folks...
… You know, if… yeah
Stephen Curran: Oh, yes, I see what you mean. In the higher level one, yes, totally agree...
Will Abramson: Yeah, yeah, yeah...
… Um, what about what Joe said about don't link resources, uh, and
… not having a path. You know, is the path handling
… Type, saying that you need to have a path property in your
Stephen Curran: Ah...
Will Abramson: um… object...
Stephen Curran: Plus one from me on that...
Will Abramson: Joe?...
Joe Andrieu: Yeah, I think… I mean, I think this is the grand compromise, and, you know, we should probably get Alex in here and see if he's also aligned with it. I mean, I think all of us are looking at what's the minimal changes we could make to what we've...
… developed and deployed, and I think I can talk Sean Conway into adding a path
… Um, and hopefully we can talk Alex into adding a path instead of the property they're using
… Um, but I think we're all gonna need to make some changes
Will Abramson: Steven?...
Stephen Curran: Uh, just to be clear, um, the linked resource already has a path. What it needs to add is the type...
Will Abramson: Yep...
Stephen Curran: the path handler type. Yeah...
Joe Andrieu: Correct. That's right...
… Yeah, I misspoke. Thanks
Will Abramson: Uh, well, yeah, okay, well, we can, um… I'll try and reach out to Alex and see what he...
… I think somebody would be great to get him in a call. I mean, maybe when we get a PR in, that's fine, we can also point it at him
Stephen Curran: Yep...
Will Abramson: Um, okay, cool. I mean, I think that was a really great discussion. I don't know if there's some more examples we should go through, Steven?...
Stephen Curran: I don't think so, I think we're done...
Joe Andrieu: It...
Will Abramson: Okay...
Stephen Curran: Here's… here's all of them. We've got a path. We've got a service...
… Service takes precedent
… Um, we've got metadata, because we chose a service, the metadata is ignored
… But with other parameters, the metadata may come into play, and so on. So, yeah, I think we covered everything
Will Abramson: Okay. Great. Um...
… Well, in that case, I did, um
Joe Andrieu: Hold on, well, I jumped on the queue...
<Zakim> JoeAndrieu, you wanted to discuss when service doesn't define a retrieval strategy
Will Abramson: Oh, sorry, Joe?...
Joe Andrieu: Uh, there were… there's an element here that we missed, which is, um...
… If we have, and we can see this in PTCR2 today, but I think it's… it's maybe true for a whole bunch of them
… Um, it… uh, BTCR2 defines service endpoints, uh, that have a
… a Bitcoin URL as a… a service which has a Bitcoin URL as a service endpoint
… And if that were specified in a URL that said service equals, and it was, you know, the ID of that particular endpoint
… Um, BTCR2 has not defined what the retrieval strategy should be
… Um, that service endpoint in the BCCR2 world is used as a URI
… It is not directly retrieved in the way that if you ran across that URL in the wild and you clicked on it, the behavior that happens would be to open up a wallet and make a prepay form to pay to that address
… But that is not what we are doing with BTCR2. So I think there's… there is this general problem that some
… Uh, service types have not defined what you do for retrieval
<Wip> w3c/
Will Abramson: Yeah, great. That is actually also what I wanted to bring up, and I wanted to draw our attention to...
w3c/did-resolution#332
Will Abramson: this comment from Marcus on this issue, which is kind of about the same thing. I wondered if, um… let me just stop talking
… I wondered if the solution… it could be, you know, if a service type doesn't define a retrieval strategy. You return the service endpoint. Like, as a default
… If people want to override that, then they just have to define a retrieval strategy in that definition
… I think what Marx is saying here is… is
… Kind of true, like, what does it mean to retrieve a
<Zakim> JoeAndrieu, you wanted to say still retrieve the resource
Will Abramson: I did call service endpoint. Yeah, I don't know. Uh, Joe?
Joe Andrieu: Oh. Yeah, what's… what is the service endpoint? Do we have an example of that?...
… Uh, your last comment just changed what I wanted to say, but, um
Will Abramson: Uh, I think it's just like a URL, right? Like a… I mean, Steven probably has better. Yeah...
Manu Sporny: Mail to, uh, would be an example...
Will Abramson: Um… Steven, do you have an example? Is that why you're on queue?...
Stephen Curran: Um, I was gonna say, you know, for DIDCOM and so on, you just… you never directly reference the service. What you do is you retrieve the DIDDOC...
Will Abramson: Mm...
Stephen Curran: So all you care about is getting the did doc, and then you say, hey, they've got a did comment point, I can use that. Hey, that's good...
… You would never actually reference the URL. So, doesn't help. this conversation, but
Will Abramson: Mm-hmm...
Joe Andrieu: Well, it… it could...
Stephen Curran: Um, for practical experience, you just… you just don't do it...
Joe Andrieu: I mean, we could say it's an error...
Stephen Curran: So, I don't think that's a bad way to do it, because you leave it up to the service to decide...
… what you do, so if you reference it in a did URL, then the service type would indicate. what you do with it, I don't know
Will Abramson: And Joe, you were in the middle of saying something about you should still receive the results. I don't know if you finish your call...
Joe Andrieu: Oh, right, yeah, sorry, that is why I got on the queue, that, um, I think we could support without loss...
… that if there is a service that has an endpoint, and the did URL identifies that service
… Um, and there's no other information about the service type
… Um, that you dereferenced that endpoint
… Um, I think that is the legacy use of service. Um… And
… I'm a little hesitant because of the potential ambiguity, maybe people didn't know it was being used that way, but I think that is the way we've been using it. To Marcus's point, I think he's trying to… Talk about that usage
Will Abramson: Uh, Steven, I think you've been right...
Stephen Curran: Yes, I've been...
Will Abramson: Uh, yeah, I was just gonna say, I think the challenge is Mark's understanding of. Existing use is we don't...
… dereferenced that URL, right? We surfaced that URL back to the… And they decide what to do with it. Uh, and we are now
… Pretty clearly, well, everyone on this call, I think, is very happy to change to, yes, we should be retrieving the results
… But currently, in the spec today, it doesn't matter. Bye
Dmitri Zagidulin: First of all, he was happy...
Will Abramson: I didn't catch that picture, but...
Manu Sporny: I didn't… I didn't catch that, Dimitri. If you want to say it again? Oh, he was happy...
Dmitri Zagidulin: I was just saying, for some values, I'm very happy...
Will Abramson: Huh. Okay...
Manu Sporny: Um, the, uh… what was I gonna say, um...
… It's gone. Sorry, I'll put myself on the queue again
Will Abramson: If anyone you remember, yeah, okay. There's no one else on the queue. Um...
Manu Sporny: Oh, yeah, now remember. So, um, I'm confused about what we're returning. So, we're saying if there's a service...
… and, you know, it's in the URL, what are we returning? And if
… Uh, it's something like a DIDCOM endpoint
… We're returning the… Did dock back?
… Is that… what we're saying, when there are no other processing rules?
Will Abramson: Hmm… too?...
Manu Sporny: You might be muted, Steven...
Will Abramson: Steven, yeah, you're muted...
Stephen Curran: I am muted, sorry about that. An error, um, if there's no… if it doesn't make sense...
… Um, return an error? I don't think that's a bad idea
Manu Sporny: Well, what does make sense? I mean, like, let's say, you know, I've got a service in there, and I'm like, here's my email service, here's my email, like, send me an email here...
… Uh, and I put service, you know, equals email. I wouldn't expect it to
… uh, send an error back, or I wouldn't expect that to error
Will Abramson: Hmm...
Manu Sporny: Well, I guess if you're saying… are we saying, like...
<Zakim> JoeAndrieu, you wanted to say there isn't a "return"
Manu Sporny: Because you want to be able to reference that thing, right? I mean, that's
Joe Andrieu: Manu, I'm on the queue to try and answer you...
Manu Sporny: Okay, got it...
Will Abramson: Yeah...
Joe Andrieu: Sorry. Um...
… the service type would define it. I think the only challenge is when the service type doesn't today define it, so we have some gaps, because we've underspecified that
… But if I have… if my service type is email, then I think that, to me, just
… interpreting the words the way I think they mean, and it should be in a spec somewhere
… that the client who has done resolution, gotten back into duck, and looked at the property and said, oh, hey, this service that's in the URL is email, then they should trigger an email, just as if you clicked on a mail-to URL in a browser
… Um, so I don't… to me, that's not complicated. If it's a DIDCOM URL that we find in the object that we got back from evaluating our did doc
… then the client should know how to process a DIDCOM. Um, entry in the did document
… Um, we aren't returning anything. This is one of the reasons I fought so hard to get rid of the function
… Uh, signature, because we don't have to figure out what's returned. The client either understands how to deal with DIDCOM or they don't
… And they just need to pull the resource into their context and do what's appropriate
Will Abramson: Um, Mana?...
Manu Sporny: Yeah, I think that that's fine and works for me. Um...
… Yeah, I guess we'll just need to see it in the… in the algorithm. Um, that's it
<Wip> aq?
Stephen Curran: Yep...
Will Abramson: Okay. Uh...
<Wip> aack swcurran
Will Abramson: Yeah
Stephen Curran: Yeah, so, given what Joe just said, I would say you...
… the service would… should be advised in those cases to return the DID dock
… Um, you know, non-normative, perhaps, but just say
… Best practices says when you do something where it makes no sense to process the service endpoint, you know, to retrieve the object at the end of the service endpoint, you should simply return the data
Will Abramson: Joe?...
Joe Andrieu: Right, so we're in a situation where the software who's processing this algorithm already has the DID document?...
… And there's no need to return anything at this point
… They could raise or signal an error, like, I like Pierre Antoine's approach to that, to say, you know, hey, we should signal an error, perhaps. Um, but there's no need to return something
… Either they got an endpoint they know how to deal with, or they didn't
Will Abramson: Okay...
… Yeah, so there's still a few bits to figure out here, but I think, um
… I think we're pretty aligned on the general direction, enough to get to PR. I mean, I think I'm the bottleneck here, and I just gotta wade through some stuff with
… Marcus, and also try and fight with that PR, but I do want to get that PR merged ASAP, so we can start. Assigning these to someone. Steven? Oh, sorry. Do you want to say anything?
Stephen Curran: I went on and off. I was just saying...
Will Abramson: Yeah...
Stephen Curran: Wait, sorry, in Joe's… in comment to Joe's...
… statement. We said earlier that if you pass a did doc with a fragment on it, or you pass a
… Um, there's sort of… like a bear did, you get… You get the did doc back
… Um, are you saying that's not the case? I don't quite understand how they deal with the
… I mean, there is no result
Will Abramson: Sure...
Joe Andrieu: yeah, there's an error, so there is no result other than that error. Like, if I've got a URL that says service equals blank...
… And the idea that service maps to a DIDCOM, and I, as a client, am looking at that as
… an RDF identifier, then I don't even need to know how to interpret it as a DIDCOM anything, right? So
… either… either I'm processing it because I understand DidCom, or I don't understand DidCom, and all I can do is error
Will Abramson: Hmm...
Stephen Curran: Mm, okay...
Joe Andrieu: Like, I don't know who else I would give the document to...
… Because I was the function that was trying to figure out how to go through this dereferencing algorithm
Will Abramson: Uh, yeah, I put myself on the queue just to say how I understand what Joe's thinking about it, is… We don't return...
… I mean, there is something that is the result of this process, but we're not returning it to any other party. We are the executor of the referencing as the client
… Um, we used the results of it
… We're not gonna return it to some other party, or maybe we would, and that's up to us, but uh
… at least how I understand Joe, to be framing, is that, you know, the client is using this DDRL for some purpose
… Um, they're gonna dereference it and use it however they see fit
… Anyway, that's my understanding. I think it makes sense, you know, I like the example of, like, for example, a verification method
… That I, um, I'm verifying a proof on a VC, and I, you know, dereferenced the did URL that
… references to the verification method that sign the proof, and then I verified the proof, right? I don't need to return that verification method to any other
… thing, but I… but the result of dereferencing is the… Here's the verification. So
… Makes sense. But I think it's… I think we all get that, but it's just language
<Zakim> JoeAndrieu, you wanted to say if VM = didcomm service, that's an error
Will Abramson: Um… anyway
… Yeah
Joe Andrieu: I just want to build real quick on that example, because I think it's a good one. Like, if… if I put into a proof that the creator of that proof. Um, which is the key. I should be looking up...
… And instead, I accidentally put in a service endpoint that goes to a DIDCOM service
… then the client who is verifying that proof is going to say, that's… I don't know what that is. That is not a verification method. Like, I can't use it. So, the URL in that was simply in the wrong context. And all we can do is raise an error
Will Abramson: Steven? No...
Stephen Curran: Yeah, I'm gonna… I'll take off. I won't say anything...
<swcurran> +1
Will Abramson: Okay, yeah, we probably should wrap. I mean, I think, like I said, this has been a great conversation. I'm really pleased that we seem to be all moving in the same direction...
… Great. And, yeah, as I said, I'm gonna try my best to get this PR in, hopefully by the end of this week, and then
… Um, if I do that, we can start thinking, I don't know who's best to just pick a stab at the step 3, maybe… maybe you, Steven. um
… And then I will say next week… I mean, I'm going to message Marcus, and if he's not here, but next week I want to plan to have a discussion about
… this thing that Marcus is pushing back strongly against, which is whether a did or a DID URL is passed to the resolve
… Um, function, or the resolve operation
… Because that's the last big thing that I think we just need to make a decision on, and then I really think all of this digital algorithm refactoring will be able to be
… Um… fleshed out into PRs, at least, and then we can argue about the details in those PRs
… Um
… Oh, and the last thing that I think we do need to talk about, but maybe that's for the future, not now, but I'm just going to raise it quickly, is, um
… testing this thing, right? Like, we… I mean, we're one month into our 6-month extension, give or take
… Um, this video I'll be referencing, I will
… It's not defined yet, but we'll need to have some form of testing. So, just think on that, um
… And I think that's it. I'll see you all next week. Thank you so much
… Thanks, Steven, for walking us through those, um, examples. It was super helpful
<Wip> transcriber-bot, pause