The blogged wandering of Robert W. Anderson
The other day, I wrote How many OpenIDs do I need? The premise was that the Identity Community needs to help educate users on the choices surrounding the use of OpenIDs. Having bought into the hype of OpenID I have since:
- Read various critiques and articles supporting OpenID.
- Added OpenID comments to this blog.
- Got an i-name, =rwa, to act as my public OpenID.
- Began tracking OpenID on Twitter.
- Participated in discussions about OpenID in financial services.
- Tried to Demand OpenID, only to find my OpenID verification failed : (
All together, I’ve come to a few conclusions.
Users assume OpenID has a trust layer
Track OpenID on Twitter and you’ll see what I mean. Here is one example:
- (leighhouse): Bill: OpenID also insures you’re not a machine / spam, creates acess #iCitizen
- me: @Leighhouse: openid does not prove you are not a robot. Anyone can create a Provider that accepts arbitrary IDs.
- (leighhouse): @rwandering Can if authenticated? Can eventually? Or Can’t period.
- me: @leighhouse: it depends on the Provider. Services need to evaluate trust of Providers (which is already too hard).
- (leighhouse): @rwandering Can if authenticated? Can eventually? Or Can’t period.
- me: @leighhouse: you are asking the wrong question. OpenID is only authentication piece, trust of IPs is a bigger question outside of tech OpenID standards.
OpenID is intended to provide identity, but without trust. Search around the Internet and you will find an OpenID Identity Provider (OP) that takes this to the extreme: it accepts arbitrary URLs with no authentication at all. It reports “trusted” to anyone who asks. Granted, this OP exists to demonstrate a point, a kind of “white hat” OpenID hack, but it leads into my next point.
Relying Parties don’t have any reasonable way of determining trust levels for Providers
Some OpenIDs can be trusted (e.g., Google, Yahoo, myopenid, etc.), others cannot. I want to be clear that I’m only talking about trusting Google (or some other Big-Co) as an OP. That means that they manage user authentication in a reasonably secure way. I am not talking about trust outside of that relationship, or even if it makes sense to trust Google as the center of your identity.
So some can’t be trusted. In addition to the example OP above, what about the numerous self-hosted OPs that are springing up?
How is a Relying Party to distinguish between all these different OPs?
It appears the OpenID authors intended to delegate this issue to a 3rd party (e.g., VeriSign or perhaps a community-based foundation).
Fair enough, but how are services to deal with this issue today? I don’t think they have a reasonable way to do it, except to maintain their own list of trusted OPs. But that is a brittle system to say the least.
On top of this, there are many technical issues that are being raised about OpenID. These range from security issues to privacy issues and much more. A good round up can be found here: The problem(s) with OpenID. Some of these issues are at the heart of why users shouldn’t want one ID on the Internet.
OpenID isn’t ready for prime time
OpenID shows a lot of promise and has real value in some current use cases. Google Friend Connect stands out, as do any applications that are built on top of services published by OpenID providers (e.g., if you want to build a service that interacts with WordPress.com, OpenID might make sense).
The OpenID hype is getting way ahead of what the technology can deliver. People are rushing out to get OpenIDs and people are demanding that their services become Relying Parties, but the technology is just not ready for general adoption.
The leaders in the identity community (the Identity Commons?) need to slow this down and get these issues sorted out, otherwise I think OpenID will end up a big failure.
It just isn’t ready for prime time.
Tags: Google, i-names, OpenID, Verisign, Yahoo
[…] OpenID isn’t ready for prime time – Robert W. Anderson There is at least some truth in here, as OpenID is a complex thing that is probably misunderstood by a lot of people that don’t really understand what is means. The advice that we need the experts to educate users on the topic is certainly valid! […]
You raise a good point about user awareness of the trust dynamics of OpenID. OpenID specifically avoids establishing a trust hierarchy in its own right. Like PGP in the cryptography arena, OpenID provides the basic bits — the tools — for the process, but leaves the trust relationships that use those tools to be developed by the marketplace. OpenIDs can be verified by service providers that provide extraordinarily high-intensity authentication, right down to biometric verification of the users, in addition to employment checks, credit card and credit bureau checks, and even in-person verification of government-issued IDs. It’s equally possible to spin up an OpenID provider that authenticates any request at all, or any level of authentication between those extremes.
OpenID is the protocol, then, for expressing the request for authentication from a provider and the results of that request. Web sites that consume OpenIDs must decide on their own which providers they want to trust, and why. You’re quite right that this is an emerging problem, and it’s an area that the company I work for (JanRain) sees an opportunity space to provide a useful service to these sites. As the marketplace develops, web sites will be able to make “OpenID provider trust” a service call they can make as well. When an OpenID is presented, if the OpenID provider is not known, a trusted service can be use to ask “Who is this provider? Do they follow the authentication policies I require?” In that way, websites can offload the complexity of vetting new providers by asking a trusted service that manages a database of providers and their attributes and policies.
This will be one of the developments that gets OpenID ready for “primetime”, I agree.
Thanks for your comment. I am a little surprised that you agree with me.
I am concerned that the “Demand OpenID” push is raising demand for OpenIDs without raising awareness about these critical issues. Unfortunately, users are getting the idea that OpenIDs include built-in trust. I don’t tihnk JanRain is telling users this, but I do think that the overall OpenID message and value proposition for users and services should have been worked out before “Demand OpenID”. And since a JanRain employee came up with “Demand OpenID”, it appears that JanRain as a company does think that OpenID is ready for “primetime”.
Of course, maybe this just comes down to a definition of “primetime”. I never meant “mass use”, but general use outside of hardcore techies. The trust issue seems to me to be too big. And too big to wait for the market to work that out.
The bigger issue isn’t that users think OpenIDs confer trust, but that services can’t tell if they can trust an OpenID. The “OpenID provider trust” call should exist today.
I’ve thought of writing my own community-based service. I hope you guys are close to having something like that done.
OpenID, the concept of using a URL as an identifier, is as ready as it’s going to be. Your article brings up awesome ideas for services people should build (many are working on them as we speak, such as reputation systems) now that OpenID is picking up steam. But all of these will go *on top* of OpenID; they are not necessarily part of the OpenID technology.
Aaron, thanks for the comment. I agree that what I’m talking about is outside of OpenID; however, I believe that the community (perhaps the OpenID foundation) should have set a parallel trust layer as a prioirty *before* OpenID started being sold to end users. I think I’m in the minority here, by the way.
Thanks for doing so much research. I’d love to dive into all of this myself, having used OpenIDs for quite awhile.
Let’s say I’m using a “trusted” provider like Verisign. Is it reasonable to assume that everything is perfectly “okay?”
If I’m understanding correctly (and I’m not sure that I am), what you’re saying is that “untrusted” providers, like “Joe’s OpenIDs” could lure unsuspecting users in and cause harm. Am I missing anything? I mainly want to make sure that I’m not leaving myself open for issues if I am using somebody like Verisign (or my own server).
Savvy users are not really the problem I’m concerned about, so the two OpenID providers you mention are probably OK (i.e., Verisign and Shannon Whitley, Identity Provider). There is one particular problem with providers if they use an ID that is non-permanent. For example, if provider example.com issues my an ID like ‘https://openid.example.com/rwandering and I later cancel my account, another user may get that same ID in the future. That means the new rwandering has access to those accounts where I used the ID. I hope Versign isn’t doing that, but I don’t know. Users who are their own providers ought to be sure that they never let their domains expire. This specific problem is resolved by using i-names as long as services correctly use the underlying i-number for logon identification.
I am more concerned about the difficulties for services that want to rely on OpenID (i.e., Relying Parties). How do you, Shannon Whitley, developer of many services, distinguish between a Verisign (which presumably you trust) and “Joe’s OpenIDs” which might just be a self-hosted Provider to facilitate spam and meddlesome bots?
I’m thinking of putting together “Robert’s Most Excellent Identity Provider Provider” which just enumerates (and serves) trust levels for Identity Providers. Maybe you can write that (but you have to use the name I came up with)
I hope this helps,
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>