Marc Canter raises what many in the community have been saying for a long time, but what the OpenID Foundation seems to have a hard time wrapping its collective minds around:

… OpenID can actually solve … [many] issues - by embracing other complementary technologies (like oAuth, OpenSocial, Portable Contacts, microformats, FOAF and RSS/Atom) to create a wrapper solution oriented approach - focused on simplifying the whole ID conundrum for end-users. Barriers of entry, usability issues and confusing messages can all be solved by OpenID positioning itself as a single point-of-contact solution.

He follows up the next day saying:

Open Stack is a little too general. I use the term open mesh - on purpose - cause I don’t WANT it to be specific. Open Mesh has to represent the combination of a bunch of different stacks; some open, some semi-open, whatever.

But OpenID sure is a great term - and it could certainly be morphed into THE brand.

This is what we need right now - a single entry point into solving the ID conundrum. ID is hard and asking end-users to keep track of the difference between Single Sign-On, authenticaton, reliable parties, claims, trust, security, privacy, data portability and persona - is just not gonna happen.

…

Without that - and we’ll be stuck catering to geeks and nerds like us - forever.

That last sentence is one that I’ve been re-iterating to anybody who’d listen in OpenID land for too many months now, or so it feels. Branding is at the very top of that list, and I completely agree that the brand has to bigger than a little protocol (and thus confuse the user with some many more little brands of other little protocols).

The question is: do the movers and shakers in this community have the courage to put the petty turf wars over being the biggest fish in a tiny pond aside, merge the ponds and actually create something, together, that is big enough to truly matter?

Says Marc:

Or as Rodney King said so eloquently “why can’t we all work together?”

And I might add: and perhaps accomplish something that actually matters in the real world?

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 …

A somewhat problemantic picture has been floating around recently depicting the so-called "Open Stack":

There is just one problem with it: the dependencies are all wrong. For example, OpenID does not depend on OAuth; both depend on XRDS-Simple, however. That means the stack isn’t actually a stack and perhaps a lot more confusing than it needs to be…

What about this instead:

Can we change this *before* too many people pick up this picture as their battly cry? Proposed improvements very much welcome; this is difficult to visualize. Please let me know. And if you can think of a better name for it, that’d be good too. (Just check Google what others think the term means)