You can be fully in control of your own OpenID if you want. Just host it on your own domain/server.
Or even easier: use delegation. Add some meta tags to the header of your blog (or any HTML page under your control), and sign up for sites using your blog URL as your OpenId.
See an example at my domain (the content is currently blank, but the meta tags are in the source code): http://jmh.id.au
I can sign up anywhere by typing in 'jmh.id.au', and it uses myopenid.com for login. If for some reason I didn't trust myopenid.com I can change providers by editing that page. So I'm not tied to any one provider.
The first is practical: you are not qualified to run OpenID on your server. Really, you're not. I'm not and I have actually implemented both OpenID providers and Relying Parties for clients before, at the old day job. If you run OpenID, you are exposed to every threat your OpenID provider is currently vulnerable to in perpetuity, unless you make it your mission in life to stay up to date on OpenID security. The people who actually do that missed a timing attack which compromised the security of nearly every OpenID-using system on the Internet. You will not do better than they did.
The second reason this is bad advice is because OpenID has a feature which should make it unnecessary: delegation, which lets you nominate any OpenID provider on the Internet as "your" provider. You are theoretically able to change that after having done it, so if you want to move your identity from Google to Yahoo you can. Delegation is a misfeature. It makes the OpenID spec roughly ten times more difficult to understand than it already was. Very few people implement delegation correctly -- of particular notice, very few relying parties implement it correctly, which means that when you come back in a few years with the same OpenID but a different underlying provider they have no recollection of you at all. That is a pretty bad failure mode for a federated authentication system, and many relying parties coded by smart people walk straight into it.
Then we come to the real meat of the matter: for an authentication system to be useful, you have to be able to use it without being able to implement it. OpenID is a user experience nightmare for non-technical users. Just the experience of actually logging in is bad enough. It also teaches your users to fall for phishing attacks against their holiest of holy credential, because every sane person uses OpenID through their email provider and OpenID teaches you that you can go to any random site, the screen is going to flash, and then you should type in your email address and password. This is phishing heaven, and losing one's email account means you lose practically your entire online identity (banks accounts, domain names, Google AdWords accounts, etc etc) even before OpenID explicitly makes your email king of all credentials.
I'm getting some cognitive dissonance here, since the grandparent says [I] use delegation and you say not to run your own server and to use delegation...
Anyway, is delegation going to get better, or should I not bother setting it up and just stick to using the same password for all my non-interesting sites? In particular, is it the site I delegate to, or the site I am authenticating myself to, or both, that can screw it up?
Sorry, that confusion was my fault: I posted the first line of my reply, and then realised I should mention delegation, so I edited it in. He must have loaded the page between the two.
Thanks for the reply patio, I haven't heard of the issues with delegation before.
Phishing attacks could definitely be a big potential problem. I'd be interested in seeing how much of the phishing and usability problems could be solved via good browser support for OpenId.
Or even easier: use delegation. Add some meta tags to the header of your blog (or any HTML page under your control), and sign up for sites using your blog URL as your OpenId.
See an example at my domain (the content is currently blank, but the meta tags are in the source code): http://jmh.id.au
I can sign up anywhere by typing in 'jmh.id.au', and it uses myopenid.com for login. If for some reason I didn't trust myopenid.com I can change providers by editing that page. So I'm not tied to any one provider.