- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 03 Nov 2011 02:05:41 -0400
- 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
Internet.
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
https://github.com/
Click on the padlock icon next to the location bar and you will see this
message:
"""
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
VERIFICATION]]]
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
SIGNATURE VERIFICATION]]]
"""
> 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
Authority.
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
signature.
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
http://manu.sporny.org/2011/payment-links/
Received on Thursday, 3 November 2011 06:06:12 UTC