<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don't understand what you are trying to say there. The whole entire<br>point of OpenID is third party providers. There is no need for OSM to
<br>have it's own provider. I'd almost prefer it not to.</blockquote><div><br>There is no need for OSM to be its own provider.  I would also prefer it not to.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I have had the same temptation for my own projects; being<br>> able to _offer_ openid seems to give both the openid benefit and the<br>> closed id benefit.<br><br>What do you mean? What is the "closed id benefit", except that it's
<br>easier to implement.</blockquote><div><br></div><div>Sometimes developers are reluctant to push out "mission critical" aspects of their service to third parties.  For example I wrote a large social web 2.0 project which relied on an early version of inames for its identity management.  When inames was revised all of the user accounts were broken for a while (we could no longer talk to the password database).  On a more personal note, I've tried to log into services like Jyte when my OpenID provider was down for maintenance...  and could not.  If your OpenID provider were to blow up, you cannot log into anything at all.  Another risk of OpenID, or any third party ID service, is that it is subject to man in the middle attacks.  What if the provider is malicious - or is subverted?
<br><br> - a<br></div></div><br>