In this article I continue to publish the results of our usability tests along with recommendations for our software development surrounding OpenID implementation.
This is a simplified workflow chart of a typical OpenID authentication process from a users perspective. The areas marked "A" through to "F" identity usability pitfalls that caught out a vast majority of our testers.
From the top you see [Enter OpenID] which is a form field requesting the users OpenID identifier (typically something like http://tom.calthrop.info
The first time you authenticate from a browser you are asked to login to your RP (your OpenID service provider or "relaying party"). In some cases your session is stored so that you do not have to log in again for a limited time.
The first time you authenticate to a website you enter a trust screen where your profile information is typically displayed. You authorize the transfer of this information back to the website. The typical form has options to "cancel" this authentication, "trust once" or "trust always". If trust always is selected the website is saved and you will no longer be presented with the trust screen when authenticating to this website.
Once complete you are returned to the website as logged in. Typically if this is your first login to the website you will be presented with a registration form that is pre-filled with the information you supplied from the trust screen.
Understanding the pitfalls
We will now go through the process step by step and examine where each pitfall lies. At each stage I make a recommendation on how to avoid the pitfall all of which naturally I recommend built into Prairie
; our Internet identity server if it has not already been done.
The OpenID identifier
See point A in the diagram. We found that around 40% of people at some point (normally after they had not used OpenID for a while) entered their email address as their "identifier". I discuss this in part 1
of this series together with suggestions for prompting the user if an email address is entered.
See points B and D in the diagram. Users expect repartition in process otherwise you introduce points of variation which can lead to points where the user experiences confusion of frustration.
The first point (B) often introduces some other decision point such as a "keep this session alive?" checkbox added to the login form. This adds confusion and misunderstanding.
Recommendation: Only have the username and password field displayed in the login form. Remove any "keep session alive" option or move it to a user account "power options" area in the form of "display keep session alive option at login" which sets a cookie.
Instead of a username ask the user for email and password.
The biggest issue here in terms of confusion is the way the process sometimes takes you to the trust screen and sometimes does not. This appears random to the user as many of them do not understand the underlying process of storing trust.
Trust Once versus trust always
See point D in the diagram. When you authenticate you have the option of saving the fact that you trust this website. This means that in future authentication you skip the trust screen. As noted above this appears random. Add to this that you have to go into some form of account page to unset that trust once continuous trust is given and you uncover a minefield of usability chaos.
Recommendation: Remove trust always and create a trust screen with two buttons; "cancel" and "proceed" on the trust screen which gives the user a clear and simple instruction to follow.
See point D in the diagram. Apart from trust the greatest form of contention is with profile data. The user is more nervous about using OpenID because they see it as giving their identity away which is far more dangerous that giving a website their MSN password. Yes you read that right. Over 50% of testers felt this way. One of the main issues here is that their profile information is displayed to them along with big words like "trust always".
Recommendation: Remove all profile information and extensions from the OpenID authentication process and focus on it being "a simple way to authenticate with a website".
Post authentication process
See point F in the diagram. There are no usability issues with a user completing the process and finding themselves logged in. This is important because it is the main purpose of why we adopted OpenID (to return me authenticated to a website that now sees me as logged in).
When using OpenID to register wit a website many usability issues occurred. All users (100%) did not understand why they had looked at a form containing their profile information (in the trust screen), trusted or approved it only to discover that they are presented with a pre-filled registration form that contains all the same information as what they have just approved.
Recommendation: We move all profile information exchange to OAuth under a different process.
OpenID authentication Summary
If the above is enacted upon we are left with a vastly simplified process that logs a user on quickly using one username (their email address) and one password.
Moving profile exchange to a key based approach
We talk of keys and certificates as technologists, but it just so happens that the vast majority of people who have a computer also have a key that they use everyday to let themselves into their house. Explaining keys to people is easy. Whilst the profile exchange in OpenID is messy a key exchange from an OpenID RP to a website to access RP profile information is easy technically with OAuth and easy to explain to a user from a usability perspective.
Take the scenario that a website wants you to register. It asks you if you want to use your OpenID. You say yes and you are taken to your RP where you are prompted with "website X wants a key to look at your email, your nickname and your mobile number one time. Would you like to login and proceed?". You login then you get a screen where you can choose what to give the website. You press "proceed" and you are returned to the registration form. Behind the scenes OpenID authenticated and OAuth gave the website a use once key. The key was then used to access the profile information and pre-fill the form. This is an important difference in workflow because the website can for instance ask for a key to always look up your email address so that should you change your RP email address this address will be automatically updated by the consumer for the duration of the key lifetime.
Having a process that does this presents other opportunities such as message exchange (a key that allows the website to forward messages to my RP) and commerce (allow Amazon to look up my credit card details) which naturally via my RP places me in command of my keys and thus in a higher degree of command for profile, communications and commerce information.
I recommend that a different process is used for profile exchange and that OpenID is used purely for authentication at login.
Usability notes. Once we removed the skip login and skip trust screens and removed all profile information in Prairie we got a 100% success rate in the number of authentications performed without question, hesitation or confusion.