Pete Rowley

In Why Johnny Can’t Authenticate Ben Laurie makes the point that:

I often hear it argued that using something better than passwords will fix the problem, for example, public/private key pairs. There’s actually two fundamental reasons why this ain’t so…

• So long as its possible for users to recover from losing their keys (or passwords, or whatever it is they use to authenticate) in a way that can be imitated by phishers, they will not be helped by these protocols. Phishers currently concentrate on getting people’s passwords simply because that’s the low-hanging fruit. Pluck that fruit and they’ll move on to recovery (which obviously cannot use anything the user can’t hold in their head).
• Computers aren’t secure and users can’t be trusted to make good decisions about what to run. Start using public/private key pairs and they’ll be stolen by viruses and worms instead of fake websites and spam. Indeed, trojans that log keys in order to steal passwords already exist.

This perfectly reasonable opinion really speaks to the current state of affairs. It is war out there and right now the phishers are winning. But I wonder if it really is an unwinnable war, or whether the current state of the art is simply too bogged down in its own dogma to see passed it. In the end no single thing will save us from the phishers since there are just too many angles of attack. However I would like to think that a combination of technologies and user training through good rituals will make phishing a long shot so long that it is not worth the risk of the attempt. I do wish our banks would help out by using what is available now though.

The Liberty Alliance made a bold statement in Vancouver last week when it opened its doors for the first time to the hoi polloi. Now this was something interesting enough to demand a visit in of itself, but with the addition of an Open Space after the Liberty meeting, well, you knew I was going to be there right?

The first two days consisted of the regular business of the Liberty Alliance where visitors were allowed to attend any session except for the super secret board stuff. I attended many of the technical sessions which were interesting, though sometimes hard to follow as an outsider without access to the documents under consideration. I also took part in a session around privacy concerns that not only assured me that Liberty has them but that they are serious about dealing with the issues. The conversation turned at one point to outside perceptions of Liberty itself and its lack of openess to its internal process and draft documents. Somewhat ironic was the point made that nowhere was there to be found any information regarding the location of the Liberty conference, at least not to those without access to internal websites. A consequence of this being the first open meeting no doubt. In all, an interesting and worthy meeting.

The final two days were spent on the Open Space which was run in unconference format by Kaliya Hamlin and was excellent as usual. Topics ranged from SAML to Liberty People Service to how should we rename this user centric identity thing? Kim Cameron wrapped up with a lunchtime introduction to CardSpace that by popular demand lasted for nearly two hours. At one point Kim was asked whether Apple would have an identity selector like CardSpace and Kim redirected the question to me in my capacity as OSIS representative. As the newly appointed unofficial spokesman for Apple I suggested that if Steve Jobs would call me I’d hook him up.

So Steve, call me.

Continuing my popular “people in” series of blogs I note that distinguishing between protocol and policy seems to be a hard thing to do. At least there appears to be a level of confusion between the two with regard to user-centric identity. This manifests when folk start talking about use cases that require access to identity data when the user is offline and not available to have the data flow through them. I recently replied to one example:

I think we are in danger of conflating architecture and policy. The point of the architecture is that the data flows through the user. User granted policy could be that data. The policy might include credentials that allow access to portions of the user data with other constraints attached such as time and usage limits. The policy will be observed by the IdP [Identity Provider]. The credentials will be owned by the RP [Relying Party]. Both will have passed through and been approved by the user and therefore are “user-centric.”

User-centric identity has a large slice of online user created policy implicit in the architecture, but it does not preclude persistent policy decisions, including decisions that result in data flows around rather than through the user. The key is that the policy was created by the user and granted by the user, and incidentally should be revokable by the user.

Next week, people in the teleconference.