W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

Re: [saag] Liking Linkability

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 24 Oct 2012 10:03:09 -0400
Message-ID: <5087F51D.3040503@openlinksw.com>
To: nathan@webr3.org
CC: Robin Wilton <wilton@isoc.org>, Ben Laurie <benl@google.com>, Ben Laurie <ben@links.org>, Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org
On 10/24/12 8:03 AM, Nathan wrote:
> Robin Wilton wrote:
>>
>>
>>
>>
>>
>> Robin Wilton
>> Technical Outreach Director - Identity and Privacy
>> Internet Society
>>
>> email: wilton@isoc.org
>> Phone: +44 705 005 2931
>> Twitter: @futureidentity
>>
>>
>>
>>
>> On 24 Oct 2012, at 10:30, Ben Laurie wrote:
>>
>>> On 23 October 2012 10:58, Robin Wilton <wilton@isoc.org> wrote:
>>>>
>>>> On 23 Oct 2012, at 09:44, Ben Laurie wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>> Not disagreeing with any of the above, but observing that:
>>>>
>>>> a) There's no particular reason you could not have an email per site
>>>> as well as a key per site.
>>>>
>>>> b) Linkability it not, as you say, inherently bad. The problem occurs
>>>> when you have (effectively) no choice about linkability.
>>>>
>>>>
>>>>
>>>> But it's very hard to use either of those mechanisms (separation 
>>>> through
>>>> emails or keys) without giving some third party the ability to 
>>>> achieve total
>>>> linkability. (In other words, both options remove effective choice).
>>> I agree that emails are a problem, but not at all sure why keys are?
>>> In the case of appropriate selective disclosure mechanisms, even if
>>> there were a third party involved, they would not be able to link uses
>>> of the keys. Also, if you insist on using linkable keys, then per-site
>>> keys do not involve third parties.
>>>
>>
>> It may just be that I'm not getting a clear mental picture of your 
>> architecture. But here was my thinking:
>> - If you use symmetric keys, you get a system which can't scale 
>> unless you opt for Schneier's idea of a key serverů but then the key 
>> server becomes a point of potential panopticality.
>>
>> - If you use PKI, *and* you want your communicating parties to be 
>> able to validate the certs they're relying on, then you have to 
>> design a CRL- or OCSP-like mechanism into the architecture, and again 
>> you end up with a component which is potentially panoptical. (Plus, 
>> you have to address the 20-year-old problem of how to make PKI usable 
>> by human beings, when recent history suggests that PKI only takes off 
>> where human beings are kept well away from it).
>
> CRL is pretty much built in to WebID, if you remove a public key from 
> the document pointed to by your uri-identifier, then it's no longer 
> valid for use in WebID - auth can't happen, rendering the cert useless 
> for WebID.
>
>
>

For sake of clarity, Nathan is speaking about the WebID authentication 
protocol.

A WebID on its own refers to an resolvable (de-referencable) identifier. 
The WebID protocol verifies the aforementioned identifier (entity 
denotation mechanism) via a combination of cryptography and entity 
relationship semantics oriented logic.

-- 

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







Received on Wednesday, 24 October 2012 14:03:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 14:03:44 GMT