w3c
Review ISSUE flags throughout the specification
There are a bunch of red ISSUE notes throughout the specification. A number of them seem out of date and should be tidied up.
What is the best way for the WG to process and clear these out of the spec? @peacekeeper thoughts?
My sense is that for the ones that we feel we need to address, we should have issues tracking them in github.
My initial take on the ISSUE flags that are old and should be removed:
- The two in the caching section - https://www.w3.org/TR/did-resolution/#caching.
- Section 12.6 Non-DID Identifiers (entire section as it is just an ISSUE that we moved to extensions repo) https://www.w3.org/TR/did-resolution/#non-did-identifiers
-
Should we define functionality that enables discovery of the list of [DID methods](https://www.w3.org/TR/did-resolution/#dfn-did-method-s) or other capabilities that are supported by a [DID resolver](https://www.w3.org/TR/did-resolution/#dfn-did-resolver-s)? Or is this implementation-specific and out-of-scope for this spec? For example, see [here](https://github.com/w3c/did-resolution/issues/26) and [here](https://github.com/w3c/did-resolution/issues/25).(From the bottom of https://www.w3.org/TR/did-resolution/#resolving-algorithm) - https://www.w3.org/TR/did-resolution/#architectures. Suggest this is done enough that it could be removed. Also, we have issues tracking the refining of the architecture section.
I am not sure about:
-
TODO: Define privacy considerations for DID resolutionhttps://www.w3.org/TR/did-resolution/#privacy-considerations. We do have one privacy consideration, probably there are more we could add?
There are also two under the DID Resolution Result section: https://www.w3.org/TR/did-resolution/#did-resolution-result
Need to define how this data structure works exactly, and whether it always contains a DID document or can also contain other results.
For certain data, it may be debatable whether it should be part of the DID document (i.e., data that describes the DID Subject), or whether it is metadata (i.e., data about the DID document or about the DID resolution process). For example the URL of the "Continuation DID document" in the BTCR method.
My sense is these two could probably just be cleaned up.
Then three ISSUES under https://www.w3.org/TR/did-resolution/#authentication.
One is for #38.
Then the other two seem to be suggestions for other security considerations. Shall we track these as issues?
Explain that DIDs are not necessarily globally resolvable, such as pairwise or N-wise "peer" DIDs.
See [RFC3339]: URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context.
An advanced idea is that the result of DID resolution could be contextual or depend on policies, see this comment.
and
A related topic is whether (parts of) DID document could be encrypted, e.g., w3c/did-core/issues/25. Also see the use of the fragment in the IPID DID method.
Hope this is helpful
This was discussed during the #did meeting on 30 October 2025.
View the transcript
Review Issue Flags throughout DID Resolution document
<ottomorac> w3c/
<ottomorac> Issue raised by Will, there are several red ISSUE notes throughout the DID Resolution specification.
Wip: Would appreciate people read over it -- found the "Issues" in the spec, categorized them as no longer relevant, some as needed.
<ivan> +1 to manu
manu: Issue flag needs an issue in the tracker if still relevant. Wip, do you want to go over them today?
<Wip> https://
Wip -- remove -- the ones in the Caching section. Has an open issue -- moved to DID Core.
manu: Remove both -- agree.
<Wip> https://
Wip: Security section -- move to an extension and not handling in DID Resolution. Just remove it.
<Wip> https://
manu: +1 to remove.
Wip: Another moved to an extension about discovery methods for a resolver. It's an extension...we've said.
Wip: There is an issue tracking this and it says in the DID Extensions.
manu: +1 to remove it.
Wip: DID Resolution Architectures. This is elsewhere partially, but should we leave it in?
<Wip> w3c/
manu: Perhaps an issue for Joe to ask about if this is part of other architectures. If so, then that might remove the section.
Wip: Issue 131 seems to track to that.
manu: Propose deleting the section and Issue from the spec per that issue.
Wip: Privacy Consideration. Perhaps create as an issue to create more.
https://
manu: Too generic. Remove the issue because we have a section. In other specs, there is language to use --- "you should also read the DID Core spec and then this section".
… Threat modelling has some stuff. Could use LLM to generate some ideas of what to build based on the specs and then curate the output.
Wip: For now remove it, add an issue to put in the language. There is an issue on Threat Modelling.
Wip: DID Resolution result section. Two -- remove them?
markus_sabadello: First can be removed based on DID URL Dereferencing inclusion.
… Second could be a general comment somewhere. We explain in Metadata section already, so probably not necessary anymore.
Wip: Will remove it in a PR and someone can object and add an issue.
Wip: Perhaps Markus can take a look at the last comment in the Issue 220.
… others we can raise issues to track and then remove.
This was discussed during the #did meeting on 11 November 2025.
View the transcript
w3c/did-resolution#220
wip: there are three outstanding ISSUE markers in the spec we haven't talked about.
… Issue 38 seems good. But the two immediately after that, we should discuss to see if they matter
… First issue explain that DIDs are not necessarily globally resolvable. This is in security considerations sections
JoeAndrieu: I know that I've used the term, but we don't have clear definition of what globally resolveable is. If we want to use the term, we need to define it more clearly.
manu: can we just delete this?
joeandrieu: Agree. Also its not a security
JoeAndrieu: I think we could just delete it since it's off topic
joeandrieu: so it's kind of off topic.
wip: ok. let delete
… second one seems similar
… so we'll update the PR to remove the two issues, but is Issue 38 still useful
wip: Yes, it's important, but should it be in the spec as such.
manu: yeah, we can just track it in the repo.
JoeAndrieu: I think we should say something about this. There is strong narrative assumption that this is always resolveable -- but that might not be possible... but there might be good reasons to not give access to it