Idea: Cryptographic claims

It would be amazing if I could attach any number of "claims" to a document, using digital signatures.

Use cases include:

1. Approving a document
2. Confirming an invoice as paid
3. Accepting a set of rules
4. Confirming the metadata of a document could be done as a claim
5. …

Fundamentally, a digital signature is made by encrypting a payload with the private key of a keypair. The payload in this case would consist of a hash of the document data, as well a statement, the "claim". The result is a statement that includes information about who made the claim, and when. Should the subject of a claim (the document) change, then the claim is no longer valid for the changed version (but remains valid for the original).

As documents do not change once they've been uploaded to Docspell, it might be sufficient to use the document ID instead of computing the hash of the data. However, having the document data hash available in the database might actually prove useful, for other cases too.

Considerations have to be made over the extent of a signature/claim:

1. Is it file-based? By which I mean attachments. Or is it document-based? In this case, the payload would need to include all documents, and a claim would be invalidated if parts of the document were added or removed.
4. What metadata should be included in the claim? Generally, I tend to assume that metadata should not be part of a claim (after all, the data are "meta"), but this needs to be looked into.

It would be good if there were different types of claim, i.e. an approval claim, and a confirmation claim, etc.. That way, claims can be nicely categorised/presented, and an optional comments field made truly optional.

From a UI perspective, claims can be treated similarly to tags, except they might also have a comment that could be accessible e.g. on hover or click-to-expand. Verifying claims could also easily be done by the UI, either by requesting the signer's public key from the database, or by using an API call `verify_claim`. Obviously, the UI needs to make the screen bleed if a verification fails.

Making a claim could either be a frontend or a backend operation. I would stay away from requiring the users to maintain key pairs outside of the browser, and even using persistent storage in the browser may cause problems when browsers are switched, multiple machines are in use, etc.. However, if it's a frontend operation, something like [OpenGPG.js](https://openpgpjs.org/) would be the way to go.

Instead, however, I think it would be worth considering making claims a backened operation, with the key material stored in the database, and encrypted using a passphrase derived from the login passphrase or some OIDC datum.

Storing claims would probably be best done in a separate table. For now, I think only documents need to be subjects, so the table would include document ID and the digital signature (binary data), and probably also user and timestamp, even though these are part of the signature, but this way searches and sorting can be done by the database. Also, a "failed" boolean might be useful, which, if set, invalidates the row and spares us from having to verify again.

The API endpoint `make_claim` would take a subject and user authorization, and generate the claim by signing on behalf of the user, storing the digital signature in the database, and returning success, or a reference to it.

Finally, claims should also be searchable, i.e. "give me all documents which Martin approved" or "show me the invoices that have been paid".

Obviously, this will not be audit-proof because a malicious admin could intercept the passphrase and decrypt the key, thus making claims in the name of others, but I reckon that's a bridge to cross then. The API could be extended to return the payload and a transaction ID, and asynchronously expect a signature from the user for the given transaction, before storing the claim. This way, the key material wouldn't leave the user's machine.