Scott's Workblog

This blog has moved! Go to my new blog!

November 12, 2007

EduServ OpenID event

Last week I attended the EduServ OpenID event in London. You can find the slides (and eventually I think some audio) over on the event website. However I've written below some reflections on the event and its messages for education.

Usability and adoption

OpenID is a new technology, so production uptake in education needs to be carefully balanced, especially concerning usability issues. People aren't used to typing their URL instead of a password. Some of the work on discovering or inferring OpenIDs may help here - David Recordon of Six Apart gave a useful, pragmatic example of a site asking people for their LJ, AOL, or other handles which can be used to identify and then initiate an OpenID exchange, without requiring that people using the service know what an OpenID is.

Also, OpenID isn't going to replace all the other methods for accessing online services. A great (though London-centric) example was given by Gavin Bell: the Oyster smartcard system for London underground sits on top of existing gateways: it literally sits atop the older insert-paper-ticket gate, and the human-operated gate remains to one side. So given that analogy we'll see OpenID logins in parallel with proprietary logins for some time yet.

an Oyster reader at London Underground.

In the meantime, usability may best be improved by addressing the issues at the browser, OS, and device level. An early example of this was by Stephen Downes with "mIDm", which presented the user's URL within the http request's agent string. Initially services such as Sxipper may offer a bridge from browser to an easier OpenID experience. More long-term, CardSpace may provide an effective system for working with OpenID.

Looking further ahead, delegation is a really powerful feature of OpenID, and one that the more savvy users make use of as it makes using an identity provider a mcu more portable experience - you can switch providers just by changing the headers in your web page. However, it involves directly manipulating page source code - will we see tools that allow user's sites and profile pages to have OpenID delegation added more easily?

Technology and security

While OpenID addresses the scenario of the user directly accessing the site from the browser, increasingly users are accessing services indirectly through other sites and rich internet applications (RIAs) via APIs. oAuth needs more careful attention in this area, especially in the RIA field. I'll be taking this up hopefully in my work on the FeedForward project.

There is some differences in views about trust in relation to OpenID. My own assertion is that identity without trust is still useful in its own right (many services require no trust beyond "you aren't a robot"). Some feel that there will tend to be a winnowing out of providers into groups of formal or informal "federations" of whitelisted OpenID providers. I think there will still be a wide set of choices, as here are plenty of cases where we don't need a lot of trust.

Uses in education

OpenID may find its initial value in "gray area" applications, particularly virtual team support, semi-formal learning, induction and "trial-use" engagement in courses.

For institutions offering services, the key questions around each service will be on the basis of trust: for some services a high level of trust is needed (e.g. submission of assignments, mdule transfer), for others little or no trust is a prerequisite (e.g. viewing timetables, browsing lecture notes and course links, taking part in topic discussion areas). So institutions either need to use diffferent identity schemes for different services (and possibly employ some bridging SSO technology) or to have an explicit differential Authz scheme for OpenID users using some sort of whitelist scheme. To give a concrete example:

ServiceOpenID policy
Access course linksAny
Post to course open forumAny with CAPTCHA
Access licensed content downloadsFederation of resource-sharing unis: {openid}, {openid}, {openid}
Create tutor support requestFederation of organisations with support entitlement: {openid}, {openid}
Submit assignment{openid} only

The flexibility of OpenID, in not specifying particular federation or trust strategies, offers some interesting possibilities here. However by allowing greater variety at the identity stage, it pushes for a more sophisticated approach to authorization.

Sean provided a great talk on the plans for UHI to become an OpenID provider, and some ideas as to how and why institutions should adopt OpenID in this way.

The future

There seems to be some consensus that there isn't a clear business case for standalone identity providers such as MyOpenID. However, there is a good case for the provision of OpenID services as a brand extension strategy. Its this angle that makes a better case for education institutions to be OpenID providers, as it offers a fairly simple hook for alumni services and viral marketing. We can also see the use of OpenID as a branding strategy from companies, similar to email addresses in the past. Also, an OpenID provider scheme for institutions can also be used as a way of easily enabling students to make use of external services using the same identity; as with email, it takes a long time for the majority of incoming students to be familiar with a technology, and we'll always have a significant minority which will need advice from institutions in setting up their Internet services.

One area that wasn't explored much was that of OpenIDs for other kinds of agents - this is the inverse of the multiple-identities characteristic. Should we also have OpenIDs for families, lovers, teams, networks, squads, projects, businesses? I can't see any reason why not. Likewise I think OpenIDs for "robots" that represent an organisation should be considered. In many cases services will want to use CAPTCHA (such as BotBouncer), but in other cases if an OpenID identifies an agent representing an entity of some value to the relying party then it should be able to make use of those services.

Finally, a big thanks to Andy and Ed and the rest of the EduServ team for a very useful event, and for inviting me to talk!

Photo credit: tompagenet (BY-SA 2.0).

main archive