Text tags with embedded widget supporting multiple signers - echosign

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.

Related

Digital Signature/ eSign verification fails

I have a eSigned / Digitally signed PDF, the document is signed using iText lib in detached signature. I am having issue while verifying the signature, getting message "signers identity is invalid because it has expired or not yet valid" and in signer info "There were errors building the path from signers certificate to an issuer certificate."
I have tried many ways to validate the signature but couldn't get any success. If I explicitly add signers certificate as trusted certificate then I get a green check and able to verify the signature but I think thats not the correct way to do it.
Adobe Signature setting are as follow:-
digitally signed pdf can be found heredigitally signed document
can anyone please help to resolve this issue.
I have tried many ways to validate the signature but couldn't get any success.
That is not surprising: Your signature is not valid. In the PDF signature field value there is a signing time 2020/06/11 09:28:35 GMT but your signer certificate is valid not before 2020/06/11 09:29:44 GMT and not after 2020/06/11 09:59:44 GMT. At the claimed signing time, therefore, your signer certificate was not valid yet and could not create a valid signature.
Apparently you sign using a signing service that creates a short-time certificate just in time when your signature request to it arrives. Unfortunately that is after the time iText stored as signing time in the PDF at the beginning of the signing process.
Thus, one way to resolve the issue is to tell iText to use a time slightly (e.g. two minutes) in the future.
You can do that by means of the PdfSignatureAppearance method setSignDate.
Your signature actually also violates a recommendation from the specification: The afore mentioned signing time stored in the signature field value dictionary should be used only when the time of signing is not available in the signature (the embedded signature container). In your case, though, the embedded signature container does contain a signingTime signed attribute with value 11/06/2020 09:29:44 GMT which is not before the start of certificate validity.
As that only is a recommendation, your PDF signature is not made invalid by having two signing time values. But as the values differ, this can result in different verification results by different validators, using either one or the other value.
Thus, another way to resolve the issue is to make sure no signing time value is added to the signature value dictionary at all. This additionally makes your signed PDF follow the recommendation above and so be more precise.
Unfortunately using the PdfSignatureAppearance method setSignDate to set a null value does not work, later on in the signing process this results in NullPointerException occurrence. But if you use a custom ExternalSignatureContainer implementation in your signing code (and not an ExternalSignature implementation), you can remove that entry in your modifySigningDictionary implementation. The key is PdfName.M.
As an aside, as your signing certificate is only valid for half an hour, validators may also reject it if their validation policy only trusts digital time stamps, not unsecured date-time values.
Thus, you should add revocation information and digitally time stamp the whole construct during the life time of the certificate to guarantee long term validation.
I understand what your issue is. There's a whole new way of solving it, in 3 steps.
Open in Adobe Acrobat DC or any Adobe pdf editor software you have.
In Edit, go to Preferences, in the end come to Signatures. Click on verification, more, in verification time section, select current time. Same location, verification information section, select never.
In Windows integration, tick validating signatures and validating certified documents. Click ok.
Close all popups. Come back to signature area and right click to select, validate signature.
Done ✅

iTextSharp not rendering digital signature

I've read the I-TEXT digital signature e-text, and also previous posts answered by MKL (who seems to be the authority along with Bruno on this topic).
essentially I have an Azure app service that gets the digital sig (base 64) and certificate chain from the company's signing API. The company's signing API returns a signature in Base64 along with a certificate chain.
I just want the to insert a signature object/container into the pdf so it will show in the signature panel when an end user opens up the pdf. I prefer to use deferred signing.
I've shifted from chapter 4's "clientseversigning example" to instead Deferred Signing in MKL's "How to create a PDF signature without knowing the signer certificate early".
The Company API returns a "plain" signature, that I am pretty sure, and also returns a chain of 3 string certificates.
I should note I do have the root and sub certs in advance (2 .cer files) but I am not using them in "prepping" the pdf for hashing right now since the deferred signing example doesn't make use of them obviously. For the container construction code (after getting the response from the Company API), I use the 3 certs chain returned from the company API, but I also tried it with the 2 .cer files, to no avail.
The only difference between my code and the one in the example is instead of byte[] certificateBytes = THE_RETRIEVED_CERTIFICATE_BYTES; X509Certificate x509Certificate = new X509CertificateParser().ReadCertificate(certificateBytes); I build 3 x509Certificates (one for each string in the chain returned from the Company API.
Sadly things wont work, I get these errors in Acrobat: Signature is invalid, There are errors in the formatting or information contained in this signature, signature's identity has not yet been verified, signing time is from the clock on the signer's computer...also if I click Certificate details just below of this error in Acrobat it is blank. This was pretty much the errors I was getting when trying the "clientserversigning example"
I am trying really hard and wondering what it could be... should I try modifying the estimated size from 12000 and bump it up? or the errors I am getting in Acrobat, maybe they are hinting the certificate chain from the Company API is not being picked up by the signing deferral container construction code ... I am struggling but any tips would be so greatly appreciated
Evan
Just to clarify, I am following chapter 4's clientserversigningexample but I am getting the following once my pdf is recreated with the signature from the company API
Its saying 1) there are errors in the formatting of information
2) signer's identity has not been verified
3) signing time is from the clock on the signer's computer
now as far as "prepping" the pdf before hashing it to send for signing...I don't see anything in the ClientSigning example that specifically preps it, can I assume the IText library is prepping it under the hood?
In your question and in your comments to it you appear to be in particular interested in
whether or not one can use a signature API that returns the certificates only together with the signature, and
when to to deferred signing.
Can You Use a Signature API That Provides the User Certificate Only After Signing
To answer this one first has to clarify what kind of signatures the signature API in question creates, plain signature values (e.g. PKCS#1 RSA signatures) or full-fledged CMS signature containers.
If it creates full-fledged CMS signature containers, you can create signatures following arbitrary signature profiles as long as the signature containers follow the requirements for them (which they often do). They only restriction you have is that you cannot have information from the signer certificate in the signature visualization because that visualization is defined in the signed data of the PDF.
If it only creates plain signature values, the best you can do is create and embed simple CMS containers that don't contain pointers to the signer certificate in the signed attributes (if they have any signed attributes as all to start with). Many signature policies of interest do require such pointers, but at least Adobe Reader accepts signatures without.
If you are in this situation and want to try creating signatures with such simple signature containers, you may want to use the code from this answer, section "How to create a PDF signature without knowing the signer certificate early".
When to Use Deferred Signing
The difference between deferred signing and other iText signing calls is not that deferred signing requires less information (compared to ExternalContainer signing).
In contrast to the other iText signing methods, signDeferred re-uses the outermost existing, filled signature field of the PDF to sign and merely replaces the signature container therein.
The method name is derived from the most common use case it’s used for:
In a first step a signature field is (probably first created and then) filled using signExternalContainer with an IExternalSignatureContainer implementation that calculates the document hash to be signed but does not return the final CMS container yet, merely some (usually) empty array. The generated PDF with a filled signature field (albeit without the final signature container) is then temporarily stored (in the file system or a database).
In a second step a signature container for the determined document hash is requested and (probably asynchronously) awaited.
In a final step signDeferred is used to inject the retrieved signature container into the PDF prepared in the first step.
This deferred signing process usually is preferred in setups in which the second step, the signature container creation and retrieval, can take longer than one wants to keep the resources blocked which are required for the document in signing. This includes in particular signatures generated by remote servers or clients, especially if that signing process awaits some third party clearance or activation.

It is possible to add new signature fields to already signed PDFs?

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.

Is there a way to get back the original unsigned document that was sent to DocuSign after it is signed/completed?

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.

Can I sign arbitrary PDFs through DocuSign without preparing signature fields?

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.