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

Adding the openbadges-dev mailing list to this thread for good measure.

Thanks!

Sunny

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

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