Re: Digital Signatures for Credentials

Having [also] dipped my toes into this subject it is good to know
that most s.c. standards have a certain origin which has colored
the work in a certain way, JOSE grew out from OpenID and REST which
required "URL-friendly" signatures.

The JOSE folks claims that JSON's lack of a canonical form makes
Base64-encoded payloads the only "safe" bet for signatures. This
is true based on the JSON spec. but not based on implementations:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcsbrowsertest.html

Anyway, for those who (like me) come from the XML/XMLDSig-world and
want to convert to JSON, the JOSE standards represent a step back.
A dual-signed message like the following would be downright horrible
to document and debug if encoded in JOSE:
https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserAuthorizesTransaction

The JSON signature used the sample only required some 20 lines of
JavaScript and no library so there will obviously be multiple JSON
signature schemes regardless of what the IETF, W3C etc says!

Dressing JSON-LD in JOSE would IMO be a very strange thing to do
so it (IMO) more boils down to if you use JSON-LD or not.

Cheers
Anders

On 2014-11-17 03:32, Manu Sporny 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
>

Received on Monday, 17 November 2014 05:52:40 UTC