Liberty Alliance Has Missed the Point

Wouldnt it be great if you could book an entire trip, flight, hotel and car on sites of your choosing without having to log on to more than one site? The Liberty Alliance Project, a consortium of IT vendors and customers dedicated to creating identity management standards, thinks so, and its just-released Phase 2 specifications for the Liberty Alliance Web Services Framework make this kind of ID service possible.

A lot of vendors are excited about this type of capability, from Liberty Alliance backers, such as Sun and VeriSign, to companies that support competing standards, such as IBM and Microsoft. Single sign-on and federated ID management are also very useful features for handling applications and portals within a large company.

But what about the ability to access different Web sites and Web services with a single log-on? I mean, it would be nice not to have to log on to related Web sites and services all the time, but on my list of Internet and technology annoyances, this doesnt rank very high. And while users may welcome this kind of convenience, they will do so only if it doesnt cost them in privacy and security.

Liberty Alliance members realize this is their main hurdle. With the Phase 2 specifications, the Liberty Alliance released a privacy and security best-practices guide for companies implementing Liberty Alliance ID management. While welcome, the Liberty Alliance specifications suffer from the problem of many standards, the inability to enforce best practices. Reading through the guide, you cant help but notice that there are far too many "shoulds" and not enough "wills" or "musts."

The history of the Web has demonstrated that many companies and Web sites will say the right things about privacy while at the same time wriggling through whatever holes they can find to profit from users private data. For example, some Web sites prominently display a privacy policy while employing a browse-wrap license that essentially invalidates the privacy policy as soon as a visitor clicks on any link in the site.

This isnt to say that the Liberty Alliance Web Services Framework doesnt have good privacy and security mechanisms. In fact, they are very good. The Phase 2 specifications contain strong security profiles and permission-based attribute-sharing features that can ensure user privacy and give users control over the information about them that can be shared.

However, these mechanisms work only when sites choose to implement them correctly. A site or group of sites and Web services using these capabilities could give users the ability to choose when and where they want to share data and to control the amount of data shared. Or these capabilities could be implemented in a way that might make users think they have control when they actually dont.

The Liberty Alliance can do better. If the groups members really want to make users feel safe about using federated ID and single sign-on across Web services and sites, they should make it easier for users to empower themselves no matter how well the sites and services follow privacy guidelines.

What Id like to see the group do is add more mechanisms to make it easy for third-party developers to create tools that give users total control over how their data is shared. A good model for this is the Internet2 groups Shibboleth ID management specification, which was designed mainly for academic institutions. In Shibboleth, users have built-in controls that give them final say over how their data is controlled.

While the Liberty Alliance specifications come close to this, they still rely on the developer of the service or site to do the right thing. I know its tough for a consortium of vendors and IT companies to make a change that gives final control to users. But thats what will be needed to make people comfortable with this kind of federated ID system.

That comfort is essential because, if the users dont come, there wont be any IDs to manage.

Labs Director Jim Rapoza can be reached at jim_rapoza@ziffdavis.com.