Re: VOTE: Verifiable Claims Terminology

> On 12 Jun 2016, at 02:54, Timothy Holborn <timothy.holborn@gmail.com> wrote:
> 
> 
> 
> On Sun, 12 Jun 2016 at 04:23 Henry Story <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote:
> 
> > On 11 Jun 2016, at 19:49, David Chadwick <d.w.chadwick@kent.ac.uk <mailto: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.
> 
> It would be worth considering the following picture:
> 
> https://www.w3.org/2005/Incubator/webid/spec/identity/#overview <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)
> 
> ATM that's not working so now, it's being pushed in no insignificant way - an array of block-chain alternatives.  Their not using HTTP URI's. It's a satoshi solution, not a 'native' or 'open web' being WWW or W3C orientated solution.

I am not suggesting that one should limit oneself to http uris. I was just saying that WebID did,
to allow us to simplify our work, and get something that would have a chance of being implementable.

The diagram with regard to sense and reference can be applied to other types of URIs such as dht URIs.

> 
> The idea i've got is to create WebID-DHT - in which the Distributed documents are shared within social-context, as to limit the distribution and therefore the size of the file whilst having controllable social-context to protecting the resource.
> 
> I find some very old friends still have copies of my very first business card, even when i've lost all the copies i had myself.
>  
> 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!
> 
> Yes.  But the UX for the desktop browser is terrible - not because it needs to be, but rather, because that's where it's at with browser buy-in and support.

That has nothing to do with my point. The current TLS certificate selection UIs are presumable not the best that can be done, or the last word on the subject.
In any case the discussion here is not about certificate selection UI. 

> 
> so, having a WebID-TLS experience that relates to the machine account, or indeed in a differentiated way for a TV, or Phone - all sorts of devices are compatible with the TLS method...   I think is great!  
> 
> just not a magic bullet, which is a bit similar to the situation of creds.

Again I did not mention TLS, just a diagram from the WebID-TLS spec, as that shows an example of a claim written in RDF that
is published on a web server, where the user is indirectly identified by a public key.

>  
> So I think what needs to be done is work on:
>   - denotation/reference
>   - meaning
>   - description
> 
> I think the scope is narrowing and/or shifting, and we need to figure out what this part / group / undertaking is doing; and how the other stuff we know needs to exist - can be developed.

yes. I see the confusion that is quite widespread across the identity discussion in many forums, that comes from conflating 
Identifiers, definite descriptions, reference, ... If one is clear about that then a lot of the rest falls out nicely, and furthermore
it turns out that a lot of the core pieces have already been standardised: RDF for descriptions, OWL for inferencing, ...


>  
> 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.
> 
> I'd be cautious with the concept of 'reinventing the semantic web' as it's being continually reinvented - I think your meaning was that it is important for people to understand that body of work rather than trying to reinvent something that has already been done. 
> 
> Amongst the fastest ways to tutor people about how these things may work in future is: https://github.com/solid/solid <https://github.com/solid/solid>  - i can tutor people through it if they need some help and are interested.
> 
> another is to look at the search interface: http://dbpedia.exascale.info/ <http://dbpedia.exascale.info/>  by typing in a known concept or famous name.
> 
> https://credly.com/ <https://credly.com/> has a rather well developed initial implementation of verifiable claims / credentials. 
> 
> I see a mix of things emerging and guess, the question is how do they all fit together...? 
> 
> 
> Tim.H.
> 
> 
> >
> > 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.
> >>
> >>
> >
> 
>