Re: [saag] Liking Linkability

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
> 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://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 )
>
> 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.

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

Received on Monday, 22 October 2012 15:14:19 UTC