Burton Group Identity Blog

Hopes and concerns for identity

Blogger: Ian Glazer

A friend in the industry recently asked me for my thoughts on OpenID, InfoCards, and the US federal government's work to consume non-government issued credentials. Letting the question rattle around in my head for a while, here's what I've got so far.

My hope is that the overall ICAM initiative is successful—not because I have been eagerly waiting to interact with the federal government using some form of authenticated credential—but because we (citizens, enterprises and government) are at a pivotal moment in the history of the web. With the US government working with both the OpenID and InfoCard Foundations, there exists an opportunity to change how individuals interact with large organizations, both public and private. For the first time, individuals would be able to (even encouraged to) interact with a large organization (such as the US federal government) using an identity asserted, not by the large organization, but by the individual. In this case, the State is no longer the sole provider of identity. This breaks the monopoly that the State has had on credentials and is indicative of the future to come.

But there is a long road to walk before getting there. There are numerous concerns with these plans. Among these are notable security concerns, especially with OpenID, that the identity community is not blind to. These are not my primary concerns.

My primary concern is with the establishment of standard user behavior that could prolong existing problems. Today, after decades of enterprise training and a decade of consumer training, people naturally expect to see two text boxes on web sites. One is for their username and the one with the little stars is for their password. This behavior is ingrained. Changing this behavior is no small feat - just ask the OpenID and InfoCard groups. But it is a change that must occur to normalize people using something stronger than username and passwords to authenticate themselves.

My concern is that the behavior that is being established as a norm - the use of either an identity selector or some other user interface means - will become the username/password for the next generation. This isn't a hypothetical problem; the writing is already on the wall. Currently, OpenID will only be accepted for low-value transactions with the government known as Level of Assurance 1 (LOA1). Activities like filing tax returns requires a far greater assurance that the person is who they claim to be and thus require a Level of Assurance 3 identifier. And there is problem. The way people use an LOA3 credential may be very different than how they do so with an LOA1 credential.

If we, as an industry, normalize user behavior that meets LOA1 needs but not LOA3, we are training in behavior that has to get untrained in a near future. What the government and its partners are on the path to doing is effecting real cultural change. This kind of change doesn't happen often and is hard to do, and especially hard to undo.

I definitely want a future in which I can assert my own identity without validation from the State, but I am very willing to wait for that future to assure that the behavior the industry normalizes is one that will work for generations to come.

US Government Identity News

Blogger: Bob Blakley

9/9/9 was a day of announcements.  You’ve already undoubtedly heard about the 64GB iPod touch, and if you’ve also heard about the new Leica M9 you know what to get me for Christmas this year.

But the identity world had its own big news today; the news is that the US Government has teamed up with the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon in creating the Open Identity Initiative. 

This is a really big deal, for two reasons.

First, as a condition of playing with the government in this game, OIDF and ICF have had to address the longest-standing and most serious defect in the open identity ecosystem: the lack of a trust infrastructure.  “What’s a trust infrastructure”, I hear you cry...

When you receive an X.509 certificate from a PKI provider, you can go to the provider’s site and read its Certification Practice Statement.  This statement provides three critical pieces of information:

1. What the provider does to ensure that the person who sent you the certificate is who he says he is.
2. What the provider does to ensure that its own systems aren’t compromised in a way that would allow people to create fraudulent certificates or steal private keys.
3. What obligations the provider undertakes and what remedies it will provide to its customers (i.e. YOU) if it breaches those obligations.

There’s never been any equivalent of a Certification Practice Statement for open identity providers.  Today’s announcement changes that.  The Open Identity Initiative has created a Trust Framework Provider Adoption Process which will allow organizations to set themselves up as roots of trust for open identity.  Organizations which serve as trust roots will assess the practices and guarantees of identity providers, and they will establish registries of providers and “score” them against a set of identity assurance criteria aligned with the Liberty Alliance Identity Assurance Framework and the OMB M-04-04 and NIST SP 800-63 guidelines.

So, if a few serious organizations sign up to become Trust Framework Providers, we’ll finally have a trust infrastructure for open identity.

The second reason today’s announcement is a really big deal is that, after years of government attempts to create identities and assign them to citizens (via such bad ideas as the UK National ID scheme and the US REAL-ID act), a government has finally recognized that individuals already HAVE identities, and that it’s a better idea, for most purposes, to use these identities than to establish a new government bureaucracy to create new identities – especially if they’re identities people don’t want.

If this initiative succeeds, and I hope it does, it’s almost certain to be a much cheaper route to government consumption of reliable digital identities of citizens than something like REAL-ID would be.  And it will preserve consumer choice at the same time as encouraging innovation in commercial identity technology.

So three cheers for Vivek Kundra and the boards of the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon.  And while we’re at it, let’s not forget to congratulate OSIS and the Internet Identity Workshop, where many of the technologies behind today’s announcement were developed and more of the ideas were born, and the Liberty Alliance, whose work on the Identity Assurance Framework is the keystone of the trust infrastructure we are finally about to see.

More discussion of user centric identity

Blogger: Gerry Gebel

For an interesting discussion of identity provider business models, privacy, and user centric identity, please check out the transcript of an interview of Bob Blakley did with Dave Witzel of Forum One Communications. He was also interviewed for the inaugural Bandit podcast. Check it out!

Freakonomics of OpenID

Blogger: Mike Neuenschwander

Melissa Lafsky, editor of freakonomics.com, recently posted on the debate, mystery, and hype surrounding OpenID. Refreshingly, she’s not buying in to any side of the debate; she simply wants to know whether OpenID can do anything useful, namely aid in the war on identity theft. Bob Blakely posed the question in a more general sense when he asked proponents of the technology “what is OpenID for?”

As Melissa points out, there’s plenty of debate over the technical merits and business models for OpenID. For those of you that want to dive in to the minutia of it all, I recommend starting with this post from Stefan Brands and this response from David Recordon. And never one to miss an opportunity to market my own musings, I highly recommend checking out my posts here and here.

But technical issues aside, I think it’s more important for people to understand a few concepts about what OpenID actually is, since it’s not immediately obvious. For one thing, although the name is catchy, OpenID isn’t an ID. Also, it’s not necessarily a single sign-on (SSO) protocol. OpenID is a protocol for “proving” control of an Internet address. The idea is that you log into something you control on the Internet; then using OpenID you can provide evidence to others that you have a verified relationship with the thing you logged into. The following example should clarify how this works:

OpenID-Inspired Bridge Buying

• Imagine your telephone rings and you answer “hello, who’s this?”

• A voice on the other end says “I own a bridge and I would like to sell you that bridge”;

• You say “Interesting. But who are you?”

• The caller responds “I’m the bridge owner; I’m going to pass you to someone who will verify that I own the bridge.”

• You hear some Muzak and a couple of weird clicking noises; you notice the Caller ID on your phone says “ACME bridge verification.” Then another voice answers the phone and you say “who is this?”

• You hear a voice that says, “I’m the Acme bridge ownership verification service; the guy you just talked to in fact owns that bridge. Thank you for your time.”

So the question is, under what context would you take such a deal? If you knew the caller also owned the ACME bridge owner verification service you would justifiably be suspicious. But if you already had a good relationship with the verification service, it might be a pretty good thing.

Currently, OpenID doesn’t include a mechanism for setting up a suitable context for most purposes (bridge buying or otherwise). Sure, we can invent one. But remember that really smart people have worked on trust problems for years. Things get much trickier once you start adding trust; in fact the protocol starts to look a lot like the also-rans that preceded OpenID.

What is OpenID for?

Blogger: Bob Blakley

There’s been a bit of a dust-up over OpenID recently in the blogosphere.  First Eugene and Vlad Tsyrklevitch published a paper at BlackHat 2007 outlining a bunch of weaknesses in OpenID.  Then Stefan Brands amplified the critique in a long blog post.  David Recordon fired back in a post of his own, in which he expresses confidence that OpenID 2.0 will fix all of OpenID’s problems.  I have less confidence than David, but I’ll leave that topic for later.  What I’d like to do first is talk about getting the horse before the cart.

What I’d really like to see, as a security guy, is a problem statement and a risk analysis.  Specifically, before we start arguing about whether OpenID 2.0 is the answer, I’d like to know the following things about the question:

1. What are the assets to be protected?

What do OpenID’s designers intend it to be used to protect?  Blog comment lists?  Blog entries?  Persistent consumer accounts on commercial servers?  Persistent employee accounts on corporate servers?

2. What are the services to be offered?

What services do OpenID’s designers intend it to offer?  Authentication of users as the legitimate possessors of OpenID URLs?  Linkage of OpenID URLs to user accounts on web-facing systems?  Linkage of OpenID URLs to user attribute information (e.g. Information Cards)?

3. What quality of protection is claimed for these services?

Is the OpenID protocol intended to protect against phishing?  Is it intended to protect against man-in-the-middle attacks?  Is it intended to protect against attempts by one OpenID party to induce another party to execute malicious code?  Is it intended to protect against session-splicing or session hijacking?  Is it intended to protect against active or passive wiretapping?

4. What is the threat model?

What threats is OpenID designed to protect against?  Accidental failures at a participating party?  Malicious behavior by users?  Malicious behavior by relying parties?  Malicious behavior by OpenID providers?  Wiretappers?  Hackers attempting to penetrate a relying party?  Hackers attempting to penetrate a provider?  Hackers attempting to penetrate a client system?  Cryptanalysts?

5. What is the trust model?

Who trusts whom to do what?  Does the user trust the OpenID provider to actually check his password?  Does the provider trust the relying party not to send maliciously constructed OpenID URL strings?  Does the relying party trust the provider not to reissue OpenID URLs to different parties at different times?  Does the relying party trust any particular OpenID provider to issue OpenID URL strings in a particular part of the namespace (e.g. “.gov”?) 

All the arguments about OpenID are entertaining, but the claims and counterclaims are very difficult to evaluate in the absence of a coherent problem statement which includes answers to questions like these.  The OpenID 2.0 Specification signally fails to address these issues; in this sense it’s a solution looking for a problem.

Some Predicted OpenID Weaknesses

Blogger: Bob Blakley

At Catalyst North America in San Francisco, I noted in my “New-School Identity Systems” talk that OpenID does not define the relationship between usernames and the names of the OpenID servers which authenticate the owners of those usernames.  I went on to predict that this would cause security problems.

A number of participants came up to me after the presentation and assured me that I was wrong, and that the lack of a defined set of trust anchor names and a defined set of rules for which portions of the user namespace each trust anchor was responsible for doesn’t create security issues with OpenID.

They were wrong and I was right; Eugene and Vlad Tsyrklevitch give details of the attacks I predicted in this paper from Black Hat 2007.  Their “Step 2” and “Step 4” attacks are precisely the sorts of things I’ve been expecting to see.  Thanks to Pamela Dingle for pointing me to the text of the paper, which I’d heard of but not seen until this morning.  There’s an accompanying presentation here.

Meta Madness

Blogger: Bob Blakley

Paul Madsen, commenting on my recent post regarding the Catalyst user-centric identity interop, argues that the event didn’t demonstrate the existence of a metasystem.  Robin Wilton agrees with him, as does Gerald Buechelt, who adds his criterion for what would constitute a metasystem:

“Even though there have been a number of different products and projects that successfully worked together, this technology is a far cry from being an identity meta-system. Multiple-protocol interop on the wire would be a true metasystem, and is a goal that various systems -- Liberty, OpenID, and Windows CardSpace included -- would need to work on together. Concordia is (probably more than) a first step towards this goal.”

Even if it were true that there was only one protocol demonstrated on the wire at the Catalyst interop event (which it is not; for example, a variety of different protocols were used to authenticate Identity Selectors to IDPs), I reject the assertion that you can’t have a metasystem without protocol diversity.

It was not a longing for different bitstreams on the wire which gave rise to the desire for an identity metasystem – it was a real honest-to-God human need: “I want to be able to visit different sites without having to create a new account at every site, and I want to do this in a way which doesn’t involve publishing everything about myself to everybody in the world”.

Meeting this need required the identity community to invent at least one set of protocols which enabled different identity systems (not “protocols”) to work together to allow users to carry their identity information around with them.

The fact that it ties multiple systems together is why it’s called a meta-system.  Notice that it’s not called a “meta-protocol”.

At the Catalyst interop event we saw users exporting managed cards from different Identity Provider systems into the same Identity Selector system.  We saw users using cards from the same Identity Provider system with different Relying Party systems.   We saw users authenticating to different Identity Provider Systems with the same (OpenID) credential.  We saw several configurations of these components working together with no Microsoft CardSpace components involved at all.

If the Liberty community and the WS-* community want to keep arguing with one another about whose protocols need to be in the mix before we call that mix a metasystem, I suppose there’s nothing that can stop them from doing that.  But the argument doesn’t help actual people or actual businesses get any interesting work done.

The participants in the Catalyst interop did help actual people and actual businesses get interesting work done.  That’s why OSIS is organizing more interops in the future; bringing Liberty-compliant components to these events and working with the other participants to make them interoperate with everyone else’s technologies would be much more useful than whining about how many protocols must dance on the head of a pin before we’re allowed to call it a meta-pin.

Incidentally, as both Gerald and Jeff Bohren note, the Catalyst interop was the second such event OSIS has organized.  I mentioned the first – held at IIW 2007a – in my initial posting.  I participated in the IIW inteorp and did not summarize it here only because Dale Olds has already posted an extensive and excellent writeup of the event.

Braying About Sun’s OpenID Support

When I read the first few lines of Sun’s press release announcement support of OpenID, I almost quit reading because it seemed un-newsworthy. And for you PR folks writing press releases, here’s the kind of stuff that triggers my “so what” response: “Through its new initiative, Sun is exploring what changes and practices are needed to make OpenID applicable to a broader spectrum of business and IT challenges.” Alert the media!

But Sun’s use of OpenID as an outward-facing registry of their workforce is an interesting move. Few businesses will trust just any old OpenID provider; rather, businesses will likely accept only OpenIDs (if any) from a provider on a whitelist. By tying a corporate identity to an OpenID, the relying party can improve the assurance of the issuer and make inferences however they may.

OK, still not huge news, but Sun’s initiative has incited the right kind of dialogue among OpenID enthusiasts. Tim Bray blogged on Sun’s forthcoming OpenID provider, which reinvigorated the identity gang mailing list. I’m convinced that the actual solution won’t be nearly as rosy as Tim portrays it. I’m not sure, for example, just how confident you can be that someone holding one of these OpenID’s is really a Sun employee (or just a contractor or former executive). But in my view, Sun’s pushing OpenID in the right direction.

In fact, I’d like to see these ideas taken much further. The Diffie-Hellman qualities of OpenID can be put to much better use than the SSO use cases so often cited. It’s as if the OpenID community serendipitously stumbled onto something that is of great value and has yet to realize it. I alluded to this in a previous post. Although  the name “OpenID” is catchy, it’d be better if we didn’t think of OpenID’s as IDs; and it’d be better not to think of the URIs associated with OpenIDs as usernames. And it would be great if people could have a dozen or so of these things at their disposal.

I recently published a report at Burton Group called, “In Search of the Internet Identity System: Contrasting the Federation Approaches of SAML, WS-Trust, and OpenID,” in which I proposed an alternative use of OpenID. Here’s an excerpt:

OpenID Is for Showoffs

Although its proponents tout SSO as the most important feature of OpenID, the standard can be put to better use. The proofs in OpenID allow for a certain kind of interaction that is of great value on the Internet. Roughly, OpenID enables a person to demonstrate control over a given web property to a stranger (who understands OpenID). It’s a web version of showing someone you own a car by hitting the “unlock” button on your key fob. Although this might seem a high-tech form of showing off, it can also be used in reputation systems. For example, a user may demonstrate control over a dozen popular websites to gain access to an exclusive site. The user may also demonstrate ownership of a particular reputation (on eBay, for example).

OpenID not only demonstrates a relationship, but to a degree, projects the status of a relationship, because the demonstration is dynamic (not based on historical certification). Once a user can demonstrate control over a resource (such as reputation), the user can then offer it as collateral in forming a new relationship. Accordingly, in the hands of astute architects, OpenID may be used to reduce risk in relationships. (For more information, see the post “Law of Relational Risk” on the Burton Group Identity and Privacy Strategies blog.)

In short, OpenID may be a convenient, scalable way to project high quality signals to perfect strangers. (For background on the topic of signaling, have a look at the work of Judith Donath). Using OpenID in this way may also satisfy the need for multi-factor identity that I pointed out in my post on the law of relational risk:

… single sign-on (SSO) efforts are often misguided. In the interest of promoting relational continuity, the more authenticated connections the better—particularly if the user can parlay these authentications into improved reputation. Recognition of participants based on multiple channels of connectivity would be the method for improving identity assurance rather than on a single login event.

To me, these are important elements for creating functional online relations and societies. At Catalyst, we’ll be proposing other pieces of a technical architecture to support relational and social processes important to social trust. So if you have any thoughts on the subject, please drop a comment on this post!

[posted by Mike Neuenschwander]