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

[swcurran]

Re: Verifier protection

Assuming a separation between the DID Controller and the Web Server, the Dishonest Web Server can at most suppress the publication of the most recent update(s) to the DID (or remove the DID entirely). They cannot (without DID Controller and witness private key control) “create” DID entries to alter the DID. Such behaviour is evident to the DID Controller, and to verifiers that either cached the now suppressed entries or cannot find the public keys to verify signatures they are holding.

If you have a Dishonest Controller and Witnesses — where all the keys are compromised by an attacker, new entries into the DID Log can be created, assuming the attacker also authenticates to the Web Server serving the DIDs. This would be evident to the DID Controller (DID Log has “unexpected” entries).

Watchers run by individual verifiers or a consortium of verifiers can be used to make evident the first issue — an invalid truncation of the DID Log. The second — compromising all of the private keys and the Web Server is harder to recognize. A PQ attack is the biggest concern with that — an attacker being able to derive private keys by knowing a public key and signature. The pre-rotation of the DID Controller key is the primary mitigation against that.

Re: Witnesses and Thresholds

I agree that the defining the best way to manage witnesses is difficult, I still think that having the mechanism defined in the protocol, and leaving the deployment details left to the implementers is the best approach. The intention is that implementers will define and publish open source witness approaches.

That said — do you have a specific proposal for adjusting what goes into the specification around witnesses?

[blelump]

That said — do you have a specific proposal for adjusting what goes into the specification around witnesses?

Assumptions:

1. thinking of an identifier system with a key rotation mechanism presumes long-lasting identifiers and anything they can bring to an ecosystem. In other words, such an ecosystem knows why it needs long-lasting identifiers (it's also a burden).
2. A protocol built in such a sophisticated infrastructure of witnesses and watchers must primarily protect verifiers from being unable to verify at a later stage, potentially years after issuance. It's, therefore, critically important to design it in a way that it does its job.
3. The protocol doesn't leave open-ended questions unanswered, or otherwise, it leaves space for vulnerabilities.

That said, in no particular order:

1. If an ecosystem has identifiers with rotation, the best assumption is that they MUST be witnessed. The niche when they don't is a pure P2P system in which participants collect proof from themselves and build mutual trust using other reputation-based mechanics to justify whether collected proofs have value in such an ecosystem.

   In essence, if a use case wants long-lasting identifiers, it must pay for it.

2. The protocol should include BFT consensus or propose other (sub)protocols that unambiguously address this problem. There are plenty of variations of pBFT; however, the underlying threshold value must be tied to the number of honest nodes while accepting the total number of dishonest nodes. Therefore, the relationship between the threshold and the total number of nodes (witnesses) is bound in the protocol (or subprotocol).

3. Weights shall be entirely removed from the protocol.

4. A Web server is a kind of watcher and a single source of truth. The protocol does not specify how (or when) other watchers watch such a Web server. Therefore, to protect other watchers at any time in the future, other watchers shall primarily rely on the supporting infrastructure, that is, witnesses in this case.

5. add the first seen rule for any node, whether it is a witness or watcher (requires proper log semantics). It is to eliminate branches in the log.

6. while witnesses infrastructure must be unified and provisioned as a part of the protocol, watchers do not need to meet this requirement. This is because of issuing and collecting universal proofs across the whole ecosystem. However, Watchers merely collect these proofs and don't even need to validate them! Therefore (KERI) protocol doesn't impose any specific actions from watchers or doesn't even impose them (as in the G-case). In many cases, however, watchers will be essential, but adding them requires the next key point to be met. Nevertheless, the protocol should branch into the most viable cases: a. no watchers; b. watchers that collect and validate.

Last but not least, considering this infrastructure requires deep knowledge of the use case, its potential scale, and the underlying protocol supporting infrastructure that consists of witnesses and watchers. It requires proper provisioning hygiene. It's far from a plug-and-play system.

[swcurran]

Thanks. The majority of the proposals fall into the DID Controller / Witness handling/governance, which we've noted in the specification is being out of scope. I do see two (and I'll add a third) things in your proposals that are in scope, and that we plan on discussing at the next Work Item Meeting:

• The removal of the weights from the threshold algorithm.
• Providing a way for resolvers to directly contact witnesses -- notably to treat them as "watchers"
• (not really in your list) Provide a way for the DID Controller to identify watchers that have agreed to monitor the DID.

The problem with the last two are that they require some definition of a protocol (even if it is just a simple, defined HTTP endpoint) for a resolver to interact with the watchers. A proposal if we do want to add this support is to:

• Add an optional "watcherURL": <url> to the witness array item.
• Add a parameters "watchers": [ "<url>", "<url>",...]
• Define that an identified "Watcher URL" MUST respond to the HTTP URL <url>?didwebvh=<scid> with the currently help DID Log for that SCID.
• Define that when a new entry is added to the DID Log, the DID Controller must notify each defined watcher. The mechanism used to contact the watchers is out of scope of the protocol.

We plan to discuss this and other issues at the next did:webvh Work Item meeting -- Thursday, Feb, 13 at 9:00 Pacific / 18:00 Central Europe -- agenda and zoom info. Our hope at that meeting is to define anything that needs to change (if anything) before the v1.0 spec.

[blelump]

Thanks. The majority of the proposals fall into the DID Controller / Witness handling/governance, which we've noted in the specification is being out of scope.

The protocol allows for vulnerabilities precisely because the current version does not address BFT resistance (and it must be resistant). This is based on the assumption that there are no viable use cases where the absence of witnesses is an option (as noted in point 1). In other words, witnessing is mandatory for long-lived identifiers, which inherently require rotation mechanics. Furthermore, since the name of the DID method contains a vh suffix, rotation mechanics are implicitly part of the DID method behavior; otherwise, verifiable history would serve no purpose. In essence, if you need ephemeral identifiers, you should consider different DID methods.

From the implementor's perspective, eliminating open-ended questions is vital, and it's doable in both the case of BFT and mandatory witnesses.

• The removal of the weights from the threshold algorithm.
• Providing a way for resolvers to directly contact witnesses -- notably to treat them as "watchers"
• (not really in your list) Provide a way for the DID Controller to identify watchers that have agreed to monitor the DID.

The problem with the last two is that they require some definition of a protocol (even if it is just a simple, defined HTTP endpoint) for a resolver to interact with the watchers. A proposal if we do want to add this support is to:

• Add an optional "watcherURL": <url> to the witness array item.
• Add a parameters "watchers": [ "<url>", "<url>",...]
• Define that an identified "Watcher URL" MUST respond to the HTTP URL <url>?didwebvh=<scid> with the currently help DID Log for that SCID.
• Define that when a new entry is added to the DID Log, the DID Controller must notify each defined watcher. The mechanism used to contact the watchers is out of scope of the protocol.

• Yes, the protocol should not include how (and when) watchers contact witnesses for updates. This is a non-functional requirement that will vary depending on the scale of the use case.

• I'd be reluctant to define watchers as an identifier controller. If the identifier controller does this, it has no value. Watchers aren't under the Controller's control but under the verifiers' control. Allowing the Controller to set up watchers imposes watchers the Controller proposes, which contradicts the verifier's protection. Watchers in this ecosystem play the auditor role for verifiers, presuming no trust in what the Controller says. It's ultimately all about never trust, always verify, and while it'd verify from Watchers set up by the Controller, however, the incentives are entirely different.

  In practice, the verifier designates his watchers on his own. Note how it impacts the provisioning hygiene of witnesses and watchers and what can go wrong...

• by writing in point 6. 'a. no watchers; b. watchers that collect and validate.` I meant to define their behavior, that is, if there are watchers:

  • they MUST follow the same verification protocol as the witnesses
  • they MUST implement the first seen rule (or otherwise you allow for branches). The other topic is that the same applies to witnesses (point 5 above).

We plan to discuss this and other issues at the next did:webvh Work Item meeting -- Thursday, Feb, 13 at 9:00 Pacific / 18:00 Central Europe -- agenda and zoom info.

Thanks. It's quite challenging for me to join at this time, but I will try to manage.

[blelump]

Further evaluation of the threshold:

1. Given an identifier with 0 witnesses and prerotation: true.
   • It behaves like a peer-to-peer exchange. The WEB server is used merely for high availability.
   • Watchers' existence in the current protocol version does not change anything.
2. Given an identifier with 1 witnesses, threshold 1 and prerotation: true.
   • Ultimately, no consensus based. No information redundancy: vulnerable to DDOS and malfunction / single point of failure.
   • Unless the witness is another BFT system under the hood, such as a blockchain (the protocol doesn't consider blockchain), it is impossible to ensure correctness and liveness.
   • Verifiers dependent on a centralized system.
   • Watchers' existence in the current protocol version does not change anything.
3. Given an identifier with 2 witnesses, threshold 1 and prerotation: true.
   • No quorum in the case witness W1 is witnessing a history and witness W2 is witnessing alternate history. Watchers and verifiers are unable to verify which history of the log is correct.
   • Watchers' existence in the current protocol version does not change anything.
4. Given an identifier with 2 witnesses, threshold 2 and prerotation: true.
   • Not fault tolerant.
   • Due to malfunction or DDOS may halt the protocol to go forward.
5. Given an identifier with 3 witnesses, threshold 1 and prerotation: true.
   • No consensus required, a dishonest controller may publish 3 alternate histories.
   • Watchers' existence in the current protocol version does not change anything.
6. Given an identifier with 3 witnesses, threshold 2 and prerotation: true.
   • If the controller is honest, the protocol guarantees correctness and liveness.
   • If the controller is dishonest so that it creates m1 and m1' (presuming genesis log m0 is already published with proofs), signs both logs, and now sends m1 => W1, W2 and m1' => W1, W3. W1 signs both m1 and m1'. It's at this stage undefined behavior, that is, whether m1 or m1' will be considered as the next log entry. To just give an example of what can be behind m1 and m1': m1 can be a rescue mission of the real owner of the identifier, and the m1' is the malicious party trying to take ownership.

It can go further...

In most cases above, the verifier/watcher has no protection against dishonest controllers, and also, as explained, the primary role of such a system is to protect verifiers. In essence, to ensure the protocol provides either one agreement or none at all.

The dishonest controller's problem is the primary problem in any PKI-based infrastructure where private keys have been exposed to a malicious party. From the current identifier owner perspective, it's critical to be able to rotate from compromised keys, and from the verifier perspective, it's critical to be able to verify but also anchor trust. Ultimately, these systems are all about enabling trust distribution.

All that said, the protocol leaves a lot of space for vulnerabilities, leaving the protocol consumers unaware of these problems.

edit: it's vital to include the WEB server (dis)honesty in this evaluation. Being now the bottleneck, it can, on its own, impact the content of identifier logs (i.e., by purposely excluding the tail of the log) as well as be the target of impersonation via DNS Hijacking.

[swcurran]

Per the February 27, 2025 meeting (agenda), we've decided to add Watchers to the specification. In simple terms, the DID Controller can add a list of URLs to the DID Log of watchers. Watchers are web servers that respond to a list of endpoints to either return their cached copies of DID data, or notifications from the DID Controller that updates have been made to the DID. The notifications are webhooks, and the watcher would get the data. A watcher could support other features/endpoints, and of course -- anyone else can monitor a DID and serve as a watcher without their URL being published in the log or being notified about updates to the DID.

As with other features, there is no requirement for how the watchers are to be used -- that's up to clients using the DID.

See PR #180 . The PR is still being discussed -- at minimum, the endpoints as they are currently in the PR will likely. change.

As to your note, above -- I think that could go onto the did:webvh information site with some context.

Agree that the security assessment would look at all of the components controller, web server, witnesses, and watchers and the potential impact if a combination of them are malicious/compromised. For example, as you note, a malicious web server could suppress the tail entries of the logs, but could not generate entries without other compromises. The result would likely be "annoying" -- signatures failing (the impact of which is relative) and would be likely detectable.