Re: WEbID Todos

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.

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