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 23:52:04 -0500
Message-ID: <547D4574.8030702@digitalbazaar.com>
To: Nate Otto <nate@ottonomy.net>, ba-standard@googlegroups.com
CC: Credentials Community Group <public-credentials@w3.org>, "openbadges-dev@googlegroups.com" <openbadges-dev@googlegroups.com>
On 11/26/2014 02:01 PM, Nate Otto wrote:
> * One of these might be encrypting OBI assertions so that they are 
> only verifiable by one particular consumer (at least without that 
> consumer revealing their private key). We could assume that the 
> consumer could divulge the decrypted version, but that it would lose 
> its verifiability if they did so.

You wouldn't have to give up verifiability in this case. Just encrypt
the digitally signed assertion and you get the best of both worlds, no?
Or am I not understanding your use case?

> * Another is "countersigning" badges, to indicate that both an earner
> and an issuer are in consensus on an assertion.

The Secure Messaging stuff has these sorts of signatures we're looking
into right now:

1. Single signatures (one signature on a document)
2. Signature Sets (multiple independent signatures on a document)
3. Chained Signatures (multiple dependent signatures on a document)
4. Threshold Signatures (where you must have at least M of N signatures
   for a signature set to be valid).

Only the first type is spec'd currently, but we do plan to expand into
the other 3 types within the next 6 months.

> what formats may public keys be published in

Right now, we support PEM-encoded public keys (which is ancient, but the
dominant industry standard):

curl https://dev.payswarm.com/i/manu/keys/1

There's a good argument to support keys published in JWK format as well.

> how are those keys discovered

The JSON-LD (SM) signature contains the key:

  "type": "GraphSignature2012",
  "creator": "https://dev.payswarm.com/i/manu/keys/1"

keys are discovered by an HTTP GET on the "creator" URL:

curl https://dev.payswarm.com/i/manu/keys/1

The owners of keys are discovered by an HTTP GET on the "owner" URL:

curl https://dev.payswarm.com/i/manu

> and how does this key infrastructure contribute to organizations'
> and individuals' ability to participate in other forms of encrypted 
> communication?

That same key format above can be used to digitally sign messages,
credentials, and encrypt communication to the recipient. We're working
on a demo right now where you can just re-use your SSH key and it plugs
right into the Secure Messaging stuff allowing you to just re-use the
keys you already have today (as a developer, anyway). So, for example,
if you have a GitHub account, you can just re-use those same keys to
digitally sign JSON-LD messages/credentials/etc.

> I'd love it if we could contribute to the development of a truly 
> democratic public key and trust graph infrastructure

+1 - that's the purpose of the SM spec... to turn the Web into a big,
democratic, decentralized public key infrastructure.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
Received on Tuesday, 2 December 2014 04:52:28 UTC

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