How order of signatures is ensured using ld-signatures?

[Drabiv]

When there are multiple signatures on a document, it is often important to have a proof of the order of signing. For example, signature of a notary, signifies that notary witnessed signing of a document by signer.

How is order of signatures ensured, prooved when using ld-signatures? There is a section about signature chains - https://w3c-dvcg.github.io/ld-signatures/#signature-chains, but it is not clear to me how to verify that the order of signatures was not changed?
Does the signature value of 2nd signature made by signing hash made of Message + 1st signature?

What is the algorithm to place signatures in order and to verify order of signatures?

[msporny]

Does the signature value of 2nd signature made by signing hash made of Message + 1st signature?

Yes, the first signature is included in the normalized data that is hashed and signed by the 2nd signature.

What is the algorithm to place signatures in order and to verify order of signatures?

It's basically a for loop that starts with the array of signatures. The algorithm then creates an object containing only the first signatures, then verifies it. If the signature is valid, it adds the second signature, then verifies it... and so on until all signatures in the chain are verified. Every subsequent signature verifies that the previous signature was included in the signature.

[Drabiv]

Thanks @msporny, that clarifies it.
I have a follow up question. When there are 3 and more signatures, then there are many ways in which signatures may have been put. How is this handled?
For example, if there are 3 signatures, the 3rd signature may have signed "Message+Sig#1+Sig#2" or it may have signed "Message+Sig#1" or "Message+Sig#2". Is there a way to convey what signatures has been signed by the signature?

[msporny]

if there are 3 signatures, the 3rd signature may have signed "Message+Sig#1+Sig#2" or it may have signed "Message+Sig#1" or "Message+Sig#2". Is there a way to convey what signatures has been signed by the signature?

Note that we're changing the spec to use "proof" instead of "signature". I'll be using the "proof" language below.

If the signatures reside in "proof" array, then the assumption is that it's a set of signatures and NO signature was included in the hash of the other signatures. If the signatures reside in a "proofChain" array, then the assumption is that every previous signature was included in the current signature.

At present, there is no way to mix and match certain signatures counter-signing other signatures. We just don't have a popular use case for such a thing.

[Drabiv]

@msporny thanks, that's clear now.

[msporny]

Re-opening as I don't think the spec is clear on this and we don't specify the algorithms I outline above. The reference implementations do this, I think, but the spec should state it clearly as well.

[cwebber]

Indeed, I was just looking today for the text... the spec currently introduces signature chains and signature sets but does not describe either of them. It seems that the behavior both in signing and in verifying in both cases is a bit different depending on whether signature chain or signature set is selected, so we should probably write language for both.

[msporny]

The spec has been updated to mention proof sets and chains here:

https://w3c.github.io/vc-data-integrity/#proofs

... but the algorithms still don't mention how to generate/verify them:

https://w3c.github.io/vc-data-integrity/#algorithms

We still need spec text updates, but at this point, it's clear what the spec text should be.

[msporny]

There has been some fairly significant re-work and finalization of the algorithms used in the specification since this issue was raised. There is now text that details how adding proofs and verifying proofs works (in general):

• Add Proof: https://www.w3.org/TR/vc-data-integrity/#add-proof
• Verify Proof: https://www.w3.org/TR/vc-data-integrity/#verify-proof

These general algorithms are then further refined in each cryptosuite specification:

• EdDSA cryptosuite: https://www.w3.org/TR/vc-di-eddsa/#eddsa-2022
• ECDSA cryptosuite: https://www.w3.org/TR/vc-di-ecdsa/#ecdsa-2019

... which contain enough detail now to specify exactly what is signed, and in what order.

That said, we still need to normatively specify the algorithm for verifying a proof chain, which is fairly straightforward. There is a new property called previousProof that 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). If you have 3 signatures that were made in order A, B, and C. 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". If you get a single verification failure in the proof chain, the entire chain after the failure is invalid and a verification failure is returned.

Once the algorithm for proof chain verification is incorporated into the specification, this issue will be closed. This issue is ready for a PR to be raised to address the issue.

[Wind4Greg]

Hi all and especially authors and editors. I'm working for a PR on this and for completeness it seems we need to include some text on Add Proof Set, Add Proof Chain and corresponding Verify Proof Set and Verify Proof Chain. There are two main choices to adding this text to the Algorithms section:

Choice #1 as sections:

1. Add Proof
2. Add Proof Set (uses Add Proof algorithm)
3. Add Proof Chain (uses Add Proof algorithm)
4. Verify Proof
5. Verify Proof Set (uses Verify Proof algorithm)
6. Verify Proof Chain (uses Verify Proof algorithm)
7. Retrieve Verification Method

Choice #2 as subsections of add/verify:

1. Add Proof
   1.1 Add Proof Set (uses Add Proof algorithm)
   1.2 Add Proof Chain (uses Add Proof algorithm)
2. Verify Proof
   2.1 Verify Proof Set (uses Verify Proof algorithm)
   2.2 Verify Proof Chain (uses Verify Proof algorithm)
3. Retrieve Verification Method

Or some other variant. Let me know I'll be working on the raw text and if I don't hear anything with use the first choice.

[msporny]

PR #121 has been merged to address this issue, closing.