Comments (6)
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.
from themis-contract.
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?
from themis-contract.
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.
from themis-contract.
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:
- 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. - 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.
from themis-contract.
Whoop! Didn't meant to close or comment! :D
from themis-contract.
Keybase support has now been removed in v0.2 (currently on branch prototype/v2
).
from themis-contract.
Related Issues (20)
- Dockerfile
- Get rid of IDs for signatures/signatories and just use e-mail addresses HOT 2
- General project context/history questions HOT 4
- themis-contract new [path/to/template.md] HOT 2
- auto push & auto commit should be off by default HOT 1
- themis-contract compile [--update] flag HOT 2
- compile needs a sanity check for variables typos, etc. HOT 3
- do comments in the markdown get included as metadata in the rendered PDF ? HOT 2
- error when no upstream set in `contract.dhall` and running `themis-contract upstream diff`
- compile should have option to commit & push
- compile should bind the: signature+underline+name together HOT 2
- explore & document how to best use pandoc for optimizing .docx -> .md conversions
- compile panics when there is error in the mustache templating
- compile: change `dhall-to-json output` verbosity (on error) from DBG to ERR
- signing should insert the current date/time/hash alongside the signature
- Identify logical unit tags from commit messages as well as github issues and pull requests HOT 1
- [TRC-IMPL.2::PREFIX.2] Record tag implementatino relationships HOT 1
- compile will sign if the signature files are present in the directory HOT 2
- create an invoicing template
- `new` command fails when attempting to create Git repo
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from themis-contract.