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.

The recent Future of Web Apps conference provided some food for thought regarding current approaches to building web applications, and how those approaches will change in the future.

Small Pieces..

Matt Biddulph (Dopplr) described the way in which the internet is genuinely becoming a network of “small pieces loosely joined” (from the Dave Weinberger book of the same name). Matts experience building Dopplr around open apis, where lightweight XML descriptions of travel itineraries can be mashed-up with maps (Google apis, kml formats), calendars (iCal), Yahoo pipes etc was interesting. His main point was that you don’t know in advance how people will use your data, but if you build open interfaces, then you’ll allow other developers and users to incorporate your data into wildly different applications. This kind of approach (using fairly ad-hoc combinations of technology – XML, XSLT, lightweight REST web services, microformats etc) seemed to be a lot more popular with the majority of the speakers at the conference than anything quite as structured as a “Semantic Web” (though that probably depends on your definition of “Semantic Web”). The general feeling was that current work-arounds for data inconsistency will get us through, and that any efforts to regularise the structure of data on websites is doomed to failure (mainly because there’s no obvious immediate payback for website owners).

Who Are You?

Of course, there are still some other hurdles in the brave new world of open data. One of them is authentication – Dopplr currently has to jump through various sign-on hoops in order to be able to access some of the feeds they need. Luckily, there are loads of open authentication and access standards to choose from! BBAuth from Yahoo, AuthSub frm Google, Authenticate from flickr, OpenAuth from AOL.. and of course, OpenID. There’s also a new open source development called OAuth, for providing access to data (the official description is that “OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are”..).

The Market Will Tell You Your Business Plan

Elsewhere, there were further calls for openness. Dick Costolo (Feedburner, and now Google) had an interesting take on how startups should approach building new applications. He said that creating an open api to your data allows the market to tell you what your business plan is (rather than starting with preconceived ideas of where the value is in your business or app). His viewpoint is that you should build an extensible architecture for your app, and only then launch a minimal version. Then you can follow up by iterating often to build out the functionality in the app faster than other people could, and continue iterating quickly as the app matures.

Twitter Ye Not

Leisa Reichelt, discussing Ambient Intimacy, described how the stream of open data coming from Facebook, IM, RSS feeds, Skype status, flickr, last.fm. mySpace, Dopplr, Twitter etc. give people and their friends a “continual partial presence” with each other and facilitates “phatic expression” (speech used only for social purposes). And people either love or hate the whole idea. Either way, the notions of community and social contact are changing rapidly.

Into The Valley

Meanwhile, Paul Graham (YCombinator) had some radical ideas to share on the future of web apps – he believes that educational qualifications are probably no longer relevant, and that education right back to secondary school will change as a result. In a world where everyone works in a startup, there’s no point spending time getting grades simply to impress companies for whom you’re not going to work anyway. (He didn’t address the issue of the other segment of the population, who may not work in startup-land). And he also said that you no longer need to raise funding to begin a startup – it’s cheap enough to start the company, get some traction, then point the VCs at Alexa to show how well you’re doing – at which point they’ll give you money. And he claims that you shouldn’t worry about having a business plan when you start out – it will emerge at a later date (sounds like the good old days pre-dotcom crash!). His other suggestion was that you have to be located in Silicon Valley, because only physical presence will allow for the serendipity required to meet and connect with others who can help your business.

And Some Techie Stuff

Throughout the conference, there were plenty of mentions of the technologies which people are using to accelerate the building of web apps – Amazon S3 for storage, memcachced for caching, Dojo and jQuery for Ajax, HyperDB for in-memory databases, Django for Python web frameworks, etc. etc. The overall message was that, if someone has already solved a problem that you have, then you should be using those existing solutions and concentrating instead on building the bit of your application which will add some value to the data you have.