Friday, September 13, 2002

Taking Liberties Over the last year, the Liberty Alliance has generated a lot of press, and a good bit of confusion. The confusion is understandable, given the permutations that the organization has gone through in such a short time frame. But given the importance of federated identity, it’s worth discussing some of the more salient—and confusing—issues related to the alliance, and its future.   Liberty at first seemed like yet another “anti-whatever-Microsoft-is-doing” organization. And if the Liberty Alliance had truly established such a negative goal for itself, then it‘s prospects would have been dim. To its credit, however, the organization’s leadership worked hard to change that perception and establish a realistic and positive mission for the alliance.   Eric Dean, CIO of United Airlines and until recently president of the Liberty Alliance management board, along with other people from companies on the management board, took control of the organization. They focused not on creating a competitor to Passport, or on following anyone’s anti-Microsoft agenda, but on a standard for how authentication services can interoperate. The first version of the Liberty specification, released at Catalyst in July, wisely leverages the Security Assertions Markup Language (SAML), extending that standard’s scope with useful implementation detail for simplified Web sign-on.   At Catalyst, Microsoft also announced support for SAML. (Well, partial support. Microsoft will support SAML assertions in combination with WS-Security in its products. Microsoft won’t support some components of the SAML 1.0 spec, such as the SOAP binding.) Likewise, the SAML community quickly showed clear support for WS-Security as a security envelope, and is already working on a SAML binding to WS-Security. So, what once looked like a large chasm between Microsoft, the SAML community, and Liberty Alliance is now a very small gap. Interoperability is inevitable at this level because the market simply demands it.   In spite of the good news, however, there’s still some confusion. To the consternation of many in the Liberty Alliance, for example, folks in the trade press still refer to the organization as being led by Sun. And many articles still imply that Liberty is indeed an authentication service that will at some point compete with Passport, when that’s clearly not the case. This has to drive the PR folks nuts.   Don’t be surprised when a Liberty board member or two launches their own services to compete with Passport, however. And that’s where the issue of a Liberty brand or logo comes up, which tends to be a point of confusion. In his recent InfoWorld column about Liberty, P.J. Connolly ends a pretty positive assessment of the 1.0 specification with these statements:    “. . . a ‘Liberty logo’ indicating that XYZ Corp.'s Web site conforms to or uses the Liberty federation methods is necessary. Sure, not having a logo may spare the project's membership from a nasty bun-fight over who gets to display the logo. But I'd feel a lot safer about federating my identity between sites if I knew how it was being done, or at least whose method I was trusting.”   With all due respect to Mr. Connolly, I don’t agree. He’s certainly right in saying that efforts at compliance or interoperability testing, along with a branding program, would be a political nightmare. But what would it really buy if they went to all that trouble? Not much.   Technology is obviously important. But “trusting” a company to federate identity just because you know what technology and standards they’re using isn’t wise. Any company that fully and completely supports the Liberty specification can still violate my privacy. Just because a given company uses the Liberty specification—or brandishes some logo—does not mean anyone should “trust” them, or assume that everything’s okay just because they’re using “good technology.” How comfortable anyone feels about doing business with a company comes down to the processes the company uses, its privacy practices and policies, and the contracts, implied or real, that it makes with its customers. Technology can support good process and policies, or bad processes and technology.   More to the point, I think the companies on Liberty’s management board did a good job of marshalling resources to create a useful spec. But I’m not convinced all of those companies have the consumer’s best interest at heart, especially when it comes to fair use, copyrights, and other complicated issues that I’m concerned about. And I won’t be convinced that they do if they suddenly display a Liberty logo.   Does that mean I don’t think the Liberty spec isn’t useful? To the contrary. I just think it’s important to realize that branding Liberty doesn’t really matter. We don’t have a Kerberos logo program, or an X.509 logo program, and other programs to “logo” standards compliance have largely failed. In fact, a logo program could, due to the political issues Mr. Connolly raises, actually get in the way of implementation and practical use of the spec.   Now that Liberty has published a specification, however, the inevitable “what now” stories have begun to appear, especially since the alliance announced that Eric Dean has stepped down and that it will elect a new management board president in the next few weeks. In covering this story, a posting on the Register this week says that “liberty's long-term role is also in question. It emerged in July that members are considering submission of specifications to the Organization for the Advancement of Structured Information Standards (OASIS), potentially leaving Liberty bereft of a mission.”   To me, this isn’t necessarily bad news, but it does raise an imporant issue.   The Liberty specification provides an indication that customer organizations can and should be more involved in the standards process. But as I’ve pointed out before, everybody and their mother seems to be creating identity and security standards lately. It’s fair to say that any future work Liberty does could overlap with efforts within OASIS and other standards bodies, such as the W3C. The longer Liberty continues to operate as-is, and the more paying members it accumulates, the more likely it will be that Liberty will, by default, become a competing standards body. I’m not sure that’s in anyone’s best interests.   In short, the Liberty Alliance must soon decide whether it will hand its work over to existing standards bodies at some point and step aside, or become a long-lived standards effort in its own right. In either case, it must work to reconcile its efforts with OASIS in particular, which has taken on an important role in creating the next generation of Web security standards.   If Liberty provides a forum for a group of concerned companies to come together, define requirements, and submit specifications to an existing standards body, then that’s a good thing. In other words, if Liberty ended up being an adjunct to an existing standards body, I don’t think it would be “bereft of a mission.” It might, in fact, be much more effective, helping reduce the confusion and accelerate convergence around a consistent security standards framework for the Web.   No one should interpret this to mean that I don’t think that the Liberty Alliance was a bad idea. The alliance overcame my initial skepticism regarding its motives and created a useful specification. In perhaps its most important impact, the Liberty specification helped drive momentum behind and increased the pressure on Microsoft to support SAML. That’s good for customers, vendors, and the industry at large. But now that we have some signs of convergence in the security standards arena, the Liberty Alliance should carefully consider its next move. And in that process, it shouldn’t let the natural instinct for self-preservation overcome what’s best for the cause that the Liberty Alliance has, thus far, done a good job in serving. 6:20:19 PM

Is that Smoke I Smell? And Who's Fiddling? Dan Gilmore's column on the AT&T/AOL deal is food for thought, for all of us. 10:29:01 AM