I want to 2 recipient [ user and witness] to use the same device or ip address to sign the document sent via docusign.
Please let me know if i can achieve this in docusign
Have you considered using in-person signing? That would require the "host" of the signing session to be a DocuSign user in your account though, but process operates under the assumption that the signer and witness are at the same location.
Alternatively, this question is asked quite often and what you need to have a serious think about is whether the witness is required at all. In most use cases, DocuSign effectively replaces the need for a witness as DocuSign itself is witnessing the signature, authenticating the recipient and recording all the actions of the recipient for you. In all but legal use cases (like notarization) it's usually found that the traditional witness signature is no longer required as a result.
Related
I am trying to implement Embedded signing using DocuSign. And I am wondering what is the legal meaning for the arguments AssertionID, AuthenticationInstant, AuthenticationMethod, and SecurityDomain when creating receiver view?
For example if I put "none" as authentication method and no value for other parameters does the signature still have legal value (in France in my case)?
Will DocuSign use signer IP address in the signature?
If I put some values, for how long should I keep this info in my app's database to stay in rules of e-signature legislation?
Whether an electronic signature meets the legal requirements for a signature or not is a legal question that you will want to discuss with the business people in your organization or company. They're paid to decide these types of issues and depending on the situation may decide to discuss with their legal counsel.
There are many different meanings to "legal signature" depending on the nature of the contract (does it involve real property?), the signatories, and the applicable laws.
For example, France is a "civil law" country. So electronic signatures for some use cases require an AES (Advanced Electronic Signature) or a QES (Qualified Electronic Signature). Good news is that DocuSign can also be used to create those types of signatures.
Re: AssertionID, AuthenticationInstant, AuthenticationMethod, and SecurityDomain
These are optional data fields that you can supply to DocuSign. If you use them, they record additional details about how and when your application authenticated the signer.
With DocuSign embedded signing, your application can authenticate the signer and then DocuSign provides the signing ceremony. But later, if the signature is challenged, you will want to provide information about your authentication of the signer. That's what those fields are for.
Re: if I put "none" as authentication method and no value for other parameters does the signature still have legal value?
If your application does not authenticate the signer, and you do not ask DocuSign to authenticate the signer, then the signature would have minimal legal value because there's no proof of who the signer was. But such signatures can still have a lot of value--remember that the vast majority of signatures are never challenged. So if the signer feels bound by their signature and your organization is willing to accept the signature, then all is well.
Note that your application can ask DocuSign to authenticate an embedded signer even if your application doesn't. For example, you can have DocuSign machine read the signer's French identity card and check the name on it. This is the DocuSign Identity feature.
Re: Will DocuSign use signer IP address in the signature?
Yes, we record the signer's IP address. But that is a very low level of signer authentication.
If I put some values, for how long should I keep this info in my app's database to stay in rules of e-signature legislation?
That depends on your company's practices (and applicable laws and regulations) for its business records. Ask your business colleagues.
We are using REST API to create envelopes and the Template is set up in DocuSign, with signer roles etc. Our customer wants to be able to decide in every separate occasion whether to use InPerson signing or send the signing link via email to the recipient.
Currently/originally we implemented Embedded signing, but our customer wants the "security question" (e.g. ask for driver's license number) to be there before the signing. So that they can prove that the buyer has actually been there to sign.
Is there a way to do this? I have the DocuSign Template set up with "needs to sign" option, but when sending the request to create a new envelope, somehow change a signer to be InPerson and trigger a workflow for that?
I managed to find information about Embedded signing and clientUserId, but is there a way to deliver information for example to the Certificate of Completion, like with the InPerson case with the input showing there?
In order to switch from In-Person (embedded) to remote signing and vice-versa, you will need to use the property ClientUserId. It is well described in the DocuSign article Embedded Signing.
If you're willing to switch after the envelope is created, see my recent question here that deals with the same issue.
To implement the "security questions", DocuSign offers multiple authentication option. It seems to me that you are looking to use the "ID Check" authentication here
In C#, it would look like this when you try to implement ID Check for a given signer :
signer.RequireIdLookup = bool.TrueString;
signer.IdCheckConfigurationName = "ID Check $";
Lastly, for your question regarding the authentication method and the certificate of completion, the Embedded signing article I mentioned above explains well what happens for the authentication method in the certificate completion below :
The authenticationMethod is an enumerated value that indicates the convention used to authenticate the signer. Since, with Embedding, you are telling Docusign that you are handling authentication this is your way of telling the platform how you authenticated the recipient. This information will also be included in the Certificate of Completion, a PDF that is automatically generated for every completed envelope.
We are using the DocuSign REST services and currently passing in the recipients required to sign the document from two People columns in a SharePoint document library. The client would now like to have it that they have secondary signers, e.g. the original users could sign but if they are not available their assistant must do so. What would be the best solution for this?
I noticed mention of something similar here:
Docusign multiple signers for one signature line
They want this to happen at run time though, so the email addresses get sent on the original request to create the envelope and this solution above speaks more to the concept of creating them via the DocuSign interface which is not ideal for them. Has anyone else tried this?
Do the assistants sign as themselves or on behalf of the original signer? I'm making some assumptions here, but most assistants would have access to their boss' emails, so presumably they'd have access to the DocuSign notifications that comes though. In that case, the assistant could simply sign as the original signer by clicking through to the envelope from the email. While this is usually a bit of an eyebrow raising move in terms of security, the reality is that many partners in law firms already delegate their authority to their PAs to sign on their behalf, and today these PAs have copies of all their bosses' signature images to place on documents.
A slightly better move, if the requirement is for the assistant to sign under their own name, is to go into the envelope from their boss' email and reassign the envelope to themselves. Then they will receive an email and they can sign under their own name and all of this will show in the audit trail.
Either way there isn't anything you need to do from an API perspective apart from ensuring the right features are turned on to allow signers to reassign.
The other option is using Signing Groups, but the groups need to be set up beforehand in the DocuSign account and your API call will enter the signing group ID (under the "signingGroupId" parameter) instead of the recipient name and email. This means either the boss or their assistant could sign if they are in the same signing group, but does not enforce one over the other.
I have a web app which I use to collect some information from a user (not name or email) and then plan on having them electronically sign a document via DocuSign immediately online (not via email).
In order to get a signing url (aka recipient view), it appears I have to provide a definition of a recipient. Part of the definition of a "recipient" is a username and email address. Is this true?
Does the DocuSign API/SDK require me to provide an end-user's (aka signer) name and email address? It seems like the API/SDK will always return a validation error if I don't provide these things. What if I don't have that information?
You need to provide the signer's name and their client_user_id within your app. You also need to supply an email for them.
The client_user_id must be unique per signer.
If you have the signer's email, use it.
If you don't, use a unique email address that includes the client_user_id to guarantee uniqueness. Eg noreply_{client_user_id} #your_company.com
Added
Re comments:
Yes, an email address is required by DocuSign to generate an embedded signing ceremony. But it is okay to fake one (that includes your app's client_user_id for the signer) if you don't, in fact, have the signer's email.
Re: Why is this the case? Because the email and name are used by DocuSign to index the "captive signer" (someone who signs your account's envelopes but doesn't have their own account with DocuSign). That's why a fake email must be unique to this person.
This technique of using name + email to identify people enables DocuSign to, for example, not require the signer to agree to the consumer agreement to use eSignatures on second and subsequent document signings with your account. -- This provides a better UX.
Since it is very common for web apps to know their user's email, this is usually not a problem. But if you don't know the signer's email, then everything works fine with a fake email as described above.
Added more
Re:
please provide a source for DocuSign being Okay with fake email address in this case? I mean is it legal?
Currently this technique for providing a fake email address for embedded signing (when a real email address is not available), is not documented on the DocuSign web site. I will add it to the embedded signing recipe when I revise it in 2017.
Re legality: the important issue is how your app authenticates the signer. Email is one way. Depending on the use case, email authentication may or may not provide a strong enough assurance to the relying party (the person who receives the signed document).
But we digress. Even if you do have a person's email address, it is common to authenticate the person beyond using their email. DocuSign has many different types of additional authentication built-in and easy to use including 2FA via SMS, pre-shared secret, in-person signing (which can include in-person verification of government ID), e-notary, digital certificates, telephone authentication, knowledge based authentication, and more. Most of these can be included with embedded signing if you wish.
Or your app (which is using embedded signing) can itself authenticate the person. When someone signed up for your app, did they have to first prove their identity? That was the authentication step. If no one else can log in as them, then they're still authenticated when you give them the embedded signing ceremony from DocuSign.
I have an document , which needs the signature from the developers account on default, how can I achieve this. I have successfully added a document and have generated the view url to be sent. But I want to add the signature of the developers account by default , cant seem to find a way to do this.
As Luis mentions in his comment above, it's not possible to automatically (programatically) add signatures to documents for some recipient(s) while requiring that other recipient(s) sign using DocuSign. You have a couple of options to get the developer's (i.e., sender's) signature on the documents:
Include the Developer (Sender) as the first recipient in the Envelope's workflow. (They'll sign using DocuSign, just as all other recipients will.) This is your best option, because you'll get all of the normal security and audit trail functionality that DocuSign provides for all signers.
Burn the Developer's (i.e., Sender's) signature into the document(s) prior to adding the documents to DocuSign. i.e., the signature will already be on the documents when you add them to DocuSign. Not a great option, IMO.
Keep in mind that automatically applying someone's signature to documents (i.e., either programatically or by burning the signature into the documents before adding them to DocuSign) somewhat nullifies the intended effect of a signature -- i.e., a signature typically implies one's agreement/consent -- but if the signature is applied without any action on behalf of the signer, then is agreement/consent truly in effect?