Implement ProofChain Class

[aljones15]

File:

https://github.com/digitalbazaar/jsonld-signatures/blob/a636acd31bd9fdd0488c9e50a3e1a39500a2ce8a/lib/ProofChain.js

Specification:
https://w3c-ccg.github.io/ld-proofs/#proof-chains

A proof chain is useful when the same data needs to be signed by multiple entities and the order of when the proofs occurred matters, such as in the case of a notary counter-signing a proof that had been created on a document. A proof chain, where order needs to be preserved, is represented by associating an ordered list of proofs with the proofChain key in a document.

The major difference between a proofChain and a proofSet is that in a proofChain order matters.

[Exulansis]

Is this feature still planned for development? I would be interested in using (or implementing a simple version of this) for a use case we are currently working on.

Related to this feature, I am not entirely certain how proofChains can be used with the VC data model (due to the issue is outlined here).

Thank you!

[dlongley]

I think the concept of how proof chains would be implemented has changed from being a new property to being a new type of proof, for example ChainedProof. A chained proof would still be attached to a document under proof but it would (details TBD by the inventor) include information about other proofs on the document that would create the chain. So it likely would no longer be a core feature of this library, but rather be a special proof type itself that could make use of existing suites in some way. This approach would be compatible with the VC data model.

We're more than happy for people to experiment with what this would look like via actual implementations! We'd expect the implementation to be a plugin to this library in the same way other LD proof suites are.

[Exulansis]

I posted a comment / update in the referenced issue to this extent, but thought I'd share it here as well.

I tried to define (perhaps to some extent naively), an initial design for the new ChainedProof Linked Data Proof type, partially based on the suggestions / inputs provided above. The document is still in flux, although the core ideas / principles are there already (nonetheless, sections 2.2.1 and 2.2.2 could use a bit of work to make them more approachable, at the moment they are a bit dense / terse).

The document can be found here.

It would be great to receive some feedback, specifically on whether this is moving into the right direction, but also on any identified design issues / unclarities / alternatives, etc.

Thank you!