After reading Simon Willison ’s excellent article on the topic I spent a couple hours last night looking at the current OpenID specification, and after a fair bit of thought found the ideas behind OpenID clever, but not what’s needed for the ID of the future.
What’s Right
OpenID has some really good ideas behind it. Here are a few that really stand out in my eyes.
- If you have a LiveJournal account for example, it just works, no extra sign-up, no additional work.
- The ID is easy to remember, a persons blog / home page URL is among the easiest things for a user to remember.
- De-centralized architecture that minimizes the potential for downtime.
- Anyone can operate an Identity Provider.
- Open, well documented protocol, as well as open-source libraries.
- ID may be portable from one Identity Provider to another without changes to the ID.
What’s Wrong
There are a number of issues I see with this system, while there are certain advantages; some of these disadvantages are quite disturbing. Here are the issues that strike me as most concerning (in no real order).
- SSL (HTTPS) is not required for any communications. This is a potential security issues, though not as large as could be due to the nature of the system.
- Requires editing HTML for users that do not use a hosting service that automatically adds the OpenID HTML code to the proper page(s).
- Not all hosting services allow the user to edit HTML directly.
- Does not offer a way to communicate enough information, such as would be used to expedite an e-commerce transaction. (This may be changed in future versions, or with extensions.)
- No trust relationships, only verifies a person controls a URL.
- No certification or audits for Identity Providers to ensure end-user security.
- Excessive bandwidth usage. Each login requires parsing at least one full HTML page to identify the Identity Provider server. If a user has
openid.delegateincluded in their page, there will be another full page download/parse for each. - HTML pages must be parsed to identify the Identity Provider server, parsing HTML can raise issues when it contains errors (as is quite common). Seeing as there is no standard library to perform the parsing, HTML with errors may work with some implementations but not with others.
- Anyone that gains access to edit the HTML of the identity URL can steal ones identity just by changing/adding an
openid.delegate. This is a real risk in some shared hosting environments.
What We Need
The idea behind OpenID, to create a distributed identity system that is easy to use and can be used universally is a great idea, and one that should be pursued. If this goal could be achieved, it would be a project that would truly help to make the world a better place (at least it in that it would save everybody time). I have great respect for the work of all that have contributed to the OpenID project; it is a great idea and certainly has uses.
To be truly useful though, an ID system needs to be easy to use for people of all skill levels, with and without web sites. It should provide an option to control how much information is shared with a web site (such as OpenID does), and should have the option to provide information such as shipping or billing information to minimize entering the same data in so many web sites. All the data should be transferred via SSL to ensure the highest level of security.
Features of The Future ID
- The protocol should be completely open and well documented.
- The protocol should be XML based so as to be lightweight and easily implemented in any language.
- The ID should be easily used with not only web sites, but via desktop applications and other forms of software that require authentication.
- The organization backing the identity system should arrange for an optional certification program for Identity Providers to ensure that certain basic security policies are implemented. The requirements should be defined by the backing organization and the audit carried out by a third-party auditing firm.
- The IDs should be in an easy to remember format that is easy to type and makes translation back to the provider simple.
- Identity Provides should offer a way to verify that a user is who they claim, not just that they control an ID. This would be an option for users that would be quite useful in applications such as e-commerce use. (This would rely on the provider having a trusted signing certificate and following certain identity verification guidelines.)
While some of these features cover far more ground than something like OpenID, this increased scope is needed to ensure that the ID service can be used in all the needed applications. While it is far more complex to add these extra features, the ability to use the resulting ID for almost any purpose makes it well worth it.
I’m not proposing an alternative to OpenID, simply seeking feedback while passing my feedback on OpenID along for those interested.
“The protocol should be XML based so as to be lightweight and easily implemented in any language.”
Since when is XML lightweight?
December 22, 2006, 3:02 am
Well, relatively speaking that is. When compared to grabbing and parsing an HTML file, dealing with XML can be a lot more efficient.
If you have a separate file that’s just for that, or a fairly trim home page; then it won’t be so bad. But if you’ve got 100KB+ of HTML on your homepage, that’ll start adding up after awhile.
I know XML can be verbose and bulky, but when compared to the full HTML of somebody’s home page, XML sounds a lot better.
December 22, 2006, 3:35 am
You don’t necessarily have to pull back the entire homepage to scan for the OpenID headers. They have to occur in the head section - so you can start reading the HTML, but terminate the connection as soon as you find them, or as soon as you see a or a or some other indication that you probably won’t find anything related to OpenID.
There’s also XRDS, which some OpenID providers (myopenid.com for example) support. This can be indicated in the HTTP headers using X-XRDS-Location, which means you don’t have to pull anything back past the headers so you don’t need to suck in any HTML at all.
December 22, 2006, 5:46 am
My angle brackets got stripped; that last comment should have said “or as soon as you see a [/head] or a [body] or…”
December 22, 2006, 5:46 am
Thanks for your thoughtful look at OpenID. We acknowledge OpenID as a starting platform, so one question is, how many of the qualities of this “Future ID” can OpenID grow in to? Just going down your features list here:
It’s already open and documented,
it’s designed by people who think XML is heavyweight (and I’d say there are standard libraries; see http://openidenabled.com/ ).
It’s possible for someone to establish an “optional certification program for identity providers”,
if you can come up with a system of globally unique identifiers that’s easier to remember than URLs or i-names, we’d love to hear about it.
and yes, there are some cases regarding trusted third-party assertions (i.e. your deceptively simple phrase “a user is who they claim”) that we’d all love to see too, but I think those are another layer.
I think the requirement that OpenID may have the hardest time meeting is the one for desktop apps. It’s possible, given the ubiquity of browser elements on desktops, and I’m sure someone will do it, but… it’s likely to be rather inelegant.
oh, and while I can’t argue the fact that a single OpenID authentication involves a number of HTTP requests, the presence of “openid.delegate” does not add an additional one. (that’s just a token that’s passed through to the server.)
December 22, 2006, 4:28 pm
@Simon - Excellent points.
While some of the more simplistic implementations would just pull back the full HTML then parse that; a better way would be to parse as you go. Yeah, for an implementation where bandwidth is a concern, that makes a lot of sense.
Thanks for pointing out XRDS, I hadn’t heard about that, I’ll have to read up on it.
@Kevin,
OpenID sounds like a promising technology, and for any technology to reach its full potential; any and all possible flaws need a close look. My goal was to get people talking about some of these possible issues, see what people thought.
If nothing else, people are talking so that goal is achieved.
In looking at your comments, I realize that I raised a number of issues with no suggestion for how to do it better. In the future I’ll try to provide at least somewhat useful suggestions for a solution.
As to my comment about the standard libraries, my thought more than anything was about ensuring that the user experience is consistent. Having an ID work some places but not others due to bad HTML will confuse the user and give the user a negative experience at those sites that are more strict about parsing. While this is a minor issue, it is worth keeping in mind. As I’m not really a part of the OpenID community, I can’t know if the libraries available are considered the ’standard’ libraries, and if so this point may be moot.
As to a system of globally unique identifiers, I don’t know if there could be a better way. Perhaps the URL system used now is the easiest to remember, and most effective available. The problem is finding something easy, yet something that could retain the flexibility you have now. I will of course give that more thought (along with more thought to many aspects of OpenID), but for now I have no suggestions as to what might be better.
As to trusted third-party assertions, while I believe this would make the ID system more attractive for things such as e-commerce use, the more thought I give it, and the more I agree with the idea of that being a separate layer. Perhaps just a field defined for the purpose then left to the Identity Provider to use or not as they see fit?
Getting the ID system working with desktop applications I think could add real value, though most likely only for a fairly small subset of users. It would be a ‘nice to have’ but in the grand scheme of things, not that important.
On the use of ‘openid.delegate’ - my apologies for misstating that. I must have read the specification wrong. I stand corrected.
@All, thanks for taking the time to read this, and give it the thought you all have. OpenID seems to be deceptively simple, while it’s a fairly simple system, there does seems to be more going on than first meets the eye.
Some of the issues I pointed out now seem to have a smaller impact than I once thought, though there are still a few issues (such as the potential for confusing novice users) that I think should be addressed. All in all though, I hope that this has sparked some consideration on how to make OpenID (and any systems like it) better.
December 22, 2006, 8:30 pm
Adam,
I have a similar line of thinking to you; at the moment the OpenID just doesn’t seem to fit. I mentioned it on Simon’s site and I still think its a valid point; especially the comment about Hotmail/Live/Yahoo, what were your thoughts on that point?
Al.
January 6, 2007, 12:35 am
Alistair,
I would have to agree. To achieve something at the scale of a single sign on you would have to get players such as MS and Yahoo involved. Otherwise all you are going to do is add another ID for users to forget.
I think the concept has real potential, an open, easier to use ID system is a great idea. Though I can’t see the current OpenID model being a system that will really change anything.
People are willing to give their information to these large companies, people (end-users) don’t know or care about things like DoS attacks. End users just care about trying to remember as few IDs as possible.
The best idea I can come up with is make the ID system a two tier system. The first would be a database of IDs and the provider they map to, then there would be the provider itself. So you would loose the ability to make it completely distributed, but you could make the process much simpler for everybody.
A simple scenario would look like this: User types in their ID, ID is resolved to the identity provider and the user is redirected to a page on the providers web site with the ID passed in, the user types in their password (or whatever method the provider uses), then the user is directed back to the original site passing some form of token that can be used to get the result of the login.
Something like that wouldn’t be hard to stitch into existing systems and would give a single authority to ensure that the system is secure and is working as designed.
January 6, 2007, 4:15 pm