Meeting minutes
<ottomorac> transcriber-bot-l, connect
Agenda
Otto Mora: Uh, so for today, we really just have two topics, uh, one of them being the new, uh, uh, review of the new intro section to Data URL Dereferencing that Joe has kindly prepared for us. Uh, so we'll be reviewing that...
… And then, after that, we would continue the review of the comments on the date URL to referencing algorithm PR for using the presentation that Steven had previously prepared. So we still have
… couple more sites to go through to review the comments. But beyond that, was there anything else that folks wanted to add to the agenda
Manu Sporny: Sorry, I'm not on, uh, trying to get on hex chat, um...
… Do we have an understanding of where Pierre Antoine is on the DID Methods Charter? And TPAC scheduling, and any of that stuff
Otto Mora: Um, I can check that with him. Um, I believe that the three sessions were already scheduled for Tuesday. And if we need an additional one, we can. But not sure about the charter status. Yeah. I can definitely follow up with that, I'll make a note about that. Rooms. Starter...
Manu Sporny: Okay, thanks...
Review of Introduction Section to DID URL Deferencing Algorithm
Otto Mora: Yeah. Okay, perfect. Alright, anything else? No?...
<ottomorac> https://
Otto Mora: Alright
… Cool. So yeah, let me just move to this topic
… Um, then, um, I believe that we would be using this link. Um, I'll also paste it in Zoom, because, uh, there was some preview issues on the
… on the… PR from the W3C GitHub repo, something to do with the
Joe Andrieu: Alright, can you hear me?...
Otto Mora: the GitHub Actions, I believe, some of the display. So we'll just use the Legendary Requirements link, and I'll yield the floor to Joe to walk us through his changes...
Joe Andrieu: Okay, let me pull up those changes...
Otto Mora: Yep. Mm-hmm...
Joe Andrieu: Okay...
Otto Mora: Uh, yes...
Joe Andrieu: Hopefully y'all can see that...
… Okay, so, um
… This is… intended to be a quick write-up to explain why this dereferencing algorithm is here, how it fits into the rest of the specification, and how it should be interpreted by those reading it. So we introduced dereferencing, and specifically, um
… Start introducing the language about a did URL, and how that means invoking a function that applies it in the current context which will become a handler
… I mentioned that DIDs allow for a number of distinct handling strategies, because we have ways that DID URLs can refer to resources in a variety of ways
… And regardless of that strategy, we first do resolution. So I connect it back up to that part of the, copy. We probably should have a link here
… Um
… But because the document's out of sync, I didn't… I didn't bother putting all the links in yet. Um, we could do that during cleanup
… Um, and then I say, the following DID URL D referencing algorithm describes how a conforming client of a conforming DID resolver prepares for, executes, and handles the respawn… the response to a call to resolve
… And then I do have some normative language, which was one of the things the editors were discussing about whether or not this section should be completely non-normative or not. But I leaned in to the notion that this should be normative because I do feel that conformance clients must execute the steps in this algorithm. Um
… I described that the only required input is the DID URL itself, the context in which the DID URL is being used, which is implied. But here we're making explicit and any configuration details specifically regarding preferred resolvers and available handlers. Those are the only inputs required and the expected side effect
… of dereferencing is the invocation of a handler that applies any retrieved resource to the current context. So there isn't an explicit return value because there isn't an explicit function signature, but we are expecting that somewhere in here, this handler that we are discovering gets called. Um, and then we do have the language around
conforming clients must allow DID URL users to set specific resolvers to be used for any specific DID method. This was pulling it out of the
… Um, outline, so that it didn't seem like you're supposed to do it in the flow every single time, because that would be maddening. Um, and then I realized we had a similar gap with regard to handlers. I used a should language
Otto Mora: Okay, thank you so much, Joe. Did we have any...
Joe Andrieu: we could discuss whether that should be must, but I say the conforming clients should allow DID URL users to set the handlers to be used for any specific handling strategy. Um, that certainly is my expectation, but, um...
… Uh, we have not discussed that at all, so just want to put that before the group, and that is the new intro
Otto Mora: Oh, we have no one on the queue, maybe. Manu, yeah, go ahead...
Manu Sporny: Yeah, just to say it out loud, I like the intro. It feels fine to me. I am still a little concerned about the normative language, but I mean, we're just going to hit that when we go to test it. We'll see what tests. pop up. I know, Joe, you had a number of ideas on how we could test this...
… Concretely, um… The… so, plus one, I think this is better than what we have in the spec right now, and any adjustments we can make, you know, um, in future PRs. I'm, um… I'm wondering, I thought, Joe, I thought you were
… Opposed to specifying dereferencing normatively. That might have just been the, you know, the function signature, you know, part of it. Has your position changed? I probably misunderstood your position
Otto Mora: Okay, thank you. Okay, I'll let Stephen go next...
Manu Sporny: Um, I still didn't really want to make didURL different, dereferencing normative, um, but I'm happy to go with whatever the consensus in the group is. That's it...
Otto Mora: Sure, Joe, do you wanna...
Joe Andrieu: Sure. Um...
Stephen Curran: Did Joe want to respond to Amanda's question there first?...
Joe Andrieu: So I'll go ahead and also make the other comment, which is that Tel Ted has already made a bunch of editorial suggestions. Mostly they look good. I just didn't get through hitting resolve and accept on all of them. So those all I didn't see anything controversial in what he was proposing...
… Um, and then… what I… what I'm opposed to, to clarify for Manu, is defining a dereferencer that is something other than a client. I very much think we do need to describe the dereferencing algorithm
Manu Sporny: It does, thanks...
Joe Andrieu: I do not think we should define a dereference error as anything other than the client to resolve...
Otto Mora: Okay, great. Uh, Steven?...
<Zakim> JoeAndrieu, you wanted to mention TallTed's suggestions generally look good and to mention it is the "dereferencer" as something other than a client that I am opposed to
Joe Andrieu: So, hopefully that helps a little bit, Manny...
Stephen Curran: Yeah, so thanks, um, for doing that, Joe. Um, I'm...
… okay with this. My reaction to it at 1st was, this doesn't get across the point that I wanted. I really reread it and reread it, and it's there. But I find you really have to read the tea leaves
… In that, and the subtle use of words to get the point
… Um, so… while I do think it would be okay to merge, and… Um
… Perhaps it's good
… I don't think it is, but maybe other spec writers that have experience with this might think it's good to be that vague. I I do find it too vague. So I did a separate pass, and I put a comment in with a link to a a Google Doc. That is a rewrite of this. Um
… trying to… based on this, but much more explicit about saying, this is about a resolution client, and this is explicitly not about a… Um, I did… URL library. Um, I did
<ottomorac> comment Stephen is mentioning: https://
Stephen Curran: put in language that say parts, and and I use not just context as a word. That's to me very vague versus
… aware of the business, the business purpose of the dereferencing I did put in that. It's it's. possible that a
… Uh, a library
… Could cover part of this, but, um, that is not business aware, but could cover part of this, so that
… allows for understanding that, hey, part of this is… could be done as a library, but definitely not all of it, because it… it doesn't lend itself, as Joe said, to a… a specific result, so I
… You know, if you want to
Otto Mora: Mm-hmm...
Stephen Curran: Not...
… do anything with that. I… that was my reaction to it, was it's just… it is… it is complete, but it… I found it to be very vague, and, um, really not getting that message across that I was hoping, which is to say, this is a resolution client. That's it
Otto Mora: Okay, uh, thank you, Steven. I see Mano. Thank you...
Manu Sporny: Yeah, this is mostly a comment on Stephen's vagueness comment. It is okay to be vague in a specification, and sometimes it's preferable if the group can't agree on the exact wording or the exact point...
… you know, that they're… that they're trying to highlight. Um, the only point that vagueness is not okay is when it will lead to interoperability failures. I
… don't see how being vague… or I don't see how the… the thing that's written right here will lead to interoperability failures. If that happens, if we, you know, go with what's here, and it's vague, and people misunderstand it, we can always revise in the 1-1
… to remove the vagueness that led to the interoperability failure. But I think… I don't know, Stephen, if making that clarification would make somebody implement this in a wildly different way, uh, that would… that was not interoperable
Otto Mora: Uh, Steven?...
Stephen Curran: Yeah, my worry about vagueness here is that...
Manu Sporny: is my take...
Stephen Curran: without really getting the con… the… context, I hate to use that word again… uh, the context in the specification of how the algorithm is supposed to be used, people will simply implement a… a...
… Uh, a dereferencing service
… and, um, go from there, and then try to figure… they won't be able to understand the algorithm, because it doesn't have enough information in it to… to do that. And
Manu Sporny: That's it. Thank you...
Stephen Curran: you know, for good reason, but without having that context, it would become difficult to implement, and you would get interoperability and implementation problems. You'd turn off...
… implementers, or you would get interoperability problems because they would each interpret how to accomplish it
Otto Mora: Mm-hmm...
Stephen Curran: That's it...
Otto Mora: Uh, okay. Romano again, go ahead...
Manu Sporny: Yeah, I don't know, Steven, if I agree. I think there's a lot of detail here that an implementer can look to. And it may be that we don't want to be that explicit in the first go around. There may be some innovative ways of doing this that we don't want to cut off...
… And, you know, if people read this and they have a hard time, you know, implementing it, I'm sure we're gonna hear about it, right? I mean, that's what Candidate Rec is for. I would rather be
Stephen Curran: Okay...
Manu Sporny: a little more vague in this section at this point than, you know, too specific. So, like, if somebody goes off and they implement a resolution, you know, service, or dereferencing service...
… let them do it, right? Like, that might be an interesting thing to see. I know, you know, Marcus has done it, and he feels that there's a lot of value there. I know that Digital Bazaar does not want to do that. We see nothing but, you know, distributed denial of service attacks against that thing. Um
… But, you know, I don't think we should try and constrain the market too much at this point. I think we should kind of
… see what happens, and then use that for a revision. Um, there's only so much guessing, I think, uh, Steven, we can do, you know, um, on how people are gonna use this to implement
… Another good test is to point a LLM at it and see if it can do an implementation based on the language and see where it gets tripped up, right? I mean, that's a fairly easy first pass to see if we've got enough in here
… All this to say, I think this is better than what we have in the spec today, and I think we'd be in pretty good shape if we merged it in any modifications to it, we could make further down the line. I guess I don't want us to keep
<Zakim> JoeAndrieu, you wanted to point to the two diagrams and detailed language
Otto Mora: Mm-hmm...
Manu Sporny: you know, putting off a merge on at least the text that we're looking at on the screen right now. That's it...
Otto Mora: Thanks, Jeff...
… Uh, thanks, Valerie. Go ahead, Joe, sorry
… No? You're on mute
Joe Andrieu: Sorry The screen sharing interface moved all the mute buttons...
Otto Mora: Go ahead...
Joe Andrieu: I wanna push back that this is vague, Steven. I think there's two diagrams here and a whole another step by step prose description of what's happening. I don't I don't think it's vague. I think it's flexible...
… That is a design criteria because we are trying to find a way to be backwards compatible with all the different ways that different people use different things. to define dereferencing. Um, but… And this is the intro text
… like, the intro text, which actually I don't think is vague at all. In fact, I wish this were less words, but I couldn't find a way to get it to be less words and actually cover the kinds of things that people had mentioned. So, this is an intro to a section that has very detailed steps
… So, I think it's fairly complete. Um, I don't know if throwing it in an LLM is the right answer, but… Um, I think, especially with the accompanying diagram and algorithmic description, I'm… I'm struggling to say how you could call it vague
Otto Mora: Steven?...
Stephen Curran: Uh, to be clear, I think the introduction is vague, and the introduction is crucial to understanding the detail that follows. That's what I'm saying, is vague...
… it… it doesn't convey the point that I was hoping the introduction would do, but that's fine if I… you know, I'm not gonna
… object or anything to it. I did write a an update based on that. And if you want to use that or take a look at it, that's fine. If you don't, that's fine as well
… Um
… I also had originally put my name, gone on the queue, and then forgot what I was gonna ask, but I realized what it was. I wondered about the intention of
… The group… is… is the intention to merge 344 and then… and then do another PR to remove?
… Uh, Section 5. I had assumed that all along, but um
… I just wanted to make sure I understand the intention of the group and what others think about that. I had assumed that, but it's just, I've had that come up in questions a few times and wanted to raise that to ask
Otto Mora: Mm-hmm. Go ahead, Joe...
Joe Andrieu: Yeah, it's a good question to check in with the group about. There had been two previous omnibus updates that addressed multiple sections, and this 344 was specifically just replace the dereferencing in context...
<manu> +1, agree on that path forward -- do the big thing, and then clean up afterwards
Joe Andrieu: Um, so we will have to go through and update links, uh, update any other, uh, language that may disagree with the new approach, etc. So there is going to need to be another round of edits after 344 is submerged
Otto Mora: Uh, yeah, I also pulled myself just to, uh, restate that, yes, like, I… the goal now being to just… exactly, let's go through all the comments on 344, get it merged in with the intro section, and then anything else that needs to be, I guess, further detailed, or… or commented on, or, like, refined. We can do another PRs, but yeah,
like, at this point, let's try to get this one merged...
… Okay, so I don't see any other comments on
DID URL Dereferencing algorithm
Joe Andrieu: Sounds good...
Otto Mora: people on the queue, and I believe we already addressed Ted's suggestions. There's no issues with those, so...
Otto Mora: If it's OK, we can move on to the next topic. Okay. did the URL dereferencing algorithm. And here is the link to the presentation
… Uh, do we want to do the same thing where Steven goes ahead? Yeah, there we go, perfect
Stephen Curran: Yep...
Otto Mora: So, I think I… I had it on your… on your same exact slide, uh, but...
Stephen Curran: Let me see...
Otto Mora: I think I saw you resolved on a few of them. So let's go to the last one...
Stephen Curran: Yeah, um, yeah, I was just jumping through, um, select the resolver, remove any fragment, I think we've gone through that...
… So I've got resolved on a lot of these, so I think here's where we were… well, um
… Yeah, um, so I think this is where we were. Um, I updated this slide after our last discussion. Um
… Joe, you've talked a few times about the client should not blindly pass on version time, um
… I… but I don't think it's ever stated in there, and
… and does something need to be added to the spec to be able to say stuff like that? Like, I find it that if… I were writing it, if I got a DID URL
… Um, with a version time, I would… I would hope it would be processed, but again, that comes back to the resolution client. If… if I don't have a… If if it's generic, you're right. The version time would be
… Determined by the business logic of it, you know, based on what time the thing was signed, or something like that
… Um, you're… I think you're assuming the
… The URL writer is the person who writes, for example, the verifiable credential, for example, and my
… and might do something to the version… to the URL, and it shouldn't be blindly processed. I think that's your thinking on that, but I'm wondering if that needs to be stated
Joe Andrieu: Um...
<Zakim> JoeAndrieu, you wanted to say versionTime is an option to Resolve and should be discussed there.
Otto Mora: Go ahead, John...
Joe Andrieu: Does it need to be stated? Maybe we should have it stated. The...
… Uh, my… sort of… I guess my top level take on it is that this is about a resolution option
… And it's the section on resolution that should explain when and why
… Um, a caller to resolve would use version time
… And so, if the caller to resolve understands what version time is, then they will know whether or not to pull it out of the query parameters, um, or to apply their own version of version time because their business case, uh, requires that
… We did, I thought, to support some change in language here, Steven, I thought we talked about this step. 4 under 611. Uh, in this conversation with your slides. So I thought we had wanted some language there
… I think it's the same itch that you're scratching, so I feel like we've… I've got a little bit of deja vu about trying to
… that did resolution options language there
Stephen Curran: Okay...
Joe Andrieu: specifically to reference what you're talking about. So I'm… I would be comfortable adding a sentence or so to that. Um...
Stephen Curran: Yeah...
… Yeah
Joe Andrieu: I don't think it violates anything about what's going on. It just, and it's not a big burden to say within that section, you know, go figure out the options. This may include parsing query parameters and treating them as options or something like that. Um...
Stephen Curran: Yeah, I realize, as you're speaking, that this… this is in… it's not associated with 613. This is tied to the… What you construct and pass to resolve...
… Um, yeah. Okay, so this is where we got into confusion, and I got
… Uh, confused about where the term round robin… it… it
… Round robin is used, so I think
… This is the 1-4 step
… process. Let me jump to the section and show that. Um… And
… And there's example leans into that there's an array of endpoints. And, um
… you know, obviously, if there's just one endpoint, you try to resolve it. If there's multiple endpoints, could you explain what you expect
… to happen, and what you're implying should happen. For example, should or must they point to the same resource? Are they assumed to be equivalents? Um
… If so, you're assuming, you know, go ahead. Actually, I'll just stop there
Joe Andrieu: Yeah, well, that was an interesting question that… so let me also address that before you go back. I do think the trick here is making sure that they refer to the same resource...
… Um, some of my concerns with different versions of this algorithm were that we were bundling together, um, potentially different namespaces from the DID documents, and in that use case, you wouldn't necessarily expect them to be the same resource
… Because you might have multiple file service endpoints specified in your DID document
… So
… The… my expectation is that this is like DNS. Which is that when the, dereferencer gets the DID document
… When the client of resolution gets a DID document back from resolution, they're going to look at this set of potential endpoints and they're going to pick one. Um, and, uh, execute it
… If it fails, whether or not they exhaustively search all of them is a business
… Uh, decision by the client
… It is not how DNS works, by the way. The DNS round robin doesn't necessarily exhaustively go through because the client doesn't even know that it's exhaustive. The DNS is itself just providing one IP address back, so you don't know how many IP addresses there might be in the pool. And so in a similar way, I tried to describe that algorithm
… Where when I'm evaluating the handling strategy to understand how I go and get a resource, I want to go through this sample set in a reasonable way
… And describing this around Robin was my attempt to do that
… Certainly, maybe the language could be clearer. Um, but one of the things you're, um
… question suggested was that the client, should potentially should, go through all of the endpoints in the set
… And I think that's probably a step too far. But we as a group could talk about which of these possible interpretations are legitimate. I don't have a skin in fight, just a place where I started
Stephen Curran: Yeah, you've got this line in there. In other words, if multiple endpoints are available, only raise if all endpoints fail. So you actually have that in there that you should try all of them. Is that what you mean?...
Joe Andrieu: Oh, yeah...
… I actually… I'm not sure we should have that
Stephen Curran: Okay. And that's also where this...
… step one is just picking one of them, and step four is where you resolve it, but that's what confused me about… I thought it was all in step one, because this line says
… keep trying them, except you don't try them until down here from my later interpretation of your comments. So that's was confusing. So
… Um, I… so yeah, I think it might be the suggestions I have, which is
… Do we assume that if there's multiple, they represent the same resource, just multiple places to get the same resource, and then what do we do with this comment, this line, which is, how do you decide whether it's a fail or a
… Or keep trying. So that's clarification that could go there as… in whatever way you want
Joe Andrieu: Yeah, I'm curious from the from the group if anyone has opinion about...
… Should we say you should check all of them?
Stephen Curran: Okay...
Joe Andrieu: Um, which is the current pros, which is not what I thought it was. I really could go either way, but whatever the sense of the group is, we should use that...
Otto Mora: Okay, uh, C. Mano, thank you...
Manu Sporny: Um, it feels like if someone… Uh, lists three things there. that you should. try all of them. I'm trying to think of like, you know, how would somebody use this thing? And then I'm thinking, well, it might very much depend on. the service type, which I don't see a service type in here. Is that a… did we leave that out on purpose?
That's a little concerning to me. Is that ID supposed to be type?...
… um
… So it does feel like, you know, if you list multiple service endpoints, you should be attempting, you know, um
… You should be attempting all of them. Yeah, this really feels like it depends on type
… Thoughts here? Yeah, I'm a bit thrown off by the example
Otto Mora: Joe?...
Joe Andrieu: Um, yeah, we could tie it to type. Um, this particular example doesn't have a type value. Um, it gets absorbed under that ellipsis that's pulling a lot of heavy work. Um...
… I think checking all of them before an error is not a bad strategy
… Uh, but the reason this may not be type-specific is that the service endpoint allows multiples. And so it seems like
… Um, we should have a general rule for that. Um, we could push it into the types, but then each type would have to specify the same thing
… Um… So… I don't know which of those might be preferable
Otto Mora: I know...
Manu Sporny: it feels like if somebody is going to list multiple service endpoints, they're doing it for redundancy, um, meaning, like, you know, it's a load balancing redundancy thing, and each… and I would expect all of… they… they expect...
Joe Andrieu: Oh...
Manu Sporny: that resource to be available through each one. So as a general rule, if we don't look at type, we could say you have to try all of them. And then we can say unless they're the type overrides this rule. So there's always a general like, you know, without, you know, with it. Yeah, so you… Go ahead...
Joe Andrieu: Sorry. Sorry, let me jump in, Manu. I forgot. This is the default service handler...
… For when there is no type
Manu Sporny: Yeah, okay, yeah, then it should check all of them. I think...
Joe Andrieu: Yeah, fair enough. We do have if it's typed, like that's the type specifies the handler strategy. So I think that loop hopefully is well represented in the pros. And then this was...
… If we bump into a service endpoint that doesn't have it because it's legacy, then here's what you should try to do
Otto Mora: Okay, Kevin is in the queue...
Joe Andrieu: Sorry...
Kevin Dean: Yes, just a correction to something Joe said about DNS. If you do a DNS lookup on a name that has multiple IP addresses, you will get multiple IP addresses back. It is then incumbent upon the client...
… to, uh, figure out how to deal with them, you know, in the event that one of them isn't accessible, it'll go to the next. But DNS itself will respond, saying, here's everything I've got, here's all the addresses, you deal with it
Stephen Curran: Okay...
Otto Mora: Uh, yeah, before that, Emmanuel was on the queue...
Manu Sporny: The, um… I'm building off of what Kevin just said. These are… these are… this is an algorithm that the client, um, the resolution client's executing, is that right?...
… So, the way to interpret, Kevin, what you just said is, we are writing rules for the client, and we're telling the client, like, if you don't have a type, check all of them, is that… Correct
Kevin Dean: Yeah. Yeah, if your browser can't access address number one in the list, it'll then go to address number two. That's how the client B is expected to behave...
… So, if we've got multiple… Uh, uh, your URLs that match the
… Service handling requirements for the client, the client
… It should start with the first or start with what it thinks is the first and then fall back to the next and the next and the next if they're not available
<Zakim> JoeAndrieu, you wanted to mention ordering
Otto Mora: Okay, I see Joe. Go ahead...
Joe Andrieu: Yeah, the, um… so thanks for that clarification, uh, Kevin. The, um...
… What I am seeing from Google's omniscient Gemini AI assisted response is that one of the things DNS does that we can't do
… um, or that I think we shouldn't do, is vary the order of the response. So, um, I didn't think you got all of them, but Kevin's correct. Um, all the IP addresses come back, but the order gets cycled
… Um, and we don't have that, so we just need to make sure that the language makes it clear that you should pick one
… Um, and not treat them as ordered, but then make sure you go through all of them. And I don't know that we have the pick one randomly. Uh, and the text
Otto Mora: Okay, Banu?...
Manu Sporny: Yeah, and, uh, plus one to that, and to… and that… that's aligned with the JSON-LD, you know, expression of this, which is it's a set, it's unord...
… So he shouldn't presume order
Joe Andrieu: Yeah, and I wouldn't want the resolver trying to keep track of that...
… Although that's how DNS does it. Um, we just haven't talked about that kind of dynamic… Functionality, um… anywhere else yet
Otto Mora: Okay, Kevin...
<swcurran> That's what I meant by my early comment on this about why round-robin
Kevin Dean: Yeah, we should also remember that programmers are lazy. Speaking as a programmer myself, I definitely am. And they're not necessarily going to read the spec to see anything that says you should pick one at random. The lazy implementation is to go through the list from top to bottom...
… And we should expect that would be the most common implementation. So it is really up to the… No. service handlers, uh, up to the… up to the DID
… To make sure that the document hasn't been in order where, you know, the
… The one at the top is the one that can handle the most requests. If you've got others, they may be backups
… We should not expect that the load will be evenly distributed
… We can provide a shut-in. The DNS randomization is a nice feature of DNS, and it puts the onus, it takes the onus away from the DNS. Programmer to do randomization
… And it's a nice feature, but we can't do that in the DID document without messing up the hash
… The best thing we can do is they should choose one at random
… And then cycle through if that fails until they're exhausted
Otto Mora: Steven...
Stephen Curran: Uh, quick question, just to confirm, Manny, that what I stated, uh, in this result, JSON-LD says that if you have it in square braces, that's a set and not… not… and unordered. Okay...
… Okay. Hmm. Okay
Manu Sporny: That is correct. Yeah, you can explicitly state that the… that order matters, but I don't think we do that for service description, or for the service thing. I'm looking that up right now, but I'm pretty sure that's correct...
Stephen Curran: Mild...
… Okay
Otto Mora: Okay...
Manu Sporny: Yeah, just confirmed it's unordered. Service endpoint is an unordered set...
Stephen Curran: Um...
… Section 6.1.7 #2\/3: Path Handling Avoiding RFC3986\/WHATWG URL
… Uh, I think the two rationales on this one
… is, um, Joe provides
… Uh, steps on how to append a path
… To the path of a service endpoint to get a resource path
… Um, previous uses, whenever we combine. Um, a
… a, uh
… You know, uh… a base URL
… with a relative is to use RFC 398652. Um
… I'd be… in looking at this further, I mean, we've had lots of discussions on this, because this is strictly to do with PATH. and has nothing to do with fragments or parameters. Um
… It seems to me it
… I would be intrigued to know the difference between Joe's algorithm and what
… RFC 3986 would provide. Um
… I… I'd much prefer that we would stick with, um
… the libraries that people are likely to use, but, you know, I'm
… Not gonna go further on that. Um, first of all, I need… is anyone on the queue for this one?
Otto Mora: No, not at the moment. Oh, Joe is now...
Joe Andrieu: Sure. Yeah, I just jumped on. I was letting you get out your opening bit...
Stephen Curran: Awesome...
Joe Andrieu: So there are two things that are happening with 3986 that I think are problematic, which is why I shifted to a simpler path-based expansion rather than a URL-based expansion. And I do think there are lots of libraries out there that handle path expansion...
… And so, as long as we don't treat this as a, as a URL, as specifically as a relative ref, then, I think there there are lots of libraries that can do what people need it to do. The, the, the two problems that happen are one is, is the
… The point of control of the con of the context that you're in. And a web page when you come across a relative ref
… um, it's understood that the author of that HTML page arranged the code in such a way that that URL would show up in that page
… There could be Javascript involved. It could be dynamic. It could be based on an Ajax. But the understood security model is that the HTML that's running in the browser that has the URL was the URL was written by the same party or controlled by the same party that wrote the HTML
… And as such, the relative ref function was intended to allow the writer of that HTML to refer to any resource that might be in the domain that is the base for that HTML. In fact, you can go all the way to the root of the domain
… And basically replace everything except for the authority part in the URL. So you can rewrite the path, you can rewrite the fragment, you can rewrite the query part. And so
… Because we have a separation of the the authority for the place in which the did shows up
… And the authority in which the, service endpoint shows up which is in the the document
… Um, we no longer have a unified security context, so that the person who is, uh, defining the URL can understand and control what's happening in the DID document
… So I think the ability for anyone writing a DID URL to change all of the parameters or all of the parts, rather than letting them simply append a path
… Which lets us address this file server use case. It doesn't let them, like, go to the root of that file system, um, it doesn't let them perhaps masquerade as another user by, uh, putting in a query parameter that would shift the user, things of that nature
… Um, and… Uh, so that's context control
… Um, and the complete rewrite. Those are my two concerns with just blindly using 3986. We are not, in fact
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Mmhm...
Joe Andrieu: using the relative ref in the way that it is in HTML. We are using that in JSON. When we refer to, like, a key, and we just want to have hashtag key...
… You know, when we're in the DID document itself. The context of that document does allow relative refs
… Um, to be used, we don't have to change anything, it's part of the media property, we get it for free
… Um, but using the relative ref algorithm outside the context in which it was created, I think is pulling in a whole bunch of heavy lifting, um, that, frankly, I don't think is a good idea for us to expose to end users
Otto Mora: Okay...
… So whilst Stephen is looking that up, Manu has also his hand raised
Manu Sporny: Yeah, those are, that was a very interesting insight, Joe, about, you know, the way that a relative ref is used in a webpage is not the same way we're kind of using it here in all cases...
… Uh, and, uh, and, and it resonated with me. The point resonated, uh, with me definitely. Um
<TallTed> s/TallTed \/\/ Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Mmhm...//
Manu Sporny: The only thing I'm concerned about is TAG coming back and saying, why aren't you using, you know
… path normalization rules that are used in, um
… that are defined in what WG and that sort of thing. And if that's our answer, I think that's a good answer. But I'm concerned I don't know enough of the details that maybe are in your head, Stephen, about what the concern is. Um, here is, um
… So, so for example, the, you know, the, are we saying anything about dots or, uh, in the path or percent decoding? I think the answer is no, we're not on purpose, because it's something else that needs to do
… path normalization. It's not this algorithm that does it, and we are expecting… and Joe, I don't know if this is true, but we're expecting, if a developer wants to do that, they're going to run the WhatWG
… algorithm on it, and I don't know if we're telling them you're forbidden from doing that, or, like, go ahead if you think that's the right thing to do in your context. Um
… And then the relative ref and the did URL query parameter, is that… are you saying, like, deprecate that entirely, Steven? Is that the question you're asking here? That's it
Stephen Curran: My question is yeah. So I'll I think I'm on the queue anyway. Yeah...
… Sorry, I couldn't find this section
… Yeah, I was wondering about the… the dots in that, because if we're punting on that in the use of this, if we're not talking about that, then that just moves it to the next step, which is when you
… Um, dereference the resulting URL. Um, I did want to confirm
… Joe, you only deal with the past, so you've stripped everything else off before that. And then the second question I had was
… I just want to make sure we're not talking at all about the relative ref did URL query parameter, the one that's been in the did
… This did resolution for a while, because that really is
<JoeAndrieu> hmph
Stephen Curran: I totally agree. That's a super messy parameter that changes things. But I think all you're talking about is… Extract the path
… from the DID URL, and then combine it with the service endpoint
… That's it
<Zakim> JoeAndrieu, you wanted to say not stripped. just isolated.
Otto Mora: Just go ahead, Joe...
Joe Andrieu: Is there a way is there a way to just clobber the queue? Um, okay. Um...
Otto Mora: Okay...
Joe Andrieu: The, uh...
… Um, it's
… So I do think we should be silent on dots in the path
… Uh, I think if… if people choose to put dots in the path, then somewhere in the process might choose to normalize that. Um, but I don't think we should. Um
… And the main thing about relative ref here is that it doesn't have an application
… Um, and the default service handler, or any of the other service handlers
… So, if we wanted to have a handler type
… That uses the relative ref property, then we would have to figure out how to use it
… and to to my sense, the relative ref property
… Um, is a security hole that we didn't realize was as big of a security hole when we created it
… So, what I've been trying to do with this particular set of changes is to address the underlying use case that I think we have consensus around, that we want to be able to have a DID URL that represents a file server and be able to reach files, multiple files, that are hanging off of that by appending to the path
… And so that was the algorithm I tried to embody here without entangling You know, because relative ref comes from 3986, it should be processed. If we're going to use that term
… then we should process according to 3986, but I think 3986 is a mistake, so I don't think we should be processing relative ref in that way. Um, but I know, Steven, that that probably frustrates you that I'm making that case
… I think you would prefer to keep that, uh, parameter
Otto Mora: Steven...
Stephen Curran: Yeah, I mean...
… I don't want to keep that parameter, no. I do think it
… is not good. So yeah, I've been dealing with it but I don't wanna keep it. My biggest thing is because we're down to just append the relative ref in the 3986 mechanism is simply a path. then I think
… Um, your concerns
… Um, are less relevant, and therefore, it would be easier if we just said, oh, just use
… either 3986 or what WG, to combine
… the path, which is the only part of the URL we're taking, and the service endpoint, because it doesn't have the risk that you're talking about. You can't rewrite all those things
… That said, if you use DOS, you can climb up and out of the. Uh, area, which
… is just punted to somewhere else, which that's fine, too. I mean, I'm not gonna it's not a hill I'll die on. But those are why, I just think it would be better to stick with a known algorithm than to introduce a new algorithm. that
Otto Mora: Okay. No?...
Stephen Curran: Especially one that's taken years of iteration on to get. And there's lots of libraries out there. That's it...
Manu Sporny: Yeah, and I don't have enough of the details in my head to understand all the side effects here...
… I think, you know, at some point, somebody has to do URL normalization, right? It's either you do it on the client side, or you're gonna take this entire thing, and you're gonna send it to the server, and the server's gonna do it on the server side. And when the server does it on the server side
… um, uh, they're gonna use the, the, you know, WWG, um, uh, algorithm largely, unless it's a very, very, very old server. Um
<swcurran> +1 to Manu
Manu Sporny: So that's just, you know, I don't know if it really matters where it's done. It's gonna happen at some point. If we don't do it, somebody else will do it, uh, for us. Uh, we being, you know, the implementation. Um
… And then, yeah, minus, like, we should deprecate relative ref. Totally different point. We should deprecate relative ref and tell people to not use it. They should stop using it. And then we should throw an error in a couple of years on it. That's it
Otto Mora: Steven?...
Stephen Curran: Just a… just a quick note to say, if we got rid of the relative ref query… did URL query parameter, the, um...
… Normalization section would become. Much smaller because it mostly covers the dangers of that query parameter. Definitely, we support that
Otto Mora: I don't know...
Stephen Curran: Oh, right. Yeah, okay...
Manu Sporny: Well, unfortunately, Steven, I said deprecate, not destroy. I prefer that we destroy it. I don't like it at all. I think, you know, we have a better option these days...
Stephen Curran: Yeah...
… All right
Otto Mora: Phase destruction...
Manu Sporny: But I don't think we can. I think we'll get objections if we try to remove it entirely. So just deprecate it...
Otto Mora: Okay...
Joe Andrieu: So...
Stephen Curran: Um...
… I think we should probably stop, and we're almost done, but there's just a couple more things in here
… And… and we'll do that the next time. I think we're close to time. I don't know if there's anything else we wanna
Otto Mora: Joe… yeah, Joe's… Joe's on the… Go ahead...
Stephen Curran: Okay, good...
Otto Mora: Joe?...
Joe Andrieu: Yeah, actually, I guess I answered my own question, but...
… Uh, I was trying to answer the question if… so, I… I agree the next step is… would be to deprecate. Um… Uh, as well
… version in which it's deprecated, so that the rest of the world can sort of start moving in that direction. Um, my first thought was, um… But do we need it in the default service handler?
… And I think we don't, because we do have the query parameter fallback. So, in the algorithm, we do get to a point where, um, if we have not yet found a handler, um
… And the user understands relative ref, right? The client software understands and sees this relative ref query parameter term
… then there is a place in the algorithm where that gets invoked. So I think… I think we can… we will pick it up if it's there in the legacy fallback in the algorithm
… And so the deprecation, I think, just heads over to its definition where we have it right now defined as a term
Otto Mora: Okay, cool. Yeah, do you want to talk about the plan for next week, Steven?...
Next Time
Stephen Curran: I mean, I'll just do continue on from this time. I'll remember that we're at 16 and be prepared to talk about these three...
Otto Mora: Yes...
Stephen Curran: Um, I'll add, um, additional notes...
… as I can answer this. Joe, I think this one's just over to you to either do something or not do something, and we'll go forward and then we'll cover the last 3 in the next call hopefully, and we'll be done
Joe Andrieu: Sounds good...
Otto Mora: Yeah...
… Yeah, I was thinking, yeah, like, we, maybe we have the special topic just to go over these comments. Review. Maybe whatever Joe has had a chance to update on the Pr. And then final final review. Thursday, next week, after
… uh… at the end of that day, we just merged the PR, and
Joe Andrieu: Hold on, hold on. We've actually got dozens of edits to the PR...
… Um, that aren't in the PR, right? So we've been working through this slide deck
… And so if we're still working on the slide deck on Wednesday, we're not going to have those edits by Thursday
Stephen Curran: Right...
Joe Andrieu: Right, there's just… there's gonna be some delay there. Um...
… We can definitely have the final PR by the following week
… Because I can… I can make sure I carve out time between then, but uh… between Wednesday and Thursday, I can't… I can't commit to getting all those edits in
Otto Mora: Okay, well, then, yeah, we'll do our best...
… Um, alright, cool
Joe Andrieu: Awesome...
Otto Mora: I think we're good...
Joe Andrieu: Thanks, Steven. Thanks, Adam. Thanks, everyone...
Otto Mora: Thanks, guys...
<TallTed> s/TallTed \/\/ Ted (he\/him) Thibodeau Jr (OpenLinkSw.com): Mmhm...//