W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: [saag] Liking Linkability

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 18 Oct 2012 14:27:33 -0400
Message-ID: <50804A15.8030701@openlinksw.com>
To: David Chadwick <d.w.chadwick@kent.ac.uk>
CC: Ben Laurie <benl@google.com>, Henry Story <henry.story@bblfish.net>, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "public-identity@w3.org" <public-identity@w3.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-webid@w3.org" <public-webid@w3.org>, "public-privacy@w3.org" <public-privacy@w3.org>
On 10/18/12 2:17 PM, David Chadwick wrote:
> On 18/10/2012 18:33, Kingsley Idehen wrote:
>> On 10/18/12 12:56 PM, David Chadwick wrote:
>>> and if the user puts his/her email address attribute in the U-Prove
>>> token???
>> Then they've broken un-linkability since a mailto: scheme URI is the
>> ultimate unit of privacy compromise on today's Internet and Web,
> yes I know. My main point was that using U-Prove or Idemix is 
> employing a very sophisticated privacy protecting encryption scheme 
> that can easily and trivially be undone by everyday users who provide 
> their email address attributes inside the tokens. So I suspect the 
> applicability of these tokens will be quite limited
> regards
> David



My apologies for misunderstanding the position you were taking :-)

>  bearing
>> in mind the state of the underground personal information networks.
>> Every social network uses your mailto: scheme URI as a key component.
>> Even if they don't share this data with 3rd parties, other pieces of the
>> puzzle come together quite easily due to the fundamental semantics
>> associated with mailto: scheme URIs i.e., you only need to have them in
>> an inverseFunctionalProperty relationship for entropy to drive the rest
>> of the profile coalescence.
>> The world I envisage starts with the ability to generate (with ease)
>> X.509 certificates bearing WebIDs in their SAN slots. We will have many
>> such certificates for a variety of purposes. An email address or any
>> other overtly identifiable data isn't a mandatory component an X.509
>> certificate  :-)
>> If I want to send something that's only readable by You, I would encrypt
>> that email via S/MIME. When I make an access policy or resource ACL I
>> tend not to require email addresses, for instance [1].
>> Links:
>> 1. http://bit.ly/Rbnayv -- some posts about the use of social entity
>> relationship semantics to constrain access to my personal data space on
>> the Web.
>> Kingsley
>>> David
>>> On 18/10/2012 17:52, Kingsley Idehen wrote:
>>>> On 10/18/12 12:06 PM, Ben Laurie wrote:
>>>>> On 18 October 2012 16:41, Kingsley Idehen <kidehen@openlinksw.com>
>>>>> wrote:
>>>>>> On 10/18/12 11:34 AM, Ben Laurie wrote:
>>>>>>> On 9 October 2012 14:19, Henry Story <henry.story@bblfish.net> 
>>>>>>> wrote:
>>>>>>>> Still in my conversations I have found that many people in 
>>>>>>>> security
>>>>>>>> spaces
>>>>>>>> just don't seem to be  able to put the issues in context, and can
>>>>>>>> get
>>>>>>>> sidetracked
>>>>>>>> into not wanting any linkability at all. Not sure how to fix that.
>>>>>>> You persist in missing the point, which is why you can't fix it. 
>>>>>>> The
>>>>>>> point is that we want unlinkability to be possible. Protocols 
>>>>>>> that do
>>>>>>> not permit it or make it difficult are problematic. I have 
>>>>>>> certainly
>>>>>>> never said that you should always be unlinked, that would be stupid
>>>>>>> (in fact, I once wrote a paper about how unpleasant it would be).
>>>>>>> As I once wrote, anonymity should be the substrate. Once you have
>>>>>>> that, you can the build on it to be linked when you choose to 
>>>>>>> be, and
>>>>>>> not linked when you choose not to be. If it is not the substrate,
>>>>>>> then
>>>>>>> you do not have this choice.
>>>>>> Do you have example of what you describe? By that question I mean:
>>>>>> implicit
>>>>>> anonymity as a functional substrate of some realm that we experience
>>>>>> today?
>>>>> That's what selective disclosure systems like U-Prove and the PRIME
>>>>> project are all about.
>>>> Ben,
>>>> How is the following incongruent with the fundamental points we've 
>>>> been
>>>> trying to make about the combined effects of URIs, Linked Data, and
>>>> Logic en route to controlling privacy at Web-scale?
>>>> Excerpt from Microsoft page [1]:
>>>> A U-Prove token is a new type of credential similar to a PKI 
>>>> certificate
>>>> that can encode attributes of any type, but with two important
>>>> differences:
>>>> 1) The issuance and presentation of a token is unlinkable due to the
>>>> special type of public key and signature encoded in the token; the
>>>> cryptographic “wrapping” of the attributes contain no correlation
>>>> handles. This prevents unwanted tracking of users when they use their
>>>> U-Prove tokens, even by colluding insiders.
>>>> 2) Users can minimally disclose information about what attributes are
>>>> encoded in a token in response to dynamic verifier policies. As an
>>>> example, a user may choose to only disclose a subset of the encoded
>>>> attributes, prove that her undisclosed name does not appear on a
>>>> blacklist, or prove that she is of age without disclosing her actual
>>>> birthdate.
>>>> Why are you assuming that a hyperlink based pointer (de-referencable
>>>> URI) placed in the SAN of minimalist X.509 certificate (i.e., one that
>>>> has now personally identifiable information) can't deliver the 
>>>> above and
>>>> more?
>>>> Please note, WebID is a piece of the picture. Linked Data, Entity
>>>> Relationship Semantics and Logic are other critical parts. That's why
>>>> there isn't a golden ontology for resource access policies, the 
>>>> resource
>>>> publisher can construct a plethora of resource access policies en 
>>>> route
>>>> to leveraging the power of machine discernible entity relationship
>>>> semantics and first-order logic.
>>>> In a most basic super paranoid scenario, if I want to constrain access
>>>> to a resource to nebulous entity "You" I would share a PKCS#12 
>>>> document
>>>> with that entity. I would also have an access policy in place based on
>>>> the data in said document. I would also call "You" by phone to give 
>>>> you
>>>> the password of that PKCS#12 document. Once that's all sorted, you can
>>>> open the document, get your crytpo data installed in your local 
>>>> keystore
>>>> and then visit the resource I've published :-)
>>>> Links:
>>>> 1. http://research.microsoft.com/en-us/projects/u-prove/
>>>> 2. http://en.wikipedia.org/wiki/Zero-knowledge_proof -- I don't see
>>>> anything about that being incompatible with what the combined use of
>>>> de-referencable URIs based names, Linked Data, Entity Relationship
>>>> Semantics, Reasoning, and existing PKI deliver.



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

Received on Thursday, 18 October 2012 18:28:00 UTC

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