DID Document Delivery Guarantees, Safety Semantics, and the Negative Externalities of a Network Partition

[wanderingbort]

During a live discussion of #950 we started talking about verifying documents that span multiple registries and the claim was that gatekeeper is responsible for resolving and verifying documents in these situations. After diving in to the code, I have a lot of questions.

Document Delivery Guarantees and Validity

I cannot find any great reference on what delivery guarantees (if any) hyperswarm topics have for the hyperswarm mediator BUT I suspect that the current satoshi mediator cannot provide any guarantee on when/if the network of gatekeeper nodes will receive the contents of a DID document. The on-chain representation is an OP_RETURN that encodes the DID of a batch document, within that batch document other DIDs are encoded directly(?). However, disclosure of that document to all connected peers has to occur via a different mediator and crucially may not occur. When importing a batch, the satoshi mediator ignores missing batch documents and continues forward, attempting to re-import it each iteration. As this batch may contain an UPDATE that conflicts with a future batch's update the validity of all DID documents registered via a satoshi mediator should be in question while any batch DID is unresolvable.

Understandably, changing this to a "halt and catch fire" case creates a trivial DoS attack where publishing a nonsensical DID to a satoshi-based ledger essentially destroys the networks ability to validate documents after a certain point in time.

As currently implemented, I believe there can be situations where two different gatekeeper nodes may produce conflicting "valid" DID document at the same logical point in time for a given DID. All it would take for this to occur is to have a disjoint set of batch DID documents between the two nodes. I believe this is possible but the exact mechanics may take manipulation of other sources of DID document data.

Safely Determining Validity

Given two gatekeeper nodes with disjoint batch document knowledge producing two different results for the same DID, what options do clients have for determining which is the safe response or if both are invalid?

It seems without running a full gatekeeper node and directly establishing that there is an unbroken chain of batch DIDs on the given Document's registry as well as an unbroken chain of events, a client cannot establish validity outright. Is that correct?

Negative Externalities of Multiple Distinct and Valid DID Documents

For this to be a significant issue, there would need to be some damage or impact from documents existing in these forms. Given that the update chain for any fork of a given document is self-validating, it seems like there is intent/consent of the documents controller. There is some exception for long-range attacks where compromising an older key could allow publication of an alternative update chain that dishonestly competes with a DID document BUT the protection against that is to simply broadcast your DID document updates.

As the "split brain" issue here only emerges with selective disclosure, it seems like honest actors will simply disclose or, in the case of a network partition, wait out any disruption so that they can get a consistent view of the network. Dishonest actors may be able to produce competing versions of their own documents BUT to what end?

Do we have any discussion on the potential downstream impacts of someone intentionally trying to publish competing versions of the same DID?

If we cannot determine any real attack scenario, maybe we can relax the expected semantics such that we consider these selective disclosure scenarios benign and advise clients to regard any validatable document associated with a DID to be valid even if there is another resolution of the DID that is inconsistent but also valid?