Handling DID resolution after a fork

[kdenhartog]

@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?

[brentzundel]

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 ***@***.***> 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 <#43>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPFKP4OVMRUM2ERWHW2TV3QH52GFANCNFSM4ITPHMFQ> .

[peacekeeper]

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?

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".

[burnburn]

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.

[wip-abramson]

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: !== did:bsvr:

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

[kdenhartog]

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.

[wip-abramson]

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.

[kdenhartog]

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)

[peacekeeper]

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.

[wip-abramson]

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.