Re: WEbID Todos

On 8 Oct 2012, at 14:04, Ben Laurie <benl@google.com> wrote:

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

It works for the whole web when you want to authenticate in a linkable manner.
It solves an important problem for decentralised social networks. This may not
be your problem, but it is mine, and I think it is a huge space for developing
new applications that are privacy enhancing.  This type of co-operative privacy
may not interest you, that is ok - I can't dictate your priorities. If you
are interested in this, and you can find a way to make WebID work more flexibly
with new versions of TLS that will be great. But I am not interested in developing
those - I want to develop the social web. I can do it now. 

And in fact I am going to turn off this mailing list a bit to get back to 
programming.


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

Social Web Architect
http://bblfish.net/