Additional documentation

1. If you log into a website using your own OpenID (http://my.name.myopenid.com), you're keeping your password to yourself, because only your OpenID server has it. You're not giving it away to the third party website that you're logging into.
2. OpenID provides two things from my standpoint as a site administrator: 1) Security. Because the authentication process is pushed to a third party OpenID server, you won't have to worry about maintaining that huge list of usernames and passwords. 2) Usability. People who take advantage of OpenID will only have to remember one username and password for all of the sites they visit.
3. This module is the OpenID URL module. It isn't an OpenID server, yet it acts as one, delegating the OpenID authentication to another OpenID server. Usually, when you log into an OpenID-enabled website, you put in your OpenID server (http://my.name.myopenid.com). Although this is handy, it doesn't help you if MyOpenID goes down, or starts charging for their service. By using OpenID URL and delegating the OpenID process, you can use any service, and still use the same OpenID URL when logging into OpenID-enabled sites. So, when you're logging into an OpenID-enabled website, instead of using http://my.name.myopenid.com, use http://mywebsite.com, which has the OpenID URL module enabled and configured. Yay!

In your case, it sounds like you want people to be able to log into to your own website through some neato authentication method. With OpenID URL, you can delegate a user profile page as an OpenID URL. So, if someone puts in their OpenID delegate information into their user profile, they could log into an OpenID-enabled website by using http://example.com/user/4....