Re: [ba-standard] Considering the Open Badges crypto tech stack

Nate:

Thanks for bringing this important topic to BA community.  I have already
commented along with others in  W3C Credentials Community Group.  I suggest
that everyone interested in this topic to take a look at what CCG members
are saying as well:

http://lists.w3.org/Archives/Public/public-credentials/2014Nov/

   - Re: Digital Signatures for Credentials
   <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0011.html>
    *Eric Korb*
   - Re: Digital Signatures for Credentials
   <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0010.html>
    *Timothy Holborn*
   - Re: Digital Signatures for Credentials
   <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0009.html>
    *Anders Rundgren*
   - Agenda: Credentials CG Teleconference - Tuesday, November 11th 2014
   <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0008.html>
    *Manu Sporny*
   - Digital Signatures for Credentials
   <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0007.html>
    *Manu Sporny*

We hope to see BA members join the W3C Credentials Community Group here:
http://www.w3.org/community/credentials/

Eric


On Mon, Nov 17, 2014 at 12:51 PM, Nate Otto <nate@ottonomy.net> wrote:

> Hi all:
>
> As part of the BA's collaboration with the W3C Credentials Community Group
> <http://opencreds.org/>, we are considering what the whole tech stack
> looks like for Open Badges as they will work with other open credentials.
> Both the BA and the W3C CCG are envisioning a greater usage of
> cryptographically signed credentials in the future, even though right now,
> virtually all issuers are using the "hosted" method of Open Badge
> verification and are not digitally signing badges.
>
> The Identity Credentials that are core to the CCG come from the work the
> W3C Web Payments group has been doing for the last few years, and they
> inherit the technology stack from that work, including JSON-LD and digital
> signatures via RDF graph normalization
> <http://json-ld.org/spec/latest/rdf-graph-normalization/>. The Open
> Badges signatures come from a different group of technologies, the JOSE
> group (which includes JSON Web Signatures and JSON Web tokens, which are
> used by signed 1.0 Open Badges).
>
> See an image of the technologies involved here, from a CCG presentation:
>
> http://opencreds.org/presentations/2014/tpac-wpig-ccg/images/technologyStack.svg
>
> It looks like Open Badges will fit well with other credentials expressed
> in JSON, and there could be some significant wins by integrating more
> closely with identity credentials, especially around allowing more options
> for the entities that issue and receive Open Badges. The difference in
> signing technology may pose some barriers to some of these wins though.
>
> With the adoption of JSON-LD for the 1.1 OBI standard, we are moving quite
> close to a compatible tech stack, except for this decision on digital
> signatures.
>
> Tomorrow morning (8am PST / 11am EST / 4PM GMT), the W3C Credentials
> Community Group is having our weekly teleconference to assess the
> possibility of aligning the signatures methods between these different
> credentials.
>
> Please take a moment to look over the documentation on signed 1.0 Open
> Badges and leave a comment here or I'm sure you would be welcome on the call
> <http://lists.w3.org/Archives/Public/public-credentials/2014Nov/0008.html>tomorrow
> morning. Unfortunately, I'm going to be on a plane and won't be able to
> make it.
>
>
> For more, keep reading:
>
> Introducing tomorrow's call, Manu Sporny wrote to the Credentials group
> mailing list:
>
>
>> 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/2013A
>> ug/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/
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "BA Standard Working Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ba-standard+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>