Re: Browser ID, WebID & URLs

On 7/18/11 12:43 PM, Henry Story wrote:
> On 18 Jul 2011, at 07:08, Brian Smith wrote:
>
>> Henry Story wrote:
>>> You seem to have made short lasting keys a necessary part of your
>>> protocol.
>>> Why is that? I am pointing out one can enable longer lasting ones too.
>> Long-lasting keys require a revocation mechanism. But, the revocation mechanism would likely leak information from the relying party to the identity provider about which identity is being verified.
> Well not that much really. In the case of WebID you do an HTTP GET on the URL. A service that wanted to be somewhat anonymous could go through a proxy. And a WebID can be part of any kind of list in any case. So there are thousands of reasons why services may be doing an HTTP get on one of them. The fact that google crawls the web says nothing about my activity anywhere.
>
>> By making keys short-lived, we can avoid the need for a revocation mechanism, and thus avoids this leakage. It does mean contacting that the browser will contact the identity provider more frequently, but I do not think that is a big deal.
> In any case one could easy to have it both ways: if a particular certificate is short lived, the need to verify is removed. If keys are longer lived, then it depends somewhat on the Relying Party's security requirements.

Orthogonal to the comments above re., privacy concerns: You can be your 
own IdP re. WebID. In short, this is the inevitable future even though 
bootstrap will be via 3rd party IdPs short term.

When a 3rd party isn't the IdP you don't have to worry about said party 
tracking your movement.



Kingsley
> Henry
>
>
>> Regards,
>> Brian
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Monday, 18 July 2011 12:14:19 UTC