The truth about identity (part 2 - Web 2.0 Apps)

Creation and maintenance

The main requirement here is for a user to be able to create and then further maintain his assets (photos, links, calendars, projects etc.).

Typical risks for a typical web 2.0 application are for the application operator:

• Loss of a user
• Legal liability towards users
• Users misuse of site that could get you in trouble – eg. Spam or posting of copyrighted material

For the user the risks are a bit greater:

• The user looses control of his assets
• Private data gets made public
• Site owner peeks at private data
• Site owner “steals” password

Firstly for you as the site operator you can see that a persons real name or address is completely irrelevant. It is essentially an issue of access control. If a users misuses the site you can always disable him and his assets.

The most common way of identification here is through a user name and password. This allows a user to manage all of his stuff by simply going to the site and registering. For you as the site developer these users are entries in a database and accessed via a User object.

It can be a bit of a hassle for many people to remember 100s of passwords and user ids. Luckily most people have by now managed to create their own schemes for classification of various passwords with types of sites.

Most web browsers nowadays also include a handy password remembering tool, so the hard work is handled for most people. Thus the old single sign on application of most identity systems is not really all that important in reality.

There is still though the fact that many people won’t go through and register just to check something out. There is a bit of a hassle cost here for the user, so you really do need to present a good reason to users to register.

Email verification

Many sites require email verification of users, which is one step you might easily be able to get rid off to lower the entrance cost/hassle of your users. Most site developers think that email verification is an absolute necessity without ever questioning it. It may very well be a requirement, so lets examine it.

Will your user ever need to use your service to:

• send invitations
• send emails (such as project management reminders)
• does he some how have to make claims that he has a particular email address?
• link to other sites (eg. Gravatars or RapLeaf).

If any of the above are true, then a verification is a necessity. You could potentially wait until the user has to do any of these things if you wish. If none of them are true you are just raising the barrier of entry to your users.

Collaboration

If your users use your site to collaborate with other users you need to help your users identify their collaborators. Chances are you will need to send invitations and you will have to hook into a fantastic identification system called email.

Most of the Web 2.0 services use email as the identification glue. Allowing them to be invite existing friends and connections to collaborate.

This is not always the case though. If your service takes off it may actually end up being the main source of identification between your users. For example Flickr users know each other by our Flickr nick names. For example I don’t know Tattva73’s real name nor email, I just know that she takes amazing photos in Panama. The only identifying factor necessary for me her style of photos and her nickname. Thus Flickr has become it’s own identification system.

The no user account option

With WideWord and WideBlog I took a slightly different approach. Obviously I have users, but I don’t have a User object. Each document or blog is identified by a unique key, which gets sent to the users email. The user can therefore manage his WideWord documents via a folder in his mail program rather than going through a sign up process.

The reason I decided to do this was that I wanted people to be able to get writing a WideWord document in a few seconds, rather than having to go through the trouble of signing up, waiting for an email and then figuring out how to use the service. Now this is not always the best way to go, but in many cases it is.

Great examples are a brick and mortar stores. Many shops have loyalty card schemes, where they encourage you to sign up for some sort of benefit to you and to them. With a few notable exceptions the majority of these stores will happily accept your money without forcing you to identify your home address. And you know it’s not worth the store’s time signing all the customers up anyway. They are interested in signing up current and potential repeat customers, not European tourists visiting Orlando for a week in June.

So to let a single user create and manage assets on your site do you really need him to sign up? Are you losing potential 1 off users for the sake of the power users? These are the questions you need to ask your self.

Email only access control

There is a growing trend for web applications to just require an email account. No password necessary. To log onto your site a user simply enters his/her email and an authenticating email gets sent to the user.

Clicking on the link in the email gives the user access to the site.

I personally think this is a great approach that more web 2.0 applications should use. In particular infrequently used applications.

This is a very low cost/hassle approach to identification that provides you with most of the benefits of the user/password option.

CardSpace, InfoCard etc.

DHH and I were both contacted by Microsoft to help implement a Rails implementation of their CardSpace identity system. I like David declined for a variety of reasons. The main reason of course is that I wouldn’t use it myself in my own applications. But otherwise because it is essentially more of the same.

This is basically the latest iteration in the whole X509 saga. Technically speaking it is interesting, but it like all the other PKI based systems introduces a huge cost/hassle level for both users and implementers. If ALL the major browsers put in support for it, it might have a bit of a future for some applications. However as far as I can see it doesn’t really offer any real benefits for web application providers and users that we haven’t already got with username/passwords.

Conclusion

Look at every hurdle you give your user to gain entry to your system. Is it really necessary? Do a 5 minute risk analysis for your own site. For the security aspects you might find my old article Trust points and Breach points in Web Apps useful.

This has been an article in my legal category. If you haven’t done so already you should check out the first part of this series The truth about identity for bloggers.

You might also enjoy the very closely related articles Pragmatic Contract Law for Entrepreneurs and Understanding and preparing for Jurisdictions.