Meeting minutes
Agenda Review, Introductions (5 min)
<ottomorac> transcriber-bot, resume
VCWG f2f Next Week: No Calls
Otto Mora: Okay. Uh...
… Okay, so I guess, yes, next week there is a verifiable credentials working group. Okay. Any, just anything anybody would like to, add to that, agenda or any other thing to point out to?
… I know that the CCG meetings, at least, have already been canceled, but I wanted to kind of ask the group, do we also cancel our meetings for that week, given
<manu> yes, let's cancel the meetings, please -- at least 3 of us will be gone.
Otto Mora: Given the face-to-face meetings, or do we have quorum to go ahead and meet?
… Any thoughts from
Stephen Curran: I'm available to meet and think we should if we can...
Otto Mora: Okay. And Mano, I think you're...
Manu Sporny: Um, I think I'll be gone, Will will be gone, uh, Joe will be gone...
Stephen Curran: Thank you. Never mind...
Joe Andrieu: Thank you...
Stephen Curran: Go ahead...
Manu Sporny: I just… adding that, like, you know, I think that might be difficult to have a meeting, but, you know...
… Happy for folks to meet and make progress where we can
Otto Mora: Mmhm...
Manu Sporny: That's it...
Otto Mora: Yeah, no, I think it… uh, Joe, yeah, go ahead...
Joe Andrieu: Yeah, I just wanted to ask Steven, what topic would you want to discuss without us? Maybe there is something you could do productively. It's kind of off my radar...
Stephen Curran: I didn't know… I didn't… Yeah, I just didn't know who was gonna be gone, so… Nobody was saying anything, so I just said that. But if… if… Half the group, three quarters of the group, it's...
… Here today are gonna be gone, then yeah, it seems pointless
Manu Sporny: Ted is going to be gone too in just a sec...
… And I think I forgot to mention that Ted's going to be attending as well
Stephen Curran: Yeah...
Otto Mora: Okay, fair. Uh, makes sense. Yep, I think then, yeah, group decision, we won't have calls next week...
Special topic call summary (5 min)
Otto Mora: Um… let me… Move on. So, uh
… Yeah. So for the call yesterday, we discussed a bit about the Prs that we would be creating. And I know Steven had mentioned that he'd be working on some of them. And then we also had a conversation around
Will Abramson: Uh...
Otto Mora: uh, the input to the DAD resolution algorithm. Um, I don't know, Will, should we… do you want to briefly, maybe, add anything in terms of summary?...
Will Abramson: Well, I think we didn't make any final decisions, but we did lay out the arguments, uh, for and against...
… Move forward, Sarah
… And I think, you know, that's what we're going to continue today. And I just want to remind folks again of, you know, we are on this short timeline, we're already over time, and we do have to make some difficult decisions
… that's really all I have to say about that. I mean, I think Steven had a good idea to, like, start the call, like, ground it with the two options, but
… By the end of this call, I would really like for us to pass the resolution and put this issue to bed and move forward
Otto Mora: Uh, yes, Stephen...
Stephen Curran: So I went through and laid out on a slide, to me, what are the two… So we've got the first two steps of… Um...
… the Pr. That was merged from Will. I've laid out
… Given the two options, here are the steps they would be, and I'd like to share them if that's okay with people. Are we okay that I share my screen for a second and show what I think are the two?
Will Abramson: Does not make sense to me...
Stephen Curran: No...
Otto Mora: Yeah, right, I think that's fine. um...
Stephen Curran: No objections? Okay...
… So
… This would be steps one and two of DID URL dereferencing based on what we'll already put into that 331 PR that we merged
… Um, if we stick with the idea that the did… did URL… or, sorry, did resolution
… Here's what I think the steps would be. deals only with the DID. So DID resolution does not accept a DID URL
… The dereferencing steps would be receive a data URL
… A May
… Um, I put this one as
… And I put brackets around it because I'm not certain of this one. But anyway, some implementations. I could put an S on that, may accept an options data structure
… Verify the received URL for validity. I'm going to call out here that I mentioned the other day that did WebVH because of its use in the Linux kernel group is using for it. They did a pass through
… Basically, all of those, the code for DidWebDH and a bunch of the results came from not
… doing validity on the URL and those items that we passed in that merge a few weeks ago of security warnings about the URL parameters. But anyway, that's what the verify would be, but no details on that one at this date
… Okay. Remove the path and parameters to create a bare DID
… Create, if needed, an options data structure, and add to it each parameter from the DID URL. So you're going to take the DID URL, and no matter what the parameters are, you stick them in the options
… Invoke the DID resolver passing the bare DID and the options and process the DID URL thereafter
… That would be the steps where we don't touch did resolution and. And
… they would be. Does any… does that match what people agree with?
… What they would envision it to be
Otto Mora: Uh, Marcus? Let's see...
Markus Sabadello: Uh, yeah, yeah, Steven, that definitely matches how I've always understood it, and how the...
… Algorithm has been has been written. I think that's a good summary
Stephen Curran: Okay, second one… Okay...
Otto Mora: So, hang on, manuals, or one or two? Okay...
Stephen Curran: Oh, sorry. Mac… whoops...
Manu Sporny: Yeah, no, I mean, our, you know, I mean, internal discussions, our implementations would only...
… Uh, put stuff into the options that were recognized
… So that's fine. I mean, you know, we don't care either way. I mean, like, this is an algorithm, we can implement it, but we did not implement it, or this is not the expectation. Like, the only thing that we would end up pulling out would be URL options
… Uh, that we understood for the did method, uh, in play
Stephen Curran: Okay, let's leave that as a detail...
… Yeah. Um, and that one, again
Manu Sporny: But we don't need to change anything. Yeah, yeah, that's fine, yeah...
Stephen Curran: Yeah, for me, you know, because there's things like extensions and so on, a client is less likely than a DID resolver to know what matters. Um, but anyway, yeah, we can leave that...
Otto Mora: Nothing...
… But
Stephen Curran: Then this is the second one, so I'll jump to the second one. Yeah, oh...
Manu Sporny: Hold on, sorry, Steven, to go back, the reason we strip stuff out is because we're concerned that, you know, just blindly doing that, you could have attacks against the resolver that end up passing options that you never intended to pass, like options...
… can be a bunch of things that, um, that you, you as, uh, you don't want the attacker to choose
… Dangerous options. Uh, uh, a certain subset of options, and if we did this algorithm, it would allow the attacker to choose
Stephen Curran: Okay. Yeah...
… Yes
Manu Sporny: Which is why we did not implement it like this, right? So anyway, we can go on, but I'm just saying, like, this is the problem that we have with this approach...
Stephen Curran: Yep. Well, we're gonna see that in the next one, then...
Manu Sporny: That's...
Stephen Curran: Create, if needed, an empty options data structure, and that's because...
… Where did Resolution accept a DID URL? So the same step for number one, receive a DID URL. Some implementations may accept an option data structure. Verify the received DID URL for validity. Did resolution has already been defined to have options?
… Invoke a DID resolver passing the DID URL and options
… And carries on. And then processed the URL with the resulting DID document that did metadata. So assume that they did resolver, accept the URL
Otto Mora: So, I see Will first on the queue...
Will Abramson: Yeah, I was just gonna say, like, I don't think this… this options data structure is empty, or not necessarily. Uh, right, like, it's...
… up to the client to decide which options they want to additionally provide. I think Joe had some good examples, like, for example, you know, if you have a
… Verifiable credential with a specific issuance time, or, like, an expiry date. you
… might want to resolve the verification method on that bid, but also for the specific time that you're kind of additionally adding in
… So it's basically you create the options with options that make sense to you. I don't think it would always be empty
Stephen Curran: Options… Um, okay, so… so hang on, so...
… Uh, I believe options are just parameters
Will Abramson: What?...
Stephen Curran: That are passed in a different way. And...
Will Abramson: Whoop-a-thank Earl...
… I think they are, well, currently they are parameters, but also you can just, they don't need to be parameters, right? Like you can resolve a did with some options. And those options don't have to have come from the did URL. They can just come from there. Um, resolving part
Stephen Curran: Okay, so that would require a dereferencer would need this step...
<Zakim> JoeAndrieu, you wanted to say I think options data structures are a MUST
Joe Andrieu: I'm on the queue to talk to this, Ste...
Stephen Curran: Um, I did… okay, go ahead...
Joe Andrieu: I think it is a may, but on the client side, not on the server side...
… So the… the dereferencing clients may have options that they care about. Uh, verifiable credentials, a good example. Like, the… the DID URL that is… is pointed to in the… in the proof property. Um, may not have a version time on it, but we may want to add a version time option
… And I believe this is this is the pattern of HTTP headers. You can you can absolutely do an HTTP get without adding any headers. But you might for good reasons. And so I think the client might add options for good reasons. And that means that the server needs to be able to handle options coming in
… But it will also need to parse the did URL to get the query parameters from the URL
Otto Mora: Okay...
… Let's see, Mano next
Manu Sporny: Yes, uh, plus one to what Joe said, um, the data… the options don't always have to come from, you know, the query parameter, uh, URL. Uh, it also opens a question on, like, our expectation is the options would override, um, what's in the DID URL. That's… that's given. I don't know if we've… we've...
… we had a discussion about that. And then the options can also have, uh, things that are totally unrelated to the DID URL, things that you know the resolver can do, um, that are specific to the resolver you're using, um, and so on and so forth. So it is very important to have both of these things
… you know
… Um, because if you only have one of them, you have to do
… potentially, you know, weird things and you can't override and you have to make decisions when you don't necessarily have all the information that you need to make the decision. So a plus one to this
… but the expectation is that, you know, the options are not empty. Uh, if they, you know, conflict with what's in the DID URL, they override, and then they can also have things that are completely independent of the DID URL, um, and any kind of query parameter. That's it
Otto Mora: Okay...
… Marcus?
Markus Sabadello: Okay. A few things. First. just have to… to mention again that I… I objected to merging the pull request to 331. Um, I… I know we probably don't want to spend time on the call about that, but I… I don't think that, uh...
… process for reaching consensus against objections was followed. I'm not an expert on this, but I read something about call for consensus and votes and things like that, and I don't think that was
… that was done, so I think while we're still discussing these things, uh, that pull request should not have been… There's, um
… Having said that, I fully agree with what Joe said about
… I also agree with what Manu said, that options would override what's in the… Client might want to add options for good reasons in addition to two parameters in the URL. This is a little bit like HTTP headers. I fully agree with that
… Parameters, um, and… Yeah, with regard to
… to these two options that I think Stephen summarized them really well. I think it's well known that I'm very much against the second option, and
… Uh, prefer the first one, the way how it's been, um
… I don't understand the argument why, what would be dangerous about that
Otto Mora: Uh, yes, Steven...
Stephen Curran: Um, I… I'm confused by what, Joe, you're calling a client. Is… I thought the client would be the thing that's invoking...
… the DID URL dereferencer, so it would be supplying these two inputs, these one and possibly two inputs. So, um… I'm not sure
… where you're using it. I guess maybe you're using the term of the client of the resolver, but that just gets confusing to me. And then the other
… Manu, if you're saying that the input must have
… Um, an options data structure, and must
… even override the URL with those. I think that
… would adjust this first step. Is that what you're suggesting, is this first step is wrong, and then, in fact, in client… And… did URL
… dereferencing the. Data structure? There has to be an accept
Otto Mora: Okay...
<Zakim> manu, you wanted to suggest we do a CfC today on 331, also. and to clarify misreading the slide.
Stephen Curran: That's it...
Otto Mora: Uh, Manu?...
Manu Sporny: I think Joe was on the queue...
Otto Mora: Oh!...
Joe Andrieu: Yeah, that's alright, I know. Um...
Otto Mora: Apologies. Yes, sure. Right...
Joe Andrieu: Uh, I'm confused by your confusion, Steven. Um, there's one client, and it's a client of the resolver. There's a resolve call that we're talking about, and the question is whether that resolve call takes a DID or a DID URL...
… I had thought we had resolved that the client here is what we sometimes call the dereferencer as opposed to having a separate service endpoint that then creates the potential for two different kinds of clients that we have to distinguish who's calling the dereferencer service and who's calling the resolve service. So, I don't know if you just
misspoke, or… or I missed hearing you
Stephen Curran: No, that's that's just never been clear to me, and I don't. I don't really understand. But that's okay. That's I don't want to distract us from that. Um...
… this… Okay, so you're saying it's just the invoke the DID resolver, and the only question you have in this whole thing is you don't care about these other steps, you just care about whether. is in here
Joe Andrieu: Well...
Stephen Curran: This word is in here...
Joe Andrieu: I… I don't know who's receiving a DID URL...
… Um
Stephen Curran: Like, okay, so let me give a concrete example that's been used before. A VC has been signed with a DID URL, which I think is a...
… a thing that I'm promoting as a use case, where I would like to see
… Um… you know, in signatures in VC, not only the fragment that it identifies the key, but also a version time parameter. So I might see a… did URL sign a VC that contains version time and… And the, um… PID
… So we stripped off that. That's what I am expecting as the input to here would be the thing that was used in signing the VC. Not only that, but I would expect that
… The caller to this might even add the version time, because they want to know what
… on their own. The state of the DID was at the time it was signed. So they've got this VC that was signed two years ago. They want to process it at that time. So the input DID URL to the dereferencer they pass, they add on version time
… That is what I'm expecting as this input to step one. And then the rest of steps. The rest of the steps are simply
… deterministic steps to invoke a DID resolver
… So that's how I see it. That's it
Otto Mora: Okay, uh… Yes, now, Manuel, go ahead, yes...
<Zakim> manu, you wanted to react to JoeAndrieu and to you wanted to suggest we do a CfC today on 331, also. and to clarify misreading the slide.
Manu Sporny: Yeah, I think I misread it in the same way that Joe did, Steven. It was confusing to me that you're basically writing the steps from the point of view of, like, the server. And now that I understand that, I understand the steps a bit better...
… the… the concern I had is that, you know, step 3, you create an empty options data structure, um, and the if-needed thing threw me off, because you don't need it if somebody passes it in, and then it gets passed through. So it's just some of the wording was
Stephen Curran: Exactly. Yes...
Manu Sporny: was confusing. I think I'm fine with it now that I understand, like, it's written from the point of view of the server, and...
Stephen Curran: Yeah...
Manu Sporny: you know, if you don't get in options, you'll create an empty one, because they didn't give you anything, and then you pass it on. If you were given options, you'll just pass them through, uh, which is… which is fine...
… Yep, and I think you're right, the thing that matters is step 4, where it says, did URL instead of did, and
Stephen Curran: Yeah...
Manu Sporny: And that's the key difference, I think, between the one before and this one, or the one that matters that we're discussing today. The other thing I put myself on the queue for is, you know, I heard Marcus loud and clear. I think he thinks there's been a process issue...
… Uh, so we should do a call for consensus on poll 331 today. Um, what we could do is we could back it out, and then wait a week, and it's gonna be two weeks, and then do a call for consensus, and then, you know, decide, and then put it back in, or we could just
… Figure out if that was, um, uh, you know, what the, what the… If that… if that… if we, you know
… Don't have consensus, which I don't think we have, um, because, you know, Marcus' statement earlier, and then the repercussions of that. Um, so I, I'd suggest chairs, you've got to take, you know, process issues seriously, and you're gonna have to
… run, um, you know, a call for consensus on that item. Um… That's it
Otto Mora: Mm-hmm...
… Okay, Marcus?
Markus Sabadello: Yes, just to add to that 331, just to be clear, I actually really like that in some ways. I like the...
… organization of of handling strategies and and things like that. I just don't, or I just object to the fact that 3, 3, 1 already clearly leans into one one of these 2 options that we're
… And… still discussing here. Right? So it it talks about resolving Ddrls. And that that's what I I'm opposed to. But I'm I'm not opposed to the the general structure in 3, 3, 1
… With regard to these two options, I would really like to understand a bit more
… why the second option is better than the first. I know I've missed some of the calls, so I apologize if this is
… already been, uh, covered, and this is clear to everyone, but it's… it's not clear to me. I don't understand
… what's dangerous about the first option? Um, I feel like
… If we are worried about an attacker injecting dangerous options
… in the in the 1st option in in the 1st approach, then the the same attacker could just as well and check dangerous options or dangerous parameters in the in the second approach. So I don't
… that it doesn't really need it. It passes the potentially a path
… I don't understand that. I feel like the second approach is more dangerous because it has these things to the resolver. To the resolver, which it doesn't need, so there's additional… opportunity for attackers to inject something. So, I don't understand
… That argument, um
… Yeah, in addition to my concern to make these kinds of changes in… In the first place
Otto Mora: Mm-hmm. Uh, Joe?...
Joe Andrieu: Sure. So, Manu, unfortunately, your comments confused me even more...
… If… if… if we want to talk about what the client is doing. It's… I think
… That would be one set of steps. And I can and I want to speak to that. If we're talking about what the resolver is doing when it is called, that's another set of steps. And we could talk to that. But when I was reading it, I thought Stephen was trying to map this to what the client of resolver does when they have a DID URL from a VC. And what
do they do with it?
… And in that case, for me, I wouldn't even bother verifying the DID URL, and I would not create an empty data structure, because I don't need one. I'm just going to call the DID resolver. Um, and give it a date URL
Stephen Curran: So… It requires an options. That's why it's there. It has to have that. That's the interface...
Joe Andrieu: Right. My position is that that should be optional rather than forcing people to construct an empty one...
… Um, but let me also speak
Stephen Curran: So that opens another, that opens another can of worms. So, okay...
Joe Andrieu: Sure, but let me speak to Marx's concerns. I think anywhere we can reduce unnecessary processing, we will improve the security of the system. We will remove the bugs that might occur because the client. Isn't processing options, according to the spec, 100%...
… Manu described earlier that their their clients don't do that Their clients do not process all the options. So if the query parameters that need to go to the resolver change, then Manu's code is gonna be in in a problematic situation
… Um, all we're doing in that processing step on the client is we're taking what is already embedded in the URL, assuming there are no changes
… Um… The… And forcing the client to process it, and put it in a JSON object, and then send it to the server. It's the exact same information with an additional, I would argue, unnecessary transformational step. That transformational step is what I'm trying to get rid of
… On the resolver side, I think it's easy to ignore what you don't need. I think it's harder to, on the client side, to add what you don't know you need to add. That's the difference between these two approaches, is I'm trying to make it easy for the client to say, hey, I've got a DID URL
… Give me the DID document for it. I don't have any special requirements around version ID or version time. I don't know of any other options that I'm going to put in, just like I get a URL and I do a GET without adding any HTTP headers. If I do want to customize
… the resolution output, then I can add options, but I don't need to. And that's the simplicity I'm trying to get to
Otto Mora: Okay...
… Thank you, Joe, and Will
Will Abramson: it… there's no normative language there. I tried to be intentionally vague. I agree, it does reference… it does talk about dig URLs, maybe it...
… slightly lean towards DigiURLs, but it does not
… It doesn't define the inputs and outputs of any of the steps intentionally. And… Uh, yeah, I mean, I think that was a great description, but I just wanted to talk to 331 briefly. I mean, I'm happy to do a call for consensus, that's a great idea. I guess, you know, the reason that it got merged was so we could move forward to getting the PRs
into the other thing. Like, my sense of 331 is
… You know, the conversation today was intentionally decided, you know, set up to finalize this discussion, did URL versus did. I don't think 331 is implying in any way that we've made that decision. I think that's very clear
… To me. So, you know, in some ways, it's not a normative change, but… oh, I saw it anyway. That's why I thought we could just merge it and then get to concrete spec text around the steps and start moving the spec forward. Maybe I have… yeah
<manu> Agree with Will, but if we have a process objection, let's make it clear what the group wants.
Otto Mora: Yep...
Will Abramson: So that's all I'll say. I mean, I don't know what does a call for consensus look like. We want. Uh, proposal...
Otto Mora: Yes, um, I wanted to plus one what Will was saying, like, Marcus, like, the goal here was to have...
… Kind of the bigger, high-level
… structure of the algorithm, uh, figured out, and then go to the details where I think where… that is where
… the the differences of opinion have have emerged. But yeah, like we we weren't trying to
<Zakim> manu, you wanted to state why first option is dangerous (the client has less knowledge than the resolver to make decisions around parameters).
Otto Mora: Oh. let's say, overrule you or whatnot. We were just trying to have the high level structure, and then in in further prs get down to the more specific items. Let me see… Amanda was next
Manu Sporny: Uh, yeah, I'm sorry, I was trying to remember what to say. Um… Uh, it...
… Just to kind of underscore what Joe's saying, Marcus, you were asking for like, you know, what are the reasons the group, you know, is favoring one approach over the other. Plus one to what Joe said, when it comes to our implementations
… We don't want the client to do any kind of processing on the dead URL by default. Right. The the when it comes to like who what what part of the system just looking at kind of software architecture, what part of the system
… Has the best knowledge and is best positioned to make a decision about what parameters to use and which ones to include and which ones to not and all that kind of stuff. That is the resolver. That's the did resolver, you know, a server side component
… It is not the client library that's living in application space. Now there may be extra things that that client library does that it does have kind of specialization around, but we, Digital Bazaar, would much rather that logic go into the thing that's doing resolution
… Um, uh, because it has all kinds of other signals and information that it can use. Like, hey, I know what this DID is, and I know the version ID that's being used is a potential attack vector for this specific DID method, and so I am not going
… to utilize that when I resolve, or I'm going to throw an error, or I'm going to do all this other stuff. The client has no ability to gather that kind of data, right? And for those reasons, we do not want the client making these types of decisions on the client side, because it does not have the information that
… a resolver would have to make, you know, specialized decisions like this. So
… that is a play… that's different from Joe's reason, slightly, um, but it's another reason why we prefer the second option, right? Um, it is what most folks that use, like, HTTP
… you know, URLs, what they expect from their libraries. They just pass the opaque string in, and they get something back, and all the backend stuff, you know, does what it needs to do. Meaning, you know, the server uses whatever, you know, business-specific logic that it needs to use to
… to respond
… the, the, you know, I appreciate, Will, your and Otto's explanation of, like, what we're trying to do, I totally agree with it, but it doesn't matter, right? Like
… Marcus is asserting that there is a process violation that happened. We need to make it very clear whether or not it is. We do a proposal and a resolution proposal, you know, merge, you know, 331 or leave 331 merged. People weigh in on it on whether or not they believe that that was, you know, the right thing to do
Otto Mora: Okay...
Manu Sporny: And then you've got to make, you know, a consensus call and do a resolution. That's the only way to address, you know, Marcus's assertion that there's been a process violation. That's it...
Otto Mora: Uh, let me just here converse with, uh, Will on whether we can move forward to that, but, uh, yes, before, uh...
… I know that Marcus was on the queue, so go ahead, Marcus
Markus Sabadello: Hey, thanks for explaining, Manuel, how...
… how your implementation works and the reasons for that. I fully agree with that. I fully agree that the client should not have to have any knowledge about what parameters or options matter. I fully agree
… the resolver is… is the place where… where that should happen. Um, but I think there's nothing in… in this first approach which
… Which says that in the algorithm that we've had so far, it says take the, take the parameters and, pass them to the resolver
… as options. Steven said early on this call that
… if I cite him correctly, something like options are just a different way of passing parameters
… Which… which I agree with, and so I think there's nothing in the algorithm the way we've always had it that suggests that the client should somehow
… process or filter or decide anything about which parameters matter and which don't. So I cannot understand that explanation. I cannot understand
… chose, uh, chose comment either about transforming the option… options to a… to a JSON object. That's… that's not really in the… in the approach one or in the in the previous algorithm either
… That's it. Thank you
Otto Mora: Okay...
… Okay, um… I see Steven
… Then Manu, and then we're gonna go into the proposal conversation. But yeah, go ahead
Stephen Curran: Okay, I think we're close to getting somewhere here, so hope we can...
… Finalize. Um, I'll add from the experience we had this week, we did WebVH, and the, um
… problems with the resolver, the DID WebVH resolvers that were uncovered through the security check. It actually was all about verifying the DID
… And most of them, many of them were there. So if we could move this step out of as we're calling this client space and into
… the resolver, it is more likely to happen. Like, what we found was we have 5 implementations, and none of them were
… really checking the DID itself for validity in a reliable way and leaving itself open
… getting all clients to do that versus having this thing called a resolver, um, library that would do it. I think that's
… a better way to do it. It reduces that… the likely… it increases the likelihood it will happen inconsistently. So if you don't pass the DID URL to the resolver, you don't get the possibility of that. So I'm actually… I've… I've really been on the… you know, I'm
<Zakim> manu, you wanted to note you can't separate out options from the URL from client desires.
Stephen Curran: not really concerned either way about this, but I think that is an argument that pushes it towards this one versus this 1st option. That's it
Otto Mora: Mm-hmm...
… Bye now
Manu Sporny: Yeah. Um, Marcus, I wanted to respond to your, you know, the, the, you know, the ability to pass, uh, you know, take the parameters in, in, in approach number one, we take the parameters out of the URL and then we put it into a JSON object and we send it up...
… The other issue that that creates is that, at that point, we cannot tell the difference. We, meaning the server-side component of this thing, cannot tell the difference between parameters that existed in a DID URL that was potentially passed to the client
… and other things that the client… other options that the client wanted to provide that would override the URL, right? We… we co-mingle the information in a way that the resolver cannot tell the difference between, like, this came probably from the URL that the
… that the client had, and this other set of things came definitely from the client and were not in the URL. I think that is also, you know, an important kind of signal that the server-side component can use to figure out the best thing to do. Again, I think
… these resolvers can have massively complex decision logic based on certain types of did methods and known, you know, breaks in the space and and all that kind of stuff. And and when it's running that when it's running that those algorithms, it's it's important to be able to tell the difference. I'm like, these are client preferences. These came
from the
… original URL, and if we commingle those things, then it loses the ability to get those types of signals in and make the best decision, the best resolving decision. Again, that's an argument for
… The second option, which does let us determine the difference between, like, these definitely came from the client and are potentially overrides, and these, you know, are something the client got from some other system downstream
Otto Mora: Mm-hmm...
Manu Sporny: That's...
<Zakim> JoeAndrieu, you wanted to say how do query parameters get to the resolver if the full DID URL isn't passed?
Otto Mora: Yeah. Sorry, Marcus. Yeah, we're closing the queue for this one. But go ahead, Joe. Last last one, and then we go to the 3, 2, 1...
Joe Andrieu: Thanks. Plus one for the ability to tell the difference between overrides and what was in the base did URL. But Marcus, you ask where in the spec does it say that you must...
… uh, parse the query parameters and put them in the options. And I… I think it is… it is… it is clear when you look at the signature of Resolve that if I cannot send the folded URL
… then… if there are any options, any query parameters in the DID URL, I must put them in the options. If that DID URL has a version time
… Then I must parse it and put it in the options, or I am not going to have that applied to my system
… Um, and put them into options. So I think the spec makes it very clear that you must process those parameters
… That's it
<swcurran> +1 to Joe
w3c/did-resolution#331
Otto Mora: Uh-huh...
… Okay, thank you. All right, so for the next, let me just change the topic to PR331. And… let me emote
… a proposal
… So that's my proposal text, um
… I just wanted to make it simple, but is there any comments on the proposal first?
… Before we… Um
… Can we go ahead? Does somebody want to add some further context before we do the vote? Just vote on it, or
… Oh, sorry. How do I… how do I enable, uh
Joe Andrieu: Oh, sorry...
Otto Mora: the Kim just enabled queue, uh… Okay...
Will Abramson: Open...
Otto Mora: Take it open. Okay, there we go...
Joe Andrieu: Oh, thank you. Cool. Um...
… Uh, I think we might just need to change it because it was merged in, right? So
… I think we just need to reflect that we're talking about either accepting the merge or the inverse and, you know, reverting it
Otto Mora: Mm-hmm...
… Okay, that makes sense, we can adjust our will
Will Abramson: Uh, yeah, that makes sense to me, too. Uh...
… I mean, I guess, like, one of my questions is maybe there's some language tweaking that we could do, like, we could just remove didURL from that completely, and I think that would satisfy Marcus
… Maybe I should have done that. Um
… I mean, I was… but the other thing I wanted to say is this fall, I really want us to have a final decision on DID versus DID URL, so I'm hoping after this proposal, we are going to have a proposal to vote. On the topic we've been discussing the past two weeks
Otto Mora: Yep...
… Okay. Thank you
Will Abramson: Welcome...
Otto Mora: Uh, Marcus?...
Markus Sabadello: Yeah. So again, I I think I I would agree to 3, 3, one. If it really separated the the topic of Ddrl versus the admit, maybe that would be the the easiest way forward to just remove the 1 1 or 2...
<Zakim> manu, you wanted to ask Markus if he'd object if we took the term "DID URL" out of that PR?
Markus Sabadello: phrases that say something like, prepare the DDRL for resolution, or… A lot of things like that
Otto Mora: Mano? Mm-hmm...
Manu Sporny: Yeah, I was just gonna ask Marcus that. So what if we, instead the proposal is remove the term did URL from the merge text from PR 331. I would imagine we should be able to achieve consensus. Undoing that, and then we move on to the DID URL versus DID input to DID resolution. Does that feel like a? Password...
Will Abramson: uh...
… Yeah, I promised Colin we could just caveat that, like, I think we don't want to remove the term DigiURL from the PR entirely. I think that, for me, looking at this text, maybe Marcus can reply, but it's only the first step, 5.1.1, prepare for resolution. And instead, we could say the first step is dereferencing a DigiURL
… of dereferencing a DigiURL is to prepare for resolution. This involves validating the DigiURL syntax, selecting the appropriate DigiResolver, and preparing to execute a resolution request
Otto Mora: Yes...
… Let's see
… Marcus?
Will Abramson: And just not reference the inputs at all...
Markus Sabadello: Both, I think it would be fine. I think that would be fine. There was a second place somewhere in the in the language. I, I don't remember now, but there were two, two sentences that there was another one. So if we change them...
… Personally, I would also prefer to still have the dereference function there. You know, that was another topic that has been discussed, the abstract function. I don't think that should be removed
… But, I'd be willing to, to, to live with that for now and maybe add it back later. So, so yeah, if we, if we update, if we change the language, it doesn't imply that you pass the TTRL to resolution then. Then I'd be fine with that
Otto Mora: Okay, so...
Will Abramson: Uh, yeah, I'll just type something up, and let's see...
Otto Mora: Okay. Will, I don't know, do we run a proposal with specifically noting...
Will Abramson: I think...
… What about this?
… It's perpetual, obviously
… And Marcus, there are two references to the URL in that step, which I think is what you're talking about
Markus Sabadello: Uh… yeah, it was...
… Okay. I had it in that
… In that in that signal group, it says prepare the DDRN for resolution
… And then it says preparing the DTRL and any accompanying DT resolution options for a resolution request. These two parts
Will Abramson: Mm-hmm...
… Yeah, so we'd remove both of those
<markus_sabadello> - "prepare the DID URL for resolution"
<markus_sabadello> - "preparing the DID URL and any accompanying DID Resolution Options for a resolution request"
Otto Mora: Okay...
… Ah, okay. Yeah, one second
… Uh, yes
Joe Andrieu: Is that a yes to me, Otto? Sorry...
Otto Mora: Uh, Joe, go ahead, yeah, sorry, go ahead. Uh, I see...
Joe Andrieu: Yeah, I think the language as it is currently should be okay with what you want, Marcus...
… Um, the… the client who's calling Resolve is starting with a DID URL
… And even if we kept a bear did as the parameter in the resolve function
… The client still is processing the preparing the DID URL to turn it into an appropriate DID
… So I think the language that Will just spoke to is still aligned with how you would like the algorithm to go
Otto Mora: Well...
<JoeAndrieu> +1
Will Abramson: Yeah, I mean, that was my perspective too, but I think, you know, like, if this is gonna solve the problem, I'm happy to remove DigURL from it, and we can always add it back in, right, when we make this decision, which… I'm running out of time. I just want to make the decision to move forward, so...
Otto Mora: Mm-hmm...
Will Abramson: Is everyone okay with the text that I'm emoted? Update PR331 to remove reference to dig URL. I'm stuck. 5.1...
… Uh, although there is one big URL that we want to keep
<TallTed> I hope someone has the time to spare to review and polish these robotic IRClogs/minutes, as they'll be indecipherable to many as they stand (e.g., "prepare the DDRN", "preparing the DTRL")
Otto Mora: Mm-hmm...
Will Abramson: Okay...
<ottomorac> Proposal: Update PR331 to remove reference to DID URL from Step 5.1.1 prepare for resolution
Otto Mora: Uh, yeah, okay, so I'll just propose all...
<manu> +1
<Wip> +1
<ottomorac> transcriber-bot, pause
<JoeAndrieu> +1
<swcurran> +1
<smccown> +1
<markus_sabadello> 0 don't like how it removes the dereference() abstract function, but wouldn't object anymore if the relevant updates are made
<TallTed> +1
<ottomorac> +1
RESOLUTION: PR331 to remove reference to DID URL from Step 5.1.1 prepare for resolution
<ottomorac> transcriber-bot, resume
Otto Mora: Uh, yes, Will...
Will Abramson: Yeah, I just wanted to speak to Marcus's zero just briefly that, you know, I mean, I thought we had made a decision about that, but either way, like, I wasn't intending to make any of those decisions in this PR. This really is about, like, taking a step in the direction towards resolving this did URL be referencing...
… debate in a way that allows us to move forward on the things that we have made consensus on and leave space for us to still have decisions about specific areas that we don't have consensus on like did versus did URL and like potentially this dereference abstract, right? Like I don't have any
… definition or, like, introduction to this section. All I'm trying to do is the scaffold that we can then build into. That's what I was trying to do
<swcurran> YES!!
Will Abramson: So, um, that's all. Uh, I see we've got 6 minutes left. Do we think we are able to run a proposal about DID versus DID URL today? Like, would anyone be opposed to us doing that? Do you think there's more conversation that we should be having?
Otto Mora: Uh, Marcus, is that the queue?...
Markus Sabadello: I really don't think this has been sufficiently discussed. I think, everybody's trying to explain it patiently, but I also feel like, for example, Manu's second explanation, I think, was very different from the from the first explanation...
… of why this change should be made, and I have a lot of concerns with that. Some of them are in GitHub comments that haven't really been considered yet, so I think it's really not ready to
… to make this decision
Otto Mora: Mm-hmm...
… Uh, I don't
Manu Sporny: Uh, they were two different reasons, Marcus. They were not meant to go together, um...
… I don't know what else to say. And we have talked this thing to death. Like, seriously, it's been going on for months. We need to make a decision and move on. Like, we're so far out of time. Like, we're outside of our charter timeframe, right? I mean, we had to get an extension to just keep working on it
… No, let's make a decision and move on. We've been talking about this for a long time, Marcus. You will get another opportunity to object after we clean up the rest of the algorithms before we go into CR
… Um, we have, you know, multiple more PRs to go. Let's make a decision so that we can at least start putting some concrete text into the… into the spec
… That's it
Otto Mora: Uh, Ted...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Just quickly, it's totally legit, Marcus, for you to open an issue which we can hold open until...
… things conclude, or things at least move further, and we come cycle around back to that issue and see how it fits with the evolved text. And if you still see a major issue, then hopefully it'll be easier for you to make clear. what that major issue is, and then for us to address it. That's it
Otto Mora: Yeah, I mean...
… I guess I'll
<manu> +1 to what TallTed said -- there's still time for Markus to understand the arguments for this path.
Otto Mora: re-emphasize and say, yeah, like, uh, we will have one last conversation around this first thing on the next meeting, uh, of the larger group, and then
… Uh, you know, formal… formal call, if that does make sense. we'll just take a vote at that point. I really, yeah, I'm sensitive to the fact that we're at the end of the call, so it feels like we should allow Marcus to, in the next call, detail his arguments briefly, and also the arguments for and the other side, and then we just take a vote
early on in the next. Let's see any other comments
… I think
Will Abramson: However… Yeah, I guess I'm on the queue. I mean, I wanted to say, too, like, I agree with Otto. I do want to make this call this week, and I'm sorry that we didn't quite have time for it, but it does feel rushed to do it in the last few minutes of the call...
… we do need to make a decision on this, and I do not want this to take the whole call next week. So, um
… I guess on Wednesday, we can… I mean, really, we shouldn't be running this on Wednesday
… Okay, so maybe on Thursday, the first thing, you know, the first thing on the agenda, and
Manu Sporny: We're not going to be here...
Joe Andrieu: Well… yeah...
Will Abramson: Oh, yeah, of course...
Joe Andrieu: Sorry, Will...
Will Abramson: Got it...
… Yeah
Otto Mora: Mmhm...
Manu Sporny: I'm very frustrated by all of this, just to get it on the record. It's super frustrating. We're not going to make this decision for another two weeks again, you know...
Will Abramson: But it is 2 weeks out...
Otto Mora: Yep. But, yeah. Yeah, I think it should be on the Thursday call, just to enable larger...
… It is what it is. I agree. Yeah. Um
… Alright, so yeah, we will run it on the first call, we will time-bound it
… Um, so that it doesn't, uh, you know, take over the whole call, and we'll take a vote at the end of the… of the time bound. Bye
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/