Many technology vendors would go very far to be allowed to speak at one of the major analyst conferences for CIOs and other enterprise technology buyers.

So, in our case, an unsolicited invitation to speak at such a conference showed up in my e-mail inbox a couple of months ago. Then, a reminder, a few weeks later. And another repeat invitation. The jackpot, many vendors would say.

Except, that thanks to the spam-fighting wisdom of my e-mail program, I never got to see any of those e-mail invitations. Clearly, the spam filter must have thought, these guys are just trying to sell me something.

So here I am, having repeatedly sleighted this invitation from a major analyst firm, without even realizing it. I only found out yesterday, by accident.

Can one apologize on behalf of one's spam filter? Would anybody right in their mind accept such an apology?

Life used to be simpler ...

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)

The Telegraph reports:

...hundreds of chip and pin machines in stores and supermarkets across Europe have been tampered with to allow details of shoppers' credit card accounts to be relayed to overseas fraudsters.

These details are then used to make cash withdrawals or siphon off money from card holders' accounts in what is one of the largest scams of its kind.

...America's counterintelligence chief said: "Previously only a nation state's intelligence service would have been capable of pulling off this type of operation. It's scary."

An organised crime syndicate is suspected of having tampered with the chip and pin machines, either during the manufacturing process at a factory in China, or shortly after they came off the production line.

This is why using the idea of a claims transformer as the general panacea for identity issues has always been very scary to me: if you have a good claims transformer, you don't really (want to) know that it is there, but your security depends on the security of each and every claims transformer in the chain.

Here, nobody thought that the card reader (a claims transformer) was even a possible security issue. How many more claims transformers are there in the credit card (or any other) value chain, and how many of them are susceptible to similar attacks? I think we'll only know after the next attack has been detected on the next claims transformer in the chain ... one by one .. and that's even more scary.

It's also a very good example for what works within an enterprise has little or no bearing on whether it works for a whole value chain, or the whole internet: in an enterprise you can enumerate and watch your claims transformers, even if it's hard. If you go beyond the enterprise, it's almost ridiculous to attempt and try ...

Allen Tom of Yahoo! announced that results of their OpenID usability studies are available. It's great to see them do that — both doing the study, and releasing the results.

Google did something similar earlier.

Are the results depressing? Personally, I don't think so: instead, they are a call to action. Let's get our hands dirty and fix what needs fixing...