Critiquing a Liberty Alliance Critique

by Russ Jones on September 17, 2002

in Russ Jones, Scott Loftesness, Writings

By Russ Jones and Scott Loftesness

In a recent critique of the Liberty Alliance entitled "On Liberty
and the Case for Anonymous Federation of Identity," (1)
Doug Kaye raises several critical points about the Liberty 1.0 specifications:

  • Privacy Protection. Is user privacy actually protected? Although
    stressed as an important objective, Kaye does not believe Liberty actually
    enhances personal privacy—indeed, he argues it may actually weaken
    individual privacy.
  • Single Sign-On. Is single sign-on really a convenience? Kaye
    believes the convenience of single sign-on is minimal—especially
    given the privacy tradeoffs required and the sophistication of modern
  • Targeted Marketing. Is better targeted marketing really desirable
    to individuals? Kaye argues that targeted marketing is something individuals
    largely want to avoid—not something that is good for you.

Following his critique of the Liberty approach, Kaye goes on to suggest
that an alternate approach—what he calls the Anonymous Federation
—would "retain the current levels of consumer
privacy protection, yet deliver to vendors and merchants most of the capabilities
they claim they need."

At first blush, Kaye’s arguments make a lot of sense and will appeal
to many people. But do these arguments hold up on closer inspection? And
is his notion of anonymous federation really an alternative? Before we
take a look at his conclusions in more detail, let’s put the Liberty specifications
in a marketplace context.

Liberty Alliance in Context

If we consider a bit of history, it’s important to realize that the huge
momentum behind the Liberty Alliance is largely in reaction to Microsoft’s
plans for what they called, at the time, Hailstorm (2) or
.NET My Services. Hailstorm, as originally described by Microsoft, was a
Microsoft-hosted network identity service that would allow individuals to
register once with Microsoft, supply related individual information/preferences,
and then use that identity seamlessly across many different Web sites.

Major holders of large numbers of consumer relationships saw Hailstorm
as a threat. One of their reactions was to join together in the Liberty
Alliance to develop an alternate approach that would return their individual
consumer databases to the center of any network identity universe.

Over time (and in parallel with the ramp of support building behind the
Liberty Alliance) Microsoft got the message from both consumers and particularly
from major corporations (the consumer relationship holders) who told them
that the over-reaching concept of Hailstorm would never work.

Since Microsoft pays particularly close attention to its major corporate
customers, the message was heard in Redmond and, as a result, Microsoft
morphed its Hailstorm story into a new one where Microsoft would become
simply the supplier of software that would enable major holders of large
numbers of consumer relationships to federate together as they might choose
to do so. Microsoft’s brief attempt at becoming the center of the online
network identity universe was effectively over for anything more than
simple username/password linking. (3)

But, by that time, the Liberty Alliance was up and running and its members
were trying to figure out how it was going to change the world for the
better in the face of Microsoft’s Hailstorm. After all, these major companies
came together for some very important reasons—or so they all thought
at the time.

The core focus of the Liberty Alliance became enabling major namespaces
(e.g., the major corporations with large numbers of existing online consumer
relationships) to define a standardized approach to enabling the cross-enterprise
sharing of consumer identity.

What that boils down to in Liberty 1.0 is enabling a major namespace
to act as the authenticator on behalf of one of its individual consumers
at a distant site outside the control of the namespace itself. There is
no actual exchange of consumer information specified in the Liberty 1.0

The prototypical usage scenario is a United Airlines Mileage Plus frequent
flyer customer making an online Hertz car rental reservation using the
username/password information associated with her United Airlines account
relationship. Behind the scenes, using the Liberty architecture, Hertz
would rely upon United’s authentication of its individual customer. Importantly,
both United and Hertz must maintain their own databases containing all
of the information they require as part of a business relationship with
their shared customer.

In other words, a master/slave relationship is envisioned in Liberty
1.0 where a master owns the consumer identity and is then relied
upon by a slave to verify that consumer’s identity (without revealing
any of the details of that identity) when requested by the slave. Note
that Liberty Alliance terminology calls masters "identity providers"
and slaves "service providers."

Privacy Protection

Now back to Kaye’s first argument. To the extent that the master namespace
enables a slave to authenticate an individual, the individual’s private
information is being used to enable broader access. The Liberty 1.0 specification
stresses that this must only be done with the consent of the consumer.
Specifically, Liberty says that any such authentication "should be
additionally predicated upon providing notice to the user, obtaining the
user’s consent, and recording both the notice and consent in an auditable
fashion." In effect, it should only be done with through consumer

A couple of points need to be highlighted here. First, technically the
Liberty 1.0 architecture only supports the authentication of an individual’s
account identifier by an identity provider. All that is provided is verification
by the identity provider that it holds, and has authenticated, this individual
with an existing on-file relationship.

Second, the opt-in approach recommended by Liberty is laudable—frankly,
most of lobbying activity (4) by
large namespace owners over the last several years has focused on opt-out
as their favored approach. It’s good to see Liberty choosing opt-in. (5)

However, Liberty also chose to use the word "should" rather
than "must" in its discussion of this subject—apparently
leaving the actual choice up to the identity provider, not the individual.
In doing so, it unfortunately compromised its primary objective of protecting
the privacy and security of individual network identity information. Let’s
hope the Liberty Alliance Public Policy Committee does its job and the
wording is adjusted in the next update.

Kaye points out that if "someone is able to impersonate me at one
web site, Liberty would allow that person to impersonate me at other web
sites without their having to log into them explicitly. Federation expands
the scope of damage due to identity theft." While true, this is only
half the story. Because identity information with Liberty is federated
within a circle of trust, federation also contains the scope of damage
due to identity theft.

Kaye is clearly very concerned about the distribution of private information
in multiple places and believes that any such distribution weakens the
privacy of an individual. His rationale is compelling. The reality, however,
is that today’s environment (requiring individuals to register and provide
information to multiple service providers) is actually the starting point.
Liberty 1.0 doesn’t propose to change that—rather, it simply enables
the individual to link (on an opt-in basis) an identity as it currently
exists in a specific namespace location with other service providers who
already have most, if not all, of that same information.

Single Sign-On

Kaye’s second argument is that any convenience benefit from single sign-on
is actually of minimal incremental value to individuals. In particular,
Kaye describes how individuals have other solutions in place today to
easily logon to Web sites (e.g., modern browsers can store username/password
information) and how the initial setup linking identities between identity
providers and services providers is just more work for the individual—read/decide/click,
read/decide/click, read/decide/click.

Frankly, with respect to single sign-on, for many (especially experienced)
users it’s hard to argue with Kaye’s points. But it’s worth noting that
the Liberty Alliance sponsors have a broader worldview than just today’s
browsers and we suspect that long-term they want to offer the convenience
of single sign-on to smaller mobile devices. Even on today’s personal
computers, a more seamless single sign-on approach does offer tangible
convenience advantages for new or novice users.

Kaye would likely argue that there’s an additional tradeoff of an increased
risk of loss of privacy and identity in exchange for providing the individual
with the convenience of single sign-on. However, that’s simply not the
case in Liberty 1.0 where no actual individual identity information is
shared between identity provider and service provider.

Kaye does mention that there may be intranet applications for federated
identity. We believe there are substantial opportunities to streamline
sign-on and access to partner Web sites in an extended enterprise scenario.
For example, a General Motors employee, logged on and authenticated to
the GM corporate network, can be seamlessly passed over to the General
Motors 401k site, maintained and run by Fidelity Investments. This streamlines
the user experience and, more importantly, takes both companies out of
the business of separately managing partner network username/password

Although Kaye doesn’t address this particular issue, what is potentially
much more valuable (and convenient) to individuals beyond single sign-on
is to allow them to selectively share information from an existing identity
provider relationship with a new service provider. This would allow an
individual to quickly complete the registration at new sites by simply
instructing the individual’s preferred identity provider to share the
individual’s registration information with the new site. Liberty 1.0 is
silent on this opportunity.

Targeted Marketing

Kaye’s third argument, while likely an accurate assessment of how consumers
actually feel about targeted marketing, doesn’t correlate to anything
specifically called out as a Liberty Alliance objective in the initial
version of the specifications. There are allusions in the Liberty Version
1.0 Overview to eventually sharing an individual’s buying habits, history,
and shopping preferences at sign-in time—but none of that is actually
addressed in the 1.0 specification.

Kaye’s Alternative: Anonymous Federation

Kaye suggests that there’s a simpler approach that
offers most of the benefits claimed for Liberty. He demonstrates this
approach using the Amazon Associates program as the illustration. Essentially
the anonymous federation approach boils down to using URLs (actually HTTP
POSTs) to contain the necessary linking information to be passed from
a referrer to the service provider. The linking information (URL+HTTP
POST) is used in combination with previously stored cookie data to link
the individual’s identity (at the service provider) with the specific

While a valid technique for streamlining the online shopping experience—that’s
why Amazon created it—it can’t be duplicated (6)
for use by other Web sites and may have certain security and privacy disadvantages.

Kaye’s underlying point here—which we strongly agree with—is
given the vision and sample use cases presented by the Liberty Alliance,
how is federated identity really that different than traditional Internet-based
comarketing? Our belief is that it can be different and far more compelling,
but the alliance needs to do a much better job describing how the technology
can be used in different scenarios and where the roadmap will take the


Kaye believes that "Liberty is unnecessary and a threat to consumer
privacy, and that alternatives exist that can deliver a majority of Liberty’s
benefits without the drawbacks." To his specific points, we believe:

  • Kaye’s argument about the Liberty 1.0 specification not adequately
    addressing individual privacy issues seems particularly weak. It is
    not clear that the implementation of Liberty as defined in the 1.0 specification
    would compromise in any way an individual’s privacy or the security
    of personal information held by an identity provider.
  • Kaye’s argument that single sign-on offers weak consumer convenience
    benefits is valid—particularly to the experienced Internet hands
    that will critique the Liberty 1.0 specification—although newer
    users will find the convenience benefits more meaningful.
  • Kaye’s argument that Liberty facilitates target marketing—which
    is an inherently bad thing—is tangential to the mission and objectives
    of the alliance.

Liberty criticism boils down to market adoption criticism. Does it provide
enough value to actually motivate any real world implementations between
Web sites? Is the user value proposition strong enough to drive end-user
adoption? Of course, neither has been demonstrated yet. And if not demonstrated
soon, players who should have known better will have poured a lot of time
and energy into the Liberty Alliance. But that’s also happened many times


  1. See
  2. Hailstorm was an amazingly bad choice as a product
    code name and helped inspire some of the negative reaction to the very
    service concept Microsoft was promoting.
  3. Microsoft hasn’t given up on storing some private
    user credential information. It recently announced it was removing the
    wallet functionality from Passport and moving it into the "MSN
  4. For example, a recent battle in California over financial
    privacy legislation (SB.773 introduced by Sen. Jackie Speier, D-Hillsborough)
    focused around the financial services industry’s strongly held belief
    that "opt-out" was most efficient yet still provided individuals
    with the privacy protections they needed. Consumer groups, on the other
    hand, felt strongly that only "opt-in" provides the necessary
    privacy protections.
  5. The original Microsoft Hailstorm approach was also
    described as "opt-in."
  6. Unfortunately, the Amazon Associates approach is
    patented. See U.S. Patent: 6,029,141.

Publication History

Initial Publication Date: September 17, 2002

Comments are closed.

Previous post:

Next post:

Clicky Web Analytics