Catch you on the flip side later - improving the federated user experience
My colleague, David Orrell, gave a presentation to the JISC Federated Access: Future Directions day in Birmingham earlier this week. Here are his slides:
David's presentation covered the user experience of both federated and user-centric approaches to identity management (i.e. the UK Access Management Federation and OpenID), the associated trust issues, and the potential impact that Information Cards might have on this space.
This blog entry focuses primarily on the first of these - the potential lack of consistency of the user experience in federated identity management environments such as that offered by the UK Access Management Federation. There are two aspects to this: firstly the different experiences that different users see of the same service (by virtue of the fact that the authentication part of that experience is offered by their home institution rather than by the service itself) and secondly the different experiences that the same user sees of different services within the federation.
By way of example, let's consider two users, Janet and John (each from different universities, let's say Bath and Bristol) and two services, Service A and Service B.
When Janet and John access Service A they will each have a slightly different experience because the authentication part of the process will be provided by Bath in one case and Bristol in the other. That makes it difficult for Service A to completely document its interface because at some point it will have to resort to saying something like: "you will then be re-directed to your institutional login page, we'll catch you on the flip side once you've been authenticated".
Conversely, when Janet (or John) accesses Service A followed by Service B she (or he) will have a different user experience of each in terms of how she (or he) is authenticated because the two services will probably present the login form differently and at a different place on the page, one may point to the federation WAYF service while the other embeds a pull-down list of universities, they may use different language to describe what is happening, and so on.
Don't believe me? Just look down the list of UK Access Management Federation services and try it for yourself. David has put some images of the way in which different services in the UK Federation present the login process to their users on slide 26 of his presentation but it is a little hard to read in the Slideshare version (above) so I'm embedding a bigger version here (click on the image to see it full size).
Look at the differing forms of language being used - "Shibboleth" vs. "UK Federation" vs. "institutional" vs. "organisational" login. Look at the differing ways of selecting the user's home institution - "search" vs. "pull-down list" vs. "multiple pull-down lists" vs. ...
The point here is not to suggest that any one of these approaches is better or worse than the others (though I happen to think that putting form boxes labelled "User Name" and "Password" next to text saying "Athens/Other Institution Login" when in fact the username/password pair being requested is the service-specific (i.e. non-federated) one, as one service has done, doesn't exactly represent best-practice and is presumably resulting in large numbers of institutional username/password pairs being seen by the service in question!). Rather, the point is that there is currently a very wide range of practice out there across UK Federation service providers (including that adopted by Eduserv in our own services), ultimately leading to confusion for the end-user.
Now... inconsistency of experience isn't bad just because it confuses people - though of course that is a very real problem. Inconsistency also represents an opportunity for phishing to take place because users have less of a handle on what step comes next in the authentication process. We probably haven't seen any phishing taking place in the context of the UK Federation to date, and maybe the controlled nature of the environment means that we won't. But it is certainly something to beware of - and certainly something that has troubled the rather more open environment within which OpenID has to operate.
Lack of consistency also represents a significant (and in the case of the UK Federation probably insurmountable) hurdle to overcome for browser-based plug-ins that might otherwise help smooth the federated authentication process.
Consider a tool like Sxipper, a Firefox plug-in that manages your usernames and passwords for you (including your OpenIDs) and that can recognise when and where to present them to services as part of their Web registration and/or login pages. Sxipper works because, despite some superficial differences across services, most logins revolve around two text boxes and a submit button (though actually, Sxipper can deal with much more than this). Furthermore, in the case of OpenID at least, there are well-adopted conventions for how these XHTML form items should be named. Heck... in most cases, even in the absence of a tool like Sxipper, the browser will do a pretty good job of remembering what needs to go where.
Contrast this with services in the UK Federation. The lack of consistency in the way information is presented and requested and the widespread use of drop-down lists to navigate to the user's home institution means that browsers and plug-ins like Sxipper stand very little (probably zero) chance of helping to smooth the process.
We can and should do better. In the short term I think we need the help of some usability designers to streamline the UK Federation user experience and to issue guidelines for service providers so that a more coherent and consistent experience is offered overall. And in the longer term... well, readers of this blog will know that I have views on institutional vs. user-centric approaches to identity management. But setting those views to one side for the moment, I suspect we are still not mainstream enough in our approaches to access and identity management. For example, can anyone point to a single mainstream Web 2.0 service that has adopted Shibboleth? The move from Athens to Shibboleth has been a step in the right direction for the UK education community (at least in my opinion) since it represents a move to open standards. But does it go far enough? Shibboleth still feels like a community-specific solution to me. Whilst I accept that the community is now significantly bigger than was the case with Athens and that the solution is based on open standards I think we will only see real community benefits (in terms of the widespread adoption and development of tools and services) if we become part of a much bigger community - a truly global community.
I think it will be interesting to see what comes of the information card work, and in particular whether the ability to embed our identity management toolkits more firmly into the desktop improves the user experience whilst stengthening security and thus improving trust models. I certainly hope so...