Re: [saag] Liking Linkability

On 24 Oct 2012, at 16:24, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 24 October 2012 16:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 10/24/12 8:03 AM, Nathan wrote:
> Robin Wilton wrote:
> 
> 
> 
> 
> 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.

+1 Nathan. 

( btw. It is always good to point people to the spec too http://webid.info/spec is the short url for it. )

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

The spec has a definition that seems pretty reasonable, ( though I think we should remove the reference to "intentions" )

http://www.w3.org/2005/Incubator/webid/spec/#terminology

WebID
A URI that refers to an Agent - Person, Robot, Group or other thing that can have Intentions. The WebID should be a URI which when dereferenced returns a representation whose description uniquely identifies the Agent who is the controller of a public key. In our example the WebID refers to Bob. A WebID is usually a URL with a #tag, as the meaning of such a URL is defined in the document refered to by the WebID URL without the #tag .


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

I would not say just implementation details. From the philosophical theory of reference 
( eg: Gareth Evans's book: The variety of Reference ) they may be, but in everyday usage 
how these things are implemented is quite important, and so are the distinctions.

According to the WebID spec definition:
 - OpenID is close [1] though they have a URL for a web page rather than an agent (not a big deal), but more importantly they don't make use of the URL to get the attributes, which is what WebID does. They certainly don't publish the public key in the OpenId profile.
 - webfinger does indeed give a method to dereference a mailto: uri, which could be used for a WebID protocol.
 - I don't think OAuth is working with URIs at all
 - Mozilla Persona could use WebIDs [2] and it would improve their protocol so dramatically, it is evident that they will at some point.

  Henry

[1] https://blogs.oracle.com/bblfish/entry/what_does_foaf_ssl_give
[2] http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid

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