Hacker News Reader

Comment by somery | Hacker News Reader

Hi everyone, my name is Alex and I'm the creator of DocuSeal.

I was not happy with the existing mainstream document signing solutions so I decided to create an open-source alternative.

I've been working on this project since the middle of May and here is what the tool can do so far:

- PDF form fields builder

- 10 field types available (Signature/Date/File/Checkbox etc)

- Multiple submitters per document

- Automated emails via SMTP

- File storage on AWS S3, Google Storage, or Azure

- Automatic PDF eSignature

- PDF signature verification

- User management

- Mobile-optimized

DocuSeal can be self-hosted on-premises or used in the Cloud for free. DocuSeal was built with Ruby on Rails with a bit of Vue3 for complex UI parts like the form builder.

Looking for some feedback and would be happy to answer any questions

View on HN

This is amazing work, and this space desperately needs an open-source solution!

The signing experience could use some polish, but it's well on its way. A few things: clicking a signature field immediately opens a file upload despite the very functional draw-your-signature canvas. Focusing to type into a field scrolls the page not so the field is in view, but so it's at the top of the viewport, which prevents the reader from seeing the paragraph of context above the field. And minimizing the bottom panel where you type fields should be unminimized if you click another field, otherwise it can cause non-technical users to feel "stuck." Oh, and in terms of demonstrations, the demo PDF should likely be a (fake) legal contract of some sort, to show off how things can be positioned in a realistic document!

If there's one thing I'd suggest you implement, though, it would be the ability to embed the signing interface in an iframe whose URL can be parameterized to prefill values via the query string, e.g. following https://helpx.adobe.com/sign/adv-user/web-form/url-parameter.... (Oh, and postMessage to the parent page when signing is done so the interface can react to that!)

So many real-world workflows can be handled with a simple wizard that pre-populates a PDF to sign, with the values from that wizard. But most of the solutions out there charge an arm and a leg for this, with large minimum order sizes and even charging for the view even if the user doesn't complete the form! Not to mention that letting people self-host, thereby avoiding third-party cookie issues, makes things significantly more accessible.

Really looking forward to how this progresses!

Thanks for the feedback! All your UI suggestions/fixes make sense and will definitely be brought into the the tool soon! Also I like the idea of using some 'fake' legal document for the demo.

Regarding the iframe - i've been thinking about creating an npm package for better integration with the host app - but maybe giving an option to use iframe should be available as well for companies that don't have developers to implement a better integration with the npm package.

iframes generators are great so IT departments can hand off the html to their web support vendors (it is just a blob of text to some IT teams).

Not to mention making this system usable by folks who haven't ever used modern JS tooling, but who are trying to string together no-code/low-code tools/form builders/Wordpress plugins to automate their workflows and be able to do more creative things with their time!

can be self-hosted on-premises

This kills it as a viable alternative to DocuSign. The point of Docusign is that it is an independent third party that maintains custody of the signed contract and proof of acceptance (i.e., digital signatures) by all parties to the contract.

A self-hosted digital signature system isn't worth anything in court; the other parties will simply reject the authenticity of any data held within it and the amount you'd have to spend to get that data into evidence would probably pay for several centuries of DocuSign's enterprise edition.

That being said, the cloud-hosted option seems viable as a competitor for Docusign if it's offered by you/your organization as a service, and could provide financial support for continued development.

>A self-hosted digital signature system isn't worth anything in court; the other parties will simply reject the authenticity of any data held within it and the amount you'd have to spend to get that data into evidence would probably pay for several centuries of DocuSign's enterprise edition.

When self-hosting it - you can integrate it with AWS s3 Azure or Google Cloud files storage - those are the trustworthy third parties that provide the entire history of logs to ensure that the documents were not altered and signed at specific date/time with the specific content.

So bringing cloud storage providers as a thirdparty when self-hosting will bring enough evidences to the court to defend the signed documents.

How do you prove who actually signed the document? Docusign does this by only sending the signing link to the signer’s email. I don’t see how you could prove that no one else had access to that link if you’re self hosting.

Self-hosted Docuseal also sends emails to the signers - you just need to add your SMTP configs to send emails.

I tested it out briefly and it looks very cool for something put together within a couple months. One thing that doesn't seem to work at the moment is automatically recognizing existing PDF form fields (although perhaps there was a problem with the specific PDF I tested).

Being able to quickly import existing forms and then just add some labels would make things move a lot quicker.

One other thing that would be helpful is to handle variable numbers of signatures required. Some documents I have to deal with have space for many signatures but for any given instance, only one or two might be needed. Perhaps I've missed this, but I'm not sure existing templates would handle this case. I think that ideally a template would contain all the signature fields but then I can specify which ones are actually required when I send out the document for signature.

Hi Alex,

what a great idea, thank you very much. Two years ago I was evaluating different signing solutions for the company I worked with and there were two killer features that forced us to go with docusign since at the time they were the only ones really supporting it:

1. Relaying of Submissions to other Signers

We often found that we needed to get a Signature from someone at another company. However, we couldn't a priori say "Person X has to sign it". Often we had a contact person that would help us navigate the internal structure of the other company and relay the signing to that person. Docusign has the ability to allow us to say this person we know can decide who has to sign this document, even if we don't know that person. No one else at the time supported that use case.

2. Qualified Electronic Signatures

So... Here in Germany our Government has some kind of Angst (might call it german angst) of anything digital. A Handwritten signature on a piece of paper is held in such high regards that the digital equivalent (qualified electronic signatures) require a video ident workflow with a passport held into the camera and so on. This has to be done via a third party service that takes like 15-20 Euro per validation. I know it's insane. There's a reason that theres no german silicon valley... Anyway, there are many situations where this level of validation is required by law.

Just my 2cts after dealing with this issue here, I think 1. is something you might look into implementing, cause it's a use case that might come up more often, 2. is just really annoying for everyone.

I'm interested in reading more about #2, can you provide a source?

https://www.docusign.com/products/electronic-signature/legal... doesn't mention anything about videos or passports. I could see how that might be one means a third party has chosen to collect proof of intent, but haven't found anything legally mandating it.

https://support.docusign.com/s/document-item?language=en_US&...

This describes how docusign uses video identification for document signing.

> If they request qualified signatures, you must verify your identity with the IDnow video service after selecting the SIGN button.

Signicat, another document signing service, uses WebID to do video verification

https://www.signicat.com/identity-methods/web-id

> The WebID service VideoID provides call-center functionality, where trained support agents can verify the validity of the provided identity papers and ask security questions to the end-user during a live video call.

This may be german law specific, the overarching EU Legislation can be found by googlign "qualified electronic signature".

In general they require complete, verified cryptographic signatures via smartcards or similar but because no one uses it, videoident has become the defacto alternative in germany

That's a misconception. Most contracts or form-free and can be made by handshake if one wants to. There are however some exceptions, which require either physical signatures or the qualified signatures as declared by eIDAS. Those exceptions are some employment contract and most things related to banking.

The need for identification over video, etc., has more to do with the know-your-customer laws.

Most physical bearers (smart card or similar) of a Qualified Certificate are issued in person or based on a known identity. Here there is no need for remote identification before the issuance of the certificate.

What you are talking about is a “remote signature service”. Such a service will often onboard a user remotely using a physical ID, video and liveliness checks and give them the credentials to produce advanced or qualified electronic signatures with the service in question. These credentials have to meet LoA Substantial or High for a QTSP to be able to issue a QC to a user. Most remote signature services use very short lived certificates (10-15 minutes) that are created for every signature the user produces. (As opposed to the long lived certificates of several years for a physical card).

Germany have to follow the eIDAS-regulation as a member state of the EU/EAA. But what level of signature is needed for what transactions is not regulated in the eIDAS.

> But what level of signature is needed for what transactions is not regulated in the eIDAS.

Yeah, its the issue that germany decided that only the QES is as legally binding as a physical signature and then they made a whole bunch of contracts, especially work related stuff require physical signatures

Hi Alex. Would you be interested in help running this as a non profit like Let’s Encrypt, but for digital signatures? I would be willing to contribute both financially and infra/DevOps/biz ops to bootstrap.

It's hard to say at this point if something like Let's Encrypt can exist in this space - but I'm for sure going to continue offering a free Cloud SaaS option with a generous set of features for document signing. I'd love to chat to explore more about the potential non-profit solution - please feel free to drop me a line at alex@docuseal.co

I’ll reach out shortly. My thoughts on this are you don’t remain free, but instead charge based on a cost recovery model. You figure out annual people/tech/admin expenses, forecast and observe request volume over time, and then adjust per signing request pricing accordingly (or perhaps sell buckets of requests to high volume consumers, contracts ensure smooth cashflow). This enables longevity and stability of the service (which gives warm fuzzies to consumers of it), no concern of an acquisition or buyout, while enabling servers to spin and people to eat.

TLDR think electric cooperative or similar. You’re building an internet utility/primitive for long term consumption.

I run a small tech nonprofit (see profile) and have also been unsatisfied with DocuSign and alternatives in the past. I'd be happy to help if I can be useful here, either with hosting (and PKI) or with development directly.

Thank you for creating this and making it open source.

What mechanism(s) is used to ensure non-repudiation?

I appreciate that the demo is not behind a sign up wall, but is account creation and email verification required for invitees to sign any documents?

Are IP addresses stored as part of the digital signature?

Any other mechanism?

IP addresses and browser User Agent strings are stored for each signature/submission - those are the only measures for 'non-repudiation' currently available.

but i think it doens't differ from other mainstream SaaS solutions - if you read through their terms of services - they put 'non-repudiation' liability on users of their services

Those are both unfortunatly trivially faked

And yet it's the standard practice for normal people.

From my research this has 0 legal validity, at least in germany in regards to the EU eIDAS. They are just smoke and mirrors for companies to make them "feel" secure but without cryptographic ensurances (Advanced Electronic Signature) or TLS like Signed Cryptography (Qualified Electronic Signature) this is just as legally binding or not binding as an E-Mail

> just as legally binding or not binding as an E-Mail

Which is legally binding. In Germany most contracts are free-form contracts (Formfreiheit) and only need declarations of intent in the form of offer and acceptance. This can be a handshake or even a head shake.

Or perhaps even an emoji reaction in a text chat, as described elsewhere itt.

Unless you are a qualified lawyer it would be polite to begin a comment like this with IANAL.

IANAL but in the common law world a contract requires 3 things:

* Offer and acceptance

* Consideration (something of value)

* An intention to form legal relations.

Acceptance is, of course, what a signature signifies. Acceptance is "a matter of fact" and thus in reality pretty much anything will do.

Yeah, it’s not like in the spirit of the law you can perform your part of the contract and then get away with saying “I never agreed”.

In the US, we have a federal law that covers electronic contract signing. I believe it’s part of the UCC? (I’m not an attorney, and that area isn’t one I practice with in tech either.)

Signatures are pretty easy to fake too, because basically noone verifies them.

In practice, the security involved only has to reach the "good enough" threshold and not a 100% hack proof level.

Another method you might consider implementing would be identity verification via SMS code. I've experienced this with docusign: https://support.docusign.com/s/document-item?language=en_US&...

It requires you to know the phone number of the signer, but for important stuff you typically do.

Yep, support for SMS verification will be added eventually with ability to bring own Twilio credentials when self-hosting it.

One of the tough things about a party-controlled, self-hosted e-signature is that it becomes easier to repudiate because a party to the contract has custody of the platform.

The non-custodial party can claim they never signed, and when the custodial party produces evidence of IP address and timestamp, the non-custodial party may have a credible argument that they are faked and the person asserting those authenticated details has the motive and means to fake them.

That argument is much harder to assert with something like DocuSign because it is unlikely DocuSign would put their business on the line to fake someone's signature.

I'm not saying repudiation based on custody of the e-signature platform is a winning argument, but it's something to consider before self-hosting if you are going to use the platform to sign your own contracts.

If only someone would invent a public nonrepudiatable ledger.

Like a chain of blocks? Where each block is signed by adding a prefix that produces an increasingly difficult hash?

someone should combine a chain of blocks for identity management with one for financial transactions/tokens and one for signature attestation. We could call it the cube chain and usher in web 4.0.....

Wait... You're talking about Git, right? Brilliant idea! You could sign a pull request, and once it's signed, you can then merge the businesses. But how do you show a diff of the signature? And what if it's not for a corporate merger?

That’s just crazy talk. Corporate mergers are the only transactions there are!

But what keeps someone from forking your git repository and insisting that their HEAD is the source of truth? How can we get a globally agreed upon source of truth?

It could probably be done with a merkle based signature log that whoever is hosting the service could provide.

To cheat, the party hosting it would probably have to forge signatures for everyone after the disputed signature.

As long as we're talking about non-cryptographic-signatures, the party hosting the e-signing software can claim any signature to have happened at any time. The whole point was DocuSign would be unlikely to do this.

I have Zero Knowledge about this topic

The problem is that it would require everyone to monitor the ledger for falsified versions of their own signature. That works a lot better in the world of Certificate Transparency where Google can scan for google.com registrations. It does not scale well to every human being doing that, or outsourcing it.

The fundamental challenge here is that there's no way to tell, based on a the signature alone, which signatures are "valid" and which are "forged"; they're not cryptographic signatures. And getting cryptographic signatures for lay people is apparently too hard to do, outside of Estonia's digital citizenship initiatives.

It might be neat if the big guys agreed on an OIDC extension that let you piggyback text to be affirmed by the user. Cryptographic proof that jane.doe@gmail.com saw text with hash H at time T and chose "Accept".

Your pointing it out like this should be be obvious, and it is. Yet Blockchain has not become a mainstream use case here.

> That argument is much harder to assert with something like DocuSign because it is unlikely DocuSign would put their business on the line to fake someone's signature.

This seems like the claim that the USG will be unlikely to put it's Military on the line so they won't leak any tank designs on discord.

Happy to concede that the CEO of DocuSign wouldn't do this but surely some 15$/h employee doesn't have that same opinion.

The support person should not have that kind of access without auditability and traceability. Even Sundar should not be able to log into a console and read your emails either.

Sure but that's a different argument than the one presented above.

Someone implied that counterfeiting a sig or altering one, etc. was just as easy in Docusign as it would be with on on-site one-party controlled system. It just isn't.

Yeah, I really like this initiative, but this is not a technology problem. This is a trust problem. The EUJ actually has a not-terrible framework in place around electronic signatures, and _some_ countries are pushing hard for adoption and implementation.

Only if we can use our Yubikey to sign the document...

I am involved with two nonprofits that need to have an easy way to get many non-technical people to sign a document. Each is paying for their own DocuSign account. The thing is, they only need to do 6-12 documents per year each, so the cost per document is insane.

Testing it now with fingers crossed and hoping that the cloud version sticks around.

Darn. I created a document, setup the info for three sigs, added the recipients emails and then it was unclear how to push it out. I guessed at "Submit it yourself," which required me to add my email so I used the first recipient's and then it opens the doc for me to fill out. It asks for full name and then when I submit, "next" just keeps spinning. FWIW, I am running FireFox with UBO, etc.

This is really important to me, so I'd be glad to work with you to troubleshoot and provide detailed user feedback.

The emails are automatically sent to the recipients after you submit the modal window to add them (there should be 'SENT' status displayed next to their emails)

Regarding the form issue - it looks like some js client side bug - i'll try to investigate this.

I was going to try it with Safari, but it didn't recognize the account that I created earlier in FF...

Looks like great work for a 2 month project

Thanks

> Looking for some feedback and would be happy to answer any questions

It would be great if you could add support for AWS QLDB. It's an immutable blockchain database (basically, "git with an SQL interface"), and you can periodically "stamp" it by notarizing its hash with one of the public blockchains.

This way you can guarantee that the records are going to be immutable and unalterable.

thanks, i think that's an interesting space to explore. there were many comments regarding the 'consistency' of the data/documents so solving this 'trust' issue especially when selfhosting it is really important

I love the fact that this exists, however my major concern is that because this is self-hosted, in the event of a dispute, the other party can claim that I forged the document. In such a scenario, how would I ever prove that I didn't?

When self-hosting it it's possible use merkle tree to ensure the documents integrity (similar to how git works with its commit hashes). So to forge one document it will require to change all document hashes after the disputed document making it impossible to cheat by the organization that is self-hosting it. This will be added into the project soon.

https://en.wikipedia.org/wiki/Merkle_tree

Alternatively I'm thinking about adding a third party AWS QLDB integration - QLDB allows to maintain an immutable, cryptographically verifiable log of data changes.

This looks great. What's the best way to contribute a translation?

I think a great feature would be an email with a confirmation link after the pdf gets signed to ensure the owner of the email was the person who signed the document, if the link share option is used.

That's a good idea! will definitely add this feature to the project

Hi Alex. First of all, congratulations. The product looks great for a 1.5 month worth of dev work. Impressive.

Is it possible at the moment to send signature requests via WhatsApp? (even at a cost per send)

It's not possible at the moment - but i've been planning to add this feature to use phone number and text messages (including WhatsApp) as a second layer of authorization when signing docs. Stay tuned!

If it's a US phone number, you can send an email to the phone number:

E.g. for T-mobile it is @tmomail.net.

> - File storage on AWS S3, Google Storage, or Azure

I'm guessing it's just a mistake/miss in this comment, but for file storage it is also possible to store it locally on the server right? Otherwise all "editions" are "in the Cloud" yes or yes, so would kind of defeat the purpose of the self-hosted version.

It's possible to use local storage or Aws s3, Azure, Google Cloud to store files. When storing locally it makes all the documents 100% owned by you - but in some cases companies might want to bring a third party files storages to ensure the integrity of the documents.

But as was mentioned before in the comments - maybe bringing AWS QLDB as a third party to ensure the consistency of data with a local files storages is the best option. This way all documents can be logged with a third party so they can't be altered - while to content of the documents won't be shared with any third party.

It's not perfect for a single person just using it for themselves (a lot of workflows seems very company/team oriented), but it's still better than nothing which is what I had before. Thank you for open sourcing it, this will absolutely help me :)

Thanks, please feel free to open an issue with your suggestion to improve the tool at https://github.com/docusealco/docuseal/issues

> DocuSeal can be self-hosted on-premises or used in the Cloud for free.

Charge something for the cloud product. If you feel your product is good, then don't give it away for free. Your product charges will help sustain future development down the road.

Does it comply with US regulations for e-signatures? Otherwise, what's the point to have a signature that is not legally binding?

That is the whole point of signatures. Otherwise it is just an image editor.

The E-Sign Act grandfathered in existing agreements that existed digitally prior to Oct. 1, 2000. All agreements after this date, however, must comply with the following set of guidelines in the E-Sign Act to be considered legally binding:

- Intent to sign. Electronic signatures are only valid if the involved parties have the intention to sign. Signature requests can be declined.

- Consent to do business electronically. Involved parties must agree to conduct transactions electronically.

- Attribution. The signature must uniquely attribute to the individual signing the document.

- Association of signature with the record. E-signatures must have a mark on the document from the signer that can then be associated with the record.

- Record retention. Electronic documents must be savable, viewable and printable by either party.

I think the tool provides all that - usually when working as a contractor i've been signing documents in PDF viewer and sending them back via email and that was what my clients wanted me to do. Tools like DocuSeal are making the process of signing docs easier than doing it via email.

And how do you achieve this with this?

How secure is it? How confidential are the records? How does it guarantee integrity?

When self-hosting it - it's up for the company that is using the tool hosted on-premises to ensure that all their specific requirements are met - i think DocuSeal provides enough features to make this happen.

AWS S3 to store documents can be integrated with DocuSeal to ensure the documents integrity - AWS services have their own logs that can't be altered and so can be used as a source of trust.

And to ensure that the document was signed by a real person companies can include photo attachments into the documents signing process (this could be a photo of an ID card or a selfie)

Then it is the most toxic thing you can ever self-host. I will gladly pay any company to get all the liability on my behalf.

This is the "I have a friend that does it cheaper" of e-signature solutions.

hey. do you have support for pfx based signatures like jsignpdf does?

Currently it’s possible to sign documents only using the autogenerated pkcs7 certificate in self-hosted DocuSeal (it’s done automatically be default).

But it should be doable to make it work with different certificate formats to bring your own certificates.

I’d be happy to explore those options and would appreciate it if you could open on issue on GH in case you’re interested to have this supported this in the tool.

Thanks for nice work. Will be checking it out and most likely using IRL if works as advertised.

Reply on news.ycombinator.com