I don't like the idea of this using bitcoin. I wonder if it's possible to build this off of regular PKI - certificate transparency logs for instance encode the proof of commitment, while the signature can be an X509 certificate.
Loved it until I saw its using Bitcoin.
With proof of work doesn’t it tie this project to a bit of an environmental nitemare? Bitcoin isn’t the best place for this, no?
I would have imagined Ethereum or some other ledger would have been better no?
Anyone with more crypto ledger knowledge be able to say what I’m trying to say more precisely.
Nice idea but with all related things the ultimate question remains whether courts will actually recognize it.
Currently courts will still consider paper-signed and scanned PDFs as legally binding, so any verification on top of that is superfluous to them.
More realistically, you take an oauth when you take the stand at the court, and if a signed document was altered by the counterparty you'd say so truthfully, if it weren't, you'd say so truthfully, and the penalty of that oauth purjury is high enough that most people wouldn't do it. Cryptography not needed.
Looks interesting, but in order to actually compete with any e-signing platform you'll at the very least need to have templates with pre-filled information, an API to autofill docs with required information, and more field types. Right now for example, you can only add text, checkbox, and date/signature fields. Checkboxes are required to be checked (no making them optional), so if there are multiple checkbox options, they have to check them all to continue. Not very useful for actual e-signing flows.
Tried to poke a little to see if I can find any name (I could not). Challenge with this domain is the TRUST anchor. As an organization/company you have to establish yourself first (directly or through reference) otherwise its hard for anyone to trust you.
It’s a neat proof of concept, but it’s hard to see the organizations that care about certified documents adopting this. Inherently conservative. Let’s Encrypt invested a lot in their early partnerships and used that to sneak up on the conservative buyers and trusters of certs.
What I think you're trying to say, but don't seem to be getting across super clearly, is that this standard hasn't yet gone through an open third party review
The idea makes sense in principle I think, and but I'll be chewing on it a bit, haha. Seems like a solid standard, but you know how standards go.... (Relevant XKCD: https://xkcd.com/927/)
I like that you kept a lot of the same commands/naming/syntax from LetsEncrypt. As someone familiar with LetsEncrypt, makes me feel like I'd slide right in here easily.
I'd like to learn more about the 'Bitcoin anchored root'...is that part of RFC 6962 or something else entirely? Do you mean a 'Bitcoin-like blockchain' or are you using the actual BTC chain? Could you point me in the right direction?
I don't like the idea of this using bitcoin. I wonder if it's possible to build this off of regular PKI - certificate transparency logs for instance encode the proof of commitment, while the signature can be an X509 certificate.
Loved it until I saw its using Bitcoin. With proof of work doesn’t it tie this project to a bit of an environmental nitemare? Bitcoin isn’t the best place for this, no?
I would have imagined Ethereum or some other ledger would have been better no?
Anyone with more crypto ledger knowledge be able to say what I’m trying to say more precisely.
Any benefits over DocuSeal?
https://github.com/docusealco/docuseal
I love the concept, it would be great to see broader uptake of an open standard for this sort of space.
Nice idea but with all related things the ultimate question remains whether courts will actually recognize it.
Currently courts will still consider paper-signed and scanned PDFs as legally binding, so any verification on top of that is superfluous to them.
More realistically, you take an oauth when you take the stand at the court, and if a signed document was altered by the counterparty you'd say so truthfully, if it weren't, you'd say so truthfully, and the penalty of that oauth purjury is high enough that most people wouldn't do it. Cryptography not needed.
This depends completely on the jurisdiction. This is simply not universally true.
Looks interesting, but in order to actually compete with any e-signing platform you'll at the very least need to have templates with pre-filled information, an API to autofill docs with required information, and more field types. Right now for example, you can only add text, checkbox, and date/signature fields. Checkboxes are required to be checked (no making them optional), so if there are multiple checkbox options, they have to check them all to continue. Not very useful for actual e-signing flows.
Tried to poke a little to see if I can find any name (I could not). Challenge with this domain is the TRUST anchor. As an organization/company you have to establish yourself first (directly or through reference) otherwise its hard for anyone to trust you.
It’s a neat proof of concept, but it’s hard to see the organizations that care about certified documents adopting this. Inherently conservative. Let’s Encrypt invested a lot in their early partnerships and used that to sneak up on the conservative buyers and trusters of certs.
I'd be very careful with this. Looks to me like an invented standard: https://letsseal.org/site/standard
Aren't all standards "invented"? Do you want to say that there is no an RFC page for the protocol?
Sure, lets say this lacks an RFC/ISO number, or any semblance of what is usually called a standard.
What I think you're trying to say, but don't seem to be getting across super clearly, is that this standard hasn't yet gone through an open third party review
Is this PAdES B-B only? As far as I know, PAdES B-T requires a QTSP timestamp.
Poked around a bit..excited to see where this goes.
Just a quick note, Under "Get help from the community > Disucssions", there's a 404 to https://github.com/letsseal/letsseal/discussions .
The idea makes sense in principle I think, and but I'll be chewing on it a bit, haha. Seems like a solid standard, but you know how standards go.... (Relevant XKCD: https://xkcd.com/927/)
I like that you kept a lot of the same commands/naming/syntax from LetsEncrypt. As someone familiar with LetsEncrypt, makes me feel like I'd slide right in here easily.
I'd like to learn more about the 'Bitcoin anchored root'...is that part of RFC 6962 or something else entirely? Do you mean a 'Bitcoin-like blockchain' or are you using the actual BTC chain? Could you point me in the right direction?
It's the actual BTC chain, it's based on https://opentimestamps.org