(1) As a way to prove you own the URL associated with your blog comment. This is the original problem that OpenID was designed to address, and although commenter impersonation isn’t a big problem for most blogs, OpenID is a great solution.

(2) As a way to identify yourself to a web site without having to create yet another username and password. This is web single sign-on, which addresses a real problem for those who want to easily use all the great web apps out there that aren’t part of Google/Yahoo/Microsoft (a big advantage of which is that you can then log in using their IDs, which you probably already have).

(3) As part of a way to calculate reputation, which can then be used to block spam or grant permissions. Other commenters point to ways in which OpenID is headed in this direction, but I think Matt’s point is that it isn’t there yet, and there are existing solutions that work reasonably well.

I think (2), web single sign-on, is by far the most compelling. It’s a big problem, and OpenID could be a big part of the solution. To me it makes a lot of sense to focus on getting some real traction for Web SSO before tackling the much tougher reputation / spam problem, which unlike Web SSO already has some workable solutions.

But looking at the progress of OpenID and Web SSO in general, what is the biggest barrier to widespread adoption? Lots of people talk about issues like security, technology, and usability, and these are all important. But as I’ve said before, the most important thing is to make it as easy as possible for site owners to adopt the system.

That means minimizing integration requirements and supporting the identity interfaces these sites already use. This is exactly what we’re trying to do at PrefPass, for OpenID as well as the other IDs that a lot of users already have: make it easy and risk-free for site owners to eliminate passwords for most of their users right now.

This is a really cool way to get more users to sign up for your app, without having to deal with the fast-changing landscape of digital identity solutions. Instead, just paste some code, and we’ll take care of it for you! The idea is to address some of the pain points for site owners (or “relying parties”) that I talked about in my previous post on the Laws of Identity.

You can read more about the new PrefPass service here; we’re also working on a WordPress plugin that should be out soon. Check it out!

I had really wanted to attend the day three session on “The Business of Identity” initiated by Johannes Ernst, but I wasn’t going to be able to make it and so stopped by the previous afternoon.

One thing that’s clear is that the identity space is evolving to the point where the technologies are going to see adoption by web apps and sites as well as the larger companies that already are active users. I heard some pretty impressive news on this front from Andy Dale, but it doesn’t seem to be public yet so I won’t mention specifics here.

I do hope more folks keep thinking about marketing and how the profit motive can help drive the adoption of identity technology on the web. Great progress has been made in ensuring that these technologies are open, flexible, and not controlled by any one company or entity; but now that these barriers are gone, I think it’s time to start thinking about positive forces that can help to jump-start the entire identity ecosystem.

iiw2007

However, there’s another important group whose needs don’t seem as well represented in the Laws as they should be. That group is site owners, or “relying parties”. And it seems to me that on the web, site owners represent “reality”: an identity system might encompass the best ideas of the day and be beautifully self-consistent, but unless it meets the needs of this group, by definition it cannot be a success.

Now, it probably says more about where my head is at than anything else, but I’ve been noticing a lot of parallels between the current state of digital identity and that of another area I pay a lot of attention to: theoretical physics. So at the risk of establishing a completely opaque metaphor, I’m going to propose that:

The Laws of Identity are like String Theory

Like the Laws of Identity, string theory encompasses the best ideas of the day and has a beautiful self-consistency. But by definition, to be a success any proposal based on this theory has to match the actual universe we see around us. And so far, string theory has failed to generate such a proposal.

Similarly, any system based upon the Laws of Identity as formulated today cannot be successful unless it meets the needs of site owners, who in the real world are the folks who have to adopt the system. And right now, I think that the systems out there don’t match what many site owners need.

To be more specific, lets take a look at two standards with a lot of momentum right now: OpenID and CardSpace.

OpenID is like General Relativity

Like general relativity, OpenID simply and elegantly solves a specific problem: how to prove to a site that you own a URL. Here’s a diagram showing at a high level how the system works:

I’ve skipped some of the details here and in subsequent diagrams in order to create pictures that are easy to compare to each other.

Also like general relativity, OpenID is an amazingly effective but demanding tool. In particular, if used as an authentication tool, OpenID demands that the site owner integrate and keep current a block of additional code, and that the user database be altered to accommodate users who instead of a username/password use a URL to authenticate.

This makes sense for a site that really needs what OpenID offers: proof of URL ownership. And this is what OpenID was originally designed for: verifying the identity URL of blog commenters. But what about a typical site that just wants to offer its users an easier way to log in?

To me, asking a typical site to deal with libraries and database changes just to ease logins seems about as sensible as asking missile designers to use general relativity to calculate trajectories. You want to use the simplest tool for the job, and while GPS calculations might require GR, the vast majority of gravity calculations do not. Along the same lines, I’d argue that proof of URL ownership isn’t the simplest way to authenticate for most web apps.

CardSpace is like Quantum Field Theory

Now let’s consider CardSpace. Like quantum field theory, CardSpace is a flexible and powerful framework that can be used to solve a wide variety of problems. Here’s a diagram for CardSpace, simplified to be easily compared to the previous diagram:

CardSpace is another demanding tool for site owners: as with OpenID, they are faced with code integration and altered databases. But beyond this, CardSpace shares another characteristic with QFT: the feeling that something’s just not right. For me, QFT feels wrong because, among other things, it’s dependent upon a background metric. In the case of CardSpace, the problem is dependence upon client software. CardSpace is PC-centric, and dependence upon client software just feels wrong in today’s web-based world.

In particular, CardSpace puts the “identity selector” on the PC as software. This means that every client has to have this software, and even worse, the identity cards themselves are not web-native; they need to be transferred from PC to PC using a USB key. To me, this makes using CardSpace in place of username/password for web apps about as sensible as using QFT in place of Ohm’s Law. The PC-centric approach might make sense in the enterprise, but for consumer web apps it seems to me like a bad fit.

Another issue I have with CardSpace is that authentication with the identity provider doesn’t take place in a browser; instead, it seems to be constrained by what the identity selector software offers. If I have this right, this really limits options for the identity provider — what if they want to use two-factor authentication, or a captcha, or a personal image for anti-phishing? Only a browser interface provides the flexibility that at least I think is needed to accommodate the diverse landscape of identity scenarios.

Identity Meta-Providers are like Quantum Mechanics

OK, so what is it that web apps need then? I think that what’s needed is the analog of Quantum Mechanics: an approach that incorporates the core ideas of more complex systems yet is usable for solving practical problems.

Leaving the tortured metaphor behind, this means moving from an identity meta-system like CardSpace to an identity meta-provider. The new web is all about services, mashups, widgets — all available from any browser. Why should identity be any different?

The key differences between the idea of an identity meta-provider as opposed to a system are:

(1) the “identity selector” function is provided by a web service instead of by software on the PC
(2) rather than simply pass on whatever auth token is issued by the identity provider, the identity meta-provider translates this authorization into a form that is easily digested by the relying party

Since I’m focusing on web apps, I’ll assume the IMP translates auth into the usual username/password, which is certainly easy to digest by existing sites; but this isn’t a requirement. Here’s a picture, easily compared to the previous two:

The main idea is to change two things about existing approaches:

(1) to require minimal effort on the part of sites
(2) to keep everything web-centric

To me, this approach has a bunch of incredible advantages:

– The identity provider can now use a web page to authenticate
– No cards exist on the PC to be stolen, moved around, etc
– Site integration is incredibly easy

Of course, these advantages come with tradeoffs:

– Sites must trust that the IMP actually authenticated the user; no signature proves this (sites for whom this is important can always choose a IMP that passes the native token on)
– Users can only use identity providers that the IMP decides to support (this can be addressed by competition among IMPs)
– The additional network communications to and from the IMP are attackable

In my opinion, these tradeoffs are well worth it.

The 8th Law of Identity?

Coming full circle, the idea of an identity meta-provider addresses what could be thought of as the “missing 8th Law of Identity”. This would be something like:

A universal identity system must streamline site adoption by minimizing integration requirements and supporting the identity interfaces these sites already use.

For most web sites who would like to ease user registrations and logins, this means that the system must hook up to existing username / password systems.

Is an 8th law, along with the concept of identity meta-providers, enough to get us to Kim Cameron’s “identity big bang”? I’m not sure, but I do think it’s a step in the right direction.

Get Flash to see this object.

UPDATE: Since writing this, I’ve come across a couple of proposals that have some of the same moving parts, but accomplish different objectives.

Kim Cameron proposed using CardSpace to authenticate OpenID users at their identity provider. This sounds like one way to reduce the phishing vulnerability of username/password authenticated IPs, but of course it brings back the requirement of client software.

Dmitry Shechtman proposed (and illustrated) a browser plug-in that, as I understand it, would implement a kind of CardSpace-style OpenID identity selector. This also helps reduce phishing vulnerability, and has a nice flow that simplifies the current OpenID user experience. But again, client software is required and relying parties still face the same integration issues.

But another aspect of PrefPass is that, unlike previous solutions such as form-filling utilities or single sign-on systems, PrefPass keeps users anonymous. This aspect is a bit more complicated.

Anonymous literally means “of unknown name,” but in reality we mean a lot more than that when we use the term. Does it mean that you don’t know who I am in the real world? That you don’t know that I’m the same person that writes a different blog? That you don’t know that I’m the same person that wrote the last post on this blog?

As far as I can tell, there isn’t really a standard way of characterizing these different degrees of anonymity. But there are some standard terms whose meanings can be perhaps slightly bent to cobble together a basic ranking:

– Unknown: absolutely nothing is known about the user

– Anonymous: the user is associated with an identifier that applies across transactions at a single site. Cookies are a common way of anonymously identifying users on a temporary basis.

– Pseudonymous: the user is associated with a pseudonym (AKA handle, username, or nickname) that applies at other sites. Most single sign-on (SSO) systems are designed to prove ownership of a pseudonym.

– Personally identifiable: the user is associated with information which can potentially be used to uniquely identify, contact, or locate them. Personally identifiable information (PII) includes things like name, telephone number, street address, and e-mail address.

One problem with pseudonymity is that it is susceptible to correlation, which can lead to personal identification. For example, if data associated with one pseudonym is collected across many sites, this richer dataset may make it possible to personally identify the user. Or if one site is compromised, this can affect the user across all sites where that pseudonym is used.

For these reasons and others, at PrefPass we decided to provide users with anonymity, not just pseudonymity. To do this, we used what in digital identity circles is called a unidirectional identifier. That just means that when you click on the PrefPass badge at two different sites, each site is provided with a different identifier. That way, each site can recognize you, but no one can tell that the same person joined those two sites.

Of course, PrefPass is all about user control, and with control comes responsibility. For example, you could manually enter a pseudonym at multiple sites where you use PrefPass to join. That would make you pseudonymous at those sites; but it would be your decision, not something built into PrefPass. And no other PrefPass sites would be affected by it.

Now, some might argue that true anonymity is impossible on the internet; that without extraordinary knowledge and care, anyone leaves a trail that can be pieced together to find out who they are in the real world. For example, see this recent blogosphere brouhaha.

But at least for me, that doesn’t at all mean that we should throw up our hands and sign our names on every page we visit. You can do a lot to remain anonymous on the internet, and as always, defaults matter. It’s true, if someone really wants to track you down, and is willing to dedicate time and money to doing so, there’s a decent chance they’ll succeed. But the same is true in the real world: if someone really wants to break into your house, they probably can. But that doesn’t mean that you shouldn’t lock your doors and safeguard the key. Most crimes are crimes of opportunity, and basic good habits will make a big difference in how likely you are to have problems.

I haven’t even touched here on another feature of PrefPass that complements anonymity: transparency. Details will have to wait for another day, but the basic fact is this: when you use PrefPass to personalize a site, the data being used for personalization is visible, editable, and controlled by you. The idea is that by making it easy for sites to ask you for your Prefs directly, they’ll have less reason to try to piece together your interests in some other way. In our view, the trade of Prefs for personalization is happening all the time on the web; so why not make it explicit, easy, anonymous, and transparent?

PS: “Degree of anonymity” is also actually a technical measure of how anonymous you are using a given anonymizing approach. Details here.

In the requisite three words, what is PrefPass all about?

As I was talking about in the last post, the idea is to keep things simple and anonymous for users, while giving sites exactly what they need:

– A user identifier (unidirectional: unique to the site and user)
– User prefs for personalization: keywords, interests, etc.

So what’s the point? To reduce the number of registrations and passwords you have to keep track of. How many times have you followed a link to a news site, or tried to check out a cool new app, and decided to bail out when you were faced with yet another registration form? PrefPass replaces that form with one click.

For sites, letting people bypass registration means attracting more users, providing better personalization, and earning higher ad revenues. PrefPass is really lightweight, so there’s no server side integration and no security worries, just a simple javascript button you add to the site. For an example of some things you can do with PrefPass, check out the demo site we set up at YourSuperNews.com.

For blogs, PrefPass is so easy to use that you can essentially add instant personalization to your blog. Check out the widgets in my sidebar for an example (more coming soon). If your blog or app has ads, you can earn more from them by targeting them to user interests, as they are here at EconoMeta. Even if you don’t have any ads, PrefPass complements stats like hits and pageviews by showing you what your readers actually are interested in — an example of this is the Audience Cloud in the sidebar here.

The point is that pretty much any site can be made better by being customized to user interests. And the purpose of PrefPass is to make it as easy as possible for the site and user to form the relationship needed to do this.

We’re off and running, with a long list of cool stuff on the way. Give it a try, and let us know what you think!

Here’s what I talked about. The concept of “digital identity” has been around for a long time, and usually includes all kinds of complicated functionalities. For example, an identity can:

– Prove you are the same person you were last time you visited
– Prove that you are a specific person or have certain attributes
– Prove that you have authorization or a reputation verified by a third party
– Grant permission for one site to pass your data on to another

But what does “identity” mean in reality for most consumer web apps? Well, basically, it usually means a registration form, an email validation, and then another username and password to remember.

This is kind of a pain for users, which makes it worth asking: what’s the *real* reason sites require registration? For most apps, it’s to do one or more of the following:

– Ensure the user is a human and not a bot
– Associate the user with site data (e.g. settings)
– Associate the user with preference data (e.g. interests)
– Contact the user (e.g. to email a forgotten password)
– Target ads to the user (to make more money)
– Associate the user with a specific person (e.g. a blogger)

Looking at this list, the interesting thing is that only the last item really requires an “identity” as most of us think of it. You’d think that the rest could be done without the oftentimes complex machinery of most identity solutions.

Well, it can, and from a certain perspective, that’s what PrefPass is all about! Instead of the same old [form -> email -> response -> password] sequence, why not just [click]? And why not make it completely anonymous? After all, only the last item above requires you to “prove” that you’re someone in particular. With anonymity, there’s no ID to remember, no privacy issues, no namespace to worry about — just [click]!

Microchunking identity means reducing it to its smallest usable parts. For example, there are some cool solutions that focus on proving that you own a blog URL — that’s a microchunk. With PrefPass, we’re focusing on letting you tell a site that you’re the same person as last time, and that you’re associated with some anonymous metadata representing your interests or preferences. That’s it. By keeping it simple, we hope to be able to solve some real problems for both sites and users, while making a big change in how much users can control their own data.

We’re just about to launch a limited beta, so if this sounds interesting to you, please help us out! You can request a beta invite by clicking on the PrefPass button in my sidebar or by going to PrefPass.com. We’re also looking for additional sites who want to try out PrefPass during the beta. If 1-click registration, instant personalization, or user-targeted ads that pay more sound interesting to you, please give me a shout at adam at prefpass dot com.

This is a powerful idea; but why limit it to media? It seems to me that the same logic applies to applications. A big part of what I think is exciting about the latest batch of web apps is that they microchunk what was once a monolithic software application (e.g. Office), make it web-native, and monetize its use via advertising and/or premium service fees.

Going back to digital media, a big part of why it can be effectively microchunked now is that certain enabling technologies are widespread enough to reduce the advantage once held by centralized media: things like editing tools, RSS syndication, and aggregators. The same thing is true for apps; enabling technologies here would include widespread broadband, more active browser techniques like AJAX, and standardized data formats.

I think that there are two main remaining barriers to microchunking apps. The first is the lack of many needed standardized data formats. One big help in this regard could be microformats. The second big remaining stumbling block is that of identity. Big applications, whether on the web or not, have the significant advantage that you just log in once, and then can easily use the different components of the app together.

So how could this identity barrier be knocked down? Well, how about microchunking identity?

As it so happens (or more like, partly motivating this post), microchunking identity is what I just talked about at BarCamp SF. I’ll get to that in the next post.