Re: Browser ID, WebID & URLs

On 7/18/11 6:05 PM, Brian Smith wrote:
> 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.

But you assume a User can not be his/her own IdP. Basically, they are 
the passport office and passport bearer. The AWWW is based on a 
different realm, one is which the insurmountable in our human space is 
possible. Not only can a user be his or her own IdP, they can have 
multiple personas at the same place and time. Again, think 'Peter 
Parker' and 'Spiderman'.

It's a sad myth that folks have been lead to believe that the InterWeb 
requires intermediaries operating at the same levels in the network 
stack. The Freedom box meme boils down to refuting the aforementioned myth.

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

Again, digest my comments above re. IdP misconception. People will soon 
own Personal Data Spaces on the InterWeb. They'll be their own IdP (and 
more), and it will happen through user interactions that are even 
simpler than what exists in today's browser driven WWW. This is 
inevitable, and I'll bet every dime I have on that inevitability, 
without breaking sweat.

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

Again, you are basing this on a misconception.

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

Yes, but that happens naturally in the WebID realm. You don't need code 
for that. Its in the data, courtesy of Linked Data which is based on a 
logic based conceptual schema.

Kingsley
> - Brian
>
>


-- 

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 17:20:22 UTC