did-resolution
did-resolution copied to clipboard
w3c
Handling DID resolution after a distributed system fork
@jandrieu raised an interesting question at RWoT that we want to consider in the resolution specification.
Let's assume this scenario:
Alice has DID:btcr:12345 that exists pre-fork.
Later on the network which btcr operates on forks into two separate forks.
How should the resolver dereference the "definitive" DID Document?
Should we take into account a fork matrix parameter or modify the identifier to account for the fork such as did:btcr:12345 -> did:btcr:fork1:12345?
My understanding is that the DID method specifies the network to be used for resolution. So if the network forks, it would be up to the DID method to specify which fork holds the "one true DID doc"
On Wed, Sep 4, 2019 at 2:59 AM Kyle Den Hartog [email protected] wrote:
@jandrieu https://github.com/jandrieu raised an interesting question at RWoT that we want to consider in the resolution specification.
Let's assume this scenario:
Alice has DID:btcr:12345 that exists pre-fork. Later on the network which btcr operates on forks into two separate forks.
How should the resolver dereference the "definitive" DID Document?
Should we take into account a fork matrix parameter or modify the identifier to account for the fork such as did:btcr:12345 -> did:btcr:fork1:12345?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-resolution/issues/43?email_source=notifications&email_token=ACPFKP44PHJ4FDH4TGXENQDQH52GFA5CNFSM4ITPHMF2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HJGA2DQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACPFKP4OVMRUM2ERWHW2TV3QH52GFANCNFSM4ITPHMFQ .
Should we take into account a
forkmatrix parameter or modify the identifier to account for the fork such asdid:btcr:12345->did:btcr:fork1:12345?
I think modifying the identifier would most likely be a bad idea. If we use a matrix parameter, then it should probably be method-specific. Its value should somehow indicate which fork to work on, e.g. by providing a block hash that is expected at a certain block height.
Maybe something like did:btcr:xz35-jznz-q6mr-7q6;btcr:block-123456=ae676e00.
Of course if that parameter isn't present, then as @brentzundel says the method would be responsible to somehow figure out what is the "true DID doc".
Note that at an earlier IIW forking came up as one of many different potential DID infrastructure failures that need to be considered. See https://github.com/windley/IIW_homepage/raw/gh-pages/assets/proceedings/IIWXXVIII_Book_of_Proceedings_2019A.pdf page 89. This list might be a good starting point for such discussions.
I am not sure this is something that the resolution spec needs to address.
To me, DID Methods specify the VDR / VDRs that they operate over.
In the case of btcr that is the Bitcoin blockchain (or its testnets), with the nodes operating the network determining the valid set of blocks. While forks are possible, they are unlikely to be long lived. The fork with the most hash power will be able to produce the most blocks and will considered the Bitcoin blockchain.
In the case of the Bitcoin blockchain forking into a different network, as it has done many times (e.g. https://www.bitcoinsv.com/), then this should be considered a new VDR and not part of the btcr DID method.
Someone may come along and fork the btcr method to bsvr and change the VDR to BSV for example. Then btcr identifiers that existed before the fork on Bitcoin might become valid bsvr identifiers. But only if presented as did:bsvr:
However, did:btcr:
I am not sure if we need to add anything in the resolution specification to address this?
Perhaps in DID core something like: DID Methods should disambiguate the VDR they are using in the case of forks
In the case of the Bitcoin blockchain forking into a different network, as it has done many times (e.g. bitcoinsv.com), then this should be considered a new VDR and not part of the btcr DID method.
It's unlikely that you can always make a determination about which VDR will be the one best associated with the method after a fork. For example, ETH followed the forked code after the DAO hack where as BTC has typically followed the unforked code (there are instances where this isn't the case such as intentional hard forks that are well accepted).
In this case, this suggests the method author needs to update the spec and resolvers need to follow the updated spec to define which chain is linked to the method and which one needs to have a new method produced for it. This likely means the resolver spec itself doesn't need to define how to do this, but the method specs should do this. In which case you'll likely need some text in this resolution spec defining how that should be done and what requirements are needed to errata a defined method in order update the registry entry.
It's unlikely that you can always make a determination about which VDR will be the one best associated with the method after a fork. For example, ETH followed the forked code after the DAO hack where as BTC has typically followed the unforked code (there are instances where this isn't the case such as intentional hard forks that are well accepted).
But in both these cases isn't it always clear which fork is the Bitcoin or Ethereum network as determined by those networks and the processes that sustain them? I would say it is those processes that make the determination about which fork is valid for the network.
But in both these cases isn't it always clear which fork is the Bitcoin or Ethereum network as determined by those networks and the processes that sustain them
Not always and those operate at a social consensus layer which still needs to be translated into a technical change in some cases (such as pointing at a new RPC node to resolve from)
I propose that we add a subsection under "Security Considerations" to explain that this can problem can theoretically exist, depending on the nature of the DID method. And we can provide a summary of the potential ways to address this problem that were discussed in this thread, such as introducing a DID parameter, or creating a new DID method (or new sub-division of the method-specific identifier) for a forked VDR.
That makes sense to me.
@kdenhartog's comment made me wonder if method specifications relying on VDRs should be encouraged to more precisely identify these VDRs.
For example, the BTCR method just says it is based on the Bitcoin blockchain and expects everyone to know what that means. Which for the most part is fine, but maybe there are situations where it isn't always clear.
This was discussed during the #did meeting on 15 May 2025.
View the transcript
w3c/did-resolution#43
Handling DID resolution after a fork #43
wip: we labelled this a security.... how does a did method spec identify the VDR...
manu: feels like it is language that depends on the specific did mehtod... since it seems to address forks....
manu: we may not want to generalize forks....
markus_sabadello: yes agree, seems like the concept of networks, some did methods do not have that....
markus_sabadello: if at some point multiple did methods care about forks, some parameters or extensions could be added later...
During discussion in today's DID WG meeting, there was consensus that while this is a legitimate concern, it feels mostly method-specific and should be covered in DID method specs, and/or possibly in extension DID parameters or metadata properties that can be registered in DID Resolution Extensions.
Unless anyone expresses other opinions, we'll soon mark this issue pending-close.
Punting on this problem to method spec authors doesn't seem like a good idea given how many methods failed to address basics like privacy or security considerations. The impact here is that people will continue to struggle to be able to identify good methods from bad ones which I'd expect will further limit the adoption of DIDs used specifically for key management use cases.
I can understand why the WG is taking the position here, but I personally think it's another step in the wrong direction. It just keeps kicking the can down the road to allow anyone to register a low quality method, rather than setting useful requirements which will produce higher quality methods that can actually be used by browsers, wallets, and other downstream software.
Hi @kdenhartog as fellow in the blockchain industry I understand where you are coming from. I would also agree with some of the earlier comments about the social layer aspects of blockchain network forks. Typically these forks end up in the birth of 2 competing networks which may or may not be permanent (eth vs. eth classic, bitcoin vs. bitcoinsv, etc.). Whilst it is a valid security concern I also see this as being very specific to blockchain based did methods as pointed out by Manu and Markus during our call.
Would adding something like the following under the "Security Considerations" section in DID Core address your concern?
VDR Network Forks: DID Methods that utilize VDRs of distributed systems as (such as distributed ledgers or other distributed systems) need to manage the potential for network forks taking place. DID Methods SHOULD disambiguate the VDR they are using in the case of such forks by either:
- maintaining a mapping of the method-specific-id subdivisions to the various VDRs
- Adding a new did parameter to specify which VDR is being used when network forks occur
I think it would also be worth inviting the opinion of @ankurdotb and @tweeddalex from the Cheqd team, to give their opinion on this issue.
In practice, the security section is ignored by method author specs. This means that there's no direct way to determine if resolution is accurate based simply on the URI. This would undermine any cryptographic infrastructure built on top of DIDs and limits the overall potential of DIDs unless we intentionally want a long tail of methods where a select few are supported by most resolvers.
Obviously this isn't something that can be perfect because each method has its own unique characteristics. For example, KERI encountered one of the first social "forks" in the community. That was an example of a non-technical non-blockchain related fork which had an impact on downstream consumers of the method. So, what I see as a resolution to this is a way to notify in the registry that a fork has occurred and establish a way to determine how to handle it to recognize them as independent through registry requirements.
I don't believe there will ever be a great solution to this problem, but I do think leaving this to method authors is insufficient given how many low quality methods there are.
Furthermore, allowing for low quality methods to remain pervasive hurts all methods as it becomes harder for consumers of DIDs to remain interoperable and certain that they'll get a similar set of properties from one DID method to the next. Hence, why I think this is a bad idea to punt on this to method authors who've already demonstrated they will typically only meet the lowest minimum to register their method which is set by the registry requirements. And even when there are substantial efforts to build quality methods like what KERI was doing, it can still lead to conflicts which require some way to address it or risk seeing people leaving DIDs behind all together.
It's a great question and I can't think of too many clean solutions, besides the suggestion made by @ottomorac. While I do think the idea of a method-specific-namespace -> actual VDR mapping in the method might help, most blockchains are open source: which in practice means anyone could create a fork/different VDR (indeed, many do for test purposes), without the knowledge of the DID method spec author.
On this point: if there's a fork, there is no guarantee that the fork would maintain DID Docs, i.e., it's not a given that did:btcr:12345 -> did:btcr:fork1:12345 always happens. The reason why the fork is created might, in fact, be specifically to ditch the DID Doc functionality. Even if retained, a fork doesn't need to maintain existing DID Docs. (There are actual parallels for this in many VDRs, not just blockchain-specific ones.)
The questions for me break down to:
- Does the fork retain 1:1 compatibility in terms of functionality for DID Documents, or does it have different functionality?
- If different, is it backwards-compatible with the original method, or a breaking change?
- Will the fork retain historical DIDs, or only new ones going forward? (Forks can ditch the previous state/history, or retain it.)
- Is the fork a clean rebrand or wants to/contends for the title of being a canonical fork? E.g., OpenOffice vs LibreOffice are completely different brands and projects; Ethereum vs Ethereum Classic are different, but more contentious.
Given these nuances, there might be other forms of social consensus instead we could rely on:
- When there is a fork of a running/active chain, there's typically a generally-considered successor that might be obvious after some time passes. Ethereum mainnet vs Ethereum Classic, Bitcoin forks etc come to mind, where there was a clear successor in number of nodes, volume, users etc. (That said, I appreciate there are contentious discussions going on Bitcoin community right now that could lead to a less-clean fork/fracture, where the successor isn't clear)
- In practical terms, resolution software (and I don't just mean Universal Resolver) has configuration that specifies a certain VDR to fetch the details from. There's nothing to prevent a developer from configuring a resolution software to fetch from a different VDR than social consensus (e.g., if someone running a private Ethereum chain decides that
did:ethrshould resolve to a different RPC endpoint than mainnet). So that scenario cannot be prevented currently anyway. Instead, I'd say social consensus comes from projects like Universal Resolver, i.e., what's the commonly-configured VDR a particular method fetches records from? This will remain true even for forks. - A fork that retains DID Documents, including existing DID Documents, could then register either a different method name (e.g.,
did:ethrclassic) or retain the existing method name but use a different namespace (e.g., did:ethr:classic - like the original post suggests). In that case, social consensus via well-known resolution software is the best possible way to answer the question of what's canonical, since this name space / which VDR is linked to, would need to be configured in resolution software. (Example: if the method was Bitcoin-based, is the VDR source from the commonly accepted successor, or the RPC endpoints of a different fork?)
I agree with @kdenhartog that even though this is method-specific, it could still be useful to include language in the DID Resolution spec itself. I like @ottomorac 's proposed language as a start. Anyone willing to write a PR for this?
You can assign the issue to me Markus, I am happy to take a stab at the PR. The question we should perhaps debate in the WG next time we discuss this is whether this belongs in the DID resolution spec, DID core or both. 🤔. I saw @wip-abramson leaning a bit towards DID core in earlier comments.
We probably need both. DID Core changes would be useful for setting registry requirements around who can notify of fork, how forks will be handled at a process level for Method registries, etc.
Then from there your text on how it impacts resolution in security is also useful. Additionally, text around resolvers being able to indicate they know of a fork and the fork has a different DID doc might be useful addition for this. This way resolvers can help alert downstream consumers to potential impacts based on the results of the resolution.
This was discussed during the #did meeting on 22 May 2025.
View the transcript
DID Resolution Issue: Handling DID resolution after a distributed system fork
<ottomorac> w3c/
Summary: Agreed on some of the complex aspects of distributed system forks. General direction is we should add an item on security considerations. Question now is if it should be on did-core or did-resolution or both?
ottomorac Kyle's comment suggest it belongs in both
markus_sabadello one a recent call we said that this should be up to DID Methods. It could be mentioned within DID Resolution. Doesn't need to be added to DID Core. Not so much about the data model and the identifier, just the resolution
<JoeAndrieu> +1 to is being resolution if anywhere
tweeddalex: +1 as well
@peacekeeper just saw your comments. If did-resolution can set requirements on methods for the spec registries, then I agree did-resolution is a better place for this. My current impression though is that this is restricted to DID Core, is that correct?
Also, we should probably account for "versioning" forks. For example, if I change a version of a method such that the output of the document changes, this also will have an impact on downstream software. did:peer is one such example of a method which closely resembles this, but accounted for it within the URI itself: https://identity.foundation/peer-did-method-spec/#generation-method