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

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 01 Dec 2014 14:17:34 -0500
Message-ID: <547CBECE.1000709@digitalbazaar.com>
To: Jason Lewis <jason@yetanalytics.com>
CC: ba-standard@googlegroups.com, public-credentials@w3.org, Brian Brennan <brian@mozillafoundation.org>, "openbadges-dev@googlegroups.com" <openbadges-dev@googlegroups.com>
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:


> 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
Received on Monday, 1 December 2014 19:18:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:38 UTC