We released our Single Sign On framework into the wild yesterday. After having Priya annouce it in the March eBulletin, we finally had our chance to use it in a production service (we've been using it for internal services for several weeks, now). So, for Round 1, we chose a simple, singular service — The Personal Mail Alias Tools.
We plan on letting it run there for a week or so and see if it generates any troubles. Then, like a great hand reaching out of the sky, we will swoop down and convert many of the other services over. Small services like the Preferred first.last Web Tool and Lookup Mail Info Tool will be easy. Other easily converted services will be items like Blog and Sympa because we have access to all of their internals.
The more difficult one's will be the more closed system services. Items like mail and calendaring will either take some trickery on our part to fake it, or we will need to lay ourselves down in front of the vendor and beg them to bless us with this feature (which, we have had limited luck with in prior circumstances).
[For more information on what differentiates an "SSO Framework" from a "Proxy Credentials System", you can check out my previous entry: What Single Sign On is and is not.]
After that, I would suspect, it will become more of a matter of people approaching us asking to hook in. The more, the better; because a Single Sign On service's value is weighed by the number of applications it inter-operates with.