- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Mon, 17 Nov 2014 22:41:14 +1100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAM1Sok1GFJByurQtHneFozZyEjHu3SkK0_5VSY70X7M47_2zKg@mail.gmail.com>
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/ > >
Received on Monday, 17 November 2014 11:41:42 UTC