Use case: My system needs to retrieve authorization forms from a variety of sources. There is no standard form - each source may define their own authorization form, but each authorization form requires exactly one signature. None of the blank forms will have PDF signature field markup - they will just be simple PDFs originally meant for printing and wet signing. For example, every summer camp in the country has their own release form. My system will receive those forms and present them for signature, without knowing what the form looks like ahead of time.
This means I will not have the chance to mark up the form with DocuSign "Sign Here" boxes.
Is it possible in DocuSign to have a system send in a form and allow the signer to manually determine exactly where they want to place their signature? Without giving the signer duties such as preparing the document themselves - I just want them to see the form on screen, and be prompted to "Click wherever you think you should sign", just like they would do in the paper world.
You can use DocuSign free form signing for your usecase.
See this DocuSign Blog Post for more information.
Free-form signing occurs when no tags are placed on a document submitted via DocuSign. This means that the signer will be presented with a palette of signature options (Signature, Initial, Full Name, etc.) which can be applied to the document at will.
Related
Let's say we receive a PDF document that is alredy signed.
We'd like to add a new signature field to the document and send it to the person that needs to sign it inside our environment.
We've seen that it's possible with AcrobatPro to directly sign the document, but it's not possible to just add the signature field to the document without signing it. We don't have AcrobatPro licenses for every user on the organization that have to sign external documents, so we're looking for a way to prepare the document for them, so they can sign it just within Acrobat Reader.
We are on a quite big organization (around 3000 ppl) and our ERP already manages everything related to signatures to our own documentation, but we are seeking for a solution to sign external documents that already have been externally signed while our provider evolves a solution inside the ERP.
I send the document to DocuSign in draft status. Then user(contract owner) logs into DocuSign, adds additional signers and tags then sends the document for signing.
Is it possible to get the original unsigned document(pdf) that was sent after the document is completed via the API?
The reason I need the original document is to make sure that the user(contract owner) has not changed/modified the document in DocuSign.
I want to make sure the signed document is exactly the one I sent via API.
DocuSign does not have granular permissions to block changes to the documents when the Envelope is in draft status.
Re: Is there a way to get back the original unsigned document that was sent to DocuSign after it is signed/completed?
Answer: unfortunately, no. As soon as original documents are uploaded to DocuSign, they are converted into a "flat" (no logic) PDF. The original document is then discarded.
As a workaround, you could programmatically create a template, then create an envelope from the template. Then the user could tag the document without the ability to change the document. See use case 8, creating a template programmatically for code examples. These are on the eg-03 series of examples. Eg, the PHP code example.
Or better, update your application to tag the documents for the user.
We are investigating the idea of enabling the documents in an envelope to be locked. Please ask your DocuSign business or support contact to add your company information to DocuSign internal issue number SMPI-236.
First of all, a bit of background - the actual questions are at the bottom.
I'm currently working on a web-based app (sort of SaaS) which allows users to send forms to their own customers.
These forms are simple, small contracts for small jobs where their customers say "Yeah sure, I'll do this and here's my confirmation".
The sort of thing that is being "signed" does not require a fully qualified digital signature and an electronic signature will suffice.
While, in this case, a simple checkbox saying "Yeah, I'll do this" would legally be sufficient, I'm keen to implement it with a signature pad. To be honest, it's just for the factor of being seemingly more binding and, well, "neat".
The current workflow looks like this:
User's customer opens web-form (the party being asked to sign is the only person in the universe to know the direct link)
Ticks a few boxes and enters text
Clicks "Sign" which opens an HTML5 signature pad (mobile) or a simple input (PC) to type their name
Clicks "Accept"
A PDF is generated for download and stored on the server (along with timestamp, IP, and a couple of other bits of information)
As you can see, the agreement in its entirety constitutes a simple electronic signature - even without the bells and whistles.
What I would like to do
As with any simple electronic signature, it's easy for any party to say that a document may have been tampered with.
So what I did is properly sign the PDF according to the specifications (using tcpdf): that entailed first generating the PDF and then adding the signature to the /Sig dictionary, then generating a digest across all byte-ranges (excluding the signature), linking it up with a .crt file and voilá: the document is signed with the lovely benefit of the signature becoming invalid if even a single byte is changed.
Now to the questions:
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
No, at least as long as you want to do this in an interoperable way.
You can of course invent your own security system, create a PDF viewer or at least plugins for the commonly used PDF viewers to support your system, and roll these programs out to your users.
But if you want existing Adobe Reader as-is to verify the signature, you've got to go the X509 PKI way.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
When using your own certificate for signing, don't forget to properly fill the reason field so it indicates that your signature is applied as a counter signature to guarantee validatability.
With that in place I don't see your signature doing any harm.
The question is how much good it does, though.
Obviously the user still can claim that he signed something different... because he did! He signed the web form, not the PDF. Thus, you might have to provide proof that the PDF reflects exactly what the web form showed anyways, that the user signed something equivalent.
If you want actual non-repudiation by the user, you need to make him sign personally in a manner that is commonly accepted to not allow tampering. In other words, your user needs to apply proper digital signatures himself. Everything else is open to claims of forgery.
You can use trusted time-stamp (defined in RFC3161) instead of signature created by the customer or by your server. Time-stamp protects document integrity and proves that your document existed before a particular time. Technically speaking it is a digital signature created by a trusted 3rd party.
Is there a way to customise or change the message that gets displayed in the document open Password dialog box while trying to open a password protected PDF file.
Default message - "filename.pdf is protected. please enter a Document Open Password."
The message shown is completely up to the PDF viewer or processor in question.
In general you cannot prescribe it but you may create your own viewer showing the text you prefer.
PS: As the OP still hoped for a different answer (and asked essentially a duplicate question here):
The PDF specification in regard to opening password protected PDF files only rules:
If a user attempts to open an encrypted document that has a user password, the conforming reader shall first try to authenticate the encrypted document using the padding string defined in 7.6.3.3, "Encryption Key Algorithm" (default user password):
If this authentication attempt is successful, the conforming reader may open, decrypt and display the document on the screen.
If this authentication attempt fails, the application should prompt for a password. Correctly supplying either password (owner or user password) should enable the user to open the document, decrypt it, and display it on the screen.
(ISO 32000-1 section 7.6.3.1)
It does not present any mechanism to supply a message for prompting for the password.
Please note that the specification even makes prompting for a password merely a recommendation ("should", not "shall"). Completely in accord with the specification, therefore, other ways to retrieve a password might be tried instead, or such password protected documents might be ignored completely!
That been said specific PDF viewers might allow to provide a prompting message in a proprietary manner; after all the early signing mechanisms in Adobe Reader even allowed the PDF to provide appearances for successfully and for unsuccessfully verified signatures which made frauds possible! I doubt, though, that current versions of serious viewers allow providing password prompt messages even in a proprietary way.
We have Echosign global account. we are trying to support multiple signature in our embbedded widget, but we have the limitation that we don't know email-id of the multiple signer at the time when widget is created. Text-tags maps the signers with the emailid that we have, but we don'thave email id at that point.
Does echosign provide any way to achieve this?
I don't think not knowing signer's email id's will have any issues.
Echosign does associate every signer with an email id, but you need not provide it at the time of creation.
Just have different signers like signer1,signer2, etc. , have different text tags like {{name_es_:signer1}},{{name_es_:signer2}},etc. and whenever they sign, depending on your signature settings echosign will allow them to verify their emailids after signature.
email fields are not mandatory with echoSign. You can simply ignore setting up emails from the API and echoSign by default will place 'signature-block'(that includes a signature field and an email field as an inseparable block) for every signer's you have on your documents. If the same document needs to be signed by number of people, there is an option called counterSigner or so while creating widgets and you can specify just the signers(signer1, signer2..) as tags,
{{es:signer1:signature}},{{es:signer2:signature}}.... .The desired tags should be according to your business rule. For you it might just be the Signature or combination of name and signature, or whatsoever.
When the first signer signs the document, he has to enter his email (on the default signature block). He then has to log in on his email account and verify the signature. After this, echoSign will automatically pass the document signed by 1st signer to the next signer and so on.