Re: unlinkability

On 6 Oct 2012, at 17:35, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 10/6/12 6:45 AM, Nathan wrote:
>> Nathan wrote:
>>> Henry Story wrote:
>>>> On 6 Oct 2012, at 11:39, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>> 
>>>>> 
>>>>> On 6 October 2012 11:25, Henry Story <henry.story@bblfish.net> wrote:
>>>>>>> (1) I think solves the unlinkability problem
>>>>>> Can you explain what the unlinkeability problem is? Or for who it is a problem?
>>>>>> 
>>>>>> 4.  Unlinkability
>>>>>> 
>>>>>>   Definition:  Unlinkability of two or more Items Of Interest (e.g.,
>>>>>>      subjects, messages, actions, ...) from an attacker's perspective
>>>>>>      means that within a particular set of information, the attacker
>>>>>>      cannot distinguish whether these IOIs are related or not (with a
>>>>>>      high enough degree of probability to be useful).
>>>>>> 
>>>>>> This is something Harry brought up.
>>>>> Can you explain why it is problematic. It is not because he brought it up
>>>>> that it is problematic right? Or is he someone who sets the standards
>>>>> of what is or is not problematic? Through what authority?
>>>>> 
>>>>> Harry stressed that this was a key consideration to him.  As an influential member of the social web (he was chair of the W3C Social Web XG), I would consider his opinions important.  His complain was that he raised this before, and that the webid group did not look at it.
>>>> 
>>>> But you have not summarised in your own words what his complaint is. So how do you know we did not answer it?
>>> 
>>> The quote in context may help:
>>> http://tools.ietf.org/html/draft-hansen-privacy-terminology-03#section-4
>>> 
>> 
>> and framed within the more specific context of http://www.w2spconf.com/2012/papers/w2sp12-final6.pdf
>> 
>> 
>> 
> For some context re. BrowserID (aka. Persona) flow, bearing in mind, according to Harry and others this is supposed to have a lower entropy factor than WebID:
> 
> 1) The user attempts to identify themselves by giving an e-mail address, and wants to bind that address to a particular set of key material (for which the user then provide a proof of possession) by having the identity provider attest to that binding.
> 
> 2) The browser checks to see if a private key is present in the browser associated with that email address.
> 
> 3) If no key exists for the email address locally in browser, the browser generates key material and registers the public key with the identity provider.
> 
> 4) The browser sends a signed authentication credential to the relying party.
> 
> 5) The relying party checks authentication credentials with their locally stored database of identity provider public keys, authenticates the user if verification suc- ceeds (not shown in diagram as this step does not happen with every transaction).
> 
> 6) The user sends signed attributes to the relying party from browser.
> 
> So this all ends up in a locally stored database of the identity provider. Enough said, since BrowserID doesn't cut it at all re. IFP semantics in a world in which our email addresses are the "super keys" of the underground personal information market. That anyone that claims to know anything about privacy and networking would make such claims about BrowserID boggles my mind.
> 
> *Comments:*
> 
> 1. Where is "user" control in this flow?
> 2. On what basis is the so-called IdP database secure?
> 3. How does any of this negate the explicit or implicit IFP semantics of an email address.
> 
> We should simply take this FUD, and every item in the ietf spec, and use it to make a much better presentation of what WebID is all about.
> 
> Points to cover:
> 
> *Unlinkability*
> 
>      Unlinkability of two or more Items Of Interest (e.g.,
>      subjects, messages, actions, ...) from an attacker's perspective
>      means that within a particular set of information, the attacker
>      cannot distinguish whether these IOIs are related or not (with a
>      high enough degree of probability to be useful).
> 
>      Example: As it states, given a piece of information (for instance a triple) can I construct a bigger profile or massive zeitgeist?
> 
> *Undetectability*
> 
>      Undetectability of an item of interest (IOI) from an
>      attacker's perspective means that the attacker cannot sufficiently
>      distinguish whether it exists or not.
> 
>      Example: is <SomeURIDenotingAnEntity> a Person, Organization, or Machine?

yes, we should look at that vocabulary and see how we can fill in some good use cases for WebID.
I am bit weary of the Unlinkability being a good term, because it's just too much of a clash from
the goodness we know comes with the ability to link things up. But I think I understand what is
meant below the word. So the definition without the word can be used.

> 
> 
> All of these matters play into the strengths that arise from combining de-referencable URIs, Entity Relationship Semantics (e.g. as explicitly delivered via RDFS and OWL), hyperlink based structured data representation (as delivered by Linked Data & RDF data model), and first-order logic (what underlies RDFS and OWL).
> 
> WebID doesn't solve these matters alone. The solution is a combination of:
> 
> 1. WebID -- cryptographically verifiable identifiers for entities of type: foaf:Agent
> 2. WebID authentication protocol -- what actually defines how authentication is performed
> 3. ACL and Data Access policies -- driven by the combination of ACL oriented ontologies, WebID authentication protoocol, and WebID.
> 
> We get into trouble when we try to refer to WebID as the solution. That kind of conflation inadvertently means 1/3 of the items outlined above.
> 
> ACL protection of resource based on logic is the key. Logic is as dexterous enough to evolve with human social network dynamics.
> 
> Let's take this opportunity to accentuate the power of socially aware ACLs and Data Access policies that leverage WebID and its Authentication Protocol.
> 
> Henry: WebID on its own is just a piece of the puzzle. We have to push the synergy of WebID and ACLs much harder via actual demonstrations.

Absolutely. 
This has to be the priority in our demos from now on.
Though we do have little nitty gritty things to finish in WebId, our demos and effort should be on
   http://www.w3.org/wiki/WebAccessControl

I'll get to programming that myself.

And at TPAC we should put a lot of time aside for those issues.

Perhaps we should start a document there on ACL. We should ask the Linked Data Profile group when there, after we show them a demo.

> This is what I do at every turn and I encourage everyone to emulate. At this juncture, I am still waiting for folks to come get on board by doing the following:
> 
> 1. sign all emails -- if you don't sign your emails you deprive yourself of the powerful entry point into the realms of user controlled verifiable identity and privacy
> 2. start using ACLs to protect Web documents that you publish -- this is basically what I've put forth as RWW-0.
> 
> Do that and you will find really simple ways to refute all of this FUD. Nothing beats an demonstration of reality.

yes. Back to work. 

> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/