Scott Blomquist

Selection paralysis

I got to thinking lately about how I wish I had a wiki on my personal web site, because I want to do some quick’n’dirty semi-structured and richly linked writing to share with others so I can get feedback and input. I spent some time catching up on what wiki systems are best at what, and discovered I was completely daunted by how many different choices there were.

I eventually whittled the list of candidates down to just short of 10 different packages, and then got stuck again. What happens if I pick one today and invest considerable time in it only to discover that a different one fits better with what I’m using it for? Is there any way to migrate the data to a different wiki package at or near full-fidelity?

More »

Roy Leban blogs about stupid password policies over at his thisUser blog. I’ve got some good news for Roy and his readers: I’m currently making a living turning all of the things that he rants about into relics of the unenlightened past. And while I have to concede that it’s a slow uphill climb, there are some very exciting things that you can do today to start simplifying your online life.

The first one worth mentioning is a thing called OpenID, which is pretty much just single sign-on for the Internet. This is not a terribly new idea–Microsoft has been pushing for something very similar in the form of Microsoft Passport Windows Live ID for around a decade. OpenID has the added benefit that you can use it even if you’re not convinced you’d like to involve Microsoft in your online life.

In fact, you can even host your own OpenID. For example, I use the address of this very blog (http://scott.blomqui.st) as my personal OpenID. (You can see it in action in my previous comments on Roy’s blog such as here. Notice the shiny orange OpenID icon to the left of my nickname?)

If you want an OpenID, I’d suggest myVidoop. (Full disclosure: I’m the CTO of the company that built it.) We’re one of the better-known OpenID providers, and unlike the other OpenID providers, we actually have a way of making money.

The big problem with OpenID today is that there are much fewer than 20,000 sites that allow you to log in today using OpenID. Which brings us to the other neat thing about myVidoop–we provide a cross-platform browser plug-in that helps you by managing your usernames and passwords as you cruise around the web. This enables you to sign in once when you open your web browser, and then we take care of signing you in to the other sites that you visit, whether OpenID-enabled or not. (Oh, and we also use a fun alternative to passwords for signing you in to the myVidoop site, so it can literally make your life almost password-free.)

I’d be thrilled if you’d give myVidoop and our password management plug-in a try and give us your frankest feedback over on GetSatisfaction.

Finally, I’ll mention for the benefit of the web site owners in the audience, there’s an experimental Vidoop project called Email to ID. If you have a web site that would be using OpenID if only most users already had one, Email to ID is your solution. Email to ID gives every user an OpenID, and the authentication mechanism is their email. (As strange as that sounds, that’s the way things already work only less conveniently–you can reset pretty much any of your passwords by simply requesting an email, so we just made the security dependency on your email box explicit.) You can find some more detailed analysis of Email to ID at Silicon Florist.

Nathan Bell blogs about how he wishes OpenID would just go away, or at least fade into the background so that users don’t have to know quite so much to use it. I really like how he’s thinking over there, and will take some time to write up my thoughts on most of it sometime soon.

Meanwhile, I wanted to throw in my two cents on requirement #3 that he laid out in his post. I and some other Vidoopsters (Michael, Chris, Will) were working on one of our OpenID usability efforts and ended up convincing ourselves that the trust page doesn’t matter if no profile data is being handed off. The boolean value that represents the success or failure of an authentication attempt is certainly no more of a data leak than the claimed identifier that had already been submitted.

Or am I missing something?

Following Clickpass‘s lead, there are 3 key scenarios that a Universal OpenID Button needs to enable in order to gain widespread use on the web: 1) new user sign up, 2) existing user sign in, and 3) merge existing Identity 1.0 user with a new or existing OpenID user.

Despite the existing best practices for all 3 requirements (and many more), as you look around the web you’ll find implementations that demonstrate dozens of completely different takes on what it means to be an OpenID Relyer. One very important side effect of Clickpass’s approach is that their button essentially comes along with mandatory best practices. That is, any site which chooses to implement the Clickpass button will behave nearly identically to any other site that chooses to implement the button.

By necessity, this minimum set of behaviors will be very small–sites probably wouldn’t be as quick to get on board with the button if full-on AX support is required, for example. But the clear guidance that such a button program would provide would be invaluable in helping site owners understand what work goes into getting started with OpenID and doing it right.

Just to throw out a strawman to get some conversation going, I’d say that a Universal OpenID Button should start by supporting the three scenarios I called out above plus it should help users get their very first OpenID if they don’t already have one. This last bit might seem like it diverges from Clickpass, or even from the current practice of each site owner choosing which OpenID provider(s) to refer users to for whatever arbitrary reasons they like, but it doesn’t have to. Site owners could still choose to send their users to myVidoop.com or MyOpenID.com or Clickpass in the interest of either themselves or their users. Or if they don’t want to choose favorites, they could send their users to the OpenID Foundation for help in choosing a provider.

By the way, next post will be the one where I start going into deeper technical detail on how I think we can pull this off.

The great OpenID usability work that Clickpass recently launched and the reactions that followed have induced me to spend some time thinking about what this all means for OpenID.

The first conclusion that I reach is that Clickpass-style single-click single sign-on is almost inevitably the future of OpenID–it makes it trivially simple for even the least savvy user to understand how to sign up and how to sign in. And interestingly, Clickpass is not the first company to realize this–they’re simply the first company to tell a story that causes this to stand out to me as a particularly brilliant feature. Yahoo provides an OpenID button (whose obnoxiously typical terms of use require a 25 pixel moat around it), and Microsoft’s Passport Live ID has employed a button for approaching a decade.

The problem with all of these buttons is that there are bound to be so many of them. As in my article on annoying social bookmark icons, I can already begin to imagine the OpenID button area that we’re soon to start seeing pop up (and there are already some examples of poor re-inventions of the button-area):

The right way to solve this problem is for us all to agree right up front on a way for each publisher to only have only one button–an OpenID button. Clickpass has an implementation that’s more than halfway there, and I think that one possible future would consist of Clickpass having opened up their button to the point that a user who already has any other OpenID gets a first-class experience with the Clickpass button. I believe that Clickpass won’t ultimately thrive without being as open as possible and collaborating closely with the OpenID community, but from my brief conversations with Peter Nixey, it seems clear to me that they get that.

Another possible future (which is not mutually exclusive with the previous one) consists of the OpenID community coming together to build an OpenID button that does things right. Clickpass would certainly still have a business in providing added value over the community-owned OpenID button, but the community button would provide a non-proprietary alternative for those site owners who value openness over features.

I’ll follow this article up shortly with a description of the minimum set of features that would be required for a community button to take off.

Marshall Kirkpatrick’s claim that Vidoop is “a company made up largely of engineers with military backgrounds” makes for a great thriller plot, especially in the context of his National ID discussion over at ReadWriteWeb. That description, however, doesn’t reflect the Vidoop that I know. One of our developers was a civilian researcher at the Naval Research Labs for a couple of years, and one of our developers was in the Army long enough to spend some time in Afghanistan. That’s the extent of our military ties.

That said, there are some very interesting things to think about elsewhere in Marshall’s post. Like him, I’m not excited about being issued a National ID, let alone the prospect of having my OpenID inseparably tied to it. That just doesn’t make sense. I shouldn’t need a National ID to have a flickr account, and any such ID shouldn’t be associated with my search engine use.

But there are scenarios where being able to convey certain institutionally-verified claims about my identity online would be useful. For example, I miss certain wines from Washington State’s wine country because the State of Oklahoma won’t let me have wine shipped here. Perhaps it’s because they don’t want minors to have access to alcohol through the mail, or more likely it’s because they don’t want alcohol in the state for which they didn’t get their tax money. Either way, being able to prove that I’m old enough or that I paid appropriate taxes on the transaction are things that technology could enable in the near future, and there’s absolutely no reason that OpenID couldn’t be one of the protocols involved at the time I prove such things.

Remember that OpenID is all about putting control of your online identity in your very own hands, and there are built-in controls to make sure it will always continue to be that way. (The strongest such control is that anyone who doesn’t like the way the current Identity Providers work can always run their own Provider.)

Your identity shouldn’t do things that you don’t want it to do, but it should certainly be able to do all of the things that you do want it to do. And with OpenID each of us has the ability to want our OpenID to do different things.

One thing that concerns many people about OpenID is what happens if their provider goes out of business or if they want to switch to another provider for some other reason.

At Vidoop, we believe that users deserve to always be in control of their online identity, even if it means that they’d like to switch away. We’ll let them keep their URL and change to another provider.

We recently shipped a feature that allows a user to go to the Account/Advanced tab on our site and delegate their myVidoop.com OpenID URL to the OpenID provider of their choice. For example, right now, if you type sblom.myvidoop.com in to one of your favorite OpenID relying party’s web site, you’ll see that you’re redirected to openid.xmpp.za.net.

All OpenID users should expect their OpenID providers to do the same. Please ask them to do so–even if you’re happy with them now. What if they go out of business, or if you decide that you like another provider better?

I love some of the kookier OpenID authentication schemes that are out there.

Here’re a few examples of what I mean:

1. http://www.jkg.in/openid/ — Does not do authentication at all. Anyone can claim any URL as their own. I call it "OpenID with null authentication".
2. http://openid.xmpp.za.net/ — Sends a message to your Jabber (XMPP) account to confirm that it was you that made the OpenID request.
3. http://www.myvauthid.com/ — If it’s even real (can’t connect to it tonight), it’s apparently an OpenID provider that uses voice print to authenticate you. My cell phone isn’t consistent enough for this sort of thing to even work.

There are just short of 1.3 zillion OpenID concerns out there (no, seriosly–I counted), most of them well-intentioned but overblown. And most of them are just as applicable to username and password. The biggest difference is that everyone has experience with username and password and knows all of the best practices for dealing with them. Unfortunately, OpenID is still young, and so the best practices are still evolving.

Habari developer Owen Winkler over at Asymptomatic describes how after spending months away from Zooomr, he has forgotten which OpenID he used to sign up.

I had the same thing happen to me (maybe even more than once)before I got the hang of the whole OpenID thing. Now that I have the hang, though, I’m far better off because I get to use the same username everywhere instead of discovering that “sblom” is already taken or that they require at least 6 letters and having to choose “sblomqui” or “sblom000″ or something else entirely.

However, there will always be new users on a site who don’t yet have the hang of OpenID, and who haven’t yet settled on a favorite OpenID URL to use everywhere. They’re bound to forget which OpenID they used to sign in from time to time. This is where best practices come in. The OpenID wiki has a good and growing collection of OpenID Relying Party Best Practices, where they mention, among other things, that the right thing to do is to allow users to use the email on file with the Relying Party to change which OpenID account is associated with the account in case the user lost access to their OpenID, or forgot which one was used.

Owen, I’d be happy to help you out by explaining to Zooomr how to behave appropriately as an OpenID RP.