Re: WEbID Todos

Henry Story wrote:
> 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. 

WebID's primary usage is skewing it's capabilities in this conversation.

"It works for the whole web when you want to authenticate" is 
universally true, "in a linkable manner" is something bolted on as the 
primary use case, it isn't a requirement.

"It solves an important problem for decentralised social networks", is 
true, and the "in a linkable manner" aids this. But that by no means 
limits the use cases where WebID can be used.

A URI WebID doesn't have to be owned by an agent that holds it, or 
linked in any way to anything or anybody. It only has to be trusted 
along with it's associated key pair by the agent to which it's been 
presented in an auth scenario. That agent doing the trusting could have 
anonymously issued it, and passed it via a briefcase in a set location 
on a street corner somewhere for some other agent to use later. Along 
with any other safegaurds necessary.

WebID is used in auth* scenarios, if it's a totally anonymous non auth 
requiring scenario, then no auth* based anything will ever help.

Best,

Nathan

Received on Monday, 8 October 2012 12:31:38 UTC