W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

Re: Browser ID, WebID & URLs

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 18 Jul 2011 13:43:27 +0200
Cc: WebID XG <public-xg-webid@w3.org>, Ben Adida <ben@adida.net>, dev-identity@lists.mozilla.org
Message-Id: <8CE2C686-E076-411B-94C6-B84F277ADAE2@bblfish.net>
To: Brian Smith <bsmith@mozilla.com>

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. 

Henry


> 
> Regards,
> Brian

Social Web Architect
http://bblfish.net/
Received on Monday, 18 July 2011 11:44:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:25 UTC