Explain concept of two types of proofs in the log

[swcurran]

In example 1 (the basic data model), the event object and the proof array are separate, but in examples 4 and 5 (use cases) the proof is in the event object. It's not clear why that is.

Perhaps the event is intended to have a proof itself, and the parallel proof array are an optional set of witness proofs, that are not used in the examples?

[swcurran]

Just looked closer at Example 10, and I see that the there is both a proof in the event, and after -- the witnesses. So I think I was just missing that concept when reading the spec.

[msporny]

Yes, there are at least two levels of proofs. One for the witnesses and one for the operations in the event. They serve two very different purposes:

The proofs in the operations establish that the data controller approved of a change (by cryptographically signing the change/operation).

The proofs beside the even establish that a witness is witnessing all of it (the hash of the event + operation + data).

We should add text to the specification that notes that the proofs at each level are to prove different things.

[swcurran]

FYI — in the webvh DID Method there are also two types of keys — that of the DID Controller and those of the witnesses.

• Unlike in Example 10 in this CEL spec, the public key for the proof on the operations is NOT in the DIDDoc (although it can be there as well). It MUST be in a list in the parameters (metadata) of the DID entry (called updateKeys). A DID Controller may want to use the same key in the DIDDoc so that it can be used for other purposes — signing other things — but they do not have to.
• The parameters also holds a list of the did:key DIDs for the witnesses, and the weight of each witness. The Log Entries must be signed by a threshold of witnesses that verify (well defined) and “approve” (undefined — up to an implementation) of a new Entry. It is also out of scope of the specification to define who the witnesses are — who controls the various did:key DIDs. If that is important for an ecosystem — they can figure out how to bind the DID to the entity (e.g. with a Trust Registry).
• The proofs for the witnesses, as of the next version of the did:webhv spec, are outside the DID Log, in a separate file. Further, only the last witness proof of a published DID Log entry is retained. A witness proof on a given entry implies all previous DID Entries are approved by the witness. This allows for minimizing the number of witness proofs that need to be verified. Thus, the witness file (did-witness.json) must be rewritten each time.