Meeting minutes
<ottomorac> w3c/
Agenda Review, Introductions (5 min)
<ottomorac> transcriber-bot, connect
Otto Mora: So, yeah, for today, we have, um...
… a proposal that we're gonna run regarding the debt resolution
… Uh, spec and the overall plan
… 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
… Some of the potential, uh, security issues, and then walking us through some options
… 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
… we can look at that one. And then, uh, just generally talking about debt resolution issue processing, so that
… We can look at whatever else is needed to try to achieve candidate rec status
Proposal regarding DID Resolution CR (10 min)
Otto Mora: Anything else that folks wanna add, uh, to the agenda, or any… Province. Okay. Okay, so
… Last week, we had a conversation that was facilitated by Will. There was this presentation, which I'm going to paste in the chat
<ottomorac> presentation from Will: https://
Otto Mora: And that presentation made it clear that we have limited time. We need to really try to achieve something. By the time our, uh
… 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
… 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
… Uh, so it says, focus on moving date resolution to CR with date URL dereferencing marked at risk
… 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
… 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
Manu Sporny: No comments. I defer to the group...
Otto Mora: Okay, anybody else?...
<ottomorac> transcriber-bot, pause
<ottomorac> PROPOSAL: Focus on moving did-resolution to CR, with DID URL Deferencing marked "At Risk"
<manu> +1
<ottomorac> +1
<swcurran> +1
<Wip> +1
<markus_sabadello> +0.5
<pchampin> +1
<JoeAndrieu> +0
<dmitriz> +1
<JennieM> +1
<pdl-asu> +1
<ottomorac> transcriber-bot, resume
Otto Mora: Okay, perfect. Okay, so with that, yeah, we passed the resolution. So...
RESOLUTION: Focus on moving did-resolution to CR, with DID URL Deferencing marked "At Risk"
Phillip Long (GU, T3, ASU): Yes...
Otto Mora: Resolved. We do agree to. Focus on on that. So… Uh, yeah, great. So...
… Now, now that we, we have that
Proposal regarding DID Resolution inputs (10 min)
Otto Mora: and… Let's move to the next topic
… Which is, yes, regarding the DID resolution inputs and the conversation that we had yesterday
<ottomorac> presentation: https://
Otto Mora: During yesterday's call, we had this presentation. I'll share the link of it here as well in the chat
… And in that presentation we discussed a couple of options regarding. how to address the
… confused deputy attack that was illustrated by Joe, and we we kind of had. um
<pdl-asu> options on slide 9
Otto Mora: you know, 4 options, one of them, including, you know. resolving a did with the current spec. Another one
… 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
… 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
… 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
… You're on mute
<pdl-asu> I think we gravitated at the end to option 4
Otto Mora: And
Joe Andrieu: Sorry...
Otto Mora: Go ahead, yeah...
Joe Andrieu: I, uh, I just wanted to, uh, share… there were 2 additional options that were discussed...
<swcurran> I would prefer option 3
Joe Andrieu: 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
… 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
… So there is that fifth option that we talked about
Otto Mora: Okay, so option five would be...
… Option 4 with no promotion by default. Okay
Joe Andrieu: That's right...
Otto Mora: And I see that, uh, Banu had commented, uh… the...
… Maybe, like, option 4 a little more… Um
… Steven, I know he had also voiced both in the signal chat and here that he likes option 3 a little more. Um
… I don't know, do we want to dwell maybe into that, Steven? maybe you're… Your preference for option three. Yep
Stephen Curran: Sure. Sure, um, I think...
… The options are all quite similar, um, and as a result
… By selecting option 3, we really
… 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
… handling. But we've added this new parameter that doesn't exist. So our backwards compatibility is actually even worse than. Um
… switching to DID URL versus DID. So, I… I think that's quite a negative on… on 4. The
… The intention is the same in 3 and 4
… Um, the… the difference is the literal calls, and by making the calls different. Um, we get
… Uh, we get to a worse position, um, relative to the current state of implementations
… And so that's why I would prefer three
Otto Mora: Yes. Okay...
Stephen Curran: Basically, all the things that Marcus is, or some of the things that Marcus was, Marcus was ideally for...
Otto Mora: Mm-hmm...
… Okay, thank you. Manu?
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...
… 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
… 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
Stephen Curran: Well, it seems to me that today. Um...
… Before the proposal that was accepted a week and a half ago or so. the
… Call was resolved, did, and options. And now we would be
… If we changed it to DID URL and options
… 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
… 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
… non-standard way of doing it, so that's why I would prefer. Option 3. With the guidance being
… You know, make sure when you pass parameters
… you make explicit choices on it because you could be doing bad things
Otto Mora: Mm-hmm...
Stephen Curran: Does that make sense, Manny?...
Manu Sporny: I understand what you're saying. I'm putting myself on the queue. Thanks...
Stephen Curran: Oh...
Otto Mora: Thanks. Yeah. Yeah, I think it's worth letting Marcus also chime in here...
Stephen Curran: Okay. Got it...
Otto Mora: chime in his view, and then we'll come back to you after Will has also intervened. So go ahead, Marcus...
Stephen Curran: That's all...
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...
… 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
… But I think that's not true. I think the client does have some knowledge about the use case
… 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
… 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
… to come from a TTRL parameter
… 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
… 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
Otto Mora: Uh, well...
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...
… 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
… The client is deciding
… 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
… 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
… 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
… 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
… 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?
Otto Mora: Mm-hmm...
Will: Thanks...
Otto Mora: Manu?...
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...
… 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
… 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
… 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
… 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
… 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
… 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
Otto Mora: Mm-hmm...
Manu Sporny: And option four. Um, yeah...
<Zakim> JoeAndrieu, you wanted to say the problem is the bad use cases we don't want to enable
Otto Mora: uh… Joe?...
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...
… 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
… 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
… this whole architecture is fundamentally more insecure if we don't lock down this request pattern. Um
… The other thing is, I do think this, the backwards compatibility matters right now
… 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
… 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
<Zakim> manu, you wanted to note too meta "all the use cases" vs. "bad use cases" vs. "good use cases"
Joe Andrieu: And then we're just back to number three. So I think four does have backwards compatibility problems
Otto Mora: Okay. Thank you, Joe. Manu?...
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...
… 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
… 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
… want something
… 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
… 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
… That's it
… 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
implementers
… have the ability to make the choice rather than the spec being overbearing on kind of, you know, the corners of the ecosystem
Otto Mora: Okay. So that was should not promote without sorry. I know I just wanted to capture. without, uh...
Manu Sporny: No, understanding what the parameter does...
Otto Mora: Understanding the, okay, the, yeah, bunch of parameter dots. Yep...
… Thank you. Just wanted to note that. Okay, uh, Will?
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
anymore...
… 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
… 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
<swcurran> +1
Otto Mora: Okay, sure...
Joe Andrieu: Yeah. I think I think, we are converging on three, so that's good. I don't like the should language...
… 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
Phillip Long (GU, T3, ASU): Wow...
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...
… 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
… 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
… We don't wanna do the thinking about it. And I think we need them to do the thinking about it
Otto Mora: Manuel?...
Manu Sporny: Yeah, I mean, I understand what you're saying, Joe...
… 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
… 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
… 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
… 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
… I'm going to just willy nilly pass stuff along, right? But I think Must is going too far
… 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
… where, you know, I'm guessing you probably wouldn't agree with that interpretation, Joe, but… Uh, yeah
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...
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...
… That's it
Joe Andrieu: But I think whatever the group goes with, I could support. I think should is enough. I'd prefer must...
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...
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...
… 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
<MacTed> SHOULD == "do this unless you have a very good reason not to *and* you fully understand the implications of doing otherwise"
Otto Mora: Okay, so...
… How do we run this? I guess people in the chat that support the chute type a plus one
<ottomorac> +1
<manu> +1
<pdl-asu> +1 for slhould
<markus_sabadello> +1
<dmitriz> +1
Otto Mora: Interesting. That's what I'm saying
<swcurran> +1 for should
<smccown> +1
<JoeAndrieu> -1
Otto Mora: Yep, okay. Okay, so yeah, that
… That's pretty much it, but I guess, um
… Joe, you indicated that for now you're fine with the
Joe Andrieu: Yeah, I didn't mean blocking with that minus one. I just… I do prefer must...
Otto Mora: But the way they… Okay. Yeah, yeah. Let's… let's...
Joe Andrieu: Yeah, I can support this. I would accept that this is consensus...
Otto Mora: Perfect. Thank you. All right, cool. So yeah, I think then...
… Do we run a proposal now, Will? Yeah. Yep, yep
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Just just just a small thing. One of these usual arguments against should is that...
… Quote unquote. It won't be tested, or quote unquote
… 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
… 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
… 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
… our testing, which is to make sure that implementation is possible, and for later testing as to what features somebody supports. That's it
Otto Mora: Yeah, yeah, absolutely. Have to be testable. Will?...
Phillip Long (GU, T3, ASU): Sure...
<pdl-asu> +1 for clear statements about should is do it unless you have an explicit reason it can't be done in your context
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...
Otto Mora: Mm-hmm...
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...
Otto Mora: Okay, we'll use Resolve. Okay, deed options...
… Hey, maybe with, um… No promotions
… Uh… And… No promotion without explicit choice
… Language will be included
… To clarify… Yes
… They need to understand
… what parameters to… How's that sound? Any comments on that?
… Okay
Manu Sporny: I would prefer we put the should thing in there, uh… no promotion...
Otto Mora: uh...
… Promote parameters
Manu Sporny: Implementers, you know, should not promote parameters without explicit choice. You could do that in the second sentence...
Otto Mora: Without explicit choice?...
… implicitly. They're understanding what they're doing. So
… That works
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Um...
Otto Mora: Oh!...
Manu Sporny: There's a duplication. Yeah, there's a duplication second sentence...
Otto Mora: Language would be...
… Oh, yeah, sorry, sorry
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah...
Otto Mora: It's saying the same thing. You're right. Okay. Cool. Uh, alright...
Phillip Long (GU, T3, ASU): I think you have it in twice...
<ottomorac> transcriber-bot, pause
Otto Mora: Let's see… Uh, yeah, okay. The… Transcriber box...
<ottomorac> 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.
<ottomorac> +1
<pdl-asu> +1
<JoeAndrieu> +1
<smccown> +1
<MacTed> +1
<manu> +1
<JennieM> +1
<markus_sabadello> +1
<pchampin> +1
<swcurran> +1
<dmitriz> +1
<pdl-asu> apologies for a flakey keyboard..
<Wip> +1
<pdl-asu> @manu LOL
RESOLUTION: The did resolution algorithm will use Resolve(did, options). Language will be included to clarify the implementers SHOULD NOT promote parameters without explicit choice.
<ottomorac> transcriber-bot, resume
Otto Mora: We can, uh, now discuss who would be...
… Like, uh, taking this on, I know that
… 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
Stephen Curran: I have closed the PR that I own, so I've taken my action. That's it...
Otto Mora: Okay, so you're… you're… you're… Yeah, you've withdrawn yours...
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...
Otto Mora: Got it. Thank you. Uh, Joe?...
Stephen Curran: Okay...
Joe Andrieu: Um, yeah, my PR is not, uh, doesn't entangle this, because it was just about the dereferencing...
Otto Mora: Okay...
Joe Andrieu: Um, so I can update that so that it has the new signature, as appropriate. Um...
Otto Mora: Mm-hmm...
Joe Andrieu: But it's not going to address the resolve, because I didn't touch that section at all...
Otto Mora: the...
Markus Sabadello: Mmhm...
Otto Mora: Okay. Yes, Marcus?...
Markus Sabadello: Actually, I think if we...
<swcurran> +1
Markus Sabadello: 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
Otto Mora: Mm-hmm...
… But maybe that's the second piece, I guess. Maybe that's what Will has. Let me see. Well, go ahead
Will: Yeah, that's a good point. Um...
… I was imagining there was some change to the Resolve, but the API is still the same
… 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
it as at risk
… 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
moment?
Otto Mora: Perhaps...
Will: I don't know...
Manu Sporny: Yeah, I mean...
Otto Mora: manual… uh, yeah...
<swcurran> +1 to Wip
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,
hey, here's how it works...
… 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
… 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
… 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
… 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
… Just wondering what's going to happen or what the expectation is
<pdl-asu> Is Joe's thing with this language abou should included do it?
Otto Mora: Yes. Uh, Pierre?...
Pierre-Antoine Champin: Yes, plus one to what Manu said. My idea about this was indeed to have something that may not be the final version of the referencing, but it could be… One of the two versions that we have right now...
… And as such, I think, even if the section is marked at risk, if we were to keep the current, well, the first one of the two versions that we have in the current draft
… We should, no pun intended, change the part that says automatically promote all parameters into options to implement the decision that was just made
… Because at this point, it's still closer to what we might get in the end than the current text. So yes, we need something that is complete, even if it's not final. And yes, we should implement that change, even if that thing is expected to change more in the future
Otto Mora: Okay. Uh, yeah...
… I'll try to find that. Thanks. Okay, Steven?
Stephen Curran: Yeah, the issue, Manu, with your idea is that that suggests we would get through… we would have to debate and go through and get a PR merged...
… that does anything more than say it's at risk. And Will's goal of having a CR in the next couple of days
… is against that idea that we're going to merge something more. So what we've got to figure out is just where do we put the words at risk?
… And that should be all we're trying to do in the next couple of days
… So
… Like, right now, we have two DID URL referencing sections. Um
… I'm okay with whatever we decide to leave in, but I think
… the only PR we want created
… And debated, and then merged, is one that says
… This feature is at risk
… In… in a suitable way. And maybe remove one of the two
… did URL dereferencing sections
… But I think that's all we should aim for, and not try to debate did URL dereferencing any further. in the group. That's it
Otto Mora: And one more thing here, also, like, that we discussed about Manu, I mean, just as context from yesterday, was that we can go to CR with, uh, maybe, like, this existing version, and this, like, work-in-progress, uh, kind of version, there's a respec feature that would allow us to. have that omitted from the CR version. Uh, so that
would...
… logistically allow us to keep working on on this one whilst like just putting that out there and still marking this at risk
Will: Yeah, so, um… I mean, I take what Stephen said, maybe I have a bit of a...
Otto Mora: So that was kind of a conversation we had yesterday. Um, well...
Will: left-field suggestion, but I think there are a few options, right? We absolutely need to mark something at risk, and we've got to choose what we mark at risk, right? We can either mark everything that we have in our spec at risk, you know, the digital URL dereferencing both of them at risk, and put those in Candidate Rec, but then, you know,
maybe we're signaling that...
… we're a bit all over the place. We can, you know, like, selectively disclose which current video URL dereferencing algorithm we want to put as at risk in the CR. The option that I was going to propose, which maybe we definitely can't do this, I mean, Steven, you were saying in the next couple of days, like, I'd be happy if we got the CR in the
next couple of weeks
… Um, there is a little bit of a conversation about the threat model, which maybe we won't have time to get into today, but one thing I want to suggest is maybe Joe's PR that he has open, like, I have reviewed it, I think it's a great step in the right direction. I don't know if other people have had a look at it
… But I feel like that is the most accurate reflection of the direction that we all are intending to move in. Like, I guess the only hesitation I have there is we would maybe be rushing to merge that in, and, like, signaling that it's more, uh, stable than it perhaps is, but, like
… Perhaps by marking it as at risk, we're already signaling that it's, you know, it's at risk, and it's
… it's not got consensus, but I still feel like
… that text is the most accurate reflection of where the group is, whereas I think the other option that I would suggest, rather than, like, marking as at risk, this sort of, like, half-done outline, which I think definitely looks like, you know, you guys have not even
… made much progress, I would suggest we keep the current version of the digital URL dereferencing text, you know, like the initial version that's been in the spec for ages. But then that does feel like there's quite a big, uh, delta between where we are at the moment as a group
… Uh, so I don't know, I just wanted to throw that out there. I don't know if people have reviewed, had a look at yours, or if that is the direction we want to go
<ottomorac> w3c/
Otto Mora: Mm-hmm. uh… Yep. Um, Manu?...
Manu Sporny: Uh, yeah, plus one, I did get a chance to glance through it, and I agree with Will, it does seem to reflect, um, my thought where the group was, so my presumption was we were gonna merge that PR market as at risk...
… and then go into CR. I didn't know about the, you know, couple of days requirement. And I'm a bit concerned, Will, about the couple of weeks thing. Like, we can always say, oh yeah, we've been saying it'll be a couple of weeks since, like, you know
… last November, or something, right? So, um… plus one to Steven's concern, like, let's just
… Get something in there. I would not object to, you know, the… what's been in the spec for a long time, and us putting that at risk and going into… into CR with that. Um, with the clear indicator that, like, what is in the spec right now is not where
… Consensus seems to be going in in the group and we're just doing this to like get into CR and potentially cut the feature. I think we need to be very clear because, you know, the whole reason you mark things as as at risk is to warn implementers because CR is when you're supposed to implement
… we're warning implementers, like, this is not stable, and we're looking for input on it, right? Um, and so it's a bit weird to say, this is unstable, we're looking for input on this thing that we plan to not keep. We've got, you know, consensuses elsewhere, so
… plus one to what Will said, like, if we can mark Joe's PR as at risk, and merge it, and have general consensus, you know, around it within the next week
<pchampin> +1 manu
Manu Sporny: we should do that. And if we don't get there, the fallback is just mark what's in the spec right now as at risk. Um
… not including the other section, um… because that's just gonna confuse people, and it's, you know… and then… and then go into CR
… as concrete suggestions
Otto Mora: Uh, yes, Steven?...
Stephen Curran: Well, I'm concerned. I don't quite know how to express it, but I don't think it's that big a deal. I don't think the URL they're referencing were very far off. No matter what we do. So I'm not hard on. One way or the other, I think...
… But we have spent months and months and months on dereferencing, so I'm afraid if we have the conversation
… it's just gonna extend it out if we just if the agreement is, we just merge those I've got a whole, you know. I've gone through it. I've got a bunch of comments that I didn't put in, because I thought Will's direction. What we weren't gonna talk about did do URL be referencing
… Um… I think it's kind of risky to merge PRs when there isn't a full conversation and
… Um, and agreement that it's complete, but if we want to do that without having that conversation
… if that's the direction, I think it's more… the most important thing to me is we get the CR in a happy place, like, in a… sorry, a
… a place that is aligned with how W3C works
<Zakim> JoeAndrieu, you wanted to speak to ethics of CSS hiding
Stephen Curran: I don't think, um, we have to be happy in this group, because I think, um, we have to get there in a way that is aligned with W3C practices, so that the spec continues to move forward. That's it
Otto Mora: Joe?...
Joe Andrieu: Yeah, so there's… there's been an idea floated, and I… that I… I really have strong reservations about, and I'm… I'm not clear, Manu, if you support it or not, but you seem to suggest it towards the end. Um...
Stephen Curran: Yep...
Joe Andrieu: Which is this idea that we might go to CR and use CSF to hide some of the content. And I think fundamentally we should not do that. I think that is borderline unethical. And what we should present, if we are presenting the spec as it is today, it should include all of the mess...
… Otherwise, we should have what is our best step forward, and that's what we should put to CR. I think putting something to CR that is not our best step forward, and using CSES to hide it
… feels… it just feels intentionally deceptive to me, so I really don't think we should even be considering that option. Um
<swcurran> +1 to Joe's statement
Joe Andrieu: I do acknowledge that right now the spec has two sections that are incompatible. That's the truth
… I do not feel that the old section represents the current consensus of the group we have talked about and had commitments to refactoring that did URL dereferencing. And so I would like to push through with the PR that I put forward and deal with the issues that people have raised
… Steven, I would love to see your issues, um, so that I could address them. Um, there are some things that need to be fixed. There's no at-risk marker, it has a DID URL instead of DID in there, right? So there are some things that I can update, um, that's pretty straightforward. But I think what we need to do is hunker down and get a version of
this new thing that we've been talking about in here
Otto Mora: Mm-hmm...
Joe Andrieu: Um otherwise I think we're we're giving putting something in the CR that we know is not how we are imagining that this will resolve...
<Zakim> manu, you wanted to make a revised concrete proposal and to note that I didn't make the CSS suggestion! :P
Otto Mora: Uh, yeah. Manu?...
<swcurran> Question: Is that proposal against the first resolution we made?
Joe Andrieu: Okay, good. Thanks...
Manu Sporny: Yeah, to be clear, I did not make the CSE thing, and I'm not supportive of that. Like, that… no. That was not me, man. Um… the, uh… what we could do, um...
… Is, uh, take the current did URL dereferencing section, you know, as is, um, put in an at-risk marker, and state that this section is highly likely to be replaced by PR blah-biddy-blah, and point to your PR, Joe. Um
Joe Andrieu: No, no, hold on. Hold on. Sorry, I need to interrupt Manu. The spec today has language in it...
… Your proposal implies that you want to remove it. I would oppose that. So… the… the
Manu Sporny: That's fine. I mean, I think it would be cleaner to do that, and I don't think it's a big deal. I'm trying to get us into, like, CR sooner than later, like, you know, following what Steven had mentioned. I don't think debating...
Joe Andrieu: So...
Manu Sporny: your PR, Joe, is going to result in success. Like, I'm… I… after months and months of it, like, I don't think there's such a thing as, oh, there's gonna be a simple conversation around your PR. Um, I think it's gonna… gonna explode again. So… so, you know...
… how do we get into that? I'm fine with your suggestion of, like, we keep sections 5 and 6 in there, we mark both of them at risk, we say that they're both likely to be replaced by your PR show, and then we get into CR
<swcurran> +1 to Manu's proposal
Manu Sporny: And then we resolve, you know, cleaning that stuff up in CR. It doesn't make the group look good to have 5 and 6 going into CR, but, you know, whatever
… We've we're, you know, we got to make some hard decisions. What I do not want to do is continue to debate
… the dereferencing PRs. I'm very, very adamantly against that, uh, because we've been doing that for months, and we keep believing that the next PR is gonna make it in, and
… You know, it doesn't. And do I think we're done? Well, you know, with that. At least I am. That's it
Otto Mora: Okay. Pierre?...
… Sure
Pierre-Antoine Champin: Just to be clear, I was the one proposing the masking and… Yeah, it was...
… JavaScript, not CSS, but that's not the point. Uh, my, my proposal was, as Manu said, I think that it doesn't look good on the group to have two competing sections in the CR. I could live with that if, if
… If there's consensus, but I would rather have just one of them in the CR
… As long as we mark it very clearly as at risk, and with an additional note that says we have other proposals on the table, and probably this one will be replaced, but we don't know exactly with what
… So, my point was not to hide that there was dissent, or that there was other proposals on the table, just to have something that looks better for a CR, because what's okay for a draft is not as okay, I think, for a CR. And the idea of masking it was not, again, to be deceptive
… It was just to clean up things in a way that was less disruptive in the editor's draft than just plainly removing it before we publish. So, it was basically automating something that otherwise we would do manually, and that would be more tedious to
Otto Mora: Okay...
… Okay
Pierre-Antoine Champin: then revert to the working version. That's really what it was about. But again, if there's consensus to go with. two competing sections in the CR, and then so be it. Both marked as at risk, obviously...
Otto Mora: Okay, well… Yeah, I think, uh...
… That seems to be the chosen direction. For now, uh
… And I guess we will review, uh, Joe's updated PR, uh, as well
… Uh, we can maybe decide if we're gonna just mark them both at risk now and merge that in before Joe's PR, but… I guess we've, uh
Stephen Curran: We need to… Otto, we need a PR from somebody. to execute that...
Otto Mora: Okay, if it...
Stephen Curran: what Manu proposed...
Otto Mora: If it's just...
Stephen Curran: Somebody needs to do it...
Otto Mora: If it's just that, I'm happy to do it. Just mark both sections at risk and put that in. And then that way, we can just...
… you know, get on with with Joe's PR right after that. Does that work?
Stephen Curran: Actually, could I ask one more question before we close?...
Otto Mora: Yeah...
Stephen Curran: Um, just to help to clear up things, I'd like to close… My PRs...
… I assume that is the direction of the group, so I'd like to close the PR if I have
… Any concerns about that? I don't think anyone would care, but I just want to make sure that's the right procedural thing to do
Otto Mora: Um… But...
… I don't know, Mano, any idea, or… Any objection? Yeah
Stephen Curran: Okay, good...
Manu Sporny: Yeah, I think it's fine. I mean, if we're not planning to merge, yeah, we don't need to keep them up...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): I would just put in your comment like...
Otto Mora: Okay, sounds good...
Stephen Curran: It's probably, you know, the direction is definitely not. So I just want to make sure that's the right thing to do. And it's the conversation. Should the conversation be held, and so on. But I'm happy to close them. So I'm going to do that. Yes...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Suggestion withdrawn based on blah...
Otto Mora: Okay...
<ottomorac> transcriber-bot, pause
Stephen Curran: Yeah, yeah, I'll put a comment in. Thank you. Thanks, Jed...