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

@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/
>
>