14:44:55 RRSAgent has joined #did 14:44:59 logging to https://www.w3.org/2026/07/02-did-irc 14:45:13 rrsagent, make logs public 14:45:29 Meeting: Decentralized Identifier Working Group 14:45:43 Chair: ottomorac 14:46:11 ottomorac has changed the topic to: DID WG Agenda 2026-07-02 https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0028.html 14:46:20 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jun/0028.html 14:46:20 clear agenda 14:46:20 agenda+ Agenda Review, Introductions (5 min) 14:46:20 agenda+ Proposal regarding DID Resolution CR (10 min) 14:46:20 agenda+ Proposal regarding DID Resolution inputs (10 min) 14:46:20 agenda+ Issue 341: Improve Hedgy Text \[1\] (10 min) 14:46:23 agenda+ DID Resolution Issue Processing (10 min) 14:46:25 agenda+ Next Time (5 min) 14:46:42 previous meeting: https://www.w3.org/2026/07/01-did-minutes.html 14:47:13 next meeting: https://www.w3.org/2026/07/08-did-minutes.html 14:51:58 transcriber-bot has joined #did 14:55:16 https://github.com/w3c/did-resolution/pull/345 15:02:12 swcurran has joined #did 15:02:14 present+ 15:03:26 present+ 15:04:25 markus_sabadello has joined #did 15:04:30 present+ 15:04:45 zakim, next item 15:04:45 agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot] 15:04:59 transcriber-bot, connect 15:05:00 scribe+ 15:05:01 Wip has joined #did 15:05:10 Otto Mora: So, yeah, for today, we have, um... 15:05:15 ... a proposal that we're gonna run regarding the debt resolution 15:05:17 present+ 15:05:18 present+ 15:05:27 ... Uh, spec and the overall plan 15:05:31 ... Then we have some additional conversation regarding the did resolution inputs which yesterday we had a a really good useful conversation that was led by Joe explaining 15:05:37 ... Some of the potential, uh, security issues, and then walking us through some options 15:06:03 ... to to address that. Then we have another issue which is related to the tack resolution, which is issue 3, 4, one. that I opened a pull request for, so 15:06:07 ... we can look at that one. And then, uh, just generally talking about debt resolution issue processing, so that 15:06:12 ... We can look at whatever else is needed to try to achieve candidate rec status 15:06:15 zakim, next item 15:06:15 agendum 2 -- Proposal regarding DID Resolution CR (10 min) -- taken up [from agendabot] 15:06:21 ... Anything else that folks wanna add, uh, to the agenda, or any… Province. Okay. Okay, so 15:06:33 ... Last week, we had a conversation that was facilitated by Will. There was this presentation, which I'm going to paste in the chat 15:06:35 presentation from Will: https://docs.google.com/presentation/d/1aXwUMyvv37Iz0VfTl2jMlbqeJFWPIPgoYh0o5HAGbpM/edit?slide=id.p#slide=id.p 15:06:42 manu has joined #did 15:06:46 present+ 15:06:49 ... And that presentation made it clear that we have limited time. We need to really try to achieve something. By the time our, uh 15:07:10 ... Charter is set to end. And so kind of the output of that whole conversation is we should have the working group focus on preparing a debt resolution spec 15:07:22 ... that solely addresses did resolution did resolution algorithm and have the goal of reaching candidate rec status, giving the current better timeline. Right? So the proposal that we want to try to run today is the following, let me 1st emote it. uh 15:07:30 ... Uh, so it says, focus on moving date resolution to CR with date URL dereferencing marked at risk 15:07:41 Wip has joined #did 15:07:47 ... Uh, and we, we kind of did address this, uh, yesterday, uh, kind of what that means. Uh, there was general agreement in the special topic call yesterday about this. Uh, however, I, I now see that we do have, uh, Manu in the room, so 15:07:53 ... If Manu, if you have any comments, or if anybody else has any comments before we run the proposal, this would be the time to… to do that 15:07:56 Manu Sporny: No comments. I defer to the group... 15:08:01 Otto Mora: Okay, anybody else?... 15:08:03 transcriber-bot, pause 15:08:03 scribe- 15:08:06 PROPOSAL: Focus on moving did-resolution to CR, with DID URL Deferencing marked "At Risk" 15:08:11 +1 15:08:13 +1 15:08:14 dmitriz has joined #did 15:08:14 +1 15:08:15 +1 15:08:22 JoeAndrieu has joined #did 15:08:29 +0.5 15:08:43 +1 15:08:43 +0 15:08:44 JennieM has joined #did 15:08:47 +1 15:08:54 present+ 15:08:56 +1 15:08:58 present+ 15:09:04 present+ 15:09:06 present+ 15:09:07 present+ 15:09:31 smccown has joined #did 15:09:42 present+ 15:10:15 pdl-asu has joined #did 15:10:20 present+ 15:10:23 +1 15:10:27 transcriber-bot, resume 15:10:27 scribe+ 15:10:37 Otto Mora: Okay, perfect. Okay, so with that, yeah, we passed the resolution. So... 15:10:38 resolved: Focus on moving did-resolution to CR, with DID URL Deferencing marked "At Risk" 15:10:42 Phillip Long (GU, T3, ASU): Yes... 15:10:49 Otto Mora: Resolved. We do agree to. Focus on on that. So… Uh, yeah, great. So... 15:10:52 ... Now, now that we, we have that 15:10:57 zakim, next item 15:10:57 agendum 3 -- Proposal regarding DID Resolution inputs (10 min) -- taken up [from agendabot] 15:10:59 ... and… Let's move to the next topic 15:11:10 ... Which is, yes, regarding the DID resolution inputs and the conversation that we had yesterday 15:11:15 presentation: https://docs.google.com/presentation/d/1NWvreIqAFj-ro6oi-qJYWbcVGoLWojmT/edit?slide=id.p9#slide=id.p9 15:11:18 ... During yesterday's call, we had this presentation. I'll share the link of it here as well in the chat 15:11:31 ... And in that presentation we discussed a couple of options regarding. how to address the 15:11:39 ... confused deputy attack that was illustrated by Joe, and we we kind of had. um 15:11:51 options on slide 9 15:11:53 ... you know, 4 options, one of them, including, you know. resolving a did with the current spec. Another one 15:12:02 ... with the options, uh, override, uh, and then, uh, options 3, which is resolve a deal with options and no promotions, and having the client, uh, select those, uh 15:12:22 ... so no promotion without explicit choice, and then resolving the did with some options and some parameters, uh, so completely separating the two, and, uh, there would be an options override as well. Uh, we… Ah. As a group, uh… There was a consensus that we 15:12:44 Wip has joined #did 15:12:45 ... Option one and two wouldn't be appropriate, but that option three and four would be… You know, or a variation of them would be the right, perhaps the right approach. So that was that was that conversation. Joe, you want to go ahead? Yeah 15:12:49 ... You're on mute 15:12:52 I think we gravitated at the end to option 4 15:12:53 ... And 15:12:56 Joe Andrieu: Sorry... 15:13:00 Otto Mora: Go ahead, yeah... 15:13:04 Joe Andrieu: I, uh, I just wanted to, uh, share… there were 2 additional options that were discussed... 15:13:14 I would prefer option 3 15:13:22 ... Um, one of them I forgot, and I think it was maybe just because it didn't… I'm not sure it addressed the root problems. If you remember it, Marcus, it was one of the ones you recommended, just another way to think about it. And then PA had also suggested that number 4, we could still have a separate bucket 15:13:37 ... But don't promote by default, right? So the real difference with number three is whether or not did query parameters get promoted indiscriminately or not, which seems to be one of the roots of the… Confused deputy risk 15:13:41 ... So there is that fifth option that we talked about 15:13:44 Otto Mora: Okay, so option five would be... 15:13:50 ... Option 4 with no promotion by default. Okay 15:13:53 Joe Andrieu: That's right... 15:13:58 Otto Mora: And I see that, uh, Banu had commented, uh… the... 15:14:04 ... Maybe, like, option 4 a little more… Um 15:14:13 ... Steven, I know he had also voiced both in the signal chat and here that he likes option 3 a little more. Um 15:14:14 q+ 15:14:22 ... I don't know, do we want to dwell maybe into that, Steven? maybe you're… Your preference for option three. Yep 15:14:27 Stephen Curran: Sure. Sure, um, I think... 15:14:33 ... The options are all quite similar, um, and as a result 15:14:37 ... By selecting option 3, we really 15:14:50 ... stick to the shape of the API, the call, to be the same as. It was previously, if we go to 4. We still have the same 15:14:57 q+ 15:15:01 ... handling. But we've added this new parameter that doesn't exist. So our backwards compatibility is actually even worse than. Um 15:15:10 ... switching to DID URL versus DID. So, I… I think that's quite a negative on… on 4. The 15:15:11 q+ 15:15:14 ... The intention is the same in 3 and 4 15:15:25 ... Um, the… the difference is the literal calls, and by making the calls different. Um, we get 15:15:35 ... Uh, we get to a worse position, um, relative to the current state of implementations 15:15:38 ... And so that's why I would prefer three 15:15:41 Otto Mora: Yes. Okay... 15:15:44 Stephen Curran: Basically, all the things that Marcus is, or some of the things that Marcus was, Marcus was ideally for... 15:15:47 ack manu 15:15:47 Otto Mora: Mm-hmm... 15:15:53 ... Okay, thank you. Manu? 15:16:15 Manu Sporny: Yeah, I didn't take option four as a backwards breaking change. Um, clearly I'm missing some detail. Um, I thought it would be a backwards supporting change, um, but the parameters make it clear that, and I don't know if it's, what is it, the client or the, um. Someone's passing those on. Um... 15:16:35 ... I'm concerned about the no promotion without explicit choice thing, because it may be that the client is not smart enough to understand what to do, and they're deferring that to the resolver, and I think we should leave that open. I'm fine with, like, a should not explicit, you know, should not promote without explicit choice 15:16:44 ... Uh, for option 4, uh, if that helps. Uh, but I'm confused, uh, Steven, by what you said, because I was not reading option 4 as the… as the way you presented it. Um… That's it 15:16:49 Stephen Curran: Well, it seems to me that today. Um... 15:16:57 ... Before the proposal that was accepted a week and a half ago or so. the 15:17:03 ... Call was resolved, did, and options. And now we would be 15:17:07 ... If we changed it to DID URL and options 15:17:30 ... Um, this change proposes that the change be resolved did options parameters, where parameters are not even… it's not clear exactly. Presumably, that would look like options. Um, being a JSON object. Um, but it definitely changes the API call 15:17:37 q+ 15:17:46 ... um, from an… you know, an HTTP binding, the… the way the goal was, it is in the… in… in the current merged spec, um, with DID and options. And so now we've got this third 15:17:57 ... non-standard way of doing it, so that's why I would prefer. Option 3. With the guidance being 15:18:00 ... You know, make sure when you pass parameters 15:18:07 ... you make explicit choices on it because you could be doing bad things 15:18:10 Otto Mora: Mm-hmm... 15:18:17 ack markus_sabadello 15:18:17 Stephen Curran: Does that make sense, Manny?... 15:18:18 Manu Sporny: I understand what you're saying. I'm putting myself on the queue. Thanks... 15:18:21 Stephen Curran: Oh... 15:18:24 Otto Mora: Thanks. Yeah. Yeah, I think it's worth letting Marcus also chime in here... 15:18:29 Stephen Curran: Okay. Got it... 15:18:32 Otto Mora: chime in his view, and then we'll come back to you after Will has also intervened. So go ahead, Marcus... 15:18:37 Stephen Curran: That's all... 15:18:53 Markus Sabadello: Yeah, I'm totally with Steven on this. I also like option 3. One argument that I've heard several times in this whole discussion was that supposedly... 15:19:01 ... the client needs to pass the entire TTRL and all the options to the resolver, because only the resolver knows how to properly process them, and the client isn't smart enough and doesn't know what to do with those. With those inputs, but 15:19:11 ... But I think that's not true. I think the client does have some knowledge about the use case 15:19:14 q+ 15:19:29 ... specific applications that the information that the resolver doesn't have. For example, in Joe's presentation yesterday. That was that was really helpful, because Joe made the point, for example, that if you took it off, then 15:19:42 ... Then you would never want to allow a version time in the DD URL to override or to become an option. You always want to use the latest version of the DDocument. You don't want a version time 15:19:48 q- 15:19:54 ... to come from a TTRL parameter 15:20:17 ack Wip 15:20:17 ... But, uh, there are other use cases where I think it's totally fine to have a version time as a parameter in a DTURL, if you want to… access historical service endpoints and things like that. So I think there's some 15:20:21 ... knowledge that the client has about what to do with parameters that the resolver doesn't have. And so I would also be for —. for option three 15:20:24 Otto Mora: Uh, well... 15:20:39 Will: Yeah, um, a couple of things. First, Steven, I don't think the backwards compatibility thing is such an issue. I think Joe did mention that that parameters bucket could just go inside the options... 15:20:58 ... object, right? So, like, we can still have the same API call and do option 4. But for me, I think the difference between option 3 and option 4 is primarily around, like, do we… like, in option 3, we are overwriting the parameters, right? Like, the 15:21:06 ... The client is deciding 15:21:10 ... which… which parameters from the DID URL to promote, and which ones to overwrite, right? There's only one set of each… of each, like, option that would go to the, uh, resolver. In option 4 15:21:20 ... like, both the client options and the didURL parameters are passed to the resolver, and then the resolver is, I guess, making some choice. Uh 15:21:29 ... And then there, I guess there is also this question about whether the client is making a decision about which parameters to put in that bucket 15:21:43 ... are not. I think option 4, as it currently stands, is the client puts all of the parameters in the bucket, or… and then there's option 5, is the client intelligently chooses which ones it understands to send across to the resolver 15:21:48 q? 15:21:51 ... But I think that is the question, right? Like, which… which… is it the client or the resolver who is best placed to make a decision about how to use these, uh, how to combine these things? 15:21:52 ack manu 15:21:52 Otto Mora: Mm-hmm... 15:21:54 Will: Thanks... 15:21:57 Otto Mora: Manu?... 15:22:05 Manu Sporny: Yeah, I mean, plus one, I do think that's the… the question, um, and I am concerned that we're gonna force... 15:22:24 ... uh, the decision one way or the other based on a very large set of use cases in front of us, right? So… so we don't know that option 3 is going to work well for all use cases, whereas option 4 is flexible enough to work for all use cases 15:22:39 q+ to say the problem is the bad use cases we don't want to enable 15:22:45 ... That said, Steven, the reason I said, you know, I get what you're saying, but I don't think there's a backwards compatibility issue, one, because of what Will said, and two, because you can make parameters nullable or make it an empty object 15:22:53 ... keep backwards compatibility. It's an optional thing that you can pass in, you don't have to do it. Uh, so I… I don't… I'd really like to take the whole backwards compatibility argument off the table. I don't think it's an issue. Um 15:23:09 ... Uh, and as long as we do not limit implementers from having parameters or overrides, then I'm fine with, you know, uh, three, uh, because I 15:23:29 ... think we are going to provide more flexibility in our resolution thing. Like, you know, I hear what people are saying, but, like, I do not buy the argument that that is going to work for every single… doing explicit choice is going to work for every single use case. But as long as we're not going to block implementers from 15:23:43 ... uh, providing more options, which I don't think we can do. I think the current, you know, API says you can put as many options in there as you want, and they can be resolver-specific. Um, if we do that, then I'm, you know, I don't think there's much of a difference between option 3 15:23:44 Otto Mora: Mm-hmm... 15:23:46 q? 15:23:47 Manu Sporny: And option four. Um, yeah... 15:23:50 ack JoeAndrieu 15:23:50 JoeAndrieu, you wanted to say the problem is the bad use cases we don't want to enable 15:23:53 Otto Mora: uh… Joe?... 15:24:11 Joe Andrieu: Um, yeah, I want to push back against two things you just said, Manu. One is, I think we don't want to enable all the use cases. Um, and we definitely are not. Like, the BTCR2 has a use case where it is very nice to be able to put a URL. parameter, um, for sidecar data... 15:24:28 ... But the problem is we know of bad use cases that will be enabled, and this is the whole point of the confused deputy problem. It's not that people can't configure their software so that they avoid confused deputy 15:24:33 q+ too meta "all the use cases" vs. "bad use cases" vs. "good use cases" 15:24:38 q+ to note too meta "all the use cases" vs. "bad use cases" vs. "good use cases" 15:24:48 ... It's that if you have a software architecture that makes Confused Deputy a common problem, then you probably want to think about changing the architecture. So, uh, I want to say we definitely don't want to support all use cases, and that's the balance. Like, are the use cases that we miss, um, worth the trade-off to say, hey, uh, this 15:24:54 ... this whole architecture is fundamentally more insecure if we don't lock down this request pattern. Um 15:24:59 ... The other thing is, I do think this, the backwards compatibility matters right now 15:25:12 ... The resolvers who are using the specification as designed will not be checking for an options.parameters or for some other set of parameters in those options 15:25:28 ... Um, and so there will be no visibility into the query parameters separate from the options, which reduces just to number 3 in any case. Um, because they, the, the, the caller, the client to the resolution will have to promote whatever parameters they care about in the options 15:25:32 ack manu 15:25:32 manu, you wanted to note too meta "all the use cases" vs. "bad use cases" vs. "good use cases" 15:25:34 ... And then we're just back to number three. So I think four does have backwards compatibility problems 15:25:39 Otto Mora: Okay. Thank you, Joe. Manu?... 15:25:59 Wip has joined #did 15:26:01 Manu Sporny: Yeah, still disagree that it's got backwards compatibility problems. I think it has implementation implications that are concerning, but again, we should not care about what's currently deployed in a way that forces us to make bad design decisions on what the API should be... 15:26:07 Q 15:26:12 q+ 15:26:17 ... But all that said, I think what I'm concerned about is this conversation is starting to become a little meta, like all use cases versus bad use cases versus good use cases. I think we can spend the rest of the call in 10 more calls 15:26:36 ... talking about the potential for all the use cases. I'm convinced that, you know, from what I've heard, as long as we don't make it, you know, illegal for people to add resolver-specific options, which I don't think we're gonna do, then I'm fine with 3. I don't know if there are any holdouts. Um, and folks that, you know, um 15:26:39 ... want something 15:26:51 ... other than 3, as long as it's not a must, like, I think we would take a pretty big issue with saying, like, you must not promote things that, uh, you know, you, you, uh 15:27:11 ... don't understand, because I think even that, you know, could be game. I think should not, you know, promote things you don't understand is where we want to be. And I think we should depend on implementers to make, you know, decisions around the security of their. resolvers based on their use cases 15:27:14 ... That's it 15:27:36 ... I mean, sorry, plus one to not supporting bad use cases. Like, that's not the argument, though, right? Like, I'm not saying, hey, we should totally support bad use cases. No, we don't want to do that. But there's some use cases where I think there's disagreement on whether or not it's a legitimate use case or not, and I want to make sure that 15:27:36 implementers 15:27:37 q+ 15:27:41 ... have the ability to make the choice rather than the spec being overbearing on kind of, you know, the corners of the ecosystem 15:27:52 Otto Mora: Okay. So that was should not promote without sorry. I know I just wanted to capture. without, uh... 15:27:57 Manu Sporny: No, understanding what the parameter does... 15:28:01 ack Wip 15:28:01 Otto Mora: Understanding the, okay, the, yeah, bunch of parameter dots. Yep... 15:28:04 ... Thank you. Just wanted to note that. Okay, uh, Will? 15:28:24 Will: Yeah, I mean, I really just wanted to get, you know, sense from the group. I'm hoping that the group can today make a decision about this. I'm hoping that we can pass a resolution to, uh… you know, we passed a resolution to change the DID URL. We definitely want to pass a resolution that says we actually don't want to do that resolution 15:28:25 anymore... 15:28:29 q+ 15:28:37 q- 15:28:43 ... And I'm hoping that by the end of this call, we can get to a direction where someone says, yes, I'll go and implement that change, because this is the last major thing that is blocking, like, the resolution algorithm from being moved… going to CR. So, it sounds like, to me, everybody 15:28:54 +1 15:28:56 ... is broadly happy with option 3, so I'd love to hear it if people are like, no, please don't do option 3, like, I hate that option. And then secondly, like, is managed… should not text acceptable to folks? Because if it is, then I feel like we have a direction, and we should… Move forward, though 15:28:59 Otto Mora: Okay, sure... 15:29:00 ack JoeAndrieu 15:29:11 Joe Andrieu: Yeah. I think I think, we are converging on three, so that's good. I don't like the should language... 15:29:11 q+ 15:29:22 ... Because I don't know who gets to exercise the should in your argument, Manu. The did URL author is not the right party, in my opinion, to make the decision 15:29:33 Phillip Long (GU, T3, ASU): Wow... 15:29:39 Joe Andrieu: Um, but any client who has the business logic to understand what they're doing with this DID URL, if they're doing a real-time interactive authentication, or if they're doing an audit on a historical authentication, or if they're checking the proof on a VC at a particular point in time... 15:29:55 ... The clients can always put whatever options they want in the options argument. So if they understand the business situation, then they can do whatever they want. What they should not do, in my opinion, and I think from a security standpoint, I think we're just… watering down the guidance to say that it should instead of must 15:30:12 ... Because the client is going to be the one who needs to enforce those rules. And if we make it that there is no must requirement, then many client implementers are just going to say, we're just going to promote everything because 15:30:16 ... We don't wanna do the thinking about it. And I think we need them to do the thinking about it 15:30:17 q? 15:30:19 ack manu 15:30:21 Otto Mora: Manuel?... 15:30:26 Manu Sporny: Yeah, I mean, I understand what you're saying, Joe... 15:30:33 q+ 15:30:38 ... the… the… I think the issue is with the definition of the word understand. What does it mean to understand a parameter? Like, can I string match against it and say, yep 15:30:55 ... go ahead and promote it, right? Or do I need to do a deep vetting about the string value that goes along with the parameter and deeply understand the path structure or that kind of stuff to promote it? It's that kind of stuff where I'm kind of like 15:31:12 ... should versus must, right? Because it's a judgment call. I'm not saying the did URL author… the should language does not impact… does not apply to the did URL author. It's specifically about the client. Um, and I think we can put plenty of warning language in here. Like, it's not… it's not like 15:31:21 ... you know, did, uh, uh, uh, did Resolver implementers are gonna look at this and all the warnings that we provide and the stuff in the threat model, and they're gonna basically be like 15:31:30 ... I'm going to just willy nilly pass stuff along, right? But I think Must is going too far 15:31:38 ... And, you know, if we put a must in there, you know, we will interpret that in a way that works for our use cases, which is probably not 15:31:44 ... where, you know, I'm guessing you probably wouldn't agree with that interpretation, Joe, but… Uh, yeah 15:31:52 Wip has joined #did 15:32:06 Joe Andrieu: Yeah, if I could just jump in. I agree, I'm not gonna block over this either, like, I just… we have a difference of… of judgment around it, so... 15:32:09 Manu Sporny: I just think, you know, should is as far as we should go with this. And I won't, you know, I won't block it, because I know implementers are gonna just ignore it if we make it too constrained... 15:32:10 ... That's it 15:32:13 Joe Andrieu: But I think whatever the group goes with, I could support. I think should is enough. I'd prefer must... 15:32:14 ack Pchampin 15:32:23 Otto Mora: Okay, so we could maybe just run a poll that should versus maybe try to see who supports it more. But I see that Pierre wants to... 15:32:47 Pierre-Antoine Champin: No, very briefly to Joe's point about should, my reading of should is not do whatever you want, right? It's not necessarily that it's optional. For me, a should means you do that unless you have a very good reason not to. And... 15:32:52 ... Uh, and the very good reason not to could be documented, as Manu suggested, in, in, in big warnings, uh, in front of this text. So, just my, my two cents on this 15:33:01 SHOULD == "do this unless you have a very good reason not to *and* you fully understand the implications of doing otherwise" 15:33:02 Otto Mora: Okay, so... 15:33:06 ... How do we run this? I guess people in the chat that support the chute type a plus one 15:33:10 +1 15:33:10 +1 15:33:11 +1 for slhould 15:33:14 +1 15:33:14 +1 15:33:15 ... Interesting. That's what I'm saying 15:33:16 +1 for should 15:33:16 +1 15:33:17 -1 15:33:26 q+ 15:33:27 ... Yep, okay. Okay, so yeah, that 15:33:30 ... That's pretty much it, but I guess, um 15:33:34 ... Joe, you indicated that for now you're fine with the 15:33:38 Joe Andrieu: Yeah, I didn't mean blocking with that minus one. I just… I do prefer must... 15:33:40 Otto Mora: But the way they… Okay. Yeah, yeah. Let's… let's... 15:33:43 Joe Andrieu: Yeah, I can support this. I would accept that this is consensus... 15:33:48 Otto Mora: Perfect. Thank you. All right, cool. So yeah, I think then... 15:33:53 ... Do we run a proposal now, Will? Yeah. Yep, yep 15:34:00 q+ 15:34:01 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Just just just a small thing. One of these usual arguments against should is that... 15:34:07 ... Quote unquote. It won't be tested, or quote unquote 15:34:13 ... we can't write a test for it, or quote-unquote, people won't take that as a thing they have to put into the thing. So I want to be really clear 15:34:18 ack MacTed 15:34:38 ... that should is almost a must, and anything that is testable as a must is equally testable as a should, and it should get to documentation of 15:34:52 ... what its test results are. I don't think that's being an issue right now, but I just want to be clear that that's how it should be thought about. Should is really close to a must, and it should be treated as just as testable for both 15:34:52 ... our testing, which is to make sure that implementation is possible, and for later testing as to what features somebody supports. That's it 15:34:52 ack Wip 15:35:00 Otto Mora: Yeah, yeah, absolutely. Have to be testable. Will?... 15:35:04 Phillip Long (GU, T3, ASU): Sure... 15:35:17 +1 for clear statements about should is do it unless you have an explicit reason it can't be done in your context 15:35:17 Will: Yeah, great. I mean, I think this is great. I think we should run a proposal. I don't even know if we need to get to the finer details in the proposal. I think, really, this proposal is just to document that we are ignoring the previous proposal that we passed, right? Like, so… ah... 15:35:20 Otto Mora: Mm-hmm... 15:35:33 Will: like, some proposal that captures option 3, uh, as the direction we want to take. I don't have… I'm not on my computer, so I can't draft any text for that, but we should run that, we should pass it, and then I would like someone to say, yeah, I'm gonna… Action map would be great... 15:35:41 Otto Mora: Okay, we'll use Resolve. Okay, deed options... 15:35:47 ... Hey, maybe with, um… No promotions 15:36:00 ... Uh… And… No promotion without explicit choice 15:36:13 ... Language will be included 15:36:21 ... To clarify… Yes 15:36:24 ... They need to understand 15:36:32 ... what parameters to… How's that sound? Any comments on that? 15:36:34 ... Okay 15:36:36 Manu Sporny: I would prefer we put the should thing in there, uh… no promotion... 15:36:39 Otto Mora: uh... 15:36:50 ... Promote parameters 15:36:53 Manu Sporny: Implementers, you know, should not promote parameters without explicit choice. You could do that in the second sentence... 15:36:57 Otto Mora: Without explicit choice?... 15:37:08 ... implicitly. They're understanding what they're doing. So 15:37:11 ... That works 15:37:16 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Um... 15:37:17 Otto Mora: Oh!... 15:37:18 Manu Sporny: There's a duplication. Yeah, there's a duplication second sentence... 15:37:21 Otto Mora: Language would be... 15:37:24 ... Oh, yeah, sorry, sorry 15:37:27 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah... 15:37:31 Otto Mora: It's saying the same thing. You're right. Okay. Cool. Uh, alright... 15:37:34 Phillip Long (GU, T3, ASU): I think you have it in twice... 15:37:39 transcriber-bot, pause 15:37:39 Otto Mora: Let's see… Uh, yeah, okay. The… Transcriber box... 15:37:39 scribe- 15:37:43 PROPOSAL: The did resolution algorithm will use Resolve(did, options). Language will be included to clarify the implementers SHOULD NOT promote parameters without explicit choice. 15:37:46 +1 15:37:48 =1 15:37:49 +1 15:37:50 +1 15:37:53 +1 15:37:53 +1 15:37:54 +1 15:37:55 +1 15:37:57 +1 15:37:58 +1 15:38:06 +1 15:38:13 apologies for a flakey keyboard.. 15:38:16 Wip has joined #did 15:38:20 +1 15:38:24 s/=1/+1/ 15:38:50 @manu LOL 15:38:53 RESOLVED: The did resolution algorithm will use Resolve(did, options). Language will be included to clarify the implementers SHOULD NOT promote parameters without explicit choice. 15:39:02 transcriber-bot, resume 15:39:02 scribe+ 15:39:07 q+ 15:39:09 Otto Mora: We can, uh, now discuss who would be... 15:39:13 ... Like, uh, taking this on, I know that 15:39:22 ack swcurran 15:39:28 ... There was a PR change from Joe that he had shared with us. I don't know if that's addressing this too, or it could. I see that Steven's got his hand up, so go ahead, Steven 15:39:31 q+ 15:39:31 Stephen Curran: I have closed the PR that I own, so I've taken my action. That's it... 15:39:37 Otto Mora: Okay, so you're… you're… you're… Yeah, you've withdrawn yours... 15:39:43 Stephen Curran: The PR that I opened, the PR, yeah, PR that I opened to execute on the last resolution is now closed. So there you go... 15:39:49 Otto Mora: Got it. Thank you. Uh, Joe?... 15:39:50 ack JoeAndrieu 15:39:52 Stephen Curran: Okay... 15:39:55 Joe Andrieu: Um, yeah, my PR is not, uh, doesn't entangle this, because it was just about the dereferencing... 15:39:58 Otto Mora: Okay... 15:40:05 Joe Andrieu: Um, so I can update that so that it has the new signature, as appropriate. Um... 15:40:08 q+ 15:40:12 Otto Mora: Mm-hmm... 15:40:15 Joe Andrieu: But it's not going to address the resolve, because I didn't touch that section at all... 15:40:16 Otto Mora: the... 15:40:17 ack markus_sabadello 15:40:17 Markus Sabadello: Mmhm... 15:40:20 Otto Mora: Okay. Yes, Marcus?... 15:40:23 Markus Sabadello: Actually, I think if we... 15:40:25 q+ 15:40:37 +1 15:40:39 ... if we do what we just decided, then I don't think we need to change anything in the resolution algorithm, because that's part of the dereferencing algorithm, right? Promotion of the… of the parameters 15:40:42 Otto Mora: Mm-hmm... 15:40:44 ack Wip 15:40:50 ... But maybe that's the second piece, I guess. Maybe that's what Will has. Let me see. Well, go ahead 15:40:56 Will: Yeah, that's a good point. Um... 15:41:12 q? 15:41:12 ... I was imagining there was some change to the Resolve, but the API is still the same 15:41:18 q+ 15:41:23 ... Maybe there isn't, like, maybe… I'm wondering if we should capture this and add some sort of security consideration or something, right? Like, because we're going to move this… I'm hoping we're going to be able to move to CR with something, and it isn't going to have the dereferencing algorithm in at this point, right? We're going to mark 15:41:23 it as at risk 15:41:36 q+ 15:41:37 q? 15:41:37 ... Uh, maybe that's fine, because I think we all know on this call we are not going to go direct until we have the DigURL dereferencing algorithm in there. So, if that's the case, and everybody's happy with that, maybe we don't need to make any changes. The only change we need to do to the spec is to mark DigURL dereferencing as at risk. At the 15:41:37 moment? 15:41:40 Otto Mora: Perhaps... 15:41:41 Will: I don't know... 15:41:41 Manu Sporny: Yeah, I mean... 15:41:43 ack manu 15:41:44 Otto Mora: manual… uh, yeah... 15:41:45 +1 to Wip 15:42:11 Manu Sporny: for features that are at risk, I mean, you have to have something there, right? Like, we can't… I don't think you were suggesting, uh, Will, that we just delete the dereferencing section, or delete it and just say that things at risk. Uh, you have to, as far as I understand, uh, PAA, like. We have to make our best effort into, like, 15:42:11 hey, here's how it works... 15:42:16 ... And it can kind of be a little, you know, loose, and we might remove it, but we should have a fairly decent structure in there 15:42:25 ... And that means, you know, we could go with what we have right now, or we could go with, you know, Joe's thing, uh, in there, or some variation thereof. Um 15:42:31 +q 15:42:43 ... I don't know what the plan is there, because one of those, you know, we don't want to drag it out for another two months trying to figure out, like, okay, well, what text are we going to put at risk, you know, in dead resolution? I think we can just mark something where people can get a general idea of how to implement it 15:42:49 ... And then we can change that, uh, during CR as we see fit, or decide that we're just gonna delete the entire section. Um 15:42:50