Re: Digital Signatures for Credentials

Having helped lead the planning of an enterprise integration platform built
on the JOSE technologies (realistically, just JWT was ready at the time), I
would add a couple points:

   1. JWT is very common in service account scenarios where the integrator
   needs a solid server-to-server credential store (i.e. Saleforce, Google,
   Microsoft).
   2. In these scenarios, integrators are dealing with some tough
   enterprise problems like user impersonation and service accounts. Are those
   topics considered as part of our JSON-LD as the digital signature method?
   Mind you those complexities are not easily put into specifications, so each
   vendor addresses them differently.
   3. Since it's so lightweight and easy to implement, there is little
   ability to add structure to the claims set. Sometimes the structure is
   valuable, other times it is a burden. You can add JSON Schema validation
   onto the JWT claim set (as one example), but at that point it's no longer
   simple to implement. JSON-LD may be a beneficial addition to the existing
   capabilities of JWT, even if it is not addressed here.

In my previous position, I had a goal to introduce JWE for our REST APIs to
correlate to the WS-* mechanism of signing and securing message payloads
because customers demanded stronger REST API security mechanisms. JWE
wasn't far enough along, but when we think of moving the world forward to a
better mean of identifying users for web application -- using HTTP versus
JSON is an interesting problem. When you look at WS-*, it was designed to
be protocol agnostic -- so HTTP signatures would not be a great fit because
other future protocols would be limited in their ability to use it. JOSE is
relatively immune to protocol specific bindings, so that may be something
you want to consider in the pros/cons list.

I don't have specific recommendations and always like the "better" thing,
but I did want to share a few things that makes the JOSE stack valuable to
systems integrators and helped spread it adoption so quickly.

Dale

On Mon, Nov 17, 2014 at 11:08 AM, Eric Korb <eric.korb@accreditrust.com>
wrote:

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