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

Re: Browser ID, WebID & URLs

From: Brian Smith <bsmith@mozilla.com>
Date: Mon, 18 Jul 2011 10:05:04 -0700 (PDT)
To: Henry Story <henry.story@bblfish.net>
Cc: WebID XG <public-xg-webid@w3.org>, Ben Adida <ben@adida.net>, dev-identity@lists.mozilla.org
Message-ID: <578781116.546474.1311008704946.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Henry Story wrote:
> Brian Smith wrote:
> > 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.

The RP would have to include an identifier for the user in that GET, which means that the identity provider learns that the user is logging into the RP. The RP would have to go to great lengths to properly mask its identity in that situation--AFAICT, the RP masking its identity would be the hardest and more error-prone part of the whole thing, and most RPs wouldn't bother.

With short-lived keys, avoiding the revocation mechanism, and avoiding the profile fetch, the user's interaction with the RP is hidden from the identity provider all the time, by default, and in a way that is better than failsafe.

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

1. Fingerprinting: the GET that Google does when it is crawling your website won't be identical to the GET it would do when the user is logging into Google.

2. When Adult Friend Finder does a GET for a user's profile, it is pretty likely that the user is logging into Adult Friend Finder; it is safe to assume that they aren't just crawling the web to build a general-purpose search engine.

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

If you have a revocation mechanism, then some RPs will use it with good intentions even when it isn't necessary. It would be better for the RP to tell the browser "this key is too old for me" and have the browser deal with that.

- Brian
Received on Monday, 18 July 2011 17:05:33 UTC

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