W3C home > Mailing lists > Public > public-credentials@w3.org > June 2016

Re: VOTE: Verifiable Claims Terminology

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Sat, 11 Jun 2016 18:49:32 +0100
To: Dave Longley <dlongley@digitalbazaar.com>, public-credentials@w3.org
Message-ID: <ddf87023-51d5-9f79-68fd-329270fb1032@kent.ac.uk>

On 11/06/2016 17:56, Dave Longley wrote:
> On 06/11/2016 07:27 AM, David Chadwick wrote:
>> It would appear to be so from the cat example that Dave gave (that
>> unfortunately has been cut out of your reply), in which the cat has two
>> different profiles but the same ID (because it refers to the same cat).
>> I think this is the wrong design, because we have now created
>> linkability between two separate profiles (or pseudonyms) that I might
>> have sent to two different relying parties. By using a common ID for two
>> different identity profiles we produce a correlation handle for the
>> relying parties.
> There are multiple use cases we want to support. One of them involves
> the ability to share a common identity with multiple parties. That
> doesn't mean that you *must* do this, it just means that you can.

The way I would model this is by having a claim that contains a unique
correlating ID, such as a passport number claim (that when signed by a
government authority becomes a credential). The id of a credential
should not uniquely identify its holder as in your cat example. This
should be explicitly ruled out of the model, so that correlation cannot
slip in by mistake. Correlation should be a positive act, by providing a
correlating claim/credential.


> There are also cases where you should be able to have the unlinkability
> characteristics you mention, which can be implemented in a variety of
> different ways. I believe a layered approach will work here. I will
> reiterate though that the trust characteristics, disincentives for
> fraud, and infrastructure needs can be much more complicated in the
> unlinkable use cases.
Received on Saturday, 11 June 2016 17:49:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:53 UTC