New approach to recording/publishing Witnesses

[swcurran]

@andrewwhitehead proposed (in this HackMD Doc) a modified witness scheme. We summarized and discussed the document and approach at 2024-11-21 meeting and came to the following concensus:

1. Data model for the witnesses parameter remains the same (list of witnesses, threshold).
2. Instead of the witness proofs going into the log, they are stored in a separate file, witness.json -- an array of proofs from witness, including the DID Log entry version number (1, 2, ...) to which the proof applies. Or should it be the version_id?
3. The array contains only the last two proofs from each witness from which proofs are collected. When a witness proof is retrieved, if there are already two in the file from the witness, remove the oldest, and add the new one before writing the file.
4. The processing logic (excluding implementation details) is: Given an entry to be witnessed, verify that the witness.json file contains valid witness proofs from a threshold of current witnesses on the current or newer log entries.
5. Questions from the HackMD document and discussed on the call:
   1. Witness proofs can be published before the DID log with a new log entry is published. This eliminates the race condition of the DID Log being published without corresponding witness proofs. The "two proofs" per witness allows for the verification of at least one of the proofs of the witness when the witness.json is published before the corresponding log entry. The resolver would ignore the proof of an unpublished entry.
   2. What DID Method can a witness use? A long discussion ensued, with follow up in Signal. The consensus was that only did:key will be supported. A note should be added to the specification that a mechanism for establishing the identity/reputation of the witness is outside the scope of the specification. If implementers need that functionality, they must define how to do that, such as including the witness DIDs in a Trust Registry.
      1. By limiting the DID type of a witness, we can drop the line in the specification about "preventing an infinite loop in resolving witnesses with mutual witnesses".
      2. The discussion went into a tangential area about the use of keys in other than the latest DID. Given the resolution of not using did:webvh for witnesses, it is not relevant to this discussion, but is relevant in other contexts. We'll continue that discussion.
   3. NOT DISCUSSED: Should the addition of witnesses only be permitted in the first entry?
      1. I propose that it can be added at any time after establishing the DID. It need not be in the first record -- a DID Controller may decide to add that to a DID after using the DID for sometime, and should not have to migrate to a new DID with a new SCID just to activate the feature.
   4. NOT DISCUSSED: Is there a use case for turning off witnessing?
      1. I propose that it not be permitted. The DID Controller could (after getting "approval" from other witnesses) migrate to a simpler witness scheme (e.g. a single witness they control) to get (more or less) the same result. That said, perhaps going to no witnesses could be permitted (empty array as the value of witnesses parameter) provided the active witness for that record agree on the change. The witness.json file would still need to be present and verifiable for the versions of the DID that were witnessed.

[swcurran]

Please weigh in on the last two ("NOT DISCUSSED") items in the description above. I'd like to get a PR for this in BEFORE the next meeting (2024.12.05). That would set us up to agree on the 1.0 version of the spec for the next meeting after that.

[swcurran]

What should the exact data model of the witness.json file be?

Is this sufficient:

{
    [
       {
            "version_id": "1-dfdfsdfsf",
            "proof": { }
       },
       ...
   ]
}

The proof is over the DID Log Entry object, same as is the proof from the DID Controller. The verificationMethod of the proof is the did:key of the witness so I assume there is not a need to call that out as a separate item in the object.