Re: Questions about Linked Data Signatures for Verifiable Claims

Hi Nate

Your email raises multiple issues that makes the answer complex and
non-deterministic. Here is my take on them

1. Who determines who should be the recipients: the issuer or subject or
both? Some issuers may wish to restrict who can view their issued
claims. e.g. a political party might give different privileges to
different donor subjects and does not want this to be public.
Alternatively the subject may wish to limit who can see credentials
containing various personal details.

2. Who must trust the recipient: the issuer or subject or both? A
subject should be able to give his/her credentials to a recipient that
the issuer does not trust but that he/she does trust. Conversely, a
subject should also be able to give a credential to a recipient he/she
does not fully trust yet wishes to obtain some sort of service from.

3. What is the overall trust model, and how does this impact on the
likelihood that a recipient will forward a credential without the
express permission of the subject? A fully trusted recipient would never
forward a credential without the subject's permission. A fully untrusted
recipient might well forward a credential if there was some benefit in
this. What would a partially trusted recipient do?

4. Should forward sharing be controlled by technical constraints or is
the trust model (when this is defined) sufficient for this?

5. How many different flavours of the same credential is it reasonable
to ask the issuer to issue? In the extreme case this would be a
different credential for each recipient.

Sorry to not give you any answers, but in my opinion your email raises a
significant number of issues that would need to be addressed before your
email can be answered

regards

David

On 26/07/2016 15:53, Nate Otto wrote:
> 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 <http://badgealliance.org>

Received on Tuesday, 26 July 2016 16:07:50 UTC