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

@Dave Longley +1 Thanks for that detailed explanation.  I believe we have
implemented in the second form.


On Thu, Feb 5, 2015 at 11:11 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> 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.
>
>