Imagine visiting a store, showing a plastic card with a few numbers on it to the store employee, and leaving 10 minutes later with a thousand dollars worth of goods. Best of all, you and the store can be fairly certain that neither of you were cheated.

Prior to the invention of the credit card, this sounded too good to be true. But it isn’t: Visa reports to have facilitated 37 billion transactions of this type in the last year.

Let’s change a few words, and read this paragraph again.

Imagine visiting a website, showing the URL of your homepage to the site, and leaving 10 minutes later with a thousand dollars worth of goods. Best of all, you and the store can be fairly certain that neither of you were cheated. [Of course there are a lot more things you might to at a website other than buying something.]

Visa cards are issued by banks, co-branded with Visa. OpenIDs are issued by "identity provider" websites, co-branded with OpenID.

Visa cards are accepted by merchants that display the Visa logo at their front door. OpenIDs are accepted by websites that display the OpenID logo on their front page.

Neither the banks for the merchants could do what they are doing without the common framework provided by Visa, which mostly consists of a well-managed brand, technical standards, payment processing and legal agreements.

It is my belief that the OpenID Foundation could, and should play the same role in the internet identity ecosystem that Visa plays in the payment ecosystem:

• Developing and setting technical standards: something the OpenID Foundation (OIDF) has done for some time.
• Clearly defining and managing the OpenID brand: something OIDF should have been doing since my company (NetMesh) transferred the OpenID trademark to the OIDF.
• Developing and encouraging the use of common legal agreements for OpenID providers and acceptors: the OIDF has not done this so far, but we have been asked many times and may start work on in 2009.
• Because OpenID is built on the open internet architecture, there is no need that I can see to operate the equivalent of Visa’s payment processing organization.

In my view, somebody needs to play that role for internet identity that Visa plays for payments; otherwise it’s fairly clear internet identity can never scale to the ubiquity of Visa — but OpenID has the same opportunity to become a factor of life for everybody as Visa had back then, and it should go after it. By way of comparison, I think most internet users log into web applications at least as often as they use their Visa card, so the opportunity is even larger than the 37 billion Visa transactions last year.

Given that this is the 21st century, a Visa for internet identity needs to be structured ifferently that Visa is, but we have already done this with the OpenID Foundation:

• non-profit, rather than for-profit;
• democractic membership organization with a low price of entry, instead of a shareholder corporation;
• being a market facilitator rather than a market participant.

Of course, wanting to be of such global significance as Visa would require us to start behaving like it. I hope that the to-be-elected new board is up to the challenge. If elected, that’s the direction in which I’d like to drive the organization and the board.

In a recent post I argued that OpenID identifiers such as www.davidrecordon.com, =eek and mylid.net/jernst are much more natural than those generated by Yahoo! or Google that might look like this: me.yahoo.com/a/vIxu8Lll29jYXQEYBNg86tIZgY7Bs8c7.

Eric Sachs, the product manager in charge at Google, gave me a hard time over it; actually, he didn’t because he’s way too nice to do such a thing. But he let me blog some of our conversation. He writes:

Google & Yahoo both use OpenID URLs by default that are not human readable, and if someone visits them, the pages have no information about the user…

One of the reason that Blogger’s OpenID service launched before the generic Google service is because those users by default had already been through the pain of picking a "human readable" name for a URL.

For our E-mail users (@gmail.com/@yahoo.com) we could have chosen to return URLs with the user’s E-mail username as AOL does, but chose not to for what are hopefully obvious reason.

So we were left with the options of (1) not launching IDPs at all, (2) launching the IDPs with machine generated IDs, or (3) forcing our users to pick an "human readable" name for an OpenID URL (but one that was not their E-mail address)

Unfortunately, for both of us option 3 requires a user to try on average 5 times to find a name that is available. We have tried to force users to pick such a name for other services at Google, and the abandonment rate is 90-95%. Yahoo’s experience is similar. The RPs we have talked to (both big ones and small ones) have said they would not use our IDP if we forced users to go through a process with such a high abandonment rate.

So while I understand that in a perfect world our choice of 2 over 3 is not great, the alternative is 1, i.e. not launching IDPs at all. And if we went down the path of #1, then the only people who could use OpenID would be bloggers and users of some social networks that use human readable URLs for profiles (though that excludes Facebook, LinkedIn, orkut, etc.)

To which I responded that I think there is a third alternative a la tinyurl. Here is Eric again:

Yep, that is what we tried for orkut.com initially. Unfortunately we got the standard problem of dictionary attacks against those URLs for screen-scraping. We experimented to find the smallest length ID that would still enable us to implement DOS style blocking for screen scraping. Unfortunately that length was 2 characters longer then what people could remember for their own ID, so we sadly gave up And that was actually back when the orkut.com user base was a LOT smaller.

You could check with … MySpace/Facebook because I think they tried the same thing and had the same problem.

Me again: "Then I’m missing something. Why is that a problem? What advantage do I gain as an attacker if I guess that somebody’s URL is me.yahoo.com/a/vIxu8Lll29jYXQEYBNg86tIZgY7Bs8c7? In particular if sites — like this example in point [the openid.net site that sparked this thread] — will show it publicly anyway?

Eric:

The problem a bunch of social networks have had is evil websites who just try to crawl our entire systems by guessing our users’ profile URLs. They then use that data for a number of nefarious purposes, some of which are pretty sophisticated. Others are more basic, like trying to track the size of a social network’s user base for competitive purposes.

If hackers can still guess (or find elsewhere) some URLs, that is not nearly as damaging as them being able to easily crawl the whole social network. And by making our profile IDs longer, we can monitor for hackers who are trying to guess profile IDs because we see lots of requests for non-existing URLs.

I thought this exchange was worthwhile blogging. This is not the first time I’ve had this conversation, but I had not been aware of that last argument — which, as made, seems to apply mostly to social networking-related sites, but not other types of sites.

What I’m concluding is:

1. If you can get your users to pick human-readable names that are not also e-mail addresses, that’s the best alternative.
2. Otherwise, use a tinyurl-style automatically-generated scheme, unless it conflicts with the goal Eric outlined.
3. If all previous approaches fail, use what is essentially a randomly generated UUID.

Remains to say for me that I now understand the argument that is being made, but there are substantial counter-arguments be made as well, including the user-unfriendliness of a non-human readable scheme, and the much higher susceptibility of what I call Phriend Phishing.

The last word hasn’t been spoken, but hopefully this discussion is helpful to understand the state of the best thinking.

Screen shot from the nominations page for the current OpenID Foundation board elections.

I’ve always thought that OpenID identifiers need to be human readable because they are likely to be printed in places like this one. Can you spot the identifier that’s just not as helpful as the others?

I have erased some information that is not needed to make my point here. There are also more nominees that you can see if you are an OIDF member, or if you read ReadWriteWeb.