Add VDR forks Security consideration

[ottomorac]

Added security consideration for VDR forks in order to address https://github.com/w3c/did-resolution/issues/43

---

Preview | Diff

[w3cbot]

This was discussed during the #did meeting on 29 May 2025.

View the transcript

w3c/did-resolution#155

<manu> dmitriz, to error check the returned DID Document, to ensure it's well-formed from a JSON-LD perspective.

ottomorac: On this one, I can help with specific wording on the forks to address issue 143 from Kyle. I added a few ways in which it may be disambiguated.
… The part we need clarification on is that a DID resolver that is aware of such a fork should inform the user that the fork can affect the resolution results.

Wip: Kyle was pretty adamant that he wanted some changes. My feeling is that some of this should be in the DID core specification.

<dmitriz> manu -- that still doesn't seem like the Resolver's area of concern. (but the consumer's)

manu: I'm also on the fence on whether we should say anything or not. It's a pretty extreme corner case.
… The DID method should probably state what to do when there's a network fork. I don't think this should go on the specification. We should punt what to do to the DID method specification itself.
… We should say that what to do in the event of a fork is to consult the DID method specification.
… The suggestion is to minimize the PR.

Wip: Do you think if we did a 2.0 in future that it should not be in the DID Resolution spec?

manu: Yes. We should probably move it but we can't make class 4 changes right now.

ottomorac: I think I can say yes, the DID methods should be able to handle that. We are likely to get pushback from Kyle if we say nothing.

<TallTed> can we make a note of that intent, in the current doc, so that it's more likely to be remembered?

manu: We all know and love Kyle but we don't have to do everything it wants. What we should say is that we don't give generalized guidance in the specification as there's no way to cover everything.
… We're presuming that there's just two branches, whereas some have the ability to look across all the forks and merge them. I don't think we can speak with authority on what you should do.

Wip: Could this be made a point in the security considerations section?

ottomorac: Yes, I could minimize it for that.

---

[ottomorac]

Update after wg discussion on 29-may to remove the guidance and indicate that did methods should manage the disambiguation of the VDR forks in the corresponding did method spec.

[wip-abramson]

This looks good, although I wonder about the SHOULD.

To me the DID Resolution spec should be placing requirements on implementations of DID Resolvers and Dereferencers. Not DID Methods.

Also, could you split the line to be ~ < 80 chars

[ottomorac]

This looks good, although I wonder about the SHOULD.

To me the DID Resolution spec should be placing requirements on implementations of DID Resolvers and Dereferencers.

This one is tricky because the did method is the one that should specify how to disambiguate the VDR network fork. Wondering then if this will require a change in both specs:

1. In DID core spec: to indicate DID methods should specify how to disambiguate VDR network forks
2. In DID resolution spec: to indicate that DID resolvers should follow the did method spec on how to disambiguate VDR network forks (although to me that sounds like a super generic statement if I am being honest).

Let us take it up in the next regular call to see what is the group consensus.

Also, could you split the line to be ~ < 80 chars

Thanks, done.

[peacekeeper]

Merging after approvals and suggestions applied.