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

Hi all,

This is a fascinating consideration.

Although I tend to feel graph normalization (I say feel b/c I haven't done
the math myself) is a potentially efficient and secure signing method, I'm
hesitant to subscribe to a method tied to an application-layer protocol
(i.e., RDF seems bound to HTTP).

Earlier, we had discussed a method related to the BitCoin blockchain
algorithm, and this seems more general-purpose.

I'm not proposing an alternative here, just that we not jump the gun on
authentication of badges; perhaps start with authentication as an extension
and then promote what works best to a first-class member, or, provide a
facility for multiple methods.

Me, I'm old-fashioned. I like Diffie-Hellman PKI. It's not the fastest, but
we're not talking about real-time competency provenance via OBI yet, are we?

Also, we have a well-established infrastructure for verifying RSA keys
(follow the instructions in my .sig if you want my pubkey). Not that I'm
saying that's the best method, just that... well...

[image: Inline image 1]

Yeah... that.

I'm not offering a universal solution. Just warning against insisting upon
one.


Jason Lewis
CTO, Yet Analytics, Inc.
410.428.0253 // yetanalytics.com

My GPG key can be found via: gpg --keyserver pgp.mit.edu --recv-keys
0xc30a0d63c4b43758
Key fingerprint: 2E05 8E7E DAC2 F264 F0C6  23A0 C30A 0D63 C4B4 3758

On Mon, Nov 17, 2014 at 1:19 PM, Sunny Lee <threeqube27@gmail.com> wrote:

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