Steve doesn’t actually know anything about the person entering the URL on his web page. The URL says to ask Victor, so Steve will actually make the request to Victor indirectly, by redirecting Alice’s browser to an authentication URL at Victor. Thus, Victor will receive Alice’s cookies in this redirected request, and these cookies may contain a token that represents Alice’s login session with Victor, if she has already logged into Victor once before. In this case, Victor knows Alice already, and also knows if the URL belongs to Alice. Thus, Victor can answer YES or NO and sign the answer using a shared key only Victor and Steve know. The signed answer is sent back to Steve and Steve can verify the signature came from Victor.

If Alice has never logged into Victor before, Alice will not yet have a session cookie with Victor, and Victor will present Alice with a login page. Alice (or the bad guy using Alice’s URL) must now log into Victor with a username/password and get a session cookie with Victor before Victor can answer Steve with YES or NO.

So you cannot simply pose as Alice by using her URL on an OpenID site, unless you know Alice’s username/password with Victor. If you are Alice, and you’ve already logged into Victor once, you can use your OpenID URL at any OpenID site without ever needing to enter a username/password again (until your session expires with Victor)

Hope that clears it up.
Cheers!
– Brian

I’m getting confused at steps 12-14. How does Victor check that it’s actually Alice who is asking and not just someone who knows Alice’s OpenID URL?

Thanks.