Traditionally, a state diagram (aka state-event model) of authentication on the web is very simple. It has only two states: Anonymous and Authenticated.

A user’s session moves from Anonymous to Authenticated upon successful presentation of valid credentials (such as a password). It moves back to Anonymous if the user logs out, or after the user’s session expired.

This model is very simple to implement, which is why it is so widespread, but unfortunately it is not very user friendly. If applied to OpenID, we get the rather bad user experience of, say, the wiki at openid.net, where logging in with OpenID actually takes more steps than it would take to log in with a traditional username and password.

In time for IIW that starts tomorrow, I’d like to propose a more complex but much more user-friendly model that’s shown here:

Here, we distinguish between the Anonymous state as before, but then three other states in which the user session may be. In each of these three states, the user is known, but with different levels of confidence.

• In the first state, “This request authenticated”, the HTTP request carries the valid credentials, and thus we have the highest confidence that the user is indeed the correct one.
• From that state, the session immediately moves to “Session authenticated”, typically implemented with a session cookie. While we are still fairly confident that the user is who was authenticated, we are less so than in the state “This request authenticated”: for example, the user’s cookie might have been stolen, or somebody else might be operating their browser because they stepped out of the office to get a cup of coffee.
• Finally, when the session has expired, we still know who the user likely is, but with far less confidence. After all, they haven’t provided a valid credential in some time.

The reason this is a better model is the state “Session expired” shown with a fill color. If a web application receives an incoming request but the session is in that state, with OpenID, if often can transparently reauthenticate the user. In the extreme case, the user never has to provide any credentials to that application again (after the initial login), because every time the session times out, the application can transparently re-authenticate the user by going back to their OpenID provider. Note that unless the user explicitly logs out, the user’s session never moves back into the Anonymous state; ergo, no fresh login is required. And there is just as much security as before.

In case of the OpenID wiki, that would mean that it would simply “recognize me” the next time I want to edit, and I don’t have to go through the unnatural act of having to authenticate again. Unfortunately, MediaWiki does not implement that more complex state model, and so it’s hard to make it behave that way. But it sure be nice if it did.

Interestingly enough, some web properties implement this more complex model. In case of Amazon, for example, you can recognize the state “Session expired” while the user is still known on their front page where it says “Recommendations for Johannes. Not Johannes?”. It only requires valid credentials later in the transaction. Now imagine that it didn’t even need those if they implemented OpenID …