libresign icon indicating copy to clipboard operation
libresign copied to clipboard

Question: should signed PDF forms be read-only after signing?

Open rotdrop opened this issue 3 years ago • 12 comments

Hi, thank you for this nice app! Actually, I'm following the development on the master branch and -- hurray! -- signing actually works again (ok, the sign button is still dead, but sending signing request, and signing documents when following the link in the email works!). Very nice!

I have a question about signing PDF-forms: it seems that I am still able to edit and save the signed forms, together with the signature. In principle I would assume that I want to sign filled PDF forms and disable further editing, but may be I am completely wrong here. Or is this just beyond the scope of this signature app? Maybe one could add an option "rasterize first, then sign" or something similar to make filled forms readonly? Or incorporate the contents of the form fields into the signature such that a change would be detected?

rotdrop avatar Feb 09 '22 17:02 rotdrop

Very happy for your considerations!

For now, LibreSign is using JSignPdf as signing engine wrapping the JSignPdf CLI on a composer package.

The sign flow on main branch don't create all form fields and fill when the signers fill the form. LibreSign save all places associated to signer user that the requester user defined. For example, user1 will sign on page 2 on coordinate X, user2 will sign on page 3 on coordinate Y.

The main version of LibreSign have partially implemented the ability to do this. For now, on frontend, only is possible put the visible element of type SIGNATURE, but the API already accept other types.

If you already defined all the signers and the place to put the visible signatures, JSignPdf will create, on moment that the user sign the document, a form field on place that you defined to put the signature, fill the field and append the signature document.

After the document was signed, the form can't be filled more, only will be possible append more signatures.

vitormattos avatar Feb 09 '22 18:02 vitormattos

Thank you for the quick reply! I meant something different: signing pre-fabricated PDF-forms, I did not mean the signature form-field created by Libresign.

rotdrop avatar Feb 09 '22 18:02 rotdrop

Is a excellent idea, but at this time we need funding to implement new features. If you want help developing, we can work together to write the epic and the histories issues describing this feature.

vitormattos avatar Feb 09 '22 19:02 vitormattos

So your proposal would be to create a new issue "Proposal: render PDF-forms read-only after signing" or something like that and for the time being add some brief comments describing the idea. I can do this ... Do you have any preferences about the structure of the contents of such a feature-request?

rotdrop avatar Feb 09 '22 22:02 rotdrop

Looking the options of JSignPdf I found this:

    --disable-fill                       deny fill encrypted documents
    --disable-modify-annotations         deny modify annotations in encrypted
                                         documents
    --disable-modify-content             deny modify content in encrypted
                                         documents

I think that the first option solve that you want, true?

vitormattos avatar Feb 09 '22 22:02 vitormattos

Oh, yes. Exactly. However, I would also say that the other two options look interesting. In principle I would at least optionally deny the (further) filling of forms and the modification of content. Does "encrypted" apply to the documents after being signed? Ok, RTFM :) I'll have a look ...

I think it would make sense to at least optionally disallow further modifications to the document after signing -- safe, perhaps, annotations.

rotdrop avatar Feb 09 '22 22:02 rotdrop

LibreSign now wrap the JSignPdf. Is good try to test first the scenarios on JSignPdf and when you find a good scenario to implement on LibreSign we can define the story and the user cases, scenarios, to implement.

I think that this settings sounds as an LibreSign's admin setting to define the default behavior and, maybe, make possible to user that will do a new signature request to define what he want to do overwriting the admin settings on an advanced settings of document.

vitormattos avatar Feb 09 '22 23:02 vitormattos

Agreed. I'll test things out with JSignPdf first.

rotdrop avatar Feb 09 '22 23:02 rotdrop

I think that locking documents after signing them should definitely be optional and explain why on a real world example of how it's being used in multiple organizations.

In PFD editing and signing software like Adobe Acrobat, PDF-XChange and others there are two main types of signing a document, with grave differences:

  1. Signing a document. Signing a document describes the process of placing a signature onto a document. After a signature is being made, the document can be edited further and be signed again. This is important, since you don't actually sign the PDF, with each signature you create a snapshot of the document, that gets signed. This is important to understand, because with you create a document lifecycle that documents each change between multiple signatures and allows to trace back who signed what state of the document, making documents virtually unfakeable.

  2. Certify a document. Similarly to signing a document, certifying a document also creates a snapshot of the document, that gets signed itself. Contrarily to signing a document, certifying a document then locks it down, allowing no further changes and signatures.

How is this used in real life? Imagine a vacation PDF-form. It contains multiple fields:

  • Requester (employee) Name
  • Leave date range
  • Signature
  • Boss name
  • Boss approval/decline checkbox
  • Boss signature
  • HR processed signature

How is this document being processed by three different people?:

  1. The requester fills out his name, the leave date range and signs it off with his signature. The PDF now contains a secure snapshot/revision of what he requested for his leave time.
  2. The employees boss gets the PDF-document and checks if he can approve the leave time. He decides that it's possible, ticks the approval box for yes and signs the document with his digital signature. We now have to signatures in the PDF-document and thus two revisions documenting what changes and status of the document each person has signed off.
  3. HR gets the document in order to document the leave time and to check if the employee actually has X days left for paid leave. Once HR deems that everything is correct, they then certify the document, placing a last signature on the document and finishing it off, hindering everybody else to make further changes to the document. This electronic signature again creates another document revision - the last since after certifying a document you cannot make further changes or signatures.

Electronic signatures are being used in many workflows like this, some smaller, some bigger - but the biggest benefit of electronic signatures is the ability to handle documents workflows just like any other process and being able to see who signed what without a chance of manipulation. Forcing to make all documents read-only after a signature would take away a lot of possibilities and would thus make all document signatures one-way.

I'd really recommend adapting the functionality to the standards other software is also using and making LibreSign interoperable and even more use- and powerful in the process by dividing functionality in Signing and Certifying.

danir-de avatar Mar 03 '22 11:03 danir-de

Good points.

For now, the signed document will be open to receive new signatures.

At the future will be good implement an option to ask if want to lock the document after signing at the time to request to signing the document. To lock will be necessary add only one signer and this will change the flow to add signers.

vitormattos avatar Mar 03 '22 12:03 vitormattos