Re: The Argument for Digital Signatures

Good approach and start of the debate.

My comments on the 5 reasons are:

* Decentralized Design

Good reason

* Independent Verifiability

Good reason

* Legally Enforceable via Legislation

Sorry, digital signatures don't really help here and might harm. Most
countries have legislation similar to the E-Sign act, that protect what is
called electronic signatures. These are a lot more low tech than say
digital signatures and include just hitting the accept button on a web
form. Server logs and emails are what currently count as proof here.

In the EU and many other countries there is specific support for Digital
Signatures, but most of them build up a complex requirement for a licensed
public key infrastructure, that just hasn't been built up even now more
than 10 years after the approval of the laws. There is an argument that for
places like the EU a traditional Electronic Signature is safer that making
up your own PKI.

At the very least traditional proof should be stored as well until the
judiciary branch becomes sophisticated enough to deal with digital
signatures.

* Secrecy

This we don't get for free with Digital Signatures, it introduces even more
complexity into it. It also means that a receipt can't be verified if the
user looses his key. I don't mind it being an option, but it shouldn't be a
requirement.

* Data Portability

To me this is pretty much the same as the decentralized design and I agree
that for technical reasons digitial signatures can be a good idea.

Usability

The very biggest problem of all is that no one has solved the usability of
digital signatures except in closed systems such as Skype.

Digital signatures are fine anywhere where it is a server signing
something, such as a receipt. But in creating a transaction no way. This is
why I strongly believe in the approach we have taken with OpenTransact to
use OAuth 2 for the transaction creation aspect of it.

http://www.opentransact.org/core.html#transfer-1

We have talked about using optional digital signatures for receipts. In our
discussion it is the asset provider (eg. a PaySwarm authority) that signs
the receipt. I suppose a third party service could also sign the offer and
a sophisticated seller could do the same.

The new JOSE (JSON Object Signing And Encryption) group in IETF is doing
good work in this area and should definitely be looked at for receipts and
other signed objects.

http://self-issued.info/docs/draft-jones-json-web-signature.html

This comes out of the OpenID connect work and provides a really interesting
approach to creating small signed and/or encrypted objects to be passed
along across the web. Thus fits our purpose well.

Pelle


On Wed, Nov 2, 2011 at 12:02 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> Hi all,
>
> We've had a number of teleconferences where the thought of using digital
> signatures in the solution has been brought into question. That is, the
> proposal has been put forward that a complete subset of the system be
> implemented such that no digital signatures are necessary. The primary
> thrust of the argument against digital signatures is that they're
> difficult to implement and the requirement of digital signatures may
> reduce the likelihood of adoption of the payment standard.
>
> I agree that digital signatures are more difficult to implement than not
> having them and I also agree that it may decrease the likelihood of
> adoption. That said, there are a number of reasons that we would like to
> propose the use of digital signatures:
>
> * Decentralized Design
> * Independent Verifiability
> * Legally Enforceable via Legislation
> * Secrecy
> * Data Portability
>
> Decentralized Design
> --------------------
>
> Let's start from an ideal scenario - ideally, PaySwarm would be
> completely decentralized. That is, a single person could play the part
> bank, transaction processor, and account holder. That is, you are
> beholden to no-one when it comes to managing your money. Additionally,
> all assets that can be transacted on the network can be expressed
> /anywhere/ on the web and the ownership claim of that asset can be
> traced back to the person making the claim. So, centralization in both
> of these cases is a bad thing. But how does one make claims on the Web,
> across multiple websites, in a way that is secure and resistant to
> forgeries?
>
> Typically, one leans on digital signatures to do this. I know of no
> other way, other than centralizing the asset listing service and/or
> centralizing the banking service, to accomplish this. So, if we are
> going to hope for a decentralized design, we must depend on digital
> signatures or come up with an alternate technology to achieve this goal.
>
> Independent Verifiability
> -------------------------
>
> Digital signatures allow for independent verifiability of claims. That
> is, how do you know if a particular set of claims were actually made by
> the person that the message says it is from? Keep in mind that using a
> centralized service could achieve this goal, but then you have to hand
> over the ability to understand a lie from the truth to a 3rd party.
> That's not necessarily bad, if you trust the 3rd party, but that 3rd
> party will probably end up using digital signatures anyway.
>
> So, in order to verify the sender of messages - you need some sort of
> digital signature.
>
> Legally Enforceable via Legislation
> ------------------------------**-----
>
> Contracts bearing digital signatures are legally enforceable in many
> industrialized nations. The argument has been made that courts don't
> care about this detail, rather focusing on the intent behind the
> transaction. While that is true to a certain degree, having a legally
> binding contract isn't a terrible thing to start out from, especially if
> the system needs digital signatures anyway as a part of it's standard
> operating protocol.
>
> Also, if we hope for this system to be usable by business, being able to
> say "This contract is legally enforceable in the USA via the ESIGN act
> of 2000" is better than not being able to say that. The knowledge that a
> contract has signatures on it that can be traced back to a business or
> individual is a strong incentive for people to behave and not get to the
> point where they're in a court of law disputing a contract. That is,
> without a digital signature on a contract - I can always claim that the
> contract was forged and I never agreed to the transaction.
>
> Secrecy
> -------
>
> If we implement Public/Private Key digital signatures, we get encryption
> for free, and we need that anyway to ensure the protection of messages
> as they travel across the system.
>
> To come at it from the other direction, we certainly need to protect
> messages flying across the network while also ensuring that site owners
> don't have to spend $30/year for an SSL certificate. That is, we need to
> have the ability to send encrypted data over regular HTTP connections.
> So, if we need that and we implement that... we have all of the tooling
> required for digital signatures.
>
> Data Portability
> ----------------
>
> Being able to move all of your money, account information, receipts,
> etc. from one place to the next requires that each digital contract,
> receipt, account information, etc. is portable from one system to the
> next. That is, you don't necessarily want to trust the person holding on
> to your data to verify that the data is valid. You want your financial
> history to look the same regardless of where it is stored. The validity
> of a digital contract / receipt should be asserted by the people that
> took part the transaction, not purely a 3rd party. Additionally, if
> digital signatures are not provided, and you port your data across more
> than 1 system, you lose the history of who made the claim.
>
> There are more reasons to support digital signatures, but I'll stop here
> and see what the feedback is on the arguments above. Keep in mind that a
> response with "we don't need digital signatures" will still need to
> address the issues above or define a subset of the system that those on
> the list feel is appropriate to implement without digital signatures.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Standardizing Payment Links - Why Online Tipping has Failed
> http://manu.sporny.org/2011/**payment-links/<http://manu.sporny.org/2011/payment-links/>
>
>

-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking