Questions about Linked Data Signatures for Verifiable Claims

I noticed a sentence in the Use Cases document in one of the drafts that
Shane and Joe worked on that none of the current documented processes
require the interaction of the claim subject/recipient, only a claim
"holder" that may or may not be the subject. In some cases, I think it is
really important that claims' subjects are the determiner of who is able to
obtain verifiable instances of claims about them. If verifiable claims are
only ever signed to be verifiable by the public, they can always be
"forwarded" in full verifiable form with anyone who holds the claim. Public
signing is only one branch of public key cryptography. We also can use
encryption methods to sign messages so they are only readable/verifiable by
holders of specific keypairs. How might we take advantage of this with
verifiable claims?

I would like to make it so that claims (badges) may be issued that are not
"forward-shareable", meaning that only an authorized inspectors are able to
verify a verifiable claim and that recipients and issuers work together to
get verifiable claims to intended inspectors. This would have the cost of
making verifiable claims using this mechanism not fully portable (because
the recipient could never give them to an arbitrary inspector to verify
without interaction with the issuer to obtain a copy signed to that
inspector), but in some cases privacy trumps portability. Of course, anyone
who possesses information on the Internet may technically share that
information with others, but if we make it so that the verifiable nature of
a claim does not travel to all holders, we can make it possible that the
ecosystem is truly user-centric.

Imagine this case using the Linked Data Signatures spec of a verifiable
claim a recipient could obtain from an issuer in order to pass to a
specific recipient (who holds the private key corresponding to "
https://publckeys.net/inspector2key"):

{
     "@context": {...},
     "claim": {"@id": "did:abc123", "isAwesome": true},
     "signature": {
          "creator": "https://publickeys.net/issuer1key",
          "domainKey": "https://publickeys.net/inspector2key",
          "created": "2016-07-25",
          "algorithm": "ECDSA256",
          "signatureValue": "fbda4567c=="
     }
}

Notes:

- The "domain" property in the Linked Data Signatures spec draft is a way
of specifying what applicability a signature has. The "domainKey" property
here is a possible new property to indicate a specific key corresponding to
the recipient of the message.


The signing algorithm used here would not be the basic public signing we
have most often considered; it would be more like encrypting the message to
a single public key. Some questions about whether this approach is feasible:

- Is it possible to leave the message content in plaintext but make the
signature verifiable only by the holder of a specific private key? (This
would facilitate multiple signatures to different domainKeys on the same
message -- otherwise it would be fine to encrypt the message content as
well)

- I'm interested in building an index of public keys that are trusted by
users on a system and associating them with descriptive information about
the entities that hold them. How should these keys be indexed/identified
and related to the entities that hold them? Is an HTTP(s) URL the best way
to identify a key (and maybe obtain descriptive public linked data about
the entity it belongs to)?

- What does the document look like that is obtained by dereferencing the
key URLs that appear here?

Thanks for your consideration,

Nate Otto
Director of Technology, Badge Alliance
badgealliance.org