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

@Jason

We've been pondering blockchain kinds of technology for 2 years (
namedcoin.info comes to mind).  I believe this may offer a level of
decentralization badge registry as well.  But, more time and thought is
needed to evaluate the pros and cons of a blockchain solution.  It would be
great to have you join in on the discussion and discovery of such a
specification for the CCG.

Thanks for your input and continued participation.

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 Tue, Dec 2, 2014 at 2:57 AM, Jason Lewis <jason@yetanalytics.com> wrote:

> Eric, Manu, (everyone),
>
> Thanks for the additional info. Especially for that blog post, Manu, it
> explicates the processes/differences better than anything I'd Googled.
>
> Like I (hope) I indicated before, I'm not against a different approach, I
> just liked the (seeming) universality of JWS/JWT. But SM seems like an
> excellent standard, and well thought out.
>
> My thoughts are now returning to the badge endorsement discussion we had
> earlier... there was a (prevailing) train of thought about awarding badges
> to badges; I'm still more interested in a chain of trust based on either
> key-signing parties or (preferably) something like the blockchain
> algorithm...
>
> I'm not offering any solutions (sorry) but I was wondering if anyone more
> intimate than I with these standards could shed some light on which if any
> could possibly fit into such a scenario?
>
> Thanks,
> Jason
>
>
> 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, Dec 1, 2014 at 2:32 PM, Eric Korb <eric.korb@accreditrust.com>
> wrote:
>
>> @Manu +1 Great responses.
>>
>>
>> *"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, Dec 1, 2014 at 2:17 PM, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> On 11/19/2014 10:35 PM, Jason Lewis wrote:
>>> > 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).
>>>
>>> The algorithm isn't tied to an application layer protocol. RDF isn't
>>> bound to HTTP, but it is bound to URIs/IRIs (that is, it's tied to the
>>> identifiers that are used on the Internet and the Web). You may want to
>>> take a look at the link below for some background:
>>>
>>> http://manu.sporny.org/2013/sm-vs-jose/
>>>
>>> > 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.
>>>
>>> Keep in mind that what's being proposed isn't that badges MUST be
>>> authenticated. This is an optional thing. If you want to ensure that the
>>> badge is cryptographically verifiable, even if the originator of the
>>> badge goes down/out of business, then you can optionally digitally sign
>>> the badge.
>>>
>>> > 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?
>>>
>>> We're talking about ensuring that badges/credentials can be
>>> cryptographically verifiable. For example, you want to make sure that
>>> the doctor that's going to be operating on your patients actually passed
>>> their board exam w/o spending a fortune trying to figure that out. You
>>> want to make sure that the contractor you hired actually has the
>>> qualifications that they say they have w/o spending a fortune doing a
>>> background check on them, etc.
>>>
>>> > 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.
>>>
>>> We're proposing a machine-readable mechanism to do what you're proposing
>>> above. So that a machine can look at a credential, understand where the
>>> public key that should do the verification resides, get the key, verify
>>> the owner of the key, and verify the authenticity of the
>>> badge/credential.
>>>
>>> > .. well...
>>> >
>>> > [XKCD comic on standards proliferation]
>>> >
>>> > Yeah... that.
>>>
>>> There is currently no standard that does everything stated above. There
>>> is JOSE, which does bits and pieces of it, but the current debate is
>>> whether JOSE should be re-used, or whether we should go with the SM
>>> stack, or some sort of hybrid.
>>>
>>> > I'm not offering a universal solution. Just warning against
>>> > insisting upon one.
>>>
>>> There is no universal solution to anything on the Internet/Web. There
>>> are, however, standards that suggest the best way to do particular
>>> things (especially when it comes to security). These standards are
>>> usually arrived at after years of public debate and technical research
>>> into alternatives. What's being suggested is that we really get into the
>>> meat of this public debate and technical research sooner than later.
>>>
>>> Hope that helps give a bit of background wrt. your comments. :)
>>>
>>> -- manu
>>>
>>> --
>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>> Founder/CEO - Digital Bazaar, Inc.
>>> blog: High-Stakes Credentials and Web Login
>>> http://manu.sporny.org/2014/identity-credentials/
>>>
>>>
>>  --
>> 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.
>