Open rotdrop opened 2 years ago
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.
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.
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.
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?
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?
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.
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.
Agreed. I'll test things out with JSignPdf first.
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:
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.
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:
How is this document being processed by three different people?:
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.
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.
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?