Giving people the tools they need to share knowledge and advance open society through social software.

Welcome

We are a network of people that have come together to give you the tools you need to share knowledge and advance open digital society.

RSS

Why 'Barnraiser'?

Barn logoWhen an Amish family needs a new barn their community gathers to build a barn in a single day, a tradition called barn raising. In building a barn together in a day they achieve something that no single family can do.

We share that spirit as we build for society.

  • 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.

    Workflow variation

    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.

    Profile data

    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.



    Summary

    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.
  • I've never been presented to a person who forgot their email address. Quite a claim you may say, but when one presents themselves in business one tends to shake hands and hand over a business card with the email written on it. Next time you are in a meeting ask someone what their OpenID URi is. You'll probably get a blank stare followed by an answer along the lines of "oh, ehm, I only have Skype".

    The email address although geeky looking is now part of our daily lives unlike the OpenID URi, hence the challenge for those of us involved in developing OpenID solutions is to provide helpful usability centric solutions to this challenge. Given that, I challenged myself; can I provide an organisation with a mechanism to authenticate with OpenID but use the employees email address and email password? Here is my approach along with usability notes from testing.


    A typical business email address looks something like this:

    firstname.surname@example.com

    OpenID has a consumer which is the web site that you want to authenticate to. It asks you for your OpenID which is typically a URi that looks something like this:

    firstname.surname.openid_server_example.com

    The first thing to notice is that they look alike to the average employee which gives them a great opportunity to confuse them. There is a far greater chance that they will forget their OpenID URi as it is not ingrained in their minds as with their email address. Instead of forcing them to learn their OpenID we should allow and forgive them for putting in their email address as their OpenID URi.


    Option 1: Allowing email addresses to be entered instead of a Uri

    In the OpenID consumer script we can look for an email address and replace with with an OpenID URi:

    <?php
    $email = "firstname.surname@example.com"; $company_email_server_url = "example.com"; $company_openid_server_url = "openid_server_example.com";
    $pos = strrpos($email, $company_email_server_url); $user = substr($email, 0, $pos-1); $URi = $user . "." .$company_openid_server_url; echo $URi; // will echo firstname.surname.openid_server_example.com
    ?>

    We now had the URi back to the consumer and proceed with authentication as normal.


    Option 2: OpenID assistance

    With option 1 we have sort of shot ourselves in the foot because if your employees don't know that they have OpenID they do not get the full benefit of it (like being able to authenticate to an external website), hence my preferred method is to "guide" your employee in a helpful way.

    Let them type in their email address but check for it:

    <?php
    $email = "firstname.surname@example.com";
    $pos = strrpos($email, "@");
    if ($pos === false) { $URi = $email; } else { $openid = str_replace("@", ".", $email); echo "This looks like an email address. Perhaps your OpenID is " . $openid; // return to form and prefill openid with $openid
    }
    echo $URi;
    ?>

    If you find something that looks like an email address then suggest to them an OpenID URi equivalent.


    Using their email password

    On the OpenID server a form is included for the users password. Upon posting that we have both the URi (firstname.surname.openid_server_example.com) and the password. The password should match that of the users email password.


    Checking username and password using LDAP

    Many companies and organisations use an LDAP directory to hold email username and passwords. Here is an example of how to check using LDAP. Please note the code is here to demonstrate the idea simply. It is not robust nor secure.

    The first bit of the email (firstname.surname) is the LDAP username so we need to get it.

    <?php
    $email = "firstname.surname@example.com"; $company_email_server_url = "example.com";
    $pos = strrpos($email, $company_email_server_url); $user = substr($email, 0, $pos-1); echo $user; // will echo firstname.surname
    ?>

    Once we have the username we can authenticate against the LDAP server.

    <?php
    // We connect anonymously and get username
    $connect = ldap_connect($server, $port); $bind = @ldap_bind($connect);
    $search = ldap_search($connect, "dc=corp,dc=sample,dc=com", "uid=".$username); $result = ldap_get_entries($connect, $search);
    // We verify using password
    $bind = @ldap_bind($connect, $result[0][dn], $password);
    if (isset($bind)) { $search = ldap_search($connect, "dc=corp,dc=sample,dc=com", "uid=".$username);
    $result = ldap_get_entries($connect, $search);
    if ($username == $result[0][uid][0]) { echo "Authenticated."; } }
    ldap_close($connect); exit;
    ?>

    If you don't use LDAP and you have an IMAP server you can simply name a connection and if it returns true then the username and password is valid:

    <?php
    $mbox = imap_open("{localhost:143}", $username, $password); ?>


    Once the username and password is checked as valid you can then continue with the OpenID authentication process as usual.

    As you maybe aware, we have a new OpenID server in our lab called "Prairie". We are considering adding the LDAP server. Please let me know if this is something you would want because if we get a good level of feedback we'll add it.

Free social software

  • Dutch
    Share information quickly and easily with Dutch; our knowledge sharing network tool.
  • Roundhouse
    Import blog entries from the whole blogsphere into your blog stream with Roundhouse; our social blogging tool.
  • Prairie
    Forget all those different username and password combinations once and for all with Prairie; our Internet identity server.
  • AROUNDMe
    A collaborative networking suite.

Highlights