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.

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.

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.

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.

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

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

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.

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

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?

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.

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

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 [email protected] saw text with hash H at time T and chose "Accept".

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.

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

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

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.

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.

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.)

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

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

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

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.

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

- 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.

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

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)

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

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

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

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

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.

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.

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.

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.

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.

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.

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!

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.

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

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.

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.