I hope this helps. I think the problem with writing simple introductions to openid is that it just offers too many options and it is difficult to decide how to

I hope this helps. I think the problem with writing simple introductions to openid is that it just offers too many options and it is difficult to decide how to approach. Here is an equivalent but by no means equal workflow[a]. Pre0. Choose your openids before you have the sites needing them! This is username/password registration/recovery/emails as it always was[b]. You come across a new site (web-app) and it supports openid login. Registration workflow: Reg0. We choose some openid from Pre0. Login into that openid at the openid provider's website in a new tab[c]. Reg1. We tell web-app our openid. What happens then is similar to a net banking/credit card transaction. Web-app takes us to openid provider's website. We say yes, we would like to register/authenticate/allow this and we are now registered and logged in. Reg2. We can now safely log out of our openid provider in the other tab if we want. We will still remain logged in at the web-app. Rule of thumb: Openid provider doesn't know what is going on at the webapp and vice a versa and they cannot affect each other in any way at this stage. (Separate cookies, no shared sessions.) You visit the website again. Login Workflow: Log1. We go to our openid provider first and login.[d] Log2. Then we go to our web-app and put our openid in. Webapp does some talking behind the scenes with the openid server and logs us in. Log3. After this point, web-app and openid provider do not talk or know whats going on at the other place. We logout of either server separately. End of workflow. [a] Initially, I replicated your workflow feature for feature but that felt like replicating a svn workflow in git. Just like git, openid is a new paradigm. One can replicate old workflow features in many many ways but methods of doing so are hardly instructive or interesting. If you want me to do so or bring back some/all feature(s) back into this workflow I will gladly do so, if only just to show that it can be easily done. openid is very much the git of the authentication world. It is a surprisingly elegant federated and distributed replacement for old small centralized island situations with a similar price in inertia and the learning curve. [b] May I recommend not mixing your existing ids (yahoo/gmail/etc) with these openids. The single tool for a single job philosophy is nice. wordpress.com is my favourite openid provider, simple interface, minimal and trustworthy enough. myopenid.com is a more fully featured option. [c] At the risk of sounding verbose and simultaneously committing the sin of not using example.com, here is an actual example. I am looking at the openid login box at stackoverflow.com (SO) and I own user.wordpress.com as an openid. I login to wordpress.com as "user" in a tab and then tell SO that I am user.wordpress.com. SO talks to WP and redirects me to WP. WP asks me what it should tell SO on my behalf. I am then taken back to SO. After this SO and WP do not talk amongst each other and I am logged in separately to both even though my username and password are stored and known only on WP. Neat. [d] That takes care of any possibility of phising. (There is a chance of phising if you are not already logged in to your openid provider and web-app redirects you to a false page. To mitigate this, any respectable openid provider doesn't show a login form ever on a page that you could reach after redirection from a web-app.) -- Here is the part about the home page thing I mentioned. You can make any page whose head portion you can edit an alias for an openid. So to carry forward our example in [c]. I put <link rel="openid.server" href="http://user.wordpress.com/?openidserver=1" > <link rel="openid.delegate" href="http://user.wordpress.com/" > in the head of kniwor-home-page.com which I own. Now kniwor-home-page.com is an openid. If tomorrow I lose faith in wordpress I just edit kniwor-home-page.com and let someone more trustworthy handle my username password login process. (I could potentially host a openid server myself on my own machine if I am paranoid enough.) This as I said is uber cool. I thus truly own my id! And I think you one already see all the wonderful things this brings to the table once one is past the initial learning curve. Nothing of value from the old system is really lost and all of the old can be replicated easily. You could just sign up with a new open id provider every time you need a new registration if you want to replicate the old days but it is much more neat to distribute control and trust by importance and other personal metrics. Points of failures are just shifted from places that were not created to handle them (email providers) to places that are now designed with that explicit purpose in mind and a lot of emails double up as openids if you insist that that is where you want your points of failure.