Perception and reality in the land of OpenID

OpenID LogoA couple related posts caught my attention recently about OpenID. As I’m now a board member of the OpenID Foundation, I feel some responsibility for helping to inform folks about OpenID: what it is, how it’s used, why I believe that it has so much potential — and at same time, address what it isn’t, won’t or can’t be, and what the scope of the OpenID solution stack is.

The first is a post by Nick O’Neill from the Social Times blog: “OpenID Organizes the Organizers While Facebook and Google Start Letting Users Login“. It was posted on December 29th.

He begins his criticism with a slight error:

Over the weekend the OpenID Foundation announced that they are having its first election of community board members.

In fact, over that particular weekend, the OIDF announced the results of its election, not the kick off.

But his broader sentiment deserves a response:

[…while] Facebook and Google have launched their own identity services that enable users to instantly log in to any site with third-party accounts[, … the] group seems to still be in the process of organizing though. … I think the group is over planning and under executing.

Josh Catone from SitePoint picked up his point, suggesting that “OpenID Needs to Start Getting Real“. He writes:

What the OpenID Foundation needs to do is start “getting real.” Getting real is a business philosophy from 37signals, a successful web application software company based in Chicago. Though there’s a lot more to their idea, one of the main themes essentially boils down to this: stop screwing around with all the stuff that doesn’t matter and just wastes time (like politics and meetings), and start doing the stuff that needs to get done (like building your app). Don’t worry about the details until people are already using what you’re selling.

I agree with O’Neill that so far the OpenID Foundation seems to be spending too much time on organizational stuff, and not enough time on actually doing what needs to get done. In a chapter of their book “Getting Real,” 37signals talks about how meetings can kill productivity. “Every minute you avoid spending in a meeting is a minute you can get real work done instead,” they write. From my admittedly outsider’s vantage point, it appears that the people behind OpenID are getting too caught up in the organizational stuff, getting too lost in the details, and not spending enough time on execution.

My perspective, of course, is that of an outsider. I’m not privy to what’s going on behind closed doors, so to speak. So my perception of what’s really going on could be off. But at this point in the game, public perception is what it’s all about.

And therein lies the heart of the problem. Perception is reality in the land of OpenID and will shape the thinking of developers, users and those who make up the OpenID and user-centered identity communities unless we initiate a campaign to earnestly counter those perceptions.

Nevermind that for OpenID to succeed, it must be developed with the involvement of many different groups, each with slightly different ideas, objectives and release cycles. Unlike Facebook Connect, OpenID is essentially consensus technology. To advance, it must secure and maintain the buy-in and adoption of many parties on every forward step. But let’s ignore that for a moment, because that’s an issue for us to overcome.

Jim Louderback (veteran of PC Mag) recounted his miserable experience trying to sign in to Disqus with his OpenID in a post titled “I can haz OpenID?“. Apparently, he can not, since he abandoned his comment and resorted to posting it to Twitter instead. The problem apparently had to do with Clickpass, but that’s besides the point, as the experience left a serious impression (emphasis mine):

And that gets me back to OpenID. I love the idea of having one set of identification credentials that I can use around the web. If it all works right, it’ll be awesome, birds will sing and the swallows will return to wherever they’ve disappeared from. But it won’t all work right, not all the time. We’re talking software here, and the internet, and the egos of childish web developers. Occasional (or more often) fail is guaranteed.

It’s even worse than I feared. A few days after my Disqus debacle I was talking with a developer friend of mine who was bemoaning the sorry state of OpenID implementations. It seems that all the big sites have their own flavors, and the OpenID foundation just doesn’t have enough clout to force a single standard across the web.

That’s a bad state of affairs. It guarantees more fail – and also guarantees epic finger-pointing. Who will lose? The users, first, who won’t be nearly as patient nor accommodating as I am. But in the end the whole glorious promise of OpenID will be left in tatters, and we’ll be back to our walled-gardens of identification. And that’s just too bad – because an open, interoperable identity system is actually one of the best ideas I’ve heard in a long time. Too bad no one can get their act together to actually build it right.

And these are the stories that will be told and retold because it’s not the successes that are heralded — it’s the epic failures. As much as I like to rag on Twitter about OAuth, their service is a million times better than it was six months ago during the Summer of the Fail. Twitter ops deserve a lot of credit for making hard decisions about which features should be cut in order to scale the service.

But when it works, people don’t shower Twitter with praise. It’s expected. It’s only when there are problems that people raise their voices — and it’s no different with OpenID. Unfortunately it’s this cacophony of complaints that ends up shaping the negative perceptions of OpenID.

So, when the Japanese chapter of the OpenID Foundation releases figures that show significant and gaining consumer awareness of OpenID in Japan that contradict the outdated and statistically insignificant findings (PDF) that Yahoo presented last year (on which so much criticism was heaped), few seem to notice.

openid-usage

Progress in Japan alone isn’t enough of course. But it does suggest that there is more to the story of OpenID’s overall progress and success in the marketplace. It also suggests that OpenID has yet to succumb to Facebook Connect or that it ever will (or that that’s even the right question).

Still, what all this says to me is that the OpenID Foundation and the community at large have its work cut out for itself.

As more people begin to believe in the promise of OpenID, more people will commit themselves to the success of OpenID, taking ownership of the idea, and promoting it their friends and family (as they did with Firefox). Our opportunity is to make good on the hope that people have for OpenID and effectively channel it to challenge the bruised perception that defines OpenID today. If we succeed, changing perceptions truly will change reality.

Twitter and the Password Anti-Pattern

Twitter / Alex Payne: @factoryjoe Yes, OAuth is ...

I’ve written about the password anti-pattern before, and have, with regards to Twitter, advocated for the adoption of some form of delegated authentication solution for some while.

It’s not as if Twitter or lead developer Alex Payne aren’t aware of the need for such a solution (in fact, it’s not only been publicly recognized (and is Issue #2 in their API issue queue), but the solution will be available as part of a “beta” program shortly). The problem is that it’s taken so long for Twitter’s “password anti-pattern” problem to get the proper attention that it deserves (Twitter acknowledged that they were moving to OAuth last August) that unsuspecting Twitter users have now exposed themselves (i.e. Twitter credentials) to the kind of threat we knew was there all along.

This isn’t the first time either, and it probably won’t be the last, at least until Twitter changes the way third party services access user accounts.

Rather than focus on Twply (which others have done, and whose evidence still lingers), I thought I’d talk about why this is an important problem, what solutions are available, why Twitter hasn’t adopted them and then look at what should happen here.
Continue reading “Twitter and the Password Anti-Pattern”

The results of the OpenID Board election are in!

I'm kind of a big dealI received an SMS from Michael Richardson this morning (around 8am here in Hawaii) congratulating me on my election to the board of the OpenID Foundation. It seems fitting that I should receive first word from him, since, as the Karl Rove of my campaign, he came up with the “kind of a big deal” slogan from Anchorman.

Anyway, I’m thrilled about the outcome of the election and am looking forward to working with Snorri Giorgetti, Nat Sakimura, David Recordon, (each of whom received two year terms along with me) and Eric Sachs, Scott Kveton, and Brian Kissel (who received one year terms).

I’m also pleased that 80% of the 217 foundation members voted in the first-ever OpenID election. We’ve obviously got a lot of work ahead of us, but I’m very confident that we’ll make great strides in 2009.

Responding to criticisms about OpenID: convenience, security and personal agency

Twitter / Chris Drackett:  openID should be dead... its over-rated.

Chris Dracket responded to one of my tweets the other day, saying that “OpenID should be dead… it’s way over-rated”. I’ve of course heard plenty of criticisms of OpenID, but hadn’t really heard that it was “overrated” (which implies that people have a higher opinion of OpenID than it merits).

Intrigued, I replied, asking him to elaborate, which he did via email:

I don’t know if overrated is the right word.. but I just don’t see OpenID ever catching on.. I think the main reason is that its too complex / scary of an idea for the normal user to understand and accept.

In my opinion the only way to make OpenID seem safe (for people who are worried about privacy online) is if the user has full control over the OpenID provider. While this is possible for people like you and me, my mom is never going to get to this point, and if she wants to use OpenID she is going to have to trust her sensitive data to AOL, MS, Google, etc. I think that people see giving this much “power” to a single provider as scary.

Lastly I think that OpenID is too complex to properly explain to someone and get them to use it. People understand usernames and passwords right away, and even OAuth, but OpenID in itself I think is too hard to grasp. I dunno, just a quick opinion.. I think there is a reason that we don’t have a single key on our key rings that opens our house, car, office and mailbox, not that that is a perfect/accurate analogy, but its close to how some people I’ve talked to think OpenID works.

Rather than respond privately, I asked whether it’d be okay if I posted his follow-up and replied on my blog. He obliged.

To summarize my interpretation of his points: OpenID is too complex and scary, potentially too insecure, and too confined to the hands of a few companies.

The summary of my rebuttals:


Convenience

OpenID should not be judged by today’s technological environment alone, but rather should be considered in the context of the migration to “cloud computing”, where people no longer access files on their local harddrive, but increasingly need to access data stored by web services.

All early technologies face criticism based on current trends and dominant behaviors, and OpenID is no different. At one time, people didn’t grok sending email between different services (in fact, you couldn’t). At one time, people didn’t grok IMing their AOL buddies using Google Talk (in fact, you couldn’t). At one time, you had one computer and your browser stored all of your passwords on the client-side (this is basically where we are today) and at one time, people accessed their photos, videos, and documents locally on their desktop (as is still the case for most people).

Cloud computing represents a shift in how people access and share data. Already, people rely less and less on physical media to store data and more and more on internet-based web services.

As a consequence, people will need a mechanism for referencing their data and services as convenient as the c: prompt. An OpenID, therefore, should become the referent people use to indicate where their data is “stored”.

An OpenID is not just about identification and blog comments; nor is it about reducing the number of passwords you have (that’s a by-product of user-centered design). Consider:

  • if I ask you where your photos are, you could say Flickr, and then prove it, because Flickr supports OpenID.
  • if I ask you where friends are, you might say MySpace, and then prove it, because MySpace will support OpenID.
  • if you host your own blog or website, you will be able to provide your address and then prove it, because you are OpenID-enabled.

The long-term benefit of OpenID is being able to refer to all the facets of your online identity and data sources with one handy — ideally memorable — web-friendly identifier. Rather than relying on my email addresses alone to identify myself, I would use my OpenIDs, and link to all the things that represent me online: from my resume to my photos to my current projects to my friends, web services and so on.

The big picture of cloud computing points to OpenIDs simplifying how people access, share and connect data to people and services.


Security

I’ve heard many people complain that if your OpenID gets hacked, then you’re screwed. They claim that it’s like putting all your eggs in one basket.

But that’s really no different than your email account getting hacked. Since your email address is used to reset your password, any or all of your accounts could have their passwords reset and changed; worse, the password and the account email address could be changed, locking you out completely.

At minimum, OpenID is no worse than the status quo.

At best, combined with OAuth, third-parties never need your account password, defeating the password anti-pattern and providing a more secure way to share your data.

Furthermore, because securing your OpenID is outside of the purview of the spec, you can choose an OpenID provider (or set up your own) with a level of security that fits your needs. So while many OpenID providers currently stick with the traditional username and password combo, others offer more sophisticated approaches, from client-side certificates and hardware keys to biometrics and image-based password shields (as in the case of my employer, Vidoop).

One added benefit of OpenID is the ability to audit and manage access to your account, just as you do with a credit card account. This means that you have a record of every time someone (hopefully you!) signs in to one of your accounts with your OpenID, as well as how frequently sign-ins occur, from which IP addresses and on what devices. From a security perspective, this is a major advantage over basic usernames and passwords, as collecting this information from each service provider would prove inconvenient and time-consuming, if even possible.

Given this benefit, it’s worth considering that identity technologies
are being pushed on the government. If you’re worried about putting all your eggs in one basket, would you think differently if the government owned that basket?

OpenID won’t force anyone to change their current behavior, certainly not right away. But wouldn’t it be better to have the option to choose an alternative way to secure your accounts if you wanted it? OpenID starts with the status quo and, coupled with OAuth, provides an opportunity to make things better.

We’re not going to make online computing more secure overnight, but it seems like a prudent place to start.


Personal agency for web citizens

Looking over the landscape of existing social software applications, I see very few (if any) that could not be enhanced by OpenID support.

OpenID is a cornerstone technology of the emerging social web, and adds value anywhere users have profiles, accounts or need access to remote data.

Historically, we’ve seen similar attempts at providing a universal login account. Microsoft even got the name right with “Passport”, but screwed up the network model. Any identity system, if it’s going to succeed on the open web, needs to be designed with user choice at its core, in order to facilitate marketplace competition. A single-origin federated identity network will always fail on the internet (as Joseph Smarr and John McCrea like to say of Facebook Connect: We’ve seen this movie before).

As such, selecting an identity provider should not be relegated to a default choice. Where you come from (what I call provenance) has meaning.

For example, if you connect to a service using your Facebook account, the relying party can presume that the profile information that Facebook supplies will be authentic, since Facebook works hard to ferret out fake accounts from its network (unlike MySpace). Similarly, signing in with a Google Account provides a verified email address.

Just like the issuing country of your passport may say something about you to the immigration official reviewing your documents, the OpenID provider that you use may also say something about you to the relying party that you’re signing in to. It is therefore critical that people make an informed choice about who provides (and protects) their identity online, and that the enabling technologies are built with the option for individuals to vouch for themselves.

In the network model where anyone can host their own independent OpenID (just like anyone can set up their own email server), competition may thrive. Where competition thrives, an ecosystem may arise, developed under the rubric of market dynamics and Darwinian survivalism. And in this model, the individual is at the center, rather than the services he or she uses.

This the citizen-centric model of the web, and each of us are sovereign citizens of the web. Since I define and host my own identity, I do not need to worry about services like Pownce being sold or I Want Sandy users left wanting. I have choice, I have bargaining power, and I have agency, and this is critical to the viability of the social web at scale.


Final words

OpenID is not overrated, it’s just early. We’re just getting started with writing the rules of social software on the web, and we’ve got a lot of bad habits to correct.

As cloud computing goes mainstream (evidenced in part by the growing popularity of Netbooks this holiday season!), we’re going to need a consumer-facing technology and brand like OpenID to help unify this new, more virtualized world, in order to make it universally accessible.

Fortunately, as we stack more and more technologies and services on our OpenIDs, we can independently innovate the security layer, developing increasingly sophisticated solutions as necessary to make sure that only the right people have access to our accounts and our data.

It is with with these changes that we must evaluate OpenID — not as a technology for 2008’s problems — but as a formative building block for 2009 and the future of the social web.

Where we’re going with Activity Streams

The DiSo Project is just over a year old. It’s remained a somewhat amorphous blob of related ideas, concepts and aspirations in my brain, but has resulted in some notable progress, even if such progress appears dubious on the surface.

For example, OAuth is a core aspect of DiSo because it enables site-to-site permissioning and safer data access. It’s not because of the DiSo Project that OAuth exists, but my involvement in the protocol certainly stems from the goals that I have with DiSo. Similarly, Portable Contacts emerged (among other things) as a response to Microsoft’s “beautiful fucking snowflakecontacts API, but it will be a core component of our efforts to distribute and decentralize social networking. And meanwhile, OpenID has had momentum and a following all its own, and yet it too fits into the DiSo model in my head, as a cornerstone technology on which much of the rest relies.

Subscribing to a person

Tonight I gave a talk specifically about activity streams. I’ve talked about them before, and I’ve written about them as well. But I think things started to click tonight for people for some reason. Maybe it was the introduction of the mocked up interface above (thanks Jyri!) that shows how you could consume activities based on human-readable content types, rather than by the service name on which they were produced. Maybe it was providing a narrative that illustrated how these various discreet and abstract technologies can add up to something rather sensible and desirable (and looks familiar, thanks to Facebook Connect).

In any case, I won’t overstate my point, but I think the work that we’ve been doing is going to start accelerating in 2009, and that the activity streams project, like OAuth before, will begin to grow legs.

And if I haven’t made it clear what I’m talking about, well, we’re starting with an assumption that activities (like the ones in Facebook’s newsfeed and that make up the bulk of FriendFeed’s content) are kind of like the synaptic electrical impulses that make social networking work. Consider that people probably read more Twitter content these days than they do conventional blog posts — if only because, with so much more content out there, we need more smaller bite-sized chunks of information in order to cope.

FriendFeed - Add/Edit ServicesSo starting there, we need to look at what it would take to recreate efficient and compelling interfaces for activity streams like we’re used to on FriendFeed and Facebook, but without the benefit of having ever seen any of the services before. I call this the “zero knowledge test”. Let me elaborate.

When I say “without the benefit of having ever seen”, I primarily mean from a programmatic standpoint. In other words, what would it take to be able to deliver an equivalent experience to FriendFeed without hardcoding support for only a few of the more popular services (FriendFeed currently supports 59 out of the thousands of candidate sites out there)? What would we need in a format to be able to join, group, de-dupe, and coalesce individual activities and otherwise make the resulting output look human readable?

Our approach so far has been to research and document what’s already out there (taking a hint from the microformats process). We’ve then begun to specify different approaches to solving this problem, from machine tags to microformats to extending ATOM (or perhaps RSS?).

Of course, we really just need to start writing some code. But fortunately with products like Motion in the wild and plugins like Action Stream, we at least have something to start with. Now it’s just a matter of rinse, wash and repeat.

I’m a candidate for the board of the OpenID Foundation!

I'm kind of a big dealThe OpenID Foundation board election opened up on December 10. After a grueling nominations process (not really), we were left with 17 candidates vying for seven community board member seats. Your candidates are (alphabetized by first name):

So far, a great deal of discussion has gone on about the various candidates’ platforms on the OpenID general mailing list. Candidates have also written about things that they would like to change in the coming year on their blogs as well, notably Dave Recordon and Johannes Ernst.

For my own part, I wrote up many of my ideas when I announced my candidacy. I also maintain a wiki page of goals that I have for OpenID.

The three issues that are at the top of my list should I be elected to the board really come down to:

  • establishing OpenID as a strong consumer brand
  • improving the user experience and ease-of-use of OpenID
  • enhancing the value of adopting OpenID for individuals, businesses, and organizations

I will lay out my rationale for these positions in a series of upcoming posts.

In the meantime, if you’d like to vote in this election, you will need to register for a $25 year-long membership in the OpenID Foundation (basically providing you the privilege to participate in this and other foundation elections and activities).

I also solicit your feedback, concerns and wishes for OpenID. Though I have plenty ideas about the kind of work that needs to go into OpenID to make it into a great cornerstone technology for the open web, I’m also very interested in hearing from other people about their experiences with OpenID, or about their ideas for how we can advance the cause of OpenID in 2009.

On invite-only betas

Fred Wilson wrote about the value of blogging and building social capital, demonstrated by the hundred requests for invites he received on his post on his recent investment, Boxee, an invite-only service.

Now, while I find the behavior of public invite-requesting curious, I understand it.

I also think there’s another side to this equation that I’d like to point out, being one of the fortunate early adopters who happens to get invited to a lot of early alphas and betas… and that’s understanding the relationship between the creator of the beta and the testers. Or, to put it another way, requesting an invite to a service for one’s own benefit is one thing; understanding that an invite is a privilege given in exchange for feedback and suggestions provided is another. And the secret to getting early access to beta programs is, perhaps obviously, to be a good beta tester.

There are any number of ways to demonstrate that you’re worthy of an invite to an invite-only alpha or beta program. One problem is that a lot of beta feedback is submitted privately, outside of public forums. Whenever I can, I attempt to use more public forums, both for my own recollection, but also for the benefit or other testers, developers and later users.

In other cases, I’ll use Flickr or Twitter, leading to interesting phenomena, similar to what Fred describes.

SpotifyIn particular, I’ve been alpha testing a music player called Spotify for some time. It’s an incredible service and recently opened up with three levels of service, although it’s sadly not available in the US yet owing to licensing issues. Now, the only way to get an account with the service is to request an invitation.

It just so happens that I screenshotted an element of the new interface, uploaded it to Flickr and titled the photo “Spotify Invites“. That photo is now the second result for that phrase on Google and people have noticed, quickly exhausting my supply of invites.

The problem with this scenario, and with Fred’s, is that many folks seem eager to get access solely for their own benefit, without thought to the quid pro quo that makes beta programs successful (and ultimately benefit both the developer and subsequent users!). And I think it’s worth it to point out that beta programs aren’t just freebie give-aways: the gate is there for a reason!

I wrote this post in 2005, back when Gmail was an invite-only service (!!) and I was thinking about the relationships we were attempting to cultivate with the Flock alpha tester program:

So what of all these invite-only (or formally invite-only) services where you have to know someone on the inside to get a golden ticket? Does it artificially increase desire? Does it help services grow organically and cut down on trolls and spam, creating more value for invitees? Does it create more investment from the user community and perhaps establish even minor connections between invitor and invitee? Or does it create a false hierarchy around an inner circle of well-connected geeks?

Who knows?

What I do know is that it’s a curious trend and happening rather profusely across the web. Good or bad? I can’t quite say — except that in the case of Flock, we’re using the invite system to start out slowly on purpose. We want to not only be able to scale up organically, but we also want to cultivate relationships with our brave early adopters so that we can build the best experience possible over time. And to that end — we want to make sure that when we do launch publicly, we’ve hammered out all the glaring issues — as well as minor ones — so that sum total Flock makes you more productive, more explorative, and more voraciously social on the web. So for now, Flock will remain available to few kindred souls with enough courage to shove through our bugs and dodge the sharp edges. In the meantime, do add yourself to our invite lottery so that your name will be there when the next round of invites go out.

Not much has changed in terms of the structure of invite-only betas (even though the tools for managing them have improved), but I think something of the intimacy and purpose of these programs have been missed as more of the mainstream have gotten used to handing out just their email address for access to such initiatives.

As Fred points out that there’s value in building up social capital so that you can help stoke interest in new projects and draw the interest of potentially valuable contributors and testers, but it’s just as important to highlight the value of diligent and hard-working testers who have an interest in improving products and becoming partners in the potential success of such projects. I think there’s the potential for mutually reinforcing and ongoing relationships in the execution of a productive beta program, and that those longer-term relationships should not be overlooked.

. . .

To that end, I’m looking for some highly motivated and qualified testers for , Real Mac Software’s new webpage screenshot utility. Be one of the first ten to leave a comment with your proper email address and a description of how you approach beta testing and I’ll send you info on where you can sign up. As I’m eager to see LittleSnapper mature, I won’t settle for just anyone — prove to me that you’d add value to the alpha tester program! 😉