Tim Bray has an excellent post entitled OpenID which attempts to separate hype from fact when it comes to the technorati's newest darling, OpenID. He writes
The buzz around OpenID is becoming impossible to ignore. If you don't know why, check out How To Use OpenID, a screencast by Simon Willison. As it's used now (unless I'm missing something) OpenID seems pretty useless, but with only a little work (unless I'm missing something) it could be very useful indeed. Problem: TLS · The first problem is that OpenID doesn't require the use of TLS (what's behind URIs that begin with https:)....Problem: What's It Mean? · Another problem with OpenID is that, well, having one doesn't mean very much; just that you can verify that some server somewhere says it believes that the person operating the browser owns that ID....Problem: Phishing · This is going to be a problem, but I don't think it's fair to hang it on OpenID, because it's going to be equally a problem with any browser-based authentication. Since browser-based authentication is What The People Want, we're just going to have to fight through this with a combination of browser engineering and (more important) educating the general public...The Real Problem · Of course, out there in the enterprise space where most of Sun's customers live, they think about identity problems at an entirely different level. Single-sign-on seems like a little and not terribly interesting piece of the problem. They lose sleep at night over "Attribute Exchange";once you have an identity, who is allowed to hold what pieces of information about you, and what are the right protocols by which they may be requested, authorized, and delivered? The technology is tough, but the policy issues are mind-boggling. So at the moment I suspect that OpenID isn't that interesting to those people.
The buzz around OpenID is becoming impossible to ignore. If you don't know why, check out How To Use OpenID, a screencast by Simon Willison. As it's used now (unless I'm missing something) OpenID seems pretty useless, but with only a little work (unless I'm missing something) it could be very useful indeed.
https:
I've been thinking about OpenID from the context of authorization and sharing across multiple social networks. Until recently I worked on the authorization platform for a lot of MSN Windows Live properites (i.e. the platform that enables setting permissions on who can view your Windows Live Space, MSN Calendar, or Friends list from Windows Live Messenger). One of the problems I see us facing in the future is lack of interoperability across multiple social networks. This is a problem when your users have created their friend lists (i.e. virtual address books) on sites like Facebook, Flickr or MySpace. One of the things you notice about these services is that they all allow you to set permissions on who can view your profile or content.More importantly, if your profile/content is non-public then they all require that the people who can view your profile must have an account with their service. We do the same thing across Windows Live so it isn't a knock on them.
What I find interesting is this; what if on Flickr I could add http://mike.spaces.live.com as a contact then give Mike Torres permission to view my photos without him having to get a Yahoo! account? Sounds interesting doesn't it? Now let's go back to the issues with OpenID raised by Tim Bray.
The first thing to do is to make sure we all have the same general understanding of how OpenID works. It's basically the same model as Microsoft Passport Windows Live ID, Google Account Authentication for Web-Based Applications and Yahoo! Browser Based Authentication. A website redirects you to your identity provider, you authenticate yourself (i.e. login) on your identity providers site and then are redirected back to the referring site along with your authentication ticket. The ticket contains some information about you that can be used to uniquely identify you as well as some user data that may be of interest to the referring site (e.g. username). Now we have a high level understanding of how it all works, we can talk about Tim Bray's criticisms.
TLS/SSL On the surface it makes sense that identity providers should use SSL when you login to your account after being redirected there by a service that supports OpenID. However as papers like TrustBar: Protecting (even Naïve) Web Users from Spoofing and Phishing Attacks, SSL/TLS does little to prevent the real security problems on the Web today, namely Web page spoofing (i.e. Phishing) and the large amount of malware on user PCs which could be running key loggers. This isn't to say that using SSL/TLS isn't important, just that it's like putting bars on your windows and leaving the front door open. Thus I can understand why it isn't currently required that identity providers support SSL/TLS. However a little security is better than no security at all.
What Does It Mean?I agree with Tim Bray that since OpenID is completely decentralized, websites that support it will likely end up creating whitelists of sites they want to talk to otherwise they risk their systems being polluted by malicious or inconsiderate OpenID providers. See Tim Bray's example of creating http://www.tbray.org/silly-id/ which when queried about any OpenID beginning with that URI instantly provides a positive response without authenticating the user. This allows multiple people to claim http://www.tbray.org/silly-id/BillGates for example. Although this may be valid if one was creating the OpenID version of BugMeNot, it is mostly a nuisance to service providers that want to accept OpenID.
http://www.tbray.org/silly-id/
http://www.tbray.org/silly-id/BillGates
PhishingUsing susceptibility to phishing as an argument not to use OpenID seems like shutting the barn door when the horse has already bolted. The problem is that security conscious folks don't want users getting used to the idea of providing their username and password for one service whenever prompted by another service. After all, the main lesson we've been trying to teach users about preventing phishing is to only enter their username and password to their primary sites when they type them in themselves not when they follow links. OpenID runs counter to this teaching. However the problem with that teaching is that users are already used to doing this several times a day. Here are three situations from this morning where I've been asked to enter my username and password from one site on another
Given the proliferation of this technique in various contexts on the Web today, it seems partisan to single out OpenID as having problems with phishing. If anything, THE WEB has a problem with phishing which needs to be solved by the browser vendors and the W3C who got us in this mess in the first place.
Attribute ExchangeThis usually goes hand in hand with any sort of decentralized/federated identity play. So let's say I can now use my Windows Live ID to login to Flickr. What information should Flickr be able to find out about me from talking to Windows Live besides my username? Should I be able to control that or should it be something that Flickr and Windows Live agree on as part of their policies? How is the user educated that the information they entered in one context (i.e. in Windows Live) may be used in a totally different context on another site. As Tim Bray mentioned in his post, this is less of a technology issue and more a policy thing that will likely differ for enterprises versus "Web 2.0" sites. That said, I'm glad to see that Dick Hardt of Sxip Identity has submitted a proposal for OpenID Attribute Exchange 1.0 which should handle the technology aspect of the problem.
Disclaimer: This is not an endorsement of OpenID by Microsoft or an indication of the future direction of authentication and authorization in Windows Live. This is me brainstorming some ideas in my blog and seeing whether the smart folks in my reader base think these ideas make sense or not.