« This Week's Semantic Web | Main | This Week's Semantic Web »
9 November 2007
Eduserv OpenID Event - London, UK 8th Nov 2007
Posted by Julian Higman at November 9, 2007 07:06 PM
OpenID has been around for some time now, as an attempt to address the proliferation of usernames and passwords that we all have. But so far it doesn't seem to have gained the critical mass or widespread adoption that it needs to be successful. This event presented an opportunity to review the current state of the technology, and to discuss some of the issues facing it.
David Recordon (Six Apart) gave a good overview of how OpenID works. In brief, instead of entering a username and password when logging into a site, you enter your OpenID (looking something like julian.myopenid.com), which has been issued to you by an OpenID provider. When the site sees your OpenID, it redirects you to the providers site, where you log in using your "global" password, after which you're redirected back into the login process of the original website. If you were already logged in to your OpenID provider, then this would happen without you noticing.
That's all fine, and seems to solve the problem of having multiple usernames and passwords. But the flaws start to appear fairly quickly.
For one thing, what's to stop an unscrupulous website from requesting an OpenID login, and then redirecting me to a fake version of my OpenID provider? Once I give my password, the evil website has access to ANY of the sites that I've been using OpenID for. As usual, the main defence is vigilance on my part, to ensure that the URLs involved don't look fishy, but it's hardly water-tight.
For another thing, what happens when you decide to change OpenID provider? (or, given the limited number of ways of making any money from being an OpenID provider, when your current one goes bust). You get another OpenID - say, julian.otheropenid.com - from another provider, but then you have to go to all the websites you use and re-register using your new moniker. There's a way round this, using delegation - I can use an OpenID like julianhigman.com, and at that URI (assuming I have control over the content of that site) I can include some markup that points any OpenID queries to the "real" OpenID provider. Then when I change providers, I just update the delegation info.
But why should a website trust the OpenID provider that I direct them to? In fact, Sean Mehan (UHI) says that he wouldn't trust ANY external OpenID provider, which is why he'll give all students a UHI OpenID and let them use (well, force them to use!) the UHI OpenID server. But that misses the point of OpenID, which is that it relates to me as a person, not me as a member of an institution. And what happens when students with existing OpenIDs - possibly from other higher education institutions - need access to the UHI online services?
Data from public websites - Flickr, for example, or even facebook - is now being included in students work, or in their eportfolios, which means that it needs to be assessed by the institution (and also needs to be retrievanle by the institution even if the external website has gone away). If the institution owns the students' OpenID, then it can simply log on and get it from whatever service it resides in. But it seems unlikely that students will want their online services to be accessible like that by their institution.
And that points up the other issue about having a unified online identity - we actually all have many identities, depending on the context that we happen to be in (we should probably call them "personas" or "personalities", rather than "identities").
In any case, access by one service to data from another (such as Facebook pulling calendar events from your Google account) needs to be controlled at a fine-grained level. As we move into the world of mashups and web services, those are the problems that we really need to solve, in addition to the issues of single sign-on across sites.
Trackback Pings
TrackBack URL for this entry:
http://blogs.talis.com/mt/mt-tb.r280.cgi/1090
