Re: Questions about Linked Data Signatures for Verifiable Claims

On 07/26/2016 10:53 AM, Nate Otto wrote:
> 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.

We might need to be careful with this, as a few of the organizations
that we're talking with want to offload the inspection of verifiable
claims to other organizations. Doing so would require an additional
mechanism to state which "verifier keys" the inspector wants to tie the
credential to.

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

Right, so understanding the use cases for this feature are important.

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

Arguable, as self-sovereign/user-centric also has to do with ease of use
and privacy. This feature doesn't really protect one's privacy and we're
also making the system more complex with this feature. That said, let's
put that to the side for the moment and talk about the technical details.

>From a technical perspective, this is do-able, but doesn't really
address the "privacy" use case... some thoughts below.

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

Thinking about this a bit more from the last time we talked about it...
yes, we could extend the Linked Data Signatures spec to perform a
signature and then encrypt only the signature field to a specific target
key so that only the receiving entity can verify the information. For
example:

{
  "@context": {...},
  "claim": {"id": "did:abc123", "isAwesome": true},
  "signature": {
    "type": "EncryptedSignature2016",
    "creator": "https://publickeys.net/issuer1key",
    "created": "2016-07-25T12:34:56Z",
    "domain": "https://publickeys.net/inspector2key",
    "signatureValue": "BASE64(ENCRYPT(SIGNATURE, inspector2key))"
  }
}

So, verifying that signature would go through the following steps:

1. Decrypt the signatureValue using the inspector's private key.
2. Verify the resulting signature using the issuer's public key.

That said, I'm not sure this really protects one's privacy as the
information is in clear text and in 99.9% of the cases, that information
is going to be valid.

So, the question is - what's the actual attack? What are we trying to
prevent?

If the answer is "make sure information is not shared", we may find
that's impossible to do given bad actors in the system (for example,
inspectors that forward information to other organizations via 3rd party
information sharing agreements).

We may find that the W3C Permissions and Obligations Expression language
to be more useful to us than making the crypto more complex:

http://w3c.github.io/poe/vocab/

... coupled with enough Common Law to give the restrictions some legal bite.

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

Both do-able, but need more information about the use case to see if
it's a problem we want to solve (via the standard).

> How should these keys be indexed/identified and related to the 
> entities that hold them?

I'd assume in the same way that the Linked Data Signature spec works
today. For example, if you dereference this (fake) key:

https://publickeys.net/issuer1key

You should see something like this:

{
  "@context": "https://w3id.org/identity/v1",
  "id": "https://publickeys.net/issuer1key",
  "type": "CryptographicKey",
  "owner": "https://publickeys.net/issuer1",
  "label": "Issuer 1 signing key",
  "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBI..."
}

and if you dereference the "owner" of that key, you should get:

{
   "@context" : "https://w3id.org/identity/v1",
   "id" : "https://publickeys.net/issuer1",
   "type" : "Identity",
   "label" : "Issuer 1"
   "description" : "A short human-readable description of issuer1",
   "publicKey" : {
      "id" : "https://publickeys.net/issuer1key",
      "type" : "CryptographicKey"
      "label" : "Issuer 1 signing key",
      "owner" : "https://publickeys.net/issuer1",
   },
}

... plus any other information you deem appropriate.

> 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)?

It's the best way that we've found. Other options include:

1. public key fingerprints/hashes
2. pointers to public ledgers
3. OIDs

Keep in mind that every option other than an HTTP URL needs to have a
corresponding dereferencing mechanism that the client understands (that
is, how do you get at the data pointed to by the identifier?).

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

Answered above... did any of that help, Nate?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
http://manu.sporny.org/2016/browser-api-incubation-antipattern/

Received on Tuesday, 26 July 2016 16:02:02 UTC