Progress and some thoughts

[Martin Atkins]

meepbear * wrote:
>> I don't follow -- if my consumer gets the server's key from the UA,
>> how do I know that a server was involved at all?
> 
> My problem is actually with the user being able to arbitrarily decide
> where the consumer will connect to. Someone could put in a legitimate
> URL, but they could also put in the URL of a server they control which
> does nothing but accept incoming connections and then stalls, forcing
> the consumer to wait until its timeout since it can't tell the
> difference between an attempt to waste server resources or a slow
> connection, 
[snip]

So-called "tarpitting" of servers is always a concern, but the current
OpenID implementations work around it by using a "paranoid" user-agent
library which has a realistic but quite short timeout on the whole request.

If your ID server has a slow enough connection that it takes longer than
the timeout then unfortunately you lose. Your only recourse is to put
your identity server on a more sensible connection or make use of
someone else's identity services. Since the identity URL and the
identity service that asserts it are separate, one can switch between
identity services at will.

>>
>> On the other hand, the server doesn't know that you supplied a URL and
>> clicked a button. Maybe you thought you clicked "About Us" on my
>> website, but my website redirected you to livejournal without your
>> asking, in an attempt to figure out who you were. So, if you show up
>> at the server with a request to give your identity to a server you've
>> never approved before, the only safe thing for the server to do is to
>> stop and make sure you know what's happening.
> 
> But the consumer can only know your URL after you've already supplied it
> at least once. A rogue site could attempt to ID me without my knowledge,
> but that would do no good since livejournal can't ID me without the URL
> to my blog even if I am logged in to it.

This is the kind of "attack" that this confirmation step is attempting
to resolve:

Imagine that Bill and Bob are a couple. Bill and Bob both have public
weblogs. One day, Bill and Bob have a massive bust-up and part company.
Bill might be curious, though, as to whether Bob is still checking up on
him through his public weblog.

Bill can include code on his site which silently checks if every visitor
is Bob. Most of the time there will be no reply, but if Bob comes along
while he is logged into his identity service, Bill will get an
affirmative response from the server and will know that Bob visited;
Bob, unless he is being particularly vigilent, will not notice the
transaction even occured.

With the confirmation step combined with an "always allow this site"
option, users can be sure that only sites they trust can find out that
they are them. Identity servers will differ in their implementation of
this, but hopefully most will provide a per-trustroot memory and some
may even provide a permanent "allow everyone" option for those who have
nothing to hide. Some other ID servers might just approve everyone
outright without attempting to confirm, as the confirmation step isn't a
required part of the spec. Users should choose an identity service that
fits their needs.