Note: I'm opening an issue here as there seems to be a plan to phase out digitalbazaar/jsonld-signatures#178, but the problem we're facing concerns both libraries.

After having fixed an issue with jcs-based proofs not verifying properly in jsonld-signatures a few months back (digitalbazaar/jsonld-signatures#176), I want to circle back to the issue of adding context definitions to the document and proof before signature generation. My concern is that the current praxis of altering @context properties during proof generation and verification may simply not be viable for proof mechanisms that directly sign the json representation of linked data.
Specifically, I see two issues:

1. Adding a proof (suite) specific context to the document can invalidate pre-existing proofs. This praxis is adopted both in this library as well as in jsonld-signatures. Adding, for the purpose of supporting a wider range of verifiers, a Ed25519Signature2020 to a document that has already been signed with a DataIntegrityProof using eddsa-jcs-2022 will alter the document, after which the eddsa-jcs-2022 suite will no longer verify the existing proof.

2. Adding the document context prior to signing and verification, as done in this library and, inconsistently (only on verification), in jsonld-signatures seems to be at odds with the prescribed proof configuration of existing jcs based cryptosuite specifications authored by Digital Bazaar (https://www.w3.org/TR/vc-di-eddsa/#eddsa-jcs-2022 & https://www.w3.org/TR/vc-di-ecdsa/#proof-configuration-ecdsa-jcs-2019). Even though this behaviour can be patched for digitalbazaar/data-integrity by reimplementing createVerifyData in your cryptosuite, jsonld-signature's behaviour will break verification in this case, which leads into a dilemma where implementing the specs correctly actually harms interoperability between implementations.

I'm hoping to start a thread here to discuss improvements that can be made to the way this is handled.
To kick this off, I can throw in two suggestions:

• Problem 1) could be solved by no longer requiring a proof/suite context to be present on the signed document; instead, this context could be added to the proof object where the document context does not already include it. From what I can see this model would continue to assure that all terms are defined and definitions are not redeclared.
• Problem 2) is probably easiest solved by aligning the proof configuration of jcs based cryptosuites with that of linked data proofs / rdf-based suites. Adding the document context to the proof object prior to canonicalization has no function for jcs-based proof schemes, but allows interoperability with the existing tooling without substantial changes to it.