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

Re: VOTE: Verifiable Claims Terminology

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sun, 12 Jun 2016 16:00:26 +0200
Message-ID: <CAKaEYhLj=DmQwLtSXZvirmUbjtcmKriYgaR5rGMvNgFq5aDuLw@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: Chadwick David <d.w.chadwick@kent.ac.uk>, Dave Longley <dlongley@digitalbazaar.com>, W3C Credentials Community Group <public-credentials@w3.org>
On 11 June 2016 at 20:22, Henry Story <henry.story@bblfish.net> wrote:

> > On 11 Jun 2016, at 19:49, David Chadwick <d.w.chadwick@kent.ac.uk>
> wrote:
> >
> >
> >
> > 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.
> I have a feeling that in this discussion there needs to be some careful
> initial work on semantics done, or else there is a danger that the group
> will have to labor to re-invent the semantic web, and that could take
> decades.

This is a good point.  Lots of groups out there are essentially reinventing
the work done in creating the semantic web, which really took about two
decades.  Its hard to see any group actually making it as far as the sem
web has in the next 5 years, but the timeline of decades is more likely
correct, given that the semantic web already had a great deal of adoption,
tooling and support.

I think the solutions that succeed are the ones that actually have testable
interop.  That turns out to be really hard.  Basic, Interop is easy,
everyone has it.  But testable heterogeneous interop is really hard and
inevitably people end up building silos that rely on organic growth, which
is attractive.  In almost all cases organic growth will hit a wall, and
fail to scale to the web.

> It would be worth considering the following picture:
> https://www.w3.org/2005/Incubator/webid/spec/identity/#overview
> which shows how URIs denote things, directly and indirectly. (this limits
> itself to HTTP(s) uris, for simplicity)
> Then you can quite easily see how public keys can denote agents indirectly
> via a relation ( a definite description as Bertrand Russel would have put
> it).
> A public key cannot denote an agent directly, because it denotes a public
> key!
> So I think what needs to be done is work on:
>   - denotation/reference
>   - meaning
>   - description
> and then the further part which is signatures of statements...
> This way one does not need to make decisions about whether people use an
> identity across sites, etc.. which is going to be up to each applicaiton
> and use case. What is needed is just to distinguish claims, who make them
> by reference to a direct identifier or a definite description.
> >
> > regards
> >
> > David
> >>
> >> 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 Sunday, 12 June 2016 14:00:55 UTC

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