I'm not doing any rust programming, so my answer will remain abstract and not specific to lopdf.
First I ensure that the signed document is an incremental update over the reference document, that is easy.
It is indeed true that many signing services and programs add their signature in one or more incremental updates. But there also are exceptions, e.g. Adobe Acrobat usually uses a full save when signing, creating a single-revision PDF in which objects may be re-ordered and renumbered, streams may be re-compressed, some direct objects may have become indirect and vice versa, etc. EXCEPT, that is, if the original document already declares itself signed! In that case Adobe also applies incremental updates.
Thus, if you can arrange for the documents you send to the user to be signed (e.g. with a certification or with a usage rights signature), then your approach is ok. Otherwise you had better reconsider and be prepared for signed versions of your document that internally look completely different.
The hard part is ensuring that the contents haven't changed. For that, I think it is enough to compare the xref table between the different increments, and see if the only objects added are related to the signature itself.
This may prove more difficult than you make it sound:
On one hand there may be quite a lot of allowed changes that one might not think of as "related to the signature itself," e.g. changes in metadata (Info dictionary and metadata streams), changes in the structure tree for tagged PDFs, changes in default resources and appearances of the form data, developer extensions, ...
On the other hand some PDF processors add equivalent copies of some existing objects in the incremental update; e.g. PDFBox before version 3 used to only detected new/changed objects to add in the incremental update if also a sequence of objects starting with the catalog leading to the new/changed object was also added, like catalog->pages->page->annots if a signature field widget is added to a page to provide a visualization of the signature.
Also depending on the characteristics of a signature added, quite a lot of extra payload may be there. E.g. if someone signs using a PAdES-LTA signature this may mean adding up to two document time stamps (in their own signature fields) and validation related information in the PDF digital security store.
Am I right? Is there any chance of manipulating the rendered contents of the document in an incremental update without updating the xref table? What care should I take when comparing the xref tables?
Well, you may want to take a look at https://www.pdf-insecurity.org/ to get an idea about some tricks one could still use some years ago to fool a PDF validator into thinking that the changes one applied to a signed PDF were allowed changes. Think these techniques improved over the recent years...
Similar techniques may be applied in your case.
What kind of objects should be whitelisted?
See above for some ideas. And be prepared to have to look closely at the actual changes applied, not merely "a signature dictionary, check".
There is a related question, but it is somehow higher level than this one, and I think the most voted answer is wrong: Comparing a signed PDF to an unsigned PDF using document hash
Hhmmm, there are quite a number of facts in that answer, each true by itself, but patched together in a way that is very questionable.
It nearly looks like someone had a low quality LLM and let that AI create an answer. But in 2012 that was not really en vogue.
