Support for multiple signatures

[lemoustachiste]

Hey,

So I was looking at how to support multiple signatures.

If the document is already signed, then the ecdsa-sd-2023 signature gets added to the document in an array of proof as expected.

However I see 2 issues:

• when both signatures are present on the original document, the first one will verify, but the ecdsa-sd-2023 will not because the document has not been derived, hence most likely creating a false negative in terms of validity
• if derived, the first signature gets dropped, so while the ecdsa-sd-2023 verifies, we have lost the knowledge of the first/previous signer.

I tried adding proof as a mandatory field and sign, but it gets dropped (https://github.com/digitalbazaar/jsonld-signatures/blob/main/lib/ProofSet.js#L57), at the moment of truth the proof property is not part of the signable document, hence it throws an error:

JSON pointer "/proof" does not match document.

I tried commenting out the delete instruction and was able to sign with I suppose the proof property as part of the ecdsa-sd signature value:

"proof": [
    {
      "type": "MerkleProof2019",
      "created": "2023-03-30T15:08:26.139158",
      "proofValue": "z4zvrPUULnHmaio2Q46Qert56PPkSCiQV6gSTM9uNxCUmxCkyXPgQ9faMYifYyQZcy6PrhpF9B6KiQTAybcsiwJZjskww5kNkthChkwqofzcRHgXHTxGtC8A377c3LLBLuBtHaSnSKjntwFafC47mXFsoKYnXNAc2ysTR9cbDtcmmZNugrq5pcZiTGVC2kYqW7iF7JAqrzitGk3TNfQbV77TJLoQkCfJGsUvWPBesiWyUMSdecDbKzXH2VEHvGxHNsd1NXGoBFdgGr6Tk4sDPRgTewNFZfLnxcvc5VZNiGZTHKza5EnrQxikhS1kvHXN8W7Ldvcr4eHTkj5R544UtLMzPjJyMWtHnbKP64GiWBj3AbBoauZ6JxHnS4xCU3uH6QbNjr3i3jTokJSy3nx",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://www.blockcerts.org/samples/3.0/issuer-blockcerts.json#key-1"
    },
    {
      "type": "DataIntegrityProof",
      "created": "2024-01-22T16:52:54Z",
      "verificationMethod": "did:key:zDnaebnVAPUfmM31cqEiju2GZo5MQFwhhuPiFXsiBPjzpvPvB#zDnaebnVAPUfmM31cqEiju2GZo5MQFwhhuPiFXsiBPjzpvPvB",
      "cryptosuite": "ecdsa-sd-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0AhVhAnnhRiiIJ7uL0ODKnZ0JYYV3ISW1yXjjbmYtoSET0TtzGvpkLQhBuOIuGFvJgeqt7epbn6YbPyVNw3Nw63NBb2FgjgCQDXG1mPbhsD-3aiBplVhYLso_IGEwjdU61teJ190i3-yxYIENtQLKlTV8B6DR89fmdosrbYOXToJJB0q02s-nE8B-ejVhAZh2S1pEGgwRJFcP4ADigKeMZxYDEaQ1wxJCA_K3bOode_O7DsnpTNUza_Liv2-qCxx6QWBKPAMEg4qm6HMBFglhABPuYkkJ4ABHsbnBItFVTtmHvjTRZ8JAauCbjVwDxeFhnp9bAO6f_hWETAwt7EAOobu3kPVpDtFHirU5P5w2TK1hAbONS4VkGiwaXqtJKocG87I-xCy6Kp9Tbh4aLfTWcOGKwWMq8z0Wk7n0Fz4Z5qF0gWR9jzYzXY579Y_Qo254Z4FhAykBTwYwD--rMXWyqVOhHGNQyoITCsM_vGqLTLD6RMtfHTi5zev1M_lxp9EkW3aunje2MSz9PM6pz3j_o4IH5blhAztuxMR2v1Y12_DtyIWojj307xmEr_bIDp7iqkb0c5ixgLXx2DQ8uV2E6G0nZH_aCc07GfEqSVRHWiGRDtSFvC1hATBmJqhpLDrNrfoGlIiwNzFAvAg0zjcVYNE5bn6tuBmp4wt3FJcITAl136I3LqcZJi68tIPFY0DXgyybwzapdwlhA5foP7b3f09NG2LwT4b2_KLLOlGKTr_TkJeANpk4TWQrRdLK2piEv_LPvmuFydDI6v6UFJw8bH2xR9Q2OvQnze1hAUUkVtYqP3im16yXTkSsgYnYsKp75vAmbWmYnchw1nZPHcCAJxEs-g2nO9S2iNXckR8yB6j751ZuGqBnRr90-PVhAVWdJyFEnA8ElQh7RNhBQy5sTufN_8Rm7dEIyf5W251cEj6ENrBZXp7r9uSHr-O1gjv6kaXYasD7HsVbtiAWZNFhAM9JR3iUCdhuCi77VcDGOCAgzHjUzW90-Q3yPzWzkquPaUgoa_P9ShEBeoW84z1WAAmc37KaI2W2JYJi1D0pU41hAXjZTU8R7dn2Smx3S2YMUaxR8og7pTRUGapHUYnV-11wonXB50uiIrQGvbUgMsgqmB4agxysRreMxf00bPgTrMVhAdXo6FwA0q0hc5v_-PtDT_c37PbbyNX2zUs2tu1QBcCPZp9ReSAzcYvQ_SK0RA2-RiBl3TNQLNmZRimB0gV2oWlhAwS3BzsZpoRULFxrNgcTNtqMka9T6XMgMd7y4JGrMIsqrFhbE5W83dNEXMKhcS9qTz9Hlxp3sZMeBWTe966LbJYNnL2lzc3Vlcm0vaXNzdWFuY2VEYXRlZi9wcm9vZg"
    }
  ]

At this point I tried to derive but again the same issue occurs (https://github.com/digitalbazaar/jsonld-signatures/blob/main/lib/ProofSet.js#L117). Commenting this out leads to another issue ( "labelMap" must be a Map of strings to strings.) which I didn't debug further.

Because anyway even if derivation worked, and the initial proof remained in the derived document, since it is now a subset of the initial document, the first signature wouldn't pass as the document has been "tempered with" in its computation.

So it looks an unsolvable problem. Was there any sort of talks on the subject, any context you could fill me with to get a broader understanding of what could be done alternatively?

[dlongley]

@lemoustachiste,

We're not aware of a use case where a derived VC that carries additional proofs is necessary.

Currently, the supported use cases involve having multiple proofs on a single VC that is stored in a digital wallet. This proof set is free to include N-many "traditional digital signature proofs" and M-many "base proofs" for selective disclosure / unlinkable-style VCs.

Then, at presentation time, a verifier indicates which cryptosuites they accept and the digital wallet (potentially with input from the user) selects one of the accepted cryptosuites and provides the VC using a proof that matches it. This will involve performing proof derivation at the time (if the mutually acceptable cryptosuite supports selective-disclosure).

There's no reason to presume that a selectively disclosed reveal document (VC with a derived proof using a particular cryptosuite) would continue to be compatible with any other proofs based on other cryptosuites. This isn't part of the design requirements for such cryptosuites -- and I imagine it would be quite challenging to make it so. For example, certainly a traditional digital signature proof would fail when any information in a VC is omitted during selective disclosure. Similar problems may occur with how selective disclosure is performed between different SD-style cryptosuites, depending on what they do. Current designs for any SD-style cryptosuite thankfully do not need to consider every other possible cryptosuite's approaches (including unknown prospective ones).

In short, there's no expectation that a derived proof would work in a proof set, nor is there any use case that I'm aware of where it would be needed. The derivation occurs once negotiation has already been performed to select a mutually acceptable cryptosuite to provide the security for a presented VC. Does this make sense -- and do you have some other use cases in mind?

If you are thinking of presentation of VCs "for the purpose of transfer" (i.e., simply moving VCs from one digital wallet to another), a digital wallet can get the consent of a user that the current request is for this purpose and include the VC(s) as they are (with their base proofs intact, performing no derivation). The recipient would also be aware of this. This is a special case of presentment, but it involves no derivation.