Re: Digital Signatures for Credentials

LD.

IMHO - Linked-Data is an important ingredients in the lifecycle broadly.

On 17 November 2014 13:32, Manu Sporny <msporny@digitalbazaar.com> wrote:

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