Digital Signatures for Credentials

During the call last week, we touched on the last major item (digital
signatures) that needs to be aligned between the Badge Alliance
technology stack and the Credentials technology stack. Like all
technology, there are upsides and downsides to each approach. I thought
I'd try and summarize them in this email.

The Credentials technology stack[1] focuses on extensibility via Linked
Data / JSON-LD and thus uses a digital signature mechanism that was
built for graph-based data.

The Badge Alliance technology stack had focused on pure JSON data and
re-using the IETF's JOSE digital signature stack. I've written about
Digital Bazaar's concerns with JOSE before[2].

In general, both technologies allow a developer to:
* Digitally sign data
* Verify digitally signed data
* Express public/private keypairs
* Encrypt and decrypt data in message envelopes

In this respect, neither technology is that different from what XML
Digital Signatures enables one to do.

Both SM and JOSE use JSON as the basic container format due to JSON's
popularity with developers. When comparing the SM vs. JOSE technology
stacks, here are some of the key pros/cons:

JSON-LD Secure Messaging Pros:
* Clear-text signatures (easier to see/debug what's going on)
* Works with any RDF syntax (N-Quads, TURTLE, etc.)
* Ensures discoverability of public keys via the Web
* Simpler interface for Web developers
* Extensible message format due to JSON-LD
* Designed to integrate cleanly with HTTP Signatures
* Identified as a need for both the Social Web WG and
  Web Annotations WG due to dependence on JSON-LD

JSON-LD Secure Messaging Cons:
* Not an official standard yet
* Graph Normalization algorithm is hidden from developers, but
  very complex

JOSE Pros:
* First mover advantage
* Already an IETF standard with thorough security review
* More software libraries exist for JOSE

JOSE Cons:
* Signed data is an opaque blob, which is very difficult to try and
  debug
* Fairly difficult to use for Web developers due to exposing too much
  complexity
* Format is not extensible, requires coordination through IETF
* No standardized public key discoverability mechanism

The biggest downside with the SM approach is that it's not a W3C
standard yet and that will take some time (1-2 years). The technology is
done and there are multiple interoperable implementations out there, so
we're not concerned about it not getting through the standardization
process once it enters the process. With the recent hallway discussion
at W3C TPAC, we feel that we should be able to get the minimum number of
W3C member votes necessary to take the specs REC-track.

So, with that introduction - are there any thoughts on SM vs. JOSE? Does
anyone feel that strongly one way or the other? Any pros/cons that are
not in the list above that should be?

-- manu

[1] http://opencreds.org/specs/source/roadmap/#technology-stack
[2] http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0004.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Monday, 17 November 2014 02:32:40 UTC