Mark DID URL Deferencing at risk

[ottomorac]

This PR implements the resolution from the DID wg meeting on 2-july: https://www.w3.org/2026/07/02-did-minutes.html#0fa3

RESOLUTION: Focus on moving did-resolution to CR, with DID URL Deferencing marked "At Risk"

This marks related sections as at risk per the W3C Processes for the same: https://www.w3.org/policies/process/#at-risk

---

Preview | Diff

[msporny]

We probably don't need as many at risk markers as exist in the spec. Just one per section to be removed/heavily modified is enough.

[ottomorac]

We probably don't need as many at risk markers as exist in the spec. Just one per section to be removed/heavily modified is enough.

Thanks @msporny . Ok, I think we could remove the marker in the "DID URL Dereferencing Result" (section 10). And then suggest we keep markers in these sections:

• Status of the document section at the start of the spec
• DID URL Deferencing (section 5)
• Provisional DID URL Dereferencing (section 6)
• DID Resolution Architectures (section 8), the comment that references the DID Resolution Threat model

@jandrieu do you agree with this approach as well?

[wip-abramson]

I like @msporny's suggestions, but other than that looks good to me. Thanks @ottomorac

[swcurran]

I'd like to see at least Manu's suggested change that I commented on applied before merging.

[ottomorac]

Hi @swcurran,

Ok just applied Manu's change.

[peacekeeper]

My understanding of the WG resolution was that it would cover sections 5 and 6, so I am fine with marking them at risk.

But I don't really agree with also marking sections 8 and 10, at least not without discussing them first. What's the problem with those sections? I think section 8 is useful for understanding different architectures of how clients, resolvers, dereferencers can be implemented, and section 10 has multiple interoperable implementations, so I think it may hurt interoperability if we remove that.

Maybe change this PR to really only mark "DID URL Dereferencing" at risk (as the title says), and create separate PRs for other sections?

[jandrieu]

I'm good with this as is, although I also support Manu's suggested changes.

[w3cbot]

This was discussed during the #did meeting on 08 July 2026.

View the transcript

w3c/did-resolution#346

Will Abramson: Okay, well, that's fine. I'm sitting, and I'll
… updated feedback from them. So, okay, let's move on to 346. So 346 is really trying, Otto, again, took this one on, which is great. He's trying to execute the resolution that we passed last week, which was focused on moving DID resolution to CR with DID URL Dereferencing marked at risk
… And when we reviewed this text, really, the editors, like Joe and Stephen, and I think many of you weren't there, actually, but we just looked through the spec and realized there are a few other sections that are, like, heavily
… Did URL dereferencing dependent? I mean, obviously, did URL dereferencing is woven throughout the spec, and I think
… that obvious tag will have to realize that, and I think that's fine, because we have this top statement that says, you know, did URL be referencing?
… feature is at risk, and if we do remove it, we are going to have to do some surgery to the spec
… the… the… oh, that… Sections that we marked as at risk
… that really Marcus is querying are the did resolution architecture section
… And the did URL dereferencing result section. I'd love to hear from people
… what they think, or, like, how do we move past this without just… you know, I don't think we can completely overrule Marcus. I mean, maybe he is right, we didn't have a discussion about what to do with the DID resolution architectures section in the group
… But I really was hoping to get this merged. So yeah, that's tricky
… Yeah

Manu Sporny: Uh, I did a quick, uh, read-through of the sections Marcus is saying we should not mark as at-risk. Uh, they are largely non-normative, though we do have a couple of normative, like, should statements sprinkled throughout...
… Um, which, you know, I don't like, I don't think we should be doing, but… but whatever, right? They're not… I don't think there are any musts, uh, in either section
… Um, and for that reason, I'm fine removing the at-risk issue markers. Um
… Because, you know, whether or not they're marked at risk or not
… If we change did URL dereferencing, there is a chance that those other sections are gonna have to change as well, right? So I don't, you know, I disagree with Marcus saying like we shouldn't mark it as at risk. There's no downside to marking it as at risk
… You know, as at risk, we're just saying, hey, like there, this section might change heavily, um, and people should pay attention to it, um, but if markets is gonna block, uh, you know, us being able to get these, uh, you know, get the CR based on this, then. Find, like, remove the language and, um
… And we, you know, we will have marked the ones that are really, you know, likely to change. as at risk, and we can… we can move on from there. So

<Zakim> JoeAndrieu, you wanted to speak for at risk for resolution architectures

Manu Sporny: Anyway, all that to say, I think it's fine for removing the at-risk markers for the things that, you know, Marcus is objecting to, um, if it gets us into CR

Will Abramson: Yeah, thanks, Manu. I do hear that. It's important to get to CR. Joe?...

Joe Andrieu: Yeah, unfortunately, Manu, I disagree. I'm the one who asked that we put that section at risk. It has language in there that I would formally object to. We define things that violates our fundamental security model...
… I really think we need to, at a minimum, put it at risk
… And we're going to have to talk about those sections if Marcus is going to fight to put them in. But we define things like proxy in your resolver, which is not supported by our security model. We have no consensus mechanisms by which we could secure that architecture. And the presumption is you need to trust your resolver
… And I think the conversation that Marcus wrote was intended to be, these are ways that things can be done, which is true, but they are not things that are part of our recommendation
… And so I think we really do need to keep that section at risk. And I didn't hear Marcus's objection to saying he's going to stop CR. I'm hearing him say he wants us to have a conversation about it

Will Abramson: Yes. I mean, I think that was his main concern. He just saw the spec and didn't realize the exception would get marked at risk. Manu?...

Manu Sporny: Yeah, and, you know, acknowledge Joe, that's, you know, a legitimate concern. I don't think you can, I don't think you can, I mean, you can formally object over anything, right? And you can object over anything, but like objecting over marking something is at risk is a bit...
… I don't
… No, no, no, no, I'm not talking about you, Joe. Yes, I heard you understood fully. I'm talking about Marcus. If Marcus is like, no, I am blocking our transition to CR, at that point, I think you can just override and basically be like, we are just putting an at-risk issue. Marker in here, like… you know

Joe Andrieu: No, I mean, I will object to this content. This is...

Manu Sporny: If you want us to talk more about it, we can talk more about it during CR. If you want us to talk about it right now...

Joe Andrieu: Oh, okay, sorry...

Manu Sporny: You know?...
… what's the point, right? Like… anyway, so I don't… I don't think it's… let's just have a discussion with Marcus tomorrow, hopefully he's on the call
… Um, and if not, let's leave it in there, and, you know, if folks want to object to it, we can say, hey, yeah, when we tried to transition to CR, there was an objection over marking a section as at-risk. And then, you know
… I don't think that… I think the response to that is like, okay, we… like, you know, it's, uh… you can talk about it in CR. It's marked as at-risk. That's it

Will Abramson: Yeah, great. I mean, uh, I think we're all on a similar page. Uh...
… I spoke to Marcus today, actually, and he said he's at this event. I'm hopeful he's going to come tomorrow, but if he's not, I think we just should… I think I take Manu's point that we should move forwards. I mean, I think we could get Marcus on board that this did resolution
… architecture section… I mean, I think I've agreed with Joe, really. This is… this is currently a section that just says, here's different ways that you could do this architecture without any real, um
… thought around the ways in which we want people to do this architecture, right? It's just, here are all the different variations, and there's no, sort of, like
… guidance around which variation is good or bad. And I think my understanding, maybe talking with Joe and some others, is that really this did resolution architecture section can be, I mean, as we mentioned there, right, can hopefully be replaced by the resolution threat model
… which is gonna, sort of, review the architecture, right, like with the DFD diagram, and then have some
… analysis, security analysis over that architecture. And… I mean, I think some of the sections in this architecture section, right, about, uh, I think it's the proxying section, maybe isn't even going to be in there. I'm not sure, I'd be interested to see how that plays out, but
… I think… I think we on the group think that's a bad idea, and we shouldn't be talking about it in… like, in this section, it's just like, here's just one way you could do it, and we don't say whether it's good or bad, or what the risks of doing it are, we just say, you know, you can do it like that if you want. um
… So, yeah, I think I like Manu's suggestion. I mean
… I take Marcus's point, we haven't talked about this as a group, right? So maybe Marcus just feels like it's gone out of nowhere, we should chat about it. I do also see that, you know, just want to get to CR. We think we're all in agreement that this section is going to be under discussion in CR
… I guess pretty, it doesn't matter too much either way. Anyway

Otto Mora: Yeah, I mean, um...

Will Abramson: What's up?...

Otto Mora: Yeah, I mean, I'm just echoing that I understand where Marcus is coming from, but I do agree with Joe's view on this, that...
… It is a
… Uh, something that, you know, is definitely going to be subject to change, and we do want to show. to the outside world, I guess, that we are… You know, kind of taking the work to do the resolution threat model, which is important, so
… Uh, even though, yes, okay, his point, yeah, formally discuss it in the call, okay, fine, but I do agree with Joe's positioning here, I think it is correct. Uh, I guess, yeah, that's it

Will Abramson: Yeah, so I think I'll add maybe just to close unless anyone has anything else. I think we can say now that we are going to discuss this again tomorrow and I will message Marcus to say that, right? But if he can't make the call, I think we should just overrule and leave these...
… sections in. I mean, the other section that we've not talked about is section 10, so maybe we can just briefly discuss that, like
… Uh, again, this is… this is non-norm… I don't think there's any normative statements in here, um, so maybe it's… it's not as important, and we could just get rid of this at-risk marker for now
… I mean, it's obviously entangled with digital URL dereferencing, so it's definitely going to be under discussion in CR
… I mean, maybe, like, you know, if that's the easiest path to just move forward, perhaps we do that
… Joe

Joe Andrieu: Yeah. Two things. One is to correct some notion about normative...
… Any section in here that is not marked as non-normative is normative
… Um, so whether or not it has shoulds or may, this section is normative
… And it would be very easy for a later edit to add a normative thing. So if if we intend for sections to be non normative we need to mark them as non normative
… that might be one step towards including, you know, the resolver architectures as, you know, a compromise direction, if ultimately that's where we went. Um, but this is at risk because it's part of dereferencing. So
… Um, right now, I do not believe we have group consensus, and I think we had a resolution to the effect that, um, we are not going to have a dereferencing function as a call, and this was the result of that function
… So I think this is just all bundled up in, you know, we're still figuring it out and trying to come to terms over what dereferencing is

Will Abramson: Mario?...

Manu Sporny: Yeah, plus one to that. I do think we need to go through and explicitly mark sections as informative or normative. That is, you know, editors typically do that much earlier in the process than this. And what that does is it adds...
… piece of text underneath that section that says this section is informative, uh, and Joe's right. This doesn't have it written as that, and therefore this section is normative, um, even though it does not have any normative, um, statements in it, and also plus one to, like, we have not agreed. that this is, you know, the output here, and so it

should be marked as at risk

Will Abramson: Okay, um...
… Yeah, so… yeah, I was kinda hoping we were gonna get to merge this today, but I think that's not possible, but we can review it again tomorrow, and uh
… You know, hopefully get through this. I hope Marcus is on the call and we can just talk through this. I mean, one of Marcus's pushback is as all, you know, as he's been saying throughout this, for instance, like, there are people who are depending on this did resolution result. He thinks if, I mean, not to put words in his mouth, but I think he

thinks that if we remove this, we're going to harm Interop
… But I think I am more in agreement with the rest of the group, which is, you know, we haven't really agreed this. It's all on discussion. I think we have passed some resolutions which impact this, particularly around HTTPS binding
… I think there is maybe a compromise that we were exploring, but then just didn't quite get to around. Leaving the HVS binding section in as informative. I'm not sure, but I think all of this needs more discussion and that's part of the problem, right? We don't want to have any more discussion. We want to just
… get something that we're happy with, which is just a resolution algorithm. into CR, right? So
… Uh, yeah, I mean, personally, I don't care how often I'm in favor of marking this section at risk and just moving forwards, but I can appreciate that, because it came as a surprise, so… this discussion. Hopefully we can have that tomorrow. Um… Okay
… Uh, any final comments before we move on to Joe's panel?

Otto Mora: No...

---

[ottomorac]

Hi @peacekeeper ,

Thanks — agreed on 5 and 6.

The issue was discussed during WG meeting on 9-July today. Please see here: https://www.w3.org/2026/07/09-did-minutes.html#a98a

On 8 and 10: an at-risk marker is non-normative and editorial. It doesn't mean we intend to remove these sections — it means the WG is still actively debating them and may revise them during CR. It's the mechanism for the conversation you're asking for, not a decision taken ahead of it. If a section stabilizes during CR, the marker simply comes off.

Section 8 reads as normative today but describes proxying / chained-resolver configurations that several of us think conflict with our resolver-trust security model (a resolver silently trusting another resolver introduces centralization, surveillance, and compromise surface we haven't defined a way to make trustworthy). That's an unresolved substantive debate, which is why it's marked. Joe opened #347 to work through it, and the section may be reframed around the resolution threat model.

Section 10 is entangled with the dereferencing rework in #344 and doesn't yet reflect consensus. Marking it at-risk flags that to implementers rather than removing anything — the interoperable implementations stay, and the marker comes off if consensus holds through CR.

Rather than splitting into separate PRs, we'd prefer to keep the markers in #346 and track the debates in #347 (architecture) and #344 (dereferencing), so the CR transition isn't gated on resolving them first. The group resolved this week to publish as CR once #346 is merged. Would welcome your input in #347.

[wip-abramson]

To add to @ottomorac, marking these sections at risk does not mean the group has agree to remove them. It simply means that the group believes more discussion is required to get to a consensus position about these sections.

The fact that you disagree, while others strongly feel these sections need further discussion just highlights this IMO.

For this reason, following the discussion in the group this week, the chairs have decided to merge this PR over your request for changes.

In the coming weeks, we fully intend to create a further CR iteration that resolves the at risk nature of the sections marked in the spec in the PR.

Thanks

[peacekeeper]

Section 8 reads as normative today but describes proxying / chained-resolver configurations that several of us think conflict with our resolver-trust security model (a resolver silently trusting another resolver introduces centralization, surveillance, and compromise surface we haven't defined a way to make trustworthy). That's an unresolved substantive debate, which is why it's marked.

If the WG is bothered by proxied resolution, then why not just mark that sub-sub-section "at risk"?

Section 10 is entangled with the dereferencing rework in #344 and doesn't yet reflect consensus.

I don't understand. How is it "entangled" with the dereferencing algorithm? In my opinion, it's completely independent of it.

[TallTed]

@ottomorac — Please don't refer to sections by number (as in #346 (comment)), as these numbers are likely to change. Much better to refer to sections by title (which may include the current number), as this is much less likely to change.