Re: [saag] Liking Linkability

On 22 October 2012 17:14, Harry Halpin <hhalpin@w3.org> wrote:

> On 10/22/2012 04:04 PM, Henry Story wrote:
>
>> On 22 Oct 2012, at 14:32, Harry Halpin <hhalpin@w3.org> wrote:
>>
>>  On 10/22/2012 02:03 PM, Kingsley Idehen wrote:
>>>
>>>> On 10/22/12 7:26 AM, Ben Laurie wrote:
>>>>
>>>>> On 22 October 2012 11:59, Kingsley Idehen <kidehen@openlinksw.com>
>>>>> wrote:
>>>>>
>>>>>> On 10/22/12 5:54 AM, Ben Laurie wrote:
>>>>>>
>>>>>>> Where we came in was me pointing out that if you disconnect your
>>>>>>> identities by using multiple WebIDs, then you have a UI problem, and
>>>>>>> since then the aim seems to have been to persuade us that multiple
>>>>>>> WebIDs are not needed.
>>>>>>>
>>>>>> Multiple WebIDs (or any other cryptographically verifiable
>>>>>> identifier) are a
>>>>>> must.
>>>>>>
>>>>>> The issue of UI is inherently subjective. It can't be used to
>>>>>> objectively
>>>>>> validate or invalidate Web-scale verifiable identifier systems such as
>>>>>> WebID or any other mechanism aimed at achieving the same goals.
>>>>>>
>>>>> Ultimately what matters is: do users use it correctly? This can be
>>>>> tested :-)
>>>>>
>>>>> Note that it is necessary to test the cases where the website is evil,
>>>>> too - something that's often conveniently missed out of user testing.
>>>>> For example, its pretty obvious that OpenID fails horribly in this
>>>>> case, so it tends not to get tested.
>>>>>
>>>> Okay.
>>>>
>>>>> Anyway, Henry, I,  and a few others from the WebID IG (hopefully) are
>>>>>> going
>>>>>> to knock up some demonstrations to show how this perceived UI/UX
>>>>>> inconvenience can be addressed.
>>>>>>
>>>>> Cool.
>>>>>
>>>> Okay, ball is in our court to now present a few implementations that
>>>> address the UI/UX concerns.
>>>>
>>>> Quite relieved to have finally reached this point :-)
>>>>
>>> No, its not a UI/UX concern, although the UI experience of both identity
>>> on the Web and with WebID in particular is quite terrible, I agree.
>>>
>> It completely depends on the browsers:
>> http://www.w3.org/wiki/Foaf%**2Bssl/Clients/CertSelection<http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection>
>> If you are on Linux just file a bug request to your browser if you are
>> unhappy, or even better hack up a good UI. It's easy: just make it simpler.
>>
>>  My earlier concern was an information flow concern that causes the issue
>>> with linkability, which WebID shares to a large extent with other
>>> server-side information-flow.
>>>
>> Including BrowserId. Which has 2 tokens that can be used to identify the
>> user across sites:
>>
>>    - an e-mail address ( useful for spamming )
>>    - a public key, which can be used to authenticate across sites
>>
>>
>>  As stated earlier, as long as you trust the browser, BrowserID does
>>> ameliorate this.
>>>
>> No it does not improve linkability at all. Certainly not if you think the
>> site you are authenticating to is the one you should be worried about,
>> because just using a public key
>> by itself is enough for Linkability in the strict (paranoid) sense. That
>> is if you
>> consider the site you are logging into to as the attacker, then by giving
>> two sites
>> a public key where you have proven you control the private key is enough
>> for them to know that
>> the same agent visited both sites. That is because the cert:key relation
>> is inverse functional.
>>
>> So in simple logical terms if you go to site1.org and identify with a
>> public key pk,
>> and they create a local identifier for you <http://site1.org/u123>, and
>> then you go site s2.net and identify with the same public key pk  and
>> they give you an identifier <http://s2.net/lsdfs>
>> (these need not be public) and then they exchange their information, then
>> each of the sites would have the following relations ( written in
>> http://www.w3.org/TR/Turtle )
>>
>>   @prefix cert: <http://www.w3.org/ns/auth/**cert#<http://www.w3.org/ns/auth/cert#>
>> >
>>
>>   <http://site1.org/u123> cert:key pk .
>>   <http://s2.net/lsdfs>   cert:key pk .
>>
>> because cert:key is defined as an InverseFunctionalProperty
>> ( as you can see by going http://www.w3.org/ns/auth/**cert#key<http://www.w3.org/ns/auth/cert#key>)
>>
>> Then it follows from simple owl reasoning that
>>
>>    <http://site1.org/u123> == <http://s2.net/lsdfs> .
>>
>> One cannot get much simpler logical reasoning that this, Harry.
>>
>>
>>  There is also this rather odd conflation of "linkability" of URIs with
>>> hypertext and URI-enabled Semantic Web data" and linkability as a privacy
>>> concern.
>>>
>> I am not conflating these.
>>
> To quote the IETF document I seem to have unsuccessfully suggested you
> read a while back, the linkability of two or more Items Of Interest (e.g.,
> subjects, messages, actions, ...) from an attacker's perspective  means
> that within a particular set of information, the attacker  can distinguish
> whether these IOIs are related or not (with a high enough degree of
> probability to be useful) [1]. If you "like linkability", that's great, but
> probably many use-cases aren't built around liking linkability.
>

Harry, this document has been discussed in detail in the WebID group.
Thank you for bringing it to our attention.

I cant help but reflect at this point, that the only reason, that this
conversation has been made possible, is due to the "linkability" property
of the e-mail protocol. :)


>  This has very little with hypertext linking of web-pages via URIs. I
> think you want to use the term "trust across different sites" rather than
> linkability, although I see how WebID wants to conflate that with trust,
> which no other identity solution does.  A link does not necessarily mean
> trust, especially if links aren't bi-directional.
>
> As explained earlier, Mozilla Personae/BrowserID uses digital signatures
> where an IDP signs claims but transfers that claim  to the RP via the
> browser (thus the notion of "different information flow") and thus the RP
> and IDP do not directly communicate, reducing the linkability of the data
> easily gathered by the IDP (not the RP).
>
> I know WebID folks believe IDP = my homepage, but for most people IDP
> would likely not be a homepage, but a major identity provider for which
> data minimization principles should apply, including ownership of the
> social network data of an individual and a history of their interactions
> with every RP. I am not defending BrowerID per se: Personae assumes you
> trust the browser, which some people don't. Also, email verification, while
> common, is not great from a security perspective, i.e. STARTLS not giving
> error messages when it degrades.
>
> Perhaps a more productive question would be why would someone use WebID
> rather than OpenID Connect with digital signatures?
>
> Although, I have ran out of time for this for the time being.
>
>
>
>> My point from the beginning is that Linkability is both a good thing and
>> a bad thing.
>>
>> As a defender of BrowserId you cannot consistently attack WebID for
>> linkability concerns and find BrowserId not to have that same problem. So I
>> hate to reveal this truth to you: but we have to fight this battle together.
>>
>> And the battle is simple: the linkability issue is only an issue if you
>> think the site you
>> are authenticating to is the enemy. If you believe that you are in
>> relation with a site that
>> is under a legal and moral duty to be respectful of the communication you
>> are having with it,
>> then you will find that the linkability of information with that site and
>> across sites is exactly what you want in order to reduce privacy issues
>> that arise out of centralised systems.
>>
>>  I do think many people agree stronger cryptographic credentials for
>>> authentication are a good thing, and BrowserID is based on this and OpenID
>>> Connect has (albeit not often used) options in this space.  I would again,
>>> please suggest that the WebID community take on board comments in a polite
>>> manner and not cc mailing lists.
>>>
>> All my communications have been polite, and I don't know why you select
>> out the WebID community.
>> As for taking on board comments, why, just the previous e-mail you
>> responded to was a demonstration that we are: CN=WebID,O=∅
>>
>>
>>
>>
>>>>
>>>>  Social Web Architect
>> http://bblfish.net/
>>
>>
>
>