Should the witness proofs be put into the DID Log?

[swcurran]

From @stormer78

Would be faster and easier as one file to retrieve and keep full witness history in the one file? No need to remove previous proofs as I could see for auditing purposes others may want to see witness proofs if retrieving a specific ID or representation at point in time.

As you don't publish the DID LogEntry until you have confirmed the witness proofs, it works to streamline and combine them.

Option A: Proofs are part of a LogEntry itself
Option B: each line in the file can be either a LogEntry or a ProofEntry (which would contain the witness proofs) for the entry above. Easy to deserialize into the correct format and then it comes down to a client side decision if they want to check every witness proof, or if they just test the latest LogEntry and ensure the witness proofs match.

I can't think of how the above would lower the security posture of webvh, if anything full witness history makes it more robust than trying to piece together point in time state with missing data.

Bytes are cheap... Running some scale tests, curious to see how it performs when there are hundreds or thousands of log entries - may parallel implement a few options and provide some data on performance aspects.

[swcurran]

Good point -- we did initially consider having the witness proofs in the DID Log Entry. I think the best way to do that would be to have a proof set, where the DID Controller and the witnesses each sign the entry, and the set of proofs are an array in the proof element.

After working on that basis for a bit, a decision was made that it would be better to have the separate file. And once we had the separate file, the idea of only keeping the most recent proof from each witness against a published Entry, plus all proofs against unpublished entries was defined.

Implementors -- do you think it would be helpful to reopen this issue? @brianorwhatever @andrewwhitehead @AlexanderShenshin

[stormer78]

This is probably the biggest pain point in the spec, it is introducing a lot of complexity (parallel processing), needing to stitch together two different states (did.jsonl and witness proofs). Opens up to silly internet issues like CDN cache not being updated with correct versions at the same time and causing failed resolutions if witness file isn't delivered correctly at the exact time the did.jsonl is updated (it still happens out there).

The single benefit from this approach to the client/resolver side that I can see is:

• You save on some bytes in the did.jsonl by being able to optimise proofs in the did-witness.json file.
• Maybe a performance advantage by dual loading in parallel the two files

bytes are cheap, and will be compressed (hopefully) on service implementations

I don't see a benefit to the controller side either. Any production web service is going to manage state and export an approved output when checks are completed.

Would strongly advocate a simpler and more durable/available implementation to merge witness proofs into the LogEntry.

[swcurran]

Comments from other implementors? Would love to get feedback in prep for the next did:webvh meeting.

[AlexanderShenshin]

I agree that it makes sense to reopen this topic.
Moving away from managing two different files would definitely reduce complexity and it's always a good thing.

Regarding specific approach, I think that both are good enough with Option A (proofs are part of a LogEntry itself) being a bit more convenient.