I’ve updated the SAML-lSSO and SAML OpenID Profile specs just to bring them up-to-date with the latest revisions of various SAML and OpenID specs and to fix minor editorial issues. The SAML-lSSO spec is presently not a current IETF Internet-Draft — it’s prior version expired a few months ago. We’re thinking about whether we want to pursue that spec “officially” or not. The issue with it being that in implementing it, one can optionally turn security completely off — which is a “feature” various folks advocating for so-called “open Internet” identity management desire. But SDOs such as IETF, OASIS, W3C, Liberty Alliance, etc all would look askance at blessing such a spec. In fact the IETF definitely would not allow it to go forward in that they have an explicit policy against promulgating insecure protocols.
The SAML OpenID Profile is a simple hack I threw together a year or so ago (in a single afternoon) to prove the point that there’s nothing OpenID accomplishes protocol- and user-experience-wise that is inherently un-do-able with SAML. 
Anyway, here’s the links to said specs…
SAMLv2 Lightweight Web Browser SSO Profile
OpenID-SAML Lightweight Web Browser SSO Profile – Draft 02
=JeffH sez check ‘em out.
 Note that I’m not claiming that they are equivalently “easy” to implement. By “implement” I mean to write code implementing the protocol on both or either the Relying Party or Identity Provider (aka OpenID Provider) side. Also note that I don’t use the term “implemneting” as a synonym for “deployment”. Also, I am not claiming that they are equivalently “easy” to deploy. Almost all the artifacts of deployment are inherent in how a protocol is implemented. A “feature” that’s often claimed about OpenID as a differentiator is that anyone with a minimally capable hosting environment can field an OpenID relying party. I.e. they don’t need root access, nor access to their webserver configuration, etc. In fact, the same is true with some (all?) of the “scripty” SAML implementations, e.g. ZXID being a case in point.