Re: VOTE: Verifiable Claims Terminology

On Sun, 12 Jun 2016, 4:31 PM Henry Story <henry.story@bblfish.net> wrote:

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

Understood and agreed.


>
> 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.
>
Understood. However I was referring to the potential ability to fiz that
problem with something such as this concept of webid-dht that may be
interoperable with other WebID methods as a goal.

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

Apologies if it appeared that I was inferring something you didn't say,
wasn't my intention.

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

IMHO, people enter the identity space and it's far more difficult than
people consider as an early enterant, and that's not even considering the
role of commercial goals and how that impacts works.

Re: utility of linked-data, entirely agreed. It has always been a key
critical part of this work imnsho.


>
>
>> 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  - 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/
> by typing in a known concept or famous name.
>
> 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...?
>
> I think some work on solid for dummies might help open the world up to
imagination for stakeholders who aren't aware of the work concepts as yet
within their roles / considerations.

I have been meaning to deploy a server, but really wanted some of the
interoperable requirements with feeds sorted or at least better undersyood
before doing so.  I think this has in-turn been unfortunate, as how it's
working now does demonstrate the concept rather well, even though it's WIP
(work in progress).

Thank-you for your input Henry.

Tim.h.

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