- SSO (single sign-on) should have been solved for the web circa 1997. At that time, all the major browsers could acquire and present digital IDs, and servers could read them.
Five years later, the de facto standard for e-commerce -- and now web services -- remains name and password authentication. It has become an article of faith that security is holding up the web services show, but we can't wish away the complexity of Kerberos, PKI (public key infrastructure) certificates, signing, encryption, and access control lists by sprinkling XML pixie dust on trust technologies.
Although the technologies are not new, they are inherently difficult, and we don't have much experience using them. Those who wait for the puff of white smoke to emerge from the standards-making Vatican only delay the day of reckoning.
Specifications such as WS-Security and SAML (Security Assertion Markup Language) do not invent new authentication, authorisation, or encryption techniques, nor should they. They aim to standardise the framework within which these techniques are used. Fair enough, but first things first. Specifications that say, "Insert your favourite authentication scheme here," presume that we know how to do that, but when authentication requires anything fancier than a name and password, typically we don't.
Consider PKI, one of the trust schemes that can be plugged in to emerging SSO frameworks. We use it every day but in a degenerate form. An SSL (Secure Sockets Layer) session is, at its core, a one-way trust relationship. You receive a digital ID from a secure server, and you trust that you've connected to LL Bean and not an imposter site. Not one person in a thousand understands the nature of this trust relationship. The inverse and arguably more crucial relationship -- namely, LL Bean trusting that you are you and not someone else with your credit card information -- doesn't exist. That's because no ecommerce site requires or even allows customers to present digital IDs.
It gets worse. The synthetic trust that digital IDs provide is supposed to be revocable. A rogue server or client can, in theory, be reined in by posting an entry to a CRL (certificate revocation list). But this procedure raises legal and technical issues that have never really been tested. Who can revoke a certificate, and for what reasons? When a certificate is revoked, will the software that accepts it as a credential even check the CRL?
We have not yet played -- and so have not yet learned -- the game of trust. Now would be a good time to read the rules and practice the techniques. You'll need to deal with these issues and technologies no matter what XML framework finally emerges.