Re: [saag] Liking Linkability

On 24 October 2012 17:00, Henry Story <henry.story@bblfish.net> wrote:

>
> 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
>
> WebIDA 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<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#dfn-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.
>

the current draft of webfinger allows dereferencing a mailto: URI ... in
fact it is anyURI


>  - 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<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>
>>
>>
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>