Closed simibac closed 3 years ago
Yes, when you are using did:ethr:0xpubKey
(without network specifier), then in the case of a fork, 2 different DIDs would emerge.
The dilemma of where the DIDs belong will be faced by all apps currently on mainnet, not just this one, so there is an assumption of continuation of at least one of the DIDs.
Of course, the DID that is anchored on the fork would not be able to use credentials that refer to the original.
In case there is no consensus as to which fork is "mainnet", I suppose that an adjustment can be made to the DID resolver and the spec, disallowing did:ethr
without a network specifier. In that case, signatures issued by these DIDs would be considered invalid.
If you wish to be certain that the DID won't be forked, you can use a chainID to begin with. Instead of did:ethr:0xpubKey
you would use did:ethr:0x1:0xpubKey
.
The registry of known networks and their corresponding deployments of the ERC1056 is at https://github.com/uport-project/ethr-did-registry#contract-deployments
Please close this if this answers your question.
In the case of a Ethereum hard fork, the DIDs registered exist on both chains. However, Is my assumption correct, that this will not result in data inconsistencies, since the DID method of the forked network would be different?
did:ethr
would continue to exist as before the fork. A new DID method such asdid:ethr:fork
would emerge and would resolve these new types of DIDs. Verifiable Credentials linked to theethr:did
only work with the original version of DID. However, who decides which fork can continue to exist under the DID methodethr:did
? In my eyes this would be the developers of the DID resolver. Is that correct?If an issuer has security concern and does not agree that the Ethereum DID resolver now supports the latest changes on the network, does this mean, that the issuer must revoke all previously issued credentials and issue new ones on the forked network?
I could not find any good resources on that. Any help is appreciated.