Using witnesses and protecting verifiers

[blelump]

Hey,

I'm having trouble finding clarity in the protocol. When performing DID resolution and obtaining the DID Document as the verifier, presuming it has witnesses, does the verifier contact the witnesses directly in any way, or does it merely fetch /did-witness.json and verify it?

[blelump]

From the verifier's perspective, it is sufficient to obtain a copy of did-witness.json and verify its contents. In this process, the verifier can always verify the contents of the DID Document alongside did-witness.json. However, this approach does not fully protect the verifier. Even though the contents may verify correctly at a time X, there is no guarantee that at a time X+n, the DID resolution will return the same version of the DID Document.

This vulnerability arises because a dishonest holder, in collaboration with dishonest witnesses, could alter the DID Document and create a new history. Such a change effectively makes the verifier unable to validate all the credentials issued before the alteration. It is important to note that the protocol remains valid in such scenarios – the altered history is still verifiable but now reflects different keys.

[blelump]

Furthermore, there is a lack of clarity regarding using weighted witnesses in the context of achieving distributed consensus. Adding weights to nodes typically accompanies a reputation-based algorithm that dynamically adjusts node weights. However, implementing such a mechanism requires a manager node to manage these adjustments.

On the other hand, the protocol proposes static weights for each node but does not evaluate how these weights provide additional protection for verifiers compared to relying on a sufficient number of proofs to meet the threshold (where each node is treated equally).

[swcurran]

Thanks for the questions and notes. Responses:

It is required by the specification that the DID Controller publish the witness proofs in the did-witness.json file beside the DID Log (did.json). With those two files, a verifier can verify the DID history -- without contacting the witnesses directly. Note that the specification is very clear to separate what is required by the DID Method (which is deliberately simple), and what governance an ecosystem might want to apply in using the witness capability.

You raised an important concern about potential vulnerabilities where dishonest controllers and witnesses could rewrite history. Here’s how this is addressed:

• Self-Certifying Identifier (SCID): The SCID embedded in the DID ensures that the genesis record of the DID cannot be altered without invalidating the identifier itself. Even in a scenario where malicious actors rewrite subsequent entries, the original genesis record remains cryptographically linked to the SCID.
• Historical DID Logs: Verifiers can retain copies of the DID Log retrieved at time X. By doing so, they can compare the entries retrieved at time X+n with their earlier copy, ensuring that the DID Log remains consistent and that no unauthorized changes have been introduced prior to time X. If inconsistencies are detected, the verifier can take appropriate action.
• Role of Watchers: While the specification does not explicitly define "watchers," (they do not have an active role in the DID Method) the watcher concept is compatible with the DID Method. Watchers are entities (or networks) trusted by verifiers to monitor DIDs for consistency over time, ensuring their integrity. They can also be used to improve DID access speeds, and to ensure DID resolution should the DID go away. Any verifier or group can operate watchers for a set of DIDs of interest.
• Mitigating Malicious Collusion: If the DID Controller, the publication mechanism, and all witnesses are malicious, it is true that they could rewrite the DID history after the genesis record. However, this risk is inherent to any system relying on trust-based entities. Verifiers must evaluate the governance and reputation of witnesses to assess the risk of such collusion. And as noted, the inclusion of optional watchers can provide a further layer of protection.

Regarding the weighting of witnesses. The specification provides an implementer with the tools achieve threshold consensus. How that gets used is up to the implementation and governance. For example, the witnesses and thresholds can be changed with each version of the DID (each entry in the log). Which witnesses are used, and what their relative weights are (such as based on reputation) could be implemented by a Manager Node that determines that anew for each DID entry. The specification does not have an opinion on how the thresholds are used for a given implementation, it just provides tools to use them.

[blelump]

Sure, the overall processes in the protocol are clearly described. Let's address the points I raised earlier:

• SCID does not protect the verifier beyond the first entry in the log. This means that additional log entries are vulnerable to being altered at any time, leaving the verifier unprotected. While watchers can address this issue, they are not mentioned in the protocol. Watchers are indeed use-case specific, but their role is crucial and deserves discussion. Watchers introduce additional complexity and raise questions about consensus among watchers, separate from the consensus within witnesses. Witnessing as a concept, therefore, requires careful analysis of the use case and may create ambiguities for implementers (FWIW, KERI faces similar challenges here). While the specification cannot and should not attempt to cover all edge cases, providing clarifications or guidance is essential. Including an informative section could help address this.

  Also note a dishonest WEB server is vulnerable to a similar problem. The WEB server acts as a watcher as it collects logs and proofs. Merely from such a WEB server, it's not possible to find out whether this is the first seen version of the log or a fork. As long as it verifies, it's correct from the protocol perspective. However, it does not protect the verifier.

• In Proof-of-Stake (PoS) protocols, weights are typically tied to the amount of stake (e.g., coins) a node contributes when voting on a new block. This creates strong economic incentives for honesty and a broad pool of participating nodes. However, in the witnessing concept, the incentives to be honest are any except economic, i.e., legal, reputational, or contractual, depending on the use case.

  Let's evaluate the example from the spec, where the threshold is 3, and nodes have the following weights:

  • Scenario 1: 2+1
  • Scenario 2: 1+1+1

  Which system is more secure? The latter (1+1+1). This is because compromising the node with weight 2 in the first scenario compromises the entire system, whereas, in the second scenario, the same level of compromise requires targeting multiple nodes. While this is just an example, it highlights an important conclusion: using weights may introduce more vulnerabilities than benefits in specific contexts. If the specification aims for clarity and unambiguity, the protocol should focus on protecting consumers in such cases rather than introducing additional options that produce ambiguity.

  Also note that nodes with higher weights are more attractive to compromise, especially if weight information is publicly accessible, as compromising such nodes has a higher impact on the system's integrity. In PoS systems, the large number of participating nodes and stake distribution mitigate this risk, leading to diminishing returns (which is not the case in the witnessing concept).

[swcurran]

I don’t think is quite right SCID does not protect the verifier beyond the first entry in the log.. The SCID within the DID allows verification of the first entry. It also contains the versionId which is the version number (1-, and incrementing per entry) and the entryHash derived from the hash of the first entry and including the SCID. Then the second entry’s versionId is derived from the second entry and the versionId of the first entry. Thus, each entry is linked to the previous entry, back to the SCID. See the section of the spec on the EntryHash generation and verification.

While I understand your comments on witnesses and thresholds, the exact configuration (number of witnesses, weights, threshold) of any particular did:webvh DID is up to its DID Controller, and by extension, the verifiers it must satisfy. The spec allows the witness configuration to be set as needed for the use case. The spec can’t/shouldn't constrain the witnesses to a single configuration.

[blelump]

SCIDs and verifier protection

Let me clarify the underlying issue. The protocol described in Section 3.7.3 and Section 3.6.3 is correct in that it generates the desired provenance log (or "microledger").

For further clarification, what I mean by verifier protection is that the underlying infrastructure is resistant (or immune) to various types of problems where the issuer claimed X at a time N. However, at the time N+x claims something different. Because a once-issued claim remains valid (potentially indefinitely), the infrastructure's primary role is to protect verifiers.

My statement about SCID not protecting the verifier arises from that such provenance logs are DAGs (directed acyclic graphs), meaning a single parent node can have multiple children. DAGs allow the creation of alternate histories or "forks" for a single SCID (see also our former work on microledgers that discusses DAGs.). Consequently, the verifier is not protected because it must rely solely on what the WEB server presents.

This problem can occur under two main conditions:

• Dishonest WEB server that becomes a single point of failure for the entire protocol. Note what's happening here: the WEB server acts as a watcher (it collects logs and proofs). One who controls the WEB server controls "the truth". Verifiers have no other way to protect themselves except to have their own watchers. While watchers solve it, technically, this is a significantly challenging problem, as discussed above.
• Dishonest Controller and dishonest witnesses. For example, in a scenario where the Controller and Witnesses operate within the same network and jurisdiction.

Also, note that the former problem with dishonest WEB servers evolves (but does not disappear) if you change the protocol and enable the querying of the witnesses. This enhances the verifiers protection; however, merely watchers ultimately give proper protection.

The protocol threshold and weights

Adding weights while making the protocol more flexible makes it more complex and fragile if not set up correctly. Given the infeasibility of achieving incentives similar to PoS protocols, keeping merely governance-based incentives (or responsibilities) doesn't offer proper protection for the verifiers. While there are endless ways of setting up weights within a governance use case, few are reasonable, i.e., as in PoS: you lose (you're dishonest), you pay for it. The other is where all weights are equal to the same number, whatever it is. It's because enforcing equality doesn't weaken the system's security, that is, by not incentivizing third parties to attack specific nodes with higher rewards.

FWIW: in KERI, merely the controller <-> witnesses relationship is regulated via pBFT and specifically via the threshold value. The protocol does not specify how to set up watchers and find a consensus among them. However, if a use-case has them or considers them, there's the same problem: finding a consensus in a distributed system (but now among watchers).