- From: Eric Korb <eric.korb@accreditrust.com>
- Date: Tue, 2 Dec 2014 12:45:04 -0500
- 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>
- Message-ID: <CAMX+RnB6k0cG96w4W9_iTLoBThS8RxxErZj4OtAm3O9tt7rabQ@mail.gmail.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