W3C home > Mailing lists > Public > public-credentials@w3.org > November 2014

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

From: Sunny Lee <threeqube27@gmail.com>
Date: Mon, 17 Nov 2014 10:19:33 -0800
Message-ID: <CA+JncYKvzEgf0AuuaHGbpJrrgvsh15tBSLznaHc4N1t9vp+35w@mail.gmail.com>
To: ba-standard@googlegroups.com
Cc: public-credentials@w3.org, Brian Brennan <brian@mozillafoundation.org>, Manu Sporny <msporny@digitalbazaar.com>, "openbadges-dev@googlegroups.com" <openbadges-dev@googlegroups.com>
Adding the openbadges-dev mailing list to this thread for good measure.



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

> 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.
Received on Tuesday, 18 November 2014 16:32:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC