Re: [saag] Liking Linkability

On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:

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


Kingsley, thanks for pointing this out.

I think some of the confusion arises from the fact that a webid is
sometimes not that clearly defined, and people focus on the protocol.

In particular a WebID is a URI that references an Agent (human or machine)

Similarly, email will become WebIDs using the webfinger spec (when that's
complete)

It can be argued that OAuth/OpenID identifiers are also WebID but with a
different auth protocol.

Mozilla persona, although certainly useful, would possibly not fit into the
same category, as they use a proprietary identification system.

The whole idea is that WebID brings things together at an architectural
level.  "The WebID Protocol", certs, X.509 are implementation details
really.


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

Received on Wednesday, 24 October 2012 14:24:53 UTC