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

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

From: Nate Otto <nate@ottonomy.net>
Date: Thu, 5 Feb 2015 18:12:07 -0800
Message-ID: <CAPk0ugkw=3bkuTiXiYOv29CnbCj3LA5YC+XahHnwnwPXC-i=ig@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>
Thanks, Dave. Eric, I don't have any specific ideas around how this might
be applied with credentials. I think the nesting approach may be ultimately
more useful with credentials, because with a simple counter-signature, it's
ambiguous what the purpose of the second signature is.

Use cases for multiple-signed credential documents might be:
 * indicating that verification of the original signature has been
successfully performed.
* endorsing claims made in the credential
* adding complementary claims to those made in the credential
* indicating earner acceptance of a credential

Some of these case distinctions may be inferred from a basic counter-signed
approach, but it might be hard to tell the difference between them.

Slightly related:
Over on the Badge Alliance side, we're talking about endorsement this week,
because I put out my proposal (arising from work done in BA's Endorsement
Working Group) for what endorsement of a badge object (Assertion, Badge
Class or Issuer Org) could look like, as a credential targeting that object
as recipient. I like the badge community's definition of a Badge Class as a
set of claims that are awarded all together as an immutable set to many
recipients. Claims that apply solely to one recipient live outside of the
Badge Class object. Badge endorsement came about as a method for outside
parties to indicate that they felt a credential set *as defined, assessed,
and issued by one issuer* is valuable. It allows consumers who trust
endorsers to extend that trust to the badges and issuers trusted by those

*Nate Otto, Developer*
Received on Friday, 6 February 2015 02:12:35 UTC

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