Tag: openid

Hopes and concerns for identity

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.

(Cross-posted from Burton Group’s Identity blog.)

No identifiers, just attributes, uniqueness: Where’s the context?

So Mike Neuenschwander hung a softball out there with his latest post on becoming an OpenID power user. Dave Kearns was quick to take a swing at it with his response to Mike’s summarization: “There are no identifiers, only attributes.”

Mike’s journey to OpenID begins with a single step – getting an OpenID, which is really an exercise in picking a name. Names are important. (I am going to stop myself from going into a discussion of the gravity of names and naming. Literature is soaked in naming issues.) As Mike points out he can pick any unused name (really, any set of unused characters.) The first person in to register ian.glazer.myopenid.com can purport to being Ian Glazer. This is no different than XRI name registration or domain registration or copyright registration… you get the idea.

Dave goes from there and reminds us that identifiers have to be unique within a given namespace. He uses the example of disambiguating family members. He provides one of the most familiar examples on unique identifiers:

Your email address – every single one of them – is a unique identifier within the entire world of the internet.

What is hidden in Dave’s comments is the role of context. Given the context of family, Dave’s non-unique identifier can be disambiguated. We use the domain name in an email address to set context. I know that an email coming from mike@burton is likely to be of a professional nature and an email coming from mike@igotsmesomefreeemail is likely to not be. The context of how you use your identifier is meaningful.

Thinking out loud here… I wonder if the visual metaphors in CardSpace will help set context for both the relying party and end-user. Presenting context in a way that is meaningful to the end user could help solve a few other problems, notably phishing sites.

Is SPML irrelevant in the coming CardSpace/Higgins/OpenID identity world?

I was reading about Conor Cahill’s workshop at RSA on secure provisioning of network credentials over the wire. It was a joint proof of concept between Intel, BT, and HP using Liberty’s ID-WSF Advanced Client. They talked about how to get credentials from service providers down into a client environment. (Although it is not a requirement, clearly Intel would love it if the client environment was a TPM-like object.)

One aspect of all this is a provisioning service, one for which Liberty has cooked up a spec. As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning. The funny thing is, I thought there already was a perfectly good provisioning service standard out there – Service Provisioning Markup Language (SPML).

That got me thinking. Provisioning is an aspect of the identity lifecycle that you don’t really hear about in talks on Higgins and CardSpace and such. This is a bit of history repeating itself. Back in the day, the authentication guys got all the glory, all the publicity, and when it came time to make sure there were actually credentials in back-end services, they waved their hands. It was the lowly user provisioning system, the late-shift janitor of the identity world, that actually had to do the dirty work. Who is this janitor in the user-centric identity world?

Before I go on without a better understanding, I’m looking for comments on this one. Where does SPML fit in this brace new identity world? Is the intention that SPML will be passed as part of a larger SAML assertion to establish credentials? Is the PSTC working on scenarios like this?