Re: Digital Signatures for Credentials

Manu +100 for a opening the door for the discussion and laying down the
facts.

I'm in agreement with Timothy - LD is an essential component for credential
stakeholders. Not all credentials will be alike, nor should they be.
Having the ability offer a context is key to broad adoption of the
specification.  Furthermore, producing signed credentials is critical to
building trust throughout the ecosystem.

IMHO - having to require coordination through IETF for extend the the
format is a "deal killer" for me.  And, why would we support such a method
when JSON-LD (a W3C standard) already addresses this issue.

Eric


*"Trust only credentials that are TrueCred*™ *verified."*
----------------------------------
Eric Korb, President/CEO - accreditrust.com
GoogleVoice: 908-248-4252
http://www.linkedin.com/in/erickorb @erickorb @accreditrust

On Mon, Nov 17, 2014 at 6:41 AM, Timothy Holborn <timothy.holborn@gmail.com>
wrote:

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