In our Docusign process - using the REST API - we have one company but two organization names, call them Org A and Org B. Org B uses the API with the authoritative copy flag = 1, so at the end of the packets they're printing, a "Certificate of Completion" and two pages of legal boilerplate are appended to the envelope. Org A doesn't use the flag, their documents don't get the certificate and boilerplate.
Question #1: The certificate and boilerplate are not in the document Org B is sending for signature, so can I assume that's part of the authoritative copy process?
The legal boilerplate has the parent company's name - and my email - throughout the text. Org B would like their own information in that space.
Question #2: They have their own credentials on the Docusign account, so is that sort of customization possible?
So, there are two things you are refering to here and there's some confusion.
Certificate of Completion. This one is generated by DocuSign for every transaction (every envelope). It doesn't have to be visible or downloaded by customers, but it's always there. If you ask for it in your code, you get it. This is not a document to be signed or be acted on. It's just a summary of everything that happened and it's used for legal purposes.
The second thing you refer to as "boilerplate" is called the Electronic Record and Signature Disclosure and is something that recipients have to agree to once and forever (unless they retract or change their information like email or name). This one is controlled by DocuSign, if DocuSign determine you are a new signer that didn't yet consent to the ERSD - then you're asked to do so. As a developer you have no control over this process.
Related
Issue:
I have a working production process for initiating remote signing via the DocuSign REST API. For the most part, it works great. However, for the initial 20 contracts we've sent out, a few clients have not received their emails from DocuSign requesting their signature. I can confirm that DocuSign reports that they successfully SENT them to the signers even though clients have reported never receiving them (despite looking through spam/junk/deleted). In these few circumstances we're stuck at a dead-end because if they don't receive that email for whatever reason, we have to revert back to manual contracts.
Having read through the following article:
https://support.docusign.com/en/articles/Why-aren-t-my-signers-receiving-DocuSign-Notification-emails
It's clear that this is a common issue and the only options we have is to either send it to another email address, have the client reach out to their ISP and figure out why it might be rejected (This is not a good / professional option), or resort to a manual contract.
One thought I had...
was to use the API to obtain the link for the current signer that DocuSign provides in the emails they send and give my app's users an alternative option to send our branded email containing this link to the remote signing page from our email service since we have zero reputation issues.
Edit based on Inbar's reply
After reading through Larry's Blog as provided by Inbar in the comments below, my idea above would need to have my app send an email to the signer with a unique URL back to my App (so that this URL is Long-Lived / limited only based on business rules) which, when clicked, would make a request to EnvelopeViews:createRecipient (time-limited / must be used in 5 mins) to retrieve a url and redirect the user to the Remote Signing page which is governed by DocuSign's session policy.Should my client need to go away and click the link in their email again, the Long Lived ==> Time Limited & redirect would repeat starting a new session.
Support seems to be better here on SO than via ticketing, so I'm hoping a DocuSign rep/guru has some ideas on what I can do to handle these scenarios.
First off, yes there are cases where emails from DocuSign are rejected as SPAM by the ISP or by the email provider. These will not even show in the spam folder because they reject them before they send them to the end-user and we do need to work with these to fix the issue. Especially if these users will be receiving more than one contract etc. For that - you will need to contact support since we need to know the email address etc.
Your idea is possible, but you'll have to read Larry's blog here. This is because the URLs are typically very short lived and expire in 5 min so sending the regular URLs over email will not work very well.
We are currently implementing Docusign within an application. We send contracts to our customer, and set the Signer to our contact person. We want the customer to be able to sign using a different name as we originally supplied in the signer, if some other person within the company does the actual signing.
So we want the signer to change the signer name and initials in the 'Adopt your signature' dialog if needed, but these fields are greyed out and disabled for editing. According to the docs this should be possible: https://support.docusign.com/en/guides/signer-guide-signing-adopt-new
Example: We have a contact named Alice with email address info#example.com. We send the Signing request, and colleague Bob will read the request from the info# mailbox, and sign it. I want Bob to be able to enter his name in the 'Adopt your signature' dialog. I have no knowledge of the existence of Bob within the company.
What I've tried sofar:
In the Docusign admin settings (Settings -> Signing Settings -> Signature Adoption Configuration), the 'Lock recipient name' checkbox is disabled, but this does not result in any changes.
I've also tried to set the agentCanEditName flag on the signer (https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/enveloperecipients/#core-recipient-parameters/) in the API, also without results.
So I have no idea how to allow the signer to change his/her own name, apart from using 'Other actions-> Assign to someone else' from the top menu. Any suggestions?
After sending the question to Docusign support, the conclusion was that they don;t support this. The only way to implement this is by:
Instruct the signer to use the reassign the signing responsibility (https://support.docusign.com/en/guides/signer-guide-signing-change-signer)
Use in-person signing, where the host can opt to change the signer (https://support.docusign.com/en/guides/ndse-user-guide-in-person-signing).
Unfortunately, both methods require prior knowledge about the signing process from the signer. Simply editing a form field during the signer process is not possible.
Thank you for reaching out. Signing groups maybe what you're looking for: https://support.docusign.com/en/guides/ndse-user-guide-signing-groups
It allows one person from a group to sign the documents vs a specific person.
Have you tried to use allowReassign: "true" in the envelopeDefinition. This offer the ability for a signer to forward the envelope to someone else and seems to be close to what you are looking for: https://support.docusign.com/en/guides/signer-guide-signing-change-signer
That being said, back to your problem, I'm not sure what is the real problem but several features are incompatible with Allowing recipient to change their name that might be the case with your call/Account. Do you have anything special enabled?
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
I am using DocuSign with my web application. Whenever I try to sign in the document, the first time I am asked for adopting a signature. From next time onwards, docusign uses the same saved signatire every time even if I need to sign a new document. I need a feature where the recipient should be asked to adopt and sign everytime he visits a new document. But this is not happening. Is there any way we can do it? If not, do we have an option in DocuSign recipient view where the recipient can select a new signature at his will?
The querstion in DocuSign remembers signature. Want to turn that feature off
is similar to mine. I tried the answers mentioned in the post but it did not help.
It sounds like you are using captive recipients and embedded signing. In this scenario, the signer is captive to your application. So, if you define a recipient a 2nd time using the same name, email and client user ID, DocuSign will use the signature the recipient adopted the first time around.
Two ways around this.
First, make the client user ID random. This way, the recipient is always unique and will always adopt a new signature.
Second, delete the signers signature from your account after the envelope is completed. This way, they would have to adopt again even if you use the same client user id.
There's definitely an option for this. Unfortunately I don't know which one it is.
Plus it might be one of the account options that is set by DocuSign Customer Service.
If you're working with a salesrep, ask him or her to have the setting updated for your developer account.
If you simply want to ensure (for your demos and development) that the signer will always be asked to adopt a signature, you can do that by always using a new {name, email} tuple.
Eg if you send a doc to {Joe Signer, joe#signer.com} the first time, send to {Joe A. Signer, joe#signer.com} the second time.
I use this technique during demos to ensure that the demonstration will include the signature adoption step.
Applications send out emails to verify user accounts or reset a password. I believe the following is the way it should be and I am asking for references and implementations.
If an application has to send out a link in an email to verify the user's address, according to my view, the link and the application's processing of the link should have the following characteristics:
The link contains a nonce in the request URI (http://host/path?nonce).
On following the link (GET), the user is presented a form, optionally with the nonce.
User confirms the input (POST).
The server receives the request and
checks input parameters,
performs the change,
and invalidates the nonce.
This should be correct per HTTP RFC on Safe and Idempotent Methods.
The problem is that this process involves one additional page or user action (item 3), which is considered superfluous (if not useless) by a lot of people. I had problems presenting this approach to peers and customers, so I am asking for input on this from a broader technical group. The only argument I had against skipping the POST step was a possible pre-loading of the link from the browser.
Are there references on this subject that might better explain the idea and convince even a non-technical person (best practices from journals, blogs, ...)?
Are there reference sites (preferably popular and with many users) that implement this approach?
If not, are there documented reasons or equivalent alternatives?
Thank you,
Kariem
Details spared
I have kept the main part short, but to reduce too much discussion around the details which I had intentionally left out, I will add a few assumptions:
The content of the email is not part of this discussion. The user knows that she has to click the link to perform the action. If the user does not react, nothing will happen, which is also known.
We do not have to indicate why we are mailing the user, nor the communication policy. We assume that the user expects to receive the email.
The nonce has an expiration timestamp and is directly associated with the recipients email address to reduce duplicates.
Notes
With OpenID and the like, normal web applications are relieved from implementing standard user account management (password, email ...), but still some customers want 'their own users'
Strangely enough I haven't found a satisfying question nor answer here yet. What I have found so far:
Answer by Don in HTTP POST with URL query parameters — good idea or not?
Question from Thomas -- When do you use POST and when do you use GET?
This question is very similar to Implementing secure, unique “single-use” activation URLs in ASP.NET (C#).
My answer there is close to your scheme, with a few issues pointed out - such as short period of validity, handling double signups, etc.
Your use of a cryptographic nonce is also important, that many tend to skip over - e.g. "lets just use a GUID"...
One new point that you do raise, and this is important here, is wrt the idempotency of GET.
Whilst I agree with your general intent, its clear that idempotency is in direct contradiction to one-time links, which is a necessity in some situations such as this.
I would have liked to posit that this doesn't really violate the idempotentness of the GET, but unfortunately it does... On the other hand, the RFC says GET SHOULD be idempotent, its not a MUST. So I would say forgo it in this case, and stick to the one-time auto-invalidated links.
If you really want to aim for strict RFC compliance, and not get into non-idempotent(?) GETs, you can have the GET page auto-submit the POST - kind of a loophole around that bit of the RFC, but legit, and you dont require the user to double-optin, and you're not bugging him...
You dont really have to worry about preloading (are you talkng about CSRF, or browser-optimizers?)... CSRF is useless because of the nonce, and optimizers usually wont process javascript (used to auto-submit) on the preloaded page.
About password reset:
The practice of doing this by sending an email to the user's registered email address is, while very common in practice, not good security. Doing this fully outsources your application security to the user's email provider. It does not matter how long passwords you require and whatever clever password hashing you use. I will be able to get into your site by reading the email sent out to the user, given that I have access to the email account or am able to read the unencrypted email anywhere on its way to the user (think: evil sysadmins).
This might or might not be important depending on the security requirements of the site in question, but I, as a user of the site, would at least want to be able to disable such a password reset function since I consider it unsafe.
I found this white paper that discusses the topic.
The short version of how to do it in a secure way:
Require hard facts about the account
username.
email address.
10 digit account number or other information
like social security number.
Require that the user answers at least three predefined questions (predefined by you,
don't let the user create his own questions) that can not be trivial. Like "What's
your favorite vacation spot", not "What's your favorite color".
Optionally: Send a confirmation code to a predefined email address or cell number (SMS) that the user has to input.
Allow the user to input a new password.
I generally agree with you with some modification suggested below.
User registers at your site providing an email.
Verification email is sent to the users account with two links:
a) One link with the GUID to verify the registration b) One link with the GUID to reject the verification
When they visit the verification url from their email they are automatically verified and the verification guid is marked as such in your system.
When they visit the rejection url from their email they are automatically removed from the queue of possible verifications but more importantly you can tell the user that you are sorry for the email registration and give them further options such as removing their email from your system. This will stop any custom service type complaints about someone entering my email in your system...blah blah blah.
Yes, you should assume that when they click the verification link that they are verified. Making them click a second button in a page is a bit much and only needed for double opt in style registration where you plan to spam the person that registered. Standard registration/verification schemes don't usually require this.