W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: WEbID Todos

From: Ben Laurie <benl@google.com>
Date: Mon, 8 Oct 2012 13:04:43 +0100
Message-ID: <CABrd9SSqAZbwuOuqO6SYE8=t9aQ6UpjntDuh1oH9yN6S9r3a7A@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, "public-webid@w3.org" <public-webid@w3.org>
On 8 October 2012 13:01, Henry Story <henry.story@bblfish.net> wrote:
>
> On 8 Oct 2012, at 13:33, Ben Laurie <benl@google.com> wrote:
>
>> On 8 October 2012 10:53, Henry Story <henry.story@bblfish.net> wrote:
>>>
>>> On 8 Oct 2012, at 11:36, Ben Laurie <benl@google.com> wrote:
>>>
>>>> On 6 October 2012 08:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>>>>> WebID is actually 2 specs.
>>>>>
>>>>> 1. The first part is authentication via your public key which is a IFP of
>>>>> your identity.  In certain circumstances (ie caching, just like
>>>>> ~/.ssh/authorized_keys ) you can be done here and it operates like SSH.
>>>>>
>>>>> (1) I think solves the unlinkability problem
>>>>
>>>> How? Clearly the public key makes all authentications that use it linkable.
>>>
>>> +1 yes.
>>>
>>> It' is only unlinkable in the bizarre sense (which may in fact be nonsense)
>>> in which for Harry Halpin BrowserId  has some unlinkable properties that
>>> WebID lacks.
>>>
>>> In any case the linkability issue is one which requires one to decide who
>>> the attacker is according to the definition [1]
>>>
>>>  If the attacker is the site you are logging into, and you want to communicate
>>> with that site unlinkably - as a wikileaks leaker would want to do to cover his
>>> tracks - then using WebID, BrowserId or other such systems is really not the
>>> right technology. That is pretty self evident.
>>>
>>>  On the other hand if you want to avoid a centralised network, be able to create
>>> long term relationships across organisations - and the site you are communicating
>>> with is not an attacker - then WebID is the right solution. The linkability properties
>>> of WebID becomes a positive without the negative of the unlinkability.
>>>
>>> Perhaps that is how we can summarise the linkability properties of WebID?
>>
>> I think the question is whether linkability needs to be an unavoidable
>> side effect of identifying yourself to a particular site. Clearly
>> there are times when you want to be linked and times when you don't.
>> Is it clear that the moment you should decide this is the moment when
>> you choose your credential?
>
> You don't have to do it then. You can go to a web site, create an account there,
> then later link them up using stronger identities. There is nothing stopping
> this from being possible. WebID is just the protocol you can use when you want
> strong cross site identity. It does not have to be the authentication system
> to use everywhere: clearly not.

It doesn't have to be, clearly, but if you want adoption it also seems
clear to me that you need to offer a universal solution. If your
"web-scale" solution does not actually work for the whole web, why
would I adopt it?

>
>> I think not - and credentials do exist
>> that can be used at multiple sites unlinkably, as well as schemes
>> where credentials are per-site and so the question is moot.
>
> And when you want cross site identity WebID is the tool to use.
>
> So I think we can make some demos where the following can be done:
>
> 1. You go to a site it does not ask you for any identity
> 2. You can login using a username/password, or some unlinkable system eg: per site certificate
> 3. you then decide you trust the site, and authenticate with WebID making it linkable.
>
> I don't see why that is not feasible, you just need to think semantically about identifiers.
> That is: don't tie identity to a literal, allow yourself to use leibniz's law to work with
> identities across literal identifiers:
>
>   <http://bblfish.net/#hjs> foaf:mbox <mailto:henry.story@bblfish.net>;
>                foaf:openid <http://bblfish.net/>;
>                cert:key [ cert:modulus ...; cert:exponent ... ].
>
> Here we have 4 identifiers for the user, each with its verification mechanism. Clearly a site
> could start off with
>
>   <user1231> local:cookie "Cookie1231" .
>
> And later add
>
>   <user1231> local:cookie "Cookie1231" ;
>      cert:key [ cert:modulus ...; cert:exponent ... ] .
>
> where it only has a per site key for the user. And later
>
>   <user1231> owl:sameAs <http://bblfish.net/#hjs> ;
>      local:cookie "Cookie1231" ;
>      cert:key [ cert:modulus ...; cert:exponent ... ] .
>
>
>>
>>>
>>> Henry
>>>
>>> [1] http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-4
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>
> Social Web Architect
> http://bblfish.net/
>
Received on Monday, 8 October 2012 12:05:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:37 UTC