W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2011

Digital Signature Usability (was Re: The Argument for Digital Signatures)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 03 Nov 2011 02:05:41 -0400
Message-ID: <4EB22F35.6000203@digitalbazaar.com>
To: public-webpayments@w3.org
> 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.

I strongly disagree with your statement here. It's provably false, case
in point: HTTPS utilizes digital signatures, which every e-commerce site
uses to secure traffic. Hundreds of millions of people a day /directly 
use/ digital signatures... it's just that nobody really knows that this 
is happening behind the scenes.

To claim that no one has solved the usability of digital signatures 
problem is hyperbolic, IMHO. We depend on digital signatures for our 
world-wide Certificate Authority infrastructure and we depend on digital 
signatures for the vast majority of SSL/TLS connections made over the 

More specifically, the Key Exchange Method in TLS has a provision in it
for using RSA key exchange, which utilizes digital signatures to protect
against Man-in-the-Middle attacks. Use Google Chrome and go to


Click on the padlock icon next to the location bar and you will see this 

GitHub, Inc. (github.com)
The identity of GitHub, Inc. at San Francisco, California US has been
verified by DigiCert High Assurance EV CA-1. [[[DIGITAL SIGNATURE 

Your connection to github.com is encrypted with 256-bit encryption.

The connection uses TLS 1.0.

The connection is encrypted using AES_256_CBC, with SHA1 for message
authentication and RSA as the key exchange mechanism. [[[DIGITAL 

> Digital signatures are fine anywhere where it is a server signing
> something, such as a receipt. But in creating a transaction no way.

What is the reasoning here? You claim that digital signatures are 
impossible for a transaction, but then don't back up the argument with 
the reasoning.

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

In our system an asset provider is not the same thing as a PaySwarm 

An asset provider is an entity that is selling something, like a song, 
blog post or article.

A PaySwarm Authority is an entity that is handling the transaction (and 
transfer of money from source to destination accounts.

The asset provider performs digital signatures on assets (things for 
sale) and listings (the terms under which the sale can occur).

You are correct in that the PaySwarm Authority is the one that digitally 
signs the receipt... but there are more advanced use cases (such as 
contract negotiation - negotiating for a certain price, for instance) 
where the contract offer can be submitted directly from the customer to 
the vendor. That is, each party in a transaction may perform a digital 
signature to establish trust in the transaction.

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

We had a look at the latest specs when they released an update to them a 
few days ago.

The short of it is that JWT, JWS and JWE is insufficient for our use 
cases due to the following reasons:

1) JWS only secure and sign messages as a part of the HTTP Header - the
    signature is out-of-band from the data, which means that a program
    must be able to extract data from the headers and apply them to the
    body of the document. This is more complicated than just processing
    the body of the document.
2) JWS signatures are not applicable to graphs of information (RDF) -
    there is no normalization protocol. Even if there was a normalization
    protocol for JSON key-value pairs, it wouldn't work for graphs of
    information. Since there is no normalization protocol, you have to
    have the original data structure to verify its hash or
3) JWS is more complicated than it needs to be - supporting every
    hashing, signature and encryption mechanism is a non-goal for
    PaySwarm because it makes the spec much more complicated than it
    needs to be.
4) JWS objects are not fully-contained documents. JWE objects are not
    fully-contained documents and thus, one must specify how to
    store the data in the JSON objects themselves. This is important
    because we expect that many implementations are just going to want
    to grab the JSON blob and store it directly into a database like
    MongoDB, CouchDB, or similar.

Signatures on JSON-LD objects address all of the shortcomings above... 
I'm sure we'll get into that discussion over the next couple of 
weeks/months. That is not to say that JWT/JWS/JWE are not useful, we 
have just found them insufficient for our use cases.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Standardizing Payment Links - Why Online Tipping has Failed
Received on Thursday, 3 November 2011 06:06:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:29 UTC