OpenID works like this:
- Users go to your website
- They have the option to 'log in' with an account they already have with another service
- They click to log inwith the other service, they are redirected to that service, with the URL of your site page appended to the request
- They log in (if not already logged in) to the service, which then asks them whether they want to allow authorization to share details with your site
- If the user approves authorization, they are redirected to the return (originating) URL on your site, the service they used to sign in with then, depending on the service and what the user allows, also sends information on the user to your site with the redirect
- When your site picks up this information, it can then process the user as having logged in (or being rejected)
There is a lot of information on the web about how this process works and how you can handle it:
http://openid.net/developers/
http://www.windley.com/archives/2006/04/how_does_openid.shtml
http://tinisles.blogspot.com/2008/02/how-does-openid-work.html
I would also suggest searching SO:
How does OpenID authentication work?
You can even see that those people who built SO itself have covered the issue:
http://www.codinghorror.com/blog/2008/05/openid-does-the-world-really-need-yet-another-username-and-password.html
If you want to use the service for registration purposes, note that you are limited to only getting information defined by the framework that the user also elects to share (e.g. location, name, email etc) - as such it should be used either for users to log in via another service (i.e. google etc), OR to populate some shared fields of a registration form 'automatically', however this is a semi-redundant use of the service - I would recommend restricting it to sign-in only, you should keep seperate any proprietary registration process.