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

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

From: Eric Korb <eric.korb@accreditrust.com>
Date: Tue, 2 Dec 2014 12:45:04 -0500
Message-ID: <CAMX+RnB6k0cG96w4W9_iTLoBThS8RxxErZj4OtAm3O9tt7rabQ@mail.gmail.com>
To: ba-standard@googlegroups.com
Cc: Manu Sporny <msporny@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>, "openbadges-dev@googlegroups.com" <openbadges-dev@googlegroups.com>
Correction: namecoin.info


*"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 12:43 PM, Eric Korb <eric.korb@accreditrust.com>
wrote:

> @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.
>>
>
>
Received on Tuesday, 2 December 2014 17:45:57 UTC

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