W3C home > Mailing lists > Public > public-credentials@w3.org > February 2015

Re: Does the 'SM' signing mechanism allow multiple signatures?

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Thu, 05 Feb 2015 11:11:39 -0500
Message-ID: <54D3963B.1020002@digitalbazaar.com>
To: Nate Otto <nate@ottonomy.net>, Credentials Community Group <public-credentials@w3.org>
On 02/05/2015 03:45 AM, Nate Otto wrote:
> Open Creds,
> 
> Either:
> 1. I've got poor reading comprehension that has prevented me from
> understanding this for months,
> 2. I'm completely wrong now,
> or 3. Does the signed JSON-LD technique we've been discussing ('Secure
> Messaging' <http://manu.sporny.org/2013/sm-vs-jose/>) allow (or is very
> close to allowing) multiple signatures on LD input without changing the
> expanded JSON-LD of the signed-output-minus-signature? This is
> interesting because that signed-output-minus-signature is the input to
> the signature-verification function, right? At least the first step of
> that algorithm is removing the signature property.

There are two kinds of "multiple signatures" that we've discussed
providing support for [1]. The first approach is like a "counter
signature", it allows multiple entities to sign the same document. The
second is to allow nested or chained signing, that is, one or more
parties sign document A and then other parties sign document B that
embeds signed document A.

The first approach, counter-signing, is like what you've shown in your
example below. The process for signing a document is to remove the
signature property, take the result and sign it, and then replace the
signature property with your signature appended to the set. The process
for verification is to remove the signature and take the result and
verify it. The "Secure Messaging" spec, I believe, currently only
details how to do this using a single signature, but this approach
should work for a set of signatures as well. Note we're moving that part
of the spec over to a separate spec, called "Linked Data Signatures 1.0"
[2], and we should do any corrections/clarifications over there.

The second approach could be modeled in a number of different ways
depending on the problem domain -- it doesn't necessarily need a new
spec to detail it in a generic way. In the Identity Credentials work,
we're currently chaining signatures by taking a signed document (a
credential in this case) and nesting it under a credential property.
Then the document with the credential property is signed. This allows,
for example, the owner of a credential to place their own signature on a
set of their credentials, authorizing their transmission to a particular
domain (they can restrict the domain with their signature).

For example:

{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://example.com/identities/jo",
  "type": "Identity",
  "credential": [{
    "id": "https://ssa.us.gov/83412",
    "type": "Passport",
    "claim": {
      "id": "https://example.com/identities/jo",
      "name": "Jo Joski",
      "birthdate": "1964-11-08",
      "governmentId": "123-45-6789"
    },
    "expires": "2018-01-01",
    "signature": {
      "type": "GraphSignature2012",
      "creator": "https://ssa.us.gov/keys/27",
      "signatureValue": "bzva..."
    }
  },
  "signature": {
    "type": "GraphSignature2012",
    "creator": "https://example.com/identities/jo",
    "domain": "https://airports.com/ORD",
    "signatureValue: "mAMX..."
  }
}

Note that the two approaches could also be combined; for example, the
"credential" above may have a set of N signatures on it all asserting
that they trust the claim that has been made about the identity.

1. http://opencreds.org/minutes/2014-09-30/
2. https://web-payments.org/specs/source/ld-signatures/

> 
> 
> Here's an example of some signed JSON-LD:
> 
> "value": {
>     "@context": "https://w3id.org/identity/v1",
>     "id": "http://ssa.us.gov/credential/8273",
>     "type": "PassportCredential",
>     "claim": {
>       "id": "https://example.org/identities/alice",
>       "name": "Alice Smith",
>       "birthdate": "1988-11-02",
>       "governmentId": "321-54-9876"
>     },
>     "expires": "2017-02-04",
>     "signature": {
>        "type": "GraphSignature2012",
>        "creator": "https://ssa.us.gov/keys/27",
>        "signature": "r+e90REDpW....bAsNUtvQM"
>     }
>   }
> 
> And with multiple signatures, the "signature" property just turns into
> an array of multiple values, just as it would turn into a 1-item array
> when JSON-LD expanded anyway:
> 
> "value": {
>     "@context": "https://w3id.org/identity/v1",
>     "id": "http://ssa.us.gov/credential/8273",
>     "type": "PassportCredential",
>     "claim": {
>       "id": "https://example.org/identities/alice",
>       "name": "Alice Smith",
>       "birthdate": "1988-11-02",
>       "governmentId": "321-54-9876"
>     },
>     "expires": "2017-02-04",
>     *"signature": [{
>        "type": "GraphSignature2012",
>        "creator": "https://ssa.us.gov/keys/27",
>        "signature": "r+e90REDpW....bAsNUtvQM"
>     },*
> 
> *    {*
> 
> *      "type": "GraphSignature2012",
>       "creator": "https://example.org/keys/1",
>       "signature": "r+eeeeeeee....aaaaBBBBB"
> **    }]*
> }
> 
> 
> Thanks for your indulgence,
> *
> *
> *Nate Otto, Developer*
> concentricsky.com <http://concentricsky.com>
> 
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Thursday, 5 February 2015 16:12:24 UTC

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