proofChain property violates VC data model requirement

[Fak3]

The VC data model states: When embedding a proof, the proof property MUST be used.

But the LD-proofs spec introduces new keyword proofChain: 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.

I wonder if it is possible to align the LD-proofs spec with VC data model.

The first possible solution that comes to mind is to introduce new ProofChain type and a proofChain property which could be used like this:

"proof": {
  "type": "ProofChain",
  "proofChain": [
     {... proof1 ...},
     {... proof2 ...},
  ]
}

Is there any better way to make proof chain conformant with VC data model?

[Exulansis]

Bumped into the same issue. Is there any way to help move this forward? Being able to support multiple ordered signatures on a credential unlocks a number of interesting use cases.

If my understanding is correct, "Proof Sets" are already supported (since multiple proofs are allowed). Unfortunately that does not suffice for some use cases.

[dmitrizagidulin]

@Exulansis - great question.
I'll include @dlongley's jsigs issue reply here, for reference

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.

So, basically, I'm reading it as "help wanted". I think the next steps would be something like:

• Let's sketch out a preliminary design here, in this issue.
• I can help create a @context for the ChainedProof suite.
• Let's see if anyone implements it :)

[Exulansis]

Thank you @dmitrizagidulin and @dlongley for your answers and offered help!

Sorry for the slow replies, juggling a few things at the moment. But still quite interested in sketching out some preliminary designs here.

To reiterate, some of the initial ideas / requirements are:

The proof type can be, e.g. ChainedProof
Seems pretty straight forward / makes sense. By extension, I assume a ProofSet proof type could be defined at some later point as well. Section 9 of the current specification states that at minimum a new proof type is expected to have an id, type, canonicalizationAlgorithm, digestAlgorithm, and proofAlgorithm. It seems like most of these are not applicable to the ChainedProof type. Therefore some guidance and help on how to define and register the type is welcome (once we have settled on the design of course).

A chained proof includes information / references other proofs on the document
Also seems reasonable. I assume a property (e.g. chainEntries, chainedProofs, etc.) is included in the proof, which references other proof entries. Some questions on this point are:

• How should the other proof entries be referenced in the ChainedProof? It does not seem like the individual Linked Data Proof entries must have associated id fields. Perhaps there are other ways to uniquely reference a specific entry from the proof array.
• Could the verificationMethod property be used to list the relevant proofs, or is it reserved for referencing key material?

Further assumptions:

• The ChainedProof proof will have a proofPurpose property, which depends on the inteded usage (e.g. assertionMethod)
  • Should all proofs referenced by the ChainedProof entry have the same proofPurpose? What are some evaluation rules here?
• The ChainedProof proof type will include no digital signatures, only reference other proof entries (which do include signatures). I am uncertain about this point. It would be useful for this entry to be signed, so that for instance the order of the signatures that make up the ChainedProof can not modified by a holder (which would result in the ChainedProof failing verification). On the other hand I am not entirely sure what key material should be used to generate this signature.

I hope to spend a bit more time on this issue in the coming days, and will hopefully be able to post some (most likely naive) further potential ideas.

[cowboy-bebug]

Could EXAMPLE 4 be updated with the proofChain property as well here (once the chained proof spec gets more ironed out)?

[Exulansis]

Hey everyone!

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, perhaps from @dmitrizagidulin, @dlongley, specifically on whether this is moving into the right direction, but also on any identified design issues / unclarities / alternatives, etc.

Of course nothing is set in stone yet, and both the design (as well as naming for the various properties / suite itself) can be updated based on feedback.

If there is a better place / way to present and discus this idea, as well as gather feedback, please let me know and I'll take the necessary steps.

Thank you in advance!

[lemoustachiste]

Thanks @Exulansis for your work. I'm facing the business requirement of having chained proof and I think this is quite a good start.

I tend to agree with you that we need a better identifying mechanism of the previous proof (and I suppose adding an id to the proof would be the most convenient way), but for the sake of conciseness, could using CBOR encoding or hashing of the previous proof be on the table?

[lemoustachiste]

Hi @msporny,

following yesterday's presentation during the CCG call, I am confused with the status of this work item.

More specifically, I am facing a use case where using the proofChain property makes sense (sequential multiple signing). With the conversation going on here and a comment I read from you on one the CCG mailing list, it seemed that proofChain property has little to no chance to make it in the final spec.

But in yesterday's presentation, the sequential signing slide was referencing proofChain.

Could you please clarify what is the official stance so I can align accordingly? For now I have settled on a hybrid solution where I am using proof but the signing order is implicitly sequential (thus each signature signs the previous one too).

Thanks a lot

[msporny]

@lemoustachiste wrote:

For now I have settled on a hybrid solution where I am using proof but the signing order is implicitly sequential (thus each signature signs the previous one too).

That is dangerous because the proof value is a set in the data model, not an array. This means that order is not guaranteed and different implementations might easily swap the order of the proofs in the array (and still be compliant with the specification). While I understand you're doing this as a temporary thing, I just thought I'd warn you about the dangers of this approach.

Could you please clarify what is the official stance so I can align accordingly

The proofChain property is defined in the Data Integrity specification (was: Linked Data Proofs): https://w3c-ccg.github.io/data-integrity-spec/#proof-chains

That specification is slated to be standardized in the VC Working Group 2.0 (under the verifiable data integrity work): https://w3c.github.io/vc-wg-charter/#deliverables

I expect that many implementations don't support proofChain yet, mostly because it's for more advanced use cases that the ecosystem hasn't necessarily had the need to solve just yet. That's not to say it's not valuable, it is, but it's not as high of a priority as many other things in the ecosystem. We expect this to change when the VC Working Group 2.0 starts up in a couple of months. It may take up to 2 years to standardize the feature.

Hope that helps, @lemoustachiste. :)

[Exulansis]

Thank you for the overview @msporny.

We have been encountering an increasing number of such, more advanced, use cases. Because there's no clear way to accomplish the feature given the current specs, In many cases we end up simplifying / re-framing the use case to avoid relying on this functionality. I think as soon as soon as this feature / functionality is better documented, we will see many use cases building on top of it.

The path forward you described (i.e. relying on the proofChain property + VC 2.0 specification) makes sense in the longer run (although still leaves some design questions open, e.g. how to include 2 proof chains, or have a chain of proof which forks at some point / has multiple "tips" [might very well be outside of the scope], and probably others).

In my current understanding, the approach we proposed in this issue (described in this previously linked doc) is complementary and to some extent orthogonal to the path forward you described. I.e. we could still continue maturing and iterating on the new proposed Data Integrity Proof Type (i.e. ChainedProof2021), while the VC 2.0 / Data Integrity spec are further developed to account for this feature / requirement. Eventually the ChainedProof proof type could be deprecated, in favor of approaches based on the proofChain property.

Hope my assumptions / understanding is correct, but in case it isn't (or I am missing something), any feedback / corrections would be appreciated!

[msporny]

Hope my assumptions / understanding is correct, but in case it isn't (or I am missing something), any feedback / corrections would be appreciated!

One of the things the new Data Integrity (renamed from Linked Data Proofs/Signatures) work does is ensure that people can continue to experiment and refine in parallel instead of being gated by an "official" W3C/IETF Working Group. It does lead to a messier/more chaotic landscape during the pre-standardization phase, but some of us view that as better than some very small handful of people from large tech companies dictating what the world should do.

So yes, innovate away, we can converge later if it makes sense. The more experiments we run before standardization, the better.

[lemoustachiste]

Hi @Exulansis,

so I've been spending a bit more time on the question and I think your proposal for the time being would be the most in line with what we are trying to achieve.

I am wondering what is the state of work there, if you have some code available, if you are open to collaboration on the subject, etc?

Thanks

[vongohren]

Just chiming in here and figuring how I can help?

There have been a repo doing exactly this: https://github.com/mattrglobal/jsonld-signatures-bbs/blob/master/sample/ts-node/src/demo_multi.ts, but its not working with later versions. And probably not following any standards

Also a slack message on DIF on tihs: https://difdn.slack.com/archives/C4X50SNUX/p1651490478563459

I was wondering, can one just order the proofs and have that signature flow as stated in the workaround, just consequently signing things? Its not optimal.

I was suggested just to add another issuer to get things to work now, but that is really not compliant with the w3c spec.

[vongohren]

Im following up with a nice repro that we can work with to find a balance of what how to do multi issuance https://github.com/vongohren/verify-issues

This can now issue multi signature VCs, in the most simple format, and it verifies with low level library, because it does not check the context of the VC.

But what are the issues or problems of getting this to work with the higher levels? Is it to make sure the chain is defined as mentioned in this topic?

Any meetings or anything this issue is being discussed?

[lemoustachiste]

I have done a simple implementation of ChainedProof2021 in python here: https://github.com/blockchain-certificates/cert-issuer/pull/232/files#diff-d123b32a844527612bcfe9e7dcf295bed57cbdf610c0a9f8da253ea10d3546f3 (still in PR)

And some tests describing the behavior here: https://github.com/blockchain-certificates/cert-issuer/pull/232/files#diff-8690e98af00dae98fbb87b457f1ab9edaea0c42524527f738c376955932b3f81

This is all executed with the MerkleProof2019 signature suite because that's the only signature suite supported by our issuer, but I've made it so that it is agnostic to the type.

I have also made a context for ChainedProof2021 which I use locally at this moment. It's basically a copy of the Ed25519 context (https://w3id.org/security/suites/ed25519-2020/v1), where I have added chainedProofType and previousProof.

I find the repetition of data a bit annoying, here is for instance and RDF normalization:

<did:example:ebfeb1f712ebc6f1c276e12ec21> <https://schema.org/claim> _:c14n8 .\n
<did:example:ebfeb1f712ebc6f1c276e12ec21> <https://schema.org/email> "[email protected]" .\n
<did:example:ebfeb1f712ebc6f1c276e12ec21> <https://schema.org/name> "Julien Fraichot" .\n
<did:example:ebfeb1f712ebc6f1c276e12ec21> <https://w3id.org/security#publicKey> "ecdsa-koblitz-pubkey:1BPQXndcz5Uf3qZQkgnvJC87LUD5n7a2mC" .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/blockcerts#BlockcertsCredential> .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://w3id.org/blockcerts#display> _:c14n6 .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://w3id.org/blockcerts#metadata> "{\\"classOf\\":\\"2021\\"}" .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://w3id.org/security#proof> _:c14n0 .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://w3id.org/security#proof> _:c14n2 .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://w3id.org/security#proof> _:c14n3 .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:ebfeb1f712ebc6f1c276e12ec21> .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://www.w3.org/2018/credentials#issuanceDate> "2022-05-02T16:36:22.915Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .\n
<urn:uuid:bbba8553-8ec1-445f-82c9-a57251dd731c> <https://www.w3.org/2018/credentials#issuer> <did:key:z6MkjHnntGvtLjwfAMHWTAXXGJHhVL3DPtaT9BHmyTjWpjqs> .\n
_:c14n1 <http://purl.org/dc/terms/created> "2022-05-03T12:23:08.253777"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n3 .\n
_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#ChainedProof2021> _:c14n3 .\n
_:c14n1 <https://w3id.org/security#previousProof> _:c14n5 _:c14n3 .\n
_:c14n1 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n3 .\n
_:c14n1 <https://w3id.org/security#proofValue> "zMcm4LfQFUZkWZxsqgMCu3yEGxPV2tYrTARWyAfLFLwKnmDBH2GTspFkacosEJbPkMmT2oGJYf9eNHhASDbRxatHSYXTAwiqkz4i19aKZ7tfShQGDAqtb6YTJLqVUGTR3XTka2BvoUs6F7RaC8DjUK9nXFxMaVSFqBUVcMEuF55XJe25WQT9FfMptGxRkYf7qNSukfQkuDkVb2fHakpUAfyNBjv3tTG5413tyAhWdSSNEBaBuEaXzsKcCuwgundh5w3yjdQaxSThGJhzFdP29n9v9K8cFy1CFMgntagaQwKkJjqcT5q"^^<https://w3id.org/security#multibase> _:c14n3 .\n
_:c14n1 <https://w3id.org/security#verificationMethod> <did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ#key-1> _:c14n3 .\n
_:c14n4 <http://purl.org/dc/terms/created> "2022-05-03T12:23:08.253777"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n2 .\n
_:c14n4 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#MerkleProof2019> _:c14n2 .\n
_:c14n4 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n2 .\n
_:c14n4 <https://w3id.org/security#proofValue> "zMcm4LfQFUZkWZxsqgMCu3yEGxPV2tYrTARWyAfLFLwKnmDBH2GTspFkacosEJbPkMmT2oGJYf9eNHhASDbRxatHSYXTAwiqkz4i19aKZ7tfShQGDAqtb6YTJLqVUGTR3XTka2BvoUs6F7RaC8DjUK9nXFxMaVSFqBUVcMEuF55XJe25WQT9FfMptGxRkYf7qNSukfQkuDkVb2fHakpUAfyNBjv3tTG5413tyAhWdSSNEBaBuEaXzsKcCuwgundh5w3yjdQaxSThGJhzFdP29n9v9K8cFy1CFMgntagaQwKkJjqcT5q"^^<https://w3id.org/security#multibase> _:c14n2 .\n
_:c14n4 <https://w3id.org/security#verificationMethod> <did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ#key-1> _:c14n2 .\n
_:c14n5 <http://purl.org/dc/terms/created> "2022-05-02T16:36:22.933Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n3 .\n
_:c14n5 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519Signature2020> _:c14n3 .\n
_:c14n5 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n3 .\n
_:c14n5 <https://w3id.org/security#proofValue> "zAvFt59599JweBZ4zPP6Ge8LhKgECtBvDRmjG5VQbgEkPCiyMcM9QAPanJgSCs6RRGcKu96qNpfmpe9eTygpFZP6"^^<https://w3id.org/security#multibase> _:c14n3 .\n
_:c14n5 <https://w3id.org/security#verificationMethod> <did:key:z6MkjHnntGvtLjwfAMHWTAXXGJHhVL3DPtaT9BHmyTjWpjqs#z6MkjHnntGvtLjwfAMHWTAXXGJHhVL3DPtaT9BHmyTjWpjqs> _:c14n3 .\n
_:c14n6 <https://w3id.org/blockcerts#content> "<div style=\\"background-color:transparent;padding:6px;display:inline-flex;align-items:center;flex-direction:column\\"><style>*{line-height:initial}</style><div>Yo</div></div>" .\n
_:c14n6 <https://w3id.org/blockcerts#contentMediaType> "text/html" .\n
_:c14n7 <http://purl.org/dc/terms/created> "2022-05-10T09:38:32.772394"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n2 .\n
_:c14n7 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#ChainedProof2021> _:c14n2 .\n
_:c14n7 <https://w3id.org/security#previousProof> _:c14n4 _:c14n2 .\n
_:c14n7 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n2 .\n
_:c14n7 <https://w3id.org/security#proofValue> "zjmftMSn1dDpJFXKdrEhwHv7BYKYSJArqwgPEM9QKB4NB2rA6hQXWNkjnuFAip3jCtZG1KZre7UuME9FYdhort2bKWwPbGWPeAEt7LAQTDvrTJwZEzyeGEGDT7UNxtCDopMLJhXHSEcnnCNtBwubMLfLFXnhe19TZTSbxKnkc7UF8WKyKXGvU7iLgwTNkRNLZn82te1QMcJBatfXQ9H3CSexGbYcouozx6ebq9wYufUhvFUYqmzA"^^<https://w3id.org/security#multibase> _:c14n2 .\n
_:c14n7 <https://w3id.org/security#verificationMethod> <did:ion:EiA_Z6LQILbB2zj_eVrqfQ2xDm4HNqeJUw5Kj2Z7bFOOeQ#key-1> _:c14n2 .\n
_:c14n8 <https://schema.org/description> "Awarded to those who rock" .\n
_:c14n8 <https://schema.org/name> "Master of Puppets" .\n
_:c14n9 <http://purl.org/dc/terms/created> "2022-05-02T16:36:22.933Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n0 .\n
_:c14n9 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#Ed25519Signature2020> _:c14n0 .\n
_:c14n9 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n0 .\n
_:c14n9 <https://w3id.org/security#proofValue> "zAvFt59599JweBZ4zPP6Ge8LhKgECtBvDRmjG5VQbgEkPCiyMcM9QAPanJgSCs6RRGcKu96qNpfmpe9eTygpFZP6"^^<https://w3id.org/security#multibase> _:c14n0 .\n
_:c14n9 <https://w3id.org/security#verificationMethod> <did:key:z6MkjHnntGvtLjwfAMHWTAXXGJHhVL3DPtaT9BHmyTjWpjqs#z6MkjHnntGvtLjwfAMHWTAXXGJHhVL3DPtaT9BHmyTjWpjqs> _:c14n0 .\n

Since we are referencing the whole proof as previousProof, the data gets duplicated. I am wondering what could be a better way (id reference? hashing of the previous proof object?).

I am going to look at the verification side of things now

[lemoustachiste]

I have defined a context for ChainedProof2021 as part of the implementation in Blockcerts.

After discussion with @msporny I will open a PR in the w3id security perma-id repo to define this URL: https://w3id.org/security/suites/chained-2021/v1. Please advise if you prefer another URL.

@dmitrizagidulin as you proposed in another comment, do you mind taking a look at the context definition? https://github.com/blockchain-certificates/cert-schema/pull/43/files#diff-6e646b5b2499d851c911f125d859e55a971e430937613ce4773294e155dbdb00. I am improving on my jsonld skills but they are still trial and error.

Thanks

[georgepadayatti]

https://github.com/blockchain-certificates/cert-issuer/pull/232/files#diff-d123b32a844527612bcfe9e7dcf295bed57cbdf610c0a9f8da253ea10d3546f3

Question,

Why do we need to have a previousProof field, from the type isn't it understood, the second proof is counter-sign of the previous ? The proofChain can retain order, since it is a "@container":"@list".

[vongohren]

Just a question, proofChains usescases, when there are multiple entities/people who want to leave a proof(signature) on a piece of data?

Searching for use cases inside this issue, I cannot really find a clear example. It would help me understand the value and context of this issue.

[msporny]

Why do we need to have a previousProof field, from the type isn't it understood, the second proof is counter-sign of the previous ? The proofChain can retain order, since it is a "@container":"@list".

Correct, we don't need a previousProof field... proofChain retains proper ordering and each signature in the list signs over the previous signature.

[msporny]

Just a question, proofChains usescases, when there are multiple entities/people who want to leave a proof(signature) on a piece of data? Searching for use cases inside this issue, I cannot really find a clear example. It would help me understand the value and context of this issue.

Notarization is a prevalent use case in many market verticals: https://en.wikipedia.org/wiki/Notary

[lemoustachiste]

I have just implemented the proposal as it was, but I never really liked the verbosity that previousProof generated, so actually I prefer that we remove it too.
Indeed thinking about it since the next proof hashes over the previous one, that feels like it's sufficient at this point. At least I cannot come up with a counter point.

[dlongley]

Another option to support "proof chains" could be to add whatever properties we need to the vocabulary to allow a proof to reference other proofs and/or the digestMultibases of other proofs, and this information would be covered by the signature. Then any cryptosuite spec could indicate an identifier for a cryptosuite that uses this capability.

[msporny]

I wonder if it is possible to align the LD-proofs spec with VC data model.

This has been done now. We have removed the proofChain property and a new property called previousProof has been added to a proof object. You can read more about the property here:

https://www.w3.org/TR/vc-data-integrity/#proof-chains

The way previousProof works is simple. If you find a proof that has previousProof, you find that object (by id) in the proof array and you verify it (and so on up the chain). You verify in A->B->C order (verifying the top-most proof in the chain first and so on down the chain). If you can verify all proofs in the proof chain, the entire proof chain is "verified".

Given that this issue was raised to resolve the fact that proofChain violated the VC Data Model, and given that it's been removed, I'm marking this issue as pending close. It will be closed after 7 days if there are no objections.

[lemoustachiste]

@msporny just to clarify something, are my assumptions correct:

• when signing with a proof set, each signature only signs the document independently (proof excluded)
• when signing with a proof chain, each signature signs the document up to the preceding proof?

[msporny]

@lemoustachiste wrote:

• when signing with a proof set, each signature only signs the document independently (proof excluded)

Yes, correct.

• when signing with a proof chain, each signature signs the document up to the preceding proof?

Yes, correct.

You got it. :)

[lemoustachiste]

@msporny is this a valid VC use case, and if so what is the best approach to it:

2 spouses sign an official document (proof set) and a notary signs over them to certify the validity of the signed document (proof chain). In that case how do we represent the previous proof? Does the spec allow for a sort of mix and match of the 2 types?

[msporny]

@lemoustachiste wrote:

2 spouses sign an official document (proof set) and a notary signs over them to certify the validity of the signed document (proof chain). In that case how do we represent the previous proof? Does the spec allow for a sort of mix and match of the 2 types?

Yes, here's how it would work:

1. Both spouses sign the official document, separately, as a proof set.
2. The notary then adds two signatures, each containing a previousProof property pointing to one of the spouse's signatures.

One alternative here is that we allow previousProof to be an array, at which point the notary would just create one extra proof with previousProof set to an array containing each spouse's proof. There's a complexity trade-off here... either we push more complexity into previousProof, or we keep it simple, at only being able to point to one previous proof. That said, it doesn't seem that much more complex to allow previousProof to have two values.

Interested in feedback from folks on whether we should allow previousProof to have more than one value.

[lemoustachiste]

Thanks Manu, it makes sense. In my opinion I think it might be easier to specify an array of previous proofs that were signed, rather than multiplying signatures on a 1 to 1 basis.

The reason for that is I think it would be easier to parse the proof object and isolate the proofs that were signed by the proof chain, remove the non relevant one(s) and verify the document once, rather than getting the proofs, noticing one is a proof chain, removing non relevant proofs and verifying the document n times as necessary (ie: a succession with 8 inheritors).

Also should there be a limit to the proof set/proof chain depth. Let's get a bit more cocky with the initial example, 2 couples have to sign one document, each with their notary vouching for their signatures, but an extra judicial entity signs the document as valid encompassing all signatures (or just the notary ones). I suppose it's an extreme edge case but I'm wondering if the spec should mention something about it (it might be better suited to use a verifiable presentation, but technically, what does prevent such an approach?).

Last but not least, I couldn't find the vocabulary for previousProof either in https://www.w3.org/ns/data-integrity/v1 or in https://www.w3.org/2018/credentials/v1. Is there a common context that defines the property or should implementors of proof chains specify the property themselves?

[msporny]

Also should there be a limit to the proof set/proof chain depth

This concern is being tracked in issue #87

I think it might be easier to specify an array of previous proofs that were signed, rather than multiplying signatures on a 1 to 1 basis.

Ok, I agree, we'll make the change in the spec.

I couldn't find the vocabulary for previousProof

Yes, it's a relatively new change and we were waiting for community feedback before we set it in stone. It sounds like there's support to go this direction, so we'll add it to the https://www.w3.org/ns/data-integrity/v1 and https://www.w3.org/ns/credentials/v2 contexts.

Given that this issue is closed, I've opened a new issue to track that concern and make sure the change is made in issue #120