informalsystems/themis-contract

Eliminate keybase dependency

Closed this issue · 6 comments

shonfeder commented

We've seen in numerous cases that mandatory and by-default Integration with keybase introduces lots of failure points and complexity. Here are the cases that come to mind:

  • Users not knowing how to obtain their 70 char keys
  • Users not having keybase accounts or not having access to them at remote locations
  • Difficulty with containerization

For our current needs, it seems like making this integration an opt-in addition would be more expedient.

This was discussed in our walk through last week.

thanethomson commented

So I've been pondering this whole contract signing thing and I'm now tending towards the possibility that we may have to eventually make the Keybase integration mandatory and the only way to sign contracts (or perhaps allow GPG).

My skepticism of doing away with Keybase/GPG (or even making it an optional "nice-to-have") comes from asking the following questions.

  • How do you know if someone's actually "signed" the contract? i.e. what constitutes a valid and verifiable act of a specific individual signing the contract?
  • Is some rendered text, maybe in a nice cursive font, of a person's name enough to constitute a signature, and couldn't that be incredibly easily faked?
  • Does the Git commit history constitute part of the signing record and, if so, how does one transfer the properties of that record to a printed version of the contract? (i.e. does the printed version lose the verifiability of signing)
  • If we don't store the record of the act of signing within the contract itself, where do we store that record in a way that's accessible to anyone who wants to verify the authenticity of the signature?
shonfeder commented

IMO, it is quite clear that there has to be way to opt out of using the keybase integration, at least while we're still at the early stage of prototyping. It just causes too much friction at every level.

However, this is absolutely not to say we shouldn't plan on making this required in the future! As soon as we can ensure a smooth, stable, and reliable process the also carries these added guarantees, we should totally do so!

However, iiuc, currently we only need to be at least as easy to use as DocuSign and produce results that are no worse. Does DocuSign secure the identity of signatories via keybase or PGP keys? I don't think so! We would also work with contracts that were physically signed and emailed in, and that has none of the protections either.

thanethomson commented

I'm just trying to enumerate, practically, what alternative "act of signing" we can use in the interim. The possibilities I can see so far for the prototype:

  1. Pre-generate and commit an image containing the signatory's full names in a font of their choosing. (A signed Git commit here acts as a "good enough" historical record, as long as the commit history is kept intact). In this case the sign command would handle the Git add/commit on behalf of the user. If we want to get fancy here we could also embed a partial SHA256 hash of the source contract into the image.
  2. Use Keybase/GPG for cryptographic signing (and make this optional).

For option 1 we're assuming that a user is going to be signing the contract in a Git repository, which I think is a fair assumption for now.

However, iiuc, currently we only need to be at least as easy to use as DocuSign and produce results that are no worse. Does DocuSign secure the identity of signatories via keybase or PGP keys? I don't think so! We would also work with contracts that were physically signed and emailed in, and that has none of the protections either.

Being a centralized service, it looks like DocuSign stores metadata associated with each and every act of signing and ties each act to a specific user account (with associated e-mail address). It also generates some kind of partial hash for the document and each act of signing (not sure what those are, but they may somehow be verifiable through their service when all you have is the printed version of the contract).

Ideally I don't ever want to go the route of having a centralized service for tracking acts of signing.

shonfeder commented

Whoop! Didn't meant to close or comment! :D

ebuchman commented

Just a note that I regularly sign contracts by downloading pdfs, adding an image of my signature, and sending an email. This is legally binding as far as I understand.

The other option is to use a cursive version of the name, like docusign. This is also legally binding so long as there is an active opt-in. We can probably satisfy that with some kind of explicit --allow-cursive flag at the command line or setting in a global config file.

As for keybase, we do not need to and thus should not support it right now. Our existing contract flow does not involve any form of cryptographic signing, and our first goal is to replicate our existing contract flow. Any discussion or thought around cryptographic signing is likely to be a distraction from that. So let's please not even make it optional. We shouldn't be thinking about it at all. Once we have signed say 10 real world contracts with the tool in a way that's better than what we were doing before, we can start thinking about keybase again.

  • 👍1
thanethomson commented

Keybase support has now been removed in v0.2 (currently on branch prototype/v2).